90%测试员搞错Bug优先级和严重性，面试直接被刷

软件测试里，优先级和严重性分不清，等于白干三年。

01 一个Bug引发的血案：优先级和严重性到底是什么

先讲一个真实案例。某电商平台上线前，测试人员提交了一个Bug：用户头像上传后显示模糊。测试员A标注：严重性-高，优先级-高。开发看了一眼，丢到下周迭代。结果上线当天，用户投诉炸了——不是头像模糊，而是头像上传后，整个页面白屏。

问题出在哪？测试员A把“模糊”和“白屏”混为一谈。模糊是界面瑕疵，白屏是功能瘫痪。一个Bug的严重性是它造成的破坏程度，优先级是修复它的紧迫程度。两者是不同维度，但90%的测试新手把它们画等号。

严重性看影响，优先级看时机。

严重性（Severity）：Bug对系统功能、数据、安全、用户体验的破坏级别。从S1到S4，S1是系统崩溃、数据丢失；S4是界面错位、文案错误。

优先级（Priority）：Bug需要被修复的先后顺序。从P1到P4，P1是立即修复，阻塞后续工作；P4是有空再修，不影响核心流程。

举个代码例子。假设你测试一个登录功能，发现密码框输入特殊字符导致页面卡死：

# 严重性：S1（系统崩溃）
# 优先级：P1（阻塞用户登录，必须立即修）
def login(username, password):
    if not sanitize_input(password):  # 缺少输入验证
        while True:  # 死循环
            pass
    return authenticate(username, password)

另一个例子：登录按钮颜色偏蓝，不是设计稿的红色：

# 严重性：S4（界面瑕疵，功能正常）
# 优先级：P4（不影响用户使用，可延后）
def render_button():
    button.color = "blue"  # 设计稿要求红色
    return button

看到了吗？同一个功能模块，Bug性质不同，严重性和优先级天差地别。测试员的核心能力，就是快速判断这两个维度，而不是一刀切。

02 四象限法则：一张表搞定Bug分类

别靠感觉分Bug。用四象限法则，把严重性和优先级组合成4种类型，每个类型对应不同的处理策略。

类型1：高严重性 + 高优先级。系统崩溃、数据丢失、安全漏洞。比如支付接口返回错误金额，导致用户多扣款。这种Bug必须当天修复，否则线上事故。

类型2：低严重性 + 高优先级。界面错位、文案错误、按钮失效。比如注册页的“同意协议”复选框默认未勾选，导致用户无法注册。虽然不崩系统，但阻塞核心流程，优先级必须高。

类型3：高严重性 + 低优先级。极端场景下触发的问题。比如用户上传10GB文件导致服务器崩溃，但99%用户不会上传这么大文件。这种Bug要规划修复，但不必立即停线。

类型4：低严重性 + 低优先级。界面小瑕疵、非核心功能异常。比如帮助文档中的错别字，或者某个不常用页面的加载慢1秒。这种Bug可以扔到待办列表，甚至直接关闭。

Bug分类不是贴标签，是决策引擎。

面试官最爱问：“一个Bug严重性高但优先级低，你怎么处理？”答案不是“修或者不修”，而是评估风险：这个Bug触发的概率多大？影响用户数多少？是否有临时规避方案？如果概率低、影响小、有替代方案，那就放到下个迭代。

举个例子。某银行App的转账功能，在跨行转账且金额超过100万且网络延迟超过5秒时，偶尔出现重复扣款。这是S1严重性，但触发条件极其苛刻。测试员建议：增加转账确认弹窗，而不是停线修复。这就是优先级低的处理方式。

03 实战演练：30个Bug案例教你精准分类

理论说再多，不如动手练。下面给出30个真实场景Bug，你试着分类。每个Bug我都给出标准答案和理由。

场景1：用户登录后，余额显示为0，实际有1000元。

• ►严重性：S1（数据错误，用户投诉）
• ►优先级：P1（立即修复，阻塞资金操作）

场景2：用户注册时，密码强度提示条颜色偏淡。

• ►严重性：S4（界面瑕疵，不影响功能）
• ►优先级：P4（有空再修）

场景3：用户在商品详情页滑动时，页面偶尔闪退。

• ►严重性：S2（功能异常，但非核心流程）
• ►优先级：P2（尽快修复，影响用户体验）

场景4：搜索功能输入中文后，搜索结果为空，但数据库有数据。

• ►严重性：S1（核心功能失效）
• ►优先级：P1（阻塞用户搜索）

场景5：App启动页广告加载慢3秒。

• ►严重性：S3（性能问题，但非功能失效）
• ►优先级：P3（优化即可，不阻塞发布）

场景6：用户下单后，订单状态显示“已取消”，但实际已支付。

• ►严重性：S1（数据不一致，用户恐慌）
• ►优先级：P1（立即修复，避免投诉）

场景7：帮助文档中“退货流程”链接跳转到404页面。

• ►严重性：S3（文档问题，不影响核心功能）
• ►优先级：P3（规划修复）

场景8：用户头像上传后，图片被拉伸变形。

• ►严重性：S3（界面异常，但功能正常）
• ►优先级：P3（可延后修复）

场景9：支付页面输入信用卡号时，格式校验不通过，但卡号正确。

• ►严重性：S2（功能异常，阻塞支付）
• ►优先级：P2（尽快修复）

