2. 单元测试的步骤
   * 模块并不是一个独立的程序，在考虑测试模块时，同时要考虑它和外界的联系，用一些辅助模块去模拟与被测模块相联系的其它模块。
   – 驱动模块 (driver)
   – 桩模块 (stub) —— 存根模块
   * 如果一个模块要完成多种功能，可以将这个模块看成由几个小程序组成。必须对其中的每个小程序先进行单元测试要做的工作，对关键模块还要做性能测试。
   * 对支持某些标准规程的程序，更要着手进行互联测试。有人把这种情况特别称为模块测试，以区别单元测试。
   集成测试（Integrated Testing）
   * 集成测试 (集成测试、联合测试）
   * 通常，在单元测试的基础上，需要将所有模块按照设计要求组装成为系统。这时需要考虑的问题是：
   – 在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；
   – 一个模块的功能是否会对另一个模块的功能产生不利的影响；
   – 各个子功能组合起来，能否达到预期要求的父功能；
   – 全局数据结构是否有问题；
   – 单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。
   在单元测试的同时可进行集成测试，
   发现并排除在模块连接中可能出现
   的问题，最终构成要求的软件系统。
   * 子系统的集成测试特别称为部件测试，它所做的工作是要找出集成后的子系统与系统需求规格说明之间的不一致。
   * 通常，把模块集成成为系统的方式有两种
   – 一次性集成方式
   – 增殖式集成方式
   1. 一次性集成方式(big bang)
   * 它是一种非增殖式组装方式。也叫做整体拼装。
   * 使用这种方式，首先对每个模块分别进行模块测试，然后再把所有模块组装在一起进行测试，最终得到要求的软件系统。
   2. 增殖式集成方式
   * 这种集成方式又称渐增式集成
   * 首先对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统
   * 在集成的过程中边连接边测试，以发现连接过程中产生的问题
   * 通过增殖逐步组装成为要求的软件系统。
   (1) 自顶向下的增殖方式
   * 这种集成方式将模块按系统程序结构，沿控制层次自顶向下进行组装。
   * 自顶向下的增殖方式在测试过程中较早地验证了主要的控制和判断点。
   * 选用按深度方向组装的方式，可以首先实现和验证一个完整的软件功能。
   (2) 自底向上的增殖方式
   * 这种集成的方式是从程序模块结构的最底层的模块开始集成和测试。
   * 因为模块是自底向上进行组装，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）已经组装并测试完成，所以不再需要桩模块。在模块的测试过程中需要从子模块得到的信息可以直接运行子模块得到。
   * 自顶向下增殖的方式和自底向上增殖的方式各有优缺点。
   * 一般来讲，一种方式的优点是另一种方式的缺点。
   (3) 混合增殖式测试
   * 衍变的自顶向下的增殖测试
   – 首先对输入／输出模块和引入新算法模块进行测试;
   – 再自底向上组装成为功能相当完整且相对独立的子系统;
   – 然后由主模块开始自顶向下进行增殖测试。
   * 自底向上-自顶向下的增殖测试


   – 首先对含读操作的子系统自底向上直至根结点模块进行组装和测试;
   – 然后对含写操作的子系统做自顶向下的组装与测试。
   * 回归测试
   – 这种方式采取自顶向下的方式测试被修改的模块及其子模块;
   – 然后将这一部分视为子系统，再自底向上测试。
   关键模块问题
   * 在组装测试时，应当确定关键模块，对这些关键模块及早进行测试。
   * 关键模块的特征：
   ① 满足某些软件需求；
   ② 在程序的模块结构中位于较高的层次（高层控制模块）；
   ③ 较复杂、较易发生错误；
   ④ 有明确定义的性能要求。
   确认测试（Validation Testing）
   * 确认测试又称有效性测试。任务是验证软件的功能和性能及其它特性是否与用户的要求一致。
   * 对软件的功能和性能要求在软件需求规格说明书中已经明确规定。它包含的信息就是软件确认测试的基础。
   1. 进行有效性测试（黑盒测试）
   * 有效性测试是在模拟的环境 (可能就是开发的环境) 下，运用黑盒测试的方法，验证被测软件是否满足需求规格说明书列出的需求。
   * 首先制定测试计划，规定要做测试的种类。还需要制定一组测试步骤，描述具体的测试用例。
   * 通过实施预定的测试计划和测试步骤，确定
   – 软件的特性是否与需求相符；
   – 所有的文档都是正确且便于使用；
   – 同时，对其它软件需求，例如可移植性、兼容性、出错自动恢复、可维护性等，也都要进行测试
   * 在全部软件测试的测试用例运行完后，所有的测试结果可以分为两类：
   – 测试结果与预期的结果相符。这说明软件的这部分功能或性能特征与需求规格说明书相符合，从而这部分程序被接受。
   – 测试结果与预期的结果不符。这说明软件的这部分功能或性能特征与需求规格说明不一致，因此要为它提交一份问题报告。
   2. 软件配置复查
   n 软件配置复查的目的是保证
   u 软件配置的所有成分都齐全；
   u 各方面的质量都符合要求；
   u 具有维护阶段所必需的细节；
   u 而且已经编排好分类的目录。
   n 应当严格遵守用户手册和操作手册中规定的使用步骤，以便检查这些文档资料的完整性和正确性。
   验收测试（Acceptance Testing）
   * 在通过了系统的有效性测试及软件配置审查之后，就应开始系统的验收测试。
   * 验收测试是以用户为主的测试。软件开发人员和QA（质量保证）人员也应参加。
   * 由用户参加设计测试用例，使用生产中的实际数据进行测试。
   * 在测试过程中，除了考虑软件的功能和性能外，还应对软件的可移植性、兼容性、可维护性、错误的恢复功能等进行确认。
   * 确认测试应交付的文档有：
   – 确认测试分析报告
   – 最终的用户手册和操作手册
   – 项目开发总结报告。
   系统测试（System Testing）
   * 系统测试，是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。
   * 系统测试的目的在于通过与系统的需求定义作比较, 发现软件与系统的定义不符合或与之矛盾的地方。
2