经常会出现这样一种局面，开发说，这个问题不能重现，重现了再看。测试说，有图有真相，即使在问题发生的当时会出现，后期又不能重现。
结果明知道程序有缺陷，会影响正常使用，却一直无法找到重现的步骤，无法定位问题，有紧急开发任务的开发人员也对此做不了完善调整。眼看着，缺陷就那样存在着……
假如软件产品交付给用户之后，在用户现场或者系统运行过程中出现由于这样的缺陷而导致的失效，那么将会大大影响用户对产品的信心。
虽然有的组织和项目可能不统计无法重现或很难重现的缺陷，甚至忽视难以重现的缺陷。
其实就程序本身而言，没有bug是不可以重现的，bug本事是建立在标准的规程上所出现的异常，只是它隐藏的有点深。所以，没有偶现的缺陷，只有没找到的规律、没有找到的最短发现路径。
个人觉得，测试人员是可以从以下几个方面找到重现步骤：
1、记录缺陷步骤，优化缺陷
细化操作步骤，观察每一步的结果与预期效果是否存在偏差，找到引发缺陷的必要步骤，尽量不要有多余的操作；
2、仍无法重现的情况下，可以考虑分析运行环境的差异；（包括软件应用支撑平台环境、操作系统环境）
3、同软件运行环境下，依旧无法重现，就需要分析数据因素；

总有些缺陷，是在一定数据条件下，才被诱发的。对于程序内部实现逻辑，可以与开发人员进行适当沟通，从逻辑上分析可能引发缺陷的操作，再逐一排查、定位问题。

测试的三重境界：
一、围绕缺陷转：

－－>发现（有效的设计、严谨高效的执行，持续的测试）
－－>定位（没有偶现的缺陷，只有没找到的规律、没有找到的最短发现路径）
－－>关闭（测试是缺陷的责任主体，缺陷的关闭是其为质量守护的重要手段，也是体现价值的方式。
因此，应艺术沟通，减少无效缺陷的草率结论，避免不修改关闭、遗留缺陷的发生）
二、站在缺陷之上：关注业务目标和商业目标，从尽早、尽快、尽多发现缺陷的维度守护质量；
三、挑战零缺陷：质量是设计出来的，从测试尽早的理论推敲，让测试尽早到设计端，以TQM的四个一切为指导思想，挑战零缺陷；

有人说“测试代替不了开发，不需要什么都往自己头上揽。”
我想说的是，测试在很大程度有驱动开发的作用，尽最大可能找到重现问题的必要步骤，或者与开发一起分析问题产生的根本原因的过程，都是一种学习，找到根本原因后的那种豁然开朗，是一种真实畅快的情绪。于你，于我，都是一种小小的满足。