缺陷分类表把缺陷的类型、严重程度、优先级、所属模块、发现阶段、复现概率和处理状态放在同一组字段里，让提交、分派和统计使用同一套口径。本文提供一份可直接复制到电子表格或缺陷管理工具的空白表，并说明各字段取值、必填与选填的划分、一条完整填写示例以及后续调整维护方法，适合正在建立或整理缺陷记录规范的研发团队参考。
要点总览（TL;DR）
- 缺陷分类表通常围绕缺陷类型、严重程度、优先级、所属模块、发现阶段、复现概率、处理状态七个维度组织字段，其中类型、严重程度、模块、复现步骤建议设为必填。
- 严重程度描述缺陷造成的影响，优先级描述处理次序，两者分开设置，才能兼顾影响判断与排期安排。
- 模板可先复制到电子表格使用，再迁移为缺陷管理工具的工作项属性；字段数量随团队规模与缺陷量逐步增加。
- 取值选项需要版本管理，调整时保留旧值映射，并每个迭代或每季度回顾一次填写完整率与选项使用情况。
- 落地到缺陷管理工作项时，可把类型、严重程度、模块配置为工作项属性，把处理状态对应到流转状态，保持表格与工具口径一致。
可直接复制的缺陷分类空白表
下表为主表模板，表头固定，空白行用于填写。复制到电子表格时，将每一列对应为一个字段；复制到缺陷管理工具时，将每一列配置为一个工作项属性，并按后文的取值选项表设置下拉选项。
| 缺陷编号 | 缺陷标题 | 缺陷类型 | 严重程度 | 优先级 | 所属模块 | 发现阶段 | 复现概率 | 复现步骤 | 环境信息 | 处理状态 | 提交人 | 处理人 | 提交日期 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
配套的取值选项表如下。团队可以直接沿用，也可以在此基础上增删选项，增删后同步更新字段说明，避免同一取值在不同记录中含义不一致。
| 字段 | 可选值 |
|---|---|
| 缺陷类型 | 功能错误、界面显示、性能问题、兼容性、数据问题、接口异常、安全漏洞、文档错误、其他 |
| 严重程度 | 致命、严重、一般、轻微 |
| 优先级 | P0 立即处理、P1 本迭代处理、P2 排期处理、P3 暂缓 |
| 发现阶段 | 需求评审、开发自测、提测、系统测试、回归测试、验收、上线后 |
| 复现概率 | 必现、高频、偶现、无法复现 |
| 处理状态 | 新建、已确认、处理中、待验证、已关闭、已拒绝、挂起 |
模板落地时，编号可由工具自动生成，标题写成“模块＋现象”的短句，复现步骤按“前置条件—操作步骤—实际结果—期望结果”的顺序填写。这样同一张表既能用于人工登记，也能直接迁移为缺陷工作项的字段结构。
缺陷分类常用维度与字段说明
七个核心维度各自回答一个具体问题：缺陷类型回答“问题属于哪一类”，严重程度回答“影响有多大”，优先级回答“先处理哪一个”，所属模块回答“问题出在哪里”，发现阶段回答“在哪个环节被发现”，复现概率回答“能否稳定重现”，处理状态回答“当前推进到哪一步”。字段含义清楚，后续的筛选、统计和复盘才有共同语言。
缺陷类型
按问题的表现形态归类，用于统计各类问题的占比和集中区域。判断口径以主要症状为准：页面元素错位、文案截断归入界面显示；响应时间超出约定指标归入性能问题；特定浏览器或设备上才出现的问题归入兼容性。一条缺陷只选一个主类型，次要类型写在描述里，避免统计时重复计数。
严重程度
描述缺陷对用户和业务造成的影响，与处理时间无关。致命指核心流程中断、数据丢失或存在安全风险；严重指主要功能不可用但存在绕行方式；一般指功能可用但结果不符合预期；轻微指体验、文案或样式层面的问题。判断时以影响范围和后果为依据，不参考修复难度。
优先级
描述处理次序，由严重程度、业务节点和修复成本共同决定。P0 表示需要立即投入处理，P1 安排在本迭代内解决，P2 进入排期队列，P3 暂缓或视情况关闭。严重程度与优先级分开设置，是因为一个轻微缺陷如果出现在即将发布的对外演示页面上，也可能需要优先处理；反之，一个严重但只影响内部测试环境的问题，可以按计划排期。
所属模块
指向缺陷所在的功能区域或系统组件，取值应与产品模块划分保持一致。模块划分过粗会导致定位困难，过细会增加填写负担，通常以一级功能模块为主，必要时增加二级模块字段。
发现阶段
记录缺陷被发现的环节，用于评估各阶段的质量控制效果。取值按团队实际流程设置，常见顺序为开发自测、提测、系统测试、回归测试、验收、上线后。上线后发现的缺陷通常需要单独统计，作为质量回顾的重点。
复现概率
描述缺陷重现的稳定程度。必现指按步骤操作每次都能出现；高频指多数情况下出现；偶现指间歇性出现；无法复现指提交时未能再次重现。偶现和无法复现的缺陷应补充日志、截图或录屏，便于后续定位。
处理状态
反映缺陷从提交到关闭的流转位置。新建表示刚提交待确认，已确认表示问题成立，处理中表示已分派并在修复，待验证表示修复完成等待测试确认，已关闭表示验证通过，已拒绝表示判定为非缺陷或重复提交，挂起表示暂时不处理。状态取值应与团队实际流转规则一致，避免出现无人推进的中间状态。
必填与选填字段的划分
必填字段的作用是保证每条缺陷都能被定位、判断和复现。缺陷类型、严重程度、所属模块、复现步骤四项建议设为必填：类型和模块决定问题归属与统计口径，严重程度决定影响判断，复现步骤决定他人能否独立验证。缺少其中任何一项，缺陷记录都难以进入正常的处理流程。
选填字段用于补充上下文，按团队情况取舍。优先级在缺陷量较少、由一人统一分派时可以后置填写；发现阶段在流程尚未稳定时可以先不强制；复现概率对偶现问题价值较高，对必现问题可以省略；环境信息在单一部署环境下可以简化。处理状态、提交人、处理人、提交日期通常由工具自动记录，不需要人工填写。
| 字段 | 建议 | 理由与适用条件 |
|---|---|---|
| 缺陷类型 | 必填 | 支撑分类统计与问题集中度分析 |
| 严重程度 | 必填 | 影响判断与发布决策的基础依据 |
| 所属模块 | 必填 | 用于定位责任范围与模块质量统计 |
| 复现步骤 | 必填 | 保证他人可独立验证问题 |
| 优先级 | 选填 | 缺陷量较大、需要统一排期时建议设为必填 |
| 发现阶段 | 选填 | 流程稳定、需要评估各阶段质量时建议设为必填 |
| 复现概率 | 选填 | 偶现问题较多的产品建议设为必填 |
| 环境信息 | 选填 | 多环境并行部署时建议设为必填 |
| 处理状态、提交人、处理人、提交日期 | 系统记录 | 由工具自动生成，无需人工填写 |
字段数量与团队规模、缺陷量相关。小团队缺陷量少，四到六个字段即可支撑日常处理，字段过多会增加填写成本，反而导致记录敷衍；缺陷量增大、多人协作或需要按模块和阶段出质量报告时，再逐步把优先级、发现阶段、复现概率转为必填。调整时一次只增加一个字段，观察一到两个迭代的填写质量再决定是否保留。
一条缺陷记录的完整填写示例
以下为一条已填写的记录，字段与第一节模板、第二节说明保持一致。示例为演示情景，用于说明各字段如何配合，不代表真实项目数据。
| 字段 | 填写内容 |
|---|---|
| 缺陷编号 | BUG-1024 |
| 缺陷标题 | 订单列表页翻页后筛选条件被清空 |
| 缺陷类型 | 功能错误 |
| 严重程度 | 严重 |
| 优先级 | P1 本迭代处理 |
| 所属模块 | 订单管理 |
| 发现阶段 | 系统测试 |
| 复现概率 | 必现 |
| 复现步骤 | 前置条件：账号下存在超过两页的订单数据。步骤：进入订单列表页，选择“待发货”筛选条件，点击第二页。实际结果：列表回到全部订单，筛选条件被清空。期望结果：翻页后保留“待发货”筛选条件。 |
| 环境信息 | 测试环境，Chrome 浏览器最新版本 |
| 处理状态 | 已确认 |
| 提交人 | 测试人员 |
| 处理人 | 订单模块开发人员 |
| 提交日期 | 按实际提交日期填写 |
逐项说明填写依据：标题采用“模块＋现象”的写法，读者不看描述也能判断问题；类型选功能错误，因为筛选逻辑失效属于功能不符合预期，界面本身显示正常；严重程度定为严重，因为筛选条件丢失会影响用户查找订单，但列表仍可浏览，存在绕行方式；优先级定为 P1，因为该问题出现在订单主流程，安排在本迭代修复；所属模块选订单管理，与产品模块划分一致；发现阶段为系统测试，说明问题在提测后被发现；复现概率为必现，步骤可稳定重现，因此环境信息只记录浏览器与测试环境即可；处理状态为已确认，表示问题已核实成立，等待开发人员开始修复。
模板的调整与维护方法
模板投入使用后需要按项目和团队变化持续调整，否则字段会逐渐与实际流程脱节。调整从裁剪字段开始：新项目启动阶段缺陷量少，可先保留必填四项加处理状态，减少填写负担；进入系统测试和回归阶段后，再启用发现阶段和复现概率；面向多端发布的产品，把环境信息设为必填。按产品线维护时，可以为不同产品线保留同一套核心字段，只在模块取值和发现阶段选项上做区分，保证跨产品线的统计口径一致。
取值选项的增删需要版本管理。每次调整记录调整日期、调整内容和原因，例如新增“接口异常”类型、合并两个含义重叠的模块、把“P3 暂缓”改为“P3 待评估”。调整前先统计旧取值下的历史数据，调整后保留旧值映射关系，避免历史报表出现断层。选项名称保持稳定，含义变化时新增选项而不是直接改写旧选项。
定期回顾建议每个迭代或每个季度做一次，检查以下几点：
- 必填字段的填写完整率是否达到预期，缺失集中在哪些字段；
- 是否存在长期空置的取值选项，或大量记录集中在“其他”类型；
- 严重程度与优先级的判断是否出现明显分歧，需要补充判断口径；
- 发现阶段的分布是否与团队实际流程一致，是否存在流程外发现的缺陷；
- 模块划分是否随产品迭代更新，新增功能是否已纳入模块取值。
当缺陷记录进入缺陷管理工作项后，字段配置和状态流转需要在工具中同步落地。ONES Project 适配缺陷管理等研发场景，支持一键提交 Bug 至对应项目或迭代，记录和跟踪缺陷修复情况，并可统计缺陷状态分布；其与 TestCase 数据互通，便于从测试用例直接提交缺陷。团队可以把本文模板中的类型、严重程度、模块等字段配置为工作项属性，把处理状态对应到流转状态，使表格口径与工具中的记录保持一致。具体字段配置入口以实际产品界面为准。
常见问题
缺陷分类表里严重程度和优先级可以合并成一个字段吗？
不建议合并。严重程度回答的是缺陷造成多大影响，判断依据是影响范围和后果；优先级回答的是先处理哪一个，需要结合业务节点、发布计划和修复成本。两者合并后，一个轻微但影响对外演示的缺陷和一个严重但只影响内部测试环境的缺陷会得到相同排序，排期时容易失真。如果团队缺陷量很少、由一人统一分派，可以暂时只填严重程度，等缺陷量增加后再补优先级字段。
小团队字段填不全，模板应该保留几项？
可以先保留缺陷类型、严重程度、所属模块、复现步骤四项必填，加上由工具自动记录的处理状态、提交人和提交日期。发现阶段、复现概率、环境信息在流程稳定或多环境部署时再转为必填。字段一次只增加一个，观察一到两个迭代的填写质量，如果新增字段长期空置或填写敷衍，就退回选填，避免模板过重导致记录质量下降。
模板复制到缺陷管理工具后，取值选项怎么和表格保持一致？
把表格中的每一列对应为工作项的一个属性，取值选项表对应为下拉选项，字段名称和选项名称保持与表格一致。处理状态需要映射到工具中的流转状态，例如“新建”对应提交后的初始状态，“待验证”对应修复完成后的状态。调整选项时同步更新表格和工具两处，并记录调整日期与原因，避免同一取值在表格和工具中含义不同。
偶现缺陷无法稳定复现，复现概率和处理状态该怎么填？
复现概率填“偶现”或“无法复现”，并在描述中补充日志、截图或录屏，说明出现时的操作路径和环境。处理状态建议先填“已确认”或“挂起”，由团队判断是否继续投入排查。偶现缺陷较多的产品，可以把复现概率设为必填，促使提交人补充足够的定位信息，减少来回沟通。
模板用了一段时间后，怎么判断字段设置是否仍然有效？
每个迭代或每季度检查几项指标：必填字段的填写完整率、是否存在长期空置的取值选项、是否有大量记录集中在“其他”类型、严重程度与优先级的判断是否出现明显分歧、模块取值是否随产品迭代更新。发现某字段长期无人使用或填写质量差，就调整为选填或删除；发现某类问题频繁出现却没有对应选项，就新增取值并记录调整原因。
