Bug规范和实际问题的处理

原创 2018年04月16日 11:08:04
一、前言
提交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、2、3、4级bug判定标准如下: ♦ 1-紧急  致命错误,例如主程序不能正常运行,基本业务功能未实现,交易数据不准确或不一致,从而使得后续流程无法正常进行:  ※ 操作系统崩溃、死机  ...
  • wangshufen20091651
  • wangshufen20091651
  • 2017-02-10 14:35:31
  • 312

bug管理规范及流程

1      概述 本文档定义bug的整个生命周期,规范bug的解决方案及管理流程。Bug在流转的过程中有章可循。 规范bug严重等级与bug解决优先级,使开发人员与测试人员能根据此文档准确判断bug...
  • testing_su001
  • testing_su001
  • 2017-02-16 13:46:20
  • 2519

一份BUG提交规范

1,BUG全部提交到http://XXX.XXX.XXX.XXXBUG论坛上 2,创建的问题的时候,“概要”--用简单明了的语句说明白你这个BUG,就相当与BUG的中心语句 3,BUG优先...
  • yangleo1987
  • yangleo1987
  • 2016-12-29 16:42:53
  • 955

测试BUG流程管理规范

  • 2016年07月20日 09:32
  • 44KB
  • 下载

bug提交规范

  • 2012年06月26日 15:08
  • 27KB
  • 下载

bug提交与规范

  • 2013年05月12日 17:16
  • 125KB
  • 下载

BUG单内容规范

1. 字段(一个BUG拥有的所有属性)BUG编号 模块 测试用例编号 标题 描述 重现方法 恢复办法 概率类型 出现概率 缺陷等级 生命类型...
  • ewq159
  • ewq159
  • 2018-03-09 17:33:50
  • 58

提交BUG的标准规范

我们在软件测试过程中,发现了BUG后,如何提交一个高质量的BUG, 其实我们可以总结一下规范的,文章主要从以下几方面讨论:...
  • sinat_37967865
  • sinat_37967865
  • 2017-12-02 23:38:30
  • 113

如何编写高质量bug报告

1.定义 Bug(缺陷):英文单词,本意是臭虫、缺陷、损坏等意思。现在人们将在电脑系统或程序中,隐藏着的一些未被发现的缺陷或问题统称为bug(漏洞)。   2.目的 简单地说,报告bug的目的...
  • wei_zhi
  • wei_zhi
  • 2016-02-29 15:27:51
  • 2088
收藏助手
不良信息举报
您举报文章:Bug规范和实际问题的处理
举报原因:
原因补充:

(最多只允许输入30个字)