不可重现的BUG的应对策略

问题场景：
有一些比较严重的BUG随机发生，难以查找规律的，测试工程师提交上去后，有可能会出现以下三个情形：
1．开发人员试图重现，重现不出，Reject回来；
2．开发人员找不到规律，所以不去解决，问题一直处于Open状态；
3．开发人员因为问题难以解决，所以直接Resolved回来，觉得反正是偶发的，先改成解决状态再说。


对开发人员、项目经理和测试工程师来说，正确的处理方法应该是怎样的?


解决方案：
1 缺陷的描述：

（1）重现频率：在提交Bug时，记录重现的频率（是、否、随机）
（2）现象：测试人员尽可能描述发生的情况并有截图。
（3）软件的版本：确认发现BUG程序版本和重现的代码是一致的，可通过tag(Clearcase应该叫Label)或者Revision号来标注。
（4）数据：发生错误时的各种变量、内存、存储器等存储的数据内容。
（5）环境：软件出错时的软硬件环境。
对缺陷的描述应该尽可能的详细。


2 缺陷的重现：

（1）重现的人员： 缺陷的重现工作，最好由测试人员去完成，一方面，测试人员的文字描述其实很难包括所有的现象信息，让开发人员重现的难度很大，另一方面，测试人员的重现更有说服力和更快捷。
（2）重现的次数：每个难重现的缺陷，由发现该缺陷的测试人员连续重复测试300次，如果还不能重现，将缺陷状态改为closed；
(3)延长测试时间，努力找到规律。如果市场紧急，由公司级领导特批，相当于高层领导评估风险，就可以先发布软件，但测试和整改继续，留待问题解决后下一版本软件升级；
(4) 若确实无法重现，转交项目经理做延迟处理，继续跟踪，若保留一个月都无法重现的，可先关闭，以后重现时再Reopen；


3 不可重现的缺陷的处理方法：

（1）人工代码走查：无法重现的代码找对系统最熟悉的开发人员重新Review代码，最好是多人一起查。查代码还找不出来，就要检查操作系统、应用服务器及其环境是否有问题，是否有兼容性问题。
（2）工具静态检查：采用静态检查工具（如pclint,splint等工具）检查代码，消除所有的error与warning。记住：可能出现问题的地方一定出现问题！
（3）换人重新开发相关模块：


4 缺陷的记录：

（1）开发人员Resolve缺陷的时候要写Revision号，写bug的原因。通过Revision号可以追溯到究竟改了什么内容。写bug原因对开发人员也是一种提高，知其然，也知其所以然。
（2）根据紧急程度，放入每日/每周跟踪列表，每次开例会时跟踪问题的解决状态。


5 行政管理：

（1）开发人员未解决直接置为Resolve状态的，必须Reopen，不允许这种假解决状况。
（2）对于开发人员，对于这种因为无法重现和定位的缺陷，不应牵涉到他们的绩效考核，以避免作假的出现。
（3）加强开发人员的质量意识培养。