测试工程师-bug的组成要素
bug的组成要素:所属产品、所属模块、版本、指派开发、bug标题、严重程度、优先级、bug类型、重现步骤、附件等;
1、 所属产品、所属模块、版本、指派开发
根据相应的项目正确填写
2、bug标题
简要描述bug问题,以一个简练精确的句子描述某个模块存在的问题或者某个操作导致了什么问题。方便项目人员快速了解问题的内容,并且对于测试组后期进行问题盘点、问题交接以及问题回归时,也可快速进行bug分类。不规范的例子:
- 一个bug标题描写多个不同的问题
- 原标题如:【已经注册过的手机号缺少提示语,短信已经发送成功再次进行获取验证码没有返回任何提示信息】
- 优化如:bug1【已经注册过的手机号缺少提示语】;bug2【短信已经发送成功再次进行获取验证码没有返回任何提示信息】
- 原标题如:【已经注册过的手机号缺少提示语,短信已经发送成功再次进行获取验证码没有返回任何提示信息】
- bug标题描述不是一个完整的句子
- 原标题如:【订单页面跳转报错】
- 优化如:【销售订单页面跳转详情页面报错500】
- bug标题描述不清晰易误导多个理解意义
- 原标题如:【商品起购数大于库存数可保存】(描述不清晰。可大于还是不可?可保存还是不可?)
- 优化如:【销售单提交接口没有校验“商品起购数”需小于“库存数”】
- 点击[按钮]用[]括起来,条件值或字段名用“”括起来
- 原标题如:【订单查询页点击重置没有清空创建日期】(句子断点不清晰)
- 优化如:【订单查询页点击[重置]没有清空查询条件“创建日期”的输入框】
3、严重程度
致命:严重影响用户使用,如无法登录、系统崩溃、程序闪退
重要:重要功能未实现,如sql错误、接口错误
一般:(实际测试中存在最多)部分功能没有实现但是不影响使用,如查询时间长
建议:页面显示方面的建议;从用户角度出发提出建议
4、优先级
bug优先级跟bug严重程度一般都是对应的
1 - 需要马上修复
2 - 尽快修复
3 - 正常进度修复
4 - 可延后修复
5、bug类型
代码错误:程序代码编写不合理或错误导致的问题
界面优化:页面设计不合理、长宽不合适、颜色不合适等显示问题
设计缺陷:由于产品人员或设计人员功能设计不合理导致的问题
配置相关:环境配置不正确导致的问题
安全相关:重要数据在传输中没有加密、缺少身份认证机制
性能问题:与性能相关的问题
6、重现步骤
前提:可描述测试出现问题的环境,功能模块,测试账号,操作数据,需求描述等
步骤:描述清楚重现步骤;添加相应bug截图;报错信息复制文字黏贴在步骤里;查询sql写明等
预期结果:描述正确的预期结果
附件:特别是导入功能需要上传我们测试的导入文件、图片以便开发重现bug并解决
不规范的例子:
- 前提里没有描写清楚测试数据,如测试账号、测试模块、测试订单号等
- 步骤里缺少截图,截图能让开发一眼看到问题出现位置
- 步骤里截图的报错信息没有将文字复制出来
- 导入功能的bug,没有将附件上传上去
7、BUG解决方案
测试人员创建bug,开发人员修复bug后根据实际处理方案选择解决方案
设计如此
如bug描述问题与需求是一致的,则开发选择“设计如此”并在备注说明原因
重复BUG
如bug为重复bug,即之前已创建过相同的bug,则开发择“重复bug”并在备注内说明重复bug的ID
外部原因
如bug是由于外部原因导致(例如网络、第三方软件等导致的问题),则开发选择“外部原因”并在备注说明原因
已解决
如bug确实存在并已修复,则开发选择“已解决”并备注bug产生原因
无法重现
如开发根据重现步骤无法重现bug,则开发选择“无法重现”并在备注说明原因。建议开发遇到此类问题不要直接选择无法重现而是先联系测试进行复现
延期处理
如开发认为此问题严重级别不高、不影响功能使用、考虑到时间等原因需要延后处理,则开发选择“延期处理”并在备注说明原因
不予解决
如开发认为此问题不是问题或者无需修改,则开发选择“不予解决”并在备注说明不予解决的原因
以下图片是禅道提bug界面