测试质量的量化指标

不知道如何度量，就不知道这个东西的好坏。所以测试人员，测试团队和测试经理们都费劲心机去搜集比较好的测试度量指标。以此来改进自己的测试工作。通过长时间度量一个测试指标，绘制对应的曲线，同时指定基准，来找到改进自己测试团队的工作。

有哪些类型的测试指标?

在深入研究无数的特定指标列表之前，先来看看常见的测试指标有哪些？

测试覆盖率——帮助了解应用程序的哪些区域已经被测试了。在测试质量良好的前提下，该指标可以揭示软件的哪些部分发现了已知的缺陷，哪些部分还存在未知的缺陷。覆盖率对应一组指标。有需求覆盖率，测试用例覆盖需求类别，单元测试覆盖率，集成和API测试覆盖率，UI测试覆盖率，手动或探索性测试覆盖率，等等。

测试跟踪和效率——证明测试在好好干活。度量包括通过/失败测试用例的百分比，接受/拒绝缺陷的百分比，以及所有缺陷的关键缺陷的百分比。

测试投入时间——关于测试工作的基本事实可以帮助建立未来测试计划的基线。度量标准包括运行的测试数量、每测试小时的缺陷和测试错误修复的平均时间。

缺陷分布——帮助了解软件或过程的哪一部分最容易受到缺陷的影响，因此应该将测试工作集中在哪里。度量标准包括缺陷的数量、百分比或严重程度，这些缺陷是按严重程度、优先级、模块、平台、测试类型、测试团队等类别分布的。许多团队在每个构建或者在测试周期的末尾测量缺陷分布。观察一段时间后的分布，就有可能看到有问题的类别是更好、相同还是更差。

测试执行——测试活动的基本度量，它记录了实际执行了多少测试，以及有多少测试被分类为通过、失败、阻塞、不完整或未执行。测试执行的一个主要好处是很容易被测试团队可视化和理解。度量包括测试执行状态、测试运行结果和按天划分的测试结果。

回归——对软件的更改增加了功能，但通常会引入新的缺陷，降低应用程序的稳定性，并危及质量。这种类型的度量有助于理解在不损害现有用户体验的情况下，更改在解决用户关注点方面的有效性。度量包括缺陷注入率和每个构建/发布/版本的缺陷。

测试团队度量——该度量团队或团队成员的测试工作分配和测试输出。专家建议，永远不要使用这些指标让单个测试人员相互竞争，而是将其作为一种跟踪单元内进度和学习的方式。度量包括发现的缺陷的分布，每个团队成员返回的缺陷，以及每个团队成员分配的测试用例。

测试经济指标-测试每个员工的产出，测试中使用的工具和基础设施。这些度量可以帮助计划测试活动的预算和评估测试的ROI。度量标准包括测试总成本、每个错误修复的成本和测试预算差异。

测试度量和软件质量度量之间的区别是什么

测试度量提出的问题是“测试有多好?”

软件质量度量提出的问题是“软件有多好?”

下面是一些软件质量度量的例子——它们不评估测试度量，它们只评估软件的质量。

可靠性——指的是软件产品固有的风险水平和它失败的可能性。这个度量标准与“稳定性”相关，正如ISO所定义的那样:当进行更改时，软件中存在回归的可能性有多大?

性能——在CISQ软件质量模型中，这方面被称为“效率”。通常，软件的性能取决于它的源代码是如何编写的，它的软件架构，该架构中的组件(数据库，web服务器等)和它的可伸缩性选项。

安全性——安全性(在软件质量的环境中)反映了攻击者由于糟糕的编码实践或架构而破坏软件、中断其活动或获取敏感信息的可能性有多大。一个核心概念是“漏洞”——可能导致安全问题或漏洞的已知问题。在系统中发现的漏洞的数量和严重程度是其安全级别的重要指标，并且通常是推迟发布和修复漏洞的原因。

可维护性和代码质量——软件可维护性衡量软件适应其他用途的难易程度，它在环境之间的可移植性，以及它是否可以从一个开发团队或从一个产品转移到另一个产品。可维护性与代码质量密切相关。如果代码是高质量的，软件可能更容易维护。

交付速度——在敏捷开发环境中，软件的新迭代可以快速交付给用户。这是敏捷思维中软件质量的衡量标准，因为软件交付的频率越高，

