【软件测试】用于衡量质量保证成功的64项基本测试指标

语言 Chinese, Simplified

软件测试指标是衡量和监控测试活动的一种方法。更重要的是，它们可以深入了解您的团队的测试进度，生产力和被测系统的质量。当我们问自己“我们测试了什么？”时，指标会给我们提供更好的答案，而不仅仅是“我们已经测试过。”不同的团队根据他们想要跟踪和控制或改进的内容来衡量各个方面。

度量通常基于数据组合传达结果或预测。

结果指标：

指标主要是完成的活动/流程的绝对指标。

示例：在套件中运行一组测试用例所花费的时间

预测指标：

作为衍生工具的指标，并作为不利结果的早期预警信号。

示例：创建的缺陷与已解决的图表显示缺陷修复率。如果此速率低于所需速率，则会引起团队注意。

为何选择测试指标？你为什么要关心？

收集测试指标的目的是使用数据来改进测试过程，而不是仅显示花哨的报告。这包括找到问题的切实答案：

测试需要多长时间？
测试需要多少钱？
虫子有多糟糕？
发现了多少个错误？重新打开？关闭？延期？
测试团队找不到多少错误？
测试了多少软件？
测试会按时完成吗？软件可以按时发货吗？
测试有多好？我们使用的是低价值的测试用例吗？
测试成本是多少？
测试工作是否足够？我们可以在此版本中进行更多测试吗？

这些问题的好答案需要衡量。这篇文章包括测试人员和QA经理最常使用的64个绝对，衍生，结果和预测指标。

基本指标

作为测试人员，您的指标创建之路必须从某个地方开始。基本QA指标是绝对数字的组合，然后可用于生成衍生指标。

绝对数字

测试用例总数
通过的测试用例数
测试用例数失败
被阻止的测试用例数
发现的缺陷数量
接受的缺陷数量
拒绝的缺陷数量
延迟的缺陷数量
关键缺陷的数量
计划的考试时数
实际测试小时数
发货后发现的错误数量

衍生指标

绝对数字是一个很好的起点，但通常只有它们是不够的。

例如，如果您报告跟随网格，这可能不足以理解我们是否按计划完成，或者我们应该每天查看的结果。

Day	Day 1	Day 2	Day 3
Results Completed	35	40	45

在这种情况下，绝对数字产生的问题多于答案。借助衍生指标，我们可以深入探讨如何解决测试过程中的问题。

测试跟踪和效率

以下是有助于测试跟踪和效率的派生指标：

13.
14.
15.
16.
17.
18.
19.
20.
21.

测试努力

测试工作指标将回答有关您的测试工作的“多长时间，多少次以及多少”的问题。这些指标非常适合为将来的测试计划建立基线。但是，您需要记住这些指标是平均值。一半的价值落在平均值上，其中一半价格低于平均值。

一些具体措施是：

22.
23.
24.
25.
26.
27.

测试有效性

测试有效性答案，“测试有多好？”或“我们是否运行高价值测试用例？”它是测试集的错误发现能力和质量的衡量标准。测试有效性指标通常显示测试团队发现的缺陷数量与软件发现的整体缺陷之间的差异百分比值。

28. 基于度量：使用缺陷遏制效率的测试有效性

测试有效性百分比越高，测试集越好，长期测试用例维护工作量就越少。

示例：如果一个版本的测试有效性为80％，则意味着20％的缺陷从测试团队中脱离出来。

该数字应导致对改进测试集的调查，回顾和纠正措施，从而增加测试集的缺陷识别率。
测试有效性永远不会是100％。因此，团队应该瞄准更高的价值，如果不是100，不应该失望。
平均有效率超过版本将显示测试集改进的努力是否给出了积极的结果。

29.基于情境：使用团队评估测试有效性

在以下情况下使用缺陷控制效率指标可能不起作用

该产品已经成熟
产品不稳定且有缺陷
由于时间/资源限制，未完成足够的测试

在这种情况下，我们需要另一种方法来衡量基于意见或背景的测试集有效性。

您可以要求您的团队对测试集的评分进行评分。在您这样做之前，告诉您的团队不偏不倚并定义一个好的测试集意味着什么是很重要的。例如，您的团队可能会认为一个好的测试集应该能够充分满足高风险要求。切合实际，专注于应用程序的最关键领域。

您的团队也可以使用主观缩放方法。在100％评级（1到10分）中，请您的团队给测试集评分，以确定测试集的完整性，最新性和有效性。获得平均得分，以获得团队感知的平均测试效果。从主题专家的角度谈论哪些测试的好与坏，证明是缩小测试重点的有意义的练习。

