软件测试管理中对于不可重现Bug的个人理解
来到公司后参加了4个项目，在测试过程中一个头疼的Bug便是不可重现的Bug。针对这类Bug，有不同的观点，一部分认为是测试人员的操作错误，一部分人认为是这类Bug是真实存在，根据我的经历我赞同后面这个观点，而且认为出现不可重现Bug只是小概率的事件。
个人认为出现不可重现Bug的原因大致如下：
1．测试环境的不稳定。
2．测试用例没有完全细化覆盖到这个功能点。
3．人的问题，测试人员总是操作不到点上。
面对不可重现性Bug我们应该怎么做呢？ 实际工作过程中出现不可重现Bug对我们测试人员是一种锻炼，锻炼我们提交Bug的能力，跟踪Bug的能力，可以充分锻炼我们的探索式思维，很多时候这种探索式思维对重现Bug有很大的帮助。
1．项目测试时，争取有自己独立的干净的测试环境。同时为了重现bug可以试着交换测试机器，或者测试任务。
2．回顾我们的测试用例，看确实是否存在遗漏功能需求。一般都会存在，只是这个需求可能极其隐蔽。
3．一旦出现Bug，分析，记录刚刚进行的操作，以及刚执行的用例，然后争取保留现场，和开发同学及时的交流，及时的查看日志，以及现场。
4．必要时借助测试工具，开发同学要有良好编码习惯特别是对于log，尽可能的要重视log的作用。
5．探索式测试。这种测试对于重现bug还是比较管用的。
我们这次项目涉及到了客户端，在测试一段时间后客户端就会crash，（客户端在用户使用过程中崩溃肯定影响公司的形象），crash出现的频率基本在一天一次左右，但是出现在不同的测试用例执行过程中，甚至在长时间开着客户端也会偶尔出现crash。这说明所谓的这个“不可重现”Bug是真实存在的，开发同学经过多次的日志分析后终于在项目测试第二轮结束时顺利解决掉。客户端崩溃的原因：简洁的说，“多线程重入一个共享对象，一个在使用，一个在 destruct”。由于本次项目缺少接口测试资源，这个原本接口测试中可以很容易发现的bug遗留到了功能测试过程中，于是变成了所谓的“不可重现”或者“不容易重现”，“无规律”重现的Bug。也就是说由于我们缺少接口测试的用例于是变成了功能测试来“埋单”了，另一个方面也证明了做为一个正规的程序类项目我们缺少测试流程中的哪一个环节也都是要付出一定代价的！
文章来源于领测软件测试网 https://www.ltesting.net/