在不同的组织级别使用哪些度量标准?

在软件项目级别，开发团队可能会跟踪:

需求和需求覆盖——不同类型的测试实际上覆盖了多少用户遵循的工作流?

缺陷分布——在软件的不同部分发现了多少缺陷?随着时间的推移是否有进展?

缺陷打开和关闭的速度——发现一个缺陷需要多长时间，开发人员在测试过程中注意发现的缺陷的速度有多快?

测试执行趋势——哪些测试是由QA团队的特定成员执行的，哪些是由自动化测试框架或服务器执行的?

燃尽图——这是开发团队必须完成的工作量的可视化图。如果测试是一个单独的活动，燃尽图可以帮助管理层可视化他们距离完成一个版本的测试范围有多近。在敏捷团队中，开发和测试是一个统一的任务——一个故事在测试之前是不会完成的——所以燃尽图同时反映了开发和测试活动。

在部门级别，负责开发和测试的组织单位的领导可能会跟踪:

MTTD（Mean Time To defect)和MTTR(Mean Time to Recovery)——总的来说，组织检测缺陷的平均时间是多少，从影响软件用户的缺陷中恢复的平均时间是多少?

缺陷移除效率——在开发周期中有多少缺陷被识别，有多少被实际修复?

测试和缺陷趋势——在几个月到几年的跨度内，测试活动和缺陷的性质是如何随时间演变的?软件质量在提高吗?我们是否检测和解决了更大比例的缺陷，产品的成熟度和稳定性是提高了还是恶化了?

在公司层面，首席执行官、首席财务官、首席营销官或首席运营官可能会跟踪以下指标:

客户报告或体验的问题——影响组织客户的质量问题有多少，什么样的质量问题?随着时间的推移，这可以提供关于软件质量如何影响用户的“底线”洞察。

缺陷严重程度——在多个项目或产品中，缺陷对用户的影响有多严重?在发现和解决这些缺陷上投入了多少时间，这些时间是否被有效地花费了?例如，组织可能会发现某些产品或项目需要更多的测试资源，因为它们表现出更严重的缺陷，会损害客户满意度和收入。

MTTR和MTTD——在组织层面，发现和响应影响客户的缺陷需要多少时间?

系统中断和停机时间——系统运行中断的频率和持续时间?随着许多软件公司过渡到SaaS交付模型，这些指标变得越来越重要。

在发布前/发布后修复bug的成本——在软件版本发布前和发布后修复发现的问题花费了多少精力?众所周知，bug发现得越晚，解决它们的成本就越高。这个度量可以帮助组织了解在生产中修复一个错误的成本有多高，并且通过扩展，更好的测试来更早地发现缺陷的ROI。

瀑布与敏捷环境中的度量

瀑布模型采用一种非迭代的开发方法，每个阶段都需要在下一个阶段开始之前完成。

在传统的瀑布环境中，测试指标包括:

产品质量——一旦开发接近瀑布式项目的末尾，就会有一致的努力来测试和稳定软件，以达到能够交付给用户的质量水平。

测试有效性——测试有高价值吗?测试团队在发现相关缺陷并帮助开发团队理解和解决它们方面的能力如何?

测试状态——计划了多少测试，运行了多少测试，还有多少测试?

测试资源——在测试组织中，产品或项目有哪些可用的资源，它们的使用情况如何?

在敏捷环境中，一些适用于测试的通用开发指标是:

冲刺燃尽图——帮助团队可视化当前迭代中剩余的工作，以及扩展，还有多少测试需要完成。

工作测试功能/运行测试功能的数量——持续添加到软件中并进行充分测试的功能或敏捷“故事”越多，项目就越健康。

速度——开发团队完成新功能的速度。更快的进展是可取的，但应该与监测技术债务相结合，以确保团队不会在跳过最佳实践或留下质量差距的情况下竞相完成功能。

累积流程——帮助可视化敏捷过程中的瓶颈。特别是，帮助团队可视化测试资源是否足够，以及测试是否放慢了开发周期。

挣值分析——一种成本估计方法，可以帮助确定软件测试作为一个整体的经济价值，以及在单个任务级别上，特定测试是否具有成本效益。

一些具体的敏捷测试指标包括:

自动化测试覆盖率的百分比——度量由自动化测试实现的测试覆盖率占手动测试和自动化测试总数的百分比。这表明了敏捷组织的成熟。

