想必大家都有这样被老板灵魂发问的经历吧。
- 当你负责的项目按时交付发布后,你老板问项目的测试质量怎么样啊?
- 当你测试的项目上线后有用户曝出使用缺陷,你老板问你这个缺陷怎么没有测试出来呢?
如果测试工程师将测试工作理解为测试用例设计、测试执行,那么你大概率回答不好老板的发问,给不到老板想要的答案。
测试工程师作为项目质量把关者, 是产品质量保障至关重要的一环,测试设计和执行只是其职责的一部分,殊不知,测试质量度量也是测试工作尤为重要的一环。测试质量度量的范围不仅限于测试角色,也包括开发角色,甚至是产品角色。因为产品质量不是测试同学测出来的,而是产研测三方共同努力“测试”的结果。
度量是一种工具,就像一把尺子,衡量项目测试质量的好坏,哪些地方做的好,哪些地方还需要改进。
下面就分享下测试工程师如何度量软件测试质量,我将其分为三个过程:
- 缺陷规范
- 缺陷管理
- 质量度量
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% | 测试质量 |
以缺陷拒绝率为例,假如测试提出84个缺陷,开发测试双方认定其中20个不属于缺陷, 你可以计算出缺陷拒绝率是20/84=0.238(23.8 %)。通常来说,缺陷拒绝率值越小,测试的质量就越高。
我们通过上述指标可以窥探测试/开发在项目中存在的问题(效率问题、质量问题等),用于提出解决方案,并最终提升项目效率和质量。这时候你也许会问了,测试同学要掌握的技能好多啊,不仅要会测,还要知道如何管好”测“,更要会分析,整个项目都要参与进来协调产研同学啊,妥妥就一项目经理(PM),啥都要管哦。
HAHA,那可不是嘛,优秀的测试工程师就是优秀的PM啊。