疫情当下,每天早上起来就会看看各种数字,有没有增多,有没有减少,再看看周边小区是不是有疫情,一波操作之后,才放心地吃早餐。数字就像一根定海神针,当你看见了,才会觉得安心。比如每当半夜惊醒的时候,发现自己还是十八岁,瞬间就安心了。覆盖率就是这种类型的数据。当你看见覆盖率上来了,你就会安心,就会有信心。最近一直在做 pipeline,覆盖率是其中重要的数据,所以想来聊聊覆盖率。都是自己的看法,得罪之处多多包涵。

是不是一定要有覆盖率

很多人都说,我们项目没有覆盖率照样上线,我说啥测试都不做的项目直接怼上线大把大把。从狭义的角度来看,覆盖率可以不需要。但是它会以另外一种形式存在。比如,会有人问这个功能测完了吧?测试充分了吧?异常用例都跑了吧?这种不精准,含糊的,无法量化的覆盖率一直存在项目的过程中。所以就像我们回答是不是一定要有测试一样,可以没有测试人员,测试角色,但是测试无处不在。

覆盖率用来做什么?

当你无法量化的时候,你就在用你的人品和信誉做担保,而开发团队对你的信任也是基于你的信誉。可是在你还没有建立你的信誉的时候,你就必须拿出量化的东西来赢得信任。

需要赢得信任不仅仅是测试,还有开发,外包。

我们在做 pipeline 和门禁的时候,会卡一些点,比如单测覆盖率,接口测试覆盖率,这些都是开发需要保证的。基于测试不能相信开发的第一定律,不能嘴上说说就可以,所以我们需要可以量化的数据来支撑。

外包的工作验收向来都是难点,通常外包投入到业务手工测试中去,都是执行用例,然后最后总结一个报告出来。这个会以测试用例执行数量和用例通过率来衡量,但是用例本身是否覆盖了所有的分支,外包有没有漏测,这些通过业务系统的覆盖率可以很好的反应出来。

最后,要上线的时候,你可以拿着覆盖率来增加你的发布信心。

覆盖率应该达到多少?

每个项目都应有自己的阈值,但是测试必须覆盖主要业务场景,代码的逻辑分支也必须尽可能的覆盖。所以在有限的时间内做到最高的就可以了。

我们的经验是持续建设,持续增益。初期可能就打个底座,慢慢地在迭代中把覆盖率加上去。

覆盖率收集方式

每种语言都有自己的覆盖率收集方式。最成熟是 Java,基于 jacoco,市场上有非常成熟的方案。非 Java 类的应用,比如 c++,go,python 这些也都有自己体系的覆盖率收集方式。不同地地方在于集成测试覆盖率的收集,我们在做手工测试,在调用对外暴露的接口,这些都是黑盒的测试,我们想收集这样测试下的覆盖率。Java 类的非常简单,只需要在启动 Java 应用的时候,挂载 jacoco 的 agent 就可以了,而非 Java 的应用,在集成测试的时候,就比较困难了。

有了覆盖率是否可以高枕无忧

就像测试也没法保证百分百出问题一样,覆盖率能保证的更少。它是许多能量化的测试手段中的一种,是度量测试完整性的一个手段,是测试有效性的一个度量。

总结

聊了那么多,其实是想再来介绍下,MTSC2019,来自蚂蚁金服的议题《进化的覆盖率 --- 代码实时染色系统》。这是移动测试领域覆盖率方案的一个标杆。我记得 360 的刘俊说过,参加了 MTSC2019 大会,听了这个议题之后,一开始以为那么酷炫的效果做不出来,但是经过探索还是做出了类似的系统。社区本次开放了 MTSC2019 年的议题,正好可以重新再来学习下。如果配合 MTSC2019 年深圳场飞麦的议题来看,会更有收获。其他的话不多说,下面是两个议题的视频。

覆盖率

飞麦的议题


↙↙↙阅读原文可查看相关链接,并与作者交流