软件测试技术（下） – 测试类型

软件测试技术主要分为两类：

静态测试技术：这些测试技术用于在不执行代码的情况下发现被测应用程序中的缺陷。静态测试的目的是在开发周期的早期阶段避免错误，从而降低修复成本。

动态测试技术：这些测试技术用于测试被测应用程序的动态行为，即通过执行代码库。动态测试的主要目的是使用动态输入来测试应用程序——其中一些输入可能根据需求允许（正向测试），而另一些则不允许（负向测试）。

静态测试技术

如前所述，静态测试技术是不需要执行代码库的测试技术。

静态测试技术主要分为两大类：

评审

评审范围从两名开发人员/测试人员之间就工件（代码/测试用例/测试数据）进行的纯粹非正式的同行评审，到由组织内部或外部的主持人主持的正式检查。

同行评审：非正式评审通常无需任何正式安排，在同行之间进行。例如，两名开发人员/测试人员互相评审彼此的工件，例如代码/测试用例。

走查：走查是指工作（代码、测试用例或受审文档）的作者向利益相关者展示其工作内容及其背后的逻辑，以达成共识或征求反馈意见。

技术评审：这是一种评审会议，仅关注受审文档的技术方面，以达成共识。它很少或根本不关注基于参考文档的缺陷识别。需要由架构师/首席设计师等技术专家进行评审。评审形式可以从非正式到完全正式。

检查：检查是最正式的评审类别。在检查之前，受审文档需要经过充分准备。检查会议中发现的缺陷会记录在缺陷管理工具中，并持续跟踪直至结束。避免了对缺陷的讨论，而是在单独的讨论阶段进行讨论，这使得检查成为一种非常有效的评审形式。

静态分析

静态分析是对需求/代码或设计的检查，以识别可能导致或不会导致故障的缺陷。例如，检查代码是否符合以下标准。不遵循标准就是一种缺陷，它可能会或不会导致故障。许多静态分析工具主要供开发人员在组件或集成测试之前或期间使用。即使是编译器也是一种静态分析工具，因为它可以指出语法的错误使用，并且它本身并不执行代码。代码结构包含几个方面——即数据流、控制流和数据结构。

数据流：它表示在给定程序中如何遵循数据路径——如何根据程序中的指令访问和修改数据。通过数据流分析，您可以识别诸如从未使用过的变量定义之类的缺陷。

控制流：它是程序指令执行的结构，例如条件、迭代或循环。控制流分析有助于识别诸如死代码之类的缺陷，即在任何条件下都不会使用的代码。

数据结构：它指的是与代码无关的数据组织方式。数据结构的复杂性会增加代码的复杂性。因此，它提供了有关如何在给定代码中测试控制流和数据流的信息。

动态测试技术

动态测试技术细分为三类：

基于结构的测试

这些也称为白盒技术。基于结构的测试技术专注于代码结构的工作原理并进行相应的测试。要理解基于结构的测试技术，我们首先需要了解代码覆盖率的概念。

代码覆盖率通常在组件测试和集成测试中进行。它确定结构测试技术在已编写的总代码中覆盖了哪些代码。代码覆盖率的一个缺点是，它不涵盖那些根本没有编写的代码（未满足需求）。市面上有一些工具可以帮助测量代码覆盖率。

测试代码覆盖率的方法有很多种：

语句覆盖率：执行的代码语句数/语句总数。例如，如果一个代码段有 10 行，而你设计的测试只覆盖了其中的 5 行，那么我们可以说该测试的语句覆盖率为 50%。

决策覆盖率：执行的决策结果数/决策总数例如，如果一个代码段包含 4 个判定（If 条件），而您的测试只执行了 1 个，则判定覆盖率为 25%。

 条件/多条件覆盖率：其目的是确定程序中每个逻辑条件的每个结果都已执行。

基于经验的技术：

这些技术是借助多年积累的经验来执行测试活动的技术。领域技能和背景是此类测试的主要因素。这些技术主要用于 UAT/业务用户测试。它们基于结构化技术（例如基于规范和基于结构的技术）并相互补充。以下是基于经验的技术类型：

错误猜测：它由在测试或被测应用程序方面拥有丰富经验的测试人员使用，因此他们可能知道系统可能存在哪些弱点。单独使用时，它并非一种有效的技术，但与结构化技术结合使用时会很有帮助。

