6.0 前言

当程序无法实现其最终用户要求的合理功能时，就发生了一个软件错误。 根据这个定义，即使完成了一次非常完美的模块测试，仍然不能保证已经找出了程序中的所有错误。因此，要结束整个测试任务，还必须进行其它形式的更深入的测试。我们将这些新形式的测试称为“更高级别的”测试。

软件开发过程在很大程度上是沟通有关最终程序的信息、并将信息从一种形式转换到另一种形式。由于这个原因，大部分软件错误都可以归因为信息沟通和转换时发生的故障、差错和干扰。

软件开发过程模型

1. 将软件最终用户的要求转换为一系列书面的需求。这些需求就是该软件产品要实现的目标。
2. 通过评估可行性与成本、消除相抵触的用户需求、建立优先级和平衡关系，将用户需求转换为具体的目标。
3. 将上述目标转换为一个准确的产品规格说明，将产品视为一个黑盒，仅考虑其接口以及与最终用户的交互。该规格说明被称为“外部规格说明”。
4. 如果该产品是一个系统，如操作系统、飞行控制系统、数据库管理系统或雇员人事系统等，而不仅是一个程序（编译器、工资程序、字处理程序等），那么下一步骤就是系统设计。该步骤将系统分割为单独的程序、部件或子系统，并定义它们的接口。
5. 通过定义每个模块的功能、模块的层次结构以及模块间的接口，来设计程序或程序集合的结构。
6. 设计一份准确的规格说明，定义每个模块的接口与功能。
7. 经过一个或更多的子步骤，将模块接口规格说明转换为每个模块的源代码算法。

假定软件开发周期的七个阶段包括了信息的沟通、理解与转换，以及大多数的软件错误都来源于信息处理中的故障，那么现在有三个补充的方法来预防或识别这些错误：

• 使软件开发过程更加精密，以防其中出现很多错误；
• 在每个阶段结束时可以引入一个独立的验证过程，在进入下一个阶段之前尽可能多地发现问题。
• 对不同的开发阶段采用不同的测试方法。如下图所示。这种结构的好处是避免了没有效果的多余测试，并使我们不会遗漏掉大量的错误类型。这种测试方法最适用于软件产品（作为合同的结果或面向广泛应用而编写的程序，与做试验用的或仅供作者本人使用的程序有所不同）。
  
• 模块测试的目的是为了发现程序模块与其接口规格说明之间的不一致。
• 功能测试的目的是为了证明程序未能符合其外部规格说明。
• 系统测试的目的是为了证明软件产品与其初始目标不一致。

注意：上图所示的测试过程顺序并不一定意味着严格的时间顺序。

6.1 功能测试

功能测试是一个试图发现程序与其外部规格说明之间存在不一致的过程。外部规格说明是一份从最终用户的角度对程序行为的精确描述。

除了在小程序中的使用情况之外，功能测试通常是一项黑盒操作。 也就是说，要依赖早期的模块测试的过程来实现理想的白盒逻辑覆盖准则。

在进行功能测试时，需要对规格说明进行分析以提炼测试用例。在第四章所讨论的等价类划分方法、边界值分析方法、因果图分析方法和错误猜测方法尤其适合于功能测试。

**应始终牢记功能测试的目的是为了暴露程序的错误以及发现程序与规格说明书中的不一致之处，而不是为了证明程序符合其规格说明书。

6.2 系统测试

系统测试并非是测试整个系统或者程序的过程，因为有了功能测试，这样会显得多余。系统测试有着特定的目的：将系统或程序与其初始目标进行比较。给定这个目标之后，隐含两方面的含义：

1. 系统测试并不局限于系统。如果产品是一个程序，那么系统测试就是一个试图说明程序作为一个整体是如何不满足其目标的过程。
2. 根据定义，如果产品没有一组书面的、可度量的目标，系统测试也就无法进行。

在寻找程序与其目标之间的不一致的过程中，应重点注意那些在设计外部规格说明的过程中所犯的转换错误。 就软件产品本身、所犯错误的数量及其严重性而言，开发周期的这个阶段是最易出错的。

这也暗示与功能测试不同，外部规格说明不能作为获得系统测试用例的基础，否则就破坏了系统测试的目标。 另一方面，也不能利用目标文档本身来表示测试用例，因为根据定义，这些文档并不包含对程序外部接口的准确描述。克服这一两难局面的方法是 利用程序的用户文档或书面材料——通过分析目标文档来设计系统测试，分析用户文档来阐明测试用例。

图中左边箭头表示将程序与其目标进行比较，是系统测试的核心目的，但是没有说明使用什么样的测试用例设计方法。由于没有一个方法，系统测试需要大量的创造性。建议我们在设计测试用例时，为了避免有所遗漏，应考虑尽可能多的类型。

6.2.1 能力测试

最明显的系统测试类型是判断目标文档提及的每一项能力（或功能，为了避免与功能测试发生混淆而不使用“功能”一词）是否都确实已经实现。能力测试的过程是逐条语句地检查目标文档，当某条语句定义了一个“要做什么”（例如，“语法应该一致…”、“用户应当可以指定一个空间范围…”等），就判断程序是否满足。此种类型的测试常常可以在不使用计算机的情况下进行。尽管如此，利用问题检查单将有助于在下一次进行测试时，确保人工检查的目标是相同的。

