代码覆盖率

代号覆盖率是测试中实际做出的陈述与理论上可能的陈述或可以做出的陈述的数量之比。 代码覆盖率作为质量保证和提高质量的指标起着重要作用，特别是在机械工程和软件技术中。

在实践中，代码覆盖率受各种标准的影响。 可以通过增加测量、样本和测试用例的数量来提高代码覆盖率。 然而，在实践中，代码覆盖率受到与每次测试相关的成本的限制。

根据测试的类型、工作量和收益，一些测试是随机进行的，其他测试是全面进行的。 对每个产品进行简单和自动的测试，因为它的成本只会稍微增加生产成本。 然而，车辆的碰撞测试当然仅使用随机样本进行，因为测试的产品随后将变得无法使用。

对于生产的 1000 辆汽车，这可能是例如意思是特别复杂的测试和碰撞测试只用单辆车进行，而不太复杂的测试则用更多甚至所有的车辆进行。

必要但复杂的测试的频率各不相同，因此代码覆盖率也不同。 如果测试主要或完全返回阳性结果，则其数量会减少。 如果测试得出阴性结果，则它会被更频繁地使用，直到生产的变化导致阳性结果显着增加，从而再次提高产品质量。

此类测试的成本效益计算是使用随机方法进行的。 如果例如，如果仅对 1000 辆汽车中的 5 辆进行测试以确定电动车窗是否正常工作，则可以使用随机方法计算基于测试结果的统计相关性和错误评估的概率。

对于软件工程中的代码覆盖率（英语测试覆盖率或代码覆盖率），随机几乎没有任何作用，因为计算机程序不是批量生产的单个产品，其中测试是用随机样本进行的。 相反，测试是根据规范（接口的属性）或要测试的软件单元的内部结构来定义的。

在软件工程中，代号覆盖率是针对软件的不同领域来确定的。 这些包括代码、数据或主题的覆盖范围。 为了达到尽可能高的代码覆盖率，必须根据要覆盖的区域编写不同的测试用例。 在软件测试中，不可能为所有面向控制流的测试过程指定代码覆盖率的度量，因为通常不可能确定实际问题的可能测试用例的数量。

主题的完整代码覆盖率是一个例外，因为可能的测试用例数量很快变得巨大（由于组合爆炸）。 一个接收两个 16 位值作为参数的简单函数的完整函数测试已经意味着 2 16 + 16 {\displaystyle 2^{16+16}} ，即大约 40 亿个测试用例，以便完全了解规范测试。 取而代之的是，人们将自己限制在一系列似乎对边缘情况有意义的测试中。 示例：有理数的根函数可以是例如与集合的所有元素 {-Double.MAX_VALUE; -1; -Double.MIN_VALUE； 0; 双.MIN_VALUE; 1; Double.MAX_VALUE} 待测试。 不同类型的有效参数通常被认为是合理的测试用例选择，用于适当的代码覆盖率，对于具有健壮性要求的组件附加限制元素（仅有效参数和仅无效参数）。 在发生错误时，将导致错误的参数包含在测试元素集中也被证明是成功的。

另一方面，代码的基本完整代码覆盖率通常是模块测试或组件测试的目标：对于“小”功能单元的高级代码覆盖率，所需的测试用例总数仅来自添加这些测试用例，而不是来自较大功能的组合。 但在这里，由于剩余的剩余风险（错误的意外“远距离影响”）以及成本效益原因，在大多数情况下也无法 xxx 实现此目标。

由于不检查任何内容的测试也可以实现高代码覆盖率，因此代码覆盖率对测试质量的意义有限。 为了保证测试的质量，通常使用突变测试。 为此，在要测试的 Code 自动构建错误或突变，然后运行测试。 如果之前有效的测试失败，则说明已检测到突变。 测试的质量可以从检测到的突变的比例中得出。 计算出的代码覆盖率因此决定了导致其中一个测试失败的突变的代码的覆盖率。

代码覆盖率也被各种国际标准用于建议或最低要求：

• IEEE 1008（“软件单元测试”）：xxx 的语句覆盖率是完成单元测试的要求，xxx 的分支覆盖率是针对包含关键代码或规范不足的模块。
• ISO 26262（“道路车辆 - 功能安全”）：根据关键程度，推荐或强烈推荐相应的代码覆盖率用于模块测试和集成测试。
• IEC 61508（“电气/电子/可编程电子安全相关系统的功能安全”）：建议或强烈建议 xxx 覆盖输入、语句、分支、条件，具体取决于安全要求级别，例如，在强烈推荐的输入、语句、分支和条件的最低级别 xxx 代码覆盖率。
• DO-178B（“机载系统和设备认证中的软件注意事项”）：要求 xxx 的代码覆盖率的声明、决策、更改决策取决于系统故障的影响。 例如，如果有乘客受伤的风险，则需要 xxx 代码覆盖率声明