代码覆盖率是否应该被用作阻碍项目进展的“里程碑”？

Question

我是一个项目的开发经理，这个项目的单元测试代码覆盖率非常低，我们确实感受到了系统遗留代码中“技术债务”的重量。

我的问题是，是否有人使用代码覆盖率作为里程碑或开发阈值，以阻止项目进入下一个冲刺，直到代码覆盖率达到特定级别？使用代码覆盖率度量的“最佳实践”是什么？

Answer 1

代码覆盖率是一个非常相对的东西。首先，因为代码复盖率本身并不能说明代码或单元测试的质量。其次，有时只用几个测试就能达到90%的覆盖率是很容易的，但有时甚至很难达到50%。对于遗留项目尤其如此，这些项目通常不是为了辅助单元测试而设计的(例如，为了避免外部依赖)。

如果你真的想把它作为一个里程碑，我的建议是拿你的代码中一些重要的类，例如那些拥有大量业务逻辑的类，看看在它上面实现高代码覆盖率是否容易。如果是这种情况，请确保此类类的代码覆盖率始终符合标准。

我的经验告诉我，在遗留类上获得高代码覆盖率需要花费很多时间，这并不总是值得投资。

我希望这能帮到你!

Answer 2

我认为使用代码覆盖率作为拦截器是不合适的。原因是，拥有一个良好的覆盖面并不是主要目标，而且它本身可以变成一个目标。只需“运行一些东西”来获得度量，而不是实际测试它，这是相当容易的。

因此，根据我的经验，最重要的事情是在运行代码的同时实际做一些事情。换句话说，重要的是你的测试是测试，而不仅仅是运行代码。

但无论如何，使用代码覆盖率作为度量标准，并在它增加时适当庆祝:-)

Answer 3

总而言之:如果你实践Scrum (或任何其他敏捷方法)，你应该遵循时间盒原则，避免扩展/延迟你的冲刺。

具体地说:代码覆盖率指标本身不足以估计应用程序的测试/就绪状态。应该使用更复杂的度量组合(请参阅有关软件测试的书籍)。