人工与自动化测试分工要明确，关键是把判断依据和责任归属写成可执行规则：先按用例的稳定性、执行频次、判定客观性和业务风险确定归属，再明确脚本维护、结果判定和失败处理的责任人，最后用准入准出与定期复盘校正分工。本文给出一套可直接落地的划分规则、角色职责表、协作机制和检查清单，适合正在梳理测试分工的测试负责人和团队成员参考。
要点总览（TL;DR）
- 分工先按稳定性、执行频次、判定客观性、业务风险四个维度给每条用例定归属，四维均高优先自动化，任一维度偏低保留人工。
- 落地分四步：盘点打标签、确定首批自动化范围、排定执行节奏与触发条件、设定失败转人工路径，每步都有可查产物。
- 角色上明确测试负责人定规则、自动化测试工程师维护脚本并做失败初判、手工测试工程师复核与提交缺陷、开发角色修复确认。
- 用准入准出、失败归因和按信号触发的复盘维持分工有效，长期失败或需求废弃的用例走下线流程。
- 检查机制是否落地看两点阻断项：无归属标签的用例、长期失败无人处理的脚本。
先定划分依据：哪些用例交给自动化，哪些留给人
分工争议通常来自“凭感觉分配”。更稳妥的做法是给每条用例按四个维度打分，再根据组合结果确定归属。四个维度分别回答：这条用例的接口和界面是否稳定、需要多频繁执行、结果能否由程序客观判定、失败后业务影响有多大。
判定时建议采用“短板原则”：四个维度都处于高位时优先自动化；任一维度明显偏低，例如界面频繁改版、结果依赖视觉或体验判断，则保留人工。这样能避免把维护成本高、判定不客观的用例硬塞进自动化，导致脚本频繁失败却无人处理。
| 维度 | 取值参考 | 归属结论 |
|---|---|---|
| 稳定性 | 接口与页面结构稳定、近期无大改 | 稳定：可自动化；频繁变动：留人工或暂缓 |
| 执行频次 | 每个迭代或每次提交都需回归 | 高频：优先自动化；低频：人工执行 |
| 判定客观性 | 结果可用断言明确表达 | 可客观判定：自动化；依赖主观体验：人工 |
| 业务风险 | 失败影响核心交易或关键流程 | 高风险且可判定：自动化并保留人工抽检；高风险但难判定：人工重点覆盖 |
按这套规则，高频回归、结果可客观判定、接口稳定的用例优先进入自动化，例如登录、下单主流程、接口参数校验。探索性测试、体验与视觉判断、需求频繁变动的用例保留人工，因为这类工作依赖测试人员的经验、联想和即时判断，脚本难以替代。
边界用例和一次性验证需要单独处理。处于稳定性临界值的用例，可以先纳入自动化观察一到两个迭代，连续稳定后再正式归属；一次性验证，例如某次数据迁移后的核对，通常人工执行更划算，不必为它建设长期维护的脚本。
分工落地的操作步骤：从用例盘点走到执行排期
规则确定后，需要按顺序推进四步，每一步都有明确输入、动作和完成标志，避免规则停留在文档里。
第一步：盘点用例并打归属标签。输入是现有用例库，动作是逐条按四维判定表评估，并在用例属性中写入“人工”“自动化”“待评估”标签。输出是一份带归属标签的用例清单。完成标志是所有在用用例都有归属标签，待评估用例数量有明确上限和评估期限。
第二步：确定自动化覆盖优先级与首批范围。输入是带标签的清单和当前迭代的回归压力，动作是按业务风险和回归频次排序，选出首批自动化范围，通常控制在团队一个迭代能稳定交付的规模。输出是首批自动化用例清单和负责人。完成标志是清单经过测试负责人确认，每条用例都有承接人。
第三步：排定执行节奏与触发条件。输入是首批清单和研发流程节点，动作是明确哪些自动化用例在代码提交后触发、哪些在每日构建执行、人工回归安排在哪个阶段。输出是一张执行排期表，写明触发条件、执行方式、责任人和结果记录位置。完成标志是排期表与迭代计划对齐，团队成员都能查到自己的执行任务。
第四步：设定失败用例的转人工判定路径。输入是自动化执行结果，动作是规定失败后先由自动化测试工程师初判，区分环境问题、脚本问题和真实缺陷，再决定重跑、修脚本或转人工复核。输出是失败处理记录和转人工清单。完成标志是每次自动化失败都有处理结论，没有长期挂起无人认领的失败项。
这四步完成后，分工从“口头约定”变成“清单、排期、处理记录”三类可查的产物。后续迭代只需在清单上更新标签、在排期表上调整节奏，不必每次重新讨论归属。
角色与交付物：谁定规则、谁维护、谁判定结果
分工能否持续，取决于每个环节是否有人负责、有产物交接。以下角色划分适用于中小型测试团队，团队规模较大时可以按业务线拆分，但职责边界保持一致。
| 角色 | 核心职责 | 主要交付物 | 交接节点 |
|---|---|---|---|
| 测试负责人 | 制定用例归属规则与自动化准入门槛，确认首批范围，组织复盘 | 归属判定规则、准入条件、复盘记录 | 迭代开始前发布规则与范围；迭代结束后组织复盘 |
| 自动化测试工程师 | 编写与维护脚本，监控稳定性，对失败做初判 | 脚本、稳定性监控记录、失败初判结论 | 提交后执行回归；失败后一个工作日内给出初判 |
| 手工测试工程师 | 执行探索性测试与人工用例，复核自动化转来的失败项，提交缺陷 | 探索测试记录、复核结论、缺陷单 | 收到转人工项后及时复核；缺陷提交后跟踪至关闭 |
| 开发角色 | 修复确认、环境支持、配合定位真实缺陷 | 修复提交、环境说明、缺陷修复确认 | 收到缺陷后按优先级修复；环境变更时提前通知测试 |
需要特别明确两处容易空档的交接。一是脚本维护：自动化测试工程师的维护工作应纳入日常排期，而不是等脚本失败后再临时处理。二是失败判定：自动化执行失败不等于缺陷，初判责任在自动化测试工程师，转人工复核后由手工测试工程师给出最终结论，开发角色负责修复确认。三方各有一份产物，责任链条才完整。
当分工规则需要落到用例归属标签、执行记录和失败处理状态上时，测试管理工具可以承担这部分承载工作。例如 ONES 测试管理支持自定义用例属性，可用来标记人工或自动化归属；支持用例分配执行人，让每条用例的责任人可查；未通过的用例可快速创建缺陷任务，使失败项在测试与研发之间流转。这些能力服务于分工规则的执行和留痕，规则本身仍需团队先行定义。
协作机制：准入准出、失败处理与定期复盘
分工规则建立后，还需要准入准出和复盘机制来维持有效性，否则自动化用例会越积越多、失败项会长期挂起。
自动化用例准入建议满足三个条件：连续多轮回归执行稳定，通过率达到团队约定门槛；脚本结构可维护，断言明确指向业务结果；用例有明确负责人。准入由测试负责人确认，未达条件的用例继续留在人工范围观察。
准出与下线同样需要规则。长期失败且修复成本高于收益的用例、对应需求已废弃的用例，应走下线流程，由负责人提出、测试负责人确认后从自动化范围移除。下线不是失败，而是把维护资源集中到有效用例上。
| 机制 | 触发条件 | 处理动作 | 责任人 |
|---|---|---|---|
| 准入 | 用例完成自动化编写并通过稳定性观察 | 确认断言与负责人，纳入回归排期 | 测试负责人 |
| 失败初判 | 自动化执行失败 | 区分环境、脚本、真实缺陷，决定重跑、修复或转人工 | 自动化测试工程师 |
| 转人工复核 | 初判为疑似真实缺陷或判定存疑 | 人工复现确认，提交缺陷或回退脚本 | 手工测试工程师 |
| 下线 | 长期失败、需求废弃、维护成本过高 | 移除自动化范围，更新归属标签 | 测试负责人确认 |
| 复盘 | 自动化失败率上升、人工回归耗时占比过高、脚本维护积压 | 调整归属比例与执行节奏，更新规则 | 测试负责人组织 |
复盘不必每个迭代都做，可以按信号触发：当自动化失败率持续上升、人工回归占用测试时间明显过多，或脚本维护任务积压时，组织一次分工复盘，检查归属标签是否过时、准入条件是否过松、失败处理是否及时。复盘结论落到规则和清单的更新上，而不是停留在讨论层面。
示例：一个迭代内人工与自动化如何配合
以下为一个演示情景，用于说明规则在单个迭代中的运行方式，具体数值和节奏需按团队实际情况调整。
迭代开始时，测试负责人根据四维判定表给本迭代新增用例打标签：支付主流程的接口校验标为自动化，结算页面的视觉与交互体验标为人工，新改版的优惠券模块因需求仍在变动标为待评估。自动化测试工程师据此更新回归脚本范围，手工测试工程师领取探索性测试任务。
开发提交代码后，自动化回归按排期触发，覆盖登录、下单、支付等稳定主流程。自动化执行期间，手工测试工程师同步开展新功能的探索性测试，重点检查脚本覆盖不到的交互细节和异常路径。
自动化回归出现两条失败。自动化测试工程师初判：一条是测试环境数据未刷新导致，重跑后通过；另一条断言失败指向支付金额计算异常，转人工复核。手工测试工程师复现后确认是真实缺陷，提交缺陷任务并附上复现步骤，开发角色修复后由自动化回归验证通过。
迭代结束时，测试负责人记录本次分工情况：新增自动化用例数量、转人工次数及原因、待评估用例的评估结论。若发现某类用例反复转人工，就在下次复盘中调整其归属或补充断言规则。这份记录同时作为下个迭代排期的输入。
完成检查：分工机制是否真正落地
判断分工机制是否建立并运转，可以逐项核对以下检查项。全部通过说明机制基本落地；存在阻断项时，应先处理阻断项再推进其他优化。
- 在用用例是否都有明确归属标签，待评估用例是否有评估期限和负责人。
- 每次自动化失败是否都有责任人、初判结论和处理结果，是否存在超过约定时限未处理的失败项。
- 脚本维护工作是否纳入日常排期，是否有固定的维护时间或任务。
- 自动化用例是否有准入确认记录，下线用例是否经过确认并更新标签。
- 分工比例是否根据复盘结论调整过，调整是否有记录可查。
- 迭代复盘中是否包含分工运行情况，转人工原因是否被归类分析。
两个阻断项需要优先处理：存在无归属标签的用例，意味着执行责任不清；存在长期失败且无人处理的脚本，意味着维护机制失效。这两类问题会直接侵蚀分工的可信度，发现后应立即指派负责人并在下一次执行前闭环。
常见问题
用例处于稳定性临界值，应该先归人工还是先归自动化？
可以先把这类用例纳入自动化观察一到两个迭代，连续稳定后再正式归属自动化；观察期内仍保留人工执行作为对照。若观察期内失败频繁且原因集中在界面变动或数据准备，就退回人工范围，避免维护成本持续累积。
自动化执行失败后，怎么避免直接甩给人工复核？
在流程上先设一道初判：由自动化测试工程师区分环境问题、脚本问题和疑似真实缺陷，环境问题重跑、脚本问题修复、疑似缺陷才转人工复核。转人工时附上失败日志、断言内容和初步判断，手工测试工程师据此复现，减少来回确认。每次失败都记录处理结论，长期挂起的失败项纳入复盘。
团队规模较小，角色职责能否合并？
可以合并角色，但要保留职责边界和交接产物。例如自动化测试工程师同时承担脚本维护和失败初判，手工测试工程师同时承担探索性测试和转人工复核，测试负责人同时制定规则并组织复盘。合并后仍需保证每条用例有归属标签、每次失败有处理结论，避免职责合并后无人对结果负责。
分工比例需要定一个固定数值吗？
不必追求固定比例。更实用的做法是按信号触发复盘：自动化失败率持续上升、人工回归占用测试时间明显过多、脚本维护任务积压时，组织一次分工复盘，检查归属标签是否过时、准入条件是否过松，再调整归属比例和执行节奏。调整结论落到规则和清单更新上，并有记录可查。
分工规则落到工具里，主要承载哪些信息？
主要是三类：用例的归属标签、每条用例的执行责任人、失败后的处理状态与缺陷流转。以 ONES 测试管理为例，支持自定义用例属性用于标记人工或自动化归属，支持用例分配执行人，未通过的用例可快速创建缺陷任务在测试与研发之间流转。规则本身仍需团队先行定义，工具承担执行与留痕。
