有关如何反驳代码覆盖率质量参数的任何工具/建议
现在，我知道人们会认为这个问题重复或被问过很多次，在这种情况下，我希望获得与相关问题的链接以及我的问题的答案。 我最近在代码覆盖方面与某些人意见不一致。我有一群人希望我们的团队基于100％的覆盖率并不意味着良好的质量测试以及良好的代码质量就完全放弃代码覆盖率的研究。 通过推销“代码覆盖率”可以告诉我尚未确定的内容的论点，我可以进行回退，并帮助我们专注于这些领域。 （以上已经在类似这样的其他SO问题中以类似的方式进行了讨论-https: //stackoverflow.com/questions/695811/pitfalls-of-code-coverage） 这些人的论据是-然后，团队会做出反应，迅速创建质量低下的测试，从而浪费时间，同时又不增加明显的质量。 在理解他们的观点的同时，我正在寻找一种方法，通过引入更健壮的工具/框架来照顾更多的覆盖标准， 从而使代码覆盖更可靠(Functional, Statement,Decision, Branch, Condition, State, LCSAJ, path, jump path, entry/exit, Loop, Parameter Value etc)。 我正在寻找的建议是将这样的代码覆盖率工具和实践/过程结合在一起使用，这可以帮助我在对建议感到满意的同时反驳此类争论。 我也欢迎根据您的经验/知识如何提出反对意见提出的任何评论/建议，因为尽管主观，但是代码覆盖率使我的团队更加意识到了代码质量和测试价值。 编辑：为了减少对我对典型代码覆盖范围弱点的理解的困惑，我想指出的是，我并不是指 Statement Coverage（或执行的代码行）工具（有很多）。实际上，这里有一篇很好的文章介绍了所有错误之处：http : //www.bullseye.com/statementCoverage.html 我不仅在寻找语句或行覆盖率，而且还在寻找多个覆盖率标准和级别。 请参阅：http : //en.wikipedia.org/wiki/Code_coverage#Coverage_criteria 这个想法是，如果一个工具可以根据多个标准告诉我们我们的覆盖范围，那么它将成为对测试质量的合理自动化评估。我绝不是要说线路覆盖率是一个很好的评估。实际上，这就是我提出这个问题的前提。 编辑： 好的，也许我对它的预测太过夸张了，但是您明白了。问题在于以统一/一致的方式在所有团队中设置流程/策略。人们普遍担心，您如何确保测试质量，如何在没有任何措施的情况下分配保证的时间。因此，我喜欢具有可测量的功能，当使用适当的流程和正确的工具进行备份时，它将使我们能够提高代码质量，同时又知道不会浪费时间在浪费性的流程上。 编辑：到目前为止，我从答案中得到了什么： 代码审查应涵盖测试以确保测试质量 “测试优先”策略有助于避免事后写出的测试仅增加覆盖率％ 探索涵盖测试标准的替代工具，而不仅仅是声明/行 分析覆盖的代码/发现的错误数量将有助于理解覆盖的重要性并提供更好的案例 最重要的是，请信任团队的投入以做正确的事并为自己的信念而战 涵盖的区块/测试数量-值得商but，但具有一定价值 感谢您迄今为止的出色回答。我真的很感激他们。此功能比具有强大功能的头脑风暴要好几个小时。