4. 缺陷字段与屏幕方案
缺陷跟踪系统能否产生可信的质量数据，很大程度上取决于缺陷单在创建那一刻收集到了什么信息。字段设计得太少，缺陷描述含糊、无法定位、无法统计；字段设计得太多，创建人面对几十个输入框，要么随意填写，要么干脆绕过流程。本节要解决的核心问题是：如何用一套“字段 + 屏幕方案”的组合，让缺陷信息既完整、又结构化、还可度量。
一、先分清三类字段的职责
在 Jira 中，缺陷单上的字段可以按来源和职责分成三类，理解它们的边界是设计的前提。
- 系统字段：Jira 自带、不可删除，如摘要（Summary）、描述（Description）、报告人（Reporter）、经办人（Assignee）、优先级（Priority）、状态（Status）、解决结果（Resolution）、创建时间、更新时间、附件、评论。这些字段是流程运转的基础，其中状态和解决结果直接驱动工作流，不能随意改动语义。
- 自定义字段：为质量度量和管理需要而新增的字段，例如缺陷类型、发现阶段、严重程度、缺陷来源、复现概率、关联需求、修复版本、根因分类、是否逃逸。它们是“可度量”的关键，因为只有结构化字段才能被 JQL 检索、被报表聚合。
- 级联字段：一种特殊的自定义字段，值之间存在父子层级，例如“模块 → 子模块”“产品线 → 组件”“环境类型 → 具体环境”。级联字段解决的是“同一维度下取值太多、平铺会失控”的问题。
一个常见的误区是把所有信息都塞进“描述”里。描述适合放自由文本的复现步骤和期望结果，但“发现阶段=系统测试”“严重程度=高”这类信息如果只写在描述里，就无法被统计。判断标准很简单：凡是将来要用来筛选、分组、画图、算指标的，都必须是独立的结构化字段。
二、必填字段：少而准，卡在正确的时机
必填字段不是越多越好。必填过多会显著增加创建成本，导致“随便填一个值”的敷衍行为，反而污染数据。合理的做法是按“没有它就无法处理或无法度量”来筛选。
建议在缺陷创建屏幕上设置以下必填项：摘要、描述、缺陷类型、严重程度、发现阶段、所属模块（级联）、报告人、经办人（或默认经办队列）。其中摘要要求一句话说清“在什么条件下、什么对象、出现什么异常”；描述建议用固定结构引导填写，例如：
【前置条件】使用测试账号 A 登录，购物车中已有 2 件商品
【操作步骤】1. 进入结算页 2. 选择优惠券 C 3. 点击提交订单
【期望结果】订单金额按优惠后价格计算并成功创建订单
【实际结果】提示“优惠券不可用”，订单未创建
【复现概率】3/3
【环境】测试环境 / Chrome 120 / 版本 2.4.0-rc3注意“复现概率”和“环境”这类信息，如果团队需要按环境统计缺陷分布，就应当从描述中抽出来做成独立字段，而不是留在自由文本里。
三、自定义字段：为度量而设计
自定义字段的设计要回答一个问题：这个字段将来会出现在哪张报表里？如果答不上来，就先不要加。以下是一组经过裁剪、面向质量度量的字段示例（参数为示例值，可按团队实际调整）。
| 字段名 | 类型 | 取值示例 | 度量用途 |
|---|---|---|---|
| 缺陷类型 | 单选 | 功能、性能、界面、兼容性、数据、安全 | 缺陷构成分析 |
| 严重程度 | 单选 | 致命、严重、一般、轻微 | 质量风险排序 |
| 优先级 | 单选 | P0、P1、P2、P3 | 排期与响应时效 |
| 发现阶段 | 单选 | 需求评审、单元测试、集成测试、系统测试、验收测试、生产 | 缺陷逃逸率、阶段分布 |
| 缺陷来源 | 单选 | 内部测试、客户反馈、线上监控、回归发现 | 内外部缺陷占比 |
| 根因分类 | 单选 | 需求遗漏、设计缺陷、编码错误、配置错误、环境问题 | 根因帕累托 |
| 修复版本 | 版本选择 | 2.4.0、2.4.1 | 版本质量对比 |
| 是否逃逸 | 复选框 | 是 / 否 | 逃逸缺陷统计 |
其中“是否逃逸”可以由“发现阶段”自动推导，但保留为独立字段便于人工复核。严重程度与优先级必须分开：严重程度描述缺陷本身对系统的影响，优先级描述业务上多快需要修，二者不一定一致——一个界面错别字严重程度轻微，但出现在首页 Banner 上优先级可能很高。
四、级联字段：把“模块”变成可聚合的层级
当产品有多个模块、每个模块下又有子模块时，用单选字段平铺会迅速膨胀到几十个选项，且无法按父级汇总。级联字段用“父值 → 子值”的结构解决这个问题。例如：
模块（父） 子模块（子）
订单 下单、支付、取消、退款
商品 详情、搜索、库存、评价
用户 注册、登录、资料、权限
营销 优惠券、活动、积分这样在 JQL 中既可以用 模块 = 订单 统计整个订单域，也可以用 模块 = 订单 AND 子模块 = 支付 精确定位。级联字段的层级不宜超过两层，三层以上在 Jira 中维护成本高、选择体验差，通常用“组件（Component）”或标签替代更合适。
五、屏幕方案：让不同角色看到不同字段
字段定义好了，还要决定“谁在什么操作下看到哪些字段”。这就是屏幕方案（Screen Scheme）的作用。Jira 中屏幕分为创建、编辑、查看三类，通过屏幕方案绑定到问题类型和项目。
推荐的做法是按操作区分屏幕：
- 创建屏幕：只放必填字段和少量关键字段，降低创建门槛。例如摘要、描述、缺陷类型、严重程度、发现阶段、模块（级联）、经办人。
- 编辑屏幕：包含全部可维护字段，供开发、测试在流转过程中补充根因分类、修复版本、是否逃逸等。
- 查看屏幕：只读展示，字段顺序按“先看结论、再看细节”排列，把严重程度、优先级、状态、经办人放在最上方。
如果团队同时有“功能缺陷”和“性能缺陷”两类问题类型，可以给它们绑定不同的屏幕方案：性能缺陷额外要求填写“并发量”“响应时间阈值”“压测工具”等字段，而功能缺陷不需要。这样既保证信息完整，又避免无关字段干扰填写。
六、字段与屏幕方案的配置关系
下面这张图展示了从“字段定义”到“屏幕方案”再到“项目/问题类型”的绑定关系，以及最终在缺陷单上呈现的效果。理解这条链路，才能在字段不生效或屏幕不匹配时快速定位问题。
这张图的关键在于：字段本身只是“原料”，屏幕决定“哪些字段在哪个操作中出现”，屏幕方案决定“哪类问题类型用哪套屏幕”，最后通过项目绑定生效。当出现“字段明明建了却看不到”时，排查顺序应当是：字段是否已加入对应屏幕 → 屏幕是否已加入屏幕方案 → 屏幕方案是否已绑定到该项目和问题类型。
七、可度量的判断标准
设计完成后，用三个问题自检：第一，能否用一条 JQL 查出“系统测试阶段发现的、严重程度为严重的、订单模块的缺陷”？第二，能否按发现阶段和根因分类画出帕累托图？第三，新人在创建缺陷时，是否知道每个必填字段该填什么？如果三个问题都能明确回答，说明字段与屏幕方案已经支撑起质量闭环的数据基础。反之，如果某个指标需要人工翻描述才能统计，就说明还缺一个结构化字段。