探索性测试：这是一种动手测试，其目标是以最少的规划实现最大的执行覆盖率。测试设计和执行并行进行，无需记录测试设计步骤。此类测试的关键在于测试人员了解被测应用程序的优势和劣势。与错误猜测类似，它与其他正式技术配合使用，以发挥其作用。

基于规范的技术：

这包括功能性技术和非功能性技术（即质量特性）。这意味着根据业务的功能性或非功能性规范创建和执行测试。其重点是识别与给定规范相对应的缺陷。以下是基于规范的技术类型：

等价划分：通常结合使用，可应用于任何级别的测试。其理念是将输入数据范围划分为有效和无效部分，以使其中一个部分被视为“等价”。一旦确定了分区，我们只需使用给定分区中的任意值进行测试，并假设该分区中的所有值都具有相同的行为。例如，如果输入字段的取值范围是 1-999，那么 1-999 之间的值将产生相似的结果，我们无需对每个值都进行测试即可认为测试已完成。

边界值分析 (BVA)：此分析测试范围的边界——有效和无效。在上面的示例中，0、1、999 和 1000 是可以测试的边界。这种测试背后的原因是，代码中通常没有妥善处理边界。

决策表：这是一种测试输入组合的好方法。它也被称为因果表。用外行人的话来说，可以将适用于被测应用程序段的条件构建为一个表格，并针对每个条件确定结果，从而实现有效的测试。

需要注意的是，组合数量不能太多，否则表格会变得过大而无法有效执行。

以信用卡为例，如果信用评分和工资限额都满足，就会发放一张信用卡。以下决策表可以说明这一点：

基于用例的测试：这种技术可以帮助我们识别执行整个系统的测试用例——就像一个实际用户（Actor），逐个事务地执行。用例是描述Actor与系统之间交互的一系列步骤。它们始终以Actor的语言定义，而不是系统语言。这种测试在识别集成缺陷方面最有效。用例还定义了流程流的任何先决条件和后置条件。ATM示例可以通过用例进行测试：

状态转换测试：当被测应用程序或其一部分可以被视为有限状态机（FSM）时，可以使用状态转换测试。继续上面简化的ATM示例，我们可以说ATM流程具有有限状态，因此可以使用状态转换技术进行测试。需要考虑以下四个基本事项：

1.系统可以实现的状态

2.导致状态变化的事件

3.从一个状态到另一个状态的转换

4.状态变化的结果

可以创建状态事件对表来推导测试条件——包括正向和负向条件。

软件测试技术的优势

提高软件质量和可靠性——通过使用不同的测试技术，软件开发人员可以在开发过程的早期识别并修复缺陷，从而降低最终产品出现故障或意外行为的风险。

提升用户体验 —— 可用性测试等技术可以帮助识别可用性问题并提升整体用户体验。

增强信心 —— 通过测试软件，开发人员和利益相关者可以确信软件符合要求并按预期运行。

促进维护 —— 通过及早识别和修复缺陷，测试可以更轻松地维护和更新软件。

降低成本 —— 在开发过程的早期发现和修复缺陷比在生命周期的后期修复缺陷成本更低。

软件测试技术的劣势

耗时：测试可能需要大量时间，尤其是在进行全面测试的情况下。

资源密集型：测试需要专业技能和资源，成本可能很高。

覆盖范围有限：测试只能发现测试用例中存在的缺陷，而缺陷可能会被遗漏。

结果不可预测：测试结果并非总是可预测的，缺陷可能难以复制和修复。

交付延迟：如果测试时间超出预期或发现重大缺陷，测试可能会延迟软件的交付。

自动化测试的局限性：自动化测试工具可能存在局限性，例如难以测试软件的某些方面，并且可能需要大量的维护和更新。

结论

软件测试技术通过及早发现缺陷并改善用户体验来确保软件质量。它们增强了人们对软件满足需求的信心。然而，测试可能耗时、耗资源，并且覆盖范围可能有限。自动化测试有其局限性，并且需要维护。尽管存在这些挑战，但其优势（例如提高质量、降低成本和更易于维护）使得测试对于成功的软件开发至关重要。