第2章软件测试的策略与过程.ppt

第二章 软件测试策略与过程 第2章 软件测试策略与过程 2.1 软件测试的复杂性分析 2.2 排除软件缺陷的手段 2.3 软件测试方法与策略 2.4 单元测试 2.5 集成测试 2.6 确认测试 2.7 系统测试 2.8 验收测试 2.9 测试后的调试 2.10 面向对象的软件测试 本章教学目标 理解软件测试的复杂性 理解软件测试的方法与策略 明确单元测试的主要任务和过程 明确集成测试的方法和确认测试的准则 明确系统测试的八个领域测试要点 明确验收测试的主要内容和相关配置 2.1 软件测试的复杂性分析 1、无法对程序进行完全测试 （1）测试所需要的输入量太大 （2）测试的输出结果太多 （3）软件实现的途径太多 （4）软件规格说明没有一个客观标准 2、测试无法显示潜在的软件缺陷和故障 ——通过软件测试只能报告软件已被发现的缺陷和故障，无法报告隐藏的软件故障。 3、存在的故障现象与发现的故障数量成正比 ——结论：应当对故障集中的程序段进行重点测试 无法进行完全测试的例子-1 无法进行完全测试的例子-2 软件测试的复杂性分析（续） 4、不能修复所有的软件故障 ——原因：没有足够的进行修复；修复的风险较大；不值得修复;可不算做故障的一些缺陷；“杀虫剂现象”。 ——结论：关键是要进行正确的判断、合理的取舍，根据风险分析决定哪些故障必须修复，哪些故障可以不修复。 5、软件测试的代价 ——工作原则：就是如何将无边无际的可能性减小到一个可以控制的范围，以及如何针对软件风险做出恰当选择，去粗存精，找到最佳的测试量，使得测试工作量不多也不少，既能达到测试的目的，又能较为经济。 软件测试的复杂性分析（续） 2.2 排除软件缺陷的手段 软件测试 软件项目评审 软件测试 软件测试 ● 测试在软件开发中占有重要地位 ● 测试成本占总开发成本的近一半 软件开发成本分布 测试人员所占比例 实际产品中的情况 软件项目评审 软件生存期中缺陷的引入、传递与消除 缺陷跟踪 缺陷的状态 Microsoft Fixed Duplicated Postponed By design Not repro Wont fix Athens Olympic Games System Open In Analysis Accepted Rejected Fixed Delivered Pending Closed Reopened Unresolved 测试对象 程序测试：发现程序中的缺陷 测试对象 文档测试：发现文档中存在的各种错误，以及各种文档之间的逻辑不一致性等 需求规格说明 设计说明（概要与详细） 程序（代码走查，编写的代码是否符合既定的规范和标准等，不是指可执行的二进制代码） 测试用例、测试计划、测试结果报告 用户手册、安装/配置手册、帮助文档等 其他 样本/范例，错误提示信息和产品支持信息等 软件测试信息流 为什么要实施测试评审 测试计划与测试评审的关系 测试与开发前期工作的关系 测试查错曲线 生存期各阶段V、VT活动 软件生存期各阶段的VVT活动 需求分析阶段 制定本项目的VVT计划 设置基于需求的测试用例 对需求进行评审与分析 对用户手册初稿进行评审与分析 概要设计阶段 修订VVT计划 制定基于设计的测试步骤 对概要设计进行评审与分析 详细设计阶段 设置基于设计的功能测试数据 对详细设计进行评审与分析 软件生存期各阶段的VVT活动(续) 程序编写和单元测试 完成测试用例说明书 进行单元测试 进行集成测试 安装 进行系统测试 进行验收测试 运行和维护阶段 软件评价 软件修改评价 回归测试 （引自美国国家标准局信息处理标准FIPS PUB101） 如何正确对待测试工作 １．明确测试工作意义 ２．加强责任心，疏忽可能造成恶果 ３．学习——实践——钻研，积累经验， 　　努力提高业务水平 ４．处理好与编程人员关系 测试工作评估问题 你单位是否有专人负责测试工作？ 你们是否有、是否用测试计划规范？ 你们是否有、是否用单元测试规程？ 你们是否有、是否用测试报告规范？ 测试过程（包括计划和实施）与整个开发过程是否并行开展？（测试在开发初期着手，在开发结束完成） 测试能够确认规格说明得到正确的实现吗？ 除规格说明以外，你能否确认用户的期望也能满足吗？ 测试人员能验证开发的阶段（如需求和设计）的精确性和完全性吗？ 测试人员向开发人员报告缺陷以期进一步采取措施吗？ 在制定计划之前测试人员能估计业务风险吗？ 测试工作评估问题(续) 针对被测软件是否提出了可度量的测试目标？ 如已提出，它与商业风险有关吗？ 测试中发现的缺陷是否做了纪录和总结，使其用于改进开发过