第11篇 章 软件测试 软件工程电子教案 .ppt

复旦大学计算机科学与工程系 软件工程课程 原因排除法 原因排除法又可分为归纳法和演绎法。 归纳法是一种从特殊推断一般的系统化思考方法。其基本思想是：从一些线索（错误征兆）着手，通过分析它们之间的关系来找出错误的原因。 组织数据 收集 有关数据 研究数据 之间的关系 导出假设 证明假设 纠正错误 能 不能 能 不能 演绎法 演绎法从一般原理或前提出发，假设所有可能出错的原因，排除不可能正确的假设，最后推导出结论。 排除 不正确原因 列出 可能的原因 精化 剩余的假设 证明假设 收集 更多数据 纠正错误 无剩余 能 有 剩 余 不能 纠正错误 修改一个错误常常会引入新的错误 在为纠正某个错误而修改程序之前应该回答三个问题： 在程序的其他地方是否也存在同类的错误？ 本次修改可能会引发什么新的错误？ 为了防止这个错误，我们应该做什么？ 回归测试（Regression Testing） 在集成测试过程中，每当增加一个（或一组）新模块时，原先已集成的软件就发生了改变。新的数据流路径被建立，新的I/O操作可能出现，还可能激活新的控制逻辑，这些改变可能使原本正常的功能产生错误。 当测试时发现错误后，需修改程序；或者在软件维护时也需修改程序。这些对程序的修改也可能使原本正常的功能产生错误。 回归测试就是对已经进行过的测试的子集的重新执行，以确保对程序的改变和修改，没有传播非故意的副作用。 回归测试集（已经过测试的子集）包括三种不同类型的测试用例： 能测试软件所有功能的代表性测试用例 专门针对可能会被修改影响的软件功能的附加测试 注重于修改过的软件模块的测试 确认测试（Validation Testing） 确认测试标准 确认测试以软件需求规约为依据，以发现软件与需求不一致的错误。主要检查软件是否实现了规约规定的全部功能要求，文档资料是否完整、正确、合理，其他的需求，如可移植性、可维护性、兼容性、错误恢复能力等是否满足。 确认测试的结果可分为两类： 满足需求规约要求的功能或性能特性，用户可以接受。 发现与需求规约有偏差，此时需列出问题清单。 软件配置评审 软件配置评审也称软件审计（audit），其目的是保证软件配置的所有成分都齐全，各方面的质量都符合要求，具有维护阶段必需的细节，而且已经编排好分类目录。 软件配置主要包括计算机程序（源代码和可执行程序），针对开发者和用户的各类文档，包含在程序内部或程序外部的数据。 α测试和β测试 如果软件是为一个客户开发的，那么，最后由客户进行验收测试（acceptance test），以使客户确认该软件是他所需要的。 如果软件是给许多客户使用的（如市场上销售的各种软件），那么让每个客户做验收测试是不现实的。大多数软件厂商都使用一种称为α测试和β测试的过程，来发现那些似乎只有最终用户才能发现的错误。 α测试是由一个用户在开发者的场所进行的，软件在开发者对用户的“指导下”进行测试。经α测试后的软件称为β版软件。 β测试是由软件的最终用户在一个或多个用户场所进行的，与α测试不同，开发者通常不在测试现场，因此，β测试是软件在一个开发者不能控制的环境中的“活的”应用，用户记录所有在β测试中遇到的（真正的或想象的）问题，并定期把这些问题报告给开发者，在接到β测试的问题报告后，开发者对软件进行最后的修改，然后着手准备向所有的用户发布最终的软件产品。 系统测试（System Testing） 系统测试是对整个基于计算机的系统进行的一系列测试。 系统测试的种类很多，每种测试都有不同的目的，它们从不同的角度测试计算机系统是否被正常地集成，并完成相应的功能。 常用的系统测试包括： 恢复测试（recovery testing） 安全测试（security testing） 压力测试（stress testing） 性能测试（performance testing） 恢复测试（recovery testing） 恢复测试是通过各种手段，强制软件发生故障，然后来验证系统能否在指定的时间间隔内恢复正常，包括修正错误并重新启动系统。 如果恢复是由系统自身来完成的，那么，需验证重新初始化、检查点机制、数据恢复和重启动等的正确性。 如果恢复需要人工干预，那么要估算平均修复时间MTTR（mean time to repair）是否在用户可以接受的范围内。 安全测试（security testing） 安全测试用来验证集成在系统中的保护机制能否实际保护系统不受非法侵入。 在安全测试过程中，测试者扮演一个试图攻击系统的角色，采用各种方式攻击系统。例如，截取或码译密码；借助特殊软件攻击系统；“制服”系统，使他人无法访问；故意导致系统失效，企图在系统恢复之机侵入系统；通过浏览非保密数据，从中找出进入系统的钥匙等等。 一般来说，只要有