Combination Strategy
当参数多、环境多、"全组合测不完"时运用正交试验法、Pairwise和判定表来解决组合爆炸问题。如果系统有多个输入字段的组合依赖关系(如"A=1且B=2时C不能为3")、或者需要适配多浏览器多操作系统多语言,一定要用此技能来设计高效的组合覆盖方案。不要试图全覆盖——组合测试的核心是用最少的用例达到最高的组合覆盖率。输出组合覆盖矩阵并标注覆盖遗漏。
SKILL.md
⚠️ 本技能单独使用效果有限,建议配合完整技能集(12 步工作流)使用。安装:npx skills add Kokxi/qa-test-skills
⚠️ 安全警告:本技能的示例可能涉及订单号、支付金额、截图、身份证、手机号等敏感数据。 实际使用时请勿粘贴真实生产数据、客户信息或财务凭证;测试前应脱敏/掩码处理。 本技能仅在 workspace/ 输出评估文件,不持久化、不外传、不跨会话复用。
组合测试策略
核心原则
全组合测不完,不测又怕漏——用科学方法简化。提供 Pairwise、正交实验法、风险加权组合三种简化策略。组合数必须少于全量组合,并标注覆盖分析。
加载时机
| 什么时候读 | 读哪个 |
|---|---|
| 设计 Pairwise/正交/风险加权时 | references/reduction-strategies.md |
三种简化策略的完整内容已下沉至references/reduction-strategies.md,避免每次触发都占用上下文。
组合测试流程
步骤1:识别参数
参数识别清单:
├─ 输入参数
│ ├─ 用户输入:文本、数字、选择
│ ├─ 系统参数:配置、环境
│ └─ 数据参数:数据状态、数据量
│
├─ 环境参数
│ ├─ 浏览器:Chrome, Firefox, Safari
│ ├─ 操作系统:Windows, Mac, Linux
│ ├─ 设备:PC, Mobile, Tablet
│ └─ 网络:WiFi, 4G, 弱网
│
└─ 状态参数
├─ 用户状态:新用户、老用户、VIP
├─ 数据状态:空、少量、大量
└─ 系统状态:正常、高负载、异常
步骤2:评估风险
风险评估矩阵:
| 参数组合 | 业务影响 | 历史缺陷 | 技术复杂度 | 风险等级 |
|---|---|---|---|---|
| A1+B1 | 高 | 有 | 高 | 高 |
| A1+B2 | 中 | 无 | 中 | 中 |
| A2+B1 | 低 | 无 | 低 | 低 |
步骤3:选择策略
根据风险等级选择测试策略:
高风险组合 → 全组合测试
示例:支付+优惠券+退款
中风险组合 → Pairwise测试
示例:浏览器×操作系统×分辨率
低风险组合 → 单参数测试
示例:不同字体、不同颜色
步骤4:生成用例
用例生成模板:
用例编号:COMBO-001
组合内容:[参数1=值1, 参数2=值2, 参数3=值3]
风险等级:高/中/低
测试重点:[这个组合要特别关注什么]
前置条件:[测试前需要准备什么]
测试步骤:[具体操作步骤]
预期结果:[期望的输出]
组合测试示例
场景:电商下单功能
参数识别:
- 用户类型:新用户、老用户、VIP
- 商品类型:普通商品、虚拟商品、预售商品
- 支付方式:微信、支付宝、银行卡
- 优惠券:无、满减券、折扣券
风险评估:
- 高风险:VIP+预售+折扣券(复杂业务规则)
- 中风险:新用户+虚拟商品(特殊流程)
- 低风险:老用户+普通商品+微信(常规流程)
测试策略:
高风险组合(全组合):
- VIP+预售+微信+折扣券
- VIP+预售+支付宝+折扣券
- VIP+预售+银行卡+折扣券
- VIP+预售+微信+满减券
- VIP+预售+支付宝+满减券
- VIP+预售+银行卡+满减券
中风险组合(Pairwise):
- 新用户+虚拟商品+微信
- 新用户+普通商品+支付宝
- 老用户+虚拟商品+银行卡
- 老用户+预售商品+微信
低风险组合(单参数):
- 新用户+普通商品+微信+无优惠券
- 老用户+普通商品+微信+无优惠券
- VIP+普通商品+微信+无优惠券
策略选择速查表
| 特征 | 推荐策略 | 组合压缩比 | 最佳适用 |
|---|---|---|---|
| 参数3-10个,每参数2-5值 | Pairwise | 全组合的10-30% | 功能、兼容测试 |
| 参数>10个,需统计分析 | 正交实验 | 全组合的5-20% | 配置、环境兼容测试 |
| 有历史缺陷数据 | 风险加权 | 按需调整 | 回归测试、重点突破 |
| 高安全/高风险 | 全组合 | 100% | 支付、安全模块 |
常见反模式
- 一刀切选Pairwise:不管场景都用两两组合 → 高安全场景必须全组合,低风险场景单参数即可
- 参数遗漏:只列了输入参数,漏了环境/状态参数 → 参数识别清单必须覆盖输入/环境/状态三类
- 对结果不排序:Pairwise跑出100条用例直接全测 → 按风险等级排序,先跑高风险组合
- 忽略交互:只测单参数,不测参数间组合 → 所有业务规则设计到的参数间交互必须覆盖
异常处理引导
| 场景 | 表现 | 处理方式 |
|---|---|---|
| 参数过多导致组合爆炸 | 简化后仍有1000+组合 | 按风险加权:高风险组合全覆盖,低风险抽样 |
| 环境差异导致不一致 | 不同环境结果不同 | 锁定基线环境,标注差异,分环境执行 |
| 业务规则频繁变化 | 组合条件随需求变更 | 稳定参数做基础组合,易变参数单独测试 |
| 遗漏关键组合 | 上线后发现未覆盖的组合有问题 | 更新检查清单,增加历史缺陷驱动的组合权重 |
输出示例
场景:电商下单功能测试(参数:用户类型×商品类型×支付方式) → 参数识别:用户(新用户/老用户/VIP)、商品(普通/虚拟/预售)、支付(微信/支付宝/银行卡) → 策略选择:Pairwise生成9条组合覆盖所有两两交互 → 风险加权:VIP用户+预售商品+微信支付标记为高风险(深测)
参数太多(10个参数×每个5种取值)全组合2小时跑不完 → 先用Pairwise压缩到核心组合,再补充高风险组合深测
检查清单
组合测试完成后检查:
- 参数识别是否完整?
- 风险评估是否合理?
- 策略选择是否恰当?
- 高风险组合是否全覆盖?
- 用例是否可执行?
- 测试效率是否提升?
评论与讨论
还没有评论,分享你的体验吧。