测试计划里常见的情况是：计划写了“测试工程师负责执行、开发配合修复”，真正执行时却没人说得清谁在什么时候交出哪份产物。职责分工要落到可交付物上：先拆活动，再用职责矩阵指定唯一负责人和评审人，最后通过评审与复盘检查分工是否执行。测试计划与职责矩阵可以在ONES的工作项和文档中统一承载，便于评审和跟踪。
要点总览（TL;DR）
- 职责分工先拆活动：按测试层级与阶段交叉列出活动清单，一项活动对应一个可验收的产物，中等规模版本通常15到30项。
- 职责矩阵固定七个字段：活动、输入、输出、负责人、协作角色、评审人、完成标志；负责人唯一、评审人独立、完成标志可核验。
- 按角色和时点整理交付物对照表，明确提测、验收等交接点的确认方式，避免口头交接。
- 分工落地靠三个环节检查：计划评审逐行核对矩阵，执行阶段跟踪交付物时点与交接记录，阶段复盘用清单确认调整是否同步。
先定分工对象：测试计划里要拆出哪些活动
职责分工模糊，往往源于分工对象本身不清楚。直接按岗位写“测试经理负责计划、测试工程师负责执行”，粒度太粗，无法判断某项工作是否完成。可行的做法是先列活动清单，再谈角色。
活动拆解用两个维度交叉：测试层级和测试阶段。测试层级按单元、集成、系统、验收展开；测试阶段按计划、设计、执行、收尾展开。交叉后逐格判断是否有实际活动，没有的格子留空，不必强行填满。例如单元测试通常没有独立的验收阶段活动，系统测试则四个阶段都有内容。
拆出的活动要区分计划类与执行类。计划类活动产出方案性文档，如测试范围说明、测试策略、进度与资源安排、风险评估；执行类活动产出过程性记录，如测试用例集、测试数据、执行记录、缺陷清单、测试报告。两类活动的负责人和评审方式通常不同，混在一起写会导致责任不清。
粒度标准只有一条：一项活动对应一个可验收的产物。如果一项活动说不清交付什么、由谁接收、怎样算完成，就继续往下拆。“开展系统测试”不是活动，“编写系统测试用例并通过评审”才是。按这个标准，一个中等规模版本的测试计划活动清单通常在15到30项之间；超过这个数量说明拆得过细，可以合并同类项。
活动清单建议用三列表格维护：层级、阶段、产出物。下表是一个简化示例。
| 测试层级 | 阶段 | 产出物 |
|---|---|---|
| 系统测试 | 计划 | 系统测试范围与策略说明 |
| 系统测试 | 设计 | 系统测试用例集及评审记录 |
| 系统测试 | 执行 | 测试执行记录、缺陷清单 |
| 系统测试 | 收尾 | 系统测试报告 |
| 验收测试 | 计划 | 验收标准与验收环境准备清单 |
| 验收测试 | 执行 | 验收测试记录与遗留问题确认单 |
清单完成后先做一次自检：每个产出物是否有人能明确判断“完成”或“未完成”。做不到的条目，要么补充完成标准，要么继续拆解。
用职责矩阵把活动落到角色：字段与填写规则
活动清单回答“做什么”，职责矩阵回答“谁负责、谁参与、谁验收”。矩阵以活动为行，字段建议固定为七项：活动、输入、输出、负责人、协作角色、评审人、完成标志。字段固定后，不同版本的测试计划可以横向比较，也便于评审时逐行核对。
填写规则有三条核心原则。第一，负责人唯一。每行只能填一个负责人，负责该产物的产出和质量。多人共同负责等于无人负责，需要协作的写入协作角色列。第二，评审人独立于负责人。评审人不能与负责人为同一人，否则评审失去约束作用；评审人应具备判断该产物是否合格的专业能力。第三，完成标志可核验。写成“用例覆盖全部需求项并通过评审”，而不是“用例编写完成”。
常见角色的承担方式如下，具体到团队时按实际能力调整：
- 测试经理：负责测试范围与策略、进度与资源安排、风险评估、测试报告汇总；评审人通常由质量负责人或项目负责人担任。
- 测试工程师：负责测试用例设计、测试数据准备、执行记录、缺陷提交与回归验证；评审人通常为测试经理或资深测试人员。
- 开发人员：负责单元测试用例与执行、提测说明、缺陷修复与修复说明；评审人通常为开发负责人或结对评审人。
- 产品人员：负责需求验收标准、验收场景确认、验收结果确认；评审人通常为业务负责人。
- 运维人员：负责测试环境部署、环境可用性确认、上线前配置核查；评审人通常为技术负责人。
填写时有几类歧义需要提前约定处理规则。一是“配合”写法含糊，协作角色列要写清配合的具体动作，如“提供接口文档”“准备测试账号”。二是跨层级活动归属不清，如集成测试用例由开发还是测试编写，按团队惯例在矩阵中明确一次，后续版本沿用。三是评审人空缺，说明该产物缺少质量把关环节，需要在计划评审前补齐。四是完成标志写成主观描述，统一改为可检查的条件，如“缺陷修复率100%且无遗留严重缺陷”。
角色与交付物对照：谁在什么时点交出什么
职责矩阵按活动组织，评审时还需要按角色和时间查看，确认每个角色在各阶段都有明确产出、交接点没有遗漏。角色—交付物—时点对照表承担这个作用。
| 角色 | 阶段 | 交付物 | 提交时点 | 接收方 |
|---|---|---|---|---|
| 测试经理 | 计划 | 测试计划与职责矩阵 | 版本启动后3个工作日内 | 项目负责人、各角色代表 |
| 产品人员 | 计划 | 验收标准与验收场景 | 测试计划评审前 | 测试经理、测试工程师 |
| 开发人员 | 设计 | 提测说明与接口文档 | 提测前2个工作日 | 测试工程师 |
| 测试工程师 | 设计 | 测试用例集与评审记录 | 提测前1个工作日 | 测试经理 |
| 运维人员 | 执行 | 测试环境可用确认 | 执行开始前 | 测试工程师 |
| 测试工程师 | 执行 | 执行记录与缺陷清单 | 每日更新 | 开发人员、测试经理 |
| 测试经理 | 收尾 | 测试报告与遗留问题清单 | 测试结束后2个工作日内 | 项目负责人、产品人员 |
跨角色交接点需要明确确认方式。提测是典型交接点：开发提交提测说明，测试工程师检查准入条件后确认接收，未达条件则退回并记录原因。验收是另一个交接点：测试经理提交测试报告，产品人员确认验收结论并签字或在线确认。确认方式写进对照表，避免口头交接。
对照表填完后检查两类问题。职责重叠表现为同一交付物出现两个负责人，处理办法是保留一个负责人，另一个改为协作角色。职责空缺表现为某阶段没有对应交付物，处理办法是补充活动或明确该阶段不适用并写明理由。
示例：一个版本测试计划的职责分工填写
以下示例为演示情景，团队与项目信息为虚构，用于说明填写过程。
背景：某业务系统发布V2.3版本，包含订单模块改造和两个新增报表。测试范围覆盖系统测试与验收测试，单元测试由开发团队自行组织。测试周期为四周。
第一步，列活动清单。按层级与阶段交叉，得到系统测试的计划、设计、执行、收尾活动，以及验收测试的计划、执行活动，共约12项。以其中三项为例：系统测试用例设计、系统测试执行、验收测试执行。
第二步，填写职责矩阵。系统测试用例设计一行：输入为需求说明与验收标准，输出为系统测试用例集，负责人为测试工程师甲，协作角色为产品人员（确认业务规则）和开发人员（确认接口行为），评审人为测试经理，完成标志为用例覆盖全部需求项且评审问题关闭。系统测试执行一行：输入为用例集与可用测试环境，输出为执行记录与缺陷清单，负责人为测试工程师甲，协作角色为运维人员（环境保障）和开发人员（缺陷修复），评审人为测试经理，完成标志为计划用例执行率100%、严重缺陷全部关闭。验收测试执行一行：输入为验收标准与验收环境，输出为验收记录与结论，负责人为产品人员，协作角色为测试工程师（提供执行支持），评审人为业务负责人，完成标志为验收场景全部通过或遗留问题经业务负责人确认。
第三步，整理交付物时点。测试计划与职责矩阵在版本启动后3个工作日内提交项目负责人；验收标准在计划评审前由产品人员提供；用例集在提测前1个工作日提交评审；执行记录每日更新；测试报告在测试结束后2个工作日内提交。
这个示例体现的取舍是：单元测试未纳入本计划，因为由开发团队按既有流程组织，只在提测说明中体现结果；验收测试负责人放在产品侧，测试团队提供执行支持，符合验收由业务确认的性质。迁移到其他团队时，活动清单的层级划分和矩阵字段可以沿用，角色承担方式按团队实际能力调整。
分工落地与完成检查
职责矩阵写完不等于分工落地。需要在计划评审、执行跟踪和阶段复盘三个环节设置检查动作。
计划评审时，逐行检查职责矩阵：每行是否有且仅有一个负责人；评审人是否与负责人不同；完成标志是否可核验；协作角色是否写清具体动作；交付物时点是否与项目里程碑对齐。评审发现的问题当场记录并指定修改人，修改完成后再次确认。评审通过后，矩阵作为测试计划的组成部分冻结，变更走变更记录。
执行阶段跟踪分工执行情况，可以用三个观察点：交付物是否按对照表时点提交，延迟时是否有人主动说明；交接点是否有确认记录，如提测接收确认、验收结论确认；缺陷流转中修复责任人和验证责任人是否清晰。跟踪频率与版本节奏匹配，短周期版本每日同步一次即可。
分工失效的典型信号包括：同一交付物多人修改但无人对质量负责；评审记录缺失或评审人从未提出意见；交接靠口头约定，出问题后互相推诿；某角色长期没有交付物输出。出现这些信号时，回到矩阵核对对应行，调整负责人或补充完成标志，并在团队内同步变更。
阶段复盘时使用以下检查清单逐项确认：
- 活动清单中的每项活动都有对应交付物，且交付物已归档。
- 职责矩阵每行负责人唯一，评审人独立，完成标志可核验。
- 角色—交付物—时点对照表中的交付物均按时提交，延迟项有原因记录。
- 提测、验收等交接点均有确认记录。
- 执行期间发生的分工调整已更新到矩阵并通知相关角色。
- 遗留问题清单中的每项都有明确责任人和处理时点。
在ONES中，测试计划活动可以建为工作项并指定负责人和评审人，职责矩阵与交付物对照表以文档形式与计划关联，交付物的提交和评审状态随工作项流转更新，评审记录和变更留存在同一处，便于计划评审和复盘时直接核对。
常见问题
团队规模较小、角色由一人兼任时，负责人唯一和评审人独立怎么处理？
小团队里测试经理和测试工程师常由同一人担任，此时负责人唯一原则仍要保留，但评审人需要从团队外找。可行做法是由项目负责人、质量负责人或业务负责人承担评审，重点评审测试范围、完成标志和风险判断。若确实找不到独立评审人，至少在矩阵中标注该产物的评审方式，例如由需求方书面确认验收标准，避免评审环节完全空缺。
测试计划执行中途需求变更，职责矩阵需要整体重写吗？
不需要整体重写，按变更影响范围局部调整即可。先判断变更影响哪些活动和交付物，只修改对应行的输入、输出、负责人或完成标志，并在矩阵中保留变更记录和调整日期。涉及新增活动的，补充到活动清单并指定负责人；涉及角色交接变化的，同步更新角色—交付物—时点对照表，并通知相关角色。变更后由原评审人确认一次，避免矩阵与实际情况脱节。
开发和测试对某个交付物的归属有争议，比如集成测试用例由谁编写，怎么定？
这类争议按团队既有能力和流程惯例定一次，写进职责矩阵后后续版本沿用。判断依据可以看三点：谁更了解被测模块的内部行为，谁具备编写和维护用例的时间，谁对用例质量承担评审责任。无论归属哪一方，矩阵中都要写清负责人、协作角色和评审人，避免出现双方都参与但无人对质量负责的情况。约定变更时在团队内同步，并更新矩阵。
职责矩阵和角色—交付物—时点对照表内容有重叠，是否只保留一份？
两份表视角不同，建议都保留。职责矩阵以活动为行，回答每项活动谁负责、谁评审、怎样算完成；对照表以角色和阶段为行，回答每个角色在什么时点交出什么、交给谁。评审时先用矩阵逐行核对责任，再用对照表检查时点和交接是否有遗漏。两份表共用同一套活动清单，维护时同步修改，避免出现两份内容不一致。
分工检查发现某角色长期没有交付物输出，应该怎么调整？
先确认该角色是否真的没有承担活动，还是承担了活动但交付物没有记录。若矩阵中该角色只出现在协作角色列，说明其职责偏支持性质，可以补充具体的配合动作和完成标志；若矩阵中该角色本应是某些活动的负责人，则检查活动是否被遗漏或负责人被错误填写。调整时明确新的负责人和完成标志，更新矩阵并通知相关角色，在下次复盘中确认调整是否生效。
