质量度量｜如何度量软件测试质量？

想必大家都有这样被老板灵魂发问的经历吧。

当你负责的项目按时交付发布后，你老板问项目的测试质量怎么样啊？
当你测试的项目上线后有用户曝出使用缺陷，你老板问你这个缺陷怎么没有测试出来呢？

如果测试工程师将测试工作理解为测试用例设计、测试执行，那么你大概率回答不好老板的发问，给不到老板想要的答案。

测试工程师作为项目质量把关者，是产品质量保障至关重要的一环，测试设计和执行只是其职责的一部分，殊不知，测试质量度量也是测试工作尤为重要的一环。测试质量度量的范围不仅限于测试角色，也包括开发角色，甚至是产品角色。因为产品质量不是测试同学测出来的，而是产研测三方共同努力“测试”的结果。

度量是一种工具，就像一把尺子，衡量项目测试质量的好坏，哪些地方做的好，哪些地方还需要改进。

下面就分享下测试工程师如何度量软件测试质量，我将其分为三个过程：

缺陷规范
缺陷管理
质量度量

1 缺陷规范

软件缺陷可以是编码中的缺陷，也可以是软件需求设计中的缺陷，最终都会导致软件程序运行不符合用户预期需求的结果。有过测试经验的小伙伴，大都接触过比较流行的缺陷管理工具Jira，用于记录测试过程发现的缺陷。想要做好质量度量，就一定要有被度量的元数据（缺陷数据），而缺陷自身被给予的特征维度越多，则越能将度量工作做的更细致，也能度量出更多的结果。而缺陷规范，可以简单理解为给缺陷贴不同维度标签（要素）。

1.1 缺陷要素

如上所述，理论上缺陷要素越多则度量的结果越精确，但通常会包含以下基本内容，如描述、发现缺陷的日期、发现缺陷的测试人员的名字、修复缺陷的开发人员的名字等。

缺陷ID：唯一的缺陷ID，可以根据该ID追踪缺陷
缺陷状态：一般情况下缺陷状态有：“打开/重新打开”、“待解决”、“不解决（拒绝）”、“已解决”、“已修复”、“延期修复”、“关闭”等。英文描述：Open/Reopen、un-solved、Won’t Fix、Resolved、Fixed、Deferred、Close。
缺陷标题：描述缺陷的标题
缺陷标签：用于缺陷归类
缺陷的详细描述：对缺陷的详细描述，缺陷如何复现的步骤等等，之所以把这项单独列出来，是因为对缺陷描述的详细程度直接影响开发人员对缺陷的修改，描述应该尽可能详细。
缺陷的严重程度：描述缺陷的严重程度，一般分为“致命（Critical）”、“严重（Major）”、“一般（Minior）”、“轻微（Trival）”和“建议修改（Suggestion）”等五种。

缺陷的紧急程度：描述缺陷的紧急程度，用P0-4级来定义，4是优先级最低的等级，0级是优先级最高的等级。缺陷的紧急程度与严重程度虽然是不一样的，但两者密切相关，往往的越是严重，就越是紧急；但是也存在一些情况，虽然严重等级不高，但是需要紧急修复。
缺陷提交人：缺陷提交人的名字

缺陷所属项目/模块：缺陷所属的项目和模块，最好能较精确的定位至模块
缺陷解决人：最终解决缺陷的人
缺陷处理结果描述：对处理结果的描述，如果对代码进行了修改，要求在此处体现出修改
必要的附件：对于某些文字很难表达清楚的缺陷，使用图片等附件是必要的。

2 缺陷管理

缺陷管理是一个缺陷从被发现到缺陷修复的系统过程，也叫缺陷生命周期管理。缺陷管理周期包含以下阶段：

1）发现缺陷

2）记录缺陷

3）修复缺陷

4）验证缺陷

5）Reopen/关闭缺陷

6）统计缺陷

2.1 发现缺陷

在发现阶段，项目团队必须在项目交付之前，尽可能多地发现缺陷。一个缺陷被发现且被开发认可，缺陷就变成可接受的状态，等待开发修复。

2.2 记录缺陷

发现缺陷则利用缺陷管理工作记录缺陷，缺陷描述务必详细，这样能降低开发“理解”/复现缺陷的成本。然后要对缺陷进行分类，例如缺陷严重程度分类有助于软件开发人员对其任务进行优先排序，开发人员优先修复那些非常严重的缺陷。

下面来做个小测验：

No	Description	Priority	Explanation
1	网站无法记住用户的登录会话	High	这是个严重的问题，因为用户可以登录，但无法执行任何进一步的交易。
2	网站的登录功能不能正常工作	Critical	登录是网站的核心功能之一，如果这个功能不能正常工作就是严重的缺陷。
3	网站的界面在移动设备上不能正确显示	Medium	影响到使用智能手机浏览网站的用户
4	网站页面上文字颜色不正确	Low	不影响功能使用，影响到体验

2.3 修复缺陷

修复缺陷过程开始于将缺陷提交给开发人员，然后开发人员根据优先级安排缺陷的修复，最后开发人员向测试同学同步修复结果。借助测试缺陷管理工具，例如Jira，可以管理缺陷的整个生命周期的活动，大大提升测试管理效率。

指派开发人员。指派给开发人员或其他技术人员进行修复，并将缺陷状态改为响应。
安排修复。他们将根据缺陷的优先级，创建一个修复这些缺陷的时间表。

修复缺陷。在开发团队修复缺陷的同时，测试同学根据上述时间表跟踪缺陷的修复过程。
同步修复结果。修复缺陷后，开发将缺陷状态设置成fixed。

2.4 验证缺陷

在开发团队修复并报告了缺陷后，测试团队会验证缺陷是否真的被修复了。

2.5 Reopen/关闭缺陷

一旦一个缺陷被解决和验证，该缺陷的状态就会被改变为关闭。如果没有，你要重新打开（reopen）缺陷，再次提交给开发修复。

2.6 统计缺陷

软件测试中的统计缺陷是将缺陷按照要素进行数据归类，用于缺陷度量。

3 质量度量

强调一点，缺陷度量不仅仅发生于测试结束后，而是伴随整个测试过程的。那么，测试质量度量指标有哪些呢？

汇总如下，可以看出软件测试度量范围不仅限于测试角色，还包括开发角色。

指标名称	定义	度量范围
测试执行率	（实际执行的测试用例数/测试用例总数）*100%	测试进度
测试通过率	（执行通过的测试用例数/测试用例总数）*100%	开发质量
需求（测试用例）覆盖率	（已设计测试用例的需求数/需求总数）*100%	测试设计质量
需求通过率	（已测试通过的需求数/需求总数）*100%	进度
测试用例命中率	（缺陷总数/测试用例数）*100%	测试用例质量
二次故障率	（Reopen的缺陷/缺陷总数）*100%	开发质量
NG率	（验证不通过的缺陷/缺陷总数）*100%	开发质量
缺陷有效率	（有效的缺陷/缺陷总数）*100%	测试
缺陷修复率	（已解决的缺陷/缺陷总数）*100%	开发
缺陷生存周期	缺陷从提交到关闭的平均时间	开发、测试
缺陷修复的平均时长	缺陷从提交到修复的平均时间	开发
缺陷关闭的平均时长	缺陷从修复到关闭的平均时间	测试
缺陷探测率	（测试发现的缺陷数/（测试发现的缺陷+客户发现的缺陷））*100%	测试质量
缺陷拒绝率	（缺陷拒绝修复数/缺陷总数）*100%	测试质量
缺陷逃逸率	（线上缺陷/（提交缺陷数量+线上缺陷））*100%	测试质量