疫情当下，每天早上起来就会看看各种数字，有没有增多，有没有减少，再看看周边小区是不是有疫情，一波操作之后，才放心地吃早餐。数字就像一根定海神针，当你看见了，才会觉得安心。比如每当半夜惊醒的时候，发现自己还是十八岁，瞬间就安心了。覆盖率就是这种类型的数据。当你看见覆盖率上来了，你就会安心，就会有信心。最近一直在做 pipeline，覆盖率是其中重要的数据，所以想来聊聊覆盖率。都是自己的看法，得罪之处多多包涵。
很多人都说，我们项目没有覆盖率照样上线，我说啥测试都不做的项目直接怼上线大把大把。从狭义的角度来看，覆盖率可以不需要。但是它会以另外一种形式存在。比如，会有人问这个功能测完了吧？测试充分了吧？异常用例都跑了吧？这种不精准，含糊的，无法量化的覆盖率一直存在项目的过程中。所以就像我们回答是不是一定要有测试一样，可以没有测试人员，测试角色，但是测试无处不在。
当你无法量化的时候，你就在用你的人品和信誉做担保，而开发团队对你的信任也是基于你的信誉。可是在你还没有建立你的信誉的时候，你就必须拿出量化的东西来赢得信任。
需要赢得信任不仅仅是测试，还有开发，外包。
我们在做 pipeline 和门禁的时候，会卡一些点，比如单测覆盖率，接口测试覆盖率，这些都是开发需要保证的。基于测试不能相信开发的第一定律，不能嘴上说说就可以，所以我们需要可以量化的数据来支撑。
外包的工作验收向来都是难点，通常外包投入到业务手工测试中去，都是执行用例，然后最后总结一个报告出来。这个会以测试用例执行数量和用例通过率来衡量，但是用例本身是否覆盖了所有的分支，外包有没有漏测，这些通过业务系统的覆盖率可以很好的反应出来。
最后，要上线的时候，你可以拿着覆盖率来增加你的发布信心。
每个项目都应有自己的阈值，但是测试必须覆盖主要业务场景，代码的逻辑分支也必须尽可能的覆盖。所以在有限的时间内做到最高的就可以了。
我们的经验是持续建设，持续增益。初期可能就打个底座，慢慢地在迭代中把覆盖率加上去。
每种语言都有自己的覆盖率收集方式。最成熟是 Java，基于 jacoco，市场上有非常成熟的方案。非 Java 类的应用，比如 c++，go，python 这些也都有自己体系的覆盖率收集方式。不同地地方在于集成测试覆盖率的收集，我们在做手工测试，在调用对外暴露的接口，这些都是黑盒的测试，我们想收集这样测试下的覆盖率。Java 类的非常简单，只需要在启动 Java 应用的时候，挂载 jacoco 的 agent 就可以了，而非 Java 的应用，在集成测试的时候，就比较困难了。
就像测试也没法保证百分百出问题一样，覆盖率能保证的更少。它是许多能量化的测试手段中的一种，是度量测试完整性的一个手段，是测试有效性的一个度量。
聊了那么多，其实是想再来介绍下，MTSC2019，来自蚂蚁金服的议题《进化的覆盖率 --- 代码实时染色系统》。这是移动测试领域覆盖率方案的一个标杆。我记得 360 的刘俊说过，参加了 MTSC2019 大会，听了这个议题之后，一开始以为那么酷炫的效果做不出来，但是经过探索还是做出了类似的系统。社区本次开放了 MTSC2019 年的议题，正好可以重新再来学习下。如果配合 MTSC2019 年深圳场飞麦的议题来看，会更有收获。其他的话不多说，下面是两个议题的视频。