不可重现的BUG的解决制度
一. 问题场景：
有一些比较严重的BUG随机发生，难以查找规律的，测试工程师提交上去后，有可能会出现以下三个情形：
ü 开发人员试图重现，重现不出，Reject回来；
ü 开发人员找不到规律，所以不去解决，问题一直处于Open状态；
ü 开发人员因为问题难以解决，所以直接Resolved回来，觉得反正是偶发的，先改成解决状态再说。
对开发人员、项目经理和测试工程师来说，正确的处理方法应该是怎样的？
二. 解决方法： 1缺陷的描述：一般缺陷的基本描述：
Ø 缺陷的标题要明确清晰。
Ø 缺陷的严重级别。
Ø 预置条件
Ø 操作步骤
Ø 过程日志
Ø 显示错误的截图
Ø 缺陷的提交者
Ø 缺陷的提交日期
不可概率重现的缺陷描述添加项：
Ø 重现频率：在提交Bug时，记录重现的频率（是、否、随机）。
Ø 明确重现概率的范围百分比。
Ø 软件的版本：确认发现BUG程序版本和重现的代码是一致的，可通过tag（Clearcase应该叫Label）或者Revision号来标注。
Ø 数据：发生错误时的各种变量、内存、存储器等存储的数据内容状态记录。
Ø 环境：软件出错时的软硬件环境。
对于缺陷的全流程描述应该尽可能的详细。
2缺陷的重现注意事项：
重现的人员：缺陷的重现工作，最好由测试人员去完成，一方面，测试人员的文字描述其实很难包括所有的现象信息，让开发人员重现的难度很大，另一方面，测试人员的重现更有说服力和更快捷。
重现的次数：每个难重现的缺陷，由发现该缺陷的测试人员连续重复测试100次，如果还不能重现，将缺陷状态改为closed；
延长测试时间，努力找到规律。如果市场紧急，由公司级领导特批，相当于高层领导评估风险，就可以先发布软件，但测试和整改继续，留待问题解决后下一版本软件升级；
若确实无法重现，转交项目经理做延迟处理，继续跟踪，若保留一个月都无法重现的，可先关闭，以后重现时再Reopen；
3不可重现的缺陷的处理方法：
² 人工代码走查：无法重现的代码找对系统最熟悉的开发人员重新Review代码，最好是多人一起查。查代码还找不出来，就要检查操作系统、应用服务器及其环境是否有问题，是否有兼容性问题。
² 工具静态检查：采用静态检查工具（如pclint，splint等工具）检查代码，消除所有的error与warning。记住：可能出现问题的地方一定出现问题！
² 换人重新开发相关模块：
4缺陷的记录：
ü 开发人员Resolve缺陷的时候要写Revision号，填写导致bug的原因。通过Revision号可以追溯到究竟改了什么内容。写bug原因对开发人员也是一种提高。
ü 根据紧急程度，放入每日/每周开发跟踪问题列表，每次开例会时跟踪问题的解决状态。
5制度要求：
Ø 开发人员未解决直接置为Resolve状态的，必须Reopen，不允许这种假解决状况。
Ø 对于开发人员，对于这种因为无法重现和定位的缺陷，不应牵涉到他们的绩效考核，以避免作假的出现。
Ø （3）加强开发人员的质量意识培养。
