测试计划里按层级分配测试类型和资源，核心是先把单元、集成、系统、验收四层的目标和准出定清楚，再把功能、性能、兼容、安全、接口、回归、探索等类型按风险高低挂到具体层级，最后依据“层级×类型”组合表估算人力、环境、数据和时间，用风险加权而非平均分摊的方式排资源。本文面向测试策略与计划编制阶段，交付层级定义表、类型组合表、资源分配表和完成检查清单；计划与执行跟踪可以在ONES中承载。
要点总览（TL;DR）
- 先定单元、集成、系统、验收四层的目标、风险对象与准入准出，形成层级定义表，再讨论测试类型放在哪一层。
- 按风险高低和缺陷发现成本把功能、接口、性能、兼容、安全、回归、探索等类型挂到具体层级，形成层级×类型组合表，避免每层平铺所有类型。
- 资源估算逐格进行，覆盖用例设计、执行、缺陷复现与验证的工时，并把环境与数据准备时间单独排入计划。
- 资源按风险加权分配，高风险格配置更有经验的执行人和更多轮次，同时预留回归与探索性测试的弹性余量。
- 计划执行前用检查清单核对风险覆盖、责任人、数字口径、追溯关系与变更机制，确保组合表与资源表可落地。
先定层级与目标：测试计划的第一张骨架表
测试计划的第一张表应当固定测试层级，而不是先列测试类型。层级决定了每类测试在什么阶段、由谁执行、以什么作为完成标志。层级划分的常见口径是单元测试、集成测试、系统测试、验收测试，产品形态不同可以裁剪：纯前端应用可能弱化单元层、强化集成与端到端；嵌入式或平台类产品则往往需要保留较完整的四层。裁剪要在计划中写明理由，避免后续评审时对“为什么没有这一层”反复解释。
每一层需要回答的核心问题不同，覆盖的风险对象也不同。单元层回答“单个函数或模块的逻辑是否正确”，风险对象是代码级缺陷与边界条件；集成层回答“模块之间、服务之间的契约与数据流是否成立”，风险对象是接口不一致、依赖失败、事务与状态问题；系统层回答“完整产品在目标环境下是否满足需求与非功能指标”，风险对象是端到端业务流程、性能、兼容与安全；验收层回答“业务方能否接受并投入使用”，风险对象是需求理解偏差与业务规则遗漏。
准入与准出要写成可核验的条件。准入描述“进入这一层之前必须满足什么”，例如单元层要求代码合入并通过静态检查，集成层要求接口契约冻结、依赖环境可用，系统层要求主流程可运行、测试数据就绪，验收层要求系统测试准出、缺陷收敛到约定阈值。准出描述“这一层什么情况下可以结束”，例如用例执行率达到约定比例、遗留缺陷按严重级别有明确处理结论、关键风险项有覆盖证据。条件要带数字口径，例如“阻塞级与严重级缺陷清零，一般级缺陷遗留不超过约定数量且有修复计划”。
层级还要与需求、设计文档建立追溯关系。每个层级应说明它承接哪些需求条目或设计条目：单元层追溯到详细设计与接口定义，集成层追溯到接口契约与集成方案，系统层追溯到需求规格中的功能与非功能条目，验收层追溯到业务验收标准。追溯关系写进计划，后续需求变更时才能判断哪一层的类型组合和资源需要跟着调整。
| 层级 | 回答的问题 | 风险对象 | 准入 | 准出 | 责任人 |
|---|---|---|---|---|---|
| 单元 | 模块逻辑与边界是否正确 | 代码缺陷、异常分支 | 代码合入、静态检查通过 | 关键模块用例通过、覆盖率达标 | 开发负责人 |
| 集成 | 模块与服务间契约是否成立 | 接口不一致、依赖失败 | 接口契约冻结、依赖环境可用 | 接口用例通过、集成缺陷收敛 | 开发与测试共同 |
| 系统 | 端到端业务与非功能指标是否满足 | 业务流程、性能、兼容、安全 | 主流程可运行、数据就绪 | 用例执行达标、严重缺陷清零 | 测试负责人 |
| 验收 | 业务方能否接受并上线 | 需求偏差、业务规则遗漏 | 系统测试准出、验收环境就绪 | 验收场景通过、业务方签字确认 | 业务方与测试负责人 |
把测试类型挂到层级上：类型组合的取舍规则
层级定好后，再决定每类测试放在哪一层、投多深。常见类型的天然适配层级有规律：单元测试集中在单元层，以自动化为主；接口测试集中在集成层，验证契约、参数与异常返回；功能测试主要落在系统层，按业务流程组织；性能、兼容、安全测试通常集中在系统层，因为它们需要接近真实的完整环境和数据；回归测试跨层存在，单元与集成层用自动化回归，系统层用核心场景回归；探索性测试多放在系统层与验收前，用于补充脚本覆盖不到的风险。
判断投入深度时，先看风险高低。风险来自需求变更频率、业务关键程度、历史缺陷密度、技术复杂度与外部依赖数量。高风险模块在对应层级加深覆盖，例如支付与权限相关的接口在集成层做正反用例与异常链路，在系统层做端到端资金流与越权场景；低风险模块在单元与集成层保持基础覆盖即可，把系统层资源让给关键路径。风险判断要落到具体对象，写成“某模块因本期改动大、涉及三方依赖，集成层加深接口异常覆盖”，而不是笼统地写“重要模块加强测试”。
取舍还要考虑缺陷发现成本随层级后移而上升。同一个逻辑错误在单元层发现只需改代码并重跑用例，到系统层才发现则要复现环境、定位链路、回归关联功能，成本明显更高。因此能在低层级用低成本手段覆盖的类型，尽量前移：参数校验、边界条件、异常分支放在单元与集成层；跨系统业务流程、真实数据量下的性能表现放在系统层。前移的前提是低层级具备可执行的测试手段，例如可自动化的用例、稳定的桩与模拟服务。
哪些类型集中在一层、哪些需要跨层重复，也要在组合表中写明。性能与安全通常集中在系统层做一次完整评估，单元层只做必要的静态检查或局部校验；功能验证则在集成层做接口级功能、在系统层做业务级功能，属于有意的跨层重复，因为两层验证的对象不同。回归测试跨层分布，但每层的回归范围要收窄到受影响模块与核心链路，避免全量重复执行。
| 测试类型 | 主要层级 | 目的 | 深度建议 | 是否必做 |
|---|---|---|---|---|
| 单元测试 | 单元 | 验证模块逻辑与边界 | 核心模块加深，其余基础覆盖 | 必做 |
| 接口测试 | 集成 | 验证契约、参数与异常返回 | 高风险接口正反用例齐全 | 必做 |
| 功能测试 | 系统 | 验证端到端业务流程 | 按业务关键路径组织 | 必做 |
| 性能测试 | 系统 | 验证响应时间与容量 | 针对关键链路与峰值场景 | 按风险决定 |
| 兼容测试 | 系统 | 验证目标环境组合可用 | 覆盖约定支持范围 | 按发布范围决定 |
| 安全测试 | 系统 | 验证权限与数据保护 | 聚焦越权、敏感数据、输入校验 | 按风险决定 |
| 回归测试 | 跨层 | 确认改动未破坏既有功能 | 按影响范围收窄 | 必做 |
| 探索性测试 | 系统、验收前 | 补充脚本未覆盖的风险 | 按时间盒组织 | 建议保留 |
按组合表估算资源：人力、环境、数据与时间
组合表确定后，资源估算逐格进行，而不是按项目总量拍一个数字。每一格要估算用例数量、执行轮次与单轮工时，再折算人力。用例数量按覆盖对象估算，例如接口测试按接口数与每接口正反用例数估算，功能测试按业务流程数与分支场景数估算；执行轮次按计划内的版本节奏确定，回归轮次通常多于首轮功能验证；工时要把用例设计、执行、缺陷复现与验证都计入，只算执行时间会低估实际投入。
环境与测试数据是容易被漏掉的资源项。环境要列出每层需要的环境类型、数量与占用时间：单元层依赖开发本地与持续集成环境，集成层需要联调环境与依赖服务桩，系统层需要接近生产的测试环境与性能压测环境，验收层需要业务方可访问的验收环境。数据准备要写明数据来源、构造方式与脱敏要求，尤其是性能测试的数据量级和验收测试的业务样本。环境与数据的准备时间要单独排入计划，并与开发提测时间对齐，否则会出现“人到位、环境没到位”的空转。
资源分配采用风险加权，而非平均分摊。平均分配把人力按层级或模块均分，看似公平，实际会让高风险区域覆盖不足、低风险区域过度投入。风险加权的做法是：先给每个组合格标注风险等级，高风险格配置更有经验的执行人和更多轮次，中风险格按标准配置，低风险格采用自动化或抽样执行。风险加权适用于需求变更集中、外部依赖多、历史缺陷密度高的版本；需求稳定、改动范围小的维护版本可以适当简化，但仍要保留关键路径的覆盖。
计划中要留出回归与探索性测试的弹性余量。余量通常按总测试工时的固定比例预留，用于应对提测延迟、缺陷修复后的重复验证和计划外的风险探查。余量不是闲置时间，要在计划中写明使用规则：优先用于高风险模块的补充验证和回归，剩余部分用于探索性测试的时间盒。余量被提前消耗时，要在计划评审中说明原因并调整后续轮次。
| 层级 | 类型 | 人力 | 环境 | 数据 | 时间 | 余量 |
|---|---|---|---|---|---|---|
| 单元 | 单元测试 | 开发按模块认领 | 本地与持续集成 | 构造数据与桩数据 | 随开发节奏 | 不单列 |
| 集成 | 接口测试 | 测试主导、开发支持 | 联调环境与依赖桩 | 接口参数集与异常数据 | 提测后首轮 | 按接口数预留 |
| 系统 | 功能、性能、兼容、安全 | 测试按风险加权配置 | 测试环境与压测环境 | 业务样本与量级数据 | 按版本节奏排轮次 | 总工时固定比例 |
| 验收 | 验收与探索性 | 业务方参与、测试支持 | 验收环境 | 真实业务样本 | 系统准出后 | 按验收场景预留 |
角色分工与交付物：谁在计划里认领哪一段
测试负责人对层级定义表、类型组合表和资源分配表负编制与维护责任。具体动作包括：组织层级与准出的评审、汇总各层风险判断、把类型挂到层级并标注必做与选做、按组合表估算资源并提交评审。交付物是三张表加一份评审记录，评审记录要写明争议点和结论，例如某类型本期后移的理由。
开发在单元层与集成层承担类型执行责任。单元测试由开发编写与执行，交付物是用例与执行结果；集成层的接口测试可以由测试主导设计、开发配合提供契约与桩服务，交付物是接口用例集与联调结果。开发还要对提测质量负责，提测前完成单元层准出，避免把本可在低层级发现的问题推到系统层。
业务方在验收层参与场景确认与结果签字。参与方式包括：评审验收场景是否覆盖关键业务规则、提供真实业务样本数据、按约定时间执行验收并给出通过或退回的结论。交付物是验收场景清单与验收结论记录。业务方不参与单元与集成层的技术判断，但可以对系统层暴露的业务规则问题提出意见。
评审与变更时的角色分工要提前约定。计划评审由测试负责人组织，开发负责人确认单元与集成层的可执行性，业务方确认验收标准；需求或排期变更时，测试负责人更新组合表与资源表，开发负责人确认新增改动涉及的层级，业务方确认验收范围是否调整。变更记录与计划版本关联，避免执行时使用过期版本。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 测试负责人 | 编制与维护三张表，组织评审与变更 | 层级定义表、组合表、资源表、评审记录 |
| 开发 | 执行单元测试，支持集成层契约与桩 | 单元用例与结果、接口契约、联调结果 |
| 业务方 | 确认验收场景，提供样本，执行验收 | 验收场景清单、验收结论 |
一个示例：中型版本迭代的层级类型与资源安排
以下为演示情景，用于说明从层级表到组合表再到资源表的落地过程，不代表真实客户案例。某中型版本迭代涉及订单模块改造、新增一个三方支付渠道、两个内部服务接口调整，计划周期四周，测试人力三人，其中一人具备性能测试经验。
风险判断：订单改造影响主交易链路，历史缺陷密度较高，定为高风险；三方支付渠道属于外部依赖，回调与对账存在不确定性，定为高风险；两个内部接口调整影响面有限，定为中风险；其余页面文案与配置项调整为低风险。据此，集成层对支付回调与订单状态接口加深异常与幂等覆盖，系统层对下单到支付完成的端到端链路做功能与性能验证，兼容层只覆盖约定的主流浏览器与移动端版本。
组合结果：单元层由开发对订单状态机与支付适配层补充用例；集成层由测试设计接口用例，覆盖正常、异常、超时与重复回调；系统层安排功能测试覆盖主交易链路与退款流程，性能测试针对下单峰值场景执行一轮，安全测试聚焦支付回调验签与越权查询；验收层由业务方按关键业务规则执行验收场景，并保留探索性测试时间盒。回归测试在集成层用自动化接口回归，在系统层收窄到交易与支付相关场景。
资源安排：三名测试人员中，两人投入系统层功能与回归，一人投入集成层接口与性能测试，安全测试由具备经验的测试人员兼任并安排外部支持评审；环境方面申请一套测试环境与一套压测环境，压测环境在性能轮次前完成数据准备；数据方面准备订单样本、支付回调样本与峰值量级数据；时间上集成层在提测后第一周完成，系统层功能与性能在第二周至第三周执行，验收在第四周前半段完成，预留约总工时一成的余量用于回归与探索。
放弃或后移的类型：本期不做全量兼容矩阵测试，只覆盖约定支持范围；安全测试不做完整渗透评估，聚焦支付相关的高风险项；低风险配置项的单元覆盖保持基础水平，不额外增加轮次。这些取舍在评审记录中写明理由与后续补偿方式，例如在下个版本安排完整兼容回归。
完成检查：计划可执行前的核对项
计划进入执行前，用一份清单逐项核对，确认类型组合与资源安排能够落地。核对以“能否执行、能否验证”为标准，不以文档篇幅为标准。
- 层级与类型组合是否覆盖已识别的全部风险：每个高风险对象都能在组合表中找到对应的层级与类型，且标注了覆盖深度。
- 每一格是否有责任人与完成标志：责任人到具体角色或人员，完成标志是可核验的结果，例如用例通过、报告出具、签字确认。
- 资源估算是否包含环境、数据与余量：环境与数据准备时间单独列出并与提测时间对齐，余量有明确比例与使用规则。
- 准入准出条件是否带数字口径：执行率、缺陷收敛标准、遗留缺陷处理结论均可核验。
- 追溯关系是否建立：各层能对应到需求或设计条目，需求变更时能定位受影响的组合格。
- 变更机制是否明确：组合表与资源表的更新由谁发起、谁确认、如何与计划版本关联。
- 评审记录是否完整：取舍理由、后移类型与补偿安排有记录，参与方已确认。
这些内容需要在计划文档与执行跟踪中保持同步。ONES TestCase 支持测试计划的规划和执行，可多维度概览全部测试计划并将用例分配执行人；用例可与需求、任务关联，测试计划可与迭代关联；未通过的用例可快速创建缺陷任务并在测试与研发团队间流转；测试报告与缺陷分布统计可自动生成，报告模板支持自定义组装。把层级、类型组合与资源安排落到计划、用例和缺陷记录中，执行过程中的进度与准出判断就有据可查。具体到层级维度的分类统计与各测试类型的专项管理方式，需结合实际配置确认。
常见问题
测试层级划分可以裁剪吗？裁剪后计划里要补什么？
可以裁剪。层级划分的常见口径是单元、集成、系统、验收四层，产品形态不同可以调整，例如纯前端应用可能弱化单元层、强化集成与端到端验证。裁剪后需要在计划中补三样内容：一是写明裁剪理由，避免评审时反复解释；二是说明被弱化层级原本承担的风险由哪一层接住；三是确认接住风险的层级具备可执行的测试手段，例如稳定的桩服务或可自动化的用例。
低风险模块是否可以不安排系统层测试？
可以降低系统层的投入，但不宜直接取消。低风险模块通常指改动范围小、历史缺陷少、不涉及关键交易链路的部分，处理方式是在单元与集成层保持基础覆盖，系统层只验证它与主流程的衔接点，不再单独安排完整业务场景。如果该模块完全不在任何端到端链路上，可以在评审记录中写明不安排系统层测试的理由，并约定后续版本补偿验证的条件。
计划执行中需求变更，组合表和资源表怎么更新？
由测试负责人发起更新，先判断变更影响哪些需求条目，再沿追溯关系定位受影响的层级与类型格，调整覆盖深度和资源投入。开发负责人确认新增改动涉及的单元与集成层工作，业务方确认验收范围是否变化。更新后的组合表与资源表要和计划版本关联，评审记录写明变更原因与调整结论，避免执行时使用过期版本。
弹性余量留多少合适，被提前用完怎么办？
余量通常按总测试工时的固定比例预留，具体比例结合版本节奏、提测稳定性和历史返工情况确定，没有统一标准。余量要在计划中写明使用规则，优先用于高风险模块的补充验证和回归，剩余部分用于探索性测试的时间盒。如果余量被提前消耗，应在计划评审中说明原因，并调整后续轮次的执行范围或补充人力，而不是直接压缩准出条件。
层级、类型组合和资源安排如何在工具中跟踪？
可以把层级与类型组合落到测试计划与用例组织中，把资源安排对应到执行人和轮次。ONES TestCase 支持测试计划的规划和执行，可多维度概览全部测试计划并将用例分配执行人；用例可与需求、任务关联，测试计划可与迭代关联；未通过的用例可快速创建缺陷任务并在测试与研发团队间流转；测试报告与缺陷分布统计可自动生成，报告模板支持自定义组装。按层级维度的分类统计与各测试类型的专项管理方式，需结合实际配置确认。
