分享到社交媒体:

本文首发于「BY林子」,转载请参考版权声明


“这次发布之前怎么这么多的缺陷,是不是需要分析一下啊?”

答案是肯定的,可是这个时候才想起要分析已经有点晚了,有可能这些缺陷很难分析了。这是发生过的一个真实场景,所记录的缺陷包含信息很有限,很难有效的做好分析!

本文就来聊聊如何有效的管理和分析缺陷。

缺陷是一项非常有价值的资产,软件缺陷的管理分为两个部分:缺陷信息收集和缺陷分析。

01 恰到好处的缺陷信息收集

1. 无效的缺陷记录

  • 信息繁冗

有的项目团队要求详细记录缺陷的多个维度信息,而且大部分都是必填字段,比如详细的重现步骤,对于有些特别简单的缺陷来讲是没必要的,关键是信息能够说明缺陷即可,过分详细的要求会带来更大的浪费。

曾经有个项目是在QC(Quality Center)里记录缺陷,需要填写很多必填属性字段,没有办法灵活根据具体缺陷调整,加上QC服务器在国外,访问速度非常的慢,每次记录缺陷成为了大家极其痛苦的一件事情。

  • 信息缺失

也有的项目对缺陷的格式和属性没有严格要求,记录的时候很简单也很自由,这样记录的缺陷由于很多必要信息的缺失,对后续的跟踪和分析也是极为不利。

比如前面提到的在QC里记录缺陷的那个项目,由于太痛了,很多时候,QA发现了缺陷也不愿意往QC里填,而是直接写个纸条简单记录下,验证完了它的生命周期就结束了,这样后面就没办法去很好的跟踪和分析了。(题外话:当时采用脚本往QC里记录缺陷,稍微减轻了点痛苦。)

  • 无效信息

还有一种情况就是记录缺陷时同样有一些属性要求填写,但是这些属性值可能不是那么有意义,导致存储的信息不仅没用,反而添加混乱,也是不利于跟踪和分析的。

比如,其中的“根因(root cause)”属性的值如下表所示,这些值根本就不是根因,这是一个没有意义的捣乱属性。

Root Cause
Functionality
Elaboration Defect
UI
Others
Performance
Integration
Security
Script
12197

2. 缺陷信息收集的正确做法

缺陷信息收集应该做到尽量简单,且包含必要的信息。

  • 标题:言简意赅,总结性的语句描述是什么缺陷
  • 详情:包括重现步骤、实际行为、期望结果等,根据具体情况确定其详细程度,必要时可以添加截图、日志信息等附加说明。
  • 重要属性:优先级、严重性、所属功能模块/产品、平台(OS、Web浏览器、移动设备的不同型号等)、环境、根因等,这些属性对应的值需要根据不同项目的情况自己定义,其中“根因”是相当关键的一个属性,后面有示例可以参考该属性对应的值有哪些。
  • 其他:每个项目对应的还会有其他信息需要记录的,自行定义就好。

3. 缺陷报告时机

在敏捷开发环境中,测试人员可能随时在测试、随时都会发现缺陷,包括还在开发手里没有完成的功能。什么时候发现的缺陷需要记录呢?通常情况下,有以下几种情况:

  • 开发还没完成的用户故事(story),测试人员发现缺陷只需要告诉开发修了,在该故事验收的时候一起检查就好了,无需单独记录;
  • 在开发已经完成,交到测试人员手里正式测试的故事,再发现缺陷就需要记录来跟踪了;
  • 后续的所有阶段发现的缺陷都需要记录。

02 鱼骨图缺陷分析法

比较推荐的一种缺陷分析方法是鱼骨图分析法,可以将跟缺陷相关的各个因素填写到鱼骨图里,对缺陷进行分析,如下图示:

鱼骨图缺陷分析法缺陷相关的各属性拿到了,就可以用表格、曲线图、饼图等统计各个属性对应的缺陷数量,分析缺陷的趋势和原因。下面是我在项目上做过的分析报告图:

缺陷趋势 - 功能模块 vs 环境

缺陷根因统计表和比例图

缺陷迭代趋势分析图

分析完得到统计的结果就要采取对应的措施,从而防范更多的缺陷产生。比如:

  • 修缺陷(上面示例中的“bug fixing”)引入的新缺陷比较多,可以在修复缺陷后添加对应的自动化测试;
  • 浏览器兼容性问题相关的缺陷较多的话,可以在开发完成验收的时候在各个主流浏览器上验收等等。

03 缺陷分析时机

什么时候该进行缺陷的分析也是需要搞清楚的一个问题。通常,推荐每个迭代周期分析一次,并且跟以往各个迭代进行对比,进行趋势对比。当然,有时候可能一个迭代发现的缺陷非常少,分析的周期可以适当延长,两个迭代合并分析一次也是可以的。还可能某个迭代突发紧急缺陷,那就可能需要立马分析。

缺陷记录是为更好的跟踪和分析缺陷做准备的,而缺陷分析是软件质量保证的重要环节,对于软件过程的改进,软件产品的发布来说具有十分重要的参考价值,建议各项目都把缺陷分析作为常规实践开展起来。

04 总结

缺陷记录是为更好的跟踪和分析缺陷做准备的,而缺陷分析是软件质量保证的重要环节,对于软件过程的改进,软件产品的发布来说具有十分重要的参考价值,建议各项目定期都要做做缺陷分析。


本文首发于「BY林子」,转载请参考版权声明

2 个评论

  1. 通告:构建测试的体系化思维(进阶篇) - BY林子 - 质量 - 质量内建

  2. 通告:测试基本职责 构建测试的体系化思维(基础篇) - 林子的空间

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注