lsekfe 发表于 2021-6-25 09:50:18

行之有效又自我提高的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跟踪分析的见解,总结一下最重要的两点:
  ·向上管理及跟踪分析
  ·当然也少不了良好的沟通技巧
页: [1]
查看完整版本: 行之有效又自我提高的Bug跟踪方法了解一下~