软件测试的艺术(第3版)第06章 更高级别的测试

1、p6.1 功能测试 p6.2 系统测试 p6.3 验收测试 p6.4 安装测试 p6.5 测试的计划与控制 p6.6 测试结束准则 p6.7 独立的测试机构 第6章 更高级别的测试 p软件测试 n特点：软件应该是可预测且稳定的，不会给用户 带来意外惊奇。 n定义：软件测试是一个过程或一系列过程，用来 确认计算机代码完成了其应该完成的功能，不执 行其不该有的操作。 第6章 更高级别的测试 p要结束整个测试任务，除模块测试外，还要 进行其他更深入的测试，我们称之为“更高 级别的”测试。 p软件开发过程在很大程度上是沟通有关最终 程序的信息，并将信息从一种形式转换到另 一种形式，因此，绝大部分软件错

2、误都可以 归因为信息沟通和转换时发生的故障、差错 和干扰。 下图为软件开发过程的各个阶段： 第6章 更高级别的测试 最终用户 需求 代码 外部规格说明 系统设计 程序结构设计 模块接口 规格说明 目标 该软件产品要实现的目标。（非常笼统） 该软件产品要实现的具体目标。（相对于需求 更为具体，对软件的能力、容量、强度、易用 性等进行说明） 从用户角度对程序行为的精确描述，为后续设 计阶段提供输入。（有明确的输入输出规范） 越来越明确、详细的规定了程序是如何建立 起来的。 这两个环节基本上 都是从用户方沟通 的一手材料，并不 精确但价值非凡。 第6章 更高级别的测试 软件产品开发周期的模型 p要预

3、防和识别这些错误，可以 n使软件开发过程更精密。 n在每个阶段结束时可以引入一个独立的验 证过程。 n对不同的开发阶段采用不同的测试方法进 行验证（不同的测试过程针对一类特定的 错误）。 第6章 更高级别的测试 验证 验证 验证 验证 验证 验证 验证 验收测试 系统测试 功能测试 集成测试 模块测试 安装测试 最终用户 需求 代码 外部规格说明 系统设计 程序结构设计 模块接口 规格说明 目标 第6章 更高级别的测试 6.1 功能测试 p功能测试是一个试图发现程序与其外部规格说明 之间存在不一致的过程。 n除了很小的程序，功能测试通常是黑盒测试 n在进行功能测试时，需要对规格说明进行分析以获

4、取测 试用例集。 l等价类划分、边界值分析、判定表、因果图、错误猜测等方法尤 其适合功能测试。 l要应用测试的原则，如1.发现错误越多的功能，可能存在错误的 可能性就越大；2.对测试用例的预期结果应该有明确定义；3.要 对无效输入给予重视。 6.2 系统测试 p系统测试的目的是将系统或程序与其初始目标进行 比较，这意味着 n 系统测试并不局限于系统，系统测试是一个试图说明程序作 为一个整体是如何不满足其目标的过程。 n 如果产品没有一组书面的、可度量的目标，系统测试也无法 进行。 p系统测试并非是测试整个系统的功能（功能测试） n 系统测试用例不能以规格说明为基础，也不能以目标文档作 为基础（

5、其中不包含对程序外部接口的准确描述）。 n 可以分析目标文档来设计系统测试，而分析用户文档来阐明 测试用例。 p 如DISPLAY命令的目标如下： n 该命令用来从终端查看主存储空间中的内容（总目标），其 语法应与所有其他系统命令的语法相一致（能力）。用户可 以通过一个地址范围或者一地址加上一数值来定义空间范围 （能力） 。该命令操作符应具有合理的默认值（易用性）。 命令的输出可以分多行显示多个字（十六进制形式），字与 字之间以空格相隔。每一行须包含该行第一个字的地址（能 力）。该命令是条“不太重要的”指令，意味着其在合理的 系统负载下，应在两秒之内开始显示输出，输出各行之间不 应有可觉察的延

