测试人员Bug书写规范

📋 个人简介

•  作者简介：大家好，我是凝小飞，软件测试领域作者
• 支持我：点赞👍+收藏⭐️+留言📝

在测试人员日常工作中，关于bug的编写和定义是一个比较经常的工作，如果bug编写描述的不清楚的话，影响到bug修复的效率，同时也会增加和开发同学对于bug的争执。下面就介绍一下，我在曾经的某个项目中梳理的组内bug测试编写规范。供大家参考。

一、缺陷管理流程

Jira中可以自定义流程，如下是一个经过实践的普遍的bug流程

二、缺陷编写规则

1．[项目]:必选，如番茄炒蛋

2．[问题类型]:必选。如缺陷，改进

3．[主题]:

标题一定要简洁明了！标题一定要简洁明了！标题一定要简洁明了！

[应用+版本][复现概率][机型][测试类型][服务端环境] 场景+操作+结果

解析：

[应用+版本]: 必选。如番茄炒蛋1.0.1.1027

[复现概率]：必选。格式只有三种，格式只有三种，格式只有三种，如下

[偶现N/10]、[有一定概率N/10]、[必现]

1. 偶现的S1/S2级严重的问题需要验证10次
2. 概率定义
   1. 偶现:10次测试，出现N次，1≤N≤2 
   2. 有一定概率: 10次测试，出现N次，2＜N＜10
   3. 必现：S1/S2级问题必须验证3到5次，连续出现，根据经验排断是必现的，即可. 单台必现，标题写必现，在bug描述里的概率部分写上单台必现。

[机型]：可选，特殊手机可填写 

[测试类型]：可选，不写默认是功能测试，否则建议写上稳定性、容错等标签

[服务端环境]：可选，不写默认是线上环境，否则写上测试环境，预发环境

场景+操作+结果：

这个是考验语文水平的时候了，这里可以有主语、谓语、宾语、定语、状语、补语组成，我泱泱大国文化源远流长 … 此处省略1万字 … 简单的说就是，在哪里做了什么发生了什么问题

也许你的操作步骤、前置条件很多，想表达的很多，但是，请写到步骤里去。 这里的描述字数不超过30个字

4．[优先级]:必选。

5．[到期日]:必选。

6．[模块]:必选。下拉选择，如无所选模块@项目责任人增加，我们为电商应用模块

7．[影响版本]:下拉选择，如无所选版本@项目责任人增加，比如班车测试中都会需要填写当前版本测试的版本。

8．[解决版本]:开发填写解决版本，创建时候可以不写

9．[经办人]:直接找接口人确认开发人员

10．[环境]:目前的验证环境，wifi，或者3G/4G，预发环境

11．[描述]:

语文老师说过，写文章要虎头猪肚豹尾，Bug描述就相当于猪肚，标题里没来得及表达的，这里可以尽情表达了，举个栗子说明一下：

[应用版本]：

填写测试的版本

[系统版本]：

填写测试手机的版本

[前置条件]: 

比如: 网络情况、账号登陆情况、后台配置情况等

1、有网络

[重现步骤]：

这里的步骤一定要清晰，切勿句式杂糅，切勿,一般来说，一个操作一个结果，最后一步出问题的结果，就写在实际结果里。

[实际结果]：写实际出现的情况

[期望结果]：写期望出现的结果

[概率]：必现3/3 ，验证3次，出现3次。

 台必现属于必现，也可以在这里备注

[恢复步骤]：退出再进入可以恢复

比如重新进入退出是否可恢复、重启是否可恢复等

问题恢复的操作，请按如下顺序测试，一旦可恢复，不需要验证后续步骤。

1. 按返回键再进入
2. 按home键再进入
3. 重启

其它恢复步骤建议也写上，比如播放过程中出现花屏马赛克，不需要操作即可恢复。

[备注]：

严重问题，建议写上

1）其它机型的对比情况：

2）其它场景的对比情况：

恢复步骤和备注是个加分项，也是体现一个人能力和思维考虑周全的地方

[测试员]：  提交人

12．[附件]:

日志：

应用一定附上logcat日志，也有可能需要bugreport, trace，或者开发特殊需求的日志。

当日志比较长, 建议写上问题发生的时间点。

严重问题或者应用系统卡死导致日志不好抓时可以保留现场给开发。

截图和视频：

可选，当描述不太清晰，步骤有点复杂的时候，请附上截图或者视频。

13．[抄送用户]:抄送开发与测试相关人员，更快推进bug的解决