常见问题

数量相对于质量保证指标

在进入列表之前,让我们花点时间 两大类质量保证指标 -数量(绝对数)和质量(派生指标)。

量化指标(绝对数字)

定量指标正是它们听起来的样子。它们是整数,测量质量保证过程的一个方面。这里列出的一些定性指标是:

• 逃虫

• 每个要求有缺陷

• 在一定期间运行的测试数量

• 测试审查率

• 缺陷捕获率

• 每次测试的平均错误

• 测试时间

• 测试成本

• 每次错误修复费用

• 每次软件更改有缺陷

定性指标(派生数字)

量化指标本身并不能全面反映出质量保证团队的表现。例如,如果不是在说,运行的测试总数和运行每个测试的平均时间的上下文中看到的话,那么每个测试的平均错误数就不会说太多。通过将不同的相关指标相互关联,从而提供一个团队的速度、准确性或有效性的微妙描述,定性指标有助于实现这一点。

以下列出一些定性指标:

• 测试覆盖面

• 试验可靠性

• 不测试费用

• 测试执行状态

• 长期分布的缺陷

• 分辨率差

• 测试案例有效性

• 漏损

• 测试用例生产率

• 测试完成状态

• 测试审查效率

最重要的20项质量保证指标

1.脱逃虫

质量保证存在的主要原因是为了防止大多数(或者,最好是所有)错误进入生产。理想的做法是,用户在应用程序或功能开始运行后,不必检测和报告任何主要的错误。 

因此,脱逃错误的数量应该是判断整个质量保证过程的主要指标。如果您的客户没有报告任何错误,而且您的团队也不需要暂停所有操作热修复程序,这表明您的质量保证活动正在产生积极的结果。 

然而,如果主要的错误反复地逃避并扰乱用户体验,您可能需要重新考虑您的测试套件。谢天谢地,当客户报告错误时,您可以快速识别问题区域和模式,而不必重新检查整个架构。 

然而,实际上,在开始生产之前,特别是在要求发布时间表时,不可能确定并解决所有可能的错误。但是,您可以决定一个可以接受的快速修复错误的数量,不会给客户带来太多的麻烦。 

例如,如果您的团队必须在3周内发布一个新的功能,则无法保证一个完全无故障的产品。所以,花点时间来确定特性的主要目的和主要的用户路径。然后,确保错误不会扰乱它,新功能不会破坏应用程序现有的UI/UX。 

专注于解决这些问题,认为较小的错误可能会出现在插入器中,但它们不会对UX造成同样的干扰。 

最后,在判断这个度量标准时,找出主要的错误是否正在逃跑。如果是的话,您可能需要添加或修复现有的测试。

当然,您的长期目标应该是设计端到端测试套件来捕捉每个可能的错误。这需要时间,精心规划,从实际测试中学习,因此,同时,使用上面的框架进行优先排序。  

2.测试覆盖面

这个度量应该能够回答这样一个问题:"我们运行了多少测试,它们涵盖了哪些软件领域?"" 

用百分比计算,测试覆盖定义了有多少应用程序被现有测试验证。

用两个快速公式很容易计算出来:

• 测试执行=已运行的测试数量/待运行的测试总数)x100

• 所需经费覆盖面=现有测试涵盖的所需经费数目/所需经费总数)x100

第二个公式对于验证所有(或大多数)的软件特性正在由质量保证检查尤为重要。例如,如果您仅仅运行500个测试,该套件在默认情况下并不能保证高质量的产品。测试必须涵盖关键的用户路径、核心功能性能和明显的客户偏好。 

3.每项要求的缺陷(要求的缺陷密度)

监测每个需求测试中出现的缺陷数量特别有用。这一质量保证指标可以揭示某些需求是否比其他需求更有风险,这有助于产品团队决定是否应该发布这些特性。 

如果测试一个特定的需求揭示了太多的缺陷,那么它实际上可以发现需求本身的问题。当然,测试用例本身也可能需要重构,但由于测试结构的缺陷,很少出现更多的缺陷。 

例如,如果对需求A的测试产生38个缺陷,而那些对需求B的测试只产生7个缺陷,那么这是测试人员检查需求A是否需要修改测试的信号。它还表明,如果需求在当前状态下可能无法实际部署。要决定后者,就得让dv和产品经理参与进来。

4.测试努力

评估测试工作需要考虑到多个其他指标。这些子度量(可以说)反映了运行的测试数量,以及运行的时间。通常按平均值计算,测试工作量数字可以帮助您决定是否运行了足够的测试,以及是否发现了足够的缺陷。 

一些重要数字:

• 每个(持续时间)运行的测试数:执行的测试数/总持续时间

• 测试审查率:被审查的测试数量/总持续时间

• 缺陷捕获率:捕获的全部缺陷/测试总持续时间

• 每次测试的平均错误:错误总数/测试总数

5.试验可靠性

一个完美的测试套件具有以下特点:

• 错误数量与失败测试之间的密切相关性 

• 每次失败的测试都包括一个真正的错误,而不是古怪的错误

• 只有当测试中的特性完全没有故障时,测试才会通过

