第2.1节覆盖率简介 _用 igv 等工具描述端到端读数覆盖率-CSDN博客

本文链接：https://blog.csdn.net/lionking0318/article/details/146395808

代码覆盖率是衡量测试“触及”或“覆盖”了多少代码的一种指标。假设我们的软件产品包含了测试用例，并至少在每次发布之前都执行这些测试。在执行这些测试时，它们会对产品执行操作，从而让代码跑起来。很快，我们就意识到，如果跟踪哪些代码被测试用例执行了就可以度量执行了多少代码。我们把被执行的代码与产品中总代码量的比例叫作“代码覆盖率”。

这是一个非常简单的度量指标。如果我们有 100 行代码，但测试只执行了其中的 75 行，那么我们的代码覆盖率就是 75%。依此类推，你就可以得到绝大多数常见的代码覆盖率类型的定义。

2.1 .1 覆盖率类型

代码覆盖率：指测试用例执行时，实际被执行的代码行数占总代码行数的比例。这是评估测试质量的一个重要指标。
功能覆盖率：指测试用例覆盖了应用程序所有功能点的比例。这有助于确保每个功能都得到了充分的测试。
场景覆盖率：针对特定使用场景设计的测试用例覆盖度，比如网络不稳定情况下的应用表现、不同操作系统版本上的兼容性等。

常用的代码覆盖率

行覆盖率又称为语句覆盖率，指已经被执行到的语句占总可执行语句（不包含类似 C++的头文件声明、代码注释、空行等等）的百分比。这是最常用也是要求最低的覆盖率指标。实际项目中通常会结合判定覆盖率或者条件覆盖率一起使用。
分支覆盖又称判定覆盖，用以度量程序中每一个判定的分支是否都被测试到了，即代码中每个判断的取真分支和取假分支是否各被覆盖至少各一次。比如，对于 if(a>0 &&b>0)，就要求覆盖“a>0 && b>0”为 TURE 和 FALSE 各一次。
条件覆盖是指，判定中的每个条件的可能取值至少满足一次，度量判定中的每个条件的结果 TRUE 和 FALSE 是否都被测试到了。比如，对于 if(a>0 && b>0)，就要求“a>0”取 TRUE 和 FALSE 各一次，同时要求“b>0”取 TRUE 和 FALSE 各一次。

2.1.2 使用场景

新功能上线前的测试：确保新功能在正式发布前经过充分测试，减少线上故障的风险。
性能优化：通过增加对性能敏感部分的测试覆盖率，帮助开发者定位性能瓶颈。
回归测试：在每次迭代或修复bug之后，通过高覆盖率的测试确保已有功能不受影响。
跨平台测试：确保应用在不同的移动设备、操作系统版本上都能正常工作。

注意事项

平衡成本与效益：追求100%的覆盖率可能会导致成本过高，需要根据项目的实际情况合理设定目标。
关注关键路径：优先保证核心业务流程和高频使用的功能得到充分测试。
自动化与手动测试相结合：利用自动化工具提高效率的同时，也不忽视那些难以自动化的复杂场景。
持续集成：将覆盖率检查纳入CI/CD流程中，及时发现问题并快速修复。
定期回顾：随着项目的发展，原有的测试用例可能不再适用，定期回顾和更新测试计划是非常必要的。

2.1.3 常见覆盖率统计工具

emma
cobertura
jacoco

emma 与 cobertura 是为单元测试而设计的覆盖率统计，jacoco 与 emma 同属于一家公司，但是是为了更广泛的覆盖率统计而设计的工具。

通过对比和各方面的调研，选择比较通用化的Jacoco作为Android端的覆盖率采集工具，而iOS端的选择不多OC使用XcodeCoversage，Swift有其自带的覆盖率采集方案，后续我们将详细介绍。至于jacoco的一些概念，插桩原理，ASM等等，将不再介绍，网上相关的资料较多，防止影响我们专注于移动端覆盖率的测试。

总之，移动端覆盖率是衡量移动应用测试质量和稳定性的重要指标之一，但并不是唯一标准。合理的覆盖率策略能够有效提升产品质量，降低风险。覆盖率测试可以单独使用，也可以放到精准测试体系中使用，而且由于移动端分Android和iOS系统，开发语言又有JAVA，Kotlin, Object-C和Swift等，所以本章内容较多，将会分如下几节进行介绍：