不可重现的BUG的应对策略
来源:互联网 发布:java工程师高级培训 编辑:程序博客网 时间:2024/05/16 12:27
问题场景:
有一些比较严重的BUG随机发生,难以查找规律的,测试工程师提交上去后,有可能会出现以下三个情形:
1.开发人员试图重现,重现不出,Reject回来;
2.开发人员找不到规律,所以不去解决,问题一直处于Open状态;
3.开发人员因为问题难以解决,所以直接Resolved回来,觉得反正是偶发的,先改成解决状态再说。
对开发人员、项目经理和测试工程师来说,正确的处理方法应该是怎样的?
解决方案:
1 缺陷的描述:
(1)重现频率:在提交Bug时,记录重现的频率(是、否、随机)
(2)现象:测试人员尽可能描述发生的情况并有截图。
(3)软件的版本:确认发现BUG程序版本和重现的代码是一致的,可通过tag(Clearcase应该叫Label)或者Revision号来标注。
(4)数据:发生错误时的各种变量、内存、存储器等存储的数据内容。
(5)环境:软件出错时的软硬件环境。
对缺陷的描述应该尽可能的详细。
2 缺陷的重现:
(1)重现的人员: 缺陷的重现工作,最好由测试人员去完成,一方面,测试人员的文字描述其实很难包括所有的现象信息,让开发人员重现的难度很大,另一方面,测试人员的重现更有说服力和更快捷。
(2)重现的次数:每个难重现的缺陷,由发现该缺陷的测试人员连续重复测试300次,如果还不能重现,将缺陷状态改为closed;
(3)延长测试时间,努力找到规律。如果市场紧急,由公司级领导特批,相当于高层领导评估风险,就可以先发布软件,但测试和整改继续,留待问题解决后下一版本软件升级;
(4) 若确实无法重现,转交项目经理做延迟处理,继续跟踪,若保留一个月都无法重现的,可先关闭,以后重现时再Reopen;
3 不可重现的缺陷的处理方法:
(1)人工代码走查:无法重现的代码找对系统最熟悉的开发人员重新Review代码,最好是多人一起查。查代码还找不出来,就要检查操作系统、应用服务器及其环境是否有问题,是否有兼容性问题。
(2)工具静态检查:采用静态检查工具(如pclint,splint等工具)检查代码,消除所有的error与warning。记住:可能出现问题的地方一定出现问题!
(3)换人重新开发相关模块:
4 缺陷的记录:
(1)开发人员Resolve缺陷的时候要写Revision号,写bug的原因。通过Revision号可以追溯到究竟改了什么内容。写bug原因对开发人员也是一种提高,知其然,也知其所以然。
(2)根据紧急程度,放入每日/每周跟踪列表,每次开例会时跟踪问题的解决状态。
5 行政管理:
(1)开发人员未解决直接置为Resolve状态的,必须Reopen,不允许这种假解决状况。
(2)对于开发人员,对于这种因为无法重现和定位的缺陷,不应牵涉到他们的绩效考核,以避免作假的出现。
(3)加强开发人员的质量意识培养。
- 不可重现的BUG的应对策略
- 不可重现的BUG的应对策略
- 不可重现的BUG的应对策略
- 如何应对难以重现的偶发性bug?
- 如何应对难以重现的Bug?
- 不可重现的bug如何处理
- 无法重现的bug
- 如何重现难以重现的bug
- 如何重现难以重现的bug
- 如何重现难以重现的bug
- 重现Bug,解决问题的根本
- 危机下的应对策略
- 【压力面试的应对策略】
- 案例:如何解决难以重现的BUG
- 案例:如何解决难以重现的BUG
- 发现的bug不能重现怎么办?
- 提交的bug不能重现怎么破?
- 如何看待那些不能重现的bug
- redboot的使用
- jQuery 1.3 API 参考文档中文版
- .net 操作 EXCEL (using c# to control and access the excel)
- 在netbeans上配置Petstore
- AutoCAD2006激活方法
- 不可重现的BUG的应对策略
- 【转】C++箴言:避免构造或析构函数中调用虚函数
- AJAX的js代码
- .INF文件是什么
- 人生之境界
- 人间正道
- 强制杀死EXCEL应用程序进程/Ole db方式读取指定Region的内容
- 编写INF文件进行文件安装(转载)
- 解决加载arx时,出现非法异常的方案