告诉您的团队不偏不倚并定义一个好的测试集意味着什么是很重要的。

测试覆盖率

软件质量指标衡量正在测试的应用程序的运行状况。不可避免的是，您要分析的下一个核心指标集围绕着覆盖范围。测试覆盖率指标衡量测试工作量并帮助回答“测试了多少应用程序？”

例如，“在这些通过或失败的测试中，我的应用程序的工件或区域是什么，它们旨在确保我的产品以高质量生产。”以下是一些关键的测试覆盖率指标。

30.

这让我们了解了与未完成的测试运行相比所执行的总测试。它通常以百分比值表示。

31.

要获得有关测试覆盖范围的要求的高级视图，您只需要划分sprint，发布或项目的范围要求总数所涵盖的要求数量。

这通常只显示是否存在关联测试，而不是显示测试运行的结果。

32.按要求测试案例

最常见的方法是查看正在测试的功能，并查看我们与用户故事或要求一致的测试数量。

REQ	TC Name	Test Result
REQ 1	TC Name1	Pass
REQ 2	TC Name2	Failed
REQ 3	TC Name3	Incomplete

33.每项要求的缺陷（要求缺陷密度）

每个要求的缺陷密度有助于发现哪个要求比其他要求更具风险。例如，测试用例可能没问题，但要求可能是造成所有问题的原因。

Req name	Total # of Defects
Req A	25
Req B	2

34.没有测试范围的要求

重要的是要知道您是否已准备好通过适当的测试覆盖率将需求推向生产。

这表明哪些要求没有测试覆盖率以及需求处于什么阶段。例如，处于“完成”状态的要求比“待办事项”状态中的要求风险更大。

REQ ID	REQ NAME	REQ STATUS
REQ001	REQ A	To Do
REQ002	REQ B	Done

尽管更高的测试覆盖率和图表可以增加对测试工作的信心，但它是一个相对值。就像我们找不到所有错误一样，我们无法创建足够的测试来实现100％的测试覆盖率。这不是测试人员的限制，而是由于所有系统都未绑定的现实。当我们考虑字段，功能和端到端测试级别时，有无数的测试。因此，最好确定将有资格作为100％测试覆盖率限定为有限的测试库存。

在WhiteBoard Friday视频系列中了解有关充分利用软件测试指标的更多提示：重要的指标。

测试经济学指标

人员（时间），基础设施和工具有助于降低测试成本。测试项目没有无限的货币资源可供支出。因此，重要的是要知道你打算花多少钱，以及你最终花多少钱在现实中。以下是一些测试经济学指标，可以帮助您当前和未来的预算计划。

35.测试的总分配成本

CIO和QA董事为单个项目或整年的所有测试活动和资源编制的预算金额

36.实际测试成本

进入测试的实际美元时间

计算此成本的一种方法是测量每个要求，每个测试用例或每个测试小时的测试成本。

例如，如果您的预算是1000美元并且包括测试100个要求，则测试要求的成本是1000/100 = 10美元。每个测试小时的成本，100小时1000美元意味着每小时10美元。当然，这假设所有要求在复杂性和可测试性方面都是相同的。

这些数字对于充当基线很重要，有助于估算项目的未来预算。

37.预算差异

实际成本与计划成本之间的差异

38.附表差异

完成测试的实际时间与计划时间之间的差异

如果实际成本低于分配预算（负差额），这对项目来说是个好消息。但是，这也可能意味着估计不正确。方差为零是优选的。

请阅读此处了解更多信息

39.每个bug修复的成本

这是通过每个开发人员在缺陷上花费的金额来计算的

如果开发人员花了10个小时来修复错误并且开发人员的每小时费用是60美元，那么错误修复的成本是10 * 60美元= 600美元。

有些团队还会考虑重新测试的成本，以获得更准确的测量结果。

40.不测试的成本

如果一组新功能投入生产但需要返工，那么返工所需的所有费用等于未测试的成本。

不测试的成本也可以追溯到更主观的价值，例如一个人的观点。以下是未测试的主观成本的一些示例：

更多客户服务电话/服务请求
生产性停电
失去用户/客户信任等
失去客户忠诚度
品牌知名度不高

测试团队指标

这些指标可用于了解每个测试团队成员的工作分配是否统一，以及是否有任何团队成员需要更多的流程/项目知识说明。永远不应该使用这些指标来归咎于责备，而应该帮助知识共享，而不应该用它来归咎于责备。

