自动化测试任务清单把“哪条用例、在哪个环境、由谁执行、结果如何、缺陷怎么跟”固定在同一行记录里，避免执行结果散落在聊天记录、流水线日志和个人表格中。下面的模板可直接复制到表格工具使用，并附字段口径、必填划分、一条完整填写示例和维护方法，适合刚开始建立自动化测试执行记录的团队按需裁剪。
要点总览（TL;DR）
- 空白模板按“任务标识—用例关联—执行载体—环境—人员与时间—结果与缺陷—状态”七组排列，复制表头即可逐行登记任务。
- 必填字段为任务编号、关联用例、执行环境、负责人、执行结果、状态；失败原因、缺陷链接在失败或阻塞时必填，实际执行时间在完成或关闭时必填。
- 填写时区分“关联用例”与“脚本/流水线标识”：前者说明业务上验证了什么，后者说明技术上由什么执行，两者保持对应。
- 维护上先定新增字段的判断标准，再固定四档状态流转，按迭代或按月归档，并让缺陷状态以缺陷系统为准。
- 清单可与缺陷跟踪、测试报告衔接，每条报告结论应能回溯到具体任务编号。
可复制空白模板：自动化测试任务清单表
下表按“任务标识—用例关联—执行载体—环境—人员与时间—结果与缺陷—状态”七组排列字段，复制表头后即可逐行登记任务。两行空白行用于确认列宽和填写位置，正式使用时按实际任务数量增删行。
| 任务编号 | 关联用例 | 脚本/流水线标识 | 执行环境 | 负责人 | 计划执行时间 | 实际执行时间 | 执行结果 | 失败原因 | 缺陷链接 | 状态 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|
字段顺序有实际作用：左侧先回答“测什么、在哪测”，中间回答“谁在什么时候测”，右侧回答“结果怎样、问题去哪了”。团队如果使用在线表格，建议冻结前四列和表头，方便横向滚动时仍能定位任务。
字段说明：每个字段填什么、怎么填
同一字段在不同团队可能有不同叫法，关键是填写口径统一。下表给出每个字段的含义、推荐填法和常见错误，可作为清单的使用说明附在表格首页。
| 字段 | 填什么 | 推荐填法 | 常见填错 |
|---|---|---|---|
| 任务编号 | 本次自动化测试任务的唯一标识 | 采用“项目缩写-迭代号-序号”，如 PAY-S12-003；编号一经分配不复用 | 用用例编号代替任务编号，导致同一用例多次执行无法区分 |
| 关联用例 | 本次任务覆盖的测试用例 | 填写用例管理工具中的用例编号；一条任务覆盖多条用例时用逗号分隔，或拆成多行 | 只写用例标题，后续无法与用例库对应 |
| 脚本/流水线标识 | 执行该用例的脚本路径、流水线名称或构建号 | 脚本写仓库路径加文件名，流水线写名称加构建号，如“pay-regression #218” | 只写“自动化脚本”，出问题后无法定位到具体执行载体 |
| 执行环境 | 任务运行的环境及其版本配置 | 写清环境名称、服务版本和关键配置，如“测试环境-订单服务 v2.3.1-独立数据库” | 只写“测试环境”，不同版本结果无法比较 |
| 负责人 | 对本次执行结果负责的人 | 填写具体姓名或工号，不写团队名 | 写“测试组”，失败后无人跟进 |
| 计划执行时间 | 任务排期中的执行时点 | 精确到日期和时段，如“2025-03-11 22:00” | 只写日期，夜间批量任务无法判断是否按时启动 |
| 实际执行时间 | 任务真实开始执行的时间 | 由流水线时间戳或执行记录复制，不凭记忆补填 | 与计划时间混填在一列 |
| 执行结果 | 本次执行的结论 | 统一取“通过、失败、阻塞、未执行”四值之一 | 写“基本通过”“部分通过”，无法统计通过率 |
| 失败原因 | 失败或阻塞的直接原因 | 写现象加定位信息，如“支付回调超时，日志显示第三方接口 504” | 写“环境问题”而不给具体现象，无法复现 |
| 缺陷链接 | 失败对应缺陷单的地址或编号 | 填写缺陷系统中的单号或可点击链接 | 把缺陷描述直接抄进单元格，缺陷状态无法同步 |
| 状态 | 任务当前所处的处理阶段 | 从“待执行、执行中、已完成、已关闭”中选择 | 结果已出但状态仍停留在“执行中” |
| 备注 | 其他需要说明的信息 | 记录重跑次数、跳过原因、临时豁免等 | 把失败原因和缺陷信息重复写进备注 |
“关联用例”和“脚本/流水线标识”容易混淆：前者回答业务上验证了什么，后者回答技术上由什么执行。两者保持对应关系，才能在用例变更时找到需要同步修改的脚本，也才能在脚本报错时回溯它服务的用例。
必填与选填：按团队阶段划分字段等级
字段并非越多越好。刚建立清单的团队先保证必填字段完整，再随执行量增加补充选填字段，可以降低填表负担，也避免大量空列让表格难以阅读。
| 等级 | 字段 | 理由 |
|---|---|---|
| 必填 | 任务编号、关联用例、执行环境、负责人、执行结果、状态 | 这六项共同回答“测了什么、在哪测、谁负责、结果如何、进展到哪”，缺一项就无法追踪任务 |
| 条件必填 | 失败原因、缺陷链接 | 执行结果为“失败”或“阻塞”时必填；结果为“通过”时留空 |
| 条件必填 | 实际执行时间 | 任务进入“已完成”或“已关闭”状态时必填，用于核对是否按计划执行 |
| 选填 | 脚本/流水线标识 | 执行由统一平台调度、构建号可自动带出的团队可暂不手填；多团队共用脚本仓库时建议填写 |
| 选填 | 计划执行时间 | 有固定回归排期的团队建议填写；按需触发的小规模任务可省略 |
| 选填 | 备注 | 用于记录重跑、跳过等例外情况，按需使用 |
裁剪时建议从右往左删：先去掉备注，再去掉计划执行时间，最后考虑脚本标识。必填字段不建议裁剪，尤其是执行环境和负责人，这两项缺失会让失败复盘失去基本线索。团队执行量稳定、重跑频繁后，可以再增加“重跑次数”“关联需求”等字段。
填写示例：一条完整任务记录
以下为演示情景，数据为虚构，用于说明各字段如何协同表达一次自动化测试执行。
| 字段 | 填写内容 |
|---|---|
| 任务编号 | PAY-S12-003 |
| 关联用例 | TC-PAY-0112、TC-PAY-0113 |
| 脚本/流水线标识 | pay-regression #218 |
| 执行环境 | 测试环境-订单服务 v2.3.1-独立数据库 |
| 负责人 | 李敏 |
| 计划执行时间 | 2025-03-11 22:00 |
| 实际执行时间 | 2025-03-11 22:06 |
| 执行结果 | 失败 |
| 失败原因 | 支付回调超时，日志显示第三方接口返回 504 |
| 缺陷链接 | BUG-2047 |
| 状态 | 已完成 |
| 备注 | 首次执行，未重跑 |
逐项看取值来源：任务编号按“项目缩写-迭代号-序号”生成，与用例编号区分；关联用例取自用例库，两条用例因共用同一支付回调流程合并为一次执行；流水线标识来自调度平台的构建记录；执行环境写明了服务版本和数据库配置，便于判断失败是否与环境差异有关；实际执行时间取自流水线时间戳，比计划晚 6 分钟，属于正常排队。
该行结果为“失败”，因此失败原因和缺陷链接按条件必填规则填写。失败原因写的是可复现的现象和定位线索，缺陷链接指向缺陷系统中的 BUG-2047，后续缺陷修复状态在缺陷系统中更新，清单只保留引用。状态填“已完成”表示本次执行动作已结束，缺陷是否修复不影响该行状态；若团队希望区分“执行完成待验证”，可在状态取值中增加一档。
调整与维护方法：让清单长期可用
清单上线后最常见的两个问题是字段越加越多、状态长期不更新。维护规则应明确“什么时候加字段、状态怎么流转、多久清理一次”，并把这些动作落到具体负责人。
新增字段的判断标准
新增字段前先问三个问题：这个信息是否已有字段可以承载；是否有至少两类任务需要它；谁来填、什么时候填。三个问题都有明确答案再新增。新增时在表格末尾追加列，同步更新字段说明表，并对存量行做一次回填或标注“历史数据未采集”，避免新旧口径混用。
状态取值与流转规则
建议保持四档状态：待执行、执行中、已完成、已关闭。任务排期后置为“待执行”；流水线启动后置为“执行中”；结果记录完成置为“已完成”；失败任务对应的缺陷关闭且验证通过后置为“已关闭”。状态变更由负责人操作，禁止跳过“执行中”直接关闭，以便统计执行时长。
定期清理与归档节奏
按迭代或按月归档已完成且已关闭的任务行，归档表保留原字段结构，主表只保留当前周期任务。归档前核对三件事：失败行是否都有缺陷链接、已完成行是否都有实际执行时间、状态是否与实际进展一致。核对结果可作为测试报告的输入。
与缺陷跟踪、测试报告的衔接
清单中的缺陷链接指向缺陷系统，缺陷状态以缺陷系统为准，清单不重复维护缺陷进展。测试报告按清单汇总通过率、失败分布和环境差异，报告中的每条结论应能回溯到具体任务编号。若团队使用 ONES 承载研发协作，可将自动化测试任务登记为工作项，通过工作项状态承载上述流转；ONES DevOps 解决方案支持集成 Jenkins、GitLab CI 等第三方流水线工具，集成后自动同步流水线数据并更新执行状态和日志，减少手工回填执行时间与结果的工作量。ONES Project 的自动化规则支持任务与需求的状态联动，例如全部任务完成后自动完成来源需求，可用于清单任务与需求进度的衔接。具体集成配置与规则启用方式以团队实际环境为准。
常见问题
团队刚开始用这张清单，字段太多填不过来怎么办？
先只保留六个必填字段：任务编号、关联用例、执行环境、负责人、执行结果、状态。条件必填字段在触发条件出现时再填，选填字段按需补充。裁剪时从右往左删，先去掉备注，再去掉计划执行时间，最后考虑脚本/流水线标识。执行环境和负责人不建议裁剪，这两项缺失会让失败复盘失去基本线索。
一条任务覆盖多条用例时，应该拆成多行还是写在一行？
看执行方式。多条用例由同一次流水线执行、结果同时产生时，可以写在一行，关联用例用逗号分隔；如果各用例分别执行、结果可能不同，就拆成多行，每行独立记录执行结果和缺陷链接。拆分的判断标准是“结果是否能独立判定”，能独立判定就单独成行。
执行结果为“失败”但还没提缺陷，缺陷链接怎么填？
按条件必填规则，失败时缺陷链接应填写。如果缺陷尚未提交，可先填“待提交”并在备注中说明，同时把状态保持在“已完成”或按团队约定单独标记，避免该行被当作已闭环。下次核对时优先检查这类行，确认缺陷已提交后补上单号。
清单里的状态和缺陷状态是什么关系？
两者分开维护。清单状态描述任务本身的处理阶段，取“待执行、执行中、已完成、已关闭”四档；缺陷状态以缺陷系统为准，清单只保留缺陷链接作为引用。失败任务对应的缺陷关闭并验证通过后，再把清单状态置为“已关闭”。这样通过率统计和缺陷进展统计各取所需，不会互相覆盖。
清单任务能否与需求进度联动，减少手工更新？
可以借助工作项和自动化规则实现。若团队使用 ONES 承载研发协作，可将自动化测试任务登记为工作项，由工作项状态承载流转；ONES Project 的自动化规则支持任务与需求的状态联动，例如全部任务完成后自动完成来源需求，可用于清单任务与需求进度的衔接。ONES DevOps 解决方案支持集成 Jenkins、GitLab CI 等第三方流水线工具，集成后自动同步流水线数据并更新执行状态和日志，减少手工回填执行时间与结果。具体集成配置与规则启用方式以团队实际环境为准。