场景10：用户退出登录后，缓存中仍保留用户敏感信息。

• ►严重性：S1（安全漏洞）
• ►优先级：P1（立即修复）

场景11：首页轮播图在iOS 15上点击无反应。

• ►严重性：S2（功能异常，但非核心）
• ►优先级：P2（尽快修复，兼容性问题）

场景12：用户修改密码后，旧密码仍可登录。

• ►严重性：S1（安全漏洞）
• ►优先级：P1（立即修复）

场景13：商品列表页加载时，数据错乱显示为其他类目。

• ►严重性：S1（数据错误）
• ►优先级：P1（立即修复）

场景14：用户评论功能中，输入超长文本导致页面卡顿。

• ►严重性：S3（性能问题）
• ►优先级：P3（优化即可）

场景15：用户分享链接到微信，点击后跳转到空白页。

• ►严重性：S2（功能异常，影响转化）
• ►优先级：P2（尽快修复）

场景16：用户收藏商品后，收藏列表显示为空。

• ►严重性：S2（功能异常）
• ►优先级：P2（尽快修复）

场景17：用户注册时，手机号格式校验过于严格，不允许国际号码。

• ►严重性：S3（功能限制，但非核心）
• ►优先级：P3（规划优化）

场景18：用户取消订单后，退款金额计算错误，多退1分钱。

• ►严重性：S2（数据错误，但金额小）
• ►优先级：P2（尽快修复）

场景19：用户登录页面，验证码图片加载失败。

• ►严重性：S2（阻塞登录）
• ►优先级：P2（尽快修复）

场景20：用户查看历史订单时，页面加载时间超过10秒。

• ►严重性：S3（性能问题）
• ►优先级：P3（优化即可）

场景21：用户修改收货地址后，系统未更新，仍显示旧地址。

• ►严重性：S2（功能异常）
• ►优先级：P2（尽快修复）

场景22：用户使用优惠券时，优惠券列表显示为空，但实际有券。

• ►严重性：S2（功能异常）
• ►优先级：P2（尽快修复）

场景23：用户反馈页面，提交按钮在点击后无响应。

• ►严重性：S3（功能异常，但非核心）
• ►优先级：P3（规划修复）

场景24：用户搜索“手机”，结果返回“电脑”相关商品。

• ►严重性：S1（数据错误）
• ►优先级：P1（立即修复）

场景25：用户登录后，页面顶部导航栏消失。

• ►严重性：S2（界面异常，影响操作）
• ►优先级：P2（尽快修复）

场景26：用户下单时，选择“到店自提”但系统仍要求填写配送地址。

• ►严重性：S2（功能逻辑错误）
• ►优先级：P2（尽快修复）

场景27：用户查看商品详情时，图片放大功能失效。

• ►严重性：S3（功能异常，但非核心）
• ►优先级：P3（规划修复）

场景28：用户退出登录后，再次登录需要重新输入所有信息。

• ►严重性：S3（体验问题）
• ►优先级：P3（优化即可）

场景29：用户使用第三方登录（微信）时，授权后页面空白。

• ►严重性：S1（阻塞登录）
• ►优先级：P1（立即修复）

场景30：用户每天第一次打开App时，加载时间超过5秒。

• ►严重性：S3（性能问题）
• ►优先级：P3（优化即可）

分类不是终点，决策才是。

这30个案例覆盖了80%的Bug场景。你对照着练，一周内就能形成肌肉记忆。

04 面试官的陷阱：如何用优先级和严重性回答Bug管理题

面试官问Bug分类，不是考你背定义。他看的是你的决策逻辑和风险意识。

常见陷阱题1：“一个Bug严重性S1，但优先级P4，你怎么处理？”

标准回答：先评估触发概率。如果触发概率低于1%，且用户可以通过刷新页面临时解决，那就规划到下个迭代修复，同时增加监控告警。如果触发概率高，即使S1也要提优先级。

陷阱题2：“开发说这个Bug是S4，但你觉得是S1，怎么沟通？”

标准回答：用数据说话。拿出用户影响范围、触发条件、业务损失数据。比如“这个Bug导致支付失败，影响10%用户，日损失5万元”。开发只看技术难度，测试看业务风险。

陷阱题3：“一个Bug，测试员标P1，开发标P3，谁说了算？”

标准回答：项目经理或产品经理决策。测试员提供严重性评估，开发提供修复成本，产品经理看业务优先级。三方对齐，避免扯皮。

测试不是找Bug，是管理风险。

面试官还会问：“你怎么定Bug的优先级？”别回答“看严重性”。要回答：看用户影响面、业务损失、修复成本、临时规避方案。这四个维度加权打分，得出优先级。

举个例子。一个Bug导致首页加载慢2秒。用户影响面：100%用户。业务损失：转化率下降5%。修复成本：后端加缓存，2小时。临时规避方案：无。加权后，这个Bug优先级是P2，不是P3。因为影响面大、损失高、修复成本低。

最后，面试官会问：“你提交的Bug，开发不改怎么办？”标准回答：先确认是否误报。如果不是，升级到项目经理，同时提供用户反馈和业务数据。如果开发仍不改，记录在Bug库，标注“已确认，待评估”，并通知相关方。不解决Bug，但要解决风险。

---

Bug分类不是技术活，是决策活。分不清优先级和严重性，你就是在给项目埋雷。