盲猜效率低，先思考再进行验证

最近应业务要求在写单元测试代码，有个要求是单元测试的覆盖率要达到85%以上。 每新增一行新的代码，基本上都需要再写上对应的测试代码验证这行代码是可以被正确执行的。

要求：单元测试85%的覆盖率；

在执行的时候遇到一个问题，就是我写的单元测试覆盖率只能达到75%，无论怎么写都是只能达到这个数字；

既然有衡量的数字指标，那就一定有衡量的口径，是那个类降低了整体的覆盖率；

找到了对应的类之后，接下来就是解决这个类为什么覆盖率这么低的问题；

但是本地运行的时候，发现这个类的覆盖率已经95%了，为什么在系统上仍然展示30%呢？
然后我就开始不断的修改自己的单元测试写法，然后部署，然后修改，然后部署，核心都是修改这个类：修改名称，多写几个方法，修改类的内部逻辑...
发现都是行不通，花了两天的时间都没有提示这个类的覆盖率；

在今天有同学提出了一个新的问题？
这个类的单元测试有没有被运行到，这个有办法知道吗？然后故意的抛出几个错误，发现在单测服务根本就没有运行这个类；

挪动了类的位置，到另外一个模块中，单元测试的覆盖率提升上来了，终于解决了问题。

其实是一个非常简单的问题，我却处理了两天的时间，这个效率可谓非常非常之低，这个问题的价值当然是非常小的，可能是典型的投入远大于产出。

回顾整个事情，我思考的问题链路：

• 怎么提升我的单元测试覆盖率？
• 怎么提升我的类的单元测试覆盖率？
• 为什么测试服务的测试覆盖率这么低？与实际不符，变成一个复杂的问题；
• 猜测个人写法有问题，咨询一些同学，没遇到过这个问题，自行排查；然后就陷入了不断的修改写法，不断验证...
• 直到有个打破了我的思考链路，你的这个能不能被统计到？
• 然后故意抛出错误，看看能不能被识别到，发现没识别，确实没有被统计到，修复问题；

过程中有问题的点：

• 从提出假设到验证的时间太长了； 机器部署一次需要15~20分钟，一个下午只能尝试几次。
• 遇到问题，只考虑一种情况，而不是把所有的可能先列一下，再进行尝试验证；

回到我自己的单元测试覆盖率有90%，但是测试服务的覆盖率只有35%，这个问题的可能原因有哪些？

• 我本地是错误的？ 不可能，确实全部都有覆盖到
• 测试服务是错误的？ 看起来不太可能，因为有35%的覆盖率；

为什么只统计到35%？而不是0%？

• 被统计到的那35%是什么？
• 剩余没被统计到的55%是什么？

发现35%的在其他地方有覆盖到，那么当前的这个类是不是全部都没有覆盖到，只是被其他的类影响才统计到的。

一点想法

反馈越快，效率越高，但是有时候这个反馈的速度不是我们能控制的；

遇到数据不一致的问题时，第一反应应该是数据的差异部分是什么，增加的部分是什么？删除的部分是什么？ 然后总结增加和删除部分的特征；

遇到稍微复杂一点的问题时，不要靠盲猜，而是先系统性的梳理出各种可能性，把可能性都列出来，然后依次进行验证；而不是反反复复的验证同一个可能性。学会思考可以大幅提升人的效率真的不假；