软件测试度量是一种通过检测软件测试过程的质量和有效性来评估软件开发的量化方法。开发团队使用测试指标来跟踪开发过程各个阶段的软件质量。测试指标对于管理层也很有用，它可以让公司股东评估软件开发团队的效率。
测试指标应该始终是有意义和可执行的。问题是有些测试指标无法达到这一目标。许多指标都是误导，有些只是无价值的指标，而有些则毫无意义。
下面这些无用的测试指标的例子可以帮助你更好地理解测试指标是否提供了所需的洞察力。
1 执行的测试用例的数量
这是一个糟糕的度量标准，原因很简单，它没有告诉你测试用例测试的是什么。
这个度量标准的最初想法是，我们开发的测试用例越多，我们的测试就越全面。实际上，许多测试用例根本没有对测试覆盖率做出贡献。许多测试套包含已弃用的测试，这些测试不再与软件的新版本相关。测试用例的设计效率不高，因此它们会重叠，并且本质上是测试相同的功能。
在这些和许多其他的情况下，拥有更多的测试用例并不是一件好事，这可能只是代表一个臃肿且过于复杂的测试套。
2每一个测试人员发现的Bug数
这是一个糟糕度量标准的原因之一在于,度量每一个测试人员的任何东西都不是一个好的实践——它鼓励过度的竞争，并且破坏协作的的团队工作，而团队合作在敏捷组织中得到了强烈的鼓励。
有些公司甚至会根据每个软件测试人员发现的缺陷来决定员工报酬，这对团队的目标尤其不利，因为它往往会抑制信息的共享，并促进“每个人都只为自己”的态度。
此外，一个员工可能在测试一个稳定的软件特性，而另一个测试一个有缺陷的、不稳定的特性。在这个度量标准下，后者会被认为性能更好，因为他发现了更多的bug，这是很愚蠢的的。
3百分比通过率
使用百分比通率作为度量指标是一个坏主意，因为在你的软件开发团队中不鼓励的行为很容易操纵这种指标。
例如，测试团队可能会专注于执行更容易通过的测试，从而提高通过率。或者，团队可以将一个长时间的测试分解成许多小的测试，人为地提高百分比的通过率。换句话说，这个指标变化无常，易于操纵。
4单元测试代码覆盖率
代码覆盖是另一个常用的度量指标，常常被错误地使用。代码覆盖率是由单元测试覆盖的代码行百分比。代码覆盖可以给你一个完全错误的实际测试覆盖图，原因有两个：
- 首先，单元测试并不是对你软件的全面测试。它们只是测试代码中特定的微组件是否能够正常工作。即使你的车里的所有部件都经过了测试和***的工作，也不能保证汽车会启动。
- 其次，这个指标对单元测试质量没有任何意义。一个单元测试可以包含优雅设计的代码，测试一个方法或函数的所有相关输入和输出。或者，它可能是一团乱麻，只测试其中的一些功能，或者其他无关的或已弃用的功能。用越来越多的草率的单元测试来覆盖代码对任何人都没有好处。
5自动化的百分比
在许多情况下，自动执行的测试用例百分比是一个无价值的度量标准。如果自动化测试不像旧的手工测试那样测试功能，那么越来越多的自动化测试是没有意义的。或者如果软件变化太快，自动化测试很快就会崩溃，需要完全重构。
被这个指标掩盖的另一个方面是测试持续时间。添加越来越多的Selenium测试，进行自动化UI测试是一个好主意。但是运行这些测试可以使构建时间从几分钟增加到几小时。在当前频繁发布版本的现实中，进行这样的测试需要非常谨慎，对于需要匆忙进行交付的团队就只能跳过了。
6每一个缺陷的成本
这可能是软件质量的最古老的度量标准，它早在上世纪60年代就在IBM内部使用过。改度量指标为一个bug贴上一个价格标签——识别一个bug、修复它、并验证它的成本。这个共识就是：在开发周期的早期修复bug要便宜得多，而在测试后期，或者在生产过程中，修复它们是非常昂贵的。
在开发周期的不同阶段度量每个缺陷的成本是一个很好的想法。然而，一些团队度量每个缺陷的成本，以使软件维护更有效。
主要问题是：对于软件的质量和用户的经验，缺陷有不同的含义。有些缺陷是“化妆品”，对于软件的用户几乎没什么影响。而其他的一些缺陷，如安全问题，如果不解决的话可能会带来灾难性后果。
一个软件团队可能会把注意了放在那些影响不大的缺陷上，大幅降低每个缺陷的成本，但是最终会损坏软件的质量。
7缺陷密度
缺陷密度是指软件中检测到的得到确认的缺陷数量。通常认为较低的缺陷密度等同于较低的软件质量，但这并不是真的。
缺陷密度的一个问题是，缺陷的数量取决于测试是如何构造和报告的，以及软件测试人员的技能。某个软件问题可以被当成一个bug、或者是该问题不同方面的15个bug，或者根本没有bug报告，因为测试人员没有发现它。因此，对于相同的软件，缺陷密度可能会有很大的变化。
结论
三个测试的挑战
在当今的测试世界中，有三个挑战与测试指标密切相关:
- 找到一种同时提高测试质量和速度的方法。持续测试是一种实践，它有助于提高软件质量，同时与快速迭代保持同步。在持续的测试环境中，度量标准是至关重要的，以确保软件质量真实的提高，而不是在迭代之间被侵蚀。
- 防止未经测试的代码更改流入到生产环节中。没有软件可以真正做到***的测试覆盖率(即使如上面提到的那样做到100%的代码覆盖，这也不一样。)传统的通过/失败度量不会告诉你最近的代码更改是否经过了测试。如果没经过测试，度量标准不会揭示发布这部分软件所固有的风险。
- 收集用于分析的质量指标出处单一。有大量的工具可以提供QA指示。但是它们都比较典型的集中与度量测试团队的过程和工作。其中的某些指标会如上述所说的那样不确定或者误导。今天的指标不能提供足够的、有意义的、显示软件质量趋势的信息。
真正提供有用信息，并帮助你了解软件质量的真实度量标准是很难得到的。
新的平台，如SeaLights，一个在敏捷环境中测量真实测试覆盖率的平台，通过提供更有用的测试指标和更具有代表性的软件质量来改变测试场景。具体地说，一种跨越所有类型自动和手工测试的对于测试覆盖的全面度量方法;一个“圣杯”度量，它揭示了每个敏捷版本中固有的风险。
随着敏捷的出现，软件开发已经成长起来，而测试也是如此，但是度量标准远远落在后面。最重要的是识别、评估和实践真实的度量标准能够帮助敏捷团队开发出更好的软件。
