软件缺陷等级
缺陷管理规范
一、 定义
软件缺陷，通常又被叫做bug或者defect，即为软件或程序中存在的某种破坏正常运行能力的问题、错误，其存在会导致软件产品在某种程度上不能满足用户的需求。
软件缺陷是指存在于软件（程序、数据、文档中的）那些不符合用户需求的问题。
1）软件未实现需求原型要求的功能
2）软件出现了需求原型指明不应该出现的错误
3）软件实现了产品说明书未提到的功能
4）软件未实现产品说明书虽未明确提及但应该实现的目标
5）软件难以理解、不易使用、运行缓慢或者从测试员的角度看最终用户会认为不好，即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷
二、目的
1、提交高质量缺陷，利于研发快速处理缺陷，减少无效bug率。
2、详细的缺陷起因与修复细节，利于研发间问题流转减少沟通成本，研测问题流转减少回归漏测风险。提高问题处理效率与版本质量。
3、明确的需求缺陷，利于需求问题回溯，推动需求变更或需求规划
三、缺陷优先级
|
优先级 |
定义描述 |
子类型 |
|
|
紧急 |
导致系统无法继续使用下去，必须立即修复，对用户产生很大影响必须优先解决 |
编号 |
名称 |
|
101 |
系统宕机、服务崩溃 |
||
|
102 |
接口响应500、504、502、404等等 |
||
|
103 |
数据库错误、客户数据丢失 |
||
|
104 |
接口响应超时频率超过50% |
||
|
105 |
业务操作或测试流程无法进行下去 |
||
|
107 |
页面无法正常控件不可点、核心页面无法加载 |
||
|
108 |
存在重大安全隐患XSS、CSRF、SQL等注入或者越权问题 |
||
|
109 |
重大UI问题或者事故，如导致用户无法使用，产品页面无法操作等 |
||
|
高
|
缺陷严重需要高度重视，优先解决 |
201 |
功能未实现或功能完全缺失，如排序功能完全缺失，或者失效 |
|
202 |
主要功能实现和需求要求不符（如实现图表饼图展示实际是柱状图） |
||
|
203 |
明显的卡顿耗时较久影响测试，如5~8s接口或者页面加载 |
||
|
204 |
字段计算结果错误、多处相同数据不一致 |
||
|
205 |
业务功能实现有问题，点击控件操作未对生效，接口对数据库未生效 |
||
|
206 |
编码时数据类型或者长度定义错误 |
||
|
207 |
基础的业务测试数据缺失导致无法继续测试，如数据库字段数据缺失 |
||
|
208 |
系统兼容导致的功能无法使用 |
||
|
209 |
用户正常操作，但是功能错误影响后续部分测试 |
||
|
210 |
主要功能页面UI设计的未实现或者部分未实现的问题 |
||
|
中 |
缺陷需要正常排队修复，或者列入发布需解决问题清单 |
301 |
滚动轴失效、跳转分页不正确 |
|
302 |
时间控件时间范围没有限定 |
||
|
303 |
次要功能异常，但不影响主要功能使用，如排序、只可部分条件筛选 |
||
|
304 |
兼容适配问题让用户功能使用操作不便的 |
||
|
305 |
用户输入边界超出正常范围，输入类型错误导致的越界报错或者空指针 |
||
|
306 |
前后端message提示错误或者文案错别字、字体大小不一致 |
||
|
307 |
次要功能页面UI设计的未实现或者部分未实现的问题 |
||
|
低 |
缺陷可在开发有时间时进行修复，不影响正常的发布上线，不影响用户功能使用 |
401 |
兼容适配问题不影响使用操作修复会更加提升体验的（低版本浏览器、市占较低的机型） |
|
402 |
建议类bug可提升用户体验，不修不影响发布版本 |
||
|
403 |
延期处理的缺陷（开发确定是缺陷，不影响当前上线，开发可在上线后处理） |
||
|
404 |
挂起的缺陷（受技术实现、短期无法解决、偶现触发的的功能问题） |
||
|
405 |
提示信息表达不清晰，容易引起歧义的提示 |
||
|
406 |
使操作者不方便或遇到麻烦，但它不影响功能的操作和执行 |
||
|
407 |
UI文字文案样式错乱、未做换行截断处理，部分被遮挡 |
||
|
408 |
易用性问题： 1、系统状态对用户不可见（进度条：告知用户进度，增加用户掌控感，toast提示框未及时消失（toast不要打断用户操作） 2、违背场景贴切原则（贴切用户所在的真实环境。把复杂的系统语言换成用户看得懂的语言） 3、图形表意不明确（如大家看到闹钟、计算器、照相机这几个图标就知道它们是干什么的） 4、违背可控性原则（让用户具有对产品的控制性与自由度，也就是要给用户留条后路比如删除、清空等功能。用户在删除的时候也是会有一定的焦虑感，可以提供撤销） 5、违背一致性原则（比如按钮、表单的用语需保持统一，设计字体、色彩、图片等设计语言都遵循同一套设计规则，操作习惯的一致性：与用户预期保持一致性） 6、违背防错原则（用户可能犯错时进行提醒，防止用户出错如提示语、置灰禁止、负向操作二次确认，不要等到用户所有步骤都操作完了才提醒，操作过程中及时提醒） 7、违背协助记忆原则（模糊查询） 8、违背灵活高效原则（新用户更重视易用性，老用户更重视效率性。让产品灵活多变，满足不同用户的需求偏好，无论是引导页、操作手册、还是开屏广告，有“跳过”或者”立即进入“按钮真的很贴心） 9、违背审美和简约设计原则（让界面保持简约、注重信息获取效率，更加聚焦内容） 10、违背人性化帮助原则（鼠标划过悬浮文字说明：起解释说明作用，帮助用户更好的理解、常驻提示需要一直固定在某个位置实时帮助用户、最后就是帮助文档了） |
||
四、缺陷类型
功能问题：功能没有实现或部分实现、与需求不一致或者实现了需求未提到的功能、影响了各种系统功能、逻辑的缺陷
性能问题：页面渲染过久或者接口响应时间过久、tps过低等，系统资源占用严重或者存在泄露问题
兼容问题：软件对于不同浏览器、操作系统、不同分辨率，或者软件对数据处理以及历史版本接口、数据库语法等不兼容产生的缺陷
安全问题：软件存在安全漏洞或者容易被攻击的端口以及用户敏感信息泄露等缺陷，以及数据越权问题
易用性问题：产品在设计上针对状态可见、简单易学容易理解，相同功能的一致性，能防止用户出错、符合客观世界、用户能够自由控制等方面存在问题的缺陷
界面问题：包括设计视觉还原类问题、界面布局不合理显示错乱、结果输出大小、数据格式展示、文字超出边界、图文混排风格不一致或图文缺失等方面的缺陷
接口问题：接口返回状态以及字段错误、或者处理逻辑与预期不符
需求缺陷：产品需求设计存在不合理难以实现，需求不清晰或变更产生的缺陷
数据问题：由于采集数据处理、大数据清洗、业务数据处理等数据处理产生的缺陷
算法问题：算法问题产生的缺陷
交互问题：涉及软件功能交互的缺陷
P0自测未通过：开发自测未通过在测试阶段发现的P0用例缺陷
测试遗漏：由于测试遗漏导致产生的缺陷
其他：以上类型以外的缺陷
五、缺陷状态以及流程
新缺陷：对应缺陷还未确认以及开始处理
待验证：当前缺陷已经修复并自测通过
已拒绝：当前缺陷提交错误，被开发人员驳回
重新打开：测试验证未通过，被测试人员打回对应的开发
挂起： 当前缺陷暂时或者当前版本无法解决以及延期解决的缺陷，对于延期解决的需要开发说明具体原因
流程图：
六、缺陷原因分析
编码错误
采集问题
大数据处理问题
业务数据处理问题
算法问题导致
三方平台异常
运维以及环境问题
P0自测遗漏
需求设计缺陷
需求变更
错误提单
其他
注：P0自测遗漏需要填写具体原因，其他原因需填写具体原因分析
七、缺陷提单以及处理规范
提单人：
1、 测试环境地址备注清晰
2、 需要清楚填写测试步骤以及实际预期结果
3、 问题描述文字清新，或者必要时加以截图视频
4、 缺陷标题简单扼要，清晰描述问题
5、 缺陷归属版本、模块、在关闭缺陷之前对应的开发处理人和开发人一致归属，填写实际处理人
6、 缺陷类型归属符合规范类型定义
开发：
1、缺陷转待验证前需要填写缺陷原因分析
2、针对P0自测未通过以及其他原因的需要清晰说明未通过原因以及具体措施
八、缺陷的处理：
1、提交缺陷时以单一场景、单一问题为原则提交，避免多个场景、问题合并在一个缺䧟单中
原则上按缺陷优先级顺序处理
2、紧急、高级的缺陷未处理完，禁止发布上线
3、紧急的缺陷需在24小时内处理完成，若处理不完，需提前上报直属领导并在项目组内通报
4、P0未自测做为重点监控缺䧟类型，并将纳入绩效考核
