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

　　1. 当你负责的项目按时交付发布后，你老板问项目的测试质量怎么样啊？

　　2. 当你测试的项目上线后有用户曝出使用缺陷，你老板问你这个缺陷怎么没有测试出来呢？

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

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

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

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

　　· 缺陷规范

　　· 缺陷管理

　　· 质量度量

　　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 记录缺陷

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

　　下面来做个小测验：

　　2.3 修复缺陷

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

　　· 指派开发人员。指派给开发人员或其他技术人员进行修复，并将缺陷状态改为响应。

　　· 安排修复。他们将根据缺陷的优先级，创建一个修复这些缺陷的时间表。

　　· 修复缺陷。在开发团队修复缺陷的同时，测试同学根据上述时间表跟踪缺陷的修复过程。

　　· 同步修复结果。修复缺陷后，开发将缺陷状态设置成fixed。

　　2.4 验证缺陷

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

　　2.5 Reopen/关闭缺陷

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

　　2.6 统计缺陷

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

　　3 质量度量

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

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

　　以缺陷拒绝率为例，假如测试提出84个缺陷，开发测试双方认定其中20个不属于缺陷， 你可以计算出缺陷拒绝率是20/84=0.238（23.8 %）。通常来说，缺陷拒绝率值越小，测试的质量就越高。

作者：QualityAssurance21    

来源：http://www.51testing.com/html/99/n-7796399.html