行之有效又自我提高的Bug跟踪方法了解一下~

lsekfe

　对于Bug跟踪分析这块，从我个人这几年的工作经验来看，大部分测试人员一般关注的都是从新建到关闭的这条工作流程。
　　至于跟踪过程中和开发人员沟通过程中会遇到各种各样的问题，至于这些问题有没有一个可通用的模板。
　　亦或者Bug关闭后有没有进行有效的分析，是什么原因导致的，对于后续测试过程有没有什么参考价值？
　　后面我提到的问题，工作2-3年的测试人好像极少有考虑到的，如果每次对Bug都进行及时有效的分析，我相信对于个人成长会有很大的帮助。

　　Bug跟踪的一般流程
　　这里叙述一下正常我们Bug跟踪的流程都有哪些步骤：新建->修改/非Bug->验证->关闭/打回。
　　新建：提交问题，分配给负责人
　　一般给pm，由pm下发，也有直接分配给开发人员。
　　修改：开发解决问题
　　确认是问题，进行修改。如果不是问题，由一些其他因素导致，如数据之类的会非问题；有时还会让测试帮忙验证问题。
　　验证：测试人员对修改好的Bug进行验证
　　如果验证通过关闭，如果验证失败将Bug打回，一般再打回的过程需要和开发人员确认一下什么原因导致没有改好，有可能代码未更新等原因。

　　跟踪过程中遇到常见问题
　　通过上面的描述，可以看到沟通基本贯穿着整个环节，说几个常见的场景：
　　·开发人员提出问题下期修复
　　·开发人员提出问题不好修改，目前是最好的解决方案
　　·开发人员说明这个不是问题，但经过你的分析还是问题
　　以上几个问题等等之类，我有一套自己的解决方案。
　　先同开发个人自己沟通，尽量修改，如果实在解决不了的情况下，有个词叫向上管理，这个方法非常管用。
　　直接和pm沟通，最好是一类问题一起沟通，基本上90%以上的问题都能解决掉。比如在有个项目中就有这样一个问题：报表查看字段多出一列空行。
　　开发以之前讨论过的结果建议类问题本期不改、这个功能后续会优化，客户提出来我们再改等等。当时我就是抽空找了时间和pm对了一下，不一会儿问题就改完了，省时省力。
　　但是也有一个问题，开发联系人可能会对你不满意。这里怎么说呢，个人理解，作为测试人员，本着对工作负责任的态度，就要有专业的职业素养。

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

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

　　1.0解决方案
　　接口调用有前提条件，注意调用时间保持比当前操作时间延后一些，好，继续测试。
　　还是复现问题，现象：
　　接口调用成功，数据库值未发生变化。

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

　　开发继续调查
　　这时候问题就不好复现了，操作了很多次才复现。突然有一天，下班所有的开发把电脑关机后，数据库锁死的数据突然释放。
　　我们发现，因为有很多开发环境，很有可能程序进入其他人的代码里，造成数据库锁住。
　　这里普及一下死锁的定义：死锁是指两个或两个以上的进程在执行过程中，因争夺资源而造成的一种互相等待的现象。若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。

　　回顾过程
　　发现问题->避免问题的前置条件（屏蔽掉）->判定死锁（关键步骤）->加索引(事实证明跑偏了)->负载均衡->问题解决。
　　我仅仅描述了大概的过程，其中经过多少轮的验证已经没有明确的数字了。
　　假如和开发没有及时的沟通，单单从Bug验证次数的结果来看，很容易对这个开发做出能力上的评判，但事实上这个开发能力挺强。
　　在这个过程中，我理解了负载均衡基本的原理及怎么去判定数据库是否死锁的办法，这些都是测试的经验积累。

　　总结
　　所以说，怎么才能丰富自己的知识储备，最好的办法是实践
　　在实践过程中，发现一个问题，像挖野菜一样，一个个挖，在挖的同时不断拓展思路。
　　以上就是对于怎么进行Bug跟踪分析的见解，总结一下最重要的两点：
　　·向上管理及跟踪分析
　　·当然也少不了良好的沟通技巧