覆盖标准(白盒、黑盒和灰盒)

覆盖标准(白盒、黑盒和灰盒)

覆盖标准Coverage Criteria
覆盖标准采用软件的抽象表示并将其划分为可测试的功能。
每个功能构成了测试需求的基础——需要由软件的测试套件进行测试的东西。
当测试套件的一个测试用例满足测试要求时，我们说测试要求被覆盖。测试套件覆盖的测试需求的百分比称为覆盖级别（或更简单地称为“覆盖率”）。
覆盖标准是一种分而治之的测试方法。

“抽象表示”指的是被测软件的高级概念模型或描述。 它是一种捕获软件功能的基本方面而不深入研究具体实现细节的表示。 抽象表示侧重于与测试目的相关的软件特性和行为，而不是特定的代码或设计。
使用抽象表示的目的是简化软件的复杂性，并为定义测试需求和识别可测试特性提供结构化框架。 它帮助测试人员和开发人员清楚地了解软件的功能并定义测试范围。

“可测试特性”是可以单独测试的软件的特定方面或功能。 这些特性源自软件的抽象表示。 它们代表需要通过测试验证的不同组件、行为或场景。
可测试的特性应该是明确定义和可测量的，这样它们才能被有效地测试。 它们可以是功能、模块、类、方法、输入、输出、用户交互或软件需要测试的任何其他方面。
通过识别抽象表示并将其划分为可测试的特性，覆盖标准提供了一种接近测试的系统方法。 测试需求源自这些特性，测试套件旨在满足这些需求。 测试套件的覆盖级别表示已覆盖的测试需求的百分比，提供对测试过程的彻底性的评估。

报表覆盖率Statement Coverage
一种非常简单的表示是程序语句组成一个软件。
每个功能都是一个程序语句。
每个测试要求都涉及执行（“覆盖”）每一行。
语句覆盖率是测试套件执行的代码行的百分比。

覆盖水平Coverage Level
JaCoCo 测量指令而不是语句，因为它计算 Java 字节码级别的覆盖率
覆盖率水平（或简称“覆盖率”）是测试的百分比
测试套件满足的要求。
例如执行了78%的语句，那么语句覆盖率为78%。

JaCoCo 类覆盖率报告JaCoCo Class Coverage Report
共有三种颜色：
绿色 = 由测试执行
黄色 = 测试执行的 if 或 for/while 语句的一个分支（真或假）
红色 = 测试未执行

批评和其他覆盖标准Criticisms and Other Coverage Criteria
语句是表示软件并将其划分（然后“征服”）以进行测试的一种非常简单的方法。
语句覆盖并不是一种“决定要测试什么”的有用方法，而是一种发现测试套件未涵盖的内容并决定是否需要更多测试用例的方法。
我们将在整个模块中满足不同的（并且可能更有用的）覆盖标准。

获得 100% 的覆盖率是否确保我们的程序没有错误？
不！ – 覆盖标准，例如语句覆盖，只是一个以系统的方式生成测试需求的方法。
例如，100% 的语句覆盖率可能会执行大部分缺陷，但是：
• 不保证缺陷会影响程序的状态
• 不保证感染会作为失败传播到程序的输出
• 不保证失败会被测试套件的断言捕获
更多细节: java 区分缺陷Defects/感染Infections/失败Failure

不可行的测试要求Infeasible Test Requirements
此外，一些测试要求可能是不可行的。
这意味着它们不可能被覆盖。
例如，一行无法执行的代码——即死代码。

该程序语句永远无法执行！ 它对语句覆盖形成了不可行的覆盖要求

回顾：重要术语Terminology
覆盖标准Coverage Criterion：一种将软件划分为一组测试要求以进行测试的方法。
测试要求Test Requirement:：测试套件必须按覆盖标准满足的软件功能。 请注意，测试需求与软件需求不同，也与测试用例不同。一个测试用例可以满足多个测试需求。
不可行的测试要求Infeasible Test Requirement:：不可能满足的测试要求。
覆盖率Coverage Level：执行的测试需求的百分比（覆盖）由测试套件。

白盒、黑盒和灰盒覆盖标准
对覆盖率标准进行分类的一种方法是区分测试需求是从代码中派生出来的，还是它没有参考它的编程方式。

白盒White Box：
全面了解内部代码结构。因此通常称为“代码覆盖率”标准。
黑盒子Black Box:
不了解内部代码结构。覆盖标准基于软件的需求、设计或抽象模型。
灰盒Grey Box:
内部代码结构的一些知识。覆盖标准基于被认为是“白盒”和“黑盒”的人工制品的混合

不同的标准，不同的缺陷
黑盒覆盖标准
由于不了解软件的内部工作原理，不太适合检测调试缺陷(defects of commission)。
最适合检测基于需求的遗漏缺陷(defects of omission)，软件的抽象模型。
白盒覆盖标准
最适合检测可以“看到”代码的调试缺陷(defects of commission)。
由于不了解软件需求，不太适合检测遗漏缺陷(defects of omission)。

在软件测试中，调试缺陷和遗漏缺陷是测试过程中可能遇到的两类问题：

1. 调试缺陷：当软件表现出不应该具有的行为或功能时，就会出现调试缺陷。 换句话说，它指的是软件包含不应该存在的东西或行为不正确的情况。 这些缺陷通常被认为是“错误”或“错误”，并可能导致意外结果或失败。 调试缺陷的示例包括逻辑错误、计算错误、崩溃或不正确的输出。

2. 遗漏缺陷：另一方面，当软件缺少或未能包含其应具有的功能或行为时，就会出现遗漏缺陷。 它指的是缺少某些东西或未正确执行的情况。 这些缺陷涉及缺少所需的特性、要求或预期的行为。 遗漏缺陷可能是由于不完整或不准确的规范、不充分的实施或开发过程中的疏忽造成的。 遗漏缺陷的示例包括功能缺失、错误处理不完整、安全漏洞或不符合要求。

这两种类型的缺陷、错误和遗漏都是不受欢迎的，它们会影响软件的质量和可靠性。 测试的目标是识别和报告这些缺陷，以便在将软件发布给最终用户之前解决和解决这些缺陷。