第8章软件测试 在软件开发过程中以及软件开发完成后，如何验证软件满足了要求，不存在 缺陷呢？由于软件系统复杂性和对其它软件、硬件的依赖性，没有办法通过数学 证明或者别的技术手段来回答这个问题。在实际软件开发项目中，软件测试是一 个不可缺少的环节，它通过将实际输出与预期输出进行审核或者比较，来揭示软 件中存在的缺陷，以便开发者进行改进。由于不可能执行所有的情况，因此我们 是通过设计一些测试用例希望它们能够揭露尽可能多的软件中存在的缺陷。同时， 由于测试的时间和费用有限，我们也需要认真规划测试过程，使测试达到的效果 最好。 另一方面，广义的测试活动不是软件开发后续过程中的一个阶段，测试的对 象也不仅是程序本身。测试活动应贯穿于软件开发的整个过程，只有这样，才能 更有效率地的开发出有质量保障的优质软件系统。尽管测试工作贯穿了软件开发 的全过程，但是我们所称呼的“测试阶段”一般都是发生在软件开发生命周期的末 期。 8.1软件测试的主要内容 为了使软件测试能够真正发挥作用，并与整个开发过程相配合，软件测试工 作必须要通过制定测试计划、设计测试、测试准备、执行测试、评估测试几个阶 段来完成。 8.1.1测试计划的制定 测试计划是对测试的对象、测试中需要的资源、测试的时间安排等进行规划 的过程。通过确定任务、识别和分析风险、安排资源和确定进度，并以文档的方 式记录下来。当然，测试计划也不是静态的，它可能在早期作为整个开发计划的 一部分，进行较为粗略的制订，而后随着项目的进行，不断完善，并在执行过程 中进行动态的调整。一般来说，测试计划应该包含以下几个方面。 (1)测试范围，也就是测试对象的界定 (2)风险的确定
第 8 章 软件测试 在软件开发过程中以及软件开发完成后，如何验证软件满足了要求，不存在 缺陷呢？由于软件系统复杂性和对其它软件、硬件的依赖性，没有办法通过数学 证明或者别的技术手段来回答这个问题。在实际软件开发项目中，软件测试是一 个不可缺少的环节，它通过将实际输出与预期输出进行审核或者比较，来揭示软 件中存在的缺陷，以便开发者进行改进。由于不可能执行所有的情况，因此我们 是通过设计一些测试用例希望它们能够揭露尽可能多的软件中存在的缺陷。同时， 由于测试的时间和费用有限，我们也需要认真规划测试过程，使测试达到的效果 最好。 另一方面，广义的测试活动不是软件开发后续过程中的一个阶段，测试的对 象也不仅是程序本身。测试活动应贯穿于软件开发的整个过程，只有这样，才能 更有效率地的开发出有质量保障的优质软件系统。尽管测试工作贯穿了软件开发 的全过程，但是我们所称呼的“测试阶段”一般都是发生在软件开发生命周期的末 期。 8.1 软件测试的主要内容 为了使软件测试能够真正发挥作用，并与整个开发过程相配合，软件测试工 作必须要通过制定测试计划、设计测试、测试准备、执行测试、评估测试几个阶 段来完成。 8.1.1 测试计划的制定 测试计划是对测试的对象、测试中需要的资源、测试的时间安排等进行规划 的过程。通过确定任务、识别和分析风险、安排资源和确定进度，并以文档的方 式记录下来。当然，测试计划也不是静态的，它可能在早期作为整个开发计划的 一部分，进行较为粗略的制订，而后随着项目的进行，不断完善，并在执行过程 中进行动态的调整。一般来说，测试计划应该包含以下几个方面。 （1）测试范围，也就是测试对象的界定 （2）风险的确定
(3)资源的规划 (4)时间进度的制定 8.1.2 测试用例和测试流程的设计 测试开始前需要设计测试用例，以及具体的测试流程。测试的设计需要依据 测试需求进行。 1.测试需求分析 对测试需求进行分析时，需要对需求进行分解，察看各种文档，和用户进行 交流。测试需求分析中考虑的问题如下： (1)确定软件的主要用例 (2)对每一个用例，确定其输入、输出、限制以及要达到的性能指标，形成测 试需求 (3)对每一个测试需求，判断其属于的测试类型（功能、性能、安全测试等）。 可以构造测试跟踪需求矩阵，针对每一个用例，列出其多项测试需求以及相应的 测试类型 (4)对于整个软件，考虑是否需要进行以下的测试： ●整个系统的性能测试 ·整个系统的安全性测试 ● 整个系统的兼容性测试 ● 整个系统的容量测试 ● 系统的界面测试 系统的安装测试 2.测试用例的设计 测试用例指对一项特定的测试任务的描述，体现了测试方案、技术、策略和 具体的方式。值得提出的是，测试用例都是从数量极大的可用测试方案中精心挑 选出的，能够最大限度发现软件缺陷的方案。由于测试用例的执行需要耗费时间， 因此，过多的测试用例可能会需要过长的时间，然而，过少的测试用例可能会带 来软件中潜在的、未发现的缺陷数量的过大，因此，如何平衡这两方面的要求， 进行合理的测试用例的选择，一直是软件测试工作的重点和难点。 评价测试用例的好坏有以下两个标准：①是否可以发现尚未发现的软件缺 陷？②是否可以覆盖全部的测试需求？
（3）资源的规划 （4）时间进度的制定 8.1.2 测试用例和测试流程的设计 测试开始前需要设计测试用例，以及具体的测试流程。测试的设计需要依据 测试需求进行。 1．测试需求分析 对测试需求进行分析时，需要对需求进行分解，察看各种文档，和用户进行 交流。测试需求分析中考虑的问题如下： （1）确定软件的主要用例 （2）对每一个用例，确定其输入、输出、限制以及要达到的性能指标，形成测 试需求 （3）对每一个测试需求，判断其属于的测试类型（功能、性能、安全测试等）。 可以构造测试跟踪需求矩阵，针对每一个用例，列出其多项测试需求以及相应的 测试类型 （4）对于整个软件，考虑是否需要进行以下的测试： 整个系统的性能测试 整个系统的安全性测试 整个系统的兼容性测试 整个系统的容量测试 系统的界面测试 系统的安装测试 2．测试用例的设计 测试用例指对一项特定的测试任务的描述，体现了测试方案、技术、策略和 具体的方式。值得提出的是，测试用例都是从数量极大的可用测试方案中精心挑 选出的，能够最大限度发现软件缺陷的方案。由于测试用例的执行需要耗费时间， 因此，过多的测试用例可能会需要过长的时间，然而，过少的测试用例可能会带 来软件中潜在的、未发现的缺陷数量的过大，因此，如何平衡这两方面的要求， 进行合理的测试用例的选择，一直是软件测试工作的重点和难点。 评价测试用例的好坏有以下两个标准：① 是否可以发现尚未发现的软件缺 陷？② 是否可以覆盖全部的测试需求？
8.1.3 测试的准备 测试的准备是指准备测试环境、准备测试数据、准备测试脚本和测试辅助代 码等过程。 1.准备测试环境 (1)测试规程准备 (2)技术准备 (3)配置软件、硬件环境，包括测试工具 (4)人员 2.测试数据准备 测试数据中包括测试输入以及测试输出，它具有两种情形： (1)正常事务的测试数据 (2)引发异常的测试数据 3.测试脚本的准备和测试辅助代码的编写 在测试过程中，有些时候也需要进行代码的编写工作。 在集成测试中，需要根据测试策略编写驱动模块和桩模块。驱动模块用以模 拟被测模块的上级模块，驱动模块接受测试数据，把相关的数据传送给被测模块， 启动被测模块，并接收和记录相应的返回数据。而桩模块模拟被测模块工作过程 中所调用的模块，一般只进行很少的数据处理。 随着自动化测试工具的流行，我们需要编写测试脚本，从而可以使测试能够 自动进行。许多工具中提供了通过“录制回放”的方式生成自动化测试脚本的方法， 但是它不够灵活。因此，测试人员可以利用脚本语言自行编写测试程序。 8.1.4执行测试 执行测试是按照计划执行所有的测试用例，并观察其测试结果的过程。在执 行测试过程中，应该按照模版填写相应的信息。如果采用了自动测试工具，那么 需要能够熟练使用这些工具完成测试过程。 8.1.5测试评估 当测试完成后，需要对测试工作进行一个总结。总结主要从两个方面进行
8.1.3 测试的准备 测试的准备是指准备测试环境、准备测试数据、准备测试脚本和测试辅助代 码等过程。 1．准备测试环境 （1）测试规程准备 （2）技术准备 （3）配置软件、硬件环境，包括测试工具 （4）人员 2．测试数据准备 测试数据中包括测试输入以及测试输出，它具有两种情形： （1）正常事务的测试数据 （2）引发异常的测试数据 3．测试脚本的准备和测试辅助代码的编写 在测试过程中，有些时候也需要进行代码的编写工作。 在集成测试中，需要根据测试策略编写驱动模块和桩模块。驱动模块用以模 拟被测模块的上级模块，驱动模块接受测试数据，把相关的数据传送给被测模块， 启动被测模块，并接收和记录相应的返回数据。而桩模块模拟被测模块工作过程 中所调用的模块，一般只进行很少的数据处理。 随着自动化测试工具的流行，我们需要编写测试脚本，从而可以使测试能够 自动进行。许多工具中提供了通过“录制回放”的方式生成自动化测试脚本的方法， 但是它不够灵活。因此，测试人员可以利用脚本语言自行编写测试程序。 8.1.4 执行测试 执行测试是按照计划执行所有的测试用例，并观察其测试结果的过程。在执 行测试过程中，应该按照模版填写相应的信息。如果采用了自动测试工具，那么 需要能够熟练使用这些工具完成测试过程。 8.1.5 测试评估 当测试完成后，需要对测试工作进行一个总结。总结主要从两个方面进行
一个是覆盖性，一个是测试质量。 1.测试的覆盖性 覆盖性回答的是“测试的完全程度如何”这一问题。覆盖性可以从两个角度 来看待，一个是从需求的角度，一个是从代码的角度。从需求的角度，就是要求 每个需求是否满足都被测试到，从代码角度，就是要求按照一定的标准，所有的 代码都被测试到。 2.测试的质量 测试质量评估的是测试过程发现缺陷的能力。 8.2测试类型 从不同的角度，测试可以分为不同的类型。我们将按照测试阶段和测试 8.2.1按照测试阶段的划分 从测试发生的阶段看，可以分为：需求分析审查、设计审查、代码审查、单 元测试、集成测试和系统测试等。 需求分析审查、设计审查、单元测试中的代码评审及各阶段测试用例的评审 都是通过对相关文档或代码的走读活动来实现的。虽然这种方法比较简单，但是 实践证明，如果安排合理，能够以较低的成本发现大部分的缺陷。通过检查方式 而非执行代码来发现缺陷的测试称为静态测试。单元测试、集成测试及系统测试 等通过运行软件来检验软件的动态行为和运行结果正确性的测试方法称之为动 态测试。 1.需求分析审查 需求规格说明书是系统设计、系统测试等的基础，也是整个项目的规划、验 收的基础。因此，对其进行检查，确定其中存在的缺陷对保障软件项目的成功具 有突出的意义。软件需求规格说明书的评审是由评审专家组进行的，主要看其是 否尽可能完整地、无二义地描述了功能和性能需求，以及在实现上是否具有可行 性。评审时经常以会议方式进行，通过将缺陷确认、整理、修改到评审专家组认 可。 2.设计审查 对软件设计的审查是通过评审专家对设计文档进行预审后，在评审会议上与
一个是覆盖性，一个是测试质量。 1．测试的覆盖性 覆盖性回答的是“测试的完全程度如何”这一问题。覆盖性可以从两个角度 来看待，一个是从需求的角度，一个是从代码的角度。从需求的角度，就是要求 每个需求是否满足都被测试到，从代码角度，就是要求按照一定的标准，所有的 代码都被测试到。 2．测试的质量 测试质量评估的是测试过程发现缺陷的能力。 8.2 测试类型 从不同的角度，测试可以分为不同的类型。我们将按照测试阶段和测试 8.2.1 按照测试阶段的划分 从测试发生的阶段看，可以分为：需求分析审查、设计审查、代码审查、单 元测试、集成测试和系统测试等。 需求分析审查、设计审查、单元测试中的代码评审及各阶段测试用例的评审 都是通过对相关文档或代码的走读活动来实现的。虽然这种方法比较简单，但是 实践证明，如果安排合理，能够以较低的成本发现大部分的缺陷。通过检查方式 而非执行代码来发现缺陷的测试称为静态测试。单元测试、集成测试及系统测试 等通过运行软件来检验软件的动态行为和运行结果正确性的测试方法称之为动 态测试。 1．需求分析审查 需求规格说明书是系统设计、系统测试等的基础，也是整个项目的规划、验 收的基础。因此，对其进行检查，确定其中存在的缺陷对保障软件项目的成功具 有突出的意义。软件需求规格说明书的评审是由评审专家组进行的，主要看其是 否尽可能完整地、无二义地描述了功能和性能需求，以及在实现上是否具有可行 性。评审时经常以会议方式进行，通过将缺陷确认、整理、修改到评审专家组认 可。 2．设计审查 对软件设计的审查是通过评审专家对设计文档进行预审后，在评审会议上与
设计人员将问题一一确认来实现。 评审专家依据需求规格说明书审查设计是否覆盖到用户提出的每个用例，对 子系统的划分、类的确定、类中属性和方法的确定、数据访问方式、安全性保障、 性能保障等进行详细的审查。 3.代码审查 代码审查是通过代码走读的方式来实现的。代码走读是开发人员在对某个模 块的代码（必须编译通过）完成编码后，进行的代码评审活动。代码走读前依据 企业制订的统一标准，按照统一的流程进行。代码审查可以在不同的层面进行， 单元审查是对一个方法或一个类，查找代码层面的错误；集成审查关注接口和流 程，包括传入的参数检查、返回值检查及流程能否顺利地进行和正确集成等；第 三个层面可称之为系统审查，关注功能层面和业务逻辑。 4.单元测试 单元测试是对软件中的基本组成单位进行测试，检验其函数的正确性（包括 功能正常，输出正确)。 一般来说，单元测试用例的编写最早可以在设计评审完成后就启动。单元测 试用例编写的目的是覆盖性，覆盖的方法有：语句覆盖、分支覆盖、条件覆盖、 条件组合覆盖和路径覆盖等。为了以最少的资源做最多的测试检查，首选路径覆 盖的方法。路径覆盖是设计足够的测试用例，运行所测程序并覆盖程序中所有可 能的路径。 5.集成测试 集成测试是软件系统在集成过程中所进行的测试。其主要目的是检查软件单 位之间的接口是否正确。 集成测试用例的编写要紧扣与程序相关的各个接口，使每类接口的数据流或 控制流均通过接口，从而实现接口测试的完全性。注意：对同一数据流要分别进 行正确数据流与错误数据流的用例设计，对边界值的输入最好有单独的用例。集 成测试还应关注接口的性能问题，根据系统的性能需求还要设计相关的接口性能 测试用例。集成测试的执行主要是借助测试工具一一桩程序来实现。桩程序的编 写最好由他人来完成，以防止一个人对接口定义理解有偏差而使意外发生。 6.系统测试 系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正 确性以及性能等是否满足各系统的需要。除了验证系统的功能外，还需要验证系 统的容错能力、错误恢复能力、安全性、性能等。 7.验收测试
设计人员将问题一一确认来实现。 评审专家依据需求规格说明书审查设计是否覆盖到用户提出的每个用例，对 子系统的划分、类的确定、类中属性和方法的确定、数据访问方式、安全性保障、 性能保障等进行详细的审查。 3．代码审查 代码审查是通过代码走读的方式来实现的。代码走读是开发人员在对某个模 块的代码（必须编译通过）完成编码后，进行的代码评审活动。代码走读前依据 企业制订的统一标准，按照统一的流程进行。代码审查可以在不同的层面进行， 单元审查是对一个方法或一个类，查找代码层面的错误；集成审查关注接口和流 程，包括传入的参数检查、返回值检查及流程能否顺利地进行和正确集成等；第 三个层面可称之为系统审查，关注功能层面和业务逻辑。 4．单元测试 单元测试是对软件中的基本组成单位进行测试，检验其函数的正确性（包括 功能正常，输出正确）。 一般来说，单元测试用例的编写最早可以在设计评审完成后就启动。单元测 试用例编写的目的是覆盖性，覆盖的方法有：语句覆盖、分支覆盖、条件覆盖、 条件组合覆盖和路径覆盖等。为了以最少的资源做最多的测试检查，首选路径覆 盖的方法。路径覆盖是设计足够的测试用例，运行所测程序并覆盖程序中所有可 能的路径。 5．集成测试 集成测试是软件系统在集成过程中所进行的测试。其主要目的是检查软件单 位之间的接口是否正确。 集成测试用例的编写要紧扣与程序相关的各个接口，使每类接口的数据流或 控制流均通过接口，从而实现接口测试的完全性。注意：对同一数据流要分别进 行正确数据流与错误数据流的用例设计，对边界值的输入最好有单独的用例。集 成测试还应关注接口的性能问题，根据系统的性能需求还要设计相关的接口性能 测试用例。集成测试的执行主要是借助测试工具——桩程序来实现。桩程序的编 写最好由他人来完成，以防止一个人对接口定义理解有偏差而使意外发生。 6．系统测试 系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正 确性以及性能等是否满足各系统的需要。除了验证系统的功能外，还需要验证系 统的容错能力、错误恢复能力、安全性、性能等。 7. 验收测试