6.2.2 容量测试

第二类系统测试是使程序经受大容量数据的检验。 容量测试的目的是为了证明程序不能处理目标文档中规定的数据容量。

鉴于对机器和工时的考虑，不可以进行过多的容量测试。

6.2.3 强度测试

强度测试是使程序承受高负载或强度的检验。所谓高强度是指在很短的时间间隔内达到的数据或操作的数量峰值。不要和容量测试搞混淆。 以测试一名打字员为例子：容量测试是判断打字员能否处理大篇幅的稿子，而强度测试则是判断打字员能否达到每分钟50个单词的速度。

由于强度测试涉及时间因素，因此它不适用于很多程序。然而，强度测试适用于在可变负载下运行的程序，以及交互式程序、实时程序和过程控制程序。基于Web的应用程序是最常接受强度测试的软件之一。在这里，我们需要确信的是应用程序及硬件能够处理一定容量的并发用户。我们需要弄清用户群，然后设计一个强度测试，体现出可能访问站点的最大人群的情况。

6.2.4 可用性测试

可用性测试又叫用户体验测试。下一章将专门讨论。

6.2.5 安全性测试

安全性测试就是设计测试用例来突破程序安全检查的过程。举例来说，我们可以设计测试用例来规避操作系统的内存保护机制，破坏数据库管理系统的数据安全机制。设计此种测试用例的方法之一是研究类似系统中已知的安全问题，然后生成测试用例，尽量暴露被测系统存在相似问题。

6.2.6 性能测试

很多软件都有特定的性能或效率目标，这些特性描述为在特定负载和配置环境下程序的响应时间和吞吐率。再一次强调，由于系统测试的目的是为了证明程序不能实现其目标，因此应设计测试用例来说明程序不能满足其性能目标。

6.2.7 存储测试

软件偶尔会有存储目标，举例来说，可能描述了程序使用的内存和辅存的容量，以及临时文件或溢出文件的大小，应设计测试用例来证明这些存储目标没有得到满足。

6.2.8 配置设置

诸如操作系统、数据库管理系统和信息交换系统等软件都支持多种硬件配置，包括不同类型和数量的I/O设备和通信线路，或不同的存储容量。通常可能的配置数量非常之大，以至于测试无法面面俱到，但是至少应该使用每一种类型的设备，以最大和最小的配置来测试程序。

如果软件本身的配置可以忽略掉某些程序组件，或可运行在不同的计算机上，那么该软件所有可能的配置都应测试到。

6.2.9 兼容性/转换测试

大多数开发的软件都并不是全新的，常常是为了替换某些不完善的系统。这样的软件往往有着特定的目标，涉及与现有系统的兼容以及从现有系统的转换过程。再次强调，在针对这些目标测试程序时，测试用例的目的是证明兼容性目标未被满足，转换过程并未生效。 在将数据从一个系统转移到另一个系统时，应尽力发现错误。

6.2.10 安装测试

测试安装过程是系统测试中的一个重要部分。对于包含在软件包中的自动安装系统而言，这尤其重要。

6.2.11 可靠性测试

如果软件的目标中包含了对可靠性的特别描述，就必须设计专门的可靠性测试。

6.2.12 可恢复性测试

诸如操作系统、数据库管理系统和远程处理系统等软件通常都有可恢复性目标，说明系统如何从程序错误、硬件失效和数据错误中恢复过来。这些系统的设计目标之一是使平均恢复时间（MTTR）最小。系统测试的一个目标是证明这些恢复机制不能够正确发挥作用。我们可以故意将程序错误置入某个系统中，判断系统是否可以从中恢复。 MTTR往往有上界和下界，所以测试用例应反映出这些界限。

6.2.13 服务/可维护性测试

软件还可能有服务或可维护性的目标。所有的此类目标都必须测试到。这些目标可能定义了系统提供的服务辅助功能。

6.2.14 文档测试

系统测试也需要检查用户文档的正确性。完成此任务的主要方法是根据文档来确定系统测试用例的形式。也就是说，一旦完成某个具体的测试情况，应该使用文档作为编写实际测试用例的指南。同时，用户文档应成为审查的对象，检查其正确性和清晰性。在文档中描述的任何范例应编成测试用例，并提交给程序。

6.2.15 过程测试

在系统测试中，必须对所以已规定的人工过程进行测试，例如系统操作员、数据库管理员或最终用户的操作过程。

6.2.16 系统测试的执行

首先，系统测试不能由程序员来执行；其次，在所有的测试阶段中，这是唯一一个明确地不能由负责该程序开发的机构来执行的测试。也许最经济的执行系统测试的方式是讲测试分包给一个独立的公司来完成。

6.3 验收测试

验收测试是将程序与其最初的需求及最终用户当前的需要进行比较的过程。这是一种不寻常的测试类型，因为该测试通常是由程序的客户或最终用户进行，一般不认为是软件开发机构的职责。

