BUG报告处理
在软件测试过程中,对于发现的每一个软件缺陷,都要记录其特征和复现步骤等信息,以便相关人员分析和复现软件缺陷。
一、软件缺陷报告包含的内容
1、报告编号:为了方便对缺陷进行管理,每个缺陷必须赋予一个唯一的编号,规则根据需要和需求进行制定;
2、标题:标题用简单的方式可以传达缺陷的基本信息,标题应该简短并尽量做到唯一,因为这个缺陷可能在以前的版本修改过;
3、报告人:缺陷报告的原始创造人,有时也应该包含报告的修订者;
4、报告的日期:首次报告的日期。让开发人员知道创建缺陷报告的日期是很重要的,因为这个缺陷有可能在以前的版本有改过;
5、程序或组件的民称:可分辨测试对象;
6、版本号:测试可能跨越多个版本的软件,提供版本信息可以方便对缺陷进行管理;
7、配置:发现缺陷的软件和硬件配置。如操做系统类型、是否用游览器、处理器的类型和速度;
8、缺陷的类型:如代码错误、设计你问题和文档不匹配;
9、严重性:描述报告的严重性;
10、优先级:由开发人员或管理人员确定;
11、关键词:使用关键词以便分类查找缺陷报告;
12、缺陷描述:对发现的问题进行详细描述
13、重现步骤:这些步骤必须是有限的,并且描述的信息足够读者知道正确的执行就可以重现报告的缺陷;
14、结果对比:在执行了重现步骤后,将期望结果与实际结果进行对比
下面是一个软件缺陷模板
模板名称
|
用户注册
|
||
版本号
|
v1.1
|
测试人
|
XXX
|
缺陷类型
|
功能错误
|
严重级别
|
B
|
可重复性
|
是
|
缺陷状态
|
New
|
测试平台
|
win XP Professional
|
游览器
|
ie8.0
|
简述
|
系统规定注册用户名长度为6-20字符,至少6个字符的用户名可成功注册
|
||
操做步骤
|
1、进入xxx购物网首页
2、单机“注册”按钮,进入用户注册协议页面
3、单机“同意”按钮,进入用户注册信息页面
4、按要求输入相关信息
5、点击“提交”按钮,提示注册成功
|
||
实际结果
|
提示用户名错误,不能注册成功
|
||
预期结果
|
注册成功
|
|
|
注释
|
建议修改
|
|
|
二、缺陷的严重性和优先等级
1、缺陷的严重性
0级(致命):最严重等级,缺陷导致系统任何一个主要功能完全丧失、用户数据受到破坏、系统崩溃、悬挂、死机等;
1级(严重):系统的主要功能部分丧失、数据不能完全保存,系统的次要功能完全丧失,系统所提供的功能或服务收到明显影响;
2级(一般):系统的次要功能没有完全实现,但不影响用户的正常使用。例如,提示信息不太准确;或用户界面差、操做时间稍长等问题;
3级(微小):操作者不方便或遇到麻烦,但不影响功能的操做和执行,如字体不美观、按钮大小不很合适、字体排列不对齐等一些小问题。
2、缺陷的优先级
立即解决(p1级):缺陷导致系统几乎不能完全运行、使用,或严重妨碍测试的执行,需立即修正、尽快修正;
高优先级(p2级):缺陷严重,影响测试,需要优先考虑修正,如不超过24小时修正;
正常排队(p3级):缺陷需要修正,但可以正常排队等待修正;
低优先级(p4级):缺陷可以在开发人员有时间的时候被修正,如果没时间可以不修正。
三、软件缺陷的生命周期
缺陷的生命周期可以简单地表现为:打开(open)—修正(fixed或solved)—关闭(close)
软件缺陷状态的描述:
打开/激活:缺陷的起始状态,或重新打开的状态。问题存在或依旧没有解决,等待修正,如新报告的缺陷、补充完整信息后在打开;
已修正:已经被开发人员检查、修复过的缺陷,通过单元测试,认为及解决但还待测试人员验证;
关闭/非激活:测试人员验证后,确认缺陷不存在的状态;
无法解决:由于技术原因或者第三方软件的缺陷,开发人员目前不能解决的缺陷;
延迟:这个缺陷不严重,被推迟修正,可以在下一个版本解决;
功能增强:该问题符合 当前的设计规格说明书,但有一个待改进问题;
不是缺陷:开发人员认为不是问题,十年测试人员的误报缺陷;
不能再现:开发人员不能复现这个软件缺陷,需要测试人员检查缺陷复现步骤;
需要更多信息:开发不能复现这个软件缺陷,但开发人员需要一些信息,例如:缺陷的日志文件、图片等。
缺陷质量
- 缺陷分级:一般四级分类法,
- 缺陷记录:bug管理系统,bug的生命周期理论
- 缺陷反思:bug评审,开发避免类似错误,测试在设计测试用例的时候考虑类似情景
《BUG严重性等级与优先级定义》
同时在测试过程中,发现了 bug 必须详细描述问题,不管是 jira,禅道或是其他的 bug 管理方式,一个 bug 要写清楚以下几点:Bug 问题描述,bug 重现步骤,是否有前置条件,预期结果,实际结果,以方便开发去进行修改。同时给 bug 准确分级,实时跟踪进度,保证项目按期完成。
上线回归与项目总结
一个需求上线完成后,要及时进行线上回归,如果有必须提醒相关的人员进行自动化线上回归或是监控工作。
在一个项目完成后,不管公司有没有要求,要对项目做相应的文字总结。总结整个项目过程中遇到的问题,最后的解决办法或是当时讨论的处理办法,有哪些需要注意的问题?有什么可以借鉴的方案或是改进策略?项目中有没有通用性的问题等等。
如冒烟测试是否一次通过,Bug 数及不同级别的 bug 数,参与开发人员对应的 Bug 数,提测试次数,上线次数等等。而后借助于第三方工具进行图表化相应的数据,然后相关问题的总结,改进方案都需要进行详细的总结。
好多也说会写缺陷报告,但总是提交信息不系统,漏掉某些关键业务处理链路上的必要信息。
缺陷报告的处理
1. 缺陷报告的简单处理流程/缺陷的生命周期
- 软件测试人员提交缺陷报告;
- 测试负责人审核后将缺陷报告分配给相关的开发人员修改;
- 缺陷被修改后由测试人员根据缺陷报告中的修改记录进行返测;
- 返测通过的缺陷报告由负责人关闭,返测未通过的缺陷报告直接返回开发人员重新 修改,缺陷报告直到缺陷被修复以后才关闭;
- 关闭或已解决的缺陷报告可能会被阶段性的复审重新打开,这些报告一旦被再次打 开应该立即处理。
2. 缺陷报告的标准处理流程
- 正常缺陷
- 重复缺陷
- 无效缺陷
- 推迟修改
- 验证不通过
- 描述不清楚
3. 缺陷跟踪管理系统/缺陷管理工具
3.1 缺陷管理工具的功能
- 缺陷提交
- 缺陷跟踪
- 缺陷分析
- 有效的缺陷分析不仅可以评价软件质量,同时可以帮助项目组很好地掌握和评 估软件的研发过程,进而改进研发过程,未对缺陷进行分析就无法对研发流程 进行改进。
- 缺陷分析还能为软件新版本的开发提供宝贵的经验,进而在项目开展之前,指 定准确、有效的项目控制计划,为开发高质量的软件产品提供保障。
3.2 常见缺陷管理工具
- Bugzilla
- Bugfree
- Mantis
- Jira
- ZenTao(禅道)
- Quality Center/Application Lifecycle Management
- 目前市场占用率最高的项目管理工具。
- 全球最大的测试工具提供商 Mercury Interactive 公司生产的企业级项目管理工 具。