不可重现BUG的解决制度
上一篇 /
下一篇 2010-12-31 10:10:48
1、 问题场景:有些比较严重的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 加强开发人员的质量意识培养。
收藏
举报
TAG: