对由本组负责处理的BUG进行管理,通过对BUG的提交、跟踪解释、验证流程进行规范,提高BUG处理效率。
测试团队以及其他团队进行的BUG提交、跟进与解释、验证工作。
- BUG管理流程
提交BUG要求分类准确、描述简洁、步骤清晰、有实例、复杂问题有据可查(日志或截图)。各部门进行审核,以开发人员的角度来审查提交的BUG,确认测试人员已将BUG描述清楚。具体要求为:
- 一个禅道问题只针对一个Bug。
- 所有BUG必须统一录入禅道系统,不可以口头沟通私下解决。
- 提交BUG前需进行充分测试,尽量排除数据源、网络环境和配置等外部因素,确定提交的BUG是由程序导致的。
- 不允许仅仅用抽象、模糊和主观色彩的词语描述BUG,比如“有错误”、“不太好”、“好像、”“似乎”、“大概之类”。
- 提交人需尽量简洁清晰地描述BUG,描述时应尽可能简洁明了,只解释事实、演示和描述BUG相关的必要细节,避免无关信息。提交人可以写上自己对问题原因的主观分析,但不能和客观描述混杂在一起表述。
- 提交人在提交BUG前,应再次仔细检查报告中是否有可能产生误解的地方。尽量避免使用模糊的、可能产生歧义的主观性词语。
- *产品模块和所属项目:必须填写正确。
- *影响版本:需填写
- *当前指派:指派给对应的研发人员,如果不知道对应的研发人员可以指定给对应的研发负责人,让其分派给具体研发人员。
- *BUG标题:在某种前提下+简述操作过程+最后的结果。如:对会员数据,进行查询,结果无数据显示且无任何提示。
- *重现步骤:【步骤】【结果】【期望】三者写清楚。
- *相关需求:暂时不做要求。
- *相关任务:暂时不做要求。
- *严重程度:BUG级别分为1-4级;
严重性 | Bug等级说明 | 常见现象 |
1级 | 无法正常运行,因软件原因导致系统死机、数据丢失等,该级别需要程序员立即修改; | 程序报错无法进行其他业务的运行,引起无响应或者服务器直接宕机等; |
功能设计与需求严重不符; | ||
数据库发生死锁、数据丢失、数据通讯错误等; | ||
2级 | 主要功能丧失,严重影响系统要求或功能的实现,该级别需要程序员尽快修改; | 程序报错但能继续运行; |
无法完成功能的正常操作; | ||
数据错误; | ||
不符合需求定义范围; | ||
性能与需求不一致; | ||
3级 | 影响系统正常运行,主要功能出现错误,该级别需要程序员修改; | 非常规操作出现错误; |
删除操作未给出提示; | ||
常规操作未给提示; | ||
可编辑区域和只读区域没有区分标志; | ||
用户体验较差,操作不方便,但不影响功能实现; | ||
数据输入没有边界值限定或不合理; | ||
4级 | 操作不合理或者不方便,建议类错误,不影响执行工作功能,对软件的改进意见或建议,该级别问题程序员可时间充足时再修改; | 易用性问题(未给出提示信息或提示信息不统一); |
缺少注释或注释表达不清晰; | ||
查询等操作响应时间过长; | ||
建议类问题; | ||
界面设计不规范,如UI不统一、文字排列不整齐、出现错别字、字体不一致等问题; |
- 附件:对于不易通过文字描述的BUG,提交人应将界面截图作为附件上传;对于崩溃、宕机现象,必须将程序日志作为附件上传。
- 其他内容:都为选填。
在BUG“新建”到“已关闭”期间,尽量使用禅道系统的注释功能进行沟通。
当BUG被以“不必改”、“无法重现”理由关闭,测试人员应仔细阅读研发人员的注释内容,再次检查报告中是否有遗漏和歧义的地方,确认无误后再进行处理。
在问题被研发人员设置为“已解决”后,测试人员应在新版本形成后一周内完成验证或以注释形式说明情况。
- 如果该BUG已解决,则在禅道中关闭问题;
- 如果该BUG仍然出现,则在禅道中反馈问题并说明情况;
- 如果验证过程中发现了新BUG,则在禅道系统中新建问题进行跟踪。