人工与自动化测试分工的核心，是按“判断价值”和“执行成本”把测试活动拆开：需要主观判断、探索性发现、体验与业务规则判断的活动交给人工；稳定、重复、可断言、回归频次高的活动交给自动化。本文给出一套可直接套用的归类规则、五步落地流程、角色交付物对照表和完成检查清单，帮助团队把分工从口头约定变成可维护、可复核的机制。文中示例仅作方法示范。
要点总览（TL;DR）
- 分工按“判断价值”和“执行成本”两个维度归类：探索性测试、体验判断、复杂业务规则验证和一次性验证优先人工；稳定回归、接口与数据校验、重复冒烟、多环境一致性检查优先自动化。
- 不稳定用例、频繁变更模块和断言难以表达的场景，先由人工承接并记录暂缓原因与重评条件，等条件成熟再评估自动化。
- 落地按五步推进：盘点活动与频次、逐项标注归属、指定负责人与触发时机、定义自动化失败后的人工复核路径、约定复核周期与调整触发条件。
- 测试负责人维护活动清单与判定规则，自动化工程师承接自动化活动并维护用例稳定性，手工测试人员承接探索与判断类活动，开发配合定位失败原因，产品与业务角色提供规则口径。
- 用活动清单覆盖度、触发时机与产出、失败复核路径、回归覆盖率与缺陷发现分布、复核记录和争议裁决方式六项检查机制是否真正运转。
分工先定标准：哪些测试交给人工，哪些交给自动化
分工争议通常来自没有共同标准：有人按“能不能写脚本”判断，有人按“以前是谁做的”判断，结果同类活动在不同迭代里归属不一致。更稳定的做法是用两个维度同时判断：一是这项活动需要多少主观判断，二是把它自动化的执行成本有多高。判断价值高、结果难以用断言表达的活动，人工承担更合适；执行成本高、重复频次高、结果可明确断言的活动，自动化收益更明显。
两个维度并不总是同向。有些活动判断价值不高但自动化成本也很高，例如界面频繁改版的流程校验，此时应优先人工承接并记录原因，等界面稳定后再评估自动化。归类时建议对每项活动同时标注两个维度的判断结果，而不是只写一个“人工/自动化”结论，这样后续复核时能看清当时的依据。
人工优先的活动类型
- 探索性测试：没有预设脚本，依靠测试人员的经验、直觉和即时判断发现异常，产出是发现的问题与对风险区域的判断。
- 体验与可用性判断：涉及操作是否顺畅、提示是否清晰、交互是否符合用户预期，结论依赖人的感受和业务理解。
- 复杂业务规则验证：规则组合多、例外情况多、判断依据来自业务方口径，需要人工对照规则逐条确认。
- 一次性验证：只执行一次或极少复现的检查，例如特定配置变更后的验证，自动化的投入产出不划算。
自动化优先的活动类型
- 稳定回归：功能已定型、每次版本都需要重复验证的核心路径，结果可用明确的预期值断言。
- 接口与数据校验：输入输出结构清晰、字段与取值可精确比对，适合批量、高频执行。
- 重复性冒烟：每个版本或每次构建后都要快速确认主流程可用，执行频次高、步骤固定。
- 多环境一致性检查：同一组检查需要在多个环境重复执行，人工逐环境操作容易遗漏，自动化可保证执行口径一致。
边界情形怎么处理
有三类场景容易在归类时卡住，建议统一按“暂缓自动化、人工承接、记录原因”处理，而不是勉强写成自动化用例。第一类是不稳定用例：执行结果时好时坏，先排查是环境、数据还是用例本身的问题，稳定前由人工复核结果。第二类是频繁变更模块：界面或规则还在快速调整，自动化维护成本高于收益，等变更收敛后再评估。第三类是断言难以表达的场景：结果需要综合判断而非单一比对，保留人工结论，并把判断要点写进活动说明，供后续参考。
暂缓不等于放弃。每项暂缓自动化的活动都应记录暂缓原因、当前承接方式和重新评估的条件，例如“模块连续两个版本无结构性变更后重新评估”，避免这类活动长期无人复盘。
归类结果要落成活动清单
归类结论需要记录为一份可维护的测试活动清单，而不是散落在会议记录里。清单至少包含以下字段，便于逐项核对和定期复核。
| 字段 | 填写内容 | 作用 |
|---|---|---|
| 活动名称 | 具体测试活动的简短描述 | 统一叫法，避免同一活动多种表述 |
| 所属模块/范围 | 功能模块或系统范围 | 便于按模块评估变更影响 |
| 执行频次 | 每版本、每次构建、按需等 | 判断自动化收益的基础 |
| 判断价值 | 高/中/低及简要理由 | 记录归类依据 |
| 自动化成本 | 高/中/低及简要理由 | 记录归类依据 |
| 归属 | 人工、自动化、暂缓自动化 | 明确当前承接方式 |
| 负责人 | 具体角色或人员 | 避免职责悬空 |
| 触发时机 | 何时执行，如提测后、每日构建后 | 保证活动按节奏发生 |
| 产出物 | 测试记录、缺陷单、结论说明等 | 便于验收和追溯 |
| 暂缓原因与重评条件 | 仅暂缓项填写 | 防止长期搁置 |
从活动清单到分工方案：五步操作流程
有了判定规则，下一步是把规则转成团队可执行的分工方案。下面五步按顺序推进，每一步都明确输入、动作、输出和完成标志，便于测试负责人组织落地。
第一步：盘点现有测试活动与执行频次
输入：现有测试用例、测试计划、历史缺陷记录和团队成员的日常操作习惯。动作：按模块梳理当前实际在做的测试活动，合并重复表述，补上那些“一直在做但没写进用例”的检查，例如上线前的人工巡检。输出：一份覆盖主要模块的测试活动初稿，每项活动标注执行频次。完成标志：团队成员对初稿没有“漏掉了某项常规检查”的明显异议。
第二步：按判定规则逐项标注人工或自动化
输入：第一步的活动初稿和上一节的判定规则。动作：对每项活动标注判断价值、自动化成本和归属结论，暂缓自动化的写明原因与重评条件。标注时由测试负责人牵头，自动化工程师和手工测试人员共同参与，避免单方面判断。输出：完成标注的活动清单。完成标志：每项活动都有归属结论，暂缓项都有原因记录，没有空白项。
第三步：为每项活动指定负责人与触发时机
输入：完成标注的活动清单。动作：为每项活动指定负责人角色，明确执行触发点，例如“提测后一个工作日内执行”“每日构建后自动执行、次日查看结果”。同时写明产出物形式，是测试记录、缺陷单还是结论说明。输出：带负责人、触发时机和产出物的分工表。完成标志：任意抽查一项活动，都能找到负责人和明确的执行时点。
第四步：定义交接点，特别是自动化失败后的复核路径
输入：分工表。动作：梳理活动之间的交接关系，重点是自动化执行失败后的处理路径：由谁判断是环境问题、用例问题还是真实缺陷，判断结论如何流转到缺陷记录，什么情况下转人工复核。同时明确人工发现的问题如何进入缺陷跟踪，避免只在聊天工具里口头传递。输出：交接路径说明，附在分工表或单独的执行规范中。完成标志：自动化失败后，团队能说清第一步找谁、判断结论记在哪里。
第五步：设定复核周期与调整触发条件
输入：分工表与交接路径说明。动作：约定固定复核周期，例如每个版本结束后或每月一次，由测试负责人组织检查分工执行情况。同时约定调整触发条件，例如模块发生结构性变更、自动化用例连续多次失败、某类缺陷反复由人工发现而自动化未覆盖。输出：复核安排与调整触发条件清单。完成标志：下一次复核的时间和负责人已确定，调整条件写入团队约定。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 盘点活动 | 用例、计划、缺陷记录 | 梳理活动并标注频次 | 活动初稿 | 无明显遗漏 |
| 逐项标注 | 活动初稿、判定规则 | 标注判断价值、成本与归属 | 完成标注的清单 | 无空白项，暂缓项有原因 |
| 指定负责人与时点 | 完成标注的清单 | 分配负责人、触发时机、产出物 | 分工表 | 抽查可追溯到人 |
| 定义交接点 | 分工表 | 梳理失败复核与缺陷流转路径 | 交接路径说明 | 失败后处理路径清晰 |
| 设定复核 | 分工表、交接说明 | 约定周期与调整条件 | 复核安排 | 时间与负责人已确定 |
角色与交付物：谁负责划分、谁负责执行
分工机制能否持续运转，取决于每个角色是否清楚自己维护什么、交付什么。下面按角色列出职责与交付物，团队可根据实际人员配置合并角色，但职责本身不宜空缺。
| 角色 | 主要职责 | 交付物/交接物 |
|---|---|---|
| 测试负责人 | 维护测试活动清单与判定规则，组织复核，处理分工争议 | 活动清单、判定规则说明、复核记录、争议裁决结论 |
| 自动化测试工程师 | 承接自动化活动，维护用例稳定性，分析执行失败原因 | 自动化用例、执行结果记录、失败原因分析 |
| 手工测试人员 | 承接探索性、体验判断与复杂规则验证活动，输出发现与结论 | 探索记录、问题清单、验证结论说明 |
| 开发人员 | 配合定位自动化失败原因，修复缺陷 | 缺陷修复记录、失败原因确认结论 |
| 产品与业务角色 | 提供业务规则口径与验收判断依据 | 规则说明、验收标准、判断依据确认 |
角色之间有两处交接最容易出问题。一是自动化失败后的判断交接：自动化工程师给出初步分析，开发人员确认是否为缺陷，测试负责人决定是否转人工复核，三方结论应记录在同一处，避免各说各话。二是业务规则验证的交接：产品与业务角色提供规则口径后，手工测试人员据此执行验证并输出结论，规则变更时由产品角色同步更新依据，防止验证标准过期。
当团队使用测试管理工具承载这套机制时，活动清单、负责人分配和执行状态需要有统一的记录位置。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，并支持用例分配执行人，便于把分工表中的负责人和触发时机落到具体的测试计划里；未通过的用例可快速创建缺陷任务，缺陷任务在测试与研发团队间流转，对应上文自动化失败后转缺陷记录的交接路径。这些能力用于承载分工执行过程，划分标准本身仍需团队自行约定。
示例：一个版本迭代中的分工安排
以下示例为方法示范，用于说明分工方案如何落到一个迭代周期，不代表特定工具能力或实测结果。假设某版本包含两个新增功能模块和若干既有模块的改动。
迭代内的范围划分
新增功能模块在需求评审后进入开发，提测时功能仍在调整，此阶段以人工探索为主：手工测试人员按业务规则执行探索性测试，重点验证规则组合和异常路径，输出问题清单和风险区域判断。既有模块的改动范围明确、核心路径稳定，由自动化承担冒烟与回归：每次构建后执行冒烟检查，版本提测后执行回归用例，结果记录在测试计划中。
执行路径
- 提测当天：自动化冒烟执行，确认主流程可用；手工测试人员同步开始新增功能的探索性测试。
- 提测后第一至二天：手工测试人员完成复杂业务规则验证，提交问题清单；自动化回归在功能修复后重复执行。
- 自动化失败时：自动化工程师先判断是环境、数据还是用例问题，确认为疑似缺陷后转开发人员定位，开发确认后创建缺陷任务，必要时由手工测试人员补充人工复核。
- 版本收尾：测试负责人汇总本轮人工发现与自动化拦截的缺陷分布，作为下轮分工调整的依据。
版本节奏中的调整
如果新增功能在迭代后期趋于稳定，测试负责人可在复核时评估将其核心路径纳入自动化回归，并记录评估结论。反之，如果某自动化用例连续多个版本失败且排查成本高，应记录原因并评估是否暂缓，改由人工承接。调整结论写入活动清单，保持清单与实际情况一致。
分工落地后的完成检查
分工方案写完不等于机制运转。建议在首次落地后和每个复核周期，用下面这份清单逐项核对，发现缺口就回到对应步骤修补。
| 检查项 | 核对方式 | 通过标准 |
|---|---|---|
| 活动清单覆盖度 | 对照近期测试计划和缺陷记录抽查 | 主要测试活动均在清单中，且每项有负责人 |
| 触发时机与产出明确 | 随机抽取若干活动询问执行人 | 能说清何时执行、产出记在哪里 |
| 自动化失败复核路径 | 查看近期失败记录的处理过程 | 每次失败都有判断结论和后续动作 |
| 回归覆盖率与缺陷发现分布 | 按版本统计自动化覆盖的回归范围与人工、自动化各自发现的缺陷 | 数据被定期观察，并用于调整分工 |
| 复核周期与调整条件 | 查看复核记录 | 复核按约定发生，调整有触发依据 |
| 分工争议裁决方式 | 回顾近期争议的处理 | 争议有明确裁决人，结论记录在案 |
检查中若发现某类缺陷反复由人工发现而自动化长期未覆盖，说明分工需要调整，应回到活动清单补充评估；若发现自动化用例频繁失败但无人跟进，说明交接路径没有真正执行，需要重新明确失败后的第一责任人和记录位置。分工争议的裁决方式建议提前约定，例如由测试负责人依据判定规则裁决，涉及业务规则口径的由产品角色确认，裁决结论写入活动清单备注，供后续复核参考。
常见问题
自动化用例频繁失败，应该先修用例还是先改分工？
先判断失败原因，再决定动作。连续失败通常来自三类问题：环境或数据不稳定、用例本身随功能变更失效、真实缺陷未被及时识别。建议由自动化工程师先给出初步分析，开发人员确认是否属于缺陷，测试负责人根据结论决定处理方式。若属于环境或数据问题，优先修复执行条件；若属于用例随功能变更失效，评估该活动是否应暂缓自动化、改由人工承接，并记录重评条件。把失败原因和结论记录在同一处，避免同类问题反复出现。
新增功能还在频繁调整，什么时候适合把它的测试活动纳入自动化？
判断依据是变更是否收敛，而不是功能是否上线。可以约定一个可观察的条件，例如模块连续两个版本没有结构性变更、核心路径的输入输出趋于稳定、断言可以明确表达。满足条件后，在复核时评估将其核心路径纳入自动化回归，并记录评估结论。在此之前，由人工承接探索性测试和规则验证，同时把判断要点写进活动说明，为后续自动化提供依据。
分工方案落地后，人工和自动化的比例需要设定目标吗？
不建议把“人工与自动化的用例数量比例”作为统一目标，因为不同模块的稳定性和判断复杂度差异很大。更有参考价值的是观察回归覆盖率、缺陷发现分布和人工投入结构：自动化是否覆盖了高频回归路径，人工发现的缺陷是否集中在探索和规则判断类活动，自动化失败是否得到及时处理。这些数据按版本统计并用于调整分工，比设定固定比例更能反映分工是否合理。
团队规模较小、角色合并时，分工机制怎么简化？
角色可以合并，职责不宜空缺。小团队中测试负责人可能同时承担手工测试，自动化工程师可能由开发兼任，但活动清单的维护、归属判定、失败复核路径和复核周期仍需有人明确负责。简化方式是减少文档层级：把活动清单、负责人、触发时机和暂缓原因放在同一张表里，复核记录附在版本总结中，争议裁决由测试负责人依据判定规则做出并记录结论。关键是每项活动都能追溯到负责人和执行时点。
自动化失败后转人工复核，复核结论应该记录在哪里？
复核结论应与失败记录放在同一处，便于追溯和统计。建议在测试执行记录中保留失败用例、失败原因初步分析、开发确认结论和人工复核结论，形成一条完整的处理链路。若确认为缺陷，转为缺陷任务并关联原用例；若判定为环境或用例问题，记录处理方式和后续动作。这样在复核周期统计缺陷发现分布时，能区分自动化拦截、人工复核发现和人工探索发现，为分工调整提供依据。
