回归测试用例选择记录表要回答两个问题：这条用例为什么被纳入或排除，以及谁基于什么结论批准了这次选择。字段设计可以沿“用例—变更—选择依据—评审结论”四段信息展开，前两段定位对象和触发原因，后两段承载判断与留痕。下面给出一份可直接复制的空白表，并逐字段说明填写口径、必填划分和完整示例。
要点总览（TL;DR）
- 记录表沿“用例—变更—选择依据—评审结论”四段信息设计字段，每行记录一条用例的一次选择判断，同一用例在不同批次重复选择时另起一行。
- 必填字段保证单条记录可独立追溯：回归批次、用例标识、所属模块、变更来源、变更编号、影响范围、选择依据、选择结果、评审结论、评审人、评审日期；用例名称、风险等级、评审意见、备注可按团队情况选填。
- 追溯选择依据的关键是“变更单/需求/缺陷编号”与“选择依据”配合：编号指向变更事实，选择依据说明该事实如何影响这条用例。
- 评审结论与选择结果分列，区分测试负责人建议与评审人最终决定；结论为“调整后同意”时需复查是否已按意见补充用例或调整选择。
- 模板维护需记录字段增删的触发条件、版本变更与归档复查节奏，字段改名时保留旧名对照，历史记录不批量改写。
可复制空白记录表模板
将下表复制到电子表格或在线表格工具中即可使用。表头字段与后文说明、示例保持同一命名。建议一行记录对应一条用例的一次选择判断，同一用例在不同回归批次被重复选择时另起一行，用“回归批次”区分。
| 回归批次 | 用例标识 | 用例名称 | 所属模块 | 变更来源 | 变更单/需求/缺陷编号 | 影响范围 | 选择依据 | 风险等级 | 选择结果 | 评审结论 | 评审意见 | 评审人 | 评审日期 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
如果团队习惯按批次集中评审，也可以把“评审结论、评审意见、评审人、评审日期”四列拆到独立的评审记录表中，用“回归批次+用例标识”作为关联键。两种组织方式的选择依据相同，区别只在评审信息是逐行记录还是按批次汇总。
字段说明：每个字段记录什么、怎么填
字段说明的目的是让不同填写人对同一列给出一致口径。下表按四段信息分组，列出含义、填写口径与示例值。
| 字段名 | 所属信息段 | 含义 | 填写口径 | 示例值 |
|---|---|---|---|---|
| 回归批次 | 用例 | 本次回归所属的版本或迭代批次 | 写版本号或迭代名称，同一批次内保持一致 | V3.2.0 回归 |
| 用例标识 | 用例 | 用例库中的唯一编号 | 直接引用用例库编号，不另起别名 | TC-LOGIN-0142 |
| 用例名称 | 用例 | 用例的简短标题 | 与用例库标题一致，便于评审人快速识别 | 手机号验证码登录成功 |
| 所属模块 | 用例 | 用例归属的功能模块 | 使用团队模块树的层级名称 | 账号中心/登录 |
| 变更来源 | 变更 | 触发本次回归的变更类型 | 从需求变更、缺陷修复、配置调整、依赖升级等类型中选择 | 缺陷修复 |
| 变更单/需求/缺陷编号 | 变更 | 追溯关联字段，指向具体变更对象 | 填写系统中真实存在的编号，多个编号用分号分隔 | BUG-2087；REQ-331 |
| 影响范围 | 变更 | 变更波及的功能、接口或数据 | 写具体对象，避免只写“相关功能” | 登录接口、验证码校验逻辑 |
| 选择依据 | 选择依据 | 纳入或排除的判断理由 | 写可核对的理由，指向影响范围或历史缺陷 | 变更修改验证码校验，直接影响本用例主流程 |
| 风险等级 | 选择依据 | 该用例覆盖场景的风险高低 | 按团队定义的高/中/低填写，与选择结果分开 | 高 |
| 选择结果 | 选择依据 | 本次是否纳入回归 | 填“纳入”或“排除”，不写模糊表述 | 纳入 |
| 评审结论 | 评审结论 | 评审人对该条选择的最终意见 | 填“同意”“调整后同意”或“不同意”，与选择结果对应 | 同意 |
| 评审意见 | 评审结论 | 结论的理由或补充要求 | 结论为“同意”时可简述确认点；有调整要求时写清动作 | 确认覆盖验证码失效场景，补充一条异常用例 |
| 评审人 | 评审结论 | 对结论负责的人 | 填姓名或系统账号，不用岗位代称 | 张明 |
| 评审日期 | 评审结论 | 结论形成的时间 | 统一格式，如 YYYY-MM-DD | 2025-03-14 |
| 备注 | 补充 | 其他需要说明的信息 | 记录例外情况、待确认事项 | 依赖第三方短信服务，需联调环境 |
追溯选择依据的关键在“变更单/需求/缺陷编号”与“选择依据”两列的配合：编号指向变更事实，选择依据说明该事实如何影响这条用例。评审人查看记录时，能沿编号回到原始变更，再对照影响范围判断理由是否成立。评审结论与选择结果分列，是为了区分“测试负责人建议纳入”和“评审人批准纳入”两个动作，避免把建议当成最终决定。
当记录表需要承载用例库、变更单与评审状态的联动时，可以把记录表作为工作项管理：ONES 测试管理支持将用例导入用例库并以结构化方式组织，同时提供自定义属性满足不同场景的字段扩展需求，用例选择记录中的批次、风险等级、选择结果等字段可以按团队口径配置。评审结论与意见可随工作项状态流转留痕，缺陷也可关联至迭代追踪。这样记录表与用例、缺陷数据在同一处维护，减少表格与系统两头核对。
必填与选填的划分
必填字段的作用是保证任何一条记录都能被独立追溯：只看这一行，就能找到用例、找到触发变更、看懂判断理由、知道谁批准。缺少其中任一环节，追溯链就会断开。选填字段用于补充上下文，缺失不影响追溯成立。
| 字段名 | 建议属性 | 理由或适用场景 |
|---|---|---|
| 回归批次 | 必填 | 缺少批次无法定位记录属于哪次回归 |
| 用例标识 | 必填 | 追溯的起点，缺失则记录无法对应用例 |
| 所属模块 | 必填 | 支撑按模块汇总影响面，评审时用于判断覆盖是否均衡 |
| 变更来源 | 必填 | 说明为什么此时做回归 |
| 变更单/需求/缺陷编号 | 必填 | 回到原始变更的唯一入口，缺失则选择依据无法核实 |
| 影响范围 | 必填 | 连接变更与用例的中间事实 |
| 选择依据 | 必填 | 记录判断本身，缺失则只剩结论没有理由 |
| 选择结果 | 必填 | 纳入或排除的明确表态 |
| 评审结论 | 必填 | 评审留痕的核心，缺失则无法证明选择经过确认 |
| 评审人 | 必填 | 结论的责任人 |
| 评审日期 | 必填 | 证明评审发生在回归执行之前 |
| 用例名称 | 选填 | 便于阅读，可由用例标识关联取得 |
| 风险等级 | 选填 | 流程成熟、需要按风险排序执行时填写 |
| 评审意见 | 选填 | 结论为“同意”且无补充要求时可留空；有调整要求时必填 |
| 备注 | 选填 | 记录例外与待确认事项 |
必填项可以按团队情况调整。刚建立记录习惯的小团队，可先保证用例标识、变更编号、选择依据、选择结果、评审人五项齐全，其余字段随流程稳定再收紧；流程成熟、需要对外交付审计材料的团队，可把风险等级和评审意见也纳入必填。调整原则是：凡是被下游用来做判断或复盘的字段，就应设为必填；只用于阅读便利的字段保持选填。每次调整必填范围都应记录在模板版本说明中，避免新旧记录口径混用。
填写示例：一条完整记录
下面两条示例使用同一批次，分别演示纳入与排除两种判断，重点看选择依据如何支撑选择结果，以及评审结论如何回应选择依据。
| 字段名 | 示例一（纳入） | 示例二（排除） |
|---|---|---|
| 回归批次 | V3.2.0 回归 | V3.2.0 回归 |
| 用例标识 | TC-LOGIN-0142 | TC-ORDER-0308 |
| 用例名称 | 手机号验证码登录成功 | 订单列表按金额排序 |
| 所属模块 | 账号中心/登录 | 交易/订单列表 |
| 变更来源 | 缺陷修复 | 缺陷修复 |
| 变更单/需求/缺陷编号 | BUG-2087 | BUG-2101 |
| 影响范围 | 登录接口、验证码校验逻辑 | 订单列表分页参数 |
| 选择依据 | 缺陷修改验证码校验分支，本用例覆盖该分支主流程，且登录为高频入口 | 缺陷仅调整分页每页条数默认值，排序逻辑未改动，本用例断言不涉及分页参数 |
| 风险等级 | 高 | 低 |
| 选择结果 | 纳入 | 排除 |
| 评审结论 | 同意 | 同意 |
| 评审意见 | 确认覆盖验证码失效场景，补充一条异常用例 | 下批次分页改版时重新评估 |
| 评审人 | 张明 | 张明 |
| 评审日期 | 2025-03-14 | 2025-03-14 |
| 备注 | 依赖第三方短信服务，需联调环境 |
示例一的选择依据写明了“改了什么、用例覆盖什么、为什么重要”三层信息，评审意见在此基础上追加了补充要求，结论与意见形成闭环。示例二的排除同样需要依据：说明变更未触及用例断言点，并给出后续复查时机，避免排除记录变成无理由的省略。两条记录都保留了变更编号，事后任何人想复核，都能从编号回到原始缺陷单核对影响范围描述是否准确。
模板的调整与维护方法
记录表随流程变化需要调整，维护的重点是让字段变更可追溯，避免旧记录因字段改名或删除而失去解释力。以下规则可作为模板维护的检查清单。
- 字段增删的触发条件：出现新的变更类型（如配置项调整、第三方依赖升级）且现有“变更来源”选项无法覆盖时，扩充选项而非新增列；评审需要按风险排序执行时，把风险等级从选填升为必填；出现跨团队交接、需要额外说明责任边界时，再考虑新增字段。每次只做必要调整，避免字段膨胀导致填写负担上升。
- 模板版本与变更记录：模板文件命名带版本号，如“回归用例选择记录表_v1.2”；在模板末尾或独立说明页维护变更记录，写明版本、日期、调整内容与原因。字段改名时保留旧名对照，历史记录不批量改写，查询时按版本说明映射。
- 评审结论的归档与复查：每个回归批次结束后，将记录表随测试报告一并归档，归档时确认评审人、评审日期无空缺。对结论为“调整后同意”的记录，复查是否已按意见补充用例或调整选择；对排除记录，在下一次相关模块变更时回看，确认排除理由是否仍然成立。
- 定期校准填写口径：每个季度或每个大版本结束后，抽取若干条记录核对选择依据与变更编号是否对应，发现“依据写得太笼统”“编号填错”等高频问题，更新字段说明中的示例，而不是反复口头提醒。
维护动作本身也应留下记录：谁在什么时间调整了哪个字段、影响哪些批次，写进变更记录即可。这样模板迭代不会打断历史记录的追溯，新批次也能按最新口径填写。
常见问题
回归测试用例选择记录表与测试用例库是什么关系？记录表需要重复存用例步骤吗？
记录表不重复存用例步骤，只存用例标识和选择判断。用例标识直接引用用例库编号，评审人需要看步骤时沿编号回到用例库查看。这样记录表保持轻量，用例内容更新时记录表无需同步修改。如果团队使用 ONES 测试管理，用例可导入用例库并以结构化方式组织，记录表中的用例标识可直接对应库中编号。
变更单编号在记录表中填多个时，选择依据怎么写才能对应上？
多个编号用分号分隔后，选择依据中应分别说明每个编号对应的判断。例如“BUG-2087 修改验证码校验分支，本用例覆盖该分支主流程；REQ-331 调整登录页文案，不影响本用例断言”。如果多个编号指向同一影响范围，可合并说明并列出全部编号。关键是评审人沿任一编号回到原始变更时，都能在影响范围和选择依据中找到对应描述。
评审结论为“调整后同意”时，记录表还需要补哪些字段？
“调整后同意”表示评审人同意选择方向但要求补充或修改。此时评审意见应写清具体动作，例如“补充一条验证码失效异常用例”或“将风险等级从低调整为高”。调整完成后，可在备注中记录调整结果和完成日期，或另起一行记录调整后的用例选择。复查时重点核对评审意见中的动作是否已落实，避免结论停留在“调整后同意”而实际未调整。
小团队刚开始用记录表，必填字段可以再减少吗？
可以。刚建立记录习惯时，可先保证用例标识、变更编号、选择依据、选择结果、评审人五项齐全，这五项构成最小追溯链：找到用例、找到触发变更、看懂理由、知道是否纳入、知道谁确认。回归批次和所属模块可随批次管理习惯逐步纳入必填。调整必填范围时，在模板版本说明中记录调整日期和原因，避免新旧记录口径混用。
记录表按批次集中评审时，评审字段拆到独立表后如何关联？
用“回归批次+用例标识”作为关联键。主表保留用例、变更、选择依据和选择结果，评审表按批次记录评审结论、评审意见、评审人和评审日期，两表通过批次和用例标识对应。拆分后需保证同一批次内用例标识不重复，否则关联会错位。如果团队使用 ONES 测试管理，评审结论与意见可随工作项状态流转留痕，减少两表手工核对的成本。
