您如何衡量单元测试的质量？

如果您(或您的组织)希望对您的代码进行彻底的单元测试,那么您如何衡量您的成功或质量？

您是否使用代码覆盖率,您的目标是多少？

您是否发现像TDD这样的哲学比指标有更好的影响？

webmat.. 34

我的提示不是一种确定你是否有良好的单元测试本身的方法,但它是一种随着时间推移发展一个好的测试套件的方法.

无论何时遇到错误,无论是在开发中还是由其他人报告,都要修复两次.首先创建一个单元测试来重现问题.当你有一个失败的测试,那么你去解决问题.

如果首先出现问题,那就是关于代码或域名的微妙暗示.为它添加测试可以确保它将来永远不会被重新引入.

关于这种方法的另一个有趣的方面是,它可以帮助您在实际查看代码的复杂性之前从更高级别了解问题.

此外,其他人已经提到的测试覆盖的价值和陷阱+1.

1> webmat..：

---

我的提示不是一种确定你是否有良好的单元测试本身的方法,但它是一种随着时间推移发展一个好的测试套件的方法.

无论何时遇到错误,无论是在开发中还是由其他人报告,都要修复两次.首先创建一个单元测试来重现问题.当你有一个失败的测试,那么你去解决问题.

如果首先出现问题,那就是关于代码或域名的微妙暗示.为它添加测试可以确保它将来永远不会被重新引入.

关于这种方法的另一个有趣的方面是,它可以帮助您在实际查看代码的复杂性之前从更高级别了解问题.

此外,其他人已经提到的测试覆盖的价值和陷阱+1.

2> t3mujin..：

---

代码覆盖率是一个有用的指标,但应谨慎使用.有些人采用代码覆盖,特别是涵盖的百分比,有点太认真,并将其视为良好单元测试的指标.

我的经验告诉我,比试图获得100%覆盖更重要,这并不容易,人们应该专注于检查关键部分.但即便如此,你也可能会得到误报.

3> Scott Bale..：

---

我非常支持TDD,但我并不重视覆盖率统计数据.对我来说,开发团队在开发时间段内感受到单元测试的成功和实用性,因为测试(a)预先发现错误,(b)实现重构和更改而不会回归,(c)帮助充实模块化,解耦设计,(d)和诸如此类的.

或者,正如Martin Fowler所说,支持单元测试和TDD的轶事证据是压倒性的,但你无法衡量生产力.阅读更多关于他的bliki:http://www.martinfowler.com/bliki/CannotMeasureProductivity.html

4> ironfroggy..：

---

如果它可以破坏,应该进行测试.如果可以测试,它应该是自动化的.

5> Gary Rowe..：

---

为了充分衡量代码的可信度,您需要不同级别的测试:单元,集成和功能.我同意上面给出的建议,即测试应该是自动化的(持续集成),并且单元测试应该涵盖具有各种边缘案例数据集的所有分支.代码覆盖工具(例如Cobertura,Clover,EMMA等)可以识别分支中的孔,但不能识别测试数据集的质量.静态代码分析(如FindBugs,PMD,CPD)可以在代码成为问题之前识别代码中的问题区域,并大大促进更好的开发实践.

测试应尝试尽可能复制应用程序将运行的整体环境.它应该从最简单的情况(单位)开始到最复杂的(功能).对于Web应用程序,必须使用各种浏览器来运行遍历网站所有用例的自动化过程,因此SeleniumRC应该在您的工具箱中.

但是,软件的存在是为了满足业务需求,因此还有针对需求的测试.这往往更像是基于功能(网络)测试的手动过程.基本上,您需要针对规范中的每个需求和相应的功能测试构建可跟踪性矩阵.在创建功能测试时,它们与一个或多个要求相匹配(例如,登录为Fred,更新密码的帐户详细信息,再次注销).这解决了交付物是否符合业务需求的问题.

总的来说,我会提倡基于某种自动化单元测试(JUnit,nUnit等)的测试驱动开发方法.对于集成测试,我建议使用一个测试数据库,该数据库在每个构建中使用已知数据集自动填充,该数据集说明了常见用例,但允许构建其他测试.对于功能测试,您需要某种用户界面机器人(用于Web的SeleniumRC,用于Swing的Abbot等).可以在构建过程中轻松收集每个度量标准,并在CI服务器(例如Hudson)上显示,供所有开发人员查看.

6> Wedge..：

---

如果您测量测试质量的主要方法是某种自动度量标准,那么您已经失败了.

度量标准可能会产生误导,并且可以进行游戏.如果度量标准是判断质量的主要(或者更糟的是,只有)方法,那么它们将被游戏(可能是无意的).

例如,代码覆盖率极具误导性,因为100%的代码覆盖率远远不及完整的测试覆盖率.此外,像"80%代码覆盖率"这样的数字在没有上下文的情况下也会产生误导.如果覆盖范围是最复杂的代码,并且只是错过了如此简单的代码,那么很容易通过眼睛进行验证,那么这比覆盖范围反向偏差要好得多.

此外,区分测试的测试域(基本上是功能集)和质量也很重要.测试质量不取决于测试的程度,因为代码质量不是由特征列表决定的.测试质量取决于测试在测试中的表现.实际上很难总结自动化指标.

下次再编写单元测试时,请尝试此实验.查看有多少种不同的编写方式,使其具有相同的代码覆盖率并测试相同的代码.看看它是否有可能编写一个满足这些标准的非常差的测试,以及一个非常好的测试.我想你可能会对结果感到惊讶.

最终,经验和判断无可替代.人眼,希望是几只眼睛,需要查看测试代码并确定它是否好.

7> Bill the Liz..：

---

代码覆盖是测试,因为测试是编程.它只能告诉你何时出现问题,它无法告诉你何时一切正常.您应该拥有100%的代码覆盖率.应使用多个输入值测试代码逻辑分支,完全处理正常,边缘和极点情况.

---

对.达到100%的代码覆盖率并不意味着您已经完成了测试.你的代码可能还有很多问题.

8> JamShady..：

---

我通常做TDD,所以我先写测试,这有助于我了解我希望如何使用这些对象.

然后,当我写这些课时,在大多数情况下,我可以发现常见的陷阱(即我正在做的假设,例如变量属于特定类型或值范围),当这些出现时,我写了一个针对该特定案例的具体测试.

除此之外,并且尽可能地获得代码覆盖率(有时候不可能达到100%),你或多或少地完成了.然后,如果将来出现任何错误,您只需确保为其编写一个首先公开它的测试用例,并在修复时通过.然后按照正常情况修复.