无法重现bug的解决方案

l开发人员试图重现，重现不出来，拒收

l开发人员找不到规律，所以不去解决，问题一直处于open状态

l开发人员因为问题难以解决，所以直接改成带反侧状态，觉得反正是偶发的，先改成解决状态再说

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

2、解决方法

缺陷的描述：

一般缺陷的基本描述

l缺陷的标题要明确清晰

l缺陷的严重级别

l预置条件

l操作步骤细致化

l过程日志

l显示错误的截图

l缺陷的提交者

l缺陷的提交日期

不可概率重现的缺陷描述添加项：

l重现频率：在提交bug时，记录重现的频率（是、否、随机）细心重复作业

l明确重现概率的范围百分比

l软件的版本：确认发现bug程序版本和重现的代码是一致的，可通过tag或revision来标注

l数据：发生错误时的各种变量、内存、存储器等存储的数据内容状态记录

l环境：软件出错的硬件环境

缺陷的重现注意事项：

l重现的人员：缺陷的重现工作，最好由测试人员去完成。其一：测试人员的文字描述其实很难包括所有现象的信息，让开发人员重现的难度很大；另一：测试人员的重现更有说服力和更快捷

l重现的次数：每个难重现的缺陷，由发现该缺陷的测试人员连续重复测试100次，如果还不能重现，将缺陷状态改为closed

l延长测试时间，努力找到规律。

l若确实无法重现，转交项目经理做延迟处理，继续跟踪，若保留一个月都无法重现的，可先关闭，以后重现时再reopen

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

l人工代码走查：无法重现的代码找对系统最熟悉的开发人员重新review代码，最好是多人一起查，查代码还是查不出来，就要检查操作系统，应用服务器及其环境是否有问题，是否具有兼容性的问题

l工具静态检查：记住：可能出现问题的地方一定会出现问题

l换人重新开发相应的模块

缺陷的记录：

l开发人员Resolve缺陷的时候要写Revision号，填写导致bug的原因。通过Revision号可以追溯到究竟改了什么内容。写bug原因对开发人员也是一种提高。

l根据紧急程度，放入每日/每周开发跟踪问题列表，每次开例会时跟踪问题的解决状态。

制度要求：

l开发人员未解决直接置为Resolve状态的，必须Reopen，不允许这种假解决状况。

l对于开发人员，对于这种因为无法重现和定位的缺陷，不应牵涉到他们的绩效考核，以避免作假的出现。

l加强开发人员的质量意识培养。