一、测试级别

软件系统通常是由许多子系统组成的，而这些子系统又是由多个组件组成的，通常被称为单元或模块。由此产生的系统结构也被称为系统的 "软件结构 "或 “架构”。设计能完美支持系统要求的架构是软件开发过程中的关键部分。

在测试过程中，系统必须在其结构的每个层面上进行检查和测试，从最基本的组件一直到完整的集成系统。与架构的某一层次有关的测试活动被称为测试 “层次”，每个测试层次都是测试过程的一个实例。
以下各节将详细说明各个测试层次在不同的测试对象、测试目标、测试技术和责任/角色方面的区别。

二、组件测试

• 术语

组件测试包括系统地检查系统结构中的最低层组件。根据用于创建这些组件的编程语言，这些组件有不同的名称，如 “单元”、"模块 "或（在面向对象编程的情况下）“类”。因此，相应的测试被称为 “模块测试”、"单元测试 "或 “类测试”。
组件和组件测试

无论使用哪种编程语言，所产生的软件构件是 “组件”，相应的测试被称为 “组件测试”。

• 测试基础

组件的具体要求和组件的设计（即规格）要被参考以形成测试基础。为了设计白盒测试或评估代码覆盖率，你必须分析组件的源代码并将其作为额外的测试基础。然而，为了判断组件对测试用例的反应是否正确，你必须参考设计或需求文档。

• 测试对象

如上所述，模块、单元或类是典型的测试对象。然而，像shell脚本、数据库脚本、数据转换和迁移程序、数据库内容和配置文件也都可以成为测试对象。

• 组件测试验证了组件的内部功能

组件测试通常只测试与系统其他部分隔离的组件。这种隔离的作用是在测试中排除外部的影响。它还简化了测试用例的设计和自动化，因为它们的范围很窄。

组件可以由多个构建块组成。重要的一点是，组件测试只需要检查有关组件的内部功能，而不是与外部组件的交互。后者是集成测试的主题。组件测试对象通常是 “从程序员的硬盘中获得的”，这使得这一层次的测试与开发工作紧密相连。因此，组件测试人员需要足够的编程技能来正确地完成他们的工作。

案例研究： 测试calculate_price类

经销商折扣是从清单价格中减去的，而配件折扣只适用于额外的东西。这两种折扣不能同时使用。最后的价格是用以下方法计算的：

为了测试这个计算，测试人员通过调用calculate_price()方法和提供适当的测试数据来使用相应的类接口。然后，测试人员记录组件对这个调用的反应–即读取并记录方法调用所返回的值。

这段代码是有错误的：计算≥5的折扣的代码永远无法到达。这个编码错误可以作为例子来解释第五章详述的白盒分析。

要做到这一点，你需要 “测试驱动”。测试驱动是一个独立的程序，它进行所需的接口调用，并记录测试对象的反应（也见第5章）。

对于calculate_price()测试对象，简单的测试驱动可以是这样的：

我们例子中的测试驱动非常简单，例如，可以扩展到记录测试数据和带有时间戳的结果，或者从外部数据表中输入测试数据。

三、开发者测试

要写测试驱动，你需要编程技巧。你还必须研究和理解测试对象的代码（或者至少是它的接口的代码），以便编程正确调用测试对象的测试驱动。换句话说，你必须掌握相关的编程语言，你需要获得适当的编程工具。这就是为什么组件测试通常是由组件的开发者自己进行的。这样的测试通常被称为 “开发者测试”，尽管 "组件测试 "才是真正的意思。开发者测试自己的代码的缺点将在第2.4节讨论。

3.1测试与调试

组件测试经常与调试相混淆。然而，调试涉及消除缺陷，而测试涉及系统地检查系统的故障。

使用单元测试框架（比如pytest、unittest、junit等）大大减少了测试驱动编程的工作量，并在整个项目中创建一致的组件测试架构。使用标准化的测试驱动也使团队中不熟悉各个组件或测试环境的其他成员更容易进行组件测试。这些类型的测试驱动可以通过命令行界面控制，并提供处理测试数据的机制，以及记录和评估测试结果。因为所有的测试数据和日志都是相同的结构，所以有可能在多个（或所有）被测组件中评估结果。

3.2 组件测试目标

组件测试级别的特点是不仅有测试对象的类型和测试环境，而且有非常具体的测试目标。

3.3 测试功能

组件测试最重要的任务是检查测试对象是否完全正确地实现了其规范中定义的功能（这种测试也被称为 "功能测试 "或 “功能性测试”）。在这种情况下，功能等同于测试对象的输入/输出行为。为了检查实现的完整性和正确性，该组件要接受一系列的测试案例，每个案例都涵盖了输入和输出数据的特定组合。

案例研究： 测试VSR-II的价格计算

