软件测试发现缺陷/bug如何提问题单？（附问题单模板）_bug清单模板

背景

一般软件测试面试的时候都会回答提问题单的问题，校招一般会问问题单都有哪些类别，社招的话会问提过哪些有价值的问题单，本文就先介绍问题单的组成和模板，举例内容软硬件都有，纯软件测试可以假想一款APP套用该模板即可，问题单的生命周期和流转可以参考我的另一篇文章：【还没写出来，先放个空链接】

问题单模板概述

1、标题

问题单标题：【项⽬名称】【模块】【⼦模块】问题现象简要描述

【例】：【XX项目】【⽹⼝】【⾃协商】配置网口XXX后，网口状态应为link up，实际为link down

【项目名称】

⼀般缺陷都在pingcode，禅道等项目管理平台上对应的测试库中提单，默认为当前所在项⽬，可省略，跨项目的同类问题单可互相关联

【模块】【子模块】

根据问题现象和初步定位结论简单分类，例如：

• 【网口】【⾃协商】表示网口自协商存在问题

【问题现象】

简单描述操作步骤，预期结果和实际结果，例如：

• 配置XXX后，网口状态应为link up，实际为link down

2、描述

问题单描述：【项⽬名称】【模块】【⼦模块】问题现象简要描述

【例】：【XX项目】【网口】【自协商】配置网口XXX后，网口状态应为link up，实际为link down

【预置条件】

是否有⼀定要具备的条件才会触发该问题，没有可不填，例如：

• 将板卡放⼊65℃温箱运⾏1.5h（⾼温下才会丢包）

【复现步骤】

写清楚该问题的复现路径，如果是偶现问题，在实际结果中注明概率，问题⼀般都是在执⾏测试⽤例 时出现，这⼀步可以完全复制测试⽤例的执⾏步骤，例如：

1. 将⽹⼝1和⽹⼝2使⽤1000M⽹线直连
2. 配置⽹⼝1为XXX
3. 配置⽹⼝2为XXX

【预期结果】

描述如果没有该问题出现，预期中应该出现什么样的结果，例如：

1. ⽹⼝1和⽹⼝2的状态都为link up

【实际结果】

描述该问题的具体现象，与预期符合的任何不⼀致都应该详细描述，以便开发⼈员分析定位，例如：

1. ⽹⼝1和⽹⼝2的状态实际都为link down

【初步定位】

描述开发⼈员的初步定位结论，如果没有开发定位，可以填写⾃⼰的初步判断，例如：

• 开发A已初步定位，怀疑为PHY读写问题
• 开发B已初步定位，暂⽆结论
• 暂⽆开发定位，个⼈怀疑为PHY读写问题
• 暂⽆开发定位，暂⽆结论，提单跟踪

【问题单责任人】

该问题单提交给哪位开发解决，可以为初步定位⼈员，也可以为项⽬经理，让其分配给对应的开发解决问题，随着问题定位的深⼊，实际责任⼈可以发⽣变化和转移，例如：

• 责任⼈为初步定位⼈员A，后发现该问题确实应该由A修改
• 初步定位⼈员A觉得该问题应该转交给B解决，责任⼈为B
• ⽆开发定位该问题或问题范围不明确，责任⼈为项⽬经理，由其转发给对应的开发⼈员进⾏定位

【附件上传】

上传问题出现前后时间点相关的软件截图，⽇志信息，错误码/报错信息，⽤于辅助研发⼈员定位，例如：

• 出现问题时的软件状态截图
• 出现问题前后的⽇志打印信息

3、其他信息

【版本信息】

填写相关的软硬件版本信息，以便统计版本问题数量以及回溯，例如：

• 第⼆批⼯⼚批量⽣产板卡
• 固件版本为V1.0.2

【严重程度】

说明该问题的严重程度，分类依据如下：

