简介很多人看到这个标题都会想“你代码覆盖率100%了，怎么还会有问题呢？”我们看代码示例：publicclassTestCalculator{publicDoubleadd(Doublea,Doubleb){returna+b;}}看junit写的测试代码：@TestpublicvoidtestAdd(){Doublea=newDouble(1);Doubleb=newDouble(2);Doublec=newDouble(3);assertEquals(c,testCalculator.add(a,b));}当我们使用EclEmma或Jacoco进行覆盖测试时，我们将获得该类100%的测试覆盖率。一切看起来都他妈的很好，是吗？好吧，我们再看一个测试，当其中一个变量为null时，返回值会是多少？@TestpublicvoidtestAddNullPointerException(){Doublea=newDouble(1);Doubleb=null;Doublec=newDouble(3);assertEquals(c,testCalculator.add(a,b));}嗯，你会发现虽然覆盖率是100%，程序抛出NullPointerException。那么肯定有人会问，在这种情况下，单元测试覆盖率的高低不能作为衡量项目代码质量的指标，那么单元测试有什么用呢？首先，我认为我们可能误解了测试覆盖率的定义。让我们先听听MartinFowler对测试覆盖率的定义：测试覆盖率是一种用于查找代码库中未测试部分的有用工具。测试覆盖率作为一个数字说明你的测试有多好用处不大。（图片来自：http://t.cn/R06jK5U）他认为把测试覆盖率作为质量目标是没有意义的，我们应该把它作为一种发现测试未覆盖代码的手段。那么100%的代码覆盖率值得追求吗？当然，这应该是每个程序员毕生的追求之一，但是如果从项目的角度考虑ROI（投入产出比），对于需要快速上线的短期项目，需要重点放在有测试涵盖了核心功能代码。如果你的项目是一个长期项目，那么高覆盖率是非常有必要的，它意味着高可维护性，以及更少的bug。（前提是你的测试是用TDD/BDD写的，我见过有人把测试代码写的乱七八糟，看他的代码，我宁愿重写。）那么对于一个项目来说，覆盖率应该是多少实现了？?事实上，没有适用于所有项目的价值。每个项目应该都有自己的门槛，但共性是测试要覆盖主要的业务场景，代码的逻辑分支也要尽量覆盖。如何提高你的项目代码覆盖率？首先我们需要阅读和理解项目代码，找出需要测试的和业务强相关的代码，结合sonar等代码质量管理平台，从代码编写规范、复杂度、重复代码等代码重构，进一步提高项目的可维护性和可读性。这也意味着重构。在重构时，您需要进行更多测试以确保重构代码的正确性。其次，我们需要对代码覆盖率进行度量和分析，那么我们应该如何度量代码覆盖率呢？一般来说，我们从以下四个维度来衡量，如上图所示：是否所有的执行语句都被执行，但不包括javaimport、空行、注释等函数覆盖：衡量代码下是否每一个定义的函数测试被称为。分支覆盖率（branchcoverage）：衡量被测代码中每个确定的分支是否都被测试过。语句覆盖率（statementcoverage）：衡量被测代码的每条语句是否都被执行。因此，线路覆盖的高低并不能说明工程的好坏。我们需要从多方面考虑。一般来说，我们遵循的标准应该是：函数覆盖>分支覆盖>语句覆盖。代码覆盖最重要的意义是：阅读和分析之前项目未覆盖部分的代码，进而推断前期QA和相关测试人员是否充分考虑了黑盒测试设计，未覆盖的代码是否测试设计为什么没有考虑盲点？是需求还是UX设计不够清晰，还是对测试设计的理解有误。检测程序中的废代码，可以扭转代码设计中不合理的部分，提醒设计者/开发者理清代码的逻辑关系，提高代码质量。代码覆盖率高并不意味着代码质量高，但另一方面，如果代码覆盖率低，代码质量永远不会高，可以作为测试的重要工具之一自查。结论单元测试的覆盖率不仅仅是为了取悦客户或者管理数据。它实际上可以反映项目中代码的健康状况，帮助我们更好地提高代码质量，增加我们对所写代码的理解。信心。
