Bug规范和实际问题的处理

一、前言
提交bug是个既愉快又痛苦的过程。成功的发现一个有效bug是很有成就感的,但是如果bug提交的不规范不清楚,导致开发反复找你确认或者一段时间后自己都忘了是个什么bug那就很痛苦了。特别是有时候bug会很多(尤其是项目前期,bug爆发的阶段)。所以好的bug能避免很多麻烦,避免了开发找你的麻烦,也避免了自己给自己找的麻烦。
所以什么样的bug才是好bug?主要从两方面:一、提高bug的有效性;二、养成这样的好习惯。
几年前,曾经面试的时候被问到同样的问题,我忘怎么回答的了,但是印象最深的是他提到了一点,有截图的bug是好bug。是的,截图这一点我很赞同。这印证了“有图有真相”这句网络术语。确实用图表说明比纯文字描述的bug要好理解的多,特别是场景复杂复现困难的bug。能让开发一目了然,提供了最原始的视觉冲击,再配以明确的文字描述,定位起来也更容易些。
那么如何提高bug的有效性:
(1)关于标题,语言描述始终是个难题,如果bug的标题能让开发正确理解80%那是很成功的一个bug。
作为一个测试团队,标题可以配置一些标签,约定俗成,如“【平台】”、“__模块__”等,而且要有“条件”、‘在哪里’、‘做了什么’、‘导致出现了什么问题’这几个要素。
(2)关于截图,要有截图(如果有日志更好,如果条件允许录像也是可以的),截图很有说明性,相当于事发现场的拍照,可以说明绝大部分情况,如果场景复杂,建议把每个步骤进行截图并配以简单的文字描述。便于跟踪。
(3)关于偶现/必现,必现的bug可以通过反复试验,将最短路径找出来,写成步骤提交上去。如果是偶现的bug,一定要先提交!因为有的偶现bug其实影响还是很大的,既然发现了,就说明是有问题的,不可放过。对于偶现bug的跟踪,最好是跟踪几个版本(如三个版本),在每个版本上对该bug进行测试验证并记录到该bug上,复现了最好,如果最终没有复现那么在第三个版本进行关闭。
(4)关于修改,有时候提交bug会漏掉一些信息或者后面发现bug没写清楚,为了开发能更好的定位问题,一定要将这些信息补上。
(5)关于回归,回归环境、版本、结果(通过、不通过、变相通过、场景不存在...)、步骤,应该要有,做到有理有据。
(6)关于项目周期很紧,很多情况是因为bug太多,提交bug会占据很多时间,所以很多同事就简单几句,就把bug提交了,为后面埋了很多坑,这样做后患无穷。其实截个图,把标题的要素习惯养起来,形成习惯之后,提交bug并不会慢的。
对于bug严重等级、优先级这些问题如下,这是基本的东西。
二、BUG提交规范:
提交模板
用例标题:【Android /IOS/Web/服务器/生产环境】_模块名_问题描述 
【测试环境】 (手机型号操作系统/系统版本/浏览器版本等等)
【前置条件】
【步骤】(应该和用例步骤是一致,如不一致,为用例缺失,需要补充用例)  
1、文字/截图
2、文字/截图
3、文字/截图
【期望结果】
1、
【实际结果】
文字/截图
【出现几率】
必现/80%/50%/20%
回归模板
【测试结论】通过/不通过/变相通过/场景不存在/重复bug/无效bug
【回归环境】
【回归版本】
【步骤】
1、文字/截图
3、文字/截图
3、文字/截图
重要的事情说三遍:
最好有截图!有截图!有截图!