这种测试输入/输出数据的组合在上例中的测试案例中得到了很好的说明。每个测试用例都输入了特定的价格和特定数量的额外费用。然后测试用例检查测试对象是否计算出正确的总价格。
例如，测试用例#2检查 “五个或更多额外项目的折扣”。当测试用例#2被执行时，测试对象输出一个不正确的总价格。测试用例#2产生了一个故障，表明测试对象没有满足其对这个输入数据组合的指定要求。
组件测试揭示的典型故障是错误的计算或缺失（或选择不当）的程序路径（例如，被忽略或错误解释的特殊情况）。

四、稳健性测试

软件组件必须与多个相邻的组件进行交互和交换数据，不能保证该组件不会被错误地访问和使用（即违背其规范）。在这种情况下，被错误处理的组件不应该简单地停止工作并使系统崩溃，而是应该做出 "合理 "和稳健的反应。因此，测试稳健性是组件测试的另一个重要方面。这个过程与普通的功能测试非常相似，但是用无效的输入数据而不是有效的数据为被测组件服务。这样的测试案例也被称为 “负面测试”，并假设组件将产生合适的异常处理作为输出。如果没有内置足够的异常处理，组件可能会产生运行时错误，如除以零或空指针访问，导致系统崩溃。

案例研究： 负面测试

对于我们之前使用的价格计算的例子，负测试将涉及到用负的输入值或错误的数据类型（例如，char而不是int）7进行测试：

// testcase 20
price = calculate_price(-1000.00,0.00,0.00,0,0);
test_ok = test_ok && (ERR_CODE == INVALID_PRICE);...// testcase 30
price = calculate_price("abc",0.00,0.00,0,0);
test_ok = test_ok && (ERR_CODE == INVALID_ARGUMENT);

各种有趣的事情出现了：

除了功能和健壮性，组件测试还可以用来检查组件的其他属性，这些属性会影响其质量，并且只能在更高的测试级别上使用大量的额外工作来测试（如果有的话）。例如，非功能属性 "效率 "和 "可维护性 "。

4.1 效率的测试

效率属性表明一个组件与可用的计算资源的交互是多么的经济。这包括诸如内存使用、处理器使用、或执行功能或算法所需的时间等方面。与其他大多数测试目标不同，测试对象的效率可以使用合适的测试标准进行精确评估，如内存的千字节或以毫秒计算的响应时间。效率测试很少对系统中的所有组件进行测试。它通常只限于那些在需求目录或组件规范中定义了某些效率要求的组件。

例如，如果在嵌入式系统中可用的硬件资源有限，或者对于必须保证预定的响应时间限制的实时系统。

4.2 测试可维护性

可维护性包含了所有影响增强或扩展程序的容易程度（或困难程度）的属性。这里的关键因素是开发人员（团队）需要花费多少精力来掌握现有的程序和它的背景。这对于需要修改他多年前编程的系统的开发者和一个从同事那里接手代码的人来说，同样有效。
需要测试的可维护性的主要方面是代码结构、模块化、代码注释、文档的可理解性和最新性等等。

案例分析： 难以维护的代码

示例的calculate_price()代码包含许多可维护性问题。例如，完全没有代码注释，数字常量没有被声明，而是硬编码的。例如，如果需要修改这样的常量，就不清楚在系统中是否需要修改，以及在哪里需要修改，这就迫使开发者要花大力气去弄清楚。

像可维护性这样的属性当然不能用动态测试来检查（见第五章）。相反，你需要用静态测试和审查会议来分析系统的规范和代码库（见第4.3节）。然而，由于你要检查单个组件的属性，这种分析必须在组件测试的范围内进行。

4.3 测试策略

如前所述，组件测试是高度面向开发的。测试人员通常可以访问源代码，支持组件测试中面向白盒的测试技术。在这里，测试人员可以使用组件的内部结构、方法和变量的现有知识来设计测试用例（见5.2节）。

4.4 白盒测试

在测试执行过程中，源代码的可用性也是一个优势，因为你可以使用适当的调试工具（见第7.1.4节）来观察测试过程中变量的行为，看看组件的功能是否正常。调试器还可以让你操作组件的内部状态，所以在测试健壮性时，你可以故意启动异常。

calculate_price()代码包括以下值得测试的语句：

满足条件（discount > addon_discount）的额外测试案例很容易从代码中推导出来。但是价格计算规范没有包含相关的信息，相应的功能也不是需求的一部分。代码审查可以发现这样的缺陷，使你能够检查代码是否正确，规范是否需要改变，或者是否需要修改代码以适应规范。

然而，在许多实际情况下，组件测试 "只 "作为黑盒测试进行–换句话说，测试用例不是基于组件的内部结构。软件系统通常由成百上千个单独的构件组成，所以分析代码只对选定的组件真正实用。

在集成过程中，单个组件越来越多地被组合成更大的单元。这些集成单元可能已经大到无法彻底检查其代码。组件测试是在单个组件上进行还是在更大的单元（由多个组件组成）上进行，这是一个重要的决定，必须作为集成和测试计划过程的一部分。