02_ 软件测试基础

1 / 11 October 2010 / HP-EDS INTERNAL ISTQB Training - FL 软件测试基础 11 October 2010 2 / 11 October 2010 / HP-EDS INTERNAL ISTQB Training - FL 课程目标 完成本章节后，你将掌握如下知识：  为什么需要软件测试  什么是软件测试  基本的测试过程  软件测试的基本原则  测试的心理学 3 / 11 October 2010 / HP-EDS INTERNAL ISTQB Training - FL 为什么需要软件测试？ 4 / 11 October 2010 / HP-EDS INTERNAL ISTQB Training - FL 软件测试的起源与历史  60年代以前 软件测试通常跟“调试”（Debug）关联在一起，由开发人员执行。没有单纯意义上 的软件测试，软件测试还没有形成概念。  70年代初期 Bill Hetzel提出软件测试是为了证明程序是正确的，首先提出软件工程的概念。  70年代末期 Glenford J Myers提出软件测试是为了证明程序是有错误的。  80年代 提出了一系列各种复杂而精密的软件开发 设计 领导形象设计圆作业设计ao工艺污水处理厂设计附属工程施工组织设计清扫机器人结构设计 流程和管理方法，例如CMM、CMMI软 件测试也有了行业 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载 IEEE/ANSI。  90年代 手工测试（Manual Test）到测试工具的发展。  现在 软件测试管理工具的大量应用 5 / 11 October 2010 / HP-EDS INTERNAL ISTQB Training - FL 软件系统的重要性 金融领域 • 金融服务系统 • 在线支付 • 消费卡服务 制造领域 • 生产管理 • 采购管理 • 销售管理 医疗领域 • 仪器设备 • 病历管理 • 血库管理 通信领域 • 计费管理 • 积分管理 • 客户管理 软件系统 • 资金的损失 • 时间的损失 • 商业信誉的损失 软件错误可能造成 6 / 11 October 2010 / HP-EDS INTERNAL ISTQB Training - FL 软件错误的例子 计算机2000年问题 http://baike.baidu.com/view/9349.htm 火星探测器“勇气号” Mars Rover”Spirit” 二00四年一月 http://marsovers.jpl.nasa.gov/newsroom /pressreleaes/20040128a.html 7 / 11 October 2010 / HP-EDS INTERNAL ISTQB Training - FL 错误被引入软件 PM：小李，订单模块明天 之前编码必须完成，并提交 给测试组进行测试。 Programmer：明天？..那好吧， 这个模块功能很多，需要编写的 代码非常的多。 …… 紧接着，他只好埋头苦干，拼命 的写着代码。 If intPrice>0 Then receipt = intPrice * 1.0 …… A mistake! 这应该是10，被 程序员错误的写 成了1.0 8 / 11 October 2010 / HP-EDS INTERNAL ISTQB Training - FL 引起软件缺陷的原因 人本身容易犯错误 时间的压力 复杂的代码 复杂的系统架构 技术的革新 复杂的外部系统 软件 系统 文档 9 / 11 October 2010 / HP-EDS INTERNAL ISTQB Training - FL 失效（Failure）与缺陷（Bug） • 失效——Failure (fail or flop) in general refers to the state or condition of not meeting a desirable or intended objective. It may be viewed as the opposite of success • 缺陷——A software bug (or just ―bug‖) is an error, flaw, mistake, failure, fault or ―undocumented feature‖ in a computer program that prevents it from behaving as intended (e.g., producing an incorrect or unexpected result) 第一个被发现的软件缺陷 • 辐射可能导致软/硬失效 • 电磁场可能导致软/硬件失效 • 污染可能导致软/硬件失效 并非所有的失效都是缺陷导致 10 / 11 October 2010 / HP-EDS INTERNAL ISTQB Training - FL 用户的质量体验 功能被实现功能未被实现 用户满意度高 用户满意度低 卡鲁模型 测试可以发现严 重影响用户满意 度的缺陷，修正 这些缺陷将会提 高软件质量。 一个设计合理的测 试过程完成并顺利 通过，可以降低系 统存在的问题的风 险，从而保证质量。 通过发现缺陷改正 缺陷这样的途径， 有利于软件质量进 一步得到改善，从 而可能达到较高的 用户体验。 Basic factors Performance factors Excitement factors 11 / 11 October 2010 / HP-EDS INTERNAL ISTQB Training - FL ISO9126质量模型 http://en.wikipedia.org/wiki/ISO_9126 9126 Functionality Reliability Usability Efficiency Maintainability Portability • Suitability • Accuracy • Interoperability • Compliance • Security • Maturity • Recoverability • Fault Tolerance • Learnability • Understandability • Operability • Installability • Replaceability • Adaptability • Time Behaviour • Resource Behaviour • Stability • Analyzability • Changeability • Testability 12 / 11 October 2010 / HP-EDS INTERNAL ISTQB Training - FL 测试与质量要素 Functionality Reliability Usability Efficiency Maintainability Portability ?.. 六个质量要素，难道是 所有的都需要进行度量 和测试吗？ 在VSR系统中，我们认 为functionality, usability以及reliability 是最要的质量要素，因 此我们应该重点保证这 三方面的质量。 测试应该重点放在与用户实际需求密 切相关的质量要素上。 因此定义哪些质量要素是最重要的就 尤为重要。 13 / 11 October 2010 / HP-EDS INTERNAL ISTQB Training - FL 一个理想的测试 假设我们需要测试如下的一段程序，我们的目标是测试各条执行路径的情况，执行时从 A点开始，直到B点，然后循环回到A点，同时我们假设这段程序被限制循环20次。 A B 520+519+518+…+51 = 119209289550780 手工测试（3分钟/次） 自动化测试（3秒钟/次） 大约需要680418319年 执行完 大约需要11340305年 执行完 14 / 11 October 2010 / HP-EDS INTERNAL ISTQB Training - FL 测试何时结束 • 软件的开发一般受到成本、进度和质 量的制约。 • 质量需要考虑成本与进度，从而得到 一个可接受的质量水平。 • 没有单纯意义的软件质量。 成本、进度与质量 • 质量的可接受水平需要利益相关者的 足够信息来确定。 • 当通过开展测试活动，使得软件达到 利益相关者所定义的可接受水平时， 意味着测试活动可以结束。 质量的可接受水平 15 / 11 October 2010 / HP-EDS INTERNAL ISTQB Training - FL 什么是软件测试？ 16 / 11 October 2010 / HP-EDS INTERNAL ISTQB Training - FL 汽车工业的例子——购车 购车的动机 • 代步需要 • 兴趣爱好 • 投资 试车（试驾）的动机 • 检查质量 • 检查功能 试车（试驾）的目的不是 • 试图破坏汽车 • 试图改进汽车的设计 购车过程中，用户预期的目的决定了他/ 她会采用如何的方式来试驾购买的车辆。 17 / 11 October 2010 / HP-EDS INTERNAL ISTQB Training - FL 试驾的目标和方法 试驾的目标 • 确定是否买得起 – 首付，月供，利率和旧 车回购 • 确认外观是否吸引人 – 车身风格，配色，内饰 • 确认舒适性 – 前后门上下车，乘坐人 员放腿的空间 • 确认有用性 – 座位数，后备箱空间 • 确认汽车性能 – 油耗，最低油号要求， 高速并线加速，超车加 速，低速转弯，高速转 弯 测试方法包括 • 检查标价和买车 合同 劳动合同范本免费下载装修合同范本免费下载租赁合同免费下载房屋买卖合同下载劳务合同范本下载 • 试用收音机，空调和车灯 • 尝试加速，停止和转弯 软件测试术语的表示 • 检查 = 静态测试 （在不用开车的情况下进 行观察，阅读和检查） • 试用 = 功能和结构测试 （在不用开车的情况下检 查汽车的功能） • 试驾 = 性能测试 （在实际开车的情况下检 查汽车的功能） 18 / 11 October 2010 / HP-EDS INTERNAL ISTQB Training - FL 开发人员级别的非软件测试——造车 来自市场营销部门的需求 • 6个座位 • 可载5个提箱 • 使用普通汽油 • 最高时速每小时80公里 汽车制造人员的设计 • 基于新车需求设计汽车模型 • 基于新车需求设计各种功能 • 根据设计制造原型车 汽车测试人员所做的测试 • 基于新车需求和设计细则做测试计划 • 检查设计蓝图和粘土模型 • 进行和分析风洞测试 • 进行和分析安全测试 • 建造原型车并验证其功能 • 驾驶原型车并验证其操作 19 / 11 October 2010 / HP-EDS INTERNAL ISTQB Training - FL 汽车测试人员所做的测试  静态测试的例子 阅读汽车设计细则，检查市场部要求的汽车需求是否都被在汽车设计中有所体现。  测试计划的例子 根据新型车在开发过程中所需要进行的各种测试，可能需要100辆原型车，这些原型 车将用于在流水线生产前进行各种测试，包括功能测试、碰撞测试、行驶测试等。  功能和结构测试的例子 阅读有关暖风和空调的功能描述，在这里驾驶员就可以知道在寒冷的天气里要多长时 间才能达到合适的温度。  性能测试的例子 阅读关于旅行中极端天气条件测试的描述，有些汽车被专门运送到冰冻的环境中，并 且需要在华氏零下的温度中进行操作。另一些车被运送到非常热的环境下，在高于 120oF的环境下进行操作。 20 / 11 October 2010 / HP-EDS INTERNAL ISTQB Training - FL 测试的主要目标 在所有商业开发项目上的主要 测试动机几乎都是一样的：减 少计划外的开销风险（Risk）， 或者更严重的说，项目失败的 风险。这一开发风险可以被量 化为某种可见的损失，包括收 入的损失或者用户的流失。 而有些开发风险则过于巨大， 以至于如果项目失败，公司的 整个业务都会面临危险。  发现缺陷（实施测试来降低所发现的风险）  正面测试  反面测试  预防缺陷（发现可以通过测试避免的开发风险的规模 和来源）  风险可能造成较大的损失  风险实际发生的概率  风险是否可以通过测试得到降低  提供对系统质量相关的信息和信息（确定测试何时可 以结束）  产品质量是否已经达到用户要求  正面测试是否充分  反面测试是否充分  对产品而言重要的风险是否都已经通过测试 21 / 11 October 2010 / HP-EDS INTERNAL ISTQB Training - FL 软件开发过程中的测试 需求 (Req) 设计 (Desn) 编码 (Code) 发布 (Reles) 业务 需要 需求测试 系统架构测试 单元测试、组件集成测试、系统集成测试 系统测试、非功能性测试 验证需求文档 的可测性、完 整性、正确性 验证系统设计 的合理性、完 整性 对各组件进行功 能测试 静态测试 静态测试 动态测试 静态测试 动态测试 静态测试 动态测试 测试 (Test) 22 / 11 October 2010 / HP-EDS INTERNAL ISTQB Training - FL 调试（Debug）还是测试（Test） 开发人员的测试：是调试（Debug）还是测试（Test）? 调试（Debugging）: 测试（Testing）: 在源程序内定为错误 诱发错误 分析错误的原因 重现错误 修改错误 定为错误(功能·需求·模块) 在程序运行时检验程序功能 记录 混凝土 养护记录下载土方回填监理旁站记录免费下载集备记录下载集备记录下载集备记录下载 错误 调试是 “建设性” 的 测试是 “破坏性” 的 23 / 11 October 2010 / HP-EDS INTERNAL ISTQB Training - FL 基本的测试过程 24 / 11 October 2010 / HP-EDS INTERNAL ISTQB Training - FL 测试过程 开始 计划 & 控制 分析 & 设计 实现 & 执行 评估出口准则 & 报告 软件系统测试报告下载sgs报告如何下载关于路面塌陷情况报告535n,sgs报告怎么下载竣工报告下载 测试结束活动 结束 结构化的软件测试过程 结构化的软件测试，使 软件测试在整个软件开 发过程中可以对软件进 行系统的，结构化的测 试。 结构化的软件测试过程 包括： • 计划和控制 • 分析和设计 • 实现和执行 • 评估出口准则和报告 • 测试结束活动 25 / 11 October 2010 / HP-EDS INTERNAL ISTQB Training - FL 计划和控制  测试过程的监控应该贯穿所有测试活动  应该及时通过监控信息的反馈，适时的调整 测试活动，比如调整测试计划  应该制定一些可度量的监控目标，从而监控 测试过程 计划 控制  识别测试任务  定义测试目标  定义为达到测试目标和任务所必须的测试活动 26 / 11 October 2010 / HP-EDS INTERNAL ISTQB Training - FL VSR-System的测试策略选择 VSR系统由以下子系统组成： DreamCar –允许用户根据需要选择不同的配置 ContractBase –管理客户信息、购买合同 JustInTime –允许用户根据已经选择的配置提交订 单 EasyFinance –进行付款计算 NoRisk –提供汽车保险业务 DreamCar ContractBase JustIn Time NoRisk EasyFinance Host 1 Exchange of car data 2 Exchange of contract data 3 Exchange of order data VirtualShowRoom (VSR) 1 2 2 2 3 重点测试这两个模 块，将进行全面的 单元测试、功能测 试、性能测试。 只对这两个模块主 要功能进行功能测 试，若时间允许， 可进一步进行全面 的功能测试。 该模块的打印功能 可适当测试，但订 单处理功能需要进 行严格的功能测试。 27 / 11 October 2010 / HP-EDS INTERNAL ISTQB Training - FL 分析和设计  设计测试用例并确定优先级  确定测试条件和测试用例所需的必要的测试 数据  规划测试环境的搭建和确定测试需要的基础 设施和工具 分析 设计  评审测试依据（比如需求、系统架构、设计和 接口说明等）  评估测试依据和测试对象的可测性  通过对测试项、规格说明、测试对象行为和结 构的分析，识别测试条件并确定其优先级 28 / 11 October 2010 / HP-EDS INTERNAL ISTQB Training - FL 测试需求 进行测试分析时，首先需要考虑的是是否有足够的信息，使得可以设计出测试案例，这包括： 1. 是否存在明确的期望结果 无论是对软件进行单元测试 还是功能测试，只有当定义了明确的期望结果，才可以去判断程 序执行是正确还是错误。 例如： 当用户在操作系统中选中某文件，并点击“Delete”键后，系统将弹出如下对话框 2. 期望结果描述是否完整、准确 测试的期望结果描述是否足够准确和完整，以至测试人员可以开发出相应的测试案例。 例如： 当用户在操作系统中选中某文件，并点击“Delete”键后，系统将弹出对话框。 说明：未对弹出对话框进行足够多的描述，无法衡量应该弹出什么样的对话框。这样的需求 缺乏可测性，因为无法准确度量。 29 / 11 October 2010 / HP-EDS INTERNAL ISTQB Training - FL 案例设计 某公司计划在圣诞节时给员工发放奖金，公司规定凡在公司工作3年以上（不含3年）5年（含5年）以 下的员工，可得到本月工资的50%做为奖金；凡工作5年以上8年（含8年）以下的员工，可得到本月 工资的75%做为奖金；凡工作8年以上者，可得到本月工资的100%做为奖金。 测试案例编号 输入 期望结果 1 X <= 3 0 2 3 < X <= 5 50 3 5 < X <= 8 75 4 X > 8 100 逻辑案例（Logical Case） 测试案例编号 输入 期望结果 1 2 0 2 4 50 3 7 75 4 12 100 可执行案例（Physical Case） 30 / 11 October 2010 / HP-EDS INTERNAL ISTQB Training - FL 实现和执行  根据计划的执行顺序，通过手工或使用测试 执行工具来执行测试规程  记录测试执行的结果，以及被测软件、测试 工具和测试件的标识和版本  将实际结果和预期结果进行比较  对实际结果和预期结果之间的差异，作为事 件上报  缺陷修正后，重新进行测试活动 实现 执行  测试用例的开发、实现并确定它们的优先级  开发测试规程并确定优先级，创建测试数据， 同时也可以准备测试用具和设计自动化测试脚 本  根据测试规程创建测试套件，以提高测试执行 的效率  确认已经正确搭建了测试环境 31 / 11 October 2010 / HP-EDS INTERNAL ISTQB Training - FL 评估出口准则和报告  依据评估结果，向利益相关者（ stakeholders）汇报测试情况，通常这样的 报告分两个级别：  非正式（Informal） • 例如单元测试的报告可能就是 Email的形式提交给测试 Leader或者Manager  正式（Formal） • 例如系统集成测试，用户验收测 试的报告可能就是以正式的文档 提交给相关人员 评估出口准则 报告  按照测试计划中定义的测试出口准则检查测试 日志  评估是否需要进行更多的测试，或是否需要更 改测试的出口准则 32 / 11 October 2010 / HP-EDS INTERNAL ISTQB Training - FL 测试结束活动 测试结束活动  在以下几种情况下需要进行测试的结束活动：  软件系统正式使用的时候  测试项目结束（或取消）的时候  达到里程碑的时候  维护版本发布完成的时候  测试结束活动的主要任务：  检查提交了哪些测试计划的可交付产品、 事件报告是否关闭、或对未关闭的事件 报告提交变更需求、以及系统的验收文 档状态等等  记录和归档测试件、测试环境和测试基 础设备，以备将来项目使用  移交测试件到维护部门  分析和记录经验教训 33 / 11 October 2010 / HP-EDS INTERNAL ISTQB Training - FL 软件测试的基本原则 34 / 11 October 2010 / HP-EDS INTERNAL ISTQB Training - FL 基本原则  测试显示缺陷的存在 #1 测试可以显示缺陷的存在，但不能证明系统不存在缺陷。测试可以减少软件中存在未被发现 缺陷的可能性，但即使测试没有发现任何缺陷，也不能证明软件或系统是完全正确的。  穷尽测试是不可能的 #2 除了小型项目，进行完全（各种输入和前提条件的组合）的测试是不可能的。通过运用风险 分析和不同系统功能的测试优先级，来确定测试的关注点，从而替代穷尽测试。  测试尽早介入 #3 在软件或系统开发生命周期中，测试活动应该尽可能早的介入，并且应该将关注点放在已经 定义的测试目标上。 35 / 11 October 2010 / HP-EDS INTERNAL ISTQB Training - FL 软件缺陷的修复成本 36 / 11 October 2010 / HP-EDS INTERNAL ISTQB Training - FL 基本原则  缺陷集群性 #4 版本发布前进行的测试所发现的大部分缺陷和软件运行失效是由于少数软件模块引起的。  杀虫剂悖论 #5 采用同样的测试用例多次重复进行测试，最后将不再能够发现新的缺陷。为了克服这种“杀 虫剂悖论”，测试用例需要进行定期评审和修改，同时需要不断增加新的不同的测试用例来 测试软件或系统的不同部分，从而发现潜在的更多的缺陷。  测试活动依赖于测试背景 #6 针对不同的测试背景，进行的测试活动也是不同的。比如，对安全关键的软件进行测试，与 对一般的电子商务软件的测试是不一样的。  不存在缺陷（就是有用系统）的谬论 #7 假如系统无法使用，或者系统不能完成客户的需求和期望，发现和修改缺陷是没有任何意义 的。 37 / 11 October 2010 / HP-EDS INTERNAL ISTQB Training - FL 测试的心理学 38 / 11 October 2010 / HP-EDS INTERNAL ISTQB Training - FL 开发人员的思维  开发人员的思维是构造思维 开发人员在设法通过程序实现用户需求时，更多的是思考如何来实现 功能而并非破坏该功能。  同时具备构造思维和破坏思维是一件不容易的事情  思维的局限性 对开发人员测试的建议 • 交叉测试——对开发人员级别的测试，例如单元测试，可以让不同的 开发人员交叉测试彼此的代码，从而避免由于测试自己代码而带来的 思维定势 • 独立测试——可提交测试给独立的测试团队来进行相关的测试 39 / 11 October 2010 / HP-EDS INTERNAL ISTQB Training - FL 测试人员的思维  技术思维能力 对技术的建模能力和理解原因与后果的能力。  创造思维能力 提出新想法和预见可能性的能力。  批判思维能力 评价想法并进行推理的能力。  实践思维能力 将想法变成现实的能力 测试人员的思维是一种破坏性的思维 40 / 11 October 2010 / HP-EDS INTERNAL ISTQB Training - FL 独立测试 一定程度的独立，通常可以更加高效地发现软件缺陷和软件存在的失效。 可以定义不同级别的独立：  测试由软件本身编写的人员来执行（低级别的独立）  测试由一个其他开发人员（如来自同一开发小组）来执行  测试由组织内的一个或多个其他小组成员（如独立的测试小组）或测试专家（如可用性或 性能测试专家）来执行  测试由来自其他组织或其他公司的成员来执行（如测试外包或其他外部组织的鉴定） 41 / 11 October 2010 / HP-EDS INTERNAL ISTQB Training - FL 沟通问题 在以建设性的方式讨论缺陷、进度和风险时，测试 员和测试的负责人需要具有良好的人与人之间沟通 的能力，当沟通方面的问题经常发生，特别是当测 试员只是被视为不受欢迎的缺陷消息的传递者时， 可依据下列方法来改善沟通关系：  以合作而不是斗争的方式开展项目，时时提醒项目 的每位成员：共同目标是最求高质量的产品  对产品中发现的问题以中性的和以事实为依据的方 式来沟通，而不要指责引入这个问题的小组成员或 个人。  尽量理解其他成员的感受，以及他们为什么会有这 种反应  确信其他成员已经理解你的描述 42 / 11 October 2010 / HP-EDS INTERNAL ISTQB Training - FL 小结 软件测试基础 • 认识了造成软件缺陷的原因，以及什么是软件失效（Failure）和软件缺陷（Bug） • 软件质量的度量模型ISO9126 • 软件测试的目标是发现缺陷、预防缺陷和提供质量信心 • 基本的软件测试过程由五大部分组成 • 软件测试的七个基本原则 • 软件测试的心理学，创造性思维和破坏性思维的对立，以及独立测试的必要性