测试套件离上述基准越近,它就越可靠。这里有一些重要的问题:

• 测试失败是因为实际的错误,还是因为糟糕的设计?如果是,有多少人?

• 测试是不正常的吗?如果是,有多少次和多久一次?

跟踪测试的可靠性是必要的,以产生信心,相信质量保证是充分的测试软件-实际工作。和所有有效的质量保证度量一样,这一项帮助测试人员不断改进现有的测试用例、场景和实践。  

6.测试时间

这个度量显示团队或测试人员在不影响软件质量的情况下创建和执行测试的速度。 

当然,度量标准将在手动和自动测试周期之间有所不同,后者的执行速度要快得多。此外,用于质量保证的工具和框架也在测试的时间上产生了实际的变化。 

将这些数字合并起来可能很困难,因此使用以下平均数:

• 创建测试的APG时间=创建测试的总时间/创建的测试总数

• 运行测试的APG时间=测试总运行时间/运行的测试总数

一旦您有了这一质量保证团队性能度量的初始数字,您就可以整合最佳实践和升级工具来提高这两个平均值。记住,如果缩短平均时间降低了质量标准,那就没有什么意义。 

7.测试成本

大多数质量保证团队必须在特定的预算范围内工作。为了证明他们的支出是合理的,他们必须对他们计划花费多少和最终花费多少进行详细的统计。两个主要数字:

• 分配用于测试的总成本:管理层为特定时期(季度、年度等)的质量保证活动核准的金额。)

• 测试实际成本:进行必要测试的实际金额。这种计算可以包括每小时、每个测试用例或每个要求的测试费用。

例如:如果您的总分配成本是2000美元,您必须测试200需求, 

每项要求的测试费用:2000/200=10美元

每小时成本:2000/测试小时数(比如200)=100美元

每个测试用例的成本:2000/测试用例的数量(假设50)=40美元

上面的例子假设所有的需求使用相同的时间和相同的美元来测试。然而,在现实世界中,通常情况并非如此,因此,您必须相应地调整对这一质量保证指标的计算。 

8.每次修复错误的成本

简单地说,这是开发人员修复每个错误的花费。 

每一个错误修复成本=修复*开发人员每小时费率所需的时间

您还可以在测试每个错误修复时考虑到额外的英里数,这些错误修复为最终报告提供了一个更全面的数字。 

9.不测试的费用

计算不测试的成本可能看起来是违背直觉的,但这是一个很好的方法来建立必要的质量保证函数。如果您不得不为向利益攸关方提出的增加预算或聘用请求提供正当理由,则监控该质量保证指标尤为重要。 

不测试的成本指的是修复未经测试进入生产的任何功能、失败和需要修复的成本。 

您不仅可以根据为弥补缺陷而花费的开发小时数计算成本,还可以包括主观成本,例如:

• 更多时间用于客户呼叫和支持请求

• 产品停机时间

• 失去顾客信任、忠诚和品牌信誉

未经测试的特性除了简单缺乏功能之外,还会产生深远的影响。确保您可以访问客户支持和产品团队的人员,他们可以让您清楚那些影响是什么。 

10.测试执行状态

在任何给定的时间里,您都应该能够获得通过、失败、阻塞、不完整或尚未执行的测试数量的准确信息。这一指标以数字和/或百分比表示,是每日/每周报告所必需的。这也是一个团队平均效率的快速快照,因为这些数字可以与先前设定的基准进行比较。 

快速提示: 将测试执行状态数字转换为可视化辅助工具,如条形图或饼图,以便于报告。原始数据并不能有效地吸引眼球。 

11.软件更改的缺陷

通常,当添加新特性或改变现有特性时,测试这些更改就会发现以前测试中不存在的缺陷。例如,如果你在一个网页上添加了一个额外的按钮,那么测试可能会显示以前的按钮(呈现得很好)现在是歪的,而且文本已经错了。换句话说,缺陷的出现纯粹是因为一种新的变化。 

例如,如果在测试后进行了5次更改,并出现了25个错误,那么您可以为每次更改分配大约5个错误。当然,一个更改带来的缺陷总是比其他的要多。 

如果您在多个项目中研究这一质量保证指标足够长的时间,那么您就可以对每次更改会带来哪些错误做出知情的预测。有了这些数字,您的团队可以在启动新的测试周期时更好地规划时间、资源投资和可用性。 

12.缺陷随时间推移的分布

在测试周期结束时,重要的是要绘制出存在多少缺陷以及它们来自哪里。这将揭示出随着质量保证团队的工作周期越来越长,他们是否在识别和解决更多的错误方面取得了进展。 

根据缺陷的起源进行分离也有助于确定哪些领域需要更多关注。这里的一些共同分类是:

• 按原因分配的缺陷

• 按模块分列的缺陷分布

• 按严重程度划分的缺陷分布

• 按平台分配的缺陷

如果某个类别中的缺陷在增加,你就可以更容易地找到原因。例如,如果在一个平台中出现更多的缺陷,这可能表明软件需要对特定环境进行更多的优化。 

13.发现的昆虫和固定好的虫

