缺陷分析:缺陷漏斗模型 | 让一个缺陷都不能漏

2018-09-21   出处:软件测试资源站  作/译者:马蚁蛋  



「缺陷分析主要不是解决缺陷,而是防止缺陷的再次发生。正如我们应该提高自身身体素质,防止生病,而不仅仅是治病。」


做缺陷分析需要投入不少的人力和时间,所以在缺陷分析之前首先我们必须明确我们为什么要做缺陷分析,缺陷分析能给我们带来什么。是效率的提升还是开发质量的提高。


接下来我们要确定缺陷分析的粒度,如果粒度太大,无法分析出具体有用的结果,如果粒度太小,投入的人力时间太多,与最终得到的成效相比,代价过大。


缺陷分析主要不是解决缺陷,而是防止缺陷的再次发生。正如我们应该提高自身身体素质,防止生病,而不仅仅是治病。

进行缺陷分析首先我们要从缺陷的来源下手。



来源主要分成两类:


1.产品发布以后的缺陷


数据:产品发布以后的缺陷主要来源于用户报的问题,当然也有一部分是自己内部员工发布的问题,可以是产品经理,测试,开发或者其他的员工。


目的:分析这部分缺陷能让我们知道我们测试工作中的不足,找到相关的原因,提高测试工作的质量。同时,可以发现用户遇到的问题,在之后的开发工作中避免这种问题再次出现,提升用户体验。


指标:计算出平均修复时间指标,知道我们维护阶段处理缺陷的效率。提高效率,提升用户的满意度。


2.产品发布之前的缺陷


数据:产品发布之前的缺陷主要来源是测试开的bug。


目的:分析这部分的缺陷,能发现需求上描述不清楚或者不合理的地方,编码容易出错的地方,流程上不合理需要改进的地方,软件薄弱的地方等。我们逐个击破,提高整个开发团队的素质。


指标:同时通过缺陷分析,计算出缺陷指标,评估风险以及开发阶段软件的质量和需要的工期。



下面我们要重点介绍的缺陷分类方法叫漏斗模型缺陷分析法。


模型从上到下是一个逐渐缩小的过程,让我们从一开始的缺陷到最后找到导致这个缺陷的部门和生产过程,以便有针对性的进行改进。


模型从右到左是生产的反向过程,在右边的生产活动如果缺陷过多,就会掩盖掉其左边的生产活动,我们必须先解决掉右边活动存在的问题,减少它产生的缺陷,这样才能看到模型左边的生产活动存在的问题。


模型如下图,绿色的是缺陷的分类,蓝色的是生产活动,红色的是对应的责任职位。


我们如何利用这个模型进行分类呢。可以分为以下几步。


1.对缺陷进行分类


把所有的缺陷按照模型的最上面一层进行分类。如果是老的缺陷,那会比较麻烦,需要重新分析老的缺陷,然后给老的缺陷分类。如果打算忽略老的缺陷,直接在之后的缺陷里进行统计,那可以直接在创建缺陷的时候加入一栏“缺陷类别”,而类别就是模型里的第一层,之后的统计中就会方便很多。


2.计算出每个类别的缺陷数目,然后对应到生产活动。


我们的生产活动主要有:

-- 编写需求

-- 理解需求

-- 系统设计

-- 编码

-- 设计测试用例

-- 功能测试

-- 回归测试

-- 性能测试

-- 实施


然后按照缺陷个数的高低进行分析每一个生产行为,分析产生缺陷的原因,是因为人还是因为制度还是因为流程。然后进行相应的改进。


以我目前的一个项目来举例,首先我提取了最近一个月发布前的缺陷。(这里主要的是,缺陷数目越多,能发现的问题更多,也更具有代表性。我这里取一个月的缺陷,只是为了说明,因为数据量太小实际参考效果不佳。)




先根据缺陷类别统计每一个类别的缺陷个数,然后对应到生产活动。


我们发现排名第一的是编码,第二的是需求,需求产生的缺陷个数居然有29个,占比32.6%。需求的缺陷占比如此之高是不太常见的。


从另一方面来说如果解决了需求这一块存在的问题,在效率的提高和产品质量的提高上会有很大的帮助。一般如果是由于需求导致的缺陷,如果找到原因并且采取有效措施后会比较容易在以后的工作中避免。