如同其它类型的测试一样，验收测试的最好方法是设计测试用例，尽力证明程序没有满足合同要求。

6.4 安装测试

安装测试与其它测试过程不同，与设计过程中的任何阶段都没有联系。他的不寻常是由于其目的不是为了发现软件中的错误，而是为了发现在安装过程中出现的错误。

在安装软件系统期间会发生很多事情。作为示例的简短列表包括了下列事件：

1. 用户必须选择大量的选项。
2. 必须分配并加载文件和库。
3. 必须进行有效的硬件配置。
4. 软件可能要求网络联通，以便和其它软件连接。

安装测试应由生产软件系统的机构来设计，作为软件的一部分来发布，在系统安装完成之后进行。除此之外，测试用例需要检查以确认已选的选项集合互不冲突，系统的所有部件全部存在，所有的文件已经创建并包含必须内容，硬件配置妥当等。

6.5 测试的计划与控制

与大多数项目的情况一样，计划是管理测试过程中至关重要的一环。一个良好的测试计划应包括：

1. 目标。必须定义每个测试阶段的目标。
2. 结束准则。必须制定准则以规定每个测试阶段何时可以结束。
3. 进度。每个阶段都须有时间表。应指出何时设计、编写和执行测试用例。
4. 责任。对于每一个阶段，应对确定谁来设计、编写和验证测试用例，谁来修改发现的软件错误。由于在大型项目中讨论特定的测试结果是否代表错误时，有可能出现争端，因此还需要一名仲裁者。
5. 测试用例库及标准。在大型项目中，用于确定、编写以及存储测试用例的系统方法是必须的。
6. 工具。必须确定需要使用的测试工具，包括计划由谁来开发或采购、如何使用工具以及何时需要使用工具。
7. 计算机时间。计划每个测试阶段所需的计算机时间，包括用来编译应用程序的服务器、用来进行安装测试所需的桌面计算机、用来运行基于Web应用程序的Web服务器、联网的设备等。
8. 硬件配置。
9. 集成。测试计划的一部分是定义程序如何组装在一起的方法。一个系统如果包含大的子系统或程序，可按增量的方式组装在一起，例如可以使用自顶向下或自底向上的方法，但是这些构造块是程序或子系统，不是模块。如果是这种情况，就需要一个系统集成计划。系统集成计划规定了系统集成的顺序、系统每个版本的功能以及编写“脚手架”代码以模拟不存在的部件的职责分工。
10. 跟踪步骤。必须跟踪测试进行中的方方面面，包括对错误易发模块的定位，以及有关进度、资源和结束准则的进展估计。
11. 调试步骤。必须制定上报已发现错误、跟踪错误修改进程以及将修改部分加入系统中去的机制。调试计划中还应包括进度、责任分工、工具以及计算机时间/资源等。
12. 回归测试。回归测试在对程序做了功能改进或进行了修改之后进行，其目的是判断程序的改动是否引起了程序其他方面的退步。回归测试通常重新执行测试用例中的某个子集。回归测试计划规定了测试人员、测试方法和测试时间，它也是必须的。

6.6 测试结束准则

有三类较为有用的结束准则：

1. 第一类，但不是最佳的准则，根据的是特定的测试用例设计技术。举例来说，
   我们会这样定义模块测试的结束准则：测试用例来源于（1）满足多重条件覆盖准则；（2）对模块接口规格说明进行边界值分析，产生的所有测试用例最终都是不成功的。
   我们会在满足下列情况时规定功能测试结束：测试用例来源于（1）因果图分析，（2）边界值分析，（3）错误猜测，产生的所有测试用例最终都是不成功的。
2. 第二类，也许是最有价值的准则，是以确切的数量来描述结束测试的条件。举例来说，在对某个具体模块进行模块测试时，直到发现了三个错误才可以认为测试结束了。要得到这一数字需要进行下面几个预测：（1）预测程序中错误的总数量。一种方法是利用以前程序的经验来预测出数字。另外，还可以使用多种预测模型。还有一种方法是使用行业范围内的平均值。（2）预测这些错误中有多大比例可能通过测试而发现。（3）预测这些错误中有多少是由各个设计阶段产生的，以及在什么样的测试阶段能够发现这些问题。
3. 第三类结束准则需要我们在测试过程中记录每单位时间内发现的错误数量。通过检查统计曲线的形状，常常可以决定究竟是继续该阶段的测试，还是结束它开始下一测试阶段。

最佳结束准则可能是上述三种类型的组合。

6.7 独立的测试机构

6.8 小结

更高级别的测试可以看做是测试的下一阶段。

功能测试试图去发现设计上的错误，也即是程序和外部规格说明书之间的不匹配之处。

系统测试从另一方面来测试软件及其最初目标的关系。系统测试用于寻找从程序设计目标转换到规格说明书最后转化成具体代码实现的每一个环节中可能发生的错误。系统测试成功的关键是始终连贯的。周密详细的计划。可以考虑聘请专门的第三方公司进行测试和测试的管理。