都100%代码覆盖了，还会有什么问题？

测试覆盖率| 2017-09-27

作者：ThoughtWorks

图0：都100%代码覆盖了，还会有什么问题？

（图片来自：https://t.cn/R06rQHi）

很多人看到这个标题时，都会想“你都100%代码覆盖了，怎么还会有问题呢？” 让我们看一下代码例子:

图1：都100%代码覆盖了，还会有什么问题？

再看看用junit写出的测试代码：

图2：都100%代码覆盖了，还会有什么问题？

当我们使用EclEmma或者Jacoco来进行覆盖测试时，对于这个类，我们将得到100%测试覆盖率。

图3：都100%代码覆盖了，还会有什么问题？

一切看起来都那么的完美，真是这样的吗？

好吧，让我们来来看看另一个测试，当其中一个变量为null时，返回值将会是什么？

图4：都100%代码覆盖了，还会有什么问题？

好了，你会发现尽管覆盖率为100%，但程序却抛出了NullPointerException。

那么肯定有人会问，这样的话单元测试覆盖率的高低都不能作为衡量项目代码质量的指标，那么我们要单元测试还有什么用？

首先，我想我们可能搞错了测试覆盖的定义。

我们先听听Martin Fowler对于测试覆盖的定义：

Test coverage is a useful tool for finding untested parts of a codebase. Test coverage is of little use as a numeric statement of how good your tests are.

图5：都100%代码覆盖了，还会有什么问题？

（图片来自：https://martinfowler.com/bliki/TestCoverage.

他认为：把测试覆盖作为质量目标没有任何意义，我们应该把它作为一种发现未被测试覆盖的代码的手段。

所以100%的代码覆盖率还值得追求吗?

当然，这应该是每个程序员毕生的追求之一，但是如果从项目角度考虑ROI(投入产出比)，对于需要快速上线的短期项目，需要注重的是让测试覆盖核心功能代码。如果你的项目是一个长期项目，那么高覆盖率是非常有必要的，它意味着高可维护性，以及更少的bug。(前提是你的测试采用TDD/BDD方式编写，我见过将测试代码写的一团糟的人，看着他的代码，我宁愿重新写一遍)

那么对于一个项目来说，覆盖率应该达到多少？

其实没有适用于所有项目的数值，每个项目都应有自己的阈值，但共性是，测试必须覆盖主要业务场景，代码的逻辑分支也必须尽可能的覆盖。

如何改进你的项目代码覆盖率？

首先我们要阅读和理解项目代码，找出其中需要测试并且与业务强相关的代码，结合sonar等代码质量管理平台，从代码编写规范、复杂度、重复代码等方面进行代码重构，进一步提高项目的可维护性与可读性。

这也意味着重构，重构的同时，你需要更多的测试来保证你重构代码的正确性。

其次要对code coverage进行度量分析，那么我们应该怎么度量code coverage？

图6：都100%代码覆盖了，还会有什么问题？

一般来说我们从以下四个维度来度量，如上图所示:

行覆盖率（line coverage）：度量被测代码中每个可执行语句是否都被执行到，但不包括java import，空行，注释等。
函数覆盖率（function coverage）：度量被测代码中每个定义的函数是否都被调用。
分支覆盖率（branch coverage）：度量被测代码中每一个判定的分支是否都被测试到。
语句覆盖率（statement coverage）：度量被测代码是否每个语句都被执行。

所以行覆盖率的高低不能说明项目的好坏，我们要从多方面进行思考，一般我们遵循的标准应是：函数覆盖率 > 分支覆盖率 > 语句覆盖率**。

代码覆盖率最重要的意义在于：

阅读分析之前项目中未覆盖部分的代码，进而反推在前期QA以及相关测试人员在进行黑盒测试设计时是否考虑充分，没有覆盖到的代码是否是测试设计的盲点，为什么没有考虑到？是需求或者UX设计不够清晰，还是测试设计的理解有误。
检测出程序中的废代码，可以逆向反推代码设计中不合理的地方，提醒设计/开发人员理清代码逻辑关系，提升代码质量。
代码覆盖率高不能说明代码质量高，但是反过来看，代码覆盖率低，代码质量绝对不会高到哪里去，可以作为测试自我审视的重要工具之一。