越改越长的Bug跟踪流程
作者:网络转载 发布时间:[ 2013/3/12 13:52:41 ] 推荐标签:
为了能够减少二次Bug率,一般组织都有一套Bug跟踪流程用来确保Bug修改的正确性。
下面是一个典型的Bug跟踪流程。
登记Bug -> 原因分析 -> 修改方案 -> 影响性分析 -> 修改 -> 测试 -> 测试组再测试
这个Bug跟踪流程基本上会有一个较高的Bug率,我的经验显示,这个流程的二次Bug率在20%左右,即每修改10个Bug,其中有2个可能没修改完全或者是引起新的Bug。
于是,一个改进的Bug跟踪流程出现了。
登记Bug -> 原因分析 -> 修改方案 -> 方案确认 -> 影响性分析 -> 修改 -> 修改代码确认 -> 测试 -> 测试组再测试
这个新的流程改进时认为,修改方案没有经过确认是造成二次Bug的重要原因,并且,修改后的代码应该经过代码复查。
但是这个修改后的流程应用后的二次Bug率仍然在20%左右,甚至有抬高的迹象。
于是,一个更新的改进流程出现了。
登记Bug -> 原因分析 -> 修改方案 -> 方案确认 -> 影响性分析 -> 影响性分析确认 -> 修改 -> 修改代码确认 -> 测试用例书写 > 测试 -> 测试组再测试
因为,过程改进人员认为,影响性分析不足是Bug没有发现的原因之一,并且,测试范围没有留下必备的文档以便确认。
但是这个修改后的流程应用以后,二次Bug率仍然没有得到改善。
于是,大家认为,不是流程的问题,是人的问题。
—— *——*——
我们来看看是不是真的是这样的?
从第一个流程开始,之所以二次Bug率很高的原因的确是开发组的测试不充分。
而测试不充分的原因,有时间压力的成分,但是另外一个重要的原因是影响性分析不足之外。而影响性分析不足的原因是——这不是人力办得到的。几乎高手也不可能分析的很全面。这才是改进了三个流程都没有达到效果的主要原因。
第二个原因是测试只是执行了部分用例。这也是为什么即使测试组全面测试通过以后交给客户还会被发现Bug的重要原因。
既然明白这两个重要原因,那么流程的改进方式不能是延长流程。延长流程不仅没有改进效果,并且还造成工时浪费,交货期延长等问题。
所以,终制定的有效改进方案是,采用自动测试,每个Bug修改的时候都要进行全部测试用例回归。
这样之后,二次Bug率(指交给测试组验证)降到几乎为0(因为有些测试只能采用人工确认)。
自动测试的执行时间随着项目的规模不同而不同,但是整体上来讲,Bug确认的工时降低了大约80%。
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11