软件测试 - 测试方法

软件测试 - 核心方法

软件测试方法是用于设计和执行测试的策略或方法。它们根据测试人员对软件内部工作原理的了解程度进行大致分类。主要的方法包括 Black-Box Testing（黑盒测试）、White-Box Testing（白盒测试）和 Grey-Box Testing（灰盒测试）。

Black-Box Testing（黑盒测试）

Black-box testing，也称为行为测试或基于规格的测试，是一种测试人员对被测软件的内部结构、设计或代码一无所知的方法。测试完全基于软件的需求和规格说明书来设计。测试人员通过提供输入并检查输出来与应用程序的用户界面（UI）或 API 进行交互，将软件视为一个不透明的“黑盒”。

常见的 Black-Box Testing 技术包括：

• Equivalence Partitioning（等价类划分）: 将输入数据划分为若干个等价类，假设同一等价类中的所有输入都将被以类似的方式处理，并从中推导出测试用例。
• Boundary Value Analysis (BVA，边界值分析): 在输入域的边缘或边界处进行测试，因为错误更容易发生在这些地方。
• Decision Table Testing（决策表测试）: 用于处理输出依赖于多个输入条件的复杂逻辑。
• State Transition Testing（状态迁移测试）: 验证软件根据输入在不同状态之间迁移时的行为。
• Use Case Testing（用例测试）: 基于用户场景或用例设计测试。

优点	缺点
非常适合从用户的角度进行测试，以及用于更高级别的测试（System Testing，系统测试；Acceptance Testing，验收测试）。	测试覆盖率有限，因为未检查内部路径；某些代码段可能无法被测试到。
无需访问源代码或详细的实现知识。	如果测试人员对系统了解有限，可能会导致测试效率低下，产生冗余或不足的测试。
明确区分了测试人员和开发人员的视角，有助于公正的测试。	在没有清晰详细的规格说明书的情况下，难以设计测试用例。
可由编程知识较少的测试人员执行。	可能无法发现性能瓶颈或特定的算法错误。

White-Box Testing（白盒测试）

White-box testing，也称为结构测试、玻璃盒测试或透明盒测试，是一种测试人员对软件的内部结构、设计和代码有全面了解的方法。测试旨在验证代码内部的逻辑、路径、分支和数据流。这种方法通常需要编程技能并能访问源代码。

常见的 White-Box Testing 技术和覆盖率指标包括：

• Statement Coverage（语句覆盖）: 确保代码中的每一行都至少执行一次。
• Branch Coverage (Decision Coverage，分支覆盖/判定覆盖): 确保每个分支（例如，if-else 语句中的）都至少执行一次（包括 true 和 false 路径）。
• Path Coverage（路径覆盖）: 确保代码中的每一条可能的执行路径都被测试到。对于复杂的代码通常不切实际。
• Condition Coverage / Multiple Condition Coverage (MCC，条件覆盖 / 多条件覆盖): 测试决策点中所有条件的组合。
• Loop Testing（循环测试）: 专注于循环结构的有效性。

诸如静态代码分析器、调试器和代码覆盖率工具等工具常用于 white-box testing，这种测试通常由开发人员或专业的 SDET（测试开发工程师）在 Unit Testing（单元测试）和 Integration Testing（集成测试）级别进行。

优点	缺点
能够彻底测试内部逻辑和数据结构，有可能发现隐藏的错误。	需要具备编程知识的熟练测试人员，这会增加成本。
有助于优化代码并删除未使用的或无用代码。	可能非常耗时，特别是对于复杂的应用程序，难以实现高路径覆盖率。
能够精确地针对特定代码段进行测试，并实现可衡量的代码覆盖率。	可能无法发现与缺失功能或需求理解错误相关的错误，因为它侧重于已有的代码。
可以在开发周期的早期就开始，甚至在单元级别。	测试用例可能与实现细节紧密绑定，使其在代码变更时容易失效。

Grey-Box Testing（灰盒测试）

Grey-box testing 是 black-box testing 和 white-box testing 方法的结合。测试人员对应用程序的内部工作原理有部分了解，例如可以访问设计文档、数据库 schema（模式）或 API 规格说明，但不一定拥有完整的源代码。这种有限的知识使测试人员能够设计更智能的测试用例，针对特定区域或潜在的漏洞，同时仍然主要从黑盒的角度来处理系统。

这种方法特别适用于 integration testing、API testing，或测试理解数据流或数据库交互非常有益的系统。例如，grey-box 测试人员可以利用数据库表结构的知识来设计特定的输入数据，以测试与数据存储相关的边界条件。

优点	缺点
在 white-box testing 的深度和 black-box testing 的广度之间提供了平衡。	如果关键的内部细节未知，测试覆盖率与完整的 white-box testing 相比仍然可能有限。
测试人员可以根据他们部分了解的内部知识设计更有效的测试场景。	确定所需的“有限知识”的恰当程度可能具有挑战性。
更适合识别特定上下文的错误或接口问题。	如果开发人员已经执行了类似的 white-box tests，某些测试可能会冗余。
由于它允许更具针对性的测试，因此可能比纯粹的 black-box testing 更有效率。	需要具备比纯粹的 black-box testing 更多样化技能的测试人员。

测试方法比较

下表总结了这些测试方法之间的主要区别：

方面	Black-Box Testing（黑盒测试）	Grey-Box Testing（灰盒测试）	White-Box Testing（白盒测试）
对内部的了解	无需了解。	部分或有限了解。	需要全面了解。
也称为	行为测试、基于规格的测试、封闭盒测试。	半透明测试。	结构测试、玻璃盒测试、透明盒测试、基于代码的测试。
执行者	主要由测试人员、最终用户执行。	测试人员、开发人员、SDET。	主要由开发人员、SDET 执行。
测试设计依据	外部规格、需求、用户界面。	部分内部知识（例如，数据库 schema、API 文档、高层设计）。	源代码、内部逻辑、数据结构、详细设计。
关注点	根据需求验证系统行为。	利用部分内部洞察测试交互、接口和数据流。	验证内部代码路径、条件和结构。
适用于算法测试吗	通常不适用。	如果算法接口已知，部分适用。	非常适用。
方法	试错法，以及 BVA、EP 等系统化技术。	基于已知内部方面的目标性测试。	系统化的代码覆盖、路径分析。

在实践中，全面的测试策略通常会融合这些方法，并在软件开发生命周期的不同阶段和级别应用。