Bug的分类与严重程度
bug分类 （禅道为例）
1）功能缺陷：业务流程未实现
2）代码错误：错误页面404、500
3）界面优化：UI问题、图文显示
4）安装部署：安装失败、无法访问等
5）性能问题：响应时间久、加载慢
6）安全相关：密码明文显示
7）其他：易用性、兼容性
8）设计缺陷：需求缺陷
bug严重程度
1)致命的（最高）：系统崩溃、死机、死循环、数据库数据丢失、数据库连接失败、主要功能丧失、重要的一级菜单不可用
2)严重的（高）：主要功能部分丧失，数据库保存、提交调用错误、功能设计与需求严重不符、自动退出，稳定性差、数值计算统计错误
3)一般的（中）：功能没有完全实现存在缺陷但不影响系统稳定性（查询时间长、格式错误、边界值错误、删除没有确认、数据表字段过多——一般12个左右）
4)轻微的（低）：兼容性、界面优化，不影响正常功能使用，错别字、页面显示重叠、提示语丢失
5)建议性（很低）
bug优先级（开发修改问题的顺序）——开发选择
1）非常紧急
2）紧急
3）一般
4）不重要
面试题：严重程度越高优先级就越高吗？
不一定，严重程度高的优先级可能会相对紧急一些。
例如：12306的登录页面吧录字写成了大陆的录，使用用户很多，直接影响到了使用感受，这就是一个紧急而不严重的问题。
bug状态
1、待确认（提交–激活）：测试人员或用户发现新问题后提交的状态
2、已确认：经测试开发讨论确认是bug,提交的状态，由开发人员点确认按钮
3、已处理（已解决）：开发确认是bug后修复的状态，修改还没验证，由开发人员来设置状态
4、已修改（已关闭）：bug的最终状态，测试通过，由测试人员来设置
5、仍存在（重新打开）：测试未通过，bug未修复成功，问题仍然存在，由测试人员设置
6、不是bug：研发认定不是bug/建议或者意见决定不采纳，开发人员来设置
7、暂不处理（挂起）：当前版本不做修改，后续版本再考虑，或不确定是不是要解决需要时间来确定，由测试或者开发来设置
bug跟踪流程：
**测试人员发现问题之后有2种情况**：
一种是不确定时找领导确认，如果领导确认这是个问题那么就创建问题，如果大家一致认为不是一个问题就放弃掉；
另一种是测试人员确定这是个问题就直接创建问题；
创建问题之后提交给开发，开发判断拿到这个问题之后判断是不是问题，如果不是直接放弃，如果是进行修复，修复解决完问题之后，测试人员来验证问题；
验证通过之后问题直接关闭，如果验证不通过仍然存在问题时重新开启，再次提交给开发，开发再次进行处理，解决问题之后我们再次验证直至验证通过问题关闭。
bug详细描述
【所属项目】关联的项目名称
【影响版本】问题出现的版本
【当前指派】处理人
【截止时间】处理的截止时间
【bug类型】bug分类
【操作系统】测试使用的什么系统
【浏览器】测试使用的浏览器
【bug标题】描述问题，简明扼要
【重现步骤】使用1、2、3的形式进行说明
【结果】操作后出现的问题描述
【预期】操作后出现的正确现象
提bug的目的
1、记录对应的问题，避免因为没有对应的记录过程而导致开发漏修复和测试人员漏测
2、阐述对应的操作步骤
3、整个问题从提出到修改，到解决形成一个闭环，毕竟bug的过程有可能会有不同的流程走向
创建高质量的bug
1)标题：简明扼要的描述bug,可以让人快速了解问题
2)测试环境：发现问题的软件/硬件系统，什么版本，如果需要还要注明哪个硬件平台
3)前提条件：用户测试步骤前的系统环境信息
4)提交步骤：在执行什么的操作时，发现的问题
5)实际结果：在测试软件的过程中，软件本身表现出的结果，可能与预期结果有出入
6)预期结果：软件设计所要求达到的需求本身达到的目的，预期目标
7)附件：图片说明
与开发沟通
1)确保自己提交的是个bug，并且可以重现
2)如果开发有疑问，或者说没有bug的时候，我们可以从用户的角度去解释使用系统时的，用户这样操作的不便
3)bug需要写清楚，或者描述清楚，开发人员在了解问题后，可以准确的定位
4)跟开发人员确定清楚、修改这块后，主要影响那里，会对其他的模块有影响没，有的话，我们需要重新关注
5)注意语言和沟通的用词
提单是基于需求的粒度去提单
参考文献：
无
备注：
如有侵权，邮箱联系，实属抱歉。
此只为学习个人笔记整理，同时如有转载请注明出处。
联系邮箱：wengyao1234@outlook.com
一同学习测开技企鹅群（闲聊，水群，广告勿扰）：826471103
2286
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
