对于Bug跟踪分析这块，从我个人这几年的工作经验来看，大部分测试人员一般关注的都是从新建到关闭的这条工作流程。
至于跟踪过程中和开发人员沟通过程中会遇到各种各样的问题，至于这些问题有没有一个可通用的模板。
亦或者Bug关闭后有没有进行有效的分析，是什么原因导致的，对于后续测试过程有没有什么参考价值？
后面我提到的问题，工作2-3年的测试人好像极少有考虑到的，如果每次对Bug都进行及时有效的分析，我相信对于个人成长会有很大的帮助。
Bug跟踪的一般流程
这里叙述一下正常我们Bug跟踪的流程都有哪些步骤：新建->修改/非Bug->验证->关闭/打回。
新建：提交问题，分配给负责人
一般给pm，由pm下发，也有直接分配给开发人员。
修改：开发解决问题
确认是问题，进行修改。如果不是问题，由一些其他因素导致，如数据之类的会非问题；有时还会让测试帮忙验证问题。
验证：测试人员对修改好的Bug进行验证
如果验证通过关闭，如果验证失败将Bug打回，一般再打回的过程需要和开发人员确认一下什么原因导致没有改好，有可能代码未更新等原因。
跟踪过程中遇到常见问题
通过上面的描述，可以看到沟通基本贯穿着整个环节，说几个常见的场景：
·开发人员提出问题下期修复
·开发人员提出问题不好修改，目前是最好的解决方案
·开发人员说明这个不是问题，但经过你的分析还是问题
以上几个问题等等之类，我有一套自己的解决方案。
先同开发个人自己沟通，尽量修改，如果实在解决不了的情况下，有个词叫向上管理，这个方法非常管用。
直接和pm沟通，最好是一类问题一起沟通，基本上90%以上的问题都能解决掉。比如在有个项目中就有这样一个问题：报表查看字段多出一列空行。
开发以之前讨论过的结果建议类问题本期不改、这个功能后续会优化，客户提出来我们再改等等。当时我就是抽空找了时间和pm对了一下，不一会儿问题就改完了，省时省力。
但是也有一个问题，开发联系人可能会对你不满意。这里怎么说呢，个人理解，作为测试人员，本着对工作负责任的态度，就要有专业的职业素养。
Bug原因分析
之前发生的一个Bug，大概跟踪了一个星期左右最终找到原因。这期间开发人员配合非常积极，测试也是一直在复现，最后发现解决方案比较乌龙，竟不用改一行代码......
测试过程
为了模拟出真实的测试场景，通过调用接口修改状态。在接口调用成功后，物品状态显示不正确（有时正确，有时不正确，非必现），和开发沟通~
1.0解决方案
接口调用有前提条件，注意调用时间保持比当前操作时间延后一些，好，继续测试。
还是复现问题，现象：
接口调用成功，数据库值未发生变化。
2.0解决方案
调试，更改数据库里面的值，更改不了。Sql语句查询，编辑修改不成功，发现表发生死锁，开发认为查询慢，造成的死锁，加了一下索引。继续测试发现问题又出现了。
开发继续调查
这时候问题就不好复现了，操作了很多次才复现。突然有一天，下班所有的开发把电脑关机后，数据库锁死的数据突然释放。
我们发现，因为有很多开发环境，很有可能程序进入其他人的代码里，造成数据库锁住。
这里普及一下死锁的定义：死锁是指两个或两个以上的进程在执行过程中，因争夺资源而造成的一种互相等待的现象。若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。
回顾过程
发现问题->避免问题的前置条件（屏蔽掉）->判定死锁（关键步骤）->加索引(事实证明跑偏了)->负载均衡->问题解决。
我仅仅描述了大概的过程，其中经过多少轮的验证已经没有明确的数字了。
假如和开发没有及时的沟通，单单从Bug验证次数的结果来看，很容易对这个开发做出能力上的评判，但事实上这个开发能力挺强。
在这个过程中，我理解了负载均衡基本的原理及怎么去判定数据库是否死锁的办法，这些都是测试的经验积累。
总结
所以说，怎么才能丰富自己的知识储备，最好的办法是实践
在实践过程中，发现一个问题，像挖野菜一样，一个个挖，在挖的同时不断拓展思路。
以上就是对于怎么进行Bug跟踪分析的见解，总结一下最重要的两点：
·向上管理及跟踪分析
·当然也少不了良好的沟通技巧