测试计划职责分工要落到可执行，关键是先把测试目标、范围、层级和资源拆成工作项，再逐项写清谁主责、谁配合、谁审批、何时交接。下面以一个假设的中等规模版本迭代为示例，给出一份已填写的分工表，并解释角色边界与调整规律，便于你按团队情况改写。
要点总览（TL;DR）
- 分工表按工作项展开，每行写清主责、配合、审批/确认人、交付物和时间节点，覆盖范围确认到复盘七个环节。
- 主责与配合按“对结果负责”和“提供输入”区分；审批点设在变更成本高、影响对外承诺的环节，如范围确认与发布判定。
- 小团队可合并角色，但审批人不宜同时是主责人；角色缺失时明确临时补位关系与确认人。
- 分工表随迭代启动核对更新，与测试计划正文配合使用，并用唯一主责、具名确认人、可检查交付物三项自查。
这份示例要解决的分工问题
本文的示例情景设定为：一个中等规模的版本迭代，包含若干功能模块的改造与新增，测试周期约三周，涉及产品、开发、测试、运维和项目管理五类角色。测试团队由一名测试负责人和三名测试工程师组成，开发侧按模块分为两个小组。这个情景用于演示分工表的填写方式，属于假设示例，不代表任何真实客户项目。
一份可用的测试计划职责分工表，需要回答四类问题：
- 做什么：把测试计划拆成具体工作项，例如范围确认、策略选择、用例评审、环境准备、执行跟踪、发布判定、复盘。
- 谁来做：每个工作项指定主责角色，明确对结果负责的人。
- 谁确认：哪些产出需要审批或会签，审批人是谁。
- 何时交接：工作项之间的输入输出在什么节点移交，交接物是什么。
示例中的角色名称、时间节点和交付物都可以替换。真实项目里，团队规模、系统数量、发布节奏不同，分工的颗粒度和角色合并方式也会不同，后文会给出调整规律。
完整示例：一份测试计划职责分工表
下表按测试计划的主要环节展开，每行包含工作项、主责角色、配合角色、审批/确认人、交付物和时间节点。时间节点以版本迭代的周次表示，T 为提测日，R 为发布日。
| 工作项 | 主责角色 | 配合角色 | 审批/确认人 | 交付物 | 时间节点 |
|---|---|---|---|---|---|
| 测试目标与范围确认 | 测试负责人 | 产品负责人、开发负责人 | 产品负责人、项目经理 | 测试范围说明（含不测范围） | 迭代启动后 2 个工作日内 |
| 测试策略与层级选择 | 测试负责人 | 开发负责人 | 项目经理 | 测试策略说明（单元、接口、界面、回归的覆盖比例） | 范围确认后 1 个工作日内 |
| 用例设计与评审 | 测试工程师 | 产品负责人、开发工程师 | 测试负责人 | 用例集与评审记录 | T-5 前完成评审 |
| 环境与数据准备 | 运维/环境管理员 | 测试工程师、开发工程师 | 测试负责人 | 环境就绪清单、测试数据说明 | T-2 前环境可用 |
| 测试执行与缺陷跟踪 | 测试工程师 | 开发工程师 | 测试负责人 | 执行记录、缺陷单及状态 | T 至 R-2 |
| 回归与发布判定 | 测试负责人 | 测试工程师、开发负责人 | 产品负责人、项目经理 | 回归结果、发布判定结论 | R-1 |
| 测试报告与复盘 | 测试负责人 | 全体角色 | 项目经理 | 测试报告、复盘纪要及改进项 | R 后 3 个工作日内 |
角色设定说明：测试负责人统筹计划、策略、判定与报告；测试工程师承担用例设计、执行与缺陷跟踪；开发负责人确认技术方案对测试的影响并组织缺陷修复；产品负责人确认范围与验收口径；运维/环境管理员保障环境与数据；项目经理确认计划节点与发布决策。小团队可以把测试负责人与测试工程师合并，但审批人不宜同时是主责人。
逐项解释：每个角色为什么这样分
主责与配合的区分标准是“对结果负责”与“提供输入”。主责角色对工作项的完成质量和时限负责，出现偏差时由主责人推动解决；配合角色提供信息、资源或技术判断，不承担该工作项的最终结果。例如用例设计的主责是测试工程师，产品负责人提供需求口径，开发工程师提供实现细节，但用例是否覆盖充分由测试负责人评审确认。
审批点的设置逻辑围绕“变更成本”和“对外承诺”。范围确认和发布判定影响版本对外交付，因此需要产品负责人和项目经理共同确认；测试策略影响资源投入，由项目经理确认即可；用例评审属于专业判断，由测试负责人确认，避免审批链过长拖慢节奏。
测试负责人统筹与测试工程师执行的边界，体现在“定规则”和“按规则做”。负责人确定测什么、测到什么程度、什么条件下可以发布；工程师负责把用例写出来、把测试跑完、把缺陷跟到关闭。负责人可以参与执行，但判定结论应由负责人统一出口，避免多人对发布条件给出不一致意见。
开发与运维的配合职责集中在两处：环境与数据准备阶段，运维负责环境可用性，开发负责部署包和配置说明；缺陷修复阶段，开发负责定位与修复，测试负责验证关闭。交接物和交接时机的确定方法是：每个工作项的交付物就是下一个工作项的输入，交付物完成即触发交接。例如环境就绪清单完成，测试执行才能开始；回归结果完成，发布判定才能进行。
分工表落地后，工作项、角色和交接状态需要在协作工具中承载。以 ONES 为例，测试计划可以拆成工作项并指派主责与配合人，用例、缺陷和测试报告作为关联对象随工作项流转，审批节点通过状态流转记录确认人和时间，交接物挂在对应工作项下，便于在版本节奏中核对每个环节是否按表推进。
可迁移规律：换团队规模怎么改这张表
小团队常见的做法是合并角色：测试负责人兼用例评审与执行，产品负责人兼范围确认与发布判定。合并能减少沟通环节，风险是审批人与主责人重合，判定缺少第二双眼睛。可行的缓解方式是把发布判定改为书面结论加异步确认，保留确认记录。
多团队或多系统并行时，分工拆分按“系统边界”和“测试层级”两个维度展开。系统边界决定环境与数据准备的主责归属，测试层级决定用例设计和执行的分工。跨系统联调需要单独设一个协调工作项，主责放在测试负责人或项目经理，配合方为各系统接口人。
角色缺失时的临时补位要有确认机制。例如没有专职运维，环境准备可由开发负责人临时主责，但环境就绪清单仍需测试负责人确认；没有专职项目经理，节点确认可由测试负责人发起、产品负责人确认，并在分工表中注明补位关系和确认人。
分工表随版本节奏更新，建议在每个迭代启动时核对一次：新增工作项是否有人主责，角色是否有变动，交接物是否仍然适用。更新记录保留在测试计划正文中，避免分工表与实际执行脱节。
适用边界与填写注意事项
本示例适用于版本迭代类测试计划，覆盖从范围确认到复盘的主要环节。具体测试脚本的编写规范、性能压测方案、安全攻击技术等内容不在本文范围；单份需求文档的质量评审也属于另一类工作，不纳入这张分工表。
填写时常见的问题有三类。第一，把职责写成岗位名称，例如只写“测试负责”，没有写清负责什么产出、在什么节点完成。第二，审批人空缺或写成“待定”，导致关键节点无人确认，发布判定失去约束。第三，交接物不明确，工作项之间只有口头交接，出问题时无法追溯。
分工表是测试计划的组成部分，不是替代品。测试计划正文说明目标、范围、策略、资源和风险，分工表把其中的责任落实到角色和时间节点。两者一起使用，才能让计划既可读又可执行。填写完成后，可用三个问题自查：每个工作项是否都有唯一主责人，每个审批点是否都有具名确认人，每个交接是否都有可检查的交付物。
常见问题
分工表里主责人和审批人可以是同一个人吗？
原则上不建议。主责人对工作项结果负责，审批人承担确认和把关职责，两者重合时判定缺少第二道检查。小团队确实人手紧张时，可以把审批改为书面结论加异步确认，保留确认记录，并在分工表中注明这种安排，避免后续追溯时说不清谁确认过。
没有专职测试负责人时，这张表怎么填？
可以由测试工程师中资历较深者临时承担统筹职责，或由项目经理代管计划节点。需要同步调整的是审批关系：范围确认和发布判定仍应由产品负责人确认，测试策略可由开发负责人会签。分工表中要写明补位关系和确认人，并在迭代启动时向相关角色同步，避免出现名义上有主责、实际无人推动的情况。
交接物写到什么颗粒度才算清楚？
判断标准是下一个工作项能否直接使用。例如“环境就绪清单”应包含环境地址、可用时间、已知限制；“回归结果”应包含执行范围、通过情况、遗留缺陷及处理意见。只写“完成测试”“环境已好”这类描述，交接时仍需口头补充，出问题也难以追溯。交付物能支撑下一环节启动即可，不必写成完整文档模板。
多个系统并行时，分工表要拆成几张？
可以保留一张总表加若干系统分表。总表列出跨系统协调工作项，如联调计划、接口对齐、统一发布判定，主责放在测试负责人或项目经理；分表按系统列出环境准备、用例设计和执行的具体责任人。两层之间用同一套时间节点对齐，避免各系统各自排期导致联调窗口对不上。
分工表和测试计划正文是什么关系？
测试计划正文说明目标、范围、策略、资源和风险，分工表把其中的责任落到角色和时间节点，属于计划的组成部分。填写分工表时如果发现某项工作找不到合适主责人，往往说明计划中的资源安排还有缺口，应回到正文补充，而不是在表里勉强指派。
