提高代码覆盖率不是测试一个人的事

现在很多团队都在推敏捷开发，讲究快速迭代、小步快跑。但快不等于乱，迭代不等于敷衍。

我发现一个很有意思的现象：重视代码覆盖率的团队，研发流程往往更规范；反之，流程混乱的团队，覆盖率通常也低得可怜。

为什么会这样？因为要提高代码覆盖率，不是测试一个人的事，而是需要开发和测试的配合。

开发写代码的时候，要考虑可测试性，不能写一堆耦合度高、逻辑混乱的代码，否则测试根本没办法设计用例。测试设计用例的时候，要对照着代码逻辑，把每个分支、每个条件都覆盖到，不能只测主流程。

举个例子，我们团队以前开发新功能，都是开发写完就扔给测试，测试发现Bug就打回去。

后来我们规定，所有新功能提交前，开发必须先做单元测试。这么做了之后，我们团队的效率明显提升，测试环节反馈的低级 Bug 数有所下降，来回返工的时间大幅减少。大家能把精力集中在核心功能打磨上，版本上线的稳定性也跟着提高。

如果大家对禅道研发团队流程感兴趣，可扫码备注【流程1223】领取

因为开发在写单元测试的时候，其实是在自己检查代码逻辑。

很多低级错误，比如变量名写错、条件判断颠倒，在这个阶段就被发现了，根本轮不到测试去提Bug。而且，单元测试写得好，后续集成测试和系统测试的效率也会提高。

这就是覆盖率的价值，它能逼着整个研发流程往更规范的方向走。