1. 致命错误：造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧 失，基本模块缺失等问题
2. 严重错误：系统主要功能部分丧失，数据库保存调⽤错误，⽤⼾数据丢失，以及功能菜单不能使⽤ 但是不影响其他功能的测试。功能设计与需求严重不符，模块⽆法启动或调⽤，程序重启，⾃动退 出，关联程序间调⽤冲突，安全问题、稳定性等
3. ⼀般错误：功能没有完全实现但不影响使⽤，功能菜单存在缺陷但不影响系统稳定性
4. 建议问题：界⾯，性能缺陷，建议类问题，不影响操作功能的执⾏，可以优化性能的⽅案等。如： 错别字、界⾯格式不规范，⻚⾯显⽰重叠、不该显⽰的要隐藏，描述不清楚，提⽰语丢失，⽂字排 列不整⻬，光标位置不正确，⽤⼾体验感受不好，可以优化性能的⽅案等

【优先级】

说明处理该问题的先后顺序，优先级越⾼越先修复，原则上与上述严重程度⼀⼀对应，但不排除有些 例外情况，例如：⽤⼾界⾯存在错别字，严重程度很低但优先级较⾼；具体分类依据如下：

1. 紧急：缺陷严重且紧急，必须⽴即修复
2. 较⾼：主要功能错误或者造成软件崩溃，须尽快修复
3. ⼀般：软件次要功能错误，按排期修复
4. 较低：对软件质量影响⾮常轻微或出现概率极低的缺陷，按排期修复

【复现概率】

其实任何缺陷在满⾜特定的条件时都是必现的，这⾥的复现概率只是说 问题出现次数÷测试总次数 的⼀个百分⽐结果，具体分类依据如下：

1. 必现：只要按照问题单中的复现步骤操作后，⼀定会出现
2. 偶现：按照问题单中的复现步骤操作后，概率性出现，写明出现的实际概率，例如：4/9（9次出现 4次），根据出现概率分为：⼤概率出现&⼩概率出现
3. 仅出现⼀次：某次测试中突然出现的问题，按照当时的测试步骤也不能复现，记录测试步骤和问题 现象以便于持续跟踪

【缺陷类别】

该问题的类别归属，属于功能/性能/兼容性等问题，具体分类依据如下：

1. 功能问题：不符合软件设计的功能指标
2. 性能问题：不符合软件设计的性能指标
3. 兼容性问题：不符合软件设计的兼容性指标
4. 其他问题：UI，安全性等问题，此处不再展开举例

【关注人】

该问题需要某些模块⼈员特殊关注，应该添加硬件负责⼈为关注人；或者该问题较为严重，影响项⽬ 整体进展，应该添加项⽬负责⼈/项⽬经理为关注⼈

真·问题单模板

标题

【XX项目】【⽹⼝】【⾃协商】配置⽹⼝XXX后，⽹⼝状态应为link up，实际为link down

描述

【预置条件】

将板卡放⼊65℃温箱运⾏1.5h

【复现步骤】

1. 将⽹⼝1和⽹⼝2使⽤1000M⽹线直连
2. 配置⽹⼝1为XXX
3. 配置⽹⼝2为XXX

【预期结果】

1. ⽹⼝1和⽹⼝2的状态都为link up

【实际结果】

1. ⽹⼝1和⽹⼝2的状态实际都为link down

【初步定位】

• 开发A已初步定位，怀疑为PHY读写问题

【问题单责任⼈】

• 初步定位⼈员A觉得该问题应该转交给B解决，责任⼈为B

【附件上传】

• 出现问题前后的⽇志打印信息

其他信息

【版本信息】

• 固件版本：V1.0.2

【严重程度】

• 严重错误

【优先级】

• 较⾼

【复现概率】

• 偶现

【缺陷类别】

• 功能问题

【关注人】

项⽬主管A，开发⼈员B

总结

如果校招面试，上述内容已足够；实际问题单详情还是依据公司和项目的实际情况来处理，祝各位学习工作顺利！