Bug跟踪方法

对于Bug跟踪分析这块,从我个人这几年的工作经验来看,大部分测试人员一般关注的都是从新建到关闭的这条工作流程。

至于跟踪过程中和开发人员沟通过程中会遇到各种各样的问题,至于这些问题有没有一个可通用的模板。

亦或者Bug关闭后有没有进行有效的分析,是什么原因导致的,对于后续测试过程有没有什么参考价值?

后面我提到的问题,工作2-3年的测试人好像极少有考虑到的,如果每次对Bug都进行及时有效的分析,我相信对于个人成长会有很大的帮助。


 

Bug跟踪的一般流程

这里叙述一下正常我们Bug跟踪的流程都有哪些步骤:新建->修改/非Bug->验证->关闭/打回。

新建:提交问题,分配给负责人

一般给pm,由pm下发,也有直接分配给开发人员。

修改:开发解决问题

确认是问题,进行修改。如果不是问题,由一些其他因素导致,如数据之类的会非问题;有时还会让测试帮忙验证问题。

验证:测试人员对修改好的Bug进行验证

如果验证通过关闭,如果验证失败将Bug打回,一般再打回的过程需要和开发人员确认一下什么原因导致没有改好,有可能代码未更新等原因。

跟踪过程中遇到常见问题

通过上面的描述,可以看到沟通基本贯穿着整个环节,说几个常见的场景:

·开发人员提出问题下期修复

·开发人员提出问题不好修改,目前是最好的解决方案

·开发人员说明这个不是问题,但经过你的分析还是问题

以上几个问题等等之类,我有一套自己的解决方案。

先同开发个人自己沟通,尽量修改,如果实在解决不了的情况下,有个词叫向上管理,这个方法非常管用。

直接和pm沟通,最好是一类问题一起沟通,基本上90%以上的问题都能解决掉。比如在有个项目中就有这样一个问题:报表查看字段多出一列空行。

开发以之前讨论过的结果建议类问题本期不改、这个功能后续会优化,客户提出来我们再改等等。当时我就是抽空找了时间和pm对了一下,不一会儿问题就改完了,省时省力。

但是也有一个问题,开发联系人可能会对你不满意。这里怎么说呢,个人理解,作为测试人员,本着对工作负责任的态度,就要有专业的职业素养。


 

Bug原因分析

之前发生的一个Bug,大概跟踪了一个星期左右最终找到原因。这期间开发人员配合非常积极,测试也是一直在复现,最后发现解决方案比较乌龙,竟不用改一行代码......

测试过程

为了模拟出真实的测试场景,通过调用接口修改状态。在接口调用成功后,物品状态显示不正确(有时正确,有时不正确,非必现),和开发沟通~

1.0解决方案

接口调用有前提条件,注意调用时间保持比当前操作时间延后一些,好,继续测试。

还是复现问题,现象:

接口调用成功,数据库值未发生变化。

2.0解决方案

调试,更改数据库里面的值,更改不了。Sql语句查询,编辑修改不成功,发现表发生死锁,开发认为查询慢,造成的死锁,加了一下索引。继续测试发现问题又出现了。

开发继续调查

这时候问题就不好复现了,操作了很多次才复现。突然有一天,下班所有的开发把电脑关机后,数据库锁死的数据突然释放。

我们发现,因为有很多开发环境,很有可能程序进入其他人的代码里,造成数据库锁住。

这里普及一下死锁的定义:死锁是指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象。若无外力作用,它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁,这些永远在互相等待的进程称为死锁进程。


 

回顾过程

发现问题->避免问题的前置条件(屏蔽掉)->判定死锁(关键步骤)->加索引(事实证明跑偏了)->负载均衡->问题解决。

我仅仅描述了大概的过程,其中经过多少轮的验证已经没有明确的数字了。

假如和开发没有及时的沟通,单单从Bug验证次数的结果来看,很容易对这个开发做出能力上的评判,但事实上这个开发能力挺强。

在这个过程中,我理解了负载均衡基本的原理及怎么去判定数据库是否死锁的办法,这些都是测试的经验积累。

总结

所以说,怎么才能丰富自己的知识储备,最好的办法是实践

在实践过程中,发现一个问题,像挖野菜一样,一个个挖,在挖的同时不断拓展思路。

以上就是对于怎么进行Bug跟踪分析的见解,总结一下最重要的两点:

·向上管理及跟踪分析

·当然也少不了良好的沟通技巧

Bug跟踪方法

上一篇:SQL 截取字符串


下一篇:PDO进行sql语句预处理和操作结果集详细介绍(二)