系统架构设计师——系统测试

测试方法

动态测试

白盒测试

白盒测试是一种软件测试方法，它关注程序的内部逻辑和代码结构。与黑盒测试不同，黑盒测试主要关注软件的功能和输入输出关系，而不考虑内部实现。白盒测试则需要测试者具备编程技能，以便于理解代码逻辑并设计相应的测试用例。

从测试覆盖标准来看，白盒测试通常要求测试用例覆盖代码中的每一条路径、每一个判定以及每一个条件。这些覆盖标准从低到高分别是语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。

1. 语句覆盖
   • 定义：要求每个可执行语句至少被执行一次。
   • 优点：简单直观，容易实施，可以发现语法错误或者不可达代码。
   • 缺点：无法确保判断逻辑的正确性，可能会遗漏一些逻辑错误。
2. 判定覆盖
   • 定义：要求每个判定的真假分支至少被执行一次。
   • 优点：比语句覆盖严格，可以发现判定逻辑的错误。
   • 缺点：如果判定由多个条件组成，单个条件的取值可能被忽略。
3. 条件覆盖
   • 定义：要求每个判定中的每个条件（布尔表达式）都取到真和假的值。
   • 优点：比判定覆盖更细致，能够检查每个条件的取值情况。
   • 缺点：并不保证判定的最终结果，可能仍然遗漏某些逻辑错误。
4. 判定/条件覆盖
   • 定义：同时满足判定覆盖和条件覆盖的要求，即每个判定的所有结果和每个条件的所有结果都被测试。
   • 优点：综合了判定覆盖和条件覆盖的优点，提供更高的测试覆盖率。
   • 缺点：工作量较大，需要更多的测试用例设计和执行。
5. 条件组合覆盖
   • 定义：要求每个判定中所有条件的可能组合至少出现一次。
   • 优点：能发现复杂判定逻辑中的错误，提供更全面的测试。
   • 缺点：测试用例数量可能非常多，工作量巨大。
6. 路径覆盖
   • 定义：要求程序中每一条可能的路径都被执行至少一次。
   • 优点：最全面的覆盖标准，能够发现所有潜在的错误路径。
   • 缺点：对于复杂程序，路径数量可能非常多，实现困难且不实际。

黑盒测试

黑盒测试也称为功能测试，主要用于集成测试、确认测试和系统测试阶段。黑盒测试将软件看作是一个不透明的黑盒，完全不考虑（或不了解）程序的内部结构和处理算法，而只检查软件功能是否能按照SRS的要求正常使用，软件是否能适当地接收输入数据并产生正确的输出信息，软件运行过程中能否保持外部信息（例如，文件和数据库等）的完整性等。黑盒测试主要有边界值分析、因果图、等价类划分法、正交实验法等方法。

1. 等价类划分

   • 定义：等价类划分是将输入域分为多个等价类，每个等价类代表一组具有相同特征的有效或无效输入。
   • 优点：通过选择代表性的输入数据进行测试，可以减少测试用例的数量，提高测试效率。
   • 缺点：可能无法发现所有潜在的错误，因为每个等价类中只选取了部分代表性数据进行测试。

2. 边界值分析

   • 定义：边界值分析主要关注输入域的边界情况，包括最小值、最大值以及中间值。
   • 优点：经验表明，软件在处理边界情况时最容易出错，因此边界值分析能够有效发现潜在问题。
   • 缺点：可能需要与其他测试方法结合使用，以确保全面覆盖。

3. 因果图

   • 定义：因果图是一种图形化的测试模型，用于描述输入与输出之间的因果关系。
   • 优点：通过分析因果图可以生成较全面的测试用例，确保多种条件组合的覆盖。
   • 缺点：绘制因果图和分析需要一定的经验和技能，可能会增加测试设计的复杂度。

4. 正交实验法

   • 定义：正交实验法是通过构造正交表来设计测试用例，以确保各种因素的组合被均衡地测试。
   • 优点：可以用较少的测试用例覆盖较多的测试组合，提高测试效率。
   • 缺点：对于复杂的系统，构造正交表可能较为困难，需要专业的知识和技能。

静态测试

静态测试是一种测试方法，被测程序不在机器上运行，采用人工检测和计算机辅助静态分析的手段对程序进行测试。静态测试包括文档测试和代码测试。

• 文档测试：检查文档的完整性、准确性和一致性。
• 代码测试：检查代码的正确性、可读性和可维护性。

代码测试的方法包括：

• 桌前检查：程序员自己检查代码。
• 代码审查：由审查小组对代码进行检查。
• 代码走查：由审查小组对代码进行逐行检查。

静态测试的内容还包括：

• 控制流分析：使用控制流程图检查被测程序是否存在没有使用的语句或子程序。
• 数据流分析：使用控制流程图分析数据各种异常情况，包括数据初始化、赋值或引用过程中的异常。
• 接口分析：模块之间接口的一致性分析、模块与外部数据库及其他软件配置项之间的一致性分析、子程序和函数之间的接口一致性分析等。
• 表达式分析：检查程序代码中的表达式错误，如括号不配对、数组引用越界、除数为零等。

测试类型

单元测试

单元测试是软件开发过程中的一个关键步骤，它专注于对软件中最小的可测试单元（如函数、方法或类）进行正确性检验。单元测试通常由开发人员编写，可以及早发现代码中的错误，提高软件质量。

自顶向下式

