标签：之间 img 计算 情况 www. 这一 可能性 语句 order
简介
代码覆盖率是衡量项目源代码被
测试的一种指标，部分的人认为这是一个非常有用的标准，越高的代码覆盖率可能就代表了更高更安全的质量保证；部分人对代码覆盖保持怀疑的态度，尽管承认覆盖率是测试质量的一个标准，但不一定相信已被覆盖的代码是经过良好的测试的；而也有一部分人认为代码覆盖率在项目中是没用甚至对项目是有害的，可能代码覆盖率较高，项目实际质量较差，给项目成员提供了一种错误的安全感。
尽管代码覆盖率分很多种（函数覆盖、语句覆盖、判断覆盖等），小编经过一段时间的实践，还是决定将重点放在语句覆盖，因为它相对简单、规则容易制定、结果方便可视化。本文将针对语句覆盖进行一些探索性的讨论。
代码覆盖率的度量
就小编接触过的大部分项目而言，大多采用了持续集成的形式，通过持续集成工具来进行自动化的构建（包括编译，发布，
自动化测试）来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。小编当前的项目也采用了Jenkins加覆盖率工具如Gcov（C++）、Emma/ JaCoCo（Java）和Coverage.py（
Python）来计算源码的测试覆盖率。
代码覆盖率的执行时机可分为两种：每日执行与每次构建执行，两种执行方式是独立且同时存在的。
对于每日执行的任务来说，可以配置一个定时任务，每次执行的范围是整个项目的所有源代码。通过工具执行生成的数据，可以建立dashboard展示每日/ 每周/ 每季度/ 每年/ 每种语言的代码覆盖率数据。同时也可以将dashboard实现项目与项目之间的比对，以评估比较各项目的质量情况。
对于每次构建执行的任务来说，可以将任务挂钩到code review流程中去，在每次触发构建时，会执行code review流程与代码覆盖率扫描，并将结果做可视化反馈给提交工程师与review的同学。如下图所示，可以针对code review设计一定的颜色，比如代码部分绿色为新增的代码，行数的橘粉色为已经被测试覆盖的代码，更方便review的同学观看。
根据小编的经验，在提交之前执行并反馈代码覆盖率扫描是一个很重要的时机，因为此时是提交的开发工程师最会对这项数据感兴趣的时机，其他时机研发会主动去提高覆盖率的可能性就会大大减少了。
代码覆盖率的结果展示
小编收集了3个项目中、5种语言、N次commit的代码覆盖率的数据，经过统计我们发现，大部分的项目覆盖率都在40%-70%之间，其中Python语言写的项目覆盖率最高、Javascript次之、最低的为C++。
经过分析，各类语言覆盖率存在巨大差异的可能性与各语言之间的结构性、范式和编写难易程度有关，同时不同的测量工具也可能影响了代码覆盖率数据的准确性。但请注意，以上数据不足以成为通用的项目代码覆盖率的指标，这些数据也仅仅只为以后提升代码覆盖率提供了一定的数据参考。
通过部署持续构建+代码覆盖率扫描系统，我们持续收到了来自配合研发团队的正面反馈，其中得到好评最多的就是在code review流程中加入覆盖率统计的功能，这一功能有利地提高了code review的关注点与效率，同时也间接地提升了代码被测覆盖率（review也算是代码覆盖率提升的方法）。
接下来的工作
经过一段时间的实践我们发现，代码覆盖率的统计问题主要是存在于代码覆盖率工具，因各工具的算法不一，因此很难制定一个统一的标准。我们进一步的工作可能就在于去啃这些工具的源码，通过实践-反馈-修正的循环不断提升覆盖率统计的准确性。
另一个问题也就是上文所说的覆盖率统计，大多都存在于单元与接口层面的测试，对于大型的集成测试、端对端测试、UI测试，这类的覆盖率是很难测量的，所以目前这类的测试还是依赖于对用例覆盖度的把控。
希望这篇
文章能对各位看官的项目起到一定作用，虽然各界对代码覆盖率的看法不一，但小编坚信，代码覆盖率的持续提升是对项目整体质量有较好的正向作用的。
如果有任何疑问，欢迎添加qq群测试入门大神 755431660 共同学习~
?
?
关于代码覆盖率的探索
标签：之间 img 计算 情况 www. 这一 可能性 语句 order
原文地址：https://www.cnblogs.com/testor/p/8979500.html
