阿亮学测试 · 第3章第4节 每天10分钟，零基础入门软件测试
【故事引入】那个让整个团队失眠的深夜
凌晨2点，某互联网公司的测试工程师小美被电话叫醒。
"小美，线上出大事了！用户登录功能完全崩溃，几万用户无法登录！"
小美立刻打开电脑排查。问题是这样的：开发刚上线了一个"优化登录逻辑"的功能，结果这个功能把整个登录模块搞挂了。
小美立即在禅道上提交了Bug，然后做了三件事：
严重程度（Severity）：设置为Critical（致命）
优先级（Priority）：设置为P0（紧急）
关联影响：标注影响用户数、订单金额
第二天早上8点紧急会议，产品经理问："这个Bug今天能修好吗？"
【原理讲解】Severity vs Priority
一、两个核心概念
严重程度（Severity）—— Bug本身的破坏力有多大？
这是Bug本身的客观属性
由测试工程师根据问题表现来判断
通常分为：Critical/High/Medium/Low
优先级（Priority）—— 这个Bug应该什么时候修？
这是业务决策的结果
由产品/项目经理根据业务需求决定
通常分为：P0/P1/P2/P3
二、严重程度分级
🔴 Critical（致命）
系统崩溃或数据丢失
核心功能完全不可用
影响所有用户
🟠 High（严重）
主要功能无法正常工作
严重的数据计算错误
🟡 Medium（中等）
功能部分受影响，但有替代方案
界面显示异常但功能可用
🔵 Low（轻微）
轻微的界面问题
拼写错误、格式问题
三、优先级分级
🔴 P0（紧急） — 必须立即修复
停止当前开发工作
24小时内必须修复并上线
🟠 P1（高） — 本次版本必须修复
优先安排开发修复
本周内完成
🟡 P2（中） — 建议修复
放入下一版本计划
不阻塞版本发布
🔵 P3（低） — 可以放到未来版本
记录在Backlog中
可能是技术债务
【实战演示】Bug定级案例
案例1：购物车结算按钮不显示
问题：用户进入购物车后，结算按钮消失
判断：影响所有用户 + 无法下单 = 直接损失
结论：Severity=High, Priority=P1
案例2：用户头像显示模糊
问题：上传高清头像后显示模糊
判断：不影响核心功能，仅美观问题
结论：Severity=Medium, Priority=P2
案例3：后台日志有ERROR信息
问题：系统日志中发现ERROR级别日志
判断：用户无感知，但可能隐藏风险
结论：Severity=High, Priority=P2
【日常应用】Bug状态流转
New → Open → Assigned → Fixed → Retesting → Closed
↓
Deferred → Won't Fix → Closed
【💬 互动时间】
思考题：
如果一个Bug严重程度很低，但产品经理要求P0优先修复，你觉得合理吗？
开发说"这个不是Bug，是需求变更"，你作为测试应该怎么处理？
线上发现一个P0 Bug，但开发资源不足，产品经理让你"先观察"，你怎么办？
📚 本节小结
要点 内容 Severity定义 Bug本身的客观破坏程度 Priority定义 Bug应该什么时候修复的业务决策 Critical级别 系统崩溃、数据丢失、核心功能全挂 P0优先级 必须立即修复，24小时内解决 沟通协作 严重程度由测试判断，优先级由产品决策
🎯 下节预告
第3.5节：缺陷管理工具——禅道/JIRA使用指南
⚠️ 免责声明：本文仅供软件测试学习研究使用，不构成任何商业建议。
作者：阿亮 | 每天10分钟，零基础入门软件测试 | 关注专栏，系统学习
