如题，产生 BUG 测试人员需要自己去分析原因吗？大田说说自己的想法：如果说到分析，最终肯定是开发查代码去分析，但是测试人员可以根据问题先做一个初步的定位。
总体思路是：由测试人员初步定位，再协助开发复现，由开发分析代码，解决。文章源自懂站帝-http://www.sfdkj.com/16201.html
1、如果是测试人员发现的 BUG，文章源自懂站帝-http://www.sfdkj.com/16201.html
可以利用 F12 抓包、Linux看日志 log、查库对比等手段先分析报错情况，这几步基本能发现大部分问题。测试人员把具体报错原因给到开发，也能提升开发的工作效率；文章源自懂站帝-http://www.sfdkj.com/16201.html
2、如果是客户发现的 BUG，文章源自懂站帝-http://www.sfdkj.com/16201.html
先由测试人员复现，复现出来后，按照上述第 1 点所说，继续后续操作；文章源自懂站帝-http://www.sfdkj.com/16201.html
3、如果测试时间实在不够，文章源自懂站帝-http://www.sfdkj.com/16201.html
测试人员需要将问题提到缺陷管理系统中，阐述清楚具体出现的步骤、bug类型等，开发按照步骤复现分析问题。文章源自懂站帝-http://www.sfdkj.com/16201.html 每个测试人员在做项目的时候基本都会遇到那种难以重现的bug，本来兴高采烈的以为发现了一个很有意思的bug，等提交上去的时候又被开发打了回来，等把开发叫到跟前演示的时候发现自己也重现不了了。 到底有哪些原因会导致这类bug的出现呢？
1. 特殊的测试数据有经验的测试人员在进行测试的时候并不会按部就班的按照case来测，假如case的粒度很粗的 话更会如此，有时候突发奇想的填了一个数据进去，结果程序报错了，等回过神来再试图去重 现的时候发现case里准备的数据都不能触发那个bug了，这时候就应该努力去回想当时用的是 什么数据（当然很多时候确实很难记起来）。
2. 环境不稳定在实际的实际的工作中，开发环境、测试环境、生产环境、UAT环境都是分开来的，所以不同 的环境下同一个数据的实际结果也有可能不同，导致测试环境下发现的bug在开发在开发环境 验证的时候无法重现，这时候有可能是开发已经deploy了最新的代码，但是测试环境没有得 到及时更新；还有另一种情况，就是环境的不稳定，这种问题在项目初期尤为明显，刚搭完的 环境总是有很多难以重现的莫名其妙的bug，这种情况可能是由于环境的配置、软件的配置或 者接口不稳定造成的。
3. 操作顺序不当如果页面上的操作没有严格的先后顺序，测试员在测试的时候有可能第一遍是12354，发现了 bug，当准备回头去验证的时候发现重现不了了，因为用例里写的顺序是12345而测的12354只 是心血来潮，bug的触发需要特定的条件和特定的操作顺序，刚好12354能够满足触发条件而 12345却能运行正常。
4. 没有找到触发关键步骤特定的bug只会在经过特定的操作之后才会出现，而当测试员不经意的做出某操作而试图重现 的时候又忽略那个关键操作的时候，那也很难重现。
5. 内存泄漏或锁有一些系统只有经过长时间运行才会暴露出bug，这个问题也很难重现。需要经过长时间的测 试才能确认以及特殊情况下数据锁的问题，导致的一些bug都很难重现。
6. 测试人员的错误操作测试人员在测的时候忘记了执行某一操作，导致出现的结果跟预期不匹配，等再回头按照case 跑的时候发现无法重现而导致误报。 在发现了难以重现的bug之后，最好提交了之后把它设为监视状态，观察它出现的频率和时间 等，如果直到版本上线还是没有重现，也要持续跟踪，毕竟这些也在项目风险范围之内。文章源自懂站帝-http://www.sfdkj.com/16201.html文章源自懂站帝-http://www.sfdkj.com/16201.html