找到的虫子和。错误固定度量是判断质量保证过程有效性的关键指标之一。它将发现的错误的数量映射到固定的数量,并提供一个平均值,客观地显示出质量保证是否在完成其主要工作。

此分析也有助于识别出现和移除错误的模式。它为缺陷管理的当前阶段提供了至关重要的见解. 

要得到这个数字,您必须首先跟踪在测试周期中每天发现和解决的错误的数量。例如,假设你有一个为期五天的测试周期,你已经收集了以下数据:

在测试周期结束时,创建/识别了17个错误,解决了15个错误。将此与以前的测试周期进行比较,您可以确定测试人员是否在发现和修复错误方面取得了更好的成绩。 

14.缺陷解决率

这个质量保证指标揭示了开发团队在分析和修复由质量保证团队报告的错误时的效率。虽然理想的情况下,解决错误不应该是一个质量保证关注的问题,但是跟踪这个数字可以帮助解释运输中的延迟--特别是对于与管理层的对话非常有用。 

为了计算这个数字,跟踪向开发团队报告的缺陷总数和在测试周期内固定的缺陷总数。然后,应用这个公式:

缺陷分辨率%=(固定缺陷总数/报告缺陷总数)x100

再次,跟踪故障解决率随着时间的推移,以验证质量保证是否为SDLC提供了预期的结果。 

15.缺陷年龄

缺陷年龄测量开发人员修复缺陷的平均时间,从缺陷何时开始实际解决到何时开始。 

错误年龄=产生错误的时间和解决错误的时间之间的差异

一般来说,缺陷年龄是用天来衡量的.我们可以说,该病毒是在2022年4月v6日v被发现的,并在2022年4月v23日被确定。在这种情况下,缺陷年龄是17天。 

逐步的低缺陷年龄是一个重要的标志,质量保证团队的成熟。这意味着在每个测试周期中修复错误花费的时间较少。 

16.测试用例有效性

这个数字以百分比来表示测试案例在检测到的错误中的有效性。换句话说,在一个测试周期中,有多少个测试用例是由您的质量保证团队执行的? 

公式很简单:

测试用例效力=(发现的错误数目/执行的测试用例数目)x100

测试用例质量的一个重要衡量标准是,测试用例的数量应该在逐步的测试周期内逐渐增加。这是质量保证团队最明显的表现指标之一。

17.漏损

漏漏似乎类似于此表中的第一项指标(即:逃脱虫)。然而,在这种情况下,您正在监控泄漏到UAT(用户验收测试)阶段的错误数量。因此,处理缺陷泄漏要比处理脱逃错误要严重得多。 

从本质上讲,这是指在应用程序经历了多层测试之后,在UAT中出现的错误数量。理想的情况是,在潜在用户接触您的产品之前,您的测试用例应该过滤掉它们。

计算如下:

漏损=(UAT中的缺陷总数/在UAT之前发现的缺陷总数)x100

18.测试用例生产率

您可能不必向管理层报告这个指标,但是衡量它有助于为您的团队设定现实的期望值。 

测试用例生产率评估为特定的冲刺/循环构建测试用例所需的努力。公式是: 测试用例生产率=(每个测试用例所需测试用例数量/工作量)x100

显然,"每个测试用例所需的努力"不会是确切的数字。某些测试用例比其他测试用例需要更多的设计工作。但是你可以要求你的测试人员提供一个公平的平均值。这个度量会让你了解你的团队在每个周期中可以完成的事情。 

19.测试完成状态

并非你的团队设计的每个测试用例都会被执行到完成。有些测试将通过,有些将失败,有些将最终没有被执行或阻塞--监测测试完成状态是整个团队表现的另一个KIP指标。 

一些不同的公式,其结果将结合起来提供测试完成状态的总体情况:

• 执行的测试用例%=(执行的测试用例数/创建的测试用例数)x100

• 未执行的测试用例%=(未执行的测试用例数/创建的测试用例数)x100

• 通过测试案例的%=(通过测试案例的数量/执行测试案例的数量)x100

• 测试失败案例%=(测试失败案例数/执行测试案例数)x100

• 被阻止的测试用例%=(被阻止的测试用例数/执行的测试用例数)x100

有了这些数字,您就可以很快地判断当前的DB2操作状态。例如,如果通过测试用例的百分比低于被阻塞测试用例的百分比,那么测试用例设计或测试环境可能存在一个基本问题。现在你知道什么问题要集中在提高下一次冲刺的结果。

20.测试审查效率

尽管测试用例可能标记了错误,但每个标记都需要测试人员进行一些检查,即使只需要几分钟--而且通常需要更长的时间。然而,根据软件及其开发阶段,测试可能会返回大量的错误。每个复习的时间加起来,这就是为什么您需要计算测试复习的效率。

测试评审效率%=(被评审的测试数量/需要评审的测试总数)x100

当然,这个质量保证度量的公式必须在一定的时间范围内应用。假设在7天的测试冲刺中,检测到58个错误,但是考虑到这些错误的性质,你的团队只能检查并转发其中的45个以便解决;你的测试检查效率为77%。

同样,这是一个很好的数字来衡量你的团队的性能,以及他们需要审查更多的缺陷。