那我们来具体分析下为什么会有这么多需求的缺陷。需求缺陷中,其中主要的问题是需求描述不清楚,其次是多语言翻译,最后是用户体验。 


需求为什么会描述不清楚,一是因为产品人员没有真正理解产品,很多情况没有考虑全面。 二是描述语言不够清晰,逻辑不够清楚。三是业务上没弄清楚真正需要的是什么。对于第一点,一方面产品人员要加强对于自身产品的理解,测试人员也可以在这方面给产品人员把关,尽量保证需求考虑足够全面。 对于第二点,产品人员在写需求的时候尽量理清思路再写。对于第三点,这一点比较难,需要产品人员多提升专业知识。 


对于多语言翻译,一开始产品人员就应该明确哪些语句需要支持多语言,并且列在一个表里,保证他们都翻译了。而不是通过测试,发现问题,报告缺陷,然后解决,再去验证。这样对于测试资源是一张浪费,特别是在测试资源紧缺的时候,更是雪上加霜。


对于用户体验方面,希望产品人员多提升在用户体验方面的认知,在设计产品的时候时刻注意,不能是一拍脑门做决定。

总结下来。对于需求产品的缺陷,只要产品人员在平时工作中多加注意,相信这一方面的缺陷会少很多。整个组的效率也会提升很多。


接下来我们来分析下编码导致的缺陷,编码导致的缺陷中占比比较大的是,逻辑错误,遗漏功能,和不同组直接的依赖。这里面我们能努力的方面是遗漏功能和不同组之间的依赖。


遗漏功能一方面是对于需求没有了解清楚,另一方面是没有考虑全面,比如特殊的数据处理,特殊场景的处理等。改进的方向是,在做之前确认自己是否真的理解了需求,还有就是积极参加测试用例评审大会,听一听测试人员的测试用例,看自己有什么遗漏的地方。 另外就是自己整理一份特殊数据,特殊场景的情况,每次做到有关的内容的时候,都提醒下自己是否考虑到了。


不同组之间的遗漏,在于组之间的不透明。对于相互影响的模块,可以考虑创建一个组之间模块依赖表,每一个组设置一个接头人,一旦有依赖的模块发生变化了立刻通知到其他组。对于上下游的模块,每次下游测试前要和上游确认所有的需要的准备工作已经完成。


前面的这些分析都是按照缺陷个数进行的分析。当然有些缺陷个数很少,可是影响却很恶劣,对于这种缺陷我们必须强烈避免,按照漏斗模型找到对应的生产活动对应的负责人,case by case的处理。坚决避免此类情况再次发生。


在我们日常的工作中,大家对于缺陷分析的重视度并不够。一方面是不知道该如何利用缺陷的价值,如何进行分析,另一方面是记录的缺陷不规范,要进行缺陷分析难度太大。


我所处的项目组由于业务多,时间上紧,所以大家都很忙很累,大家都意识到流程上业务上存在问题,可是却无法知道具体问题出在哪里,如何改进,更没有数据可以用来说服老板或者其他人进行改变。直到某天我意识到,缺陷就是开发过程的产物,它最能说明我们的开发过程到底存在什么问题,然后我就开始进行缺陷分析,不过一开始没想好从哪个维度入手,也不清楚缺陷该如何分类,分类的粒度应该多大。


于是慢慢的尝试,最终整理出来的漏斗模型里面列的那些分类,因为整个图很像漏斗加上分析的过程就像用漏斗一样,一遍遍的过滤信息,最终找到根本问题,所以我把它叫做漏斗模型。希望大家能从我这篇文章中得到帮助


如何学习?学习没有资料?请关注本公众号,回复「M」试试,获得更多视频资料和入群资格。




【声明】:上文为本站编辑转载,文章版权归原作者所有。文章内容为作者个人观点,本站只提供转载参考,目的在于传递更多专业信息,普惠测试相关从业者,开源分享,推动行业交流和进步。如涉及作品内容、版权和其它问题,请原作者及时与本站联系,我们将第一时间进行处理。本站拥有对此声明的最终解释权!   


欢迎给测试窝投稿或参与内容翻译工作,请邮件至editors@testwo.com。也欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,并与我们的编辑和其他窝友交流。
161°|1614 人阅读|0 条评论

登录 后发表评论
最新文章