测试类型组合要解决的问题，是在有限人力、环境和时间下，把功能、接口、性能、兼容性、安全、回归等测试放到最需要的位置。本文给出一套可操作的做法：先做风险分级与资源盘点，再建立测试类型与风险、层级的对应关系，据此确定组合与投入比例，明确角色分工，并用检查清单确认这份组合能够执行。最终交付物包括风险分级表、资源盘点清单、测试类型组合表和完成检查清单。
要点总览（TL;DR）
- 先按业务影响与失效概率给需求或模块定风险等级，再盘点人力技能、环境、时间窗口和测试数据四类资源约束，两项输入齐备后再讨论测试类型取舍。
- 把功能、接口、性能、兼容性、安全、回归等类型对应到各自覆盖的风险面和执行层级，高风险模块配置全流程与关键契约验证，低风险模块精简为冒烟加必要回归。
- 资源不足时从低风险项开始裁剪，高风险项的类型覆盖、上线功能的冒烟验证、变更关联模块的回归是三条保留底线，触碰底线需书面记录并由产品负责人确认。
- 组合表要写清测试类型、覆盖对象、执行层级、投入占比、负责人和完成标志，用风险覆盖率与资源占用率两项指标做平衡校验。
- 计划变更时按需求范围变化、提测推迟、关键资源不可用、发现新高风险缺陷等条件触发复核，更新组合表并归档变更记录。
先定判断口径：风险分级与资源盘点
类型组合的取舍需要两个输入：哪些地方值得多测，以及手上有多少资源可用。风险分级回答前者，资源盘点回答后者。两项输入没有完成之前就讨论“做不做性能测试”，容易变成凭印象分配。
按业务影响与失效概率划分风险等级
对每个需求或模块，从两个维度打分：业务影响指失效后对用户、资金、合规或口碑的损害程度；失效概率指该部分逻辑复杂度、变更幅度、历史缺陷密度和技术陌生度带来的出错可能。两个维度各分三档，交叉后形成风险等级。
| 业务影响 \ 失效概率 | 低 | 中 | 高 |
|---|---|---|---|
| 高 | 中风险 | 高风险 | 高风险 |
| 中 | 低风险 | 中风险 | 高风险 |
| 低 | 低风险 | 低风险 | 中风险 |
打分时给每个判断附一句依据，例如“支付回调涉及资金，影响为高；本次重构改动核心链路，失效概率为高”。依据写清楚，评审时才能被质疑和修正。风险分级表的输出物是：模块或需求清单、两个维度的评分、风险等级、判断依据、复评时间。这项工作通常由测试负责人牵头，模块测试人员提供变更与缺陷历史，产品提供业务影响判断。
资源盘点要列清四类约束
资源盘点不是笼统写“人手紧张”，而是把约束量化到可以排期的程度：
- 人力技能：可投入的测试人数、各自擅长的领域（如性能调优、安全测试、自动化脚本），以及外部支持是否可得。
- 测试环境：各类环境的数量与可用时段，特别是性能环境、兼容性设备池、安全测试隔离环境这类稀缺资源。
- 可用时间窗口：本版本从提测到发布的日历天数，扣除等待修复、回归验证后的净测试时间。
- 测试数据：生产脱敏数据、构造数据、压测数据集的准备状态和获取周期。
盘点结果形成资源盘点清单，由测试负责人维护，在排组合表前与开发负责人确认环境占用，避免计划写在纸上、执行时抢环境。清单需要标注每项资源的可用起止时间，这是后续判断“能不能排进去”的直接依据。
把测试类型映射到风险与层级
测试类型的选择依据是它覆盖哪类风险，以及在哪一层执行成本最低。先建立对应关系，再谈投入多少，可以避免把所有验证都压到系统测试阶段。
常见测试类型的风险覆盖面
| 测试类型 | 主要覆盖的风险 | 常见执行层级 |
|---|---|---|
| 单元测试 | 核心算法、边界条件、复杂分支的逻辑错误 | 代码层，开发主导 |
| 接口测试 | 服务间契约、参数校验、异常返回、数据一致性 | 接口层，前后端联调前后 |
| 功能测试 | 业务流程正确性、需求符合度、状态流转 | 系统层，提测后 |
| 性能测试 | 响应时间、吞吐量、并发下的稳定性与资源占用 | 系统层，独立性能环境 |
| 兼容性测试 | 浏览器、机型、操作系统、分辨率差异导致的展示与功能异常 | 系统层，设备或浏览器矩阵 |
| 安全测试 | 越权访问、注入、敏感数据暴露、认证绕过 | 接口层与系统层结合 |
| 回归测试 | 变更对既有功能的影响，历史缺陷复发 | 按影响范围选择单元、接口或系统层 |
按风险等级配置类型
高风险模块优先配置能够直接暴露重大失效的类型：功能测试做全流程覆盖，接口测试覆盖关键契约与异常分支，性能测试验证峰值场景，安全测试检查权限与敏感数据，回归范围覆盖关联模块。中风险模块以功能测试和接口测试为主，性能与安全按是否触及相关面选择性执行，回归聚焦直接依赖。低风险模块精简为冒烟级功能验证加必要回归，把节省出的时间投向高风险项。
层级选择遵循“能在低层验证的不拖到高层”：逻辑分支用单元测试覆盖，契约问题用接口测试拦截，系统层集中验证端到端流程和跨模块交互。这样同一份人力可以覆盖更多风险点。对应表的输出物是：每个风险等级对应的类型清单、执行层级、覆盖对象说明，由测试负责人组织模块测试人员共同确认。
在资源约束下确定类型组合与投入比例
有了风险分级和类型对应关系，接下来把资源上限作为边界，排出可执行的组合。核心原则是：高风险项的类型配置不因资源紧张而取消，只能调整执行深度和自动化程度；被压缩的空间从中低风险项中找。
分配步骤
- 列出全部候选测试类型，按风险等级标注必做、应做、可选三档。必做对应高风险项的核心类型，应做对应中风险项，可选对应低风险项。
- 用资源盘点清单中的净测试时间乘以可投入人力，得到总人天上限，再按风险等级初分比例。常见起点是高风险项占一半以上，中风险项占三成左右，低风险项保留一到两成用于冒烟和回归。
- 逐项核对必做类型是否有对应的人力技能、环境和数据。缺一项就标记为资源缺口，进入调整环节，而不是默认它能做成。
- 对资源缺口做替换：性能环境不足时，缩小压测场景到核心交易链路；安全测试人力不足时，优先做权限与敏感数据两类检查；兼容性设备不足时，按用户访问占比选取主流机型。
- 把最终结果填入组合表，计算风险覆盖率（已配置测试类型的高风险项占全部高风险项的比例）和资源占用率（计划人天除以可用人天），两项都达标后提交评审。
资源不足时的裁剪顺序与保留底线
裁剪从低风险项开始：先去掉低风险模块的可选类型，再压缩中风险项的测试深度，例如把全量回归改为影响范围回归。保留底线有三条：高风险项必须有对应类型覆盖；每个上线功能至少有冒烟级验证；本次变更涉及的关联模块必须纳入回归。触碰底线的裁剪需要测试负责人书面记录风险，并由产品负责人确认接受。
组合表字段
| 字段 | 填写要求 |
|---|---|
| 测试类型 | 功能、接口、性能、兼容性、安全、回归等 |
| 覆盖对象 | 具体模块、接口或业务场景，避免写“全系统” |
| 执行层级 | 单元、接口、系统、验收 |
| 投入占比 | 占本版本测试总人天的百分比，合计为100% |
| 负责人 | 具体到人，含开发侧配合人 |
| 完成标志 | 可核验的结果，如用例执行率与通过率、压测报告结论、缺陷收敛情况 |
组合表编制完成后，风险项、测试任务和负责人需要在同一处跟踪状态，避免表格与执行脱节。ONES 的工作项与测试管理能力可以把风险项关联到具体测试任务，记录负责人、状态和完成情况，评审后的调整也能留痕，便于版本结束时对照检查覆盖率是否兑现。
角色分工与交付物
组合表要落到执行，需要明确谁编制、谁提供输入、谁评审、谁按表执行。职责不清时，组合表容易停留在文档层面。
| 角色 | 职责 | 交付物 | 交接节点 |
|---|---|---|---|
| 测试负责人 | 组织风险分级，维护资源盘点清单，编制组合表，主持评审 | 风险分级表、资源盘点清单、测试类型组合表 | 提测前完成评审并发布 |
| 模块测试人员 | 提供模块变更与缺陷历史，认领类型任务，按完成标志交付 | 模块风险评分依据、测试用例与执行记录、测试报告 | 评审前提交输入，执行期按周更新状态 |
| 开发 | 确认环境占用，承担单元测试与接口测试，配合缺陷修复 | 单元与接口测试结果、环境可用时间确认 | 排期前确认环境，提测时提交自测结果 |
| 产品 | 判断业务影响，确认风险接受，参与验收标准制定 | 业务影响评级、风险接受记录、验收标准 | 风险分级阶段与裁剪确认时 |
评审采用会议加书面确认的方式：测试负责人讲解组合表与覆盖率、资源占用两项指标，各角色确认自己的任务与完成标志，有异议当场调整并记录。评审通过后组合表作为本版本测试执行的依据，变更需走同样的确认流程。
示例：一个版本的类型组合如何落地
以下为演示情景，用于说明排布过程，不代表真实项目数据。某版本包含订单结算改造、会员积分规则调整和后台报表导出三个部分，净测试时间10个工作日，可投入测试人力3人，合计约30人天；性能环境仅第4至第6个工作日可用，兼容性设备池覆盖主流机型。
风险分级结果
| 模块 | 业务影响 | 失效概率 | 风险等级 | 依据 |
|---|---|---|---|---|
| 订单结算改造 | 高 | 高 | 高风险 | 涉及资金与核心链路，本次改动幅度大 |
| 会员积分规则 | 中 | 中 | 中风险 | 影响用户权益，规则变更范围可控 |
| 后台报表导出 | 低 | 中 | 低风险 | 内部使用，出错可人工补导 |
类型组合与投入比例
| 测试类型 | 覆盖对象 | 层级 | 投入占比 | 负责人 | 完成标志 |
|---|---|---|---|---|---|
| 接口测试 | 结算下单、支付回调、退款接口 | 接口 | 15% | 开发A，测试B复核 | 关键接口用例全部通过，异常分支有记录 |
| 功能测试 | 结算全流程、积分规则、报表导出 | 系统 | 35% | 测试B、测试C | 用例执行率100%，严重缺陷清零 |
| 性能测试 | 结算下单峰值场景 | 系统 | 15% | 测试B | 压测报告给出结论，瓶颈有处理意见 |
| 安全测试 | 结算与积分接口的越权、敏感数据 | 接口与系统 | 10% | 测试C | 权限检查项全部通过 |
| 兼容性测试 | 结算页在主流机型与浏览器的展示与支付 | 系统 | 10% | 测试C | 矩阵内设备验证完成，问题已修复 |
| 回归测试 | 订单关联模块、积分历史数据 | 接口与系统 | 15% | 测试B、测试C | 影响范围回归通过，历史缺陷无复发 |
资源冲突时的调整
初排时性能测试计划覆盖下单与查询两个场景，但性能环境只有三天可用，且与安全测试的隔离环境准备时间重叠。调整方式：性能测试收敛到下单峰值这一个核心场景，查询场景改为接口层响应时间抽测；安全测试提前到第2个工作日，用测试环境完成权限检查，敏感数据检查放到性能环境释放后执行。报表导出原计划做兼容性验证，按低风险裁剪为冒烟级功能验证，节省的人天补入结算回归。调整后高风险项的类型覆盖没有减少，资源占用控制在30人天内。
完成检查：组合是否可执行
组合表提交评审前，用以下清单逐项核对。任何一项不通过，都回到对应环节修正，而不是带着缺口进入执行。
- 高风险项是否都有对应测试类型覆盖，覆盖对象是否写到具体模块或接口，而非笼统的“全系统”。
- 每类测试是否有明确负责人，负责人是否具备所需技能，开发侧配合人是否确认。
- 每类测试是否有可用环境和测试数据，环境占用时间是否与排期一致。
- 每类测试是否有可核验的完成标志，例如用例执行率、压测结论、缺陷收敛标准，而非“已完成测试”。
- 投入占比合计是否为100%，资源占用率是否在可用人天上限内。
- 被裁剪的类型是否记录了风险说明，是否经产品负责人确认接受。
- 风险覆盖率是否达到约定目标，未覆盖的高风险项是否有替代验证手段。
计划变更时触发复核：需求范围新增或删减、提测时间推迟超过两个工作日、关键人员或环境不可用、执行中发现新的高风险缺陷。复核由测试负责人组织，更新组合表并重新确认覆盖率与资源占用，变更记录随版本归档，作为下个版本风险分级的参考。
常见问题
风险分级时业务影响和失效概率打分有分歧，怎么处理？
分歧通常来自判断依据没有写清楚。要求每个评分附一句具体依据，例如“涉及资金结算，影响为高”“本次重构改动核心链路，失效概率为高”，评审时针对依据讨论而不是针对分数争论。仍然无法达成一致时，由测试负责人和产品负责人共同裁定，并在风险分级表中记录裁定结果和理由，作为下个版本复评的参考。风险等级偏保守不会造成实质损失，偏乐观才会让高风险项漏配测试类型。
资源紧张时，性能测试和安全测试只能保留一项，怎么选？
判断依据是本次变更是否触及相关风险面。变更涉及核心交易链路、并发入口或数据量明显增长时，性能风险更直接，优先保留核心场景的性能验证；变更涉及权限模型、认证流程、对外接口或敏感数据流转时，安全风险更直接，优先保留越权与敏感数据检查。两项都触及时，可以缩小范围而不是二选一：性能测试收敛到单一峰值场景，安全测试只做权限与敏感数据两类检查，用较低成本覆盖主要风险。无论保留哪项，另一项的风险说明和替代验证手段都要写入组合表。
组合表评审通过后，执行中发现原定的投入比例不够用，怎么办？
先判断缺口属于哪类情况。如果是某类测试的实际工作量超出预估，从低风险项的可选类型中调剂人天，并同步更新投入占比，保证合计仍为100%。如果是执行中发现了新的高风险缺陷，触发复核：重新评估该模块的风险等级，补充对应测试类型，必要时压缩中低风险项的测试深度。调整后的组合表需要重新确认风险覆盖率与资源占用率，变更记录随版本归档，不能只在执行群里口头同步。
低风险模块只做冒烟测试，会不会漏掉问题？
冒烟级验证的前提是该模块本次变更幅度小、历史缺陷密度低、失效后可以人工补救。满足这些条件时，冒烟加必要回归是合理的精简方式。需要额外关注两种情况：低风险模块被高风险模块直接依赖时，回归范围要覆盖这层依赖；低风险模块本次改动涉及数据迁移或对外接口时，应重新评估失效概率，必要时上调风险等级。风险分级表中的复评时间就是为这类变化准备的。
类型组合表需要每个版本都重新编制吗？
不需要从零开始。可以把上个版本的组合表作为基线，按本版本的变更范围调整：风险等级发生变化的模块重新配置类型，未变更的模块沿用原配置并核对资源是否仍然可得。基线复用的价值在于历史缺陷密度和实际投入数据可以直接作为本次分级的依据。每个版本结束时对照检查覆盖率是否兑现，把偏差记录下来，下个版本编制时修正预估。