代码复杂度和静态代码分析——使用圈复杂度或其他形式的自动化分析来衡量代码质量。

在生产中发现的缺陷/已逃逸的缺陷——统计在发布日期之后发现的给定发布的缺陷。显示交付给最终用户的软件质量的“底线”指标。

缺陷类别——按组划分的缺陷数量;比如功能错误、通信错误、安全漏洞、性能缺陷。他可以帮助敏捷团队确定导致最终用户80%问题的帕累托20%缺陷。

缺陷周期时间——度量从开始修复一个缺陷到完全解决该缺陷之间所经过的时间。敏捷控制图可以帮助直观地表示敏捷周期内解决任务的速度。

缺陷溢出——度量在给定的冲刺或迭代中没有得到解决的缺陷的数量，以及从一个冲刺溢出来的缺陷的数量，以便在下一个冲刺中得到解决。

手动测试和自动测试使用哪些测试指标?

测试自动化已经席卷全球，人们普遍认为，如果没有广泛的自动化测试，敏捷开发将是不可能的。然而，仍然存在手动测试的空间。对于敏捷团队来说，将关键的验收测试、复杂或敏感的用户故事交给人工测试和分析是很常见的。

传统上，不同的度量标准被用于测试手动和自动软件测试。

手动测试指标

测试用例执行——测试团队或单个测试人员在特定的软件版本上运行了多少测试用例?

测试用例准备——设计了多少测试用例脚本来覆盖软件功能?

缺陷度量——关于年度测试人员发现的缺陷数量和性质的各种度量，包括:

• 缺陷优先级

• 缺陷严重程度

• 缺陷逃逸率——在软件发布之前，手工测试人员无法识别的缺陷的百分比。

测试自动化度量

测试总持续时间——运行自动化测试所需的时间。这很重要，因为测试通常是敏捷开发周期中的瓶颈。

单元测试覆盖率——度量单元测试覆盖了多少软件代码。这个指标给出了软件代码库被广泛测试的大致近似值。

路径覆盖——测试覆盖的线性无关路径的测量。路径覆盖需要非常彻底的测试;程序中的每条语句都至少执行一次，覆盖全路径。

需求覆盖——显示测试了哪些特性，以及有多少测试符合用户描述或需求。测试自动化成熟度的一个非常重要的度量，因为它跟踪交付给客户的特性中有多少是由自动化覆盖的。

通过或失败的测试百分比——统计最近通过或失败的测试数，占计划运行的测试总数的百分比。该度量提供了测试进度的概述，这很容易在构建、发布或时间段之间进行可视化和比较。

在测试中发现的缺陷数量——在测试执行阶段遇到的有效缺陷数量的度量。捕获软件版本与以前版本相比的“糟糕程度”。对预测建模也很有用。

总覆盖率的%自动化测试覆盖率——与手动测试相比，这个指标报告了自动化测试实现的测试覆盖率的百分比。帮助量化测试自动化计划的进展。

测试执行——作为构建的一部分执行的测试总数。这是一个重要的统计数据，用于了解自动化测试是否按预期运行并汇总其结果。

有用和不相关的结果——比较自动化测试的有用结果和不相关的结果，不相关的结果可能是由破坏测试的软件更改、测试环境的问题等引起的。

生产中的缺陷——许多敏捷团队将此作为自动化测试效率的“底线”:在软件发布后，在生产中发现了多少严重的问题。

被破坏的构建百分比——度量由于自动化测试失败而破坏的构建的数量，以及工程师提交到共享代码库的代码质量。

不稳定测试的数量——“不稳定”测试是指使用相同的代码和相同的配置可能显示通过和失败结果的测试。不可靠的测试可能对开发人员有害，因为失败并不总是表明代码中的错误，寻找根本原因是浪费时间。

结论:朝向一个整体测试指标

有许多测试指标。选择正确的度量标准，遵循它们并采取措施来改进它们，这是成功的软件测试操作的关键。我们简要概述了几个维度的测试指标——测试类型、组织使用、瀑布测试与敏捷测试、手动测试与自动化测试。

我们相信今天的开发和QA团队需要一个唯一的数据来源，它可以量化测试质量和软件质量的最重要方面。根据我们的经验，拥有一个单一的、整体的仪表盘可以对软件测试活动的学习过程和实际性能产生巨大的影响。