测试人员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的解决

上一篇:CentOS 7 socat命令端口转发 —— 筑梦之路


下一篇:机器学习-04-分类算法-01决策树