成对组合测试设计 Skill：用两两交互覆盖降低组合测试成本
两个设置经常会产生单独测试时看不见的交互。成对组合测试把它们暴露出来，又不要求团队执行所有完整组合。
为什么需要这个 Skill
成对组合测试设计用于在遵守约束并保留高风险组合的前提下，选择覆盖因素取值对的测试用例。
Skill 用来做什么
当团队需要围绕“因素对、取值选择、约束、风险加权、覆盖和可复现性”工作时，使用成对组合测试设计 Skill。
Awesome QA Skills 按语言和测试阶段组织 Skill。系列总览 解释通用安装方式，本文只聚焦成对组合测试设计。
好的成对设计不是生成器吐出的魔法结果。它解释约束、保留罕见高风险组合，并说明两两覆盖无法证明三因素或有状态交互。
它适合这些场景：团队需要重复检查因素对、取值选择、约束、风险加权、覆盖和可复现性；多个证据来源互相矛盾；交接时必须说明哪些内容仍未验证。
它不做什么
成对组合测试设计 Skill 可以组织成对集合的材料、证据和下一步动作，但它不能替代：
- 业务或领域负责人对规则、范围和风险的确认。
- 真实环境、账号、数据、日志或运行结果；静态分析不会自动升级为运行证据。
- 发布、合规、生产操作和残余风险接受等授权决定。
- 在输入相互冲突时替团队选择一个未经确认的事实。
它主要检查哪些内容
这个 Skill 的价值不在于把关键词再列一遍，而在于把每个关注点接到可观察的输入、判断和收口动作。先用源 Skill 已定义的输出字段整理一张小矩阵：
| 检查关注点 | 开始前要问 | 结果应留下什么 |
|---|---|---|
| 成对集合 | 选中的用例与因素取值 | 符合约束 |
| 覆盖报告 | 已覆盖、排除和未覆盖因素对 | 原因 |
| 风险复核 | 需要显式用例的高影响因素对 | 负责人和下一步 |
如果某一行只有经验判断、没有来源或验证方法，就把它留在待确认项里，不要提前写成通过。
开始之前先审计输入
围绕“成对集合”开始分析时，先把输入分成六种状态。缺口不会自动变成失败，但也不能被隐藏在结论里。
| 状态 | 含义 | 本 Skill 的处理方式 |
|---|---|---|
| known | 材料直接证明的事实 | 标出来源、版本和时间，允许进入判断 |
| missing | 本轮需要但尚未提供的材料 | 列出最小补证动作，结论保持受限 |
| conflicting | 来源之间互相矛盾 | 并列来源和冲突点，交给负责人裁决 |
| stale | 材料存在但版本或时间已经过期 | 标出新鲜度，不把旧结论当当前事实 |
| out_of_scope | 有关但不在本轮范围内 | 明确排除，避免分析悄悄扩大 |
| assumptions | 为继续分析而暂时采用的假设 | 写出验证方式和失效条件 |
至少把输入版本、范围、环境、证据位置和负责人放在一起。没有运行记录时，只能交付分析、设计或验证计划，不能写执行通过。
从问题到结构化发现
先把来源、范围、证据状态、分析判断、责任角色、动作、关闭条件和验证方式连起来，再写结论。下面的案例保留这个 Skill 的专属编号和领域语境。
分层写法
围绕成对集合，不要把四种语气揉成一句“建议通过”：
| 层次 | 写法 | 本文应用 |
|---|---|---|
| 事实 | 材料直接显示了什么 | 引用来源中的重点、版本、输入或运行记录 |
| 基于证据的推断 | 多个事实共同支持的判断 | 说明推断链，并保留不确定性 |
| 建议 | 下一步最小动作是什么 | 指定补证、复核、执行或回归路径 |
| 人工决策 | 谁需要决定什么 | 由负责人确认范围、风险接受、资源和发布含义 |
一个完整案例
本节按输入、分析、发现、决策和验证展开；材料不足时保留 missing、conflicting 或 assumptions，不把它们改写成通过。
输入
| 材料 | 这次提供什么 | 缺失时怎么处理 |
|---|---|---|
| 因素清单 | 因素、取值、两两目标和风险 | 先合并行为等价取值 |
| 约束 | 不支持或互斥的因素对 | 记录排除的组合 |
| 执行上下文 | 数据、平台、环境和证据收集 | 确保生成用例可复现 |
可以这样调用：
请使用 pairwise-testing Skill。
任务：覆盖通知渠道、语言、设备类型和隐私模式在账号设置中的两两交互
输入材料：[需求、版本、链接、日志、报告或数据路径]
范围：[本次包含和排除的对象]
未知项：[缺失的环境、账号、数据或权限]
期望输出：[按风险排序的发现、证据状态和下一步动作]
先审计输入。分开写事实、假设和待确认问题。没有运行记录时不要声称已经执行。分析
先从一个边界清楚的小回合开始：覆盖通知渠道、语言、设备类型和隐私模式在账号设置中的两两交互。覆盖邮件、Push 和短信渠道在两种语言、移动端与桌面端、严格与宽松隐私模式下的组合。账号没有验证手机号时排除短信，再人工检查剩余未覆盖的隐私因素对。
交接产物要保留输入版本、时间窗口、证据索引、负责人和下一次验证动作。Skill 可以整理不确定性，不能制造缺失的产物。
发现
示例发现：把一次问题写成可交接动作
下面的字段示例只展示记录方式，不代表真实环境已经执行。
假设当前材料无法证明“成对集合”已经满足要求，发现可以这样写。它既不替团队补写规则，也不把缺失证据伪装成失败。
| 字段 | 示例写法 |
|---|---|
| 来源与范围 | 记录本轮使用的需求、版本、环境和成对集合的具体对象 |
| 发现 | 成对集合的判断条件或结果仍缺少可追溯依据 |
| 证据状态 | missing / assumptions；如果来源相互矛盾则改为 conflicting |
| 影响与优先级 | 说明会影响哪个用户、链路或交付决定，不凭感觉扩大等级 |
| 负责人和人工决策 | 由业务、开发、安全或测试负责人确认规则和风险取舍 |
| 动作与关闭条件 | 补齐最小证据；关闭条件是来源、判断和责任人都能复核 |
| 验证 | 指定一次可重复的检查、查询或运行，并保存原始产物 |
这类记录的重点是让下一位同事能从发现回到来源，再执行一项能改变结论的动作。
决策
责任角色和待决策问题应由对应负责人确认；Skill 不替他们做风险取舍。
验证
关闭前按发现中的验证方式执行，并保留原始产物；没有执行记录时，状态仍然保持未验证。
发现如何进入下一阶段
交接产物
| 输出字段 | 它要回答什么 | 示例状态 |
|---|---|---|
| 成对集合 | 选中的用例与因素取值 | 符合约束 |
| 覆盖报告 | 已覆盖、排除和未覆盖因素对 | 原因 |
| 风险复核 | 需要显式用例的高影响因素对 | 负责人和下一步 |
没有运行记录、查询结果或原始产物时，不要写“已通过”。好的成对设计不是生成器吐出的魔法结果。它解释约束、保留罕见高风险组合，并说明两两覆盖无法证明三因素或有状态交互。
下一步路由
至少交付来源、证据状态、负责人、关闭条件和验证动作；下一阶段的结论仍受证据状态约束。
怎样准备更好的输入
如果第一次调用只有一行目标，输出就应该保持受限。补充来源版本、受影响对象、环境、已知缺陷和决策负责人，才能从看起来完整的清单推进到可用评审。
这里补充信息会改变结果，因为因素对、取值选择、约束、风险加权、覆盖和可复现性必须接回证据，不能只靠熟悉的测试套路推断。
和其他 Skill 怎么配合
容易踩的坑
- 把两两覆盖当成全部交互覆盖。
- 忘记数据或权限约束。
- 不保留生成种子或用例顺序。
安装与调用
全局安装这个 Skill：
npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/pairwise-testing -g安装后使用 pairwise-testing Skill，并附上真实项目材料。
常见问题
什么时候应该用更高阶组合？
当领域失败依赖两个以上因素时，使用更高阶交互覆盖。
成对测试可以自动选择取值吗？
可以减少选择工作，但风险和约束仍需要人工评审。
参考
源 Skill 与执行契约
完整执行契约位于 成对组合测试设计 提示词。调用 Skill 前先阅读它；提示词定义了详细流程和输出契约。源目录 中包含入口文件以及实际存在的配套资料。
入口文件重点约束因素对、取值选择、约束、风险加权、覆盖和可复现性。要保留它的决策边界，不要把静态设计写成执行结论。
参考链接
-
Awesome QA Skills：成对组合测试设计 源文件：https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/pairwise-testing
-
Awesome QA Skills GitHub:https://github.com/naodeng/awesome-qa-skills
-
成对组合测试设计 详情页：https://inaodeng.com/zh-cn/qaskills/pairwise-testing/