在我们的测试过程中，我们提出了许多的BUG，其中有许多BUG因为无法重现而被关闭，这是一个非常可惜的情况。
其实，在我现在的工作过程中，这种事情每天都会发生，在感到遗憾的同时，我对我们的产品也有一些担忧。BUG无法重现，但是它确真真实实的出现过，面对这个问题，测试人员应该怎么办？
第一种方法：只要BUG出现一次，就提交BUG，并且保留截图甚至其他证据，以便以后查看。这种方法，在公司管理办法非常成熟的情况下，这类BUG在总结会上，一般会有个好的评估结果，这个数据，将作为产品风险性考虑的一个依据；如果公司的管理办法不成熟，甚至研发与测试，不在同一个重视级别上，这类的BUG，将会引起很多的争论，最后要么测试赢，要么研发赢，还有可能就直接忽略。
第二种方法：将这种BUG，先记录在word文档中（将操作过程描述的详细一些），待整个测试包都测试完毕后，将这种BUG再重现一遍，想尽可能想到的办法。如果这个BUG还不能重现，也先别着急，留下来，下次测试也许用得着。
在测试过程中，我们往往都关注这种BUG的结果，也许这个结果，还成为了考核业绩的一个依据。但我们忽略了一个关键因素—BUG报告。这是非常令人遗憾的，因为优秀的bug报告对反映测试小组真实的和可理解的工作质量同测试本身一样都是非常重要的。试想一下：如果你不能用开发人员能够理解的术语和能够用于调试的方法给开发人员解释一个错误，他怎么能够修复问题呢？如果你不能够在bug报告中提出一个醒目的错误总结来引起管理层的注意，你又如何让他们关心你们发现的问题呢？
BUG报告的核心，是对错误的描述，以下学习到的一些方法，可以帮助大家提高编写BUG的质量：
详细记录：测试人员应该采用深思熟虑的，小心谨慎的方法执行测试，并且做详尽的记录。这样可以促使他们对测试下的系统有很好的认识。当错误发生的时候，一个有详细记录的测试人员能够知道最早出现问题的地方
多次重现：测试人员在编写bug报告之前必须在检查问题是否可重现。如果错误不可再重现，仍然应该写下来，但是必须说明问题的偶然性。一个好的处理原则就是在编写bug报告之前反复尝试3次。
尝试隔离：在尝试编写bug报告之前，必须试着隔离错误。可以采用改变一些变量的方法，如系统的配置，它可能可以改变错误的症状。这些信息可以为开发人员着手调试提供思路。
及时归纳：在测试人员发现了一个已隔离的，可重现的问题后，应该对问题进行归纳。同一个问题是否出现在其他的模块或其他的地方？同一个故障是否有更加严重的问题？
对比：如果测试人员以前曾经验证过现在出错的测试用例，那么他就应该检查以前的测试结果以检查相同的条件是否通过以前的测试。如果是的话，那么这个问题就象是一个回归的错误。注意由于同一测试条件有可能出现在多个测试用例中，这个步骤就不仅仅只是检查一个测试用例在以前的多个结果。
总结：在bug报告的第一行写上错误的总结是非常关键的。测试人员要花些时间思考已发现的错误对客户有何影响。这不仅仅要求测试人员编写的报告要能够吸引读者，使和管理层的沟通清晰，还要能够帮助设置错误修复的优先级别。
精简：在bug报告的初稿完成后，测试人员应该反复阅读它，集中剔除那些没有关系的步骤或词语。隐含的或模糊的说明和那些由于对没有任何关系的细节或者那些在重现错误过程中不需要的步骤而消磨报告欢迎程度的无穷唠叨都不是bug报告的目标。
消除歧义：测试人员在精简空话的同时或其之后随即应该再仔细检查报告是否有会产生误解的地方。测试人员应该尽量避免使用模糊的，会产生歧义的和主观的词语。目标是使用能够表述事实，清楚的，不会产生争执的词语。
中立：如文中所述，作为坏消息的传递人，和善地提交消息是一个挑战。如同所有的错误总结一样，独立的bug报告在措辞方面应该保持公正。攻击开发人员，指责潜在的错误，企图诙谐或使用挖苦将引起开发人员的憎恶，并且使注意力从“提高产品质量”这个大的目标上转移开了。谨慎的测试人员只用Bug报告来描述事实。
检查：一旦测试人员感觉bug报告是他能够编写的最好版本，他应该将报告再给一个或多个同行进行检查。他的同事们也应该给出一些建议，为了澄清问题不断地提问，如果适当的话，甚至可以挑战“错误成灾”的结论。在允许的时间里，测试小组应该尽可能提交最好的bug报告。
