1、回忆操作步骤、尝试重现

尽量回忆当时的操作步骤，并且最大可能的复原当时的操作环境。

确认当时的操作步骤是否有误。如果确认无误，可以多次尝试重现；

即使发现有操作错误的情况，也不要认为没问题了，要思量为什么会操作错误是否用户也会有这种操作？然后和产品讨论自己的想法，很可能这是用户体验上的问题。

可以把整个操作流程进行分解，逐个步骤进行考虑影响因素，然后进行验证。

视测试时间、严重程度、重要程度而定，要花多久进行重现，既不能一两次就草草了事，也不能无休止的在这一个问题上无限制消耗时间。

如果是崩溃问题，一定要尽可能的抓取log并分析原因，然后提供给开发。

2、提交bug与开发沟通

即使不能重现，也一定要提交bug备忘：

1)有的测试人员经常会因为不能重现，就不提交或忽略提交了，这是错误的；

2)用户那边可能会出现，至少我们测试出现过，所以出于测试责任考虑，也要提交；

3)当前不能重现，不代表以后不能重现，既然出现问题了，那肯定是有问题，只不过当前无法解释而已。

4)要把当时出现问题时的环境、步骤，尽可能的在bug上写全，并且附上自己的分析和看法，哪怕是猜测也行，以便后续尝试重现。

开发对自己的程序了解深刻，看到bug后，有可能很容易就能知道问题所在立马就能修改，或者根据现象给测试人员重现上的提示。

对于这类bug，有些开发可能不太乐意让提交，因为没有重现步骤没法改，所以一定要和开发明确说明，这首先是备忘一下，后续可能会重现或想到修改方法；就算最后一直无法解决，也可以置为不可重现关闭。（在搜狗项目中，开发的bug数是不计入绩效统计的，所以开bug对于开发没有什么阻力）

切忌测试人员把单次发现的bug直接给开发，而不进行多次验证、尝试重现，因为这是不专业的表现，发现问题、多次多角度尝试重现、帮助分析问题原因都是测试人员应该做的。

虽然重现bug是测试的职责，但初步定位bug也是测试人员需要提高的能力，因为这样可以和开发一起找原因，提高开发对你能力的认可。但一定要注意，测试人员认为的原因，需要用一种建议的形式和开发沟通，否则会让开发认为你太自负，并且一旦你说的原因是错的，更会被认为是自不量力。

如果直到最后上线前都没有重现，那么就要把这个问题计入上线风险。

3、后续回归测试时着重关注

一轮测试时发现的不可重现问题，在后续回归测试或随机测试时，可以把这类问题重新拿出来分析并尝试重现（所以当即提交bug并详细说明步骤与分析内容的重要性就体现出来了，如果没有这些内容，后续想尝试复现难度都很大）。

重现问题时，不要仅局限在当前的环境下，换换思路、逆向思维、多发散、甚至带点创造性的做法往往会有较大的惊喜。

一旦再次重现，一定要保留现场，叫开发人员一起查看。

如果发现了必现步骤，那么就要好好进行分析，为什么测试用例没有覆盖或者常规测试没有发现，及时总结。

4、如果无法重现，也没有任何信息，可以让开发增加监控日志，以便下次出现问题时可以捕获到相关信息以便进行分析定位问题。

5、如果问题比较严重但无法重现，可以让开发检视自己的代码，做代码审查，评估代码是否有问题。