41.返回缺陷的分布，团队成员明智 - 见解2.0

test metrics - defects returned by team member

42. 每个测试团队成员重新测试的开放缺陷的分布 - 洞察力2.0

43. 根据测试团队成员见解2.0分配的测试用例

44. 由测试团队成员执行的测试用例 - 见解2.0

通常，饼图或直方图用于快速获取工作分配的快照。下面的图表立即引起我们的注意，鲍勃超额预订，大卫未得到充分利用。这使测试主管/经理有机会研究为什么会这样，并在需要时采取纠正措施。

测试执行状态

测试执行快照图表显示组织为已通过，失败，阻止，未完成和未执行的总执行次数，以便轻松吸收测试运行状态。这些图表是日常状态会议的绝佳视觉辅助工具，因为原始数字有更高的机会滑落人们的思维。不断增长和萎缩的酒吧吸引了人们的注意力，更有效地传达了进步和速度。

45.测试执行状态图表

测试执行/缺陷查找率跟踪

这些图表有助于理解测试速率和缺陷发现率与期望值的比较。

取累积缺陷计数和测试执行率，绘制理论曲线。与实际值相比，这将触发早期的红色标记，如果要达到目标，测试过程需要更改。

46.测试执行跟踪和缺陷查找速率跟踪

变更指标的有效性

软件经历了变化 - 频繁，极少，远在中间。必须监控所包含的变更，以了解它们对现有系统稳定性的影响。变化通常会导致新的缺陷，降低应用稳定性，导致时间线滑落，危及质量等。

这些措施可以帮助我们更好地了解影

47.测试变化的影响

可归因于更改的缺陷总数。这可能意味着确保缺陷得到适当影响，并在向开发报告时附加固定视觉。将这些缺陷归类为变更相关与否，这是一种努力，但这是值得的。

48.缺陷注射率

可归因于更改的已测试更改/问题的数量

例如：如果对系统进行了10次更改，并且30个缺陷可归因于更改，则每次更改最终会注入三个缺陷，并且每次更改的缺陷注入率为3。

知道这个数字将有助于预测每次新变化可能出现的缺陷数量。这允许测试团队战略性地使用回顾会议来了解他们帮助识别和修复来自新变更的缺陷的能力。

缺陷分布图

缺陷可以根据类型，根本原因，严重程度，优先级，模块/组件/功能区域，平台/环境，负责测试人员，测试类型等进行分类。您团队的权利如何设置完整的精细分类列表用于缺陷报告。

缺陷分布图有助于理解分布并确定目标区域以最大程度地去除缺陷。通过使用直方图，饼图或帕累托图表来显示开发和测试工作的位置。

49.由于原因导致的缺陷分布

50.模块/功能区域的缺陷分布

51.严重程度的缺陷分发

52.按优先顺序分配的缺陷

53.按类型分发缺陷

54.测试人员（或测试人员类型）的缺陷分布 - Dev，QA，UAT或最终用户

55.按测试类型分发缺陷 - 审查，演练，测试执行，探索等。

56.平台/环境的缺陷分发

直方图或饼图显示对高度受影响区域的即时视觉识别。但是，当参数太多而没有难以辨别的模式时，您可能必须使用帕累托图。缺陷

分配饼图：

这仅用于一个目的。它可以帮助您快速找到最密集的区域（大多数缺陷的原因）。

缺陷分布直方图：

创建直方图时，请务必将数据值从高到低或从低到高组织起来以产生最大影响。

test metrics - defect distribution histogram

您可以在此处停止，但要从指标中获得更多信息，请继续执行下一步。

将直方图与每个原因中的缺陷严重性分布相结合。这将为您提供您应该更准确地关注的领域。

例如：我们知道造成大多数缺陷的区域是用户数据输入，但仅仅因为计数很高，我们不必首先关注那个，因为大多数“用户数据输入”都很低（绿色）。缺陷数量最多且严重问题较多的下一类是“代码错误”。因此，此图表将改进我们的数据，并让我们更深入地了解在何处引导进一步开发和修复工作。

缺陷分布帕累托图：

您还可以创建一个帕累托图表来查找哪些原因可以解决大多数缺陷。在大多数情况下，可能不需要帕累托图。但是，如果原因太多而且直方图或饼图不足以清楚地显示趋势，那么帕累托图可以派上用场。

要知道要关注哪些原因以便以最少的工作来修复最大缺陷（或者20％的原因可以修复80％的缺陷），在辅助轴上绘制一条80％标记的线并将其放到 X轴，如下：

导致用户数据输入和代码错误的原因应该比其他更重要。