自顶向下的单元测试是一种测试策略，从软件结构的顶层开始，并在逐步向下的层次中进行。在这种方法中，高层的函数或模块首先被测试，而这些函数可能依赖于尚未开发的底层模块。因此，测试时通常需要使用桩（stubs）来模拟这些底层模块的行为。

优点

• 允许开发者从用户的角度开始测试，有助于确保核心功能的正确性。
• 可以早期发现设计上的问题，因为从顶层开始测试可以帮助揭示架构问题。

缺点

• 需要创建大量的桩，这可能导致额外的开发和维护工作。
• 由于底层模块还未完全实现，可能无法完全测试高层模块的所有功能。

自底向上式

与自顶向下相反，自底向上的单元测试从软件结构的底层开始，并逐步向上进行。在这种方法中，底层的函数或模块首先被测试，这些测试通常不需要依赖其他未测试的模块。

优点

• 减少了对桩的依赖，因为底层模块不依赖于尚未测试的高层模块。
• 可以迅速发现低层模块中的错误，为上层模块的测试提供坚实的基础。

缺点

• 可能较难从整体上验证系统的行为，因为是从细节开始的。
• 需要等待底层模块测试通过后才能进行上层模块的测试，可能导致测试进度延迟。

孤立测试

孤立测试是指对每个单元进行独立于其他单元的测试，不考虑其与其他单元的交互。这种测试方法可以非常详细地检查单个单元的功能和边界条件。

优点

• 可以详尽地测试每个单元的所有功能和边界条件。
• 由于测试环境较为简单，容易定位错误。

缺点

• 可能忽略了单元间的交互影响，无法发现集成问题。
• 过分关注单个单元可能导致忽视整体行为。

综合测试

综合测试（也称为集成测试）发生在单元测试之后，其主要目的是验证多个单元（模块、函数、类等）在集成后的行为是否符合预期。在现实世界中，单个单元在与其他单元交互时可能会出现问题，综合测试就是用来发现这类问题的。

集成测试

集成测试主要关注多个单元（模块、函数、类等）在集成后的行为是否符合预期。根据不同的测试策略，集成测试可以细分为多种类型。

基于分解的集成策略

基于分解的策略侧重于如何将软件模块逐步组合起来进行测试。

非渐增式

• 定义：也称为“大爆炸”集成测试，所有模块一次性集成到一起，然后进行测试。
• 优点：看起来速度快，因为不需要多次集成。
• 缺点：风险高，一旦出现错误，很难定位问题所在。

渐增式

• 定义：模块逐步集成，并边集成边测试。
• 优点：更容易定位问题，风险管理更好。
• 缺点：总体耗时可能较长。

####### 自底向上集成

• 策略：从最底层的模块开始集成，逐步向上。
• 优点：底层模块先验证，提供稳定基础。
• 缺点：高层模块的依赖需要桩，测试高层功能可能要等底层全部完成。

####### 自顶向下集成

• 策略：从最高层模块开始，使用桩来模拟下层模块。
• 优点：可以尽早发现高层设计问题。
• 缺点：需要大量的桩，且底层模块测试可能不充分。

####### 混合的增量式（三明治）式

• 策略：结合自顶向下和自底向上的策略，同时从两端开始测试。
• 优点：平衡了两者的优点，减少了桩和驱动的使用。
• 缺点：管理相对复杂，需要良好的协调。

基于功能的集成策略

• 策略：根据业务功能进行集成，优先测试关键功能。
• 优点：可以快速验证核心功能，适合敏捷开发。
• 缺点：非核心模块的测试可能被延迟。

基于调用图的集成策略

• 策略：通过分析模块之间的调用关系，确定集成顺序。
• 优点：能够系统地识别模块间依赖，有助于优化集成顺序。
• 缺点：调用图的构建和维护可能较为复杂。

配置项测试

配置项测试（Configuration Item Testing, CIT）是一种特定的软件测试，主要针对那些被定义为配置项的软件组件或特性。配置项是指软件系统中任何可独立交付、测试和维护的部分。

目的

• 确保每个配置项在特定的配置环境下按预期工作。
• 验证配置项之间的兼容性和交互性。

特点

• 关注单个配置项在各种环境配置下的表现。
• 有助于识别特定配置导致的缺陷。

系统测试

系统测试是测试整个软件系统的过程，包括所有集成的模块、子系统和软硬件环境。它验证完整的系统是否满足规定的要求。

目的

• 验证系统作为一个整体是否按照规格书工作。
• 检查系统的功能、性能、可靠性等是否符合需求。

特点

• 范围广，覆盖所有功能和性能方面。
• 可能包括压力测试、性能测试、安全测试等。

验收测试

验收测试是由用户或客户进行的测试，目的是验证软件是否符合他们的需求和期望。它是软件交付之前的最后一道测试。

目的

• 验证软件是否满足业务需求和用户期望。
• 确保软件在实际环境中可以正常工作。

特点

• 通常基于用户场景和用例进行。
• 可能包括 alpha 测试（内部用户）和 beta 测试（外部用户）。

回归测试

回归测试是在软件修改后进行的测试，以确保这些修改没有引入新的错误或导致旧功能的失效。

目的

• 验证代码更改后，原有功能是否仍然正常工作。
• 确保新的或修改过的功能按预期工作，并且没有破坏现有功能。

特点

• 可以针对所有受影响的模块进行。
• 重点关注可能受影响的模块及其依赖。