BUG提交规范文档

 一 概述

1.编写目的

在软件测试阶段经常出现开发人员看不懂或者理解错误测试人员提交的Bug描述这种情况，增加了开发人员和测试人员沟通工作，从而浪费了不必要的时间和人力成本，为尽可能避免这种情况发生而编写此文档来优化测试流程，并加强Bug描述的可读性。

2.读者对象

本文档的主要读者为软件开发项目管理者、开发工程师、测试工程师。

二 BUG提交规范

1.TAPD系统中BUG的主要要素

元素	说明
缺陷ID	Bug的唯一标识，由TAPD自动生成
项目名称	每个测试项目都有唯一的名称
关联需求	选择对应的需求项(非必填项)
发现版本	选择发现问题的版本号
关闭版本	选择关闭问题的版本号
验证人	填写验证问题的人员姓名
发布计划	选择对应的发布计划项
模块	当前Bug属于哪一端
优先级	Bug解决的优先级，等级越高越紧急
严重程度	Bug的严重程度
开发人员	对应的开发人员，如不清楚就提交给组长
处理人	负责修复该Bug的人员
抄送人	需要知道该Bug的人员，比如美术产生的bug需要通知到开发人员
重现规律	提交该问题时总结的该问题的复现概率，后续发生变化后及时更改
第二轮bug原因	开发人员根据实际情况进行填写
拒绝原因	开发人员在将状态修改为拒绝时选择拒绝原因
描述	在详细描述中，对BUG产生的前提条件、操作步骤、实际结果、预期结果等进行描述
附件	提交BUG时，可上传必要的附件。（截图，视频，日志等）

2.具体提交规范

2.1 标题

标题要求简明扼要的阐述问题本质，使查看人员能快速了解Bug内容。需要写明在哪个页面执行什么操作出现什么现象。

特别提醒：

1.标题中标点符号不能超过1个

2.标题中不能含有测试流程步骤

3.明确操作内容，语句表达明确，避免歧义，涉及到数字的操作，尽量明确数字，避免模糊的“多次”、“长时间”之类的描述

2.2 测试环境

说明发现BUG的测试环境，也可在右侧环境选择（需项管添加该项），一般包含测试环境、预发布环境、正式环境。

2.3 前提条件

明确指出所提交的Bug是在怎么样的情况下出现的，例如账号登录状态、网络类型等。

2.4 操作步骤

要简明清晰分步骤描述如何复现Bug问题，步骤用序号编排。

要按照自己的操作的实际步骤写清楚每一步是怎么操作的，最后操作到哪个页面或者点击哪个按键。

如在特定情况下发生的问题，还需明确提供以下信息：

1.准确写出连续点击次数，点击时长与上下滑动屏幕时长

2.对于特定数据产生的问题，提供具体数据

3.精准描述bug产生的路径后，再描述现象

特别提醒：测试步骤中的点击要用>符号连接

2.5 期望结果

按照测试步骤应当得到的正确结果，按照产品需求的期望清晰准确的填写预期结果。而且结果必须是无疑义，可判定性的结果。

特别提醒：期望结果不要包含测试步骤，要是简单的一个结果

2.6 实际结果

按照测试步骤实际出现的错误结果，避免使用“不正常”，“有误”等模糊词汇，需要直接描述实际现象。

特别提醒：期望结果和实际结果要相互对应

2.7 严重等级

初步判定BUG的严重性等级，根据BUG出现在系统中的严重程度来分的。主要定义如下5级：

1.致命BUG，包括以下各种错误：

1.1常规操作引起的系统崩溃、死机、死循环
1.2造成数据泄漏的安全性问题，比如恶意攻击造成的账户私密信息泄露
1.3涉及金钱，如支付类软件，金钱计算错误

2.严重BUG，包括以下各种错误：

2.1重要功能未实现（例如：微信不能发朋友圈）
2.2错误的波及面广，影响到其他重要功能正常实现
2.3非常规操作导致的程序崩溃、死机、死循环 (非常规操作：用户使用软件时不会进行的操作）
2.4外观难以接受的缺陷（例如：直播平台的封面图片的失真、压缩，完全变形）
2.5密码明文显示

3.一般BUG，包括以下各种错误：

3.1次要功能不能正常实现
3.2操作界面错误（包括数据窗口内列名的定义，含义不一致）例如：列名与列名下的内容不一致
3.3查询错误、数据错误显示
3.4简单的输入限制未放在前端进行控制；（格式显示，如登录和注册中的格式判断可由前端判断）
3.5删除操作未给出提示

4.提示BUG，包括以下各种错误：

4.1界面不规范
4.2辅助说明描述不清楚
4.3提示窗口文字未采用行业术语
4.4界面存在文字错误

5.建议BUG：

5.1 可以提高产品质量的建议，包括新需求和对需求的改进

2.8 优先级

判定BUG被修复的优先级别，划分标准如下：

紧急：立即反馈开发处理

高：需开发24小时内处理完

中：需开发36小时处理完

低：需开发48小时处理完

无关紧要：项目发版之前/之后解决

2.9 复现概率

复现概率一定要在多次测试的基础之上填写，若必定复现则填写必现，若偶现，请执行多次后统计概率填写。

2.10 附件

UI类型：Bug需要上传截图，并且增加相应的红框标识

功能类型：上传视频文件或者截图（增加相应的红框标识）。必要时用fiddler或者charles抓包，将请求值和返回值截图上传

崩溃类型：上传Log并且Log不得超过10分钟，在抓取前清除日志缓存

2.11 备注

Bug补充说明信息，如：其它设备有无类似情况、线上版本有无此问题等。

三 BUG流转

1.BUG生命周期流程图

2.注意事项

2.1 开发人员拒绝BUG时

1.重复的Bug：在评论里附上被重复的Bug链接

2.无法复现的Bug：首先确认开发环境和测试环境是否一致，操作步骤是否正确，如确实无法复现，与测试人员确认后再更改状态

3.解决成本高：先与产品人员进行确认，产品认可后方可修改状态

2.2 测试人员处理拒绝状态时的BUG

1.认可拒绝理由，关闭Bug

2.不认可拒绝理由或者不清楚该理由是否可接受，与测试负责人协商确认

3.开发以不合理的原因拒绝Bug，沟通后拒不修改，将此情况反馈给测试负责人

2.3 BUG挂起

Bug挂起前需要得到产品人员的认可

2.4 测试人员对偶现BUG的处理方式

1.抓取Log、截图、视频；

2.仔细回忆，记录前置环境、操作步骤、使用过的数据；

3.尝试去重现；

4.当发现尝试多次仍无法重现时，先给开发提单，附上能取到的所有日志及截图、详细前置环境及操作步骤、可初步的注明Bug出现的概率（十分之一、百分之一、千分之一）；

5.对Bug进行评估，确定优先级，如果优先级高的话，将Bug单发给组内的同事，让大家帮忙关注该Bug；

6.与开发沟通，猜测可能出现问题的地方，让开发协助查看代码走向，添加状态打印信息，进行有针对性的测试。仍旧无法重现，我们一般需要把Bug保留3个版本，持续关注（测试人员每验证一个版本在Bug下添加备注XXX版本验证XX次是否复现）。并且需要关注发布后的用户反馈，跟进Bug。