随着时间的推移缺陷分布图表

测试周期结束时或测试周期中某一点的缺陷分布是该时间点缺陷数据的快照。如果事情变得更好或更糟，它不能用于得出结论。例如：在某个时间点，您将知道X个严重错误。我们不知道X是否超过最后一个周期或更少或相同。

随着时间的推移，您将了解每个类别中的缺陷。我们可以看到缺陷是否随着时间的推移或过度释放而增加，减少或稳定。

随时间的缺陷分布是多线图，显示一段时间内每个原因/模块/严重性趋势的缺陷。

57.原因导致的缺陷分布

58.模块随时间的缺陷分布

59.严重程度随时间的缺陷分布

60.平台随时间的缺陷分布

对于以下数据：

Test Cycle	Code Error	Security Problem(access permissions)	User error(data entry)
Cycle 1	8	4	15
Cycle 2	7	3	13
Cycle 3	1	5	9
Cycle 4	1	5	4
Cycle 5	0	4	1

在5个周期内绘制3个原因的多线图，如下所示：

以下是图表可以帮助我们理解的内容：

最初的两个周期中的代码错误一直很高，但是从第3周期开始显着下降并保持低水平。这表明开发工作的有效性。
用户数据输入错误已从初始版本中暴露出来;这表明用户对产品的熟悉程度和接受度增加
随着测试周期的进行，安全相关的缺陷保持稳定并且没有改善（即数量减少）。这意味着，这些必须作为优先事项处理和处理。

限制：

对于负趋势，即对于发布/测试周期，如果缺陷计数在特定原因类别中增加，则此图表告诉我们这是什么，但不告诉我们原因。
当工作原因很少时，它是最有效的。想象一下，这个图表有10个原因类别，而不是3个，这将是太多的线条使它太繁忙和难以解释。

创建缺陷与缺陷已解决图表

61.缺陷创建与缺陷解决图表

找到的错误与固定图表相比，是一个缺陷分析折线图，可让我们查看缺陷删除过程模式并了解缺陷管理的有效性

要开始创建固定与发现图表，您必须先收集编号。发现的缺陷和没有。每天在测试周期中解决的缺陷。这是需要累积数字才有意义的图表之一。在10天的测试周期中考虑以下缺陷数据：

Test Cycle 1- Date	Bugs created	Bugs resolved	Cumulative bugs created(Total no. of bugs created so far)	Cumulative bugs resolved(Total number of bugs resolved so far)
10/10/2016	6	4	6	4
10/11/2016	3	0	9	4
10/12/2016	4	4	13	8
10/13/2016	2	4	15	12
10/14/2016	2	3	17	15
10/15/2016	0	0	17	15
10/16/2016	1	0	18	15
10/17/2016	0	2	18	17
10/18/2016	0	2	18	19
10/19/2016	0	0	18	19

针对上述数据创建的缺陷与已解决的图表如下所示：

这张图很棒，但有太多的线条让我们分心。因为创建和解决的错误的原始数量是没有意义的，您可以从图表中删除它们以获得更清晰的创建与已解决的图表，如下所示。

此图表回答了以下问题：

我们准备好了吗？
软件是否在测试结束时获得稳定性？
缺陷管理系统是否有效？

这是如何做：

1.在测试周期结束时，绿线变得更直，更平坦或更稳定 - 这表明错误发现率已经下降，累积错误数量不变 - 因此，它有助于我们回答问题 - “我们测试的足够吗？ “或”产品是否已准备好发货？“

如果绿线越来越陡峭，这意味着即使在测试结束时，找到错误的速度也没有下降。因此，需要进行更多测试，产品尚未发货。

2.在曲线的末端，创建和解析的线会聚（或多或少）。这也是一个好兆头，因为它表明缺陷管理过程正在发挥作用并且正在有效地解决问题。

如果蓝线低于绿线，则意味着缺陷未及时解决，我们可能需要改进流程。

限制：虽然此图表回答了许多重要问题，但它确实有其局限性。

绿色线中的尖峰可能在测试周期开始时发生，此时错误发现率通常很高。当开发团队完成所有缺陷并将其中的大部分标记为已完成时，也可能出现蓝线尖峰。这可能会导致对正在发生的事情的一时的恐慌。
该图表显示了正在发生的事情，但需要进一步研究以了解“为什么”。

参考文献：

https://confluence.atlassian.com/jira064/created-vs-resolved-issues-rep…

管理测试过程 - 由雷克斯黑色。第4章“缺陷去除的进展情况”。

http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470404159.html