问题场景：有些比较严重的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加强开发人员的质量意识培养