缺陷必填项设置的目标，是让处理人拿到记录就能复现、能分派、能验证关闭，同时不让提交人把时间耗在填表上。本文给出一套可执行的判定标准、字段分档清单、配置步骤与完成检查清单，适用于正在整理缺陷模板或准备调整现有必填规则的团队。
要点总览（TL;DR）
- 必填项的判定标准是“缺了它能否复现、能否分派、能否验证关闭”，三个环节都不受影响的字段改为选填或后补。
- 字段分三档：标题、复现步骤、实际结果、预期结果、环境、严重程度、发现版本为核心必填；复现概率、附件、关联用例、日志按缺陷来源或类型设为条件必填；修复版本、根因分类、备注为选填。
- 配置按梳理字段、分档、设置必填与默认值、配置动态显示规则、试运行定稿五步推进，每步都有对应输出物。
- 控制负担优先用默认值、自动带出和模板预填减少手工输入，核心必填控制在七到十个左右，并按缺陷类型动态显示字段。
- 上线前逐项核对：每个必填字段能说清缺失后果、提交耗时合理、开发凭记录即可复现分派、条件规则确实触发、有字段回看机制。
必填项该按什么标准划分
判断一个字段是否必填，用同一个问题追问：缺了它，处理人还能不能复现问题、把缺陷分派给正确的负责人、在修复后确认关闭？三个环节中任一环节会因缺字段而卡住，这个字段就具备必填资格；三个环节都不受影响，它更适合选填或后补。这条标准的好处是直接对应缺陷流转的实际动作，避免按“信息越全越好”的思路把所有字段都设为必填。
按这条标准，字段可以分成三档。核心必填是所有缺陷都必须填写的字段，缺了它缺陷无法进入正常处理；条件必填是在特定缺陷类型、来源或模块下才要求填写的字段，例如线上反馈的缺陷需要日志，测试发现的缺陷需要关联用例；选填是填写有助于分析、但不影响当前流转的字段，可以在处理过程中补充。三档并存，比“全必填”或“全选填”更贴近真实提交场景。
必填项与缺陷记录质量的关系是间接的：必填只保证字段不为空，不保证内容有效。一条复现步骤写着“按上次那样操作”的记录，字段填满了仍然无法复现。因此必填项设置要配合填写要求和模板骨架，例如复现步骤给出“前置条件—操作步骤—出现频率”的结构，让提交人知道填什么算填好。返工成本主要来自两处：信息不足导致开发反复询问，以及字段过多导致提交人草率填写或绕过流程。必填项设置同时影响这两处，需要在完整与轻量之间取平衡。
哪些字段必须填、哪些适合选填
下表给出一份可直接采用的字段分档清单。档位依据仍是“能否复现、能否分派、能否验证关闭”，理由列说明每个字段为什么放在这一档。团队可以在此基础上增删，但建议先保留核心必填的最小集合，再按自身缺陷来源补充条件必填。
| 字段 | 档位 | 理由 | 填写要求 |
|---|---|---|---|
| 标题 | 核心必填 | 用于识别和检索缺陷，分派时首先看标题 | 一句话描述现象与位置，避免“有问题”“报错”这类无法区分的写法 |
| 复现步骤 | 核心必填 | 决定处理人能否重现问题，是复现的核心依据 | 按操作顺序编号，写清前置条件和数据 |
| 实际结果 | 核心必填 | 说明当前发生了什么，与预期对比才能判断是否为缺陷 | 描述观察到的现象，附关键提示信息 |
| 预期结果 | 核心必填 | 给出正确行为的参照，缺少时处理人无法确认修复目标 | 写清依据来源，如需求文档、设计稿或行业惯例 |
| 环境 | 核心必填 | 不同环境的行为差异常见，缺环境信息会导致无法复现 | 至少包含设备或浏览器、系统版本、测试环境标识 |
| 严重程度 | 核心必填 | 影响分派优先级和处理顺序 | 按团队既定分级选择，取值标准另行定义 |
| 发现版本 | 核心必填 | 定位问题引入的版本范围，影响修复与回归安排 | 填写发现缺陷时的构建或发布版本 |
| 复现概率 | 条件必填 | 偶现问题需要说明概率才能安排排查投入；稳定复现时价值有限 | 在问题非稳定复现时要求填写，如“必现”“约三成” |
| 附件或截图 | 条件必填 | 界面类、报错类缺陷需要视觉证据；纯逻辑或数据问题可由文字说明 | 按缺陷类型触发，要求至少一张截图或一段日志 |
| 关联需求或用例 | 条件必填 | 测试发现的缺陷关联用例便于回归；线上反馈往往没有对应用例 | 测试来源缺陷要求关联，其他来源可后补 |
| 日志 | 条件必填 | 线上缺陷缺少日志时排查成本高；测试环境通常可直接复现 | 线上来源缺陷要求附日志片段或链接 |
| 修复版本 | 选填 | 由处理人在修复阶段填写，提交时通常未知 | 修复完成时补充 |
| 根因分类 | 选填 | 用于后续质量分析，提交阶段无法判断 | 关闭缺陷时由处理人补充 |
| 备注 | 选填 | 承载补充信息，不影响流转 | 有需要时填写 |
这张表的关键取舍在于把“提交时知道的信息”和“处理过程中才知道的信息”分开。修复版本、根因分类这类字段，提交人本来就不掌握，设为必填只会迫使填写占位内容，反而降低数据可信度。把它们放到处理阶段补充，既保证记录完整，也不增加提交负担。
设置必填项的操作步骤
把上面的清单落到工具配置，需要经过梳理、分档、配置、动态规则和试运行五步。每一步都有明确输入和输出，完成标志是输出物经过确认，可以进入下一步。
第一步：梳理现有字段与使用情况
输入是当前缺陷模板或工作项类型的全部字段，以及近一段时间的缺陷记录。动作是统计每个字段的填写率、被引用情况和处理人追问频率，找出长期空置的字段和经常被追问缺失的字段。输出是一份字段现状清单，标注“高频使用”“偶尔使用”“基本空置”三类。完成标志是清单覆盖全部现有字段，并有数据支撑分类。
第二步：按判定标准给字段分档
输入是第一步的现状清单和“能否复现、能否分派、能否验证关闭”的判定标准。动作是逐字段追问缺失后果，把字段归入核心必填、条件必填、选填三档，并为条件必填写明触发场景。输出是字段分档表，格式可参照上一节。完成标志是每个核心必填字段都能说清缺失后果，每个条件必填字段都有明确的触发条件。
第三步：在缺陷模板或工作项类型中配置必填与默认值
输入是分档表。动作是在缺陷模板或工作项类型中把核心必填字段设为必填，为环境、发现版本、提交人、所属模块等字段配置默认值或自动带出，用模板预填复现步骤的骨架结构。输出是配置完成的缺陷模板和一份配置说明，记录每个字段的档位与默认值来源。完成标志是新建一条测试缺陷时，默认值正确带出，核心必填字段为空时无法提交。
在 ONES 中，缺陷可以作为工作项在项目或迭代中提交和跟踪，ONES Project 支持一键提交 Bug 至对应项目或迭代，并记录修复情况；ONES TestCase 支持未通过的用例快速创建缺陷任务，使缺陷在测试与研发之间流转。字段的必填与默认值配置入口和可配置范围，以团队所用版本的官方说明为准，配置前建议先在测试项目验证一遍。
第四步：按缺陷类型或模块设置动态显示规则
输入是条件必填字段的触发场景。动作是把触发条件转成规则，例如缺陷来源为线上反馈时显示并要求日志字段，来源为测试时显示并要求关联用例字段；某些模块的缺陷额外要求填写设备信息。输出是动态规则清单，逐条写明触发条件、显示字段和是否必填。完成标志是在对应场景下新建缺陷，规则确实触发，非对应场景下字段不出现或不拦截提交。
第五步：试运行并收集反馈后定稿
输入是配置完成的模板和动态规则。动作是选择一个或两个团队试运行两到四周，记录每次提交的耗时、被退回补充的次数，以及处理人仍然追问的信息。输出是试运行反馈记录和修订后的字段分档表。完成标志是提交耗时和退回次数趋于稳定，处理人不再频繁追问同一类信息，规则经缺陷管理负责人确认后定稿并记录版本。
角色分工与各环节交付物
必填项规则涉及制定、配置、使用和反馈四类角色，明确分工可以避免规则上线后无人维护。下表给出角色、职责与交付物的对应关系，团队规模较小时可由一人兼任多个角色，但职责仍需分开记录。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 缺陷管理负责人或测试负责人 | 制定字段分档标准与缺陷模板，确认条件必填的触发场景，定稿规则 | 字段分档表、缺陷模板、规则版本记录 |
| 项目或团队管理员 | 在工具中配置必填规则、默认值与动态显示规则，维护配置与文档一致 | 配置说明、动态规则清单 |
| 提交人（测试、客服、用户支持） | 按模板提交缺陷，反馈填写负担和不清楚的字段 | 试运行期间的提交耗时与反馈记录 |
| 开发与缺陷处理人 | 反馈字段是否足够复现和分派，指出仍需追问的信息 | 追问信息清单、字段补充建议 |
分工之外还需要一条维护机制：规则变更由缺陷管理负责人确认，管理员执行配置，变更记录保留版本号。缺少这条机制时，字段往往在多次临时调整后变得臃肿，最初的分档标准也就失效了。
示例：一个中等规模团队的必填项方案
以下为演示情景，用于说明分档与配置的落地方式，不代表特定团队的真实数据。某团队约五十人，包含测试、开发和产品角色，缺陷来源以测试提交为主，另有少量来自客服转交的线上反馈。团队此前的缺陷模板有二十余个字段，其中大部分为必填，提交人常以“无”“暂无”填充，开发仍频繁追问环境和复现步骤。
调整后，核心必填保留标题、复现步骤、实际结果、预期结果、环境、严重程度、发现版本七项。环境字段默认带出提交人当前使用的测试环境和浏览器信息，发现版本默认取当前迭代的构建号，提交人只需核对。复现步骤使用模板预填“前置条件、操作步骤、出现频率”三段结构，提交人按段填写。
条件必填按来源设置动态规则：来源为线上反馈时，要求填写日志和影响范围，复现概率改为必填；来源为测试时，要求关联用例，附件在界面类和报错类缺陷中必填。修复版本、根因分类改为选填，由处理人在修复和关闭阶段补充。备注保持选填。
效果评估从两个方向看：提交侧记录单条缺陷的平均填写耗时和被退回补充的次数，处理侧记录开发在缺陷下追问信息的条数。调整后的目标是填写耗时下降、退回次数减少，同时开发追问环境与复现步骤的情况明显减少。评估周期建议覆盖两到三个迭代，避免单周波动影响判断。若某条件必填字段在试运行中触发后经常被填“无”，说明触发条件过宽，应缩小到真正需要的缺陷类型。
如何避免必填项过多造成提交负担
控制负担的第一条原则是给必填项数量设上限：以能复现和分派的最小集合为准，超出部分改为选填或后补。核心必填字段控制在七到十个左右，通常足以支撑复现和分派；继续增加字段时，先问它是否会在提交阶段被真实使用。
减少手工输入比减少必要信息更有效。环境、发现版本、提交人、所属模块这类字段可以通过默认值和自动带出完成，提交人只需核对；复现步骤、实际结果可以用模板预填结构，把“写什么”变成“填空”。这样既保留信息，又缩短填写时间。
按缺陷类型动态显示是控制负担的关键手段。所有字段对所有人必填，会让测试提交线上问题时面对一堆无关字段，也会让客服提交反馈时被要求填写用例编号。把字段与来源、类型、模块绑定，只在相关场景出现，可以显著降低单次提交的字段数量。
对低价值字段采取降档处理：先改为选填，观察一段时间仍无人填写且无人引用，就考虑从模板中移除。定期回看字段使用率是维持规则健康的必要动作，建议每季度或每半年检查一次，重点看三类信号：长期空置的必填字段、经常被填占位内容的字段、处理人反复追问的缺失信息。前两类考虑降档或删除，第三类考虑提升为必填或加入模板骨架。
完成检查：必填项设置是否到位
规则上线前，用下面这份清单逐项核对。每一项都对应一个可观察的结果，核对不通过时回到对应步骤修订，而不是直接上线后再补。
- 每个必填字段都能回答“缺了它会导致什么后果”，回答不了后果的字段已降为选填。
- 提交人能在合理时间内完成一次完整提交，试运行记录中有实际耗时数据支撑。
- 开发仅凭记录即可复现问题并完成分派，不需要在缺陷下追问环境、步骤或预期结果。
- 条件必填规则在对应场景下确实触发，非对应场景下不出现、不拦截提交。
- 默认值和自动带出在新建缺陷时正确生效，提交人只需核对而无需重复录入。
- 存在字段回看与调整机制，明确了回看周期、负责人和调整记录的保存方式。
- 规则变更留有版本记录，提交人能够获知最近一次调整的内容。
这份清单同时可以作为后续复查的基准。团队业务或缺陷来源发生变化时，重新走一遍清单，比凭印象增删字段更能保持规则与实际的匹配。
常见问题
缺陷来源既有测试提交又有线上反馈，必填项要设两套吗？
不必维护两套独立模板，用一套核心必填加条件必填即可。核心必填字段对所有来源一致，保证记录的基本可比性；差异部分通过动态显示规则处理，例如来源为线上反馈时要求填写日志和影响范围，来源为测试时要求关联用例。这样提交人面对的是同一张表单，只是随来源增减少数字段，维护成本也低于两套模板并行。
团队担心必填项减少后缺陷信息不够用，怎么处理？
把“提交时必须知道的信息”和“处理过程中才知道的信息”分开。修复版本、根因分类这类字段提交人本来就不掌握，设为必填只会得到占位内容。可以先降为选填，由处理人在修复和关闭阶段补充，同时观察处理人是否仍频繁追问某类信息：如果追问集中在环境或复现步骤，说明这些字段应保留必填并加强模板骨架；如果追问的是后补字段，说明降档合理。
试运行多久可以定稿，期间看哪些指标？
建议覆盖两到三个迭代，避免单周波动影响判断。提交侧记录单条缺陷的平均填写耗时和被退回补充的次数，处理侧记录开发在缺陷下追问信息的条数。当填写耗时和退回次数趋于稳定、开发不再频繁追问同一类信息时，可以提交缺陷管理负责人确认定稿。若某个条件必填字段触发后经常被填“无”，说明触发条件过宽，应缩小到真正需要的缺陷类型再定稿。
规则上线后由谁负责调整，多久回看一次？
规则变更由缺陷管理负责人确认，项目或团队管理员执行配置，变更记录保留版本号，提交人能够获知最近一次调整内容。回看建议每季度或每半年一次，重点看三类信号：长期空置的必填字段、经常被填占位内容的字段、处理人反复追问的缺失信息。前两类考虑降档或删除，第三类考虑提升为必填或加入模板骨架。团队业务或缺陷来源发生明显变化时，应提前触发一次回看。
用 ONES 承载缺陷提交时，字段配置要注意什么？
ONES Project 支持一键提交 Bug 至对应项目或迭代并记录修复情况，ONES TestCase 支持未通过的用例快速创建缺陷任务，缺陷可以在测试与研发之间流转。字段的必填、默认值与动态显示规则的配置入口和可配置范围，以团队所用版本的官方说明为准，配置前建议先在测试项目验证一遍，确认默认值正确带出、必填字段为空时无法提交，再推广到正式项目。
