回归用例选择评审表用来记录“为什么选这条用例、由谁评审、结论是什么”，以一条用例一行的表格承载。字段可分为用例标识、选择依据、评审记录、执行跟踪四组；其中用例编号、用例名称、选择理由、评审结论建议设为必填，其余字段按团队实际取舍。下面给出可直接复制的空白表、逐字段填写口径、必填规则、完整示例与维护方法。
要点总览（TL;DR）
- 评审表按一条用例一行组织，字段分为用例标识、选择依据、评审记录、执行跟踪四组，共16个字段。
- 用例编号、用例名称、选择理由、评审结论建议设为必填，其余字段按项目阶段和团队习惯取舍。
- 选择理由要写清变更点与用例覆盖点的对应关系，评审结论统一使用通过、有条件通过、不纳入三档取值。
- 小团队可只保留四项必填加变更点和备注；多模块、多轮回归项目再逐步增加影响范围、风险等级、执行轮次等字段。
- 评审表按回归批次建立版本并冻结归档，用例编号与关联需求/缺陷字段保持指向用例库和单据，形成可追溯链路。
可复制空白模板：回归用例选择评审表
将下表复制到表格工具或文档中即可使用。记录粒度保持一条用例一行：同一用例若因多个变更点被重复选中，可拆成多行分别说明，或在选择依据中并列多个变更点，团队内部统一即可。表头按四组排列，便于评审时按顺序阅读。
| 分组 | 字段 | 填写内容 |
|---|---|---|
| 用例标识 | 用例编号 | |
| 用例标识 | 用例名称 | |
| 用例标识 | 所属模块 | |
| 用例标识 | 关联需求/缺陷 | |
| 选择依据 | 变更点 | |
| 选择依据 | 影响范围 | |
| 选择依据 | 选择理由 | |
| 选择依据 | 风险等级 | |
| 评审记录 | 评审人 | |
| 评审记录 | 评审日期 | |
| 评审记录 | 评审结论 | |
| 评审记录 | 修改意见 | |
| 执行跟踪 | 优先级 | |
| 执行跟踪 | 执行轮次 | |
| 执行跟踪 | 执行结果 | |
| 执行跟踪 | 备注 |
如果团队习惯横向表头，可将上表转置为一行表头、下方留空行填写，字段顺序保持一致即可。空白模板只解决“有哪些字段”，各字段的填写口径见下一节。
字段说明：每个字段记录什么、怎么填
字段说明的目标是让不同评审人填出可比较的内容。用例标识类字段尽量引用用例库中的既有编号与名称，避免评审表与用例库出现两套叫法；选择依据类字段要写到“哪个变更、影响哪里、为什么这条用例能覆盖”，而不是只写“相关”“重要”这类无法核对的词。
| 字段名 | 含义 | 填写口径 | 示例值 |
|---|---|---|---|
| 用例编号 | 用例在用例库中的唯一标识 | 直接引用用例库编号，不另行编号 | TC-LOGIN-012 |
| 用例名称 | 用例的简短标题 | 与用例库标题一致，能独立看懂验证什么 | 账号密码登录成功跳转首页 |
| 所属模块 | 用例归属的功能模块 | 使用团队模块划分的既有名称 | 登录与鉴权 |
| 关联需求/缺陷 | 触发本次回归的需求单或缺陷单 | 填写单号，多个用逗号分隔 | REQ-2087，BUG-3315 |
| 变更点 | 本次改动具体发生在哪里 | 写到接口、页面或逻辑分支级别 | 登录接口增加验证码校验 |
| 影响范围 | 变更可能波及的功能与数据 | 列出直接受影响和间接受影响的对象 | 登录页、密码错误提示、会话创建 |
| 选择理由 | 说明这条用例为何被纳入回归 | 把变更点与用例覆盖点对应起来，一句话说清 | 该用例覆盖登录主流程，验证码变更后主流程需重新确认 |
| 风险等级 | 用例失败对业务的影响程度 | 按团队约定取值，如高/中/低 | 高 |
| 评审人 | 参与本次选择评审的人员 | 填写姓名，多人用逗号分隔 | 张敏，李伟 |
| 评审日期 | 评审完成的日期 | 统一格式，如YYYY-MM-DD | 2025-03-14 |
| 评审结论 | 对该用例是否纳入回归的决定 | 取值限定为通过、有条件通过、不纳入 | 有条件通过 |
| 修改意见 | 结论为有条件通过或不纳入时的说明 | 写清需要补充或调整的具体内容 | 补充验证码超时场景后再纳入 |
| 优先级 | 执行顺序的先后 | 与风险等级区分，按执行排期填写 | P1 |
| 执行轮次 | 该用例计划在第几轮回归中执行 | 填写轮次编号或日期区间 | 第1轮 |
| 执行结果 | 执行后的实际结果 | 评审阶段可留空，执行后回填通过/失败/阻塞 | 通过 |
| 备注 | 其他需要说明的信息 | 填写环境依赖、数据准备等补充说明 | 需预置测试账号 |
评审结论的取值需要提前约定，避免出现“基本通过”“待定”等无法统计的写法。有条件通过表示用例方向认可，但需按修改意见补充内容后再执行；不纳入表示本次回归不选该用例，修改意见中写明原因，便于后续追溯。执行跟踪字段在评审阶段只需填优先级和执行轮次，执行结果与备注在执行后回填，这样评审表同时承担了选择记录和执行记录的衔接作用。
必填与选填：哪些字段不能空
必填字段的作用是保证每一行都能被追溯：知道是哪条用例、为什么选它、评审给了什么结论。用例编号、用例名称、选择理由、评审结论四项缺失时，该行无法支撑后续执行和复盘，应退回补充。其余字段按项目阶段和团队习惯取舍。
| 字段 | 必填/选填 | 说明 |
|---|---|---|
| 用例编号 | 必填 | 唯一标识，缺失则无法与用例库对应 |
| 用例名称 | 必填 | 评审时快速识别用例内容 |
| 选择理由 | 必填 | 评审的核心依据，缺失则评审失去意义 |
| 评审结论 | 必填 | 决定该用例是否进入执行 |
| 所属模块 | 选填 | 用例库已能按模块检索时可省略 |
| 关联需求/缺陷 | 选填 | 变更来源单一且明确时可省略 |
| 变更点 | 选填 | 建议填写；变更点较多时可由选择理由承载 |
| 影响范围 | 选填 | 影响面清晰的小变更可省略 |
| 风险等级 | 选填 | 需要按风险排序执行时填写 |
| 评审人 | 选填 | 小团队口头评审时可省略，正式评审建议填写 |
| 评审日期 | 选填 | 需要按批次归档时填写 |
| 修改意见 | 选填 | 结论为通过时可留空 |
| 优先级 | 选填 | 执行排期需要时填写 |
| 执行轮次 | 选填 | 多轮回归时填写 |
| 执行结果 | 选填 | 执行后回填 |
| 备注 | 选填 | 按需填写 |
缺失处理规则建议写进评审流程：评审前由用例负责人自查必填项，缺项的行不进入评审议程；评审中发现必填项为空，当场退回补充，补充完成后再给出结论；评审结束后由记录人统一检查一遍必填列，确认无空值再归档。选填字段一旦在某个项目中启用，就应在该项目内保持一致，避免同一张表里有的行填、有的行空，影响横向比较。
填写示例：一次登录模块变更的完整评审行
下面以登录模块增加验证码校验为例，演示一条用例从选择到评审的完整填写。示例为演示情景，团队可按自身模块划分和编号规则替换。
| 字段 | 填写内容 |
|---|---|
| 用例编号 | TC-LOGIN-012 |
| 用例名称 | 账号密码登录成功跳转首页 |
| 所属模块 | 登录与鉴权 |
| 关联需求/缺陷 | REQ-2087 |
| 变更点 | 登录接口增加验证码校验，校验失败返回错误码 |
| 影响范围 | 登录页交互、密码错误提示、会话创建、第三方登录入口 |
| 选择理由 | 该用例覆盖登录主流程，验证码校验插入后主流程的请求参数与跳转逻辑均受影响，需重新确认 |
| 风险等级 | 高 |
| 评审人 | 张敏，李伟 |
| 评审日期 | 2025-03-14 |
| 评审结论 | 有条件通过 |
| 修改意见 | 补充验证码超时与刷新场景的断言后再纳入本轮回归 |
| 优先级 | P1 |
| 执行轮次 | 第1轮 |
| 执行结果 | 通过 |
| 备注 | 需预置已注册测试账号 |
这一行中，选择理由与变更点形成对应：变更点在登录接口，选择理由说明该用例覆盖的正是受影响的登录主流程，评审人据此可以判断选择是否合理。评审结论为有条件通过，修改意见写明了需要补充的具体场景，而不是笼统写“再完善”；执行结果在执行后回填，使评审记录与执行记录留在同一行，复盘时能直接看到“为什么选、评审怎么定、执行结果如何”。
调整与维护方法：按团队规模裁剪字段
模板不必一次上齐所有字段。字段增删的判断标准是：该字段是否影响“选择是否合理”和“结论是否可追溯”这两个问题。影响则保留，不影响则合并或删除，避免表格变成填写负担。
- 小团队或单模块项目：保留用例编号、用例名称、选择理由、评审结论四项必填，加变更点和备注即可，评审人可由记录人代填。
- 多模块并行项目：增加所属模块、影响范围、风险等级，便于按模块汇总和按风险排序执行。
- 需要正式评审留痕的项目：补齐评审人、评审日期、修改意见，评审结论严格使用三档取值。
- 多轮回归项目：启用执行轮次、优先级、执行结果，把评审表与执行记录放在同一张表中维护。
- 字段合并建议：变更点与影响范围在变更较小时可合并为一列“变更与影响”；关联需求/缺陷与备注可合并，减少重复填写。
维护方面，评审表按回归批次建立版本，文件名或表头注明批次号与日期，例如“回归选择评审表-2025年3月批次-v2”。每次评审结束后冻结当批版本，后续调整另存新版本，避免历史记录被覆盖。归档时与用例库、缺陷记录保持关联：用例编号指向用例库条目，关联需求/缺陷字段指向对应单据，执行结果回填后与缺陷单状态对照，形成从变更到用例、从评审到执行的完整链路。
当评审表需要在多人之间流转、并与用例和缺陷保持关联时，可以借助ONES的工作项与文档能力承载：用例以工作项形式维护编号与模块，评审表作为文档随批次归档，评审结论和执行结果回填到对应工作项状态，需求与缺陷通过关联关系串联。这样字段口径不变，评审记录与执行记录在同一处可查，减少表格在多个副本之间同步的成本。团队规模较小时，用表格工具维护同一套字段同样可行，关键是必填项和结论取值保持一致。
常见问题
评审表里的“选择理由”和“变更点”有什么区别，能不能只填一个？
变更点描述改动发生在哪里，选择理由说明这条用例为什么能覆盖该改动，两者回答的是不同问题。变更较小时可以只填选择理由，但理由中要包含变更位置和覆盖关系，例如“登录接口增加验证码校验，该用例覆盖登录主流程”。变更点较多或影响面较广时，建议分列填写，便于评审人逐项核对。
评审结论为“有条件通过”的用例，补充完成后还需要重新评审吗？
是否重新评审由团队约定。常见做法是：修改意见中写明的补充内容由用例负责人完成后，由原评审人确认即可，不必组织完整评审；如果补充内容改变了用例的覆盖范围或影响判断，则应重新走一次评审。无论哪种方式，都建议在修改意见或备注中记录补充完成情况，保持结论与后续动作可对应。
同一用例因多个变更点被重复选中，表格里怎么处理？
两种方式都可行：拆成多行，每行对应一个变更点，选择理由分别填写；或合并为一行，在选择依据中并列多个变更点。拆行便于按变更点统计和追溯，合并则减少重复。团队内部统一一种方式即可，关键是同一批次内不要混用，否则汇总时容易重复计数。
评审表需要和用例库、缺陷单保持同步吗？
建议保持关联而非复制。用例编号直接引用用例库编号，关联需求/缺陷字段填写单号，评审表只记录选择与评审信息，用例内容和缺陷状态仍以原系统为准。这样用例库更新时评审表不会出现两套叫法，复盘时也能顺着编号回到原始记录。执行结果回填后，可与缺陷单状态对照检查。
团队刚开始用这张表，字段太多填不过来怎么办？
先只启用四项必填字段，加上变更点和备注，跑完一个回归批次后再评估。如果评审中经常出现“说不清为什么选”的情况，再增加影响范围和风险等级；如果需要按模块汇总，再增加所属模块。字段随问题逐步增加，比一开始上齐全部字段更容易坚持。
