不可重现的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）加强开发人员的质量意识培养。