6、时（性能）。命令处理器中发生的编程错误 在最坏情况下可能导致该命令失效，而系统以及用户交互则 不应受到影响（强度） 。系统投入使用后，命令处理器中 包含的用户发现的错误不应超过一个（可靠性）。 6.2 系统测试 目标文档实例 p系统测试没有特定的技术和方法，但可以根据不同 类型的测试来考虑测试用例的设计，包括： n 能力测试，容量测试，强度测试，易用性测试，安全性测试， 性能测试，存储测试，配置测试，兼容性/配置/转换测试， 安装测试，可靠性测试，可恢复性测试，适用性测试，文档 测试，过程测试 p不是所有这些类型都适用于任何程序/软件，但为了 避免有所遗漏，设计测试用例时应该考虑所有类型。 6

7、.2 系统测试 系统测试的类型 p能力测试 n 判断目标文档提及的每一项能力（以区别功能测试中的功 能）是否都确实已经实现。 n 通常是通过人工检查目标文档中定义了“要做什么” 。 p容量测试 n 是程序经受大容量数据的检验，目的是证明程序不能处理目 标文档中规定的数据容量。 n 容量测试需要大量的资源，不可进行过多。 n 如使操作系统的作业队列达到饱和容量。 6.2 系统测试 系统测试的类型 p强度测试 n 使程序承受高负载或强度的检验。所谓高强度是指在很短的 时间间隔内达到的数据或操作的数量峰值。（要与容量测试 相区分） n 强度测试涉及时间因素，适用于在可变负载下运行的程序以 及交互式程

8、序、实时程序和过程控制程序。基于Web的应用 程序也是最常接受强度测试的软件之一。 n 如，1.在很短的时间内是操作系统的作业队列达到峰值; 2.web应用程序要处理一定容量的并发用户。 注：强度测试是对强度的界定很重要。 6.2 系统测试 系统测试的类型 p易用性测试 n每个用户界面是否都根据用户的智力、教育程度和环境 要求进行了调整？ n程序的输出是否有意义、不模糊且无计算机杂乱信息？ n错误诊断信息是否直接，非计算机专业用户是否能够理 解（这要求对错误进行精确的预测和详细的分类）？ n整体的用户界面是否在语法、惯例、语义、格式、风格 和缩写等方面展现出了相当程度的完整性、一致性和同 一性

9、？ n系统是否包含过多或不太可能用到的选项？ n对于所有输入，系统是否返回了即时确认信息？ n程序是否易于使用？如区分大小写的要求用户是否清楚， 不同层次菜单之间的浏览是否容易等。 6.2 系统测试 系统测试的类型 p安全性测试 n 设计测试用例来突破程序安全检查。 l例如可以设计测试用例来规避操作系统的内存保护机制、 破坏数据库管理系统的数据安全机制等。 n 常用的测试用例设计方法是研究类似系统中已知的安全问题，然 后生成测试用例，暴露被测系统中的类似问题 n 基于Web的应用程序常常比绝大多数程序所需的安全测试级别更 高，对于电子商务网站尤其如此。 p性能测试 n 很多软件都有特定的性能或

10、效率目标，这些特性描述为在特定负 载和配置环境下程序的响应时间和吞吐率。应设计测试用例来说 明程序不能满足其性能目标。 6.2 系统测试 系统测试的类型 p存储测试 n 软件偶尔会有存储目标，例如描述程序使用的内存和 辅存的容量以及临时文件或移出文件的大小。应设计 测试用例来证明这些存储目标没有得到满足。 p配置测试 n 很多软件都支持多种硬件配置，可以运行在多种操作 系统下，使用多种web浏览器。通常可能的配置数量 非常之大，以至于无法全面测试，但应该尽可能测试 各种配置。 6.2 系统测试 系统测试的类型 p兼容性/配置/转换测试 n 很多软件不是全新的，而是为了替换某些已有的系统。这样

11、的软件往往涉及与已有系统的兼容以及从已有系统的转换过 程，如升级数据库管理系统。 p安装测试 n 有些软件的安装过程非常复杂，测试安装过程是系统测试的 一个重要部分。 p可靠性测试 n 所有测试都是为了提高软件的可靠性，但如果软件的目标中 包含了对可靠性的特别描述，就必须设计专门的可靠性测试 用例。 p适用性测试 n 对于软件的适用性和可维护性目标也必须测试。 6.2 系统测试 系统测试的类型 p可恢复性测试 n 诸如OS、DBMS等软件通常都有可恢复性目标，说明系统如何从硬 件失败和数据错误中恢复过来。系统测试的一个目标是证明这些恢 复机制不能正确发挥作用。 n 可以故意将程序错误植入个系统

