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