Bug提交规范及注意事项:
一、BUG提交规范
目前所使用的JIRA系统中,BUG的内容主要包括以下要素:
| | | | | | | | | | | | | | | | | | | | | | | | | | | 在详细描述中,可对BUG产生的前提条件、操作步骤、实际结果、预期结果等进行描述 | | | | |
具体提交规范如下:
1. 现象描述
详细描述BUG的现象;
2. 测试环境
说明发现BUG的测试环境;
3. 前提条件
详细描述BUG产生的前提条件。例如浏览器,操作系统,移动设备组件版本,软件版本等;
4. 操作步骤
详细描述发现BUG的操作步骤;
5. 期望结果
描述预期正确的结果;
6. 实际结果
描述实际不正确的结果;
7. BUG严重性等级
初步判定BUG的严重性等级;
8. BUG优先级
判定BUG被修复的优先级别;
9. 附件
包括:BUG现象截图、操作产生的系统日志等;
注:严重等级以上BUG必须带有附件,一般性BUG则附件可选。
10. 备注
BUG补充说明信息,如:测试分析意见、其它设备有无类似情况等;
附BUG提交范例:
【前提条件】
操作系统:Win7
浏览器:IE10,Firefox 47.0.1
【操作步骤】
- 1. 首页,点击“我要注册”;
- 2. 打开注册页面,输入未注册过的手机号和密码
- 3. 点击 注册按钮;
【实际结果】
注册不成功,停留在当前页面
【预期结果】
注册成功,跳转至首页
二、BUG提交注意事项
1. 测试人员提交新缺陷时,尽量用最简洁的语言最清晰的描述出BUG的出处、操作步骤、现象、(建议),并尽量截图;
2. 当你的BUG报告以“不可重现”打回给你时,测试人员应该反复阅读它,集中剔除那些没有关系的步骤或词语,再检查是否有遗漏或清晰的步骤,再去找研发人员。
3. 测试人员在精简空话的同时,应该再仔细检查报告是否会产生误解的地方。测试人员应该尽量避免使用模糊的,会产生歧义的、主观的词语。目标是使用能够表述事实、清楚的,不会产生争执的词语;
4. 不要使用感叹号或其它表现个人感情色彩的词语或符号;
5. 不要使用含糊的词语(例如,好像,似乎)或网络语言来描述发现的现象;
三、Bug的类型
1. 文档缺陷:术语不一致,文档缺失,不易理解等;
2. 设计缺陷:需求不明确,操作便捷性等;
3. 配置缺陷:安装部署不成功,配置文件错误等;
4. UI 缺陷:风格不一致,界面不友好等;
5. 数据校验:数据长度,类型缺失校验;
6. 查询统计:查询结果列表异常等;
7. 功能缺陷:功能不可用;
8. 可靠性 :用户权限错误等;
9. 性能缺陷:查询性能,并发处理等;
10. 流程缺陷:流程不能流转,流程错误结束等;
11. 语言质量:字符未本地化,标点符号,商标符号错误;
12. 用户互动:与使用者互动不良;
四、Bug的等级划分
BUG等级是根据BUG出现在系统中的严重程度来分的。主要定义如下5级:
1. 致命BUG,包括以下各种错误:
1.1 由于程序所引起的死机,非法退出
1.2 死循环
1.3 导致数据库发生死锁
1.4 因错误操作导致的程序中断
1.5 严重的数值计算错误
2.严重BUG,包括以下各种错误:
2.1 功能不符
2.2 数据流错误
2.3 程序接口错误
2.4 轻微的数值计算错误
3.重要BUG,包括以下各种错误:
3.1 操作界面错误
3.2 打印内容、格式错误
3.3 简单的输入限制未放在前台进行控制
3.4 删除操作未给出提示
4.轻微BUG,包括以下各种错误:
4.1 界面不规范
4.2 辅助说明描述不清楚
4.3 显示格式不规范
4.4 长时间操作未给用户进度提示
4.5 提示窗口文字未采用行业术语
4.6 可输入区域和只读区域没有明显的区分标志
4.7 系统处理未优化
5.微小BUG:
5.1 界面重构、描述更改、流程改进
五、 Bug优先级划分
危机:要求立即修改,作为修改最高等级;
紧急:要求重点修改,产品发布前必须修复;
中等:需要尽快进行修改,产品发布前必须修复;
尽快:需要修改,如果时间允许应该修改;
不急:可能要修复,时间空余情况下进行修改。
六、其他注意事项
当发现一个BUG时,请注意下面的问题:
1. 同一软件中的相似功能是否有相同的问题?
2. 其他的浏览器是否有相同的问题?
3. 其他的软硬件配置是否有相同的问题?
4. 其他的区域是否有相同的问题?
5. 以前的版本是否有相同的问题? |