【发布时间】：2011-02-28 14:52:51
【问题描述】：
是否有经过验证的方法来验证 junit 测试或集成测试的质量？
您的业务分析师是否应该审核单元测试以确保其有效性？或者还有其他方法吗？ 在传统的代码优先环境中，同行或领导会审查测试计划，但自动化测试呢？
我查看了this stackflow 线程，但无法提取任何有意义的内容。
想法？
【问题讨论】：
标签： junit
【发布时间】：2011-02-28 14:52:51
【问题描述】：
Mutation testing 和 代码覆盖率 可以验证您的测试的质量。
所以首先检查你的代码覆盖率是否足够高。在此通过变异测试验证之后，您的 测试结果良好。变异测试工具在生产代码中进行小的更改并重新运行测试 - 修改后，一个好的测试应该会失败。对于 Java 中的变异测试工具，请查看 PIT Mutation Testing 和这篇博文：Introduction to mutation testing with PIT and TestNG
但这还不够，测试应该写得好，可读性好。因此，您还需要代码审查和测试的质量规则验证。我推荐一本关于编写好测试的好书Practical Unit Testing。第 10 章：本书中的Maintainable tests 可免费获得。
【讨论】：
-
这里是变异测试思维方式的一个很好的例子：wp.me/prMeE-11
-
@MariuszS 变异测试能保证百分百的junit代码质量吗？
这是一篇不错的链接文章：
http://www.ibm.com/developerworks/java/library/j-cq01316/index.html?ca=drs
还有：
良好的测试⇒高覆盖率 高覆盖率⇒/⇒ 良好的测试
覆盖率工具有助于确定项目的哪些区域需要更多关注，但这并不意味着覆盖范围好的区域不需要更多关注。
代码覆盖工具是一个好的开始，但知道给定的行已执行并不意味着它已经过测试。没有断言或expected=Exception.class 的臭名昭著的测试用例就是一个例子。
我可以想象这个级别的标准很少：
- 如果线路经过测试，对其进行的任何更改（反转条件、移除...）都应至少通过一项测试
- 给定的逻辑应该是完全可重构的，仅基于其测试
- 测试不反映生产代码
- 测试不应依赖于当前日期、区域设置、时区、其他测试的顺序
一个人可能会尝试自动化第一个，其他人或多或少是主观的。
至于分析师进行测试审查 - 可能只有 Fitensse 固定装置的可读性足以满足非开发人员的需求。
【讨论】：
代码审查是确保测试质量的最佳方式。我不会让业务分析师审查测试，因为他们可能没有接受过理解测试所需的培训。此外，单元测试并不都存在于分析师需求所在的功能级别。分析师可能会说“当用户单击保存时，配置文件被保存”，而您可能必须跨多个层编写 n 个测试才能获得该功能。
【讨论】：
-
代码审查是一个工具，但是如果使用它的人不知道如何最好地使用它，那么这个工具就毫无用处。进行代码审查的人需要有正确的测试关键心态来确定某些东西是否经过充分测试。工具可以提供有用的指标来帮助确定需要关注的领域，但最终是编写代码的人最清楚他/她的组件的极端情况是什么。
您可以考虑使用代码覆盖工具来确保 100% 的代码行正在测试。 Emma 是一个很好的 java 工具（http://emma.sourceforge.net/）。
【讨论】：
-
我不会说 100% 的代码覆盖率结果可以确保您的 JUnit 测试的质量。这可能会导致开发人员添加一些无用的测试，以确保他们的覆盖结果足够。
-
我不会投反对票，但覆盖率不是质量指标，而是覆盖率指标。具有 100% 的覆盖率并不能确保测试正在测试任何内容。
-
代码覆盖率只会确保每一行代码都有一个测试。它仍然不能证明我在真正的 TDD 或 Test First 环境中的测试质量。我错过了什么吗？
-
我同意这不是质量的最佳衡量标准，但它确实提供了一个关于需要或预期多少单元测试的指标。最后，单元测试的质量取决于招聘过程的质量（以及管理层随后要求开发人员对编写测试负责的程度）。代码覆盖率是一种（可测量的）方式来强制要求编写一定的最低数量的测试。