测试计划职责分工要解决的问题，是把测试目标、范围、风险、策略、资源和进度拆成一件件可交付的工作，并写清每项工作由谁负责、谁配合、需要什么输入、产出什么结果、怎样算完成。本文给出一张可直接填写的职责矩阵、四个阶段的负责人安排、角色与评审节点清单，并用一个版本迭代示例说明如何填写，最后提供落地检查项。
要点总览（TL;DR）
- 职责分工的起点是一张矩阵：纵向列工作项，横向写负责人、协作人、输入、输出和完成标志，负责人按角色填写。
- 测试计划按计划、设计、执行、收尾四个阶段推进，分别由测试负责人、测试分析师、测试执行人、测试负责人牵头，各阶段有明确交付物。
- 测试计划评审、用例评审、测试报告确认三个节点要固定发起人、参与人和通过条件，缺陷与风险升级责任单独写明。
- 分工是否落地，用负责人唯一、输出可验证、评审有记录、人员可交接、风险有跟踪人、收尾有确认六项检查判断。
测试计划职责分工先定什么：一张职责矩阵的字段
职责分工的起点是一张矩阵：纵向列出测试计划涉及的工作项，横向写清每项工作的责任关系。矩阵填完，分工是否清楚基本就能看出来——哪一格空着，哪项工作就没人真正负责。
工作项按测试计划的实际内容划分，通常包括以下几类：
- 目标与范围：确定本轮测试要验证什么、不验证什么，范围边界写进测试计划。
- 风险识别：列出影响质量与进度的风险，给出应对措施和触发条件。
- 测试策略：确定测试类型组合（功能、回归、接口、性能等）、测试深度和准入准出标准。
- 用例设计：编写测试用例与测试数据，组织用例评审。
- 环境准备：准备测试环境、测试账号、依赖系统与基础数据。
- 执行与缺陷跟踪：按计划执行用例，记录结果，提交并跟踪缺陷。
- 测试报告：汇总执行结果、缺陷分布、遗留风险和结论。
每个工作项至少写清五个字段：
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 负责人 | 对该工作项结果负责的唯一角色 | 测试分析师 |
| 协作人 | 提供输入或参与评审的角色 | 开发负责人、产品负责人 |
| 输入 | 开展工作所依据的材料或前置条件 | 需求文档、验收标准、接口说明 |
| 输出 | 可交付、可检查的产物 | 测试用例集、用例评审记录 |
| 完成标志 | 判断该工作项结束的客观条件 | 用例评审通过，遗留问题已记录处理人 |
负责人一栏按角色填写，例如“测试负责人”“开发负责人”，不直接写人名。角色与人员的对应关系放在测试计划的资源部分单独维护。这样人员调整时只需更新对应关系，矩阵本身不用重写，职责也不会因为某人离岗而出现空白。
按阶段拆分：计划、设计、执行、收尾各由谁负责
职责矩阵按工作项横向铺开，阶段视角则回答另一个问题：测试计划从启动到关闭，每个阶段由谁牵头、交付什么。两种视角配合使用，矩阵保证不漏项，阶段保证节奏清楚。
| 阶段 | 牵头角色 | 主要动作 | 关键交付物 |
|---|---|---|---|
| 计划 | 测试负责人 | 组织范围与验收标准确认，识别风险，确定策略、资源与进度 | 测试计划文档、风险清单 |
| 设计 | 测试分析师 | 设计用例与测试数据，开发确认可测性，组织用例评审 | 测试用例集、评审记录 |
| 执行 | 测试执行人 | 执行用例、记录结果、提交缺陷；开发修复；测试负责人跟踪风险 | 执行记录、缺陷单、风险跟踪表 |
| 收尾 | 测试负责人 | 汇总结果，说明遗留风险，完成报告确认与移交 | 测试报告、遗留问题清单 |
计划阶段由测试负责人牵头，产品/需求负责人确认业务范围与验收标准，开发负责人确认技术可行性与提测时间。范围确认的产物是写进测试计划的测试范围说明，完成标志是范围与验收标准经双方确认、无未决争议项。
设计阶段由测试分析师主导。测试分析师依据需求与验收标准设计用例和测试数据，开发负责人从实现角度确认可测性，例如接口是否可调用、日志是否足以定位问题。完成标志是用例评审通过，评审意见已闭环。
执行阶段由测试执行人按计划执行并记录结果，缺陷提交后由开发负责人安排修复，测试负责人跟踪缺陷收敛趋势和风险状态。当缺陷修复速度或环境稳定性影响准出判断时，由测试负责人发起风险升级，而不是等收尾阶段再说明。
收尾阶段由测试负责人汇总执行结果与缺陷数据，形成测试报告，列出遗留问题及其影响范围、建议处理方式。报告确认通常由测试负责人、开发负责人和产品/需求负责人共同完成，确认后测试计划关闭，遗留问题移交给后续版本或运维环节跟踪。
角色及交付物：谁签字、谁评审、谁跟踪
阶段划分解决先后顺序，角色清单解决边界问题。同一件事出现两个负责人，或者评审时找不到签字人，往往是因为角色交付物没有写清。下表按角色列出交付物与参与的评审节点。
| 角色 | 主要交付物 | 参与的评审与签字 |
|---|---|---|
| 测试负责人 | 测试计划、风险清单、测试报告 | 组织测试计划评审；签署测试报告 |
| 测试分析师 | 测试用例集、测试数据方案 | 发起用例评审；根据评审意见修订用例 |
| 测试执行人 | 执行记录、缺陷单 | 参与用例评审；确认缺陷复现信息完整 |
| 开发负责人 | 可测性确认意见、缺陷修复结果 | 参与测试计划与用例评审；确认缺陷修复 |
| 产品/需求负责人 | 验收标准确认、范围确认意见 | 确认测试范围与验收标准；确认测试报告结论 |
| 环境管理员 | 测试环境、账号与基础数据 | 确认环境就绪状态，参与环境问题处理 |
| 项目经理 | 跨团队依赖协调结论、发布节奏安排 | 参与测试计划评审；协调资源与时间冲突 |
三个评审节点需要固定下来：测试计划评审在计划阶段结束前完成，确认范围、策略、资源和进度；用例评审在设计阶段完成，确认覆盖度与可执行性；测试报告确认在收尾阶段完成，确认结论与遗留风险处理方式。每个节点写明发起人、参与人和通过条件，避免评审变成通知。
缺陷跟踪的责任划分要单独说明：测试执行人负责提交信息完整的缺陷并验证修复结果，开发负责人负责安排修复并给出修复说明，测试负责人对缺陷整体收敛情况和阻塞发布的缺陷负责。风险升级的触发条件写进测试计划，例如关键缺陷超过约定时限未修复、环境连续不可用超过约定时长，触发后由测试负责人向项目经理和产品/需求负责人同步。
这些工作项和评审记录需要有承载的地方。在ONES中，测试计划、测试用例、缺陷与评审可以放在同一个项目空间里：测试计划作为工作项记录范围与进度，用例与需求关联，缺陷从执行结果直接提交并流转到修复，评审结论留在对应工作项上。职责矩阵中的负责人和完成标志，对应到系统中的责任人与状态，检查分工执行情况时可以直接查看记录，不必依赖口头确认。
一个示例：中型版本测试计划的职责分工表
以下示例为演示情景：一个中型版本迭代，包含新功能测试与既有功能回归测试，涉及前端、后端和一条外部依赖接口。示例只展示矩阵如何填写，实际项目需按自身规模调整角色和完成标志。
| 工作项 | 负责人 | 协作人 | 输入 | 输出 | 完成标志 |
|---|---|---|---|---|---|
| 测试范围与验收标准 | 测试负责人 | 产品/需求负责人、开发负责人 | 需求文档、版本目标 | 测试范围说明、验收标准清单 | 范围与标准经产品与开发确认 |
| 风险识别 | 测试负责人 | 开发负责人、项目经理 | 需求变更记录、历史缺陷数据 | 风险清单及应对措施 | 风险清单纳入测试计划评审 |
| 测试策略 | 测试负责人 | 测试分析师、开发负责人 | 测试范围、质量目标 | 测试类型组合、准入准出标准 | 策略在测试计划评审中通过 |
| 用例与测试数据设计 | 测试分析师 | 测试执行人、开发负责人 | 验收标准、接口说明 | 测试用例集、测试数据 | 用例评审通过，意见闭环 |
| 环境准备 | 环境管理员 | 开发负责人、项目经理 | 部署说明、外部接口联调安排 | 可用测试环境、账号与基础数据 | 环境冒烟通过，外部依赖可连通 |
| 执行与缺陷跟踪 | 测试执行人 | 开发负责人、测试负责人 | 测试用例、可用环境 | 执行记录、缺陷单 | 计划内用例执行完毕，缺陷状态更新 |
| 测试报告 | 测试负责人 | 产品/需求负责人、开发负责人 | 执行记录、缺陷数据 | 测试报告、遗留问题清单 | 报告经三方确认，遗留问题有处理人 |
示例中的跨团队依赖主要出现在两处。一是外部依赖接口的联调时间，由项目经理在计划阶段与对方团队确认，环境管理员据此安排环境连通性验证，完成标志写成“外部依赖可连通”，而不是笼统的“环境准备好”。二是回归测试所需的历史数据，由测试分析师在用例设计阶段一并准备，避免执行阶段临时补数据拖慢进度。
环境准备这一行还体现了协作关系的写法：环境管理员是负责人，开发负责人提供部署支持，项目经理协调资源。三方各司其职，环境出问题时先找负责人，再由负责人判断是否需要开发介入，责任链清楚。
分工落地与完成检查
职责矩阵写完不等于分工落地。以下检查项用于测试计划评审前和阶段结束时逐条核对，判断分工是否真正被执行。
- 每个工作项都有唯一负责人。检查矩阵中负责人一栏无空缺、无两人并列；协作人可以多个，负责人只能一个。
- 输入与输出可验证。检查每项输出是否是具体产物，例如“用例集”“风险清单”，完成标志是否能用客观条件判断，例如“评审通过”“冒烟通过”。
- 评审与签字按节点完成。检查测试计划评审、用例评审、测试报告确认三个节点是否都有记录，参与人是否覆盖对应角色，未通过的意见是否已闭环。
- 人员变动时可交接。检查负责人是否按角色填写，角色与人员的对应关系是否单独维护；出现人员调整时，矩阵无需重写即可继续使用。
- 缺陷与风险有明确跟踪人。检查缺陷收敛情况是否有人定期查看，风险升级触发条件是否写入测试计划，触发后是否有响应记录。
- 收尾有确认。检查测试报告是否经测试、开发、产品三方确认，遗留问题是否写明影响范围和处理人。
检查中发现的问题按性质处理：负责人空缺属于分工设计问题，回到矩阵补齐；完成标志模糊属于定义问题，改成可判断的条件；评审记录缺失属于执行问题，补做评审并留下记录。三类问题分开处理，比笼统地“加强沟通”更容易改到位。
当测试计划、用例、缺陷和评审记录集中在一个协作平台中时，上述检查可以直接对照系统中的责任人与状态完成。ONES可将测试计划、用例、缺陷与评审关联在同一项目下，负责人、完成状态和评审结论都有记录可查，人员变动时调整角色对应关系即可延续原有分工。
常见问题
测试负责人和项目经理在测试计划分工中如何划界？
测试负责人对测试计划本身负责，包括范围、策略、风险清单、用例评审组织和测试报告结论；项目经理负责跨团队依赖协调、资源与时间冲突处理、发布节奏安排。两者的交界在资源与进度冲突：测试负责人提出风险和资源需求，项目经理在项目层面协调解决。分工表里把“跨团队依赖协调结论”写成项目经理的交付物，把“风险清单及应对措施”写成测试负责人的交付物，边界就清楚了。
团队规模较小、一人兼多个角色时，职责矩阵还要按角色填吗？
仍建议按角色填写，在资源部分注明角色与人员的对应关系，例如测试负责人与测试分析师由同一人担任。这样做的价值在于：角色定义的是职责内容，人员对应的是当前安排。团队扩编或人员调整时，只需更新对应关系，矩阵中的工作项、输入输出和完成标志可以继续沿用。需要注意的是，一人兼多角色时，评审环节要避免自己评审自己的产出，可以请开发负责人或产品负责人承担对应评审。
测试计划评审没有通过，后续阶段怎么安排？
评审未通过通常集中在范围不清、验收标准缺失、资源不足或进度不可行几类问题。处理方式是先记录未通过意见和责任人，再按问题性质分流：范围与验收标准问题回到产品/需求负责人补充确认；资源与进度问题由项目经理协调；策略问题由测试负责人修订。修订完成后重新评审，通过条件与首次评审一致。在评审通过前，设计阶段可以先行开展不依赖争议范围的用例设计，但执行阶段的准入应以计划评审通过为前提。
缺陷修复责任和测试验证责任如何衔接？
缺陷提交后，开发负责人负责安排修复并给出修复说明，测试执行人负责验证修复结果并关闭或退回缺陷。衔接的关键是缺陷单信息完整：复现步骤、环境、预期与实际结果、影响范围写清楚，开发才能判断修复方式；修复说明写清改动范围和影响面，测试才能确定回归范围。测试负责人对缺陷整体收敛趋势负责，当关键缺陷超过约定时限未修复时，按测试计划中写明的触发条件发起风险升级。
遗留问题在测试报告确认后由谁跟踪？
测试报告确认时，遗留问题清单要写明每项问题的影响范围、建议处理方式和接收方。常见做法是：影响本版本发布判断的问题由产品/需求负责人决定是否带风险发布；不影响发布但需后续处理的问题移交给后续版本负责人或运维环节跟踪，并在清单中写明接收人。测试负责人完成移交后，测试计划即可关闭，遗留问题的后续状态由接收方在其工作项中维护。
