测试策略里的类型组合，实质是回答“在哪个层级、用哪类测试、投入多少”的问题。合理的做法是先按业务目标和历史缺陷列出风险清单，再按单元、集成、系统、验收四个层级分配功能、非功能与静态测试的主次，最后用人力、环境、时间与准入准出条件把组合固定下来。本文按这一顺序给出可直接写入测试计划的步骤、配比表与检查清单，适用于策略与计划编制阶段。
要点总览（TL;DR）
- 类型组合的初稿来自质量目标、风险清单和测试层级三项输入，三者合在一起才能判断某类测试做不做、做多深、放在哪一层。
- 功能测试覆盖业务规则与主流程，非功能测试按风险选择子类并写明触发条件与通过标准，静态测试前置到需求评审、设计评审和代码检查三个固定环节。
- 配比表按单元、集成、系统、验收四个层级给出功能、非功能、静态测试的相对投入强度，调整时保持高风险项至少在一个层级获得功能与非功能双重覆盖。
- 把组合写进计划分四步：输出测试项清单、指定主类型与辅助类型、排定执行顺序与依赖、写入准入准出与暂停恢复规则，每步都有可判定的完成标志。
- 定稿前用检查清单核对高风险项覆盖、非功能触发条件、静态测试责任人与时点、资源匹配和准入准出可判定性。
先定组合依据：质量目标、风险与测试层级
类型组合的初稿来自三份输入：质量目标、风险清单和测试层级划分。三者合在一起，才能判断某类测试该不该做、做多深、放在哪一层做。缺少任何一项，配比就容易变成按经验平均分配。
从业务目标和历史缺陷提炼质量目标与风险清单
质量目标描述系统必须达到的可观察状态，例如“订单提交在促销峰值下成功率不低于99.9%”“支付金额计算零差错”“新版本上线后旧版客户端仍可正常下单”。这些目标来自业务方的验收预期、合同条款、监管要求和上一版本遗留问题。把目标逐条拆开，就能得到对应的风险项：哪些功能一旦出错影响最大，哪些质量属性一旦不达标会阻断上线。
历史缺陷是风险清单的第二来源。按模块、缺陷类型和严重级别统计近几个版本的缺陷分布，能看出问题集中在业务规则理解、接口契约、并发处理还是兼容性上。缺陷集中的区域在下一版本应提高对应类型的投入。风险清单建议至少包含：风险描述、影响范围、发生可能性、可接受程度、对应质量目标五项字段，便于后续排序。
按四个层级划分，明确每层能发现的问题类型
测试层级决定测试类型的落点。单元层面对代码与函数，适合发现逻辑错误、边界处理和单元级静态问题；集成层面对模块间接口与数据流，适合发现契约不一致、序列化错误和集成后的性能瓶颈；系统层面对完整业务链路，适合验证端到端流程、业务规则组合和非功能指标；验收层面对用户视角与业务场景，适合确认需求满足度和上线可接受性。层级划分清楚后，每类测试放在哪一层就有了依据，避免同一问题在多个层级重复验证。
用风险等级决定三类测试的投入优先级
风险等级是排序工具而非装饰。高风险项应同时具备功能验证和非功能验证，并在静态环节提前拦截；中风险项以功能测试为主，非功能测试按触发条件选择性执行；低风险项可只做静态检查和冒烟级功能验证。这样排序的结果是一张按优先级排列的测试项清单，后续配比和资源安排都从这张清单出发。
本节完成标志：形成一份质量目标与风险清单，以及一张“层级—类型”对应初稿，标明每个层级计划覆盖的测试类型和主要风险项。
三类测试在策略中的分工与配比
功能、非功能、静态测试回答的是不同问题，策略中应分别写明各自承担的回答任务，再给出配比。配比的作用是约束投入，防止某一类测试挤占其他类型的资源。
功能测试：覆盖业务规则、主流程与异常分支
功能测试回答“系统行为是否符合业务预期”。策略中应明确覆盖范围包括主流程、业务规则组合、异常分支和边界条件，并说明每个层级的覆盖重点：单元层覆盖规则计算逻辑，集成层覆盖接口传递后的业务结果，系统层覆盖跨模块的完整流程，验收层覆盖用户实际操作路径。功能测试用例应按风险清单排序，高风险流程优先设计、优先执行。
非功能测试：按风险选择子类并写明触发条件
非功能测试回答“系统在特定条件下是否仍然可用”。策略中不必罗列全部子类，而应按风险选择：涉及高并发或数据量增长的模块安排性能测试；涉及用户身份、支付、敏感数据的模块安排安全测试；涉及长时间运行或故障恢复的模块安排可靠性测试；涉及多端、多浏览器、多版本并存的模块安排兼容性测试。每个子类都要写明触发条件，例如“单接口预估峰值QPS超过500时执行负载测试”“新增第三方支付渠道时执行安全测试”，以及通过标准，例如响应时间上限、错误率上限、恢复时间上限。触发条件写清楚，执行时就不需要临时争论做不做。
静态测试：前置到需求评审、设计评审与代码检查
静态测试回答“在运行之前能否发现问题”。策略中应把静态测试安排为三个固定环节：需求评审检查需求完整性、可测试性和验收标准；设计评审检查架构对非功能目标的支撑，例如容量设计、安全边界、故障处理方案；代码检查检查编码规范、常见缺陷模式和单元测试覆盖情况。静态测试的价值在于发现越早修复成本越低，因此策略中要写明每个环节的责任人、检查清单和通过时点，而不是笼统写“加强评审”。
按层级和风险的类型配比表
配比用投入占比或用例数量占比表达均可，关键是说明比例依据。下表给出一个可按项目调整的参考结构，比例依据是“高风险项多类型覆盖、低风险项轻量覆盖”的原则。
| 测试层级 | 功能测试 | 非功能测试 | 静态测试 | 配比依据 |
|---|---|---|---|---|
| 单元 | 高，覆盖规则与边界 | 低，仅关键算法性能验证 | 高，代码检查与单元覆盖 | 缺陷在此层修复成本最低 |
| 集成 | 中高，接口业务结果验证 | 中，接口性能与安全 | 中，接口契约评审 | 接口问题是集成阶段主要风险 |
| 系统 | 高，端到端流程与规则组合 | 高，性能、安全、可靠性、兼容性按风险选择 | 低，以评审结论复核为主 | 非功能指标需在完整环境验证 |
| 验收 | 中，用户场景确认 | 低，以生产指标预演为主 | 低，验收标准评审 | 确认需求满足度，不重复系统测试 |
表中“高、中、低”表示相对投入强度，实际比例应结合团队规模、版本周期和风险清单调整。调整时保持一条规则：任一高风险项至少在一个层级获得功能与非功能双重覆盖，并在静态环节有对应检查。
把类型组合写进测试计划的步骤
组合判断需要落成计划文本才能执行。以下四步给出每步的输入、动作、输出与完成标志，可直接作为计划中“测试类型安排”章节的编写顺序。
步骤一：确认范围与层级，输出测试项清单
输入是需求文档、架构说明和风险清单。动作是逐条确认本版本纳入测试的功能范围，按单元、集成、系统、验收归类，形成测试项清单，每项标注所属层级、关联风险等级和验收标准。输出是测试项清单。完成标志是清单中每个测试项都有层级归属和风险等级，没有未归类的需求条目。
步骤二：为每个测试项指定主类型与辅助类型
输入是测试项清单和类型配比表。动作是为每个测试项指定一个主类型（决定主要验证手段）和若干辅助类型（补充验证），例如“订单结算”以功能测试为主、性能测试与安全测试为辅，“登录鉴权”以安全测试为主、功能测试为辅。输出是带类型标注的测试项清单。完成标志是每个高风险项至少有一个主类型和一个辅助类型，且辅助类型写明了触发条件。
步骤三：排定执行顺序与依赖
输入是带类型标注的测试项清单和版本排期。动作是按依赖关系排序：静态测试前置到需求与设计评审，代码检查随开发提交进行；单元测试随代码完成；集成测试在接口联调后启动；系统测试在集成通过后执行，其中非功能测试安排在功能主流程稳定之后，避免环境反复重建；验收测试在系统测试准入通过后开始。输出是带时间点的执行顺序表。完成标志是每类测试都有开始条件和前置依赖，非功能测试与功能测试的衔接点明确。
步骤四：写入准入准出条件与暂停恢复规则
输入是执行顺序表和风险清单。动作是为每个层级定义准入条件（如冒烟通过率、静态检查无严重问题、测试环境就绪）和准出条件（如用例执行率、缺陷收敛趋势、非功能指标达标），并写明暂停与恢复规则，例如“出现阻断级缺陷时暂停系统测试，修复并回归通过后恢复”。输出是计划中的准入准出章节。完成标志是每条条件都可判定，不出现“基本通过”“大致达标”这类无法核验的表述。
这四步完成后，测试计划中的类型安排章节即具备可执行性。计划、用例与缺陷记录如果分散在文档和表格中，类型组合的执行状态容易失真；在ONES中，测试计划可关联需求与用例，用例按类型和层级打标签，缺陷回流到对应测试项，评审记录与计划版本一并留存，便于按本节步骤逐项核对执行情况。
角色分工与交付物
类型组合的决策、执行与确认需要分开落到人。下表给出常见分工，团队规模较小时可一人兼多角，但决策与评审不宜由同一人完成。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 测试负责人 | 组织风险清单梳理，做出类型组合决策，计划成文，跟踪准入准出 | 质量目标与风险清单、测试计划类型安排章节、配比表 |
| 开发人员 | 执行单元测试与代码检查，修复静态检查发现的问题 | 单元测试用例与结果、代码检查记录 |
| 架构师 | 参与设计评审，确认非功能目标的架构支撑，定义非功能测试触发条件 | 设计评审意见、非功能测试项与通过标准 |
| 运维人员 | 准备测试环境与监控手段，支持性能、可靠性测试执行 | 环境就绪确认、监控数据与测试报告 |
| 业务方或产品负责人 | 确认质量目标与验收标准，参与验收测试确认 | 验收标准确认记录、验收结论 |
| 评审人（可由测试负责人之外的人员担任） | 评审类型组合与计划的可执行性，核对检查清单 | 评审意见与定稿确认 |
分工的关键是让每个测试项都有明确的主责角色，静态测试环节尤其要指定责任人和检查时点，否则前置安排容易落空。
示例：一个迭代的类型组合安排
以下为演示情景，用于说明组合方法，不代表真实项目数据。某电商系统进行为期两周的迭代，新增优惠券叠加规则并调整订单结算接口。
情景设定与风险项
风险清单包括：优惠券叠加计算错误导致金额差错（高）；结算接口在促销峰值下响应超时（高）；新规则与旧版客户端不兼容（中）；结算代码复杂度上升带来维护风险（中）。质量目标为金额计算零差错、峰值下单成功率不低于99.9%、旧版客户端可正常下单。
按层级分配类型
单元层：以静态测试和功能测试为主，代码检查覆盖结算逻辑，单元测试覆盖叠加规则与边界金额。集成层：功能测试验证结算接口与优惠券服务的业务结果，安全测试检查优惠券参数防篡改。系统层：功能测试覆盖下单主流程与异常分支，性能测试按“峰值QPS超过预估阈值”触发，兼容性测试覆盖旧版客户端。验收层：业务方按用户场景确认叠加规则与金额展示。
资源与节奏安排
人力上，开发承担单元测试与代码检查，测试工程师承担集成与系统功能测试，一名测试工程师与运维配合执行性能测试，业务方在验收阶段投入半天。环境上，性能测试使用独立环境，避免与功能测试互相干扰。节奏上，第一周完成静态评审、单元测试与集成测试；第二周前半段执行系统功能测试，主流程稳定后启动性能与兼容性测试，后半段完成验收与回归。
检查点
迭代中期检查静态问题关闭率与集成用例通过率；系统测试准入前确认冒烟通过；性能测试前确认环境与监控就绪；上线前核对高风险项的功能与非功能结果均已记录，缺陷回流项完成回归。
完成检查：组合是否可执行
策略定稿前，用以下清单逐项核对。任一项不满足，说明组合仍停留在描述层面，需要补充后再定稿。
- 每个高风险项都能在清单中找到对应的测试类型和测试层级，且至少有一项非功能验证。
- 每项非功能测试都写明了触发条件和通过标准，标准可量化、可判定。
- 静态测试的三个环节（需求评审、设计评审、代码检查）均有责任人和时点，检查清单已附。
- 资源安排与测试项数量匹配：人力、环境、时间能覆盖计划执行的用例量，没有因环境冲突或人力不足而空转的测试项。
- 每个层级的准入准出条件均可判定，暂停与恢复规则明确到触发条件和恢复动作。
- 类型配比表与实际排期一致，配比调整有记录和理由。
- 评审人已按本清单核对并给出定稿意见。
清单全部通过后，测试计划中的类型组合即可进入执行与跟踪阶段，后续版本可在此基础上按风险变化调整配比。
常见问题
版本周期很短、人力有限时，三类测试的组合应该怎么压缩？
压缩的顺序建议从低风险项开始，而不是平均削减每一类测试。先按风险清单把测试项排序，低风险项只保留静态检查和冒烟级功能验证；中风险项保留功能测试主流程，非功能测试只执行触发条件已满足的子类；高风险项的功能与非功能覆盖不削减，静态环节的代码检查也保留，因为这两处投入的修复成本最低。
压缩后要同步调整准入准出条件，例如把系统测试的用例执行率要求按剩余测试项重新计算，避免条件与实际范围脱节。压缩决定和理由应记录在计划中，便于下个版本复盘时判断是否恢复。
非功能测试的触发条件由谁定，评审时看什么？
触发条件通常由架构师与测试负责人共同确定：架构师从容量设计、安全边界和故障处理方案出发给出技术阈值，测试负责人结合风险清单和历史缺陷判断哪些模块需要纳入。评审时重点看三件事：触发条件是否可量化（如峰值QPS、数据量、并发用户数），通过标准是否可判定（如响应时间上限、错误率上限、恢复时间上限），以及条件与对应风险项是否一一对应。
评审后触发条件应写入测试计划的类型安排章节，执行阶段按条件判断是否启动，减少临时争论。
静态测试已经安排了评审，为什么还要单独写责任人和时点？
评审安排写在计划里，执行时容易因为排期紧张被推迟或走过场。写明责任人和时点，是把静态测试变成有交付物的固定环节：需求评审由谁检查需求完整性与可测试性、设计评审由谁确认非功能目标的架构支撑、代码检查在哪个提交节点完成，各自输出什么记录。
时点建议与开发节奏对齐，例如代码检查随每次提交进行，设计评审在开发启动前完成。这样静态发现的问题能在对应阶段关闭，而不是积压到系统测试阶段才暴露。
类型配比表里的高、中、低，怎么落到具体的人力和用例数量？
配比表给出的是相对投入强度，落地时用测试项清单换算：先统计每个层级、每个类型的测试项数量，再按高、中、低的相对关系分配人力和时间。例如系统层功能测试为高、非功能测试为高，两者在排期上都要留出独立时段，非功能测试还需要独立环境，不能与功能测试共用同一套环境反复重建。
换算结果要与可用人力核对，出现覆盖不了的情况时回到风险清单调整范围，而不是直接降低高风险项的覆盖强度。调整记录保留在计划版本中。
组合执行到一半发现某类测试投入不足，计划怎么调整？
先判断缺口来自范围判断还是资源不足。如果是风险清单遗漏了某类问题，例如集成阶段暴露出较多接口性能问题，应补充对应的非功能测试项和触发条件，并同步更新配比表与准入准出条件；如果是人力或环境不足导致计划内测试项无法执行，应调整排期或缩小低风险项范围，把资源让给高风险项。
调整需要走计划变更记录，写明变更原因、影响的风险项和新的完成标志，评审人确认后执行。缺陷回流数据可以作为判断缺口的主要依据。
