pairwise-test-coverage
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChinesePairwise Test Coverage
成对测试覆盖
Combinatorial testing that covers all factor pairs in near-minimal test cases.
When to use: Multi-factor systems where exhaustive testing is impractical, state machines, retry/recovery logic, configuration matrices, compatibility testing, any code with 3+ interacting parameters.
When not to use: Single-factor tests (just test each value), two-factor systems (test all combinations directly), UI snapshot tests, type-only changes.
通过接近最少的测试用例覆盖所有因子对的组合测试。
适用场景：穷举测试不切实际的多因子系统、状态机、重试/恢复逻辑、配置矩阵、兼容性测试，以及任何包含3个及以上交互参数的代码。
不适用场景：单因子测试（只需测试每个值即可）、双因子系统（直接测试所有组合）、UI快照测试、仅类型变更的场景。
Core Philosophy
核心理念
Exhaustive testing doesn't scale. If a system has 4 factors with 3 values each, that's 81 test cases. Pairwise testing covers all pair interactions in ~12 cases -- an 85% reduction with near-complete defect detection.
穷举测试无法扩展。如果一个系统有4个因子，每个因子有3个取值，那需要81个测试用例。而成对测试仅需约12个用例就能覆盖所有因子对交互——测试用例减少85%，同时缺陷检测率接近完整覆盖。
Rationalizations (Do Not Skip)
误区纠正（请勿跳过）
| Rationalization | Why It's Wrong | Required Action |
|---|---|---|
| "We'll test the important combinations" | Unexpected factor interactions go untested without systematic coverage | Generate the pairwise matrix |
| "81 test cases is fine" | 81 cases means 81 things to maintain and debug when they fail | Use pairwise to get 12 |
| "The test passes, so the code works" | Test must FAIL before the fix to prove it catches the bug | Validate detection first |
| 错误观点 | 错误原因 | 正确做法 |
|---|---|---|
| “我们只测试重要的组合” | 缺乏系统性覆盖会导致未预料到的因子交互无法被测试 | 生成成对矩阵 |
| “81个测试用例没问题” | 81个用例意味着维护成本高，且失败时需要调试81个内容 | 使用成对测试将用例减至12个 |
| “测试通过了，所以代码没问题” | 测试必须在修复前失败，才能证明它能发现bug | 先验证缺陷检测能力 |
Quick Reference
快速参考
| Technique | Use When | Key Pattern |
|---|---|---|
| Pairwise Matrix | Multiple factors with discrete values | |
| Property-Based | Value ranges, type safety invariants | |
| Model-Based | State machine transitions | Transition table tests |
| Fault Injection | Storage/network failures | Mock rejection scenarios |
| Contract Tests | Schema validation at boundaries | |
| 技术 | 适用场景 | 核心模式 |
|---|---|---|
| 成对矩阵 | 多因子且取值离散的场景 | |
| 基于属性的测试 | 取值范围、类型安全不变量 | |
| 基于模型的测试 | 状态机转换 | 转换表测试 |
| 故障注入 | 存储/网络故障场景 | 模拟拒绝场景 |
| 契约测试 | 边界处的 schema 校验 | |
Included Utilities
内置工具
typescript
// Pairwise matrix generator (zero dependencies)
import { generatePairwiseMatrix, formatAsMarkdownTable } from './pairwise.ts';
// Pairwise test case helpers
import { createPairwiseTestCases, generateTestCaseName } from './test-fixtures.ts';typescript
// 成对矩阵生成器（零依赖）
import { generatePairwiseMatrix, formatAsMarkdownTable } from './pairwise.ts';
// 成对测试用例辅助工具
import { createPairwiseTestCases, generateTestCaseName } from './test-fixtures.ts';Performance and Limits
性能与限制
The greedy algorithm never enumerates the Cartesian product. Pair count grows as O(factors² × values²).
| Factors | Values | Cartesian | Pairwise Cases | Time |
|---|---|---|---|---|
| 3 | 3 | 27 | ~10 | <1ms |
| 8 | 4 | 65,536 | ~46 | ~2ms |
| 8 | 8 | 16,777,216 | ~100 | ~10ms |
Hard limits (throws if exceeded): max 20 factors, max 50 values per factor. Beyond these, pair count exceeds ~475K (C(20,2) × 50²) and in-memory generation becomes impractical.
贪心算法不会枚举笛卡尔积。因子对数量的增长复杂度为 O(factors² × values²)。
| 因子数量 | 每个因子的取值数 | 笛卡尔积数量 | 成对测试用例数 | 耗时 |
|---|---|---|---|---|
| 3 | 3 | 27 | ~10 | <1ms |
| 8 | 4 | 65,536 | ~46 | ~2ms |
| 8 | 8 | 16,777,216 | ~100 | ~10ms |
硬限制（超出则抛出错误）：最多20个因子，每个因子最多50个取值。超出此范围后，因子对数量会超过约47.5万（C(20,2) × 50²），内存内生成将变得不切实际。
Violation Rules
违规规则
| Slug | Rule | Severity |
|---|---|---|
| Multi-factor code changes need pairwise tests | must-fail |
| Tests must fail before fix, pass after | must-fail |
| 标识 | 规则 | 严重程度 |
|---|---|---|
| 多因子代码变更需要成对测试 | 必须失败 |
| 测试必须在修复前失败、修复后通过 | 必须失败 |
Definition of Done
完成标准
- Factors documented in test file header
- Pairwise matrix as test cases
it.each - Tests fail before fix, pass after
- 测试文件头部已记录因子信息
- 成对矩阵以 测试用例形式存在
it.each - 测试在修复前失败、修复后通过
Companion Skills
配套技能
This skill provides combinatorial test matrix generation, not test design guidance. For broader methodology:
- Search on skills.sh for constraint handling, higher-strength covering arrays, and test oracle strategies
combinatorial testing - Guard truth tables with 5+ boolean inputs use pairwise for coverage — use model-based-testing for state machine transition matrices and guard truth table generation
- Zod schemas with 5+ optional fields use pairwise for compound state coverage — use zod-contract-testing for schema boundary validation and compound state matrices
本技能提供组合测试矩阵生成能力，但不包含测试设计指导。如需更全面的方法论：
- 在 skills.sh 上搜索 ，获取约束处理、更高强度覆盖数组和测试预言机策略相关内容
combinatorial testing - 包含5个及以上布尔输入的守卫真值表，使用成对测试实现覆盖——对于状态机转换矩阵和守卫真值表生成，使用 model-based-testing
- 包含5个及以上可选字段的 Zod 模式，使用成对测试实现复合状态覆盖——对于 schema 边界校验和复合状态矩阵，使用 zod-contract-testing
Details
详细内容
See references for:
- workflow.md: Step-by-step implementation guide
- violations.md: Full violation rules with detection patterns
- examples.md: 6 testing technique examples (pairwise, property-based, model-based, fault injection, contract, observability)
参考以下文件获取详情：
- workflow.md：分步实现指南
- violations.md：完整的违规规则及检测模式
- examples.md：6种测试技术示例（成对测试、基于属性的测试、基于模型的测试、故障注入、契约测试、可观测性测试）