摘要：你是否在为忘记前面怎么执行测试而出现bug苦苦冥思，因为现在你需要说明怎么复现它？你是否在为开发人员不能根据你提交的bug描述而复现问题无奈？你是否在开发人员的机器上不能复现bug而百思不得其解？这里面包含的秘密是需要你去揭开并解决的。
你是否在为忘记前面怎么执行测试而出现bug苦苦冥思，因为现在你需要说明怎么复现它？
碰到这样的情况，往往是缺乏对应的测试用例，且执行流程过于复杂导致的。而往往出现在探索性测试阶段，因为我们可能灵机一动就会想到一个可能会出现bug的测试场景。如果经验不足的测试人员，可能会立即去执行自己的假设，但如果这个场景过于复杂，在执行过程中出现bug后，会突然蒙掉（如果一直专心做这件事还好，但往往中间可能会穿插着其它一些事情），忘记了前面的执行步骤。
我带过很多测试新人，普遍都存在这样的问题。这时我会告诫他们，以后再想到一个新的测试场景，或者在没有用例的情况下执行复杂的流程前，都应该用笔在纸上简单作下步骤描述。这样避免了因为种种原因遗忘既定的测试流程，在出现bug时无法复现。而往往他们都采纳了我的建议，并在后面的测试中避免了这种情况。
你是否在为开发人员不能根据你提交的bug描述而复现问题无奈？
这也是我经常听到测试人员抱怨的，当然开发人员也在抱怨测试人员提交的bug不足复现bug。这种情况，往往由两方面导致：一是测试人员的bug描述的不够简洁、详尽；二是测试人员与开发人员没有形成默契，导致沟通存在障碍。
针对第一种情况，描述不够简洁、详尽。可能原因是测试人员口水话过多，但并没有把bug复现的信息表述清楚。描述一个bug，不一定需要让我们严格的把所有的执行步骤，测试结果，期望结果都按教科书经典案例一般详细的描述出来。反而这样做的话，在时间较紧的情况下会导致我们测试执行效率较低。不管如何，一定要保证你的bug描述简洁明了，这里有几个妙招：
1）在bug摘要最前面，标明测试的功能点。这样会让开发人员快速知道是哪里出现了问题。
2）bug摘要应该简洁明了，并突出重点，即能让开发人员从摘要中就能大致了解怎么出现的这个bug。比如，【注册】输入5位长度密码也成功注册；密码长度应在6~15个字符之间
3）在bug描述中，应该标明测试环境，出现bug模块路径，测试数据，以及浏览器等信息。我们知道浏览器的兼容性，android和ios等手机系统的差异，都可能导致测试的结果完全不同。
4）复杂的测试，应该简单明了的说明bug出现的步骤。如，复现bug步骤：1、执行……；2，执行……
5）附上bug的重要截图。千言万语，抵不过一张截图；有图有真相。
针对第二种情况，开发和测试还不够默契，沟通存在障碍也会影响bug的复现。往往开发和测试人员一起协作的时间越久，也越容易形成默契。我发现这样一个现象，当一个相当优秀的测试人员进入一个全新的研发团队，在开始，与开发的书面和口头沟通都存在或多或少的问题。比如开发人员并不熟悉你的style：bug描述的非常详尽、明了，但因为不熟悉你的描述语言，以及你的描述方式等，从而复现bug出现困难。针对这样的情况也有几个妙招：
1）多和开发人员沟通。不管从生活上兴趣上，还是一些工作问题上；
2）去了解开发人员的style。即了解开发人员易于理解的表达方式去描述你的bug；
3）收集开发人员的意见，并选择性的采纳。可能开发人员对你的描述方式，沟通方式有着一定的意见，那么定期进行意见收集，然后去选择性的采纳也是个不错的主意。
你是否在开发人员的机器上不能复现bug而百思不得其解？
这样的问题也是测试人员容易碰到的。出现这种情况，往往存在如下几个原因：
1、开发人员复现bug，可能只是在自己的工作环境上。环境不一样，可能就会导致执行结果不一样。比如发布的测试版，打的包并不完整。或者开发人员并没有在发版之前把所做的修改全部提交到版本库等。
所以我们应该明确告诉开发人员，复现bug一定要去测试环境复现，确认问题后再到个人工作环境上对问题进行原因分析并修复。
2、版本管理混乱，开发人员随时修改测试环境，或者干脆测试环境和开发环境没有做区分。
测试环境和开发环境一定要分开，并且做好测试环境版本发布管理。否则开发人员为了避免一些责任，比如bug关乎于绩效考核，那么就可能在发布测试版本后发现bug而偷偷的去测试环境做更改。这样后面自然复现不了bug，反而指责测试人员不够仔细。
3、复现的环境情况不完全相同导致。
可能看起来复现的环境都是一样，但实际情况是这样吗？比如复现一个WEB应用界面上的bug，可能看起来复现的环境都是一样的（比如都使用的chrome浏览器），但在自己和开发人员的环境并不一样。这样的情况往往是因为一些配置，所使用的浏览器版本等因素不一致导致的。这时可以把开发人员拉倒你的面前一起复现bug，分析原因。