每次新一轮版本提测，测试群里必然会出现类似的争论：有人说这个按钮错位是“严重缺陷”，开发觉得“这也能叫严重”；有人说支付金额计算错误明明很严重，可产品因为不是主流程就把优先级压得很低。吵到最后，不少团队干脆用“一句话拍板”的方式定级——今天测试说了算，明天开发说了算，后天产品急了又推翻重来。这种混乱我经历太多次了。
Bug的分类和定级，从来不是流程部门发明出来给团队添堵的，它是整个缺陷治理体系里最底层、最关键的一环。分类不统一，数据统计就是垃圾；定级不科学，研发资源就会用错地方。这篇文章我想把自己这些年在一线产品、测试、研发团队里沉淀下来的Bug分类定级经验整理出来，不讲虚的，直接给框架、给字段、给流程、给避坑方法，适合测试工程师、研发负责人和刚搭建缺陷管理体系的团队参考。
1. 为什么要给Bug分类和定级：先想清楚这层逻辑
1.1 分类定级不是流程负担，而是风险管理的入口
很多团队把Bug分类定级当成“提缺陷单时顺手填几个下拉框”的事情，填完了就再也不看。这是本末倒置。
我习惯把Bug分类定级理解成一个风险过滤器。产品发出去以后，用户可能遇到一百种问题，但研发产能是有限的，不可能同一时间修完这一百个问题。分类定级就是在回答两个问题：第一，这个问题属于哪一类风险，影响面大还是小；第二，这个问题现在爆发的概率和破坏力有多大，值不值得马上投入人力。
想清楚这层，你再看那些被诟病的“流程负担”，本质上是定级标准缺失、分类维度混乱造成的。不是流程本身没用，是你没把它建对。
1.2 一套通用的分类维度总览
具体设计分类体系之前，建议先建立一个基本认知：分类不是单一维度，而是多个维度叠加。我在团队里最常用的是下面这套总览：
| 分类维度 | 解决什么问题 | 典型枚举 |
|---|---|---|
| 缺陷性质 | 问题到底属于哪一类，影响范围多大 | 功能、UI、性能、安全、兼容性、数据、接口等 |
| 可复现性 | 问题能不能稳定复现，修复难度如何评估 | 必现、高频、偶发、单次 |
| 发现阶段 | 问题是哪个环节漏进去的 | 需求评审、开发自测、测试、回归、预发、线上 |
| 涉及模块 | 问题出在哪个系统层面 | 前端、后端、数据库、移动端、第三方对接 |
| 业务影响 | 对用户和业务指标的影响程度 | 核心流程、一般流程、边缘功能、优化建议 |
这套维度看着简单，但真正落地以后能解决不少“扯皮”问题。比如有一个缺陷，性质是“接口兼容性”，可复现性是“偶发”，涉及模块是“后端服务”，业务影响是“核心流程”。有了这些标签组合，你不需要看完整Bug描述，就能大概预判优先级。
1.3 高频分类误区：只看严重程度不看频次
我见过最多的分类定级误区，就是团队只用一个字段——“严重程度（Severity）”，而且判断标准极其主观。开发觉得代码能跑就不严重，测试觉得不符合需求就严重，产品觉得没有用户反馈就不严重。三个角色各说各话，最终只能靠吵。
更严重的问题是忽略“复现频次”这个维度。一个支付按钮点击后偶发报错，虽然单次影响严重，但如果一万次里才出现一次，优先级可能就没有“登录后首屏必现白屏”那么高。反过来，一个“文案错别字”看起来不严重，但如果它是App启动首屏的必现问题，用户天天看得见，那它其实已经影响品牌形象了，优先级不该排到最后。
分类定级体系的第一课，就是学会用多个维度去评估风险，而不是只盯着其中一个维度下结论。
2. Bug分类框架：一张能落地的分类清单
2.1 按缺陷性质分类：功能、UI、性能、安全、数据、兼容性等
缺陷性质是最直观、也最容易被团队拿来第一个做的分类。但这个分类想做好，不能只分“功能Bug”和“样式Bug”两类，要结合产品形态细化。
我常用的分类枚举和对应典型场景如下：
- 功能缺陷：按按钮没反应、提交表单后数据丢失、状态流转错误等。这类占日常Bug的40%以上。
- UI展示问题：错位、遮挡、切图不准确、字体大小不一致、深色模式适配异常。很多团队把这类Bug一律定为“低优先级”，这是不对的，影响首屏或者引导页的UI问题应该单独标记。
- 交互逻辑问题：点击区域过小、手势冲突、流程中断后没有引导出口、可访问性缺失。
- 性能缺陷：接口响应超时、列表滚动卡顿、内存泄漏导致OOM、启动时间过长。性能问题通常不是“一次复现”，需要附上耗时数据或压测报告。
- 安全漏洞：越权访问、SQL注入、敏感数据明文传输、XSS、CSRF、权限校验缺失。安全类的Bug不能按常规功能缺陷处理，发现后应第一时间同步安全负责人。
- 兼容性问题：不同浏览器、不同Android/iOS版本、不同分辨率下的表现差异。
- 数据问题：数据计算错误、数据不一致、脏数据、历史数据迁移异常、统计口径不一致。
- 接口/集成问题：后端接口字段错误、联调环境不通、第三方SDK回调失败、状态码处理不对。
- 环境/配置问题：由于配置错误导致的异常、环境变量缺失、证书过期等在测试环境和生产环境表现不一致的问题。
- 文档/可维护性问题：注释错误、接口文档与实现不一致、设计文档缺失。这类一般不走紧急修复流程。
2.2 按可复现性与发现阶段分类
可复现性直接决定了你该怎么处理这个Bug。我处理过不少“开发说复现不了，测试说必现”的情况，最后发现其实是测试环境和开发环境的数据不同。因此，可复现性分类要给开发者判断问题的思路：
- 必现：输入相同操作，每次都能出问题，这是最好查的一类。
- 高频复现：100次操作中能稳定出现几十次，通常能通过日志和断点追踪到。
- 偶发复现：出现频率低，常见于并发、网络抖动、时序竞态等问题，修复成本高。
- 单次出现：只出现过一次，无法复现。这类往往跟外部环境或者脏数据有关，建议保留现场信息但不立即指派开发。
发现阶段这个维度经常被忽略，但它是后续做质量复盘的关键数据源。阶段划分建议为：需求评审阶段、开发自测阶段、冒烟测试阶段、功能测试阶段、回归测试阶段、预发验收阶段、线上运行阶段。每个阶段漏出去一个Bug，背后都可能对应一个流程漏洞。比如线上漏了核心流程Bug，说明功能测试没有充分覆盖主链路；预发才测出来的数据问题，说明测试环境的数据构造和真实环境差异太大。
2.3 实际项目里的分类枚举和字段设计
分类字段不能只在口头说，必须落到缺陷管理工具里。以我常用的Jira和禅道为例，Bug单至少要包含以下结构化字段：
bug_title: [一句话说清楚问题，不要写成结论] bug_type: [功能 | UI | 交互 | 性能 | 安全 | 兼容性 | 数据 | 接口 | 环境配置 | 文档] module: [涉及的一级模块或二级模块] severity: [S1致命 | S2严重 | S3一般 | S4轻微] priority: [P0紧急 | P1高 | P2中 | P3低] frequency: [必现 | 高频 | 偶发 | 单次] found_stage: [需求 | 开发自测 | 冒烟 | 功能测试 | 回归 | 预发 | 线上] environment: [测试环境 | 预发环境 | 生产环境，附版本号和平台信息] reproduce_steps: [具体步骤，尽量带上输入数据] expected_result: [期望表现] actual_result: [实际表现] attachment: [截图 | 录屏 | 日志 | 接口返回报文]很多团队不喜欢让研发填太多字段，觉得影响效率。我的经验是，字段数量控制在10个以内，并且设置默认值，就不会有太大阻力。比如frequency默认是“必现”，测试如果没改，说明默认就是“必现”，减少漏填概率。分类枚举和定级规则要写进团队的Wiki或者新人指南里，而不是让每个人自己理解。
3. Bug定级体系：从三个维度确定级别
3.1 严重程度：这个Bug影响有多大
严重程度衡量的是“问题一旦发生，对系统、用户和业务造成的破坏程度”，它和修复时间无关。即使暂时没人手修，也不影响它的严重级别。
我习惯用四级划分：
| 级别 | 定义 | 典型例子 |
|---|---|---|
| S1致命 | 系统不可用、数据丢失、资金损失、严重安全隐患或核心功能完全不可用 | 支付回调导致订单金额翻倍、登录接口崩溃、核心库被拖库 |
| S2严重 | 主要功能不可用或受影响严重，但有临时绕过方案 | 订单列表打不开但可通过搜索入口查看、导出Excel报错 |
| S3一般 | 次要功能异常，或主要功能的非核心场景受影响 | 消息通知偶发不推送、筛选条件少了一个选项 |
| S4轻微 | 不影响功能使用，只影响体验或美观 | 按钮颜色不对、某处文案有错别字 |
严重程度强调客观破坏力。我见过测试人员为了证明自己“发现了很牛的Bug”，把一个S4的问题写成S2，这个习惯非常不好。定级一旦脱离实际破坏力，评审会上就会失去公信力。
3.2 优先级：这个Bug什么时候必须修
优先级衡量的是“修复这个Bug在时间轴上的紧迫程度”，本质上是一个资源调度判断。它要考虑严重程度，但要还要考虑用户影响面、业务目标、有没有临时规避方案。
我常用四级优先级：
| 级别 | 含义 | 适用场景 |
|---|---|---|
| P0紧急 | 当前迭代内必须立即停下手头工作去处理 | 线上核心功能不可用、涉及资金/账户/法律风险、核心链路阻断提测 |
| P1高 | 本版本必须修复 | 主流程功能异常、大量用户会遇到、虽非致命但影响核心体验 |
| P2中 | 本迭代排期修复，可以延后到下一版本 | 次要功能问题、影响面较小的界面缺陷 |
| P3低 | 有空再修，无明确排期 | 优化建议、低概率偶发且影响轻微的问题 |
这里要重点提醒：严重程度和优先级经常不一致，这是正常的。比如“首页偶发闪退”可能是S1，但如果复现率极低且能自动恢复，那么优先级可能只到P1或P2；反过来，“用户头像加载不出来”是S3，但如果是社区产品的首屏体验，那么它可能是P1。
3.3 频次与覆盖范围：怎么把“偶发Bug”说得清楚
复现频次是定级中最容易被拍脑袋的环节。测试说“偶发”，开发说“我复现不了”，最后优先级被降。要解决这个问题，不能靠感觉，要给频次建立量化标准。
我在项目中建议用如下口径：
- 必现：同一操作步骤，复现概率100%。
- 高频：在测试环境或线上连续操作中，复现概率大于30%，或10次操作中能出现3次以上。
- 偶发：复现概率在1%到30%之间，需要一定前置条件触发。
- 单次：只出现过一次，没有连续两次复现出来。
对于线上问题，还可以结合业务日志统计影响用户数。比如一个接口报错在大盘日志里影响了5%的请求，这就是实打实的“影响范围”；如果只是某个测试账号出现了，那就要谨慎判断。定级评审时，合格的测试人员应该能说出“我在什么环境、用什么数据、连续操作了几次、复现了几次”这样的话，而不是一句“反正我这边出现了几次”。
3.4 定级矩阵与计算公式
单靠人拍板，定级依然会漂。我习惯在团队里先定义一个由“严重程度 + 复现频次 + 发现阶段”构成的定级矩阵，让大部分Bug能机械地得出初始优先级。
| 严重程度 \ 频次 | 必现 | 高频 | 偶发 | 单次 |
|---|---|---|---|---|
| S1 | P0 | P0 | P1 | P2 |
| S2 | P1 | P1 | P2 | P2 |
| S3 | P2 | P2 | P3 | P3 |
| S4 | P3 | P3 | P3 | 挂起/关闭 |
发现阶段单独作为加减项：线上发现的Bug，在矩阵基础上提升一个优先级档位；预发发现的Bug维持原优先级；测试早期发现的Bug可以降一个档位。这样设计背后的逻辑是，越晚发现的问题，修复的成本和影响都更大，优先级需要上调。
这个矩阵不需要做到100%精确，它的价值在于让多数Bug不用开会就能定级。对于矩阵判不出、有争议的场景，再走人工评审，效率会高很多。
4. 实操流程：从报Bug到定级闭环
4.1 高质量Bug单长什么样
Bug描述质量直接决定定级和排查效率。一个低质量Bug单写“首页打不开”，开发不知道是Android还是iOS、是全部用户还是部分用户、是网络问题还是页面崩溃，然后就要花半天来回沟通。
我要求团队里的Bug单至少包含四块：前置条件、复现步骤、期望结果、实际结果。再配合结构化字段，基本能避免大部分无效沟通。给你一个我常用的示例格式：
【前置条件】 - 账号：测试账号A，已开通付费会员 - 环境：生产环境，iOS 17.2，App版本4.8.0 - 数据：账号内有3张优惠券，其中1张已过期 【复现步骤】 1. 进入首页，点击“我的钱包” 2. 点击“优惠券”Tab 3. 点击一张“已过期”的优惠券详情 4. 返回列表，点击“可用”Tab 【期望结果】 可用优惠券列表正常展示，已过期券不会被带入“可用”分区 【实际结果】 “可用”Tab下出现了一张已过期的优惠券，点击进入详情后再返回，列表出现重复数据 【附加信息】 - 截图/录屏：见附件 - 接口返回：/coupon/list 返回数据中 status=EXPIRED - 发生频率：连续操作5次，5次均出现有了这样的Bug单，开发基本能直接定位到优惠券列表的过滤条件忘了过滤过期状态。省下来的沟通时间是非常可观的。
4.2 首次定级、评审修正、跟踪复核
我推行的流程是“三定”：提交时初定、评审时校准、关闭时复核。
- 首次定级由提交人完成。测试在提交Bug时，依据分类字典和定级矩阵给出初始严重程度和优先级。
- 评审校准一般在每周的缺陷评审会或者每天站会后进行。测试、开发负责人、产品负责人一起把P0和P1的Bug过一遍，确认是否有误判。争议大的场景，直接按矩阵和实际业务评估调整。
- 关闭时复核由测试负责人执行。开发修复完，测试在验证通过并关闭Bug时，需要顺手确认之前的定级是否合理。如果发现分类乱填了，要当场指出来，时间长了大家自然就学会认真对待了。
这套流程的核心原则是：定级不是测试一方的事，也不是开发一方的事，而是多方协作后形成的固化规则。规则越僵化，吵得越少。
4.3 测试、开发、产品在定级中的责任划分
最常见的内耗来源是边界不清晰。我建议按如下方式切分：
- 测试负责提供事实：严重程度判断、复现步骤、影响范围、频次数据。测试要中立，不能为了让Bug被重视就拔高严重等级。
- 开发负责提供成本视角：修复方案的技术难度、改动范围、对现有逻辑的影响、预计修复时长。开发不能因为“改起来麻烦”就故意把优先级往下压。
- 产品负责提供业务视角：用户价值、业务流程优先级、替代方案是否存在、是否影响拉新或付费等核心指标。产品也不能只关注自己功能线的KPI。
最终定级建议由测试负责人或QA负责人拍板。如果开发实在不认可，可以提交到项目周会上升决策，而不是让测试和开发在线下互相对峙。建立“拍板人”机制，是解决定级争议最快的办法。
5. 常见问题与避坑经验
5.1 最常吵起来的几个经典场景
场景一：开发说“这不是Bug，是需求理解不一致”。遇到这种情况，第一时间拉产品确认预期行为，不要把结论停留在“是不是Bug”上。即便最终判定“不改代码只改文档”，也要走一次变更记录。
场景二：非主干功能的S2 Bug，开发坚持P2，产品觉得不影响KPI。我一般会问三个问题：用户能不能绕过这个功能达到目标？绕过成本有多高？这个功能是否在本次版本的核心承诺里？如果用户无法绕过，哪怕是非主干功能，也应该按P1处理。
场景三：偶发性性能问题，无法稳定复现。处理方式是先补充监控埋点，采集下一次发生时的现场数据，同时保留日志至少30天。定级可以先标记为P2，等数据采集完整后再升P1。但要注意，如果是影响线上资金安全或用户隐私的性能问题，可以先停掉相关活动开关，直接按P0处理。
场景四：同类Bug大量出现，但每个单独立了级，最后没人统一看全貌。比如某个接口超时，可能有前端、后端、第三方超时配置等多个缺陷。我建议在分类里增加“根因关联”字段，或者用标签把同一根因的Bug打在一起，避免大家一起修，又修出重复问题。
5.2 线上Bug的紧急处理与事后复盘
线上Bug和测试环境Bug要区别对待。线上问题一旦涉及S1，走“立即止血”流程，先降级、回滚、下架功能或者切开关，保证用户可用性优先。止损动作做完以后再去讨论根因和修复方案。
线上定级给P0的Bug，建议都要触发一次复盘，重点不是追责，而是回答以下问题：
- 为什么这个Bug没有被测试阶段拦截？
- 测试数据和线上数据有什么差异？
- 用例设计缺了哪条链路？
- 监控和告警为什么没有覆盖到？
- 分类和定级规则是否要调整？
复盘结论要落到文档和用例库更新上，否则同样的Bug换个姿势还会再出现。
5.3 如何用数据持续修正分类定级规则
很多团队建完分类体系就不管了，这是不对的。我建议每个月花半天时间做一次缺陷数据复盘，重点看几个指标：
- 分类分布：功能类Bug占比是不是过高？占比高说明需求评审和研发自测的覆盖不足。
- 各阶段发现Bug占比：线上Bug占比超过20%，就要回头补测试覆盖和监控告警。
- 定级准确性：以评审后的最终定级为准，看测试初次定级有没有明显偏差。偏差率高，说明字典或者矩阵没落地。
- 误报率：开发确认为“无效Bug”的数量占总量的比例，超过10%就需要关注测试对业务或者配置的理解是不是有问题。
另外，我强烈建议每季度更新一次分类字典。新业务、新架构、新终端形态出现后，原有的分类枚举可能不够用。比如上一代的分类里没有“AI生成内容合规性”这类，现在很多业务已经需要了。分类字典不是一成不变的SOP文档，它应该跟随产品演进。
5.4 我的几点实操建议
写到最后，结合这些年踩过的坑，给你几个直接能用的建议：
第一，分类枚举宁少勿多。一开始字段太多会让团队抗拒，先把最核心的10个枚举定义清楚，跑两个迭代再逐步增加。
第二，定级矩阵必须贴在缺陷管理工具的首页或者侧边栏。不要放在一个没人看的Wiki页面里，否则用着用着就变回“凭感觉定级”。
第三，P0Bug必须设置独立通知流。不管是钉钉、飞书还是邮件，P0出现的时候要让测试负责人、研发负责人、产品负责人第一时间收到，而不是等人事后去看Bug列表。
第四，遇到“偶发”Bug，先不急着定级，先把现场信息抓全。这一步做得好，能把后面返工成本降低一半以上。复现不了的问题往往不是不存在，而是现场信息太少，复现条件被掩盖了。
第五，把分类定级的质量纳入团队建设的一部分。我见过一个测试新人因为连续两周分类准确率100%，在周会上被公开表扬，之后整个团队的Bug单质量都上来了。正向激励比扣分管用得多。
6. 结尾：一些个人体会
我记得刚带项目的头两年，为了Bug定级的事没少得罪人。后来想明白了，大家吵的本质是怕自己的需求被忽略，而不是真在乎那个“级别”的标签。所以我现在更愿意把功夫下在建立清晰规则上，让定级结果“对事不对人”。
如果你现在所在的团队还在用“每天为Bug吵半小时”的方式管理缺陷，我的建议是别急着上复杂平台，先把分类维度、定级矩阵、Bug单模板这三件事做扎实。这套基础打好了，再上什么Jira、禅道、TAPD都能发挥价值。
最后分享一个小技巧：每次新版本上线前，花10分钟把P0和P1的Bug清单拉出来过一遍，问自己一句“这些不修就上线的后果，我们真的能承担吗？”这个习惯帮我避免了至少三次上线事故。希望这些经验对你有用。