三、BUG的严重等级划分:
BUG分为5个严重等级,分别是:1致命,2严重,3一般,4次要,5建议/提示
缺陷严重程度
定义
示例
致命
缺陷产生后,产品主要功能会失效,业务陷入瘫痪状态,关键数据损坏或丢失,且故障无法自行恢复(无法自动重启)
(1)产品功能失效/和需求期望不符,用户无法使用
(2)无法正常启动、异常退出、Crash、资源不足、死循环、崩溃或严重资源不足等
(3)安全问题:支付漏洞、被劫持、信息被盗取、被注入等
(4)核心功能/页面:无法访问
(5)数据:损坏或丢失且不可恢复
严重
缺陷产生后,产品主要功能无法使用,核心功能无法完成、功能报错、数据错误等,但不会影响程序运行
(1)产品重要功能不稳定
(2)由程序引起的非法退出、重启等(但能自行恢复)
(3)产品与需求严重不符、缺失,或存在关键性错误
(4)产品难于理解和操作;
(5)产品无法进行正常的维护性;
(6)产品升级后功能出现丢失、性能下降等
(7)性能达不到系统规格;
(8)产品不符合标准规范,存在严重兼容性问题
一般
缺陷发生后,系统在功能、性能、可靠性、易用性、可维护性、可安装性等方面的一般问题
(1)产品一般性功能失效或不稳定
(2)产品未进行输入限制(如正确和错误值的界定)
(3)一般性的文档错误
(4)产品一般性的规范性和兼容性问题
(5)系统报表、日志、统计信息显示错误
(6)次要功能未显示或无法使用,但不影响程序其他功能
(7)系统调试信息难于理解或存在错误
次要
缺陷发生后,对用户只会造成轻微影响,这些影响在用户可接受的范围内
(1)产品输出正确,但不够规范
(2)产品提示信息不够清晰,难以理解
(3)文档中存在错别字、语句不通等
(4)长时间操作未给用户提供进度提示等
(5)页面排版不整齐
建议
对用户体验造成影响的问题,可以提升用户体检的建议
(1)不符合常规用户习惯,不符合行业规范
(2)引导不够明确等
四、BUG的优先级划分
BUG分为5个优先等级,分别是:1立即解决,2急需解决,3重要不紧急,4正常处理,5不紧急不重要
优先级
定义
解释
1
立即解决(now)
表示问题必须马上解决,否则系统根本无法达到预定的需求
2
急需解决(当天)
表示问题的修复很紧要,很急迫,关系到系统的主要功能模块能否正常
3
重要不紧急(不超过3天)
表示有时间就要马上解决,否则系统偏离需求较大或预定功能不能正常实现
4
正常处理(不超过5天)
表示问题不影响需求的实现,但是影响其他使用方面,比如页面调用出错,调用了错误的等。
5
不紧急不重要
即问题在系统发布以前必须确认解决或确认可以不予解决,如建议性bug

五、对应关系
(1)、严重性和优先级并不总是一一对应。有时候严重性高的软件缺陷,优先级不一定高,甚至不需要处理,而一些严重性低的缺陷却需要及时处理,具有较高的优先级。
(2)、严重等级和优先级可随测试策略的变化而有所调整。提交的bug可能在不同的测试阶段而变得不一样。如前期的测试重点是功能点的实现,这个时候提交的建议性的bug则显得不那么重要,但是到了后期项目功能业务稳定后,测试重点有所改变,这些建议性的bug则更能优化产品,给产品润色,所以可以将bug优先级和严重等级进行调整。
六、怎样处理走回来的bug
怎么应对走回来的bug,这是在实际测试中往往会遇到的问题。走回来的bug状态一般分几种:
已解决(代码修复)、外部原因、设计如此——每个公司会有不同,具体根据部门间的约定而定,但大同小异。
(1)已解决代码修复的情况,这种是最好处理的,直接走正常的验证流程即可,验证不通过的走reopen的流程。
(2)外部原因这种情况,一般是因为无法复现、场景不存在了、条件不满足了等等一些第三方的原因或不可抗的因素。遇到这种情况可以在测试团队约定一个流程:转给测试leader——leader确认——再转给测试人员进行处理。这么做的原因是这种bug一般测试人员不好评估影响,但作为leader则更能把握质量和权衡利弊。
(3)设计如此的情况,这种bug一般是开发找了产品(UE/UI)进行确认的。在跟踪记录中如果有产品人员的确认记录,即达成了三方一致的情况,可以予以关闭;在跟踪记录中如果没有产品的确认记录只是开发的单方面说明,则需要找产品进行线下确认,并备注到bug上。
(4)还有一种是重复bug,这种测试人员要尽量避免。提交bug之前要在管理平台进行确认是否重复。
(5)关于开发给的处理原因,这是一个很头疼的问题,每个开发不一样,在返回的bug中进行的说明也千差万别,最差的就是仅会简单的写几个字:“已解决”、“已修复”这种惜墨如金的做法。这也是我们最不希望看到的,从项目质量管理上也是不好的做法,对于开发来说时间久了他也不知道错在哪里,无法进行追溯和提高,对于测试人员则会感到莫名其妙,也很难对bug进行分类分析。一旦出现这种情况需要leader和开发项目经理进行沟通,对开发人员的这种行为进行约束和规范。一旦约定后遇到这种情况可以予以打回,要求开发说明问题原因。





阅读更多
文章标签: bug 缺陷 软件测试
个人分类: 软件测试
上一篇我的测试用例设计实践(1)
想对作者说点什么? 我来说一句

bug提交与规范

2013年05月12日 125KB 下载

mantis中的bug状态变化流程

2010年01月14日 32KB 下载

BUG库管理规范BUG库管理规范

2010年01月19日 154KB 下载

最新版jira里面的bug处理流程图

2012年04月04日 37KB 下载

关于实际应用中的数值计算

2009年09月13日 63KB 下载

BUG描述语言规范

2014年03月19日 65KB 下载

MATLAB题库很好用

2014年01月01日 186KB 下载

Mantis Bug处理流程

2010年02月08日 171KB 下载

Bugzilla小知识

2011年03月29日 15KB 下载

没有更多推荐了,返回首页

关闭
关闭