测试人员7个悲剧且无用的kpi指标...

测试指标应该始终是有意义的、可执行的。问题是有些测试指标无法达到这一目标。许多指标都是误导，有些只是稍微还有点价值，而有些则毫无意义。

7个无用测试指标还统计？把这篇文章给老板看看！尤其是第二点！

下面这些无用的测试指标的例子可以帮助你更好地判断，你现在所用的测试指标是否能够对软件质量彻底洞察。

1.执行的测试用例的数量

这是一个糟糕得不能再糟糕的度量标准了——原因很简单，这一指标并没有告诉你测试用例到底都测试了什么。

这个度量标准的最初想法是：我们开发的测试用例越多，我们的测试就越全面。

实际上，许多测试用例根本没有对测试覆盖率做出贡献。许多测试集包含很多已弃用的测试用例，这些测试用例不再与软件的新版本相关。

测试用例的设计因为重叠，导致效率不高——毕竟本质上是在测试相同的功能。

在这些其他的情况下，拥有更多的测试用例并不是一件好事，这只等价于一个臃肿、过于复杂的测试集罢了。

2.一个测试人员发现的Bug数

这也是一个糟糕得度量标准。原因之一在于，度量任何一位测试人员的成果并不是一个好的实践——鼓励过度的竞争、破坏团队工作的协作性。

因为团队合作在敏捷中占据了相当大的分量，所以这一指标完全就是跟“更快、更好、更强”的理念对着干。

有些公司甚至会根据每个软件测试人员发现的缺陷数量来决定员工报酬——WTF——这对团队的目标尤其不利，因为它往往会抑制信息的共享，并促进“每个人都只为自己”的态度。

此外，一个员工可能在测试一个比较稳定的软件特性，而另一位在测试一个有缺陷的、不稳定的特性。

在这个度量标准下，后者会被认为绩效更好，因为他发现了更多的bug——这简直愚蠢。

3.通过率百分比

使用通过率作为度量指标这个主意不好，因为在软件开发团队中，很容易操纵这种指标——这是不鼓励的行为。

例如，测试团队可能会专注于执行更容易通过的测试，从而提高通过率。

或者，团队可以将一个长时间的测试分解成许多小的测试，人为地提高百分比的通过率。换句话说，这个指标变化无常，易于操纵。

4.单元测试代码覆盖率

代码覆盖率是另一个常用的度量指标，但是这一指标常常被错误使用。

代码覆盖率是指单元测试覆盖的代码行百分比。代码覆盖率完全可以给你一个错误的实际测试覆盖图，原因有两个：

首先，单元测试并不是软件的全面测试。它们只是测试，代码中特定的微组件是否能够正常工作。

即使你的车里的所有部件都经过了测试，可以单独、完美地工作，也不能保证汽车会启动。

其次，这个指标对单元测试质量没有任何意义。一个单元测试可以是优雅设计的代码，测试一个方法或函数的所有相关输入和输出

；或者，它可能是一团乱麻，只测试其中的一些功能，或者其他无关的或已弃用的功能。用越来越多的草率的单元测试覆盖率作为指标对任何人都没有好处。

5.自动化测试百分比

在许多情况下，自动执行测试用例百分比是一个无价值的度量标准。

如果自动化测试不像旧的手工测试那样测试功能，那么越来越多的自动化测试是没有意义的。而且当软件迭代/变化太快时，自动化测试变得相当脆弱，脚本需要完全重构。

被这个指标掩盖的另一个方面是测试持续时间。进行越来越多的Selenium自动化UI测试是一个好主意，但是运行这些测试可以使构建时间从几分钟增加到几小时。

在当前频繁发布版本的现实中，进行这样的测试需要非常谨慎，对于需要匆忙进行交付的团队就只能跳过了。

6.每一个缺陷的成本

这可能是软件质量最古老的度量标准，它早在上世纪60年代就在IBM内部使用过。为一个bug贴上一个价格标签——识别一个bug、修复它、并验证它的成本。

这个共识就是：在开发周期的早期修复bug要便宜得多，而在测试后期，或者在生产过程中，修复它们是非常昂贵的。

在开发周期的不同阶段度量每个缺陷的成本是一个很好的想法。然而，一些团队度量每个缺陷的成本的目的，是为了让软件的维护更有效。

主要问题是：对于软件质量和用户体验，缺陷有不同的含义。有些缺陷只是“一擦就掉的化妆品”，对于软件用户几乎没什么影响。而其他的一些缺陷，如安全问题，如果不解决的话可能会带来灾难性后果。

一个软件团队可能会把注意放在那些影响不大的缺陷上，虽然大幅降低了每个缺陷的成本，但是最终会损坏软件质量。

7.缺陷密度

缺陷密度是指软件中检测到的、得到确认的缺陷数量。通常认为较低的缺陷密度等同于较低的软件质量，但这并不是真的。

缺陷密度的一个问题是，缺陷的数量取决于测试是如何构造和报告的，以及软件测试人员的技能。

某个软件问题可以被当成一个bug、或者是该问题不同方面的15个bug，或者根本没有bug，因为测试人员没有发现它。因此，对于相同的软件，缺陷密度可能会有很大的变化。

结论：测试三个的挑战

在当今的测试世界中，有三个挑战与测试指标密切相关:

• 找到一种能同时提高测试质量和速度的方法。持续测试是一种实践方式，它有助于提高软件质量，同时能与快速迭代保持同步。在持续的测试环境中，度量标准是至关重要的，他需要确保软件质量能真实的提高。
• 防止未经测试的代码修改部分流入到生产环节中。没有软件可以真正做到百分百的测试覆盖率（即使如上面提到的那样做到100%的代码覆盖，也不可能真的100%测试了一个产品。）传统的通过/失败度量不会告诉你最近的代码修改部分是否经过了测试。如果没经过测试，度量标准不会展示出这部分的风险。
• 用同一种方式收集用于分析的质量指标。有大量的工具可以提供QA功能，但是它们的功能都比较典型，都集中在度量测试团队的过程和工作上。其中的某些指标，会如上述所说的那样，不确定或者误导。今天的指标不能提供足够的、有意义的、显示软件质量趋势的信息。

能真正提供有用的信息，帮助你了解软件质量的度量标准是很难得到的

随着敏捷的出现，软件开发已经成长起来，而测试也是如此，但是度量标准却远远落在后面。测试人员要有能力识别、评估和实践真实的度量标准，才能够帮助敏捷团队开发出更好的软件。