老司机教你-BUG编写技巧
一、BUG标题1、需包含Bug的具体位置，并以【】标注，举例：【模块-渠道】
【MKT_H5】
【MKT_PC】
【MKT_H5_PC】
【MKT_Android_app】
【MKT_IOS_app】
【MKT_iphoneX】
【MKT_iphone6 plus】
【MKT_Android_Chrome浏览器】【MKT_APP_Chrome浏览器】
【MKT-ipad模拟器】
2、需写明具体页面、或具体组件，或具体区域，以及操作、现象
【模块-渠道】XX页面，XXXXXXXXXXXX
【模块-渠道】XX组件，XXXXXXXXXXXX
3、非test阶段，需标注影响环境
【MKT_UAT_PC】
【MKT_Prod_H5】【MKT_Prod_PC】
4、标题清晰简洁
5、明确说明问题（不能只是说出现问题）
6、使用有意义的单词
7、长度尽量控制在30字以内
8、切勿出现错别字
错误示例： 奔溃（崩溃），电击（点击），登陆，（登录），重置（充值），现实（显示）
9. 标题组合形式
模式1：BUG【模块-渠道】+ Bug页面 + BUG操作 + BUG的结果
模式2：BUG【模块-渠道】+ Bug页面+ BUG的结果：
【MKT-PC】优惠活动详情页，会员领取组件，优惠券的缺口不是透明的
模式3：BUG【模块-渠道】+ Bug页面+ BUG的期望：
【MKT-PC】活动落地页，酒店列表的折扣标签字号应为14px
模式4：BUG【模块-渠道】+ 组件名称 + 区域 + BUG操作 + BUG的结果：
【LessCode_H5】富文本组件，数据区，插入表格，输入框被遮挡了
模式5：BUG【模块-渠道】+ 组件名称 + BUG操作 + BUG的结果：
【MOTO_Android_app】选择优惠蒙层，输入推广码点击使用后，手机键盘没有收起来
对比以下哪种描述更好：
【LessCode_PC】编辑区，酒店组件的折扣标签字号不是14px （结果）
【LessCode_PC】编辑区，酒店组件的折扣标签字号应为14px （期望）
【LessCode_PC】编辑区，酒店组件的折扣标签字号错误，应为14px （结果+期望）
二、BUG描述-前置条件
1、明确指出所提交的Bug是在怎么样的情况下出现的，当所发现Bug前提条件为空时，需要填【无】。
2、特殊条件下的Bug必须详细描述产生Bug的前提。示例：
3、只有在使用附件中的图片（大图片：60M）时，会出现此Bug。
登录账号
访问链接
三、BUG描述-重现步骤
1、要简明清晰分步骤描述如何复现Bug问题，步骤用序号编排。
2、要按照自己的操作的实际步骤写清楚每一步是怎么操作的，最后操作到哪个页面或者点击哪个按键。
3、如在特定情况下发生的问题，还需明确提供以下信息：
4、准确写出连续点击次数，点击时长与上下滑动屏幕时长。
5、对于特定数据产生的问题，提供具体数据。
6、精准描述bug产生的路径后，再描述现象。
特别提醒：测试步骤中的点击要用->符号连接
复现步骤描述及概率
描述复现步骤中的页面切换为避免出现描述不清晰或者有歧义，需用“->”符号连接
关于复现概率一定要在多次测试的基础之上填写，若必定复现则填写100%，若偶现，请执行多次后统计概率填写。
四、BUG描述-截图
Bug需要上传截图，并且增加相应的红框标识；
有多个图片时，尽量组合汇总在一张图，便于打开时一目了然
五、期望结果
按照测试步骤应当得到的正确结果，按照产品需求的期望清晰准确的填写预期结果。而且结果必须是肯定无疑义，可判定性的结果。
特别提醒：期望结果不要包含测试步骤，要是简单的一个结果
注意：避免提出的期望不合理，而开发直接按不合理的期望实现
需求期望
行业通识期望 （可能有歧义，建议先沟通，再提单，或者bug中备注）
常识期望
建议优化 （可能有歧义，建议先沟通，再提单，或者bug中备注）
六、BUG附件
Bug的附件中包含的截图需增加相应的红框标识，便于Bug的定位。
所提Bug附件的命名需要与Bug标题相呼应
错误示例：视频20168377894872.MP4
Bug中的视频附件需采用MP4格式，不能出现非Mp4格式视频
附件命名需与标题相呼应，必须注明出现bug的时间点
文件名称不能出现怪异冗长
七、BUG严重级别
P1-致命：致命性问题-系统无法启动、系统无故重启、冻屏、爆音；阻塞开发/测试工作，生产无法进行，需要紧急解决的问题；系统崩溃，数据丢失，严重的内容泄露的问题；
由于程序所引起的死机，非法退出
死循环
数据库发生死锁
因错误操作导致的程序中断
与数据库连接错误
P2-严重：主要功能缺失，或功能使用上有严重障碍的问题；
程序错误
程序接口错误
数据库的表、业务规则、缺省值未加完整性等约束条件
P3-高：商品性的问题（功能已实现，但使用上不便的问题）；次要功能缺失，或功能已实现，仅UI或控件元素与需求不符的问题；
操作界面错误（包括数据窗口内列名定义、含义是否一致）
简单的输入限制未放在前台进行控制
删除操作未给出提示
数据库表中有过多的空字段
P4-中：功能没有完全实现但是不影响使用，功能菜单存在缺陷但不影响系统稳定性（一般、界面、性能缺陷、兼容性）
输入输出不规范
长操作未给用户提示
提示窗口文字未采用行业术语
可输入区域和只读区域没有明显的区分标志
操作时间长
查询时间长
格式错误
边界条件错误
删除没有确认框
P5-低：次要、易用性及建议性问题
错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排版不整齐，光标位置不整正确，用户体验感受不好，可以优化性能方案（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）
八、BUG优先级
紧急 即“急需解决”，表示问题的修复很紧要，很急迫，关系到系统的主要功能模块能否正常。
高 即“高度重视”，表示有时间就要马上解决，否则系统偏离需求较大或预定功能不能正常实现。
中 即“正常处理”，进入个人计划解决，表示问题不影响需求的实现，但是影响其他使用方面，比如页面调用出错，调用了错误的等。
低 即“低优先级”，即问题在系统发布以前必须确认解决或确认可以不予解决。
备注：严重性和优先级并不总是一 一对应。有时候严重性高的软件缺陷，优先级不一定高，甚至不需要处理，而一些严重性低的缺陷却需要及时处理，具有较高的优先级。 支持下！ 谢谢分享:lol
页:
[1]
