测试计划职责分工要落到可执行状态，起点是把计划要产出的内容拆成一份份可交付物，再按交付物指定唯一负责人、协作角色和评审人，最后用职责矩阵写进测试计划并在评审中逐项确认。本文按“交付物清单—角色分配—写入计划与评审—变更交接—示例—完成检查”的顺序展开，职责矩阵与评审记录也可以放在ONES中随测试计划一起维护。
要点总览（TL;DR）
- 职责分工从交付物清单入手：先列清测试计划要产出的目标与范围、风险与策略、资源与环境、进度与准入准出、缺陷与报告机制，每项写清输入、动作、输出和可观察的完成标志。
- 每项交付物只设一个负责人，协作角色提供输入或人力，评审人按标准把关；三者判定依据分别是承担结果、提供输入、判断合格。
- 把分工写成职责矩阵（交付物、负责人、协作角色、评审人、完成标志、计划完成时间），放在测试计划“组织与职责”一节，评审会上逐行确认并留存记录。
- 执行阶段人员变动、范围调整或依赖变化时，按申请、确认、记录三步更新矩阵，交接覆盖交付物状态、未完成事项和待评审项。
- 用五项检查判断分工是否可执行：唯一负责人、角色落实到人、完成标志可验证、矩阵纳入版本管理、空缺与争议有处理路径。
先定测试计划要产出什么，再谈谁负责
职责分工写成空泛的岗位描述，通常是因为先写了“测试负责人统筹测试工作”“开发配合修复缺陷”这类句子，却没有说明这些工作最终要交出什么。换一个顺序：先列清测试计划本身需要产出哪些内容，每项内容都定义输入、动作、输出和完成标志，职责才有附着点。完成标志要能被第三方观察和验证，例如“范围清单经产品负责人确认并写入计划文档”，而不是“范围明确”。
下表是一份常见的测试计划交付物清单，可按项目实际增删。四列的含义是：输入说明动手前需要拿到什么，动作说明由谁做什么，输出是留在计划或系统中的产物，完成标志是判断该项可以关闭的依据。
| 交付物 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 测试目标与范围 | 版本需求清单、需求优先级、历史缺陷分布 | 圈定本次测试覆盖的需求、模块与不覆盖项，写明测试目标 | 范围清单与目标说明，写入测试计划 | 范围清单经产品负责人确认，不覆盖项写明理由 |
| 风险清单与测试策略 | 需求变更记录、架构说明、上版本遗留问题 | 识别质量风险，按风险确定测试类型、深度与优先级 | 风险清单（含等级与应对）与策略说明 | 每条高风险都有对应测试措施和责任人 |
| 测试资源与环境 | 环境拓扑、测试数据需求、人员可用时间 | 列出所需环境、账号、数据、设备与人力，确认到位时间 | 资源清单与环境准备计划 | 环境可用并经冒烟验证，资源缺口有明确解决时间 |
| 进度与准入准出标准 | 版本排期、提测时间、质量目标 | 编排测试阶段与里程碑，定义提测准入和发布准出条件 | 进度表与准入准出条目 | 标准可量化（如用例执行率、遗留缺陷等级分布），经评审通过 |
| 缺陷管理与测试报告机制 | 缺陷等级定义、报告对象与频率 | 约定缺陷提交、流转、回归规则与报告模板、发送节奏 | 缺陷规则说明与报告模板 | 规则与模板在计划中可查，首份报告按约定时间发出 |
这份清单与后面的职责矩阵是一一对应的：清单里每一行交付物，在矩阵中都对应一行，负责人、协作、评审三列都围绕这行填写。清单先行还有一个好处：评审时讨论的是“这项交付物有没有人真正对结果负责”，而不是“某岗位是否配合”，争议更容易收敛。
按角色拆分职责：谁负责、谁协作、谁评审
角色分配的关键是单一负责人原则：每项交付物只设一个负责人，对结果负责；协作角色提供输入或参与执行；评审人把关质量与准入准出。三者判定依据不同——对最终结果承担责任的人是负责人，为完成该交付物提供必要信息或人力的人是协作人，依据标准判断其是否合格的人是评审人。一个人可以在不同交付物中承担不同身份，但在同一行里只担任一种角色。
常见角色包括测试负责人、测试工程师、开发负责人、产品/需求负责人、运维与环境负责人、项目经理。下表给出一种典型分配，实际项目中按团队结构替换角色名称，但保持“一行一个负责人”的结构。
| 交付物 | 负责人 | 协作角色 | 评审人 |
|---|---|---|---|
| 测试目标与范围 | 测试负责人 | 产品/需求负责人、开发负责人 | 项目经理 |
| 风险清单与测试策略 | 测试负责人 | 开发负责人、测试工程师 | 产品/需求负责人 |
| 测试资源与环境 | 运维与环境负责人 | 测试工程师、开发负责人 | 测试负责人 |
| 进度与准入准出标准 | 测试负责人 | 项目经理、开发负责人 | 项目经理 |
| 缺陷管理与测试报告机制 | 测试工程师（指定一人） | 开发负责人、测试负责人 | 测试负责人 |
跨团队场景需要额外补两件事。一是接口人：当交付物依赖外部团队（如共用环境、第三方接口）时，为每个外部依赖指定一名本方接口人，负责对外沟通和进度同步，接口人不必是该交付物的负责人。二是升级路径：写明当协作方未按时提供输入、评审意见无法达成一致时，由谁在多长时间内裁决，通常由项目经理或测试负责人的上级承担。升级路径写进计划，比事后临时找人更有效。
把分工写进测试计划：职责矩阵与评审确认
职责矩阵建议至少包含六个字段：交付物、负责人、协作角色、评审人、完成标志、计划完成时间。它放在测试计划文档中“组织与职责”一节，紧跟范围与策略之后，让读者先看到要做什么，再看到谁来做。矩阵中的角色名应尽量落到具体人名，至少在计划评审前完成这一转换，避免“测试组”“开发组”这类集体称谓导致无人真正负责。
计划评审会是确认分工的主要场合。议程可以按交付物逐行推进：负责人说明该项的完成标志和时间，协作角色确认能提供的输入与时间，评审人确认把关标准。确认方式建议采用逐项口头确认加记录，评审结束后把确认结果（谁确认、有无保留意见）附在计划或评审记录中。对于有保留意见的行，当场记录待办与责任人，不带着模糊结论进入执行。
评审中常见的两类问题要有处理办法。分工争议，例如两项交付物都指向同一角色导致负荷集中，处理方式是回到完成标志判断哪项更关键，必要时拆分交付物或调整时间，而不是简单加人。空缺角色，例如项目没有专职环境负责人，处理方式是指定一名兼任者并在矩阵中注明兼任，同时把该角色的输入需求写清楚，避免空缺被默认为测试团队兜底。
当测试计划、用例与执行记录在ONES中管理时，测试计划可以与迭代关联，用例可分配执行人，测试计划也可单独配置权限，职责矩阵中的负责人和协作关系因此有对应的系统承载；评审确认的结论可以随计划文档留存，便于执行阶段回查。
执行中的职责变更与交接
计划评审通过只是分工的起点。执行阶段出现人员变动、范围调整、环境或依赖变化时，原矩阵可能失效，需要有明确的更新机制。触发情形一般包括：负责人离岗或转岗、需求范围增减导致新增或取消交付物、测试环境更换或外部依赖方变更、进度压缩导致角色合并。
变更的处理分三步。申请：由发现变化的人提出，说明受影响的交付物和期望的新负责人。确认：由测试负责人与项目经理确认新安排，涉及评审人变化的需征得新评审人同意。记录：在职责变更记录中写明变更日期、原负责人、新负责人、影响范围和确认人。变更记录与测试计划版本同步更新，矩阵中保留变更痕迹，避免出现两个版本的职责说明并存。
交接内容要覆盖三件事：交付物当前状态（已完成、进行中、未开始）、未完成事项及卡点、待评审项及其评审人。交接以清单形式完成，交接双方与测试负责人共同确认。人员变动频繁的项目，可以把交接清单固化为模板，减少每次重新组织信息的时间。
示例：一个版本测试计划的职责分工
以下为演示情景，用于说明填写过程，不代表真实项目数据。某版本计划包含三个需求模块，测试周期两周，团队中有测试负责人一名、测试工程师两名、开发负责人一名、产品负责人一名，环境由运维兼任。
第一步，按S1的清单裁剪出本版本的交付物：目标与范围、风险与策略、环境与数据、进度与准入准出、缺陷与报告机制，共五项。第二步，逐项填写职责矩阵：
| 交付物 | 负责人 | 协作角色 | 评审人 | 完成标志 | 计划完成时间 |
|---|---|---|---|---|---|
| 目标与范围 | 测试负责人 | 产品负责人、开发负责人 | 项目经理 | 范围清单确认，不覆盖项写明理由 | 计划启动后第2天 |
| 风险与策略 | 测试负责人 | 开发负责人、测试工程师甲 | 产品负责人 | 高风险均有测试措施与责任人 | 第3天 |
| 环境与数据 | 运维（兼任） | 测试工程师乙 | 测试负责人 | 环境冒烟通过，测试数据就绪 | 第4天 |
| 进度与准入准出 | 测试负责人 | 项目经理、开发负责人 | 项目经理 | 标准量化并经评审通过 | 第3天 |
| 缺陷与报告机制 | 测试工程师甲 | 开发负责人 | 测试负责人 | 规则与模板可查，首份报告按时发出 | 第5天 |
第三步，评审会上逐行确认，产品负责人对范围行提出补充一条不覆盖理由，当场记录并由测试负责人当天更新。第四步，执行到第二周时，测试工程师甲临时支援其他项目，其负责的缺陷与报告机制需要交接：由测试工程师乙接任负责人，交接清单列明已提交缺陷数量、待回归项和下一份报告时间，测试负责人确认后更新矩阵并记录变更。整个过程说明：分工明确不等于一次写死，而是矩阵、评审记录和变更记录三者能互相对上。
完成检查：分工是否真的明确
在计划评审通过前和执行中定期，用下面这份清单逐项核对。每项都给出通过标准，任一项不通过就回到对应章节修正。
- 每项交付物是否有唯一负责人：矩阵中每行负责人列只有一个人名或明确岗位，没有“测试组共同负责”这类写法。
- 协作与评审角色是否落实到人：协作列和评审列在评审前已由角色名转换为具体人员，外部依赖有本方接口人。
- 完成标志是否可观察、可验证：每条完成标志都能用文档状态、系统记录或评审结论判断，避免“基本完成”“大致明确”。
- 职责矩阵是否随计划评审确认并纳入版本管理：矩阵有版本号或更新日期，评审确认记录可查，变更后矩阵同步更新。
- 空缺与争议是否有明确处理路径：兼任角色已注明，升级路径写明了裁决人和时限。
这五项同时满足，职责分工才算达到可执行状态。此后每次范围或人员变化，按S4的变更流程更新矩阵，分工就能随计划一起保持有效。
常见问题
团队规模很小，测试负责人同时承担多项交付物，职责矩阵还有必要吗？
有必要，但可以简化。小团队里一人兼任多个角色是常态，矩阵的作用是让兼任关系显性化，避免某项交付物在忙碌时被默认为无人负责。做法是保留“一行一个负责人”的结构，在负责人列写具体人名，兼任情况在备注中注明；协作与评审列可以合并到最少的人，但每行仍要能回答“谁对结果负责、谁把关”。当项目范围扩大或人员增加时，这份矩阵可以直接拆分，不需要重新梳理。
评审会上对某项交付物的负责人有分歧，当场定不下来怎么办？
先回到完成标志判断。分歧往往来自对交付物边界理解不同，把该项的完成标志和计划完成时间摆出来，讨论谁具备对结果负责的条件，比争论岗位归属更容易收敛。当场无法达成一致时，记录待办、指定裁决人和裁决时限，由项目经理或测试负责人的上级在时限内决定，结论补入矩阵并注明确认人。不要带着模糊结论进入执行，否则执行阶段会以“当时没定”为由反复扯皮。
外部团队提供的测试环境或接口经常延迟，职责怎么划分才不互相推诿？
为每个外部依赖指定一名本方接口人，接口人负责对外沟通、进度同步和风险上报，不必是该交付物的负责人。环境交付物的负责人仍由本方承担准备与验证职责，完成标志写成“环境可用并经冒烟验证”，把外部延迟转化为可跟踪的风险项，写清预计到位时间和备选方案。接口人与负责人的分工同时写进矩阵，出现延迟时按升级路径由裁决人在约定时限内决定是否调整测试范围或顺序。
职责矩阵需要多久更新一次，变更记录要保留到什么程度？
按事件更新，不按固定周期。人员变动、范围增减、环境或依赖变化、进度压缩导致角色合并时，都触发一次更新，走申请、确认、记录三步。变更记录保留变更日期、原负责人、新负责人、影响范围和确认人即可，与测试计划版本同步，矩阵中保留变更痕迹。项目结束后这些记录可以作为复盘依据，判断哪些交付物经常换人、哪些角色长期空缺，为下一个版本的分工提供参考。
用ONES管理测试计划时，职责矩阵和评审记录放在哪里比较合适？
可以把职责矩阵作为测试计划文档的一节维护，测试计划与迭代关联，用例分配执行人，负责人和协作关系在系统中有对应承载；评审确认结论随计划文档留存，执行阶段回查方便。ONES测试管理支持为用例库、测试计划单独配置权限，也支持自动生成测试报告并自定义报告模板，这些能力可以承接分工后的执行与汇报动作。职责矩阵模板或评审确认表单是否有固定形式，建议在选型或试用时向厂商确认。
