利用自动JUnit代码覆盖率测试用例生成来快速构建和扩展测试

我最近写过一篇关于陷入代码覆盖率百分比陷阱的文章，这引发了热烈的讨论，所以我想我将更深入地探讨代码覆盖率问题和解决方案。具体来说，涵盖覆盖率本身、自动生成的JUnit测试的值以及如何识别有问题的单元测试。另外，还会浅显地提及如何在执行方面继续做得更好。

JUnit代码覆盖率如何工作？

让我们从覆盖率指标本身以及我们如何计算代码覆盖率开始。代码覆盖率数字通常是无意义的，或充其量是会造成误导的。如果你“确实”拥有100％的代码覆盖率，那又意味着什么呢？你是如何测量的？

有很多不同的方法来衡量覆盖率。

衡量代码覆盖率的一种方法是从需求角度出发。你是否对每一项要求都进行了测试？这是一个合理的开始……但这并不意味着所有代码都已经过测试。

衡量代码覆盖率的另一种方法是通过测试的次数（别笑，我实际上是在真实案例中听到的）。真的，我是说真的！这是一个非常糟糕的指标，显然毫无意义。可能是比简单地计算你拥有多少个测试还差？当然，这个我不好说。

然后我们来尝试确定执行了什么代码。常见的覆盖率指标包括语句覆盖率、行覆盖率、分支覆盖率、决策覆盖率、多个条件覆盖率，或者更全面的MC/DC或修改后的条件/决策覆盖率。

当然，最简单的方法是行覆盖率，但是你可能已经看到，工具对此进行了不同的衡量，因此覆盖率将有所不同。执行代码行并不意味着你已经检查了该代码行中可能发生的所有不同情况。这就是为什么安全关键标准（例如用于汽车功能安全的ISO 26262和用于