12、中，判断系统是否可以从中恢复。 n 这些系统的设计目标之一是平均恢复时间（MTTR）最小，测试目 标之一就是证明系统不能满足MTTR的要求。 p文档测试 n 系统测试也需要检查用户文档的正确性和清晰性。 p过程测试 n 很多软件系统不是完全自动化的，其中包括了很多人员操作过程。 在系统测试中，必须对所有已规定的人工过程，如系统操作员、最 终用户、数据库管理员的操作过程进行测试。 6.2 系统测试 系统测试的类型 p系统测试的执行 n 系统测试执行的一个最关键的考虑是决定由谁来执行测试 n 不能由程序员来进行系统测试 l执行系统测试的人思考问题的方式必须与最终用户相同，必 须充分了解最终用户的态

13、度和使用环境以及程序的使用方式。 l理想的人员组成：专业的系统测试专家、最终用户代表、人 类工程学工程师、程序的主要分析人员或设计人员。 n 在所有的测试阶段之中，这时唯一一个明确地不能由负责 该程序开发的机构来执行的测试 l软件开发机构的心理有悖于测试活动的目标 l至少应该由很少受开发机构左右的独立人群来执行 l独立的测试机构 6.2 系统测试 系统测试的类型 6.3 验收测试 p验收测试 n是将程序与其最初的需求及最终用户当前的需要进行比 较的过程 n通常是由程序的客户或最终用户来进行，一般不认为是 软件开发机构的职责 n最好的方法是设计测试用例，尽力证明程序没有满足合 同要求；假如这些测

14、试用例都通过了，就可以接受该程 序。 6.4 安装测试 p安装测试 l安装测试不同于其他测试，它的目的不是发现软件的错误，而是 为了发现在安装过程中出现的错误，安装过程中会发生很多事件， 例如用户必须选择大量的选项、必须分配并加载文件和库、必须 进行有效的硬件配置、可能要求网络连接其他软件，等等 l安装测试应该由生成软件系统的机构设计，作为软件的一部分来 发布，在系统测试完成之后进行。 l测试用例要检查已选的选项集合互不冲突、系统的所有部件都存 在、所有文件已创建并包含必需内容、硬件配置妥当等等。 6.5 测试的计划与控制 p 计划是管理测试过程中至关重要的一环，良好的测试计划中应包括： n

15、目标：定义每个测试阶段的目标 n 结束准则：制订准则规定每个测试阶段何时可以结束 n 进度：每个阶段的时间表，何时设计、编写和执行测试用例 n 责任：每个阶段应确定由谁负责设计、编写和执行测试用例，谁负责修改发现 的软件错误 n 测试用例库及标准 n 工具：需要使用的测试工具，何时、如何使用 n 计算机时间：每个测试阶段所需的计算机时间 n 硬件配置：描述需要的特别的硬件配置或设备 n 集成：定义程序如何组装在一起，如自顶向下的增量测试 n 跟踪步骤、调试步骤 n 回归测试：对程序作了功能改进或修改之后进行回归测试，目的是判断程序的 改动是否引起了程序其他方面的退步。通常是重新执行测试用例集的

16、某个子集。 6.6 测试结束准则 p 典型的无用准则 n 用完了安排的测试时间后 n 执行完了所有测试用例都未发现错误 p 较有用的3类准则 1. 根据特定的测试用例技术来定义准则 l例如规定通过了某些来源的所有测试用例后结束 2. 以确切的数量来描述结束测试的条件 l需要预测一些数量：程序错误总数，可能发现的错误比 例，错误产生和被发现的阶段 l经验数据 3. 在测试过程中记录每单位时间内发现的错误数量，通过检查 统计曲线的形状，决定是继续该阶段的测试还是结束它并开 始下个测试阶段 6.6 测试结束准则 p 最佳的测试结束准则是上述3类的组合 n模块测试：最佳的准则是1，应该要求使用一系列 具体的测试用例设计方法。 n功能测试和系统测试：结