1、回忆操作步骤、尝试重现
　　尽量回忆当时的操作步骤，并且大可能的复原当时的操作环境。
　　确认当时的操作步骤是否有误。如果确认无误，可以多次尝试重现；
　　即使发现有操作错误的情况，也不要认为没问题了，要思量为什么会操作错误是否用户也会有这种操作？然后和产品讨论自己的想法，很可能这是用户体验上的问题。
　　可以把整个操作流程进行分解，逐个步骤进行考虑影响因素，然后进行验证
　　视测试时间、严重程度、重要程度而定，要花多久进行重现，既不能一两次草草了事，也不能无休止的在这一个问题上无限制消耗时间
　　如果是崩溃问题，一定要尽可能的抓取log并分析原因，然后提供给开发
　　2、提交bug与开发沟通
　　即使不能重现，也一定要提交bug备忘：
　　1)有的测试人员经常会因为不能重现，不提交或忽略提交了，这是错误的
　　2)用户那边可能会出现，至少我们测试出现过，所以出于测试责任考虑，也要提交；
　　3)当前不能重现，不代表以后不能重现，既然出现问题了，那肯定是有问题，只不过当前无法解释而已。
　　4)要把当时出现问题时的环境、步骤，尽可能的在bug上写全，并且附上自己的分析和看法，哪怕是猜测也行，以便后续尝试重现
　　开发对自己的程序了解深刻，看到bug后，有可能很容易能知道问题所在立马能修改，或者根据现象给测试人员重现上的提示
　　对于这类bug，有些开发可能不太乐意让提交，因为没有重现步骤没法改，所以一定要和开发明确说明，这首先是备忘一下，后续可能会重现或想到修改方法；算后一直无法解决，也可以置为不可重现关闭。（在搜狗项目中，开发的bug数是不计入绩效统计的，所以开bug对于开发没有什么阻力）
　　切忌测试人员把单次发现的bug直接给开发，而不进行多次验证、尝试重现，因为这是不专业的表现，发现问题、多次多角度尝试重现、帮助分析问题原因都是测试人员应该做的。
　　虽然重现bug是测试的职责，但初步定位bug也是测试人员需要提高的能力，因为这样可以和开发一起找原因，提高开发对你能力的认可。但一定要注意，测试人员认为的原因，需要用一种建议的形式和开发沟通，否则会让开发认为你太自负，并且一旦你说的原因是错的，更会被认为是自不量力。
　　如果直到后上线前都没有重现，那么要把这个问题计入上线风险。
　　3、后续回归测试时着重关注
　　一轮测试时发现的不可重现问题，在后续回归测试或随机测试时，可以把这类问题重新拿出来分析并尝试重现（所以当即提交bug并详细说明步骤与分析内容的重要性体现出来了，如果没有这些内容，后续想尝试复现难度都很大）。
　　重现问题时，不要仅局限在当前的环境下，换换思路、逆向思维、多发散、甚至带点创造性的做法往往会有较大的惊喜。
　　一旦再次重现，一定要保留现场，叫开发人员一起查看
　　如果发现了必现步骤，那么要好好进行分析，为什么测试用例没有覆盖或者常规测试没有发现，及时总结。