高代码覆盖率并不能保证高产品质量，但低代码覆盖率一定说明大部分逻辑没有被自动化测到。后者通常会增加问题遗留到线上的风险，当引起注意。
没有普适的针对所有产品的严格覆盖率标准。实际上这更应该是业务或技术负责人基于自己的领域知识，代码模块的重要程度，修改频率等等因素，自行在团队中确定标准，并推动成为团队共识。
低代码覆盖率并不可怕，能够主动去分析未被覆盖到的部分，并评估风险是否可接受，会更加有意义。实际上笔者认为，只要这一次的提交比上一次要好，都是值得鼓励的。
谷歌有篇博客(参考资料)提到，其经验表明，重视代码覆盖率的团队通常会更加容易培养卓越工程师文化，因为这些团队在设计产品之初就会考虑可测性问题，以便能更轻松的实现测试目标。而这些措施反过来会促使工程师编写更高质量的代码，更注重模块化。
最后，欢迎点击左下角详情按钮，加入七牛云Goc交流群，我们一起聊聊goc，聊聊研发效能那些事。
参考资料
谷歌管理覆盖率的经验: https://testing.googleblog.com/2020/08/code-coverage-best-practices.html
往期推荐开源啦 | go语言系统测试覆盖率收集利器goc
觉得不错，欢迎关注：