人工与自动化测试的分工，可以按“判断依赖度、执行频次、稳定性、维护成本”四条线拆开：需要主观判断、探索性发现和一次性验证的工作留给人工，规则明确、重复执行、结果可机判的工作交给自动化。下面给出一份已填好的分工示例表，覆盖登录、下单、支付、报表四类典型场景，并逐项说明归属理由、可迁移的划分规律和适用边界。示例为演示情景，不对应真实客户案例。
要点总览（TL;DR）
- 分工按四条线判断：判断依赖度、执行频次、稳定性、维护成本；结果无法机判的活动归人工或协同，高频稳定的回归项归自动化。
- 示例表覆盖登录权限、下单库存、支付退款、报表核对四类场景共 12 项活动，每项给出归属、理由、执行时机和负责人角色。
- 协同项按“人工准备与判定、自动化执行与留证”分工，交接需写清输入数据、执行结果、判定人和留证位置。
- 迁移时按六步填写：列活动、标判断依赖、标频次、标稳定性、定归属、定交接，并在每个迭代结束后复盘调整。
- 产品早期需求频繁变更、强合规审计场景、专项测试以及团队技能结构差异，都需要调整示例中的自动化占比与角色配置。
这份分工示例要解决什么问题
这份示例面向有持续迭代回归需求的 Web 业务系统团队，典型情况是每两到四周一个版本、每次发布前需要回归一批核心链路。团队已经积累了一批测试用例，但人工与自动化之间没有明确边界，常见问题是：该自动化的重复检查仍靠人点，需要人判断的体验问题却试图写成脚本。示例的作用是把这些活动摆到同一张表上，逐项确定归属。
示例的输入有三项：一份测试活动清单（从现有用例和发布检查项中整理）、用例来源（手工用例库与已有脚本）、迭代节奏（本文按双周迭代设定）。输出是一张分工表，每行包含测试活动、归属、划分理由、执行时机和负责人角色。读者拿到表后，可以对照自己的活动清单逐行填写，而不是从零设计分类体系。
需要说明的是，表中的场景、活动项和角色均为通用业务示例，用于演示填写方式。团队实际使用时，活动颗粒度、角色名称和执行时机都应结合自身产品形态调整。
完整分工示例：四类场景的已填表格
下表按四类场景展开，共 16 项测试活动。“协同”表示人工与自动化各自承担一部分动作，交接内容在表格后单独说明。负责人角色按常见配置设定：测试工程师、测试开发、业务测试负责人。
| 测试活动 | 归属 | 划分理由 | 执行时机 | 负责人角色 |
|---|---|---|---|---|
| 登录成功、失败、锁定等固定分支验证 | 自动化 | 规则明确、结果可机判、每次回归都要执行 | 每次构建后 | 测试开发 |
| 权限矩阵逐角色核对 | 协同 | 自动化遍历角色与菜单组合，人工确认越权提示文案与页面表现 | 版本回归 | 测试工程师 + 测试开发 |
| 登录页异常提示的易用性评估 | 人工 | 涉及文案清晰度与交互感受，依赖主观判断 | 需求验收 | 业务测试负责人 |
| 下单主流程（选商品—填地址—提交订单） | 自动化 | 路径固定、高频回归、断言点明确 | 每次构建后 | 测试开发 |
| 库存扣减与超卖边界验证 | 协同 | 自动化构造并发下单并核对库存数，人工设计边界数据与判定异常结果是否可接受 | 版本回归 | 测试工程师 + 测试开发 |
| 促销叠加规则的探索性测试 | 人工 | 组合空间大、规则随运营策略变化，脚本维护成本高于收益 | 需求验收 | 测试工程师 |
| 支付渠道回调成功与失败处理 | 自动化 | 结果状态可机判，渠道回归频繁 | 每次构建后 | 测试开发 |
| 退款金额与手续费计算核对 | 协同 | 自动化按用例批量计算比对，人工确认特殊退款场景的账务口径 | 版本回归 | 测试工程师 + 测试开发 |
| 支付失败后的用户引导与客服话术验证 | 人工 | 涉及跨角色体验与话术一致性，需要人工判断 | 需求验收 | 业务测试负责人 |
| 报表口径与汇总数核对 | 自动化 | 同一口径下可重复比对，适合固定数据集回归 | 每日定时 + 版本回归 | 测试开发 |
| 报表筛选条件组合与展示效果检查 | 协同 | 自动化覆盖主要组合，人工抽查展示与导出效果 | 版本回归 | 测试工程师 + 测试开发 |
| 新报表需求的首轮验证 | 人工 | 需求刚落地、口径尚在确认，一次性验证不适合先投入脚本 | 需求验收 | 测试工程师 |
协同项的交接动作需要写清楚，否则“协同”容易变成双方都不负责。示例中的约定是：登录权限项由人工提供角色清单与预期菜单，自动化遍历并输出差异截图，人工判定差异是否为缺陷；库存项由人工准备并发场景数据与可接受阈值，自动化执行并保留库存流水，人工复核异常单；退款项由人工给出特殊场景清单，自动化批量计算并输出比对表，人工确认账务口径；报表项由人工确定抽查范围，自动化执行比对并留存结果文件，人工判定展示问题。
逐项解释：每一条为什么这样分
判断依赖度决定一项活动能否交给机器。登录页异常提示的易用性、支付失败后的引导话术、促销叠加的探索性测试，共同点是“结果好坏需要人来评估”。这类活动即使能写成脚本点击，也无法自动判断提示是否清楚、话术是否一致，因此归人工。反过来，登录固定分支、下单主流程、支付回调处理的结果是明确的通过或失败，适合自动化。
执行频次与稳定性决定自动化的投入是否划算。下单主流程、支付回调、报表口径核对在每个版本甚至每天都要执行，路径相对固定，脚本写一次可以反复使用。新报表需求的首轮验证只做一次，需求口径还可能调整，先写脚本再改脚本的成本高于人工验证，因此留人工。
维护成本决定一些高频项也要谨慎。促销叠加规则随运营策略变化，界面和规则都可能频繁调整，断言容易失效，脚本维护会持续消耗测试开发时间。示例把这类活动留给人工作为探索性测试，等规则稳定、组合收敛后再评估是否自动化。
协同项的分工逻辑是“人工准备与判定，自动化执行与留证”。权限矩阵、库存边界、退款计算、报表抽查都属于执行量大但判定需要业务理解的活动。自动化负责遍历、比对和保存结果，人工负责设计输入、确认口径和判定异常，两边通过明确的交接物衔接。
示例中保留的人工项，如易用性评估、话术验证、探索性测试，是按判断需要和维护成本做出的选择。这些活动即使工具能力充足，也不适合优先自动化，因为机器无法替代业务判断，强行脚本化反而增加维护负担。
从示例到自己的表：可迁移的划分规律
四条规则在实际填写时会冲突，建议按以下优先级取舍：先看判断依赖度，结果无法机判的一律归人工或协同；再看执行频次，低频活动优先人工；再看稳定性，界面或规则频繁变动的活动暂缓自动化；最后看维护成本，估算脚本编写与后续维护投入是否低于人工执行成本。冲突时的顺序是判断依赖度优先于频次，频次优先于稳定性，稳定性优先于维护成本。
填写可以按六步推进：
- 列活动：从现有用例库和发布检查项中整理出测试活动，颗粒度控制在“一次可独立执行并判定结果”的层面。
- 标判断依赖：逐项标注结果是否需要人工主观评估，需要则进入人工或协同候选。
- 标频次：标注每项活动在每个迭代或每次构建中的执行次数。
- 标稳定性：标注相关页面、规则、数据在近几个版本中的变动情况。
- 定归属：按上述优先级给出人工、自动化或协同。
- 定交接：协同项补齐输入数据、执行结果、判定人和留证位置四个字段。
协同项的交接字段建议固定下来：输入数据写清由谁准备、放在哪里；执行结果写清自动化输出什么形式的结果；判定人写清由哪个角色做最终判断；留证位置写清截图、日志或比对文件存放在何处。四个字段齐全，协同项才能在版本回归时被稳定执行。
分工表需要随迭代节奏复盘。建议每个版本结束后检查三类信号：自动化项是否频繁误报、协同项的交接是否出现遗漏、人工项中是否出现了重复执行且规则稳定的活动。出现前两类信号时调整脚本或交接约定，出现第三类信号时把该活动移入自动化候选。复盘周期与迭代周期保持一致，避免表填写一次后长期不更新。
分工表要真正执行，还需要用例、任务和执行结果在同一处承载。ONES DevOps 解决方案的功能模块组合中包含测试管理，可与项目管理、流水线集成等模块配合，把测试活动、执行记录和缺陷流转放在同一条研发流程里；其工具链集成能力用于打通项目管理与工程实践。团队可以把分工表中的归属和执行时机落到测试任务上，让协同项的交接有明确的状态和记录可查。
适用边界：这些情况要调整示例
产品处于早期、需求频繁变更时，示例中的自动化占比应下调。此时主流程尚未稳定，脚本写完就可能因界面或规则调整而失效，优先用人工探索性测试发现方向性问题，等核心链路稳定后再逐步把高频回归项转入自动化。
强合规或强审计场景对留证和人工复核有额外要求。示例中的留证位置只写到截图和比对文件，这类场景需要补充操作人、时间、审批记录等字段，关键结论可能需要双人复核。分工表应增加复核角色一列，协同项的判定人不能由执行人兼任。
本文范围限定在人工与自动化的活动归属，脚本编写方法、框架选型不在讨论之内；AI 辅助用例生成与缺陷分析属于相邻主题，示例未涉及。性能测试、安全测试等专项测试的分工也未纳入，这类活动通常需要独立的工具和角色配置，不能直接套用本表。
团队规模与技能结构会直接影响分工结果。测试开发人力充足的团队可以把更多协同项转为自动化；缺少脚本维护人力的团队应压缩自动化范围，把资源集中在最高频的核心链路。角色名称也需按实际配置调整，示例中的“测试开发”在部分团队可能由开发兼任。分工表是协作约定，不是固定模板，按自身条件调整后才能落地。
常见问题
分工表里的“协同”项，实际执行时最容易卡在哪里？
最容易卡在交接物不明确：自动化跑完了，但没人说清结果交给谁判定、判定依据是什么、结果文件放在哪里。示例用四个字段固定交接：输入数据由谁准备并放在何处、自动化输出什么形式的结果、由哪个角色做最终判定、截图或比对文件留存在哪里。四个字段齐全后，协同项才能在每个版本稳定复现。若某一项长期出现交接遗漏，可以先把它降级为纯人工，等交接约定理顺后再恢复协同。
自动化脚本经常误报，是应该继续维护还是退回人工？
先区分误报来源。如果断言写得太宽或测试数据不稳定，属于脚本问题，修正断言和数据准备即可；如果相关页面或业务规则在近几个版本频繁变动，说明该活动当前稳定性不足，示例中的做法是暂缓自动化，退回人工或降为协同，等规则收敛后再评估。判断标准可以看两点：误报是否集中在同一批用例，以及修正误报所花的时间是否已接近人工执行成本。两者都成立时，退回人工更划算。
团队没有专职测试开发，这份分工表还能用吗？
可以用，但需要压缩自动化范围。示例中的“测试开发”角色在部分团队由开发兼任，或由测试工程师承担脚本维护。缺少专职人力时，优先把最高频、最稳定的核心链路（如登录固定分支、下单主流程、支付回调）纳入自动化，协同项适当减少，把资源集中在维护成本最低的项上。分工表是协作约定，角色名称和自动化占比都应按实际人力调整，不必照搬示例配置。
分工表多久复盘一次比较合适？
建议与迭代周期保持一致，每个版本结束后检查三类信号：自动化项是否频繁误报、协同项交接是否出现遗漏、人工项中是否出现重复执行且规则已稳定的活动。前两类信号对应调整脚本或交接约定，第三类信号对应把该活动移入自动化候选。复盘频率高于迭代节奏会增加管理成本，低于迭代节奏则容易让表与实际执行脱节。
强合规场景下，示例表需要补哪些内容？
示例中的留证位置只写到截图和比对文件，强合规或强审计场景通常还需要补充操作人、操作时间、审批记录等字段，关键结论可能需要双人复核。落到表上，可以增加“复核角色”一列，并约定协同项的判定人不由执行人兼任。具体留证字段和复核要求应以所在行业的合规规定和内部审计制度为准，本文示例不构成合规建议。
