组合测试与分类树

• 正交数组的基本概念
• 设计步骤（因子、水平、选表、生成）
• 正交表的性质

正交数组（OA）设计步骤为：第一步，确定因子与水平——列出影响测试结果的因子（如操作系统、浏览器、分辨率）及各因子的水平（取值），水平数可相同或相近；第二步，确定正交表——根据因子数 k 与水平数，选择匹配的正交表（如 L9(3^4)、L16(4^5)、L25(5^6)），表符号 L_n(t^k) 表示 n 次试验、k 个因子、每个因子 t 个水平；若无现成表，可用构造算法生成；第三步，映射因子——把实际因子与水平填入正交表对应列，不用的列可忽略；第四步，生成测试用例——正交表每一行即一个测试用例，覆盖各因子水平的组合；第五步，验证正交性——校验任意两因子各水平组合出现的次数相等（均衡性），保证覆盖均匀。设计后还需补充必要的边界/约束用例。

正交数组的核心是"均衡性"：任意两因子各水平组合出现次数相等，从而保证"两两覆盖"且无偏。设计步骤的关键是"因子水平确定 + 正确选表 + 映射生成"。正交表牺牲高阶组合覆盖以换取用例数可控，适合水平数相同、交互以两两为主的场景。

• Pairwise 的覆盖原理
• 所有参数对覆盖的含义
• 为什么有效

Pairwise（2-way）组合测试的原理是：不覆盖所有参数的全组合，而是保证"任意两个参数的所有取值组合"都至少出现一次。设参数 A 有 a 个取值、B 有 b 个取值，则 A、B 两参数的所有组合有 a×b 种，Pairwise 保证这些组合各至少覆盖一次；对全部参数对（如 A-B、A-C、B-C）都满足此要求。这样用例数从全组合的乘积级降到接近"最大参数取值数 × 参数个数"的量级，同时覆盖了参数间的主要交互。Pairwise 有效的原因是经验表明：大多数缺陷由单个参数或两个参数交互触发，3 个及以上参数交互的缺陷占比低，因此 2-way 覆盖能发现绝大多数组合缺陷，是"覆盖与成本"的最优平衡点。

Pairwise 的数学基础是"对任意两参数的组合全覆盖"，它建立在"缺陷多为 1-way/2-way 交互"的经验规律上。它牺牲了 3-way 及以上组合的覆盖，换取用例数从指数级降到平方级。理解"所有参数对的覆盖"这一原理，是掌握 Pairwise 的关键。

• 各 Pairwise 工具的特点
• 开源/商业、约束支持、扩展性
• 工程选型

各 Pairwise 工具在工程上各有取舍：PICT（Microsoft）是开源命令行工具，支持约束（If/Then）、种子、权重，生成速度快、社区成熟，是业界最常用的免费首选；jenny 是简单开源工具，支持生成与约束，但功能较简；BREW 是开源工具，支持 t-way、约束与种子，灵活但文档少；Hexawise 是商业 SaaS 工具，支持 t-way、约束、权重、可视化与报告，适合团队协作但需付费；ACTS（NIST）是开源工具，支持 t-way、约束、支持 2~6-way 及混合强度，适合科研与工程。工程取舍依据：是否需要 t-way 扩展（3-way 以上选 ACTS/Hexawise）、是否需要复杂约束（PICT/ACTS 支持）、是否需商业支持与可视化（Hexawise）、成本与团队偏好。通常"免费优先选 PICT，需高 t-way 或科研选 ACTS，需协作可视化选 Hexawise"。

工具选型是"功能、成本、易用性"的权衡。PICT 以免费、约束强、成熟成为默认选择；ACTS 在 t-way 扩展与科研支持上更强；Hexawise 提供商业级协作与可视化。理解各工具能力侧重，才能按项目需求合理选择。

• t-wise 的含义
• t 增大时用例数的增长
• 工程边界

t-wise 组合测试要求"任意 t 个参数的所有取值组合"至少覆盖一次，其中 2-way 即 Pairwise，3-way 覆盖任意三个参数组合，4-way、6-way 依次类推。t 越大，覆盖的参数交互越多，缺陷发现能力越强，但用例数急剧增长——t-way 的用例数近似与参数取值数的 t 次方相关，t 增大导致用例数爆炸式上升。工程边界：经验表明绝大多数缺陷由 1-way 或 2-way 交互触发，3-way 交互缺陷占比明显下降，4-way 及以上缺陷很罕见。因此工程上通常默认 2-way；对安全关键/高风险交互或多参数强耦合场景升级到 3-way；4-way 及以上仅用于损害后果极严重、且具备足够测试资源的少数场景，否则成本失控。判据是"缺陷风险 × 用例成本"的平衡。

t-wise 的工程边界本质是"缺陷触发是低阶交互为主"这一经验规律。2-way 覆盖绝大多数缺陷且成本低，t 增大覆盖更全但成本指数增长且边际收益递减。工程上按"风险×成本"选择 t，避免盲目追求高阶 t 导致组合爆炸。

• CTM 的概念与提出者
• 分类树绘制
• 组合测试生成

Classification Tree Method（CTM，分类树法）由 Grochtmann 与 Grimm 提出，是一种把输入域按"分类（classification）与类别（class）"层级分解并组合生成测试用例的方法。绘制步骤：先确定系统的输入域，按独立维度划分出若干"分类"（如"文件类型""大小""权限"），每个分类下再划分互斥的"类别"（如文件类型下分"图片/文档/压缩包"），形成层级树；然后从每个分类中选取类别组合，组合时保证覆盖各分类的类别，生成测试用例。CTE（Classification Tree Editor）是该方法的工具实现，支持可视化编辑分类树并自动生成组合用例。组合测试在分类树基础上可用 Pairwise/正交表控制组合规模，也可用全组合。分类树的价值在于"层级化、结构化地梳理输入域，避免分类遗漏或重叠"。

CTM 的核心是"分类"与"类别"的层级分解：分类是独立的维度，类别是分类下互斥的取值。它把输入域结构化，便于识别遗漏与重叠，并支撑组合测试生成。CTE 工具让建模与生成本自动化。这是等价类与组合测试的融合方法。

• Covering Array 与 strength
• strength 与用例数的关系
• t-wise 覆盖率计算

Covering Array（覆盖数组）CA(N; t, k, v) 是组合测试的数学表示，其中 N 为用例数、t 为 strength（覆盖强度）、k 为参数个数、v 为参数取值数（假设各参数 v 个取值）。strength t 表示"任意 t 个参数的所有取值组合"都被覆盖。用例数 N 与 t 的关系：t 越大，N 越大；理论上 N 与 v^t 相关（近似 N ≥ v^t 的下界），实际 N 随 t 增大而显著增长，但远小于全组合 v^k。t-wise 覆盖率计算：对给定的用例集，枚举所有"任意 t 个参数的值组合"，统计"至少被一个用例覆盖的组合数/所有组合总数"即为 t-wise 覆盖率，如 2-way 覆盖率 = 已覆盖的参数对组合数 / 全部参数对组合数。覆盖率越高意味着 t 阶交互覆盖越完整，可通过工具（如 ACTS）验证生成的用例集是否达到目标 strength。

strength 是组合覆盖的"阶数"，决定覆盖的交互维度；用例数随 strength 增长但远小于全组合。t-wise 覆盖率是"量化验证"组合覆盖是否达标的度量，通过"已覆盖组合/总组合"计算。理解 strength 与用例数的数学关系，能正确选择 t 并评估覆盖完整性与成本。

• 禁止组合（constraint）的含义
• 约束在 Pairwise 生成中的处理
• 保证合规

Pairwise 中的 constraint（禁止组合）指某些参数取值组合在业务上不允许，如"浏览器=IE 且 系统=macOS"不可能。工程处理：在 Pairwise 工具（如 PICT/ACTS）中声明约束（如 If "浏览器" = "IE" Then "操作系统" <> "macOS"，或直接声明禁止组合），工具在生成用例时自动规避这些非法组合，保证生成的用例集"合规"——即不包含任何被禁止的组合。同时，工具会尽量保留原本应该覆盖的合法组合，用其他合法组合替代被禁止的组合，使覆盖损失最小化。测试者还需验证：生成的用例中确实不含禁止组合（约束校验），且被禁止组合的"防御行为"（如系统拒绝该组合）单独补充测试。约束处理是 Pairwise 工程化的关键，否则生成的用例会违反业务规则。

约束保证"生成的用例集在业务上合法"，是 Pairwise 从纯数学走向工程的关键。工具把约束作为生成时的硬限制，规避非法组合并尽量维持覆盖。处理重点是"正确声明约束 + 生成后校验合规 + 对禁止组合的防御行为单独补测"。

• 分类树与等价类/边界值的结合
• 从需求画分类树
• 映射到测试用例

分类树方法与等价类、边界值结合的实际流程：第一步，从需求识别输入域，按独立维度划分分类（classification），每个分类再划分互斥类别（class），画出分类树；第二步，对类别做等价类/边界值细化——对每个分类的类别，用等价类划分补充有效/无效类别，用边界值补充边界值类别（如大小分类下的"恰好上限/上限+1"）；第三步，从分类树映射到测试用例——从每个分类选取类别组合生成用例（用 pairwise/正交控制组合规模），对无效类别和边界值类别单独生成用例；第四步，验证覆盖——核对分类树是否完整覆盖需求（无遗漏、无重叠分类）。映射的要点是"分类树保证结构覆盖，等价类/边界值保证取值深度，组合保证交互覆盖"。

分类树是"结构骨架"，等价类/边界值是"取值细化"，组合是"交互覆盖"。三者结合：先用分类树梳理维度，再细化取值，最后组合生成。这避免"分类漏项"与"取值覆盖不足"，是等价类/边界值/组合三种方法的融合流程。

• 移动端兼容矩阵的组合爆炸
• Pairwise 选最小覆盖集
• 残留风险评估

移动端兼容测试涉及机型×OS×分辨率×浏览器等海量组合，全组合不可行。Pairwise 的应用：把机型、OS、分辨率、浏览器、网络等作为参数，列出各自取值，用 Pairwise 工具生成覆盖"任意两参数组合"的最小用例集，例如 100 机型×5 OS×10 分辨率×5 浏览器 的全组合达 25 万，Pairwise 可降到几百个用例。选最小覆盖集时，可用约束（如某机型只支持特定 OS）剔除不可能组合，用种子/权重保证关键机型与高风险组合被保留。残留风险评估：Pairwise 牺牲了 3-way 及以上组合的覆盖，需评估"未覆盖的高阶组合中，哪些可能承载缺陷"——通常通过历史缺陷数据分析特定交互（如 3-way 机型×OS×分辨率）是否高频，若存在则对其升级到 3-way 或针对性补测；同时用"覆盖报告"统计已覆盖的组合比例，量化残留风险。兼容回归在不同版本迭代时增量更新用例集。

移动端兼容矩阵是 Pairwise 的典型应用：海量组合用 2-way 降到可控，约束与种子保证合规与关键覆盖，残留风险通过"高阶组合分析 + 覆盖统计"评估。工程上"2-way 为主 + 关键 3-way 补强 + 覆盖报告量化"，在兼容覆盖面与成本间平衡。

• t-wise 覆盖度的量化
• Covering Array 验证
• strength 达标检查

t-wise 覆盖度的量化验证是通过"枚举并统计已覆盖的 t 组合"实现的。方法：对给定用例集，枚举所有"任意 t 个参数取值的组合"，逐一检查是否被至少一个用例覆盖，统计"已覆盖组合数 / 总组合数"，得到 t-way 覆盖率；若覆盖率为 100%（覆盖所有 t 组合），则用例集达到 strength t 的 Covering Array 要求。可用工具（如 ACTS、PICT）生成 Covering Array 结果或直接验证：把目标 strength（如 2-way 或 3-way）作为参数输入，工具会校验当前用例集是否覆盖全部 t 组合并报告缺失组合。若生成了更高 strength 的覆盖数组，则自然满足低 strength。验证要点：明确 t 值、核对参数与取值集合一致、检查是否存在未覆盖的 t 组合并补充用例，直到覆盖率达标。

t-wise 覆盖度验证的核心是"覆盖率 = 已覆盖 t 组合 / 总 t 组合"，用工具枚举比对可精确验证 strength 是否达标。这是"量化覆盖"的关键——避免凭感觉认为覆盖充分，而是用数学可验证的方式确认。工程上生成后必须验证 strength，否则可能覆盖不足。

• 参数划分原则
• 等价类取值 vs 组合参与
• 降低用例量

组合测试与等价类/边界值的分工是：等价类/边界值负责"单参数取值空间的压缩"，组合测试负责"参数间交互的覆盖"。分工原则：对"取值空间大、但各取值间交互影响小"的参数，用等价类/边界值选少数代表值（如金额、日期、文本长度的取值），不必全量参与组合；对"取值空间小、且与其他参数交互影响大"的参数（如操作系统、浏览器、支付方式、状态），用全部取值参与组合测试。划分方法：先按风险与业务判断每个参数是"取值敏感"还是"交互敏感"，取值敏感者用等价类/边界值收敛为少数代表值，交互敏感者全取值参与组合，再用 Pairwise 生成组合用例。这样既保证单参数取值被覆盖，又保证关键交互被覆盖，同时把用例量降到最低。工程上"等价类/边界值压缩取值 + Pairwise 覆盖交互"是标准结合模式。

分工的本质是"把每个参数按敏感维度分流"：取值敏感的参数用等价类/边界值压缩，交互敏感的参数用组合覆盖。这避免了"所有参数都全取值参与组合"导致的爆炸，也避免了"所有参数都用代表值"导致的交互漏测。合理分流是降低用例量的关键。

• 分类与类别的提取原则
• 独立分类与互斥类别
• 过细/重叠/遗漏的规避

分类树中，分类（classification）是"独立的输入维度"，类别（class）是"分类下互斥的取值"。提取原则：第一，分类独立性——每个分类代表一个独立的维度，分类之间不重叠（如"文件类型"与"文件大小"是独立维度）；第二，类别互斥性——同一分类下的类别之间互斥且穷尽（每个输入恰好落入一个类别，如"文件类型"下"图片/文档/压缩包"互斥且覆盖全部）；第三，与需求对齐——分类从需求的实际输入维度提取，避免引入与业务无关的维度。避免问题的原则：分类过细（把本可合并的维度拆散）会徒增成本，应合并同类维度；分类重叠会导致同一输入归属多个分类，应保证维度独立；分类遗漏会漏测，应系统核对需求的所有输入维度。实践上用"分类树层级呈现 + 需求核对清单"验证无遗漏、无重叠、粒度适中。

分类树的质量取决于"分类独立、类别互斥、粒度适中"。独立与互斥保证结构清晰、无歧义，粒度适中保证成本可控，需求对齐保证无遗漏。规避过细/重叠/遗漏的关键是"以需求维度为准、用清单核对、用互斥性自检"。

• 增量维护的意义
• 新增参数/取值时的扩展
• 既有覆盖的保持

组合测试的增量维护指在需求变更（新增参数或取值）时，只补充增量用例而不重跑全部用例。方法：新增参数时，工具（如 PICT 的"增量模式"）在保留原用例集的基础上，为"新参数 × 已有参数"的组合生成补充用例，使新增参数参与后仍满足 t-way 覆盖；新增取值时，为"新取值 × 其他参数"的组合补充用例。关键在于"增量生成"不破坏既有覆盖：新生成的用例补充到原用例集后，要校验"原有参数对的覆盖仍满足"（新用例不覆盖旧组合部分，但旧用例已覆盖），并验证整体用例集仍满足目标 strength。操作上：保留原用例集作为"种子"，增量生成时只添加"能覆盖新组合"的用例，避免重复与冗余，最后用覆盖验证工具确认整体 strength 达标。这样既控制回归成本，又保证覆盖不退化。

增量维护的核心是"把原用例集作为种子，只补新增组合"而非全量重算。这利用"增量生成"特性，避免需求变更导致的大规模回归。关键是"增量后整体 strength 仍达标"的校验——新增用例不破坏既有覆盖，只填补新组合空白。这是组合测试在持续演进项目中的落地要点。

• 两者的原理与关系
• 差异点
• 工程选型

Pairwise 与正交数组测试（OAT）都用于"从全组合中选代表性用例"，但有所区别。原理上，Pairwise 要求"任意两参数的所有取值组合都覆盖"（2-way 覆盖），正交数组（OA）要求"任意两因子的各水平组合出现次数相等"（均衡性/正交性），正交数组的覆盖更强（元素数量均衡）且支持 t-way 扩展。关系上，正交数组是 Pairwise 的一种"更均衡"的实现形式，Pairwise 生成的用例集未必满足正交均衡性，但两者都保证两两覆盖。工程对比：正交数组结构规整、均衡性好、适合水平数相同或相近的场景，但存在"水平数不等时选表困难、用例数可能略多"的局限；Pairwise 更灵活（支持水平数不等、约束、种子、权重）、用例数通常更少、工具支持好（PICT/ACTS），适合大多数工程场景。选型上：追求严格均衡/实验设计用正交数组，求灵活高效用 Pairwise（业界默认）。

Pairwise 与 OAT 的核心差异是"是否要求均衡性"：OAT 更严格（元素均衡），Pairwise 更灵活（只要求覆盖）。工程上因 Pairwise 灵活、工具成熟、用例更少而成为默认，OAT 在均衡性要求高的场景仍有价值。理解差异便于按场景选型。

• 组合覆盖的数学基础
• 用例数减少的原理
• 覆盖与成本的关系

Pairwise 的数学基础是"组合覆盖"与"经验缺陷分布"的结合。全组合测试用例数为各参数取值数的乘积（v1×v2×…×vk），随参数数指数增长；Pairwise 只要求"任意两参数的所有取值组合"被覆盖，其用例数理论上界约为最大参数取值数 × 参数个数（如 v² 量级），远小于全组合。用 Covering Array 表示，CA(N; 2, k, v) 的 N 远小于 v^k。为什么有效：经验研究表明，缺陷多为单参数（1-way）或两参数交互（2-way）触发，3-way 及以上交互缺陷占比很低，因此用 2-way 覆盖能发现绝大多数组合缺陷，同时用例数从指数级降到平方级。数学上，Pairwise 通过"覆盖所有参数对"而非"覆盖所有参数组合"，把"组合爆炸"转化为"约线性/平方增长"，实现覆盖与成本的最优平衡。

Pairwise 减少用例数的数学根源是"从全组合（v^k）降为参数对覆盖（约 v²）"，这建立在"缺陷聚于低阶交互"的经验规律上。理解"覆盖参数对而非全组合"这一数学本质，就理解了 Pairwise 为何有效且高效。

• CTE 与 Pairwise 的特点
• 多系统测试的维度
• 工程取舍

多系统测试（multi-system testing）涉及多个系统/组件/平台作为参数维度（如"系统A版本×系统B版本×平台×协议"），组合爆炸显著。CTE（分类树编辑工具）以"分类树+类别"结构化建模，视觉化、易梳理各系统维度，适合"维度多、需要清晰展示与团队沟通"的场景，且能结合等价类/边界值细化；Pairwise 以"矩阵+约束"高效生成最小覆盖集，适合"重点关注两两交互覆盖、用例数要最小"的场景。工程取舍：若多系统间的交互以两两为主、追求最小用例数，用 Pairwise 更高效；若需清晰展示各系统维度、便于评审与对接业务、或维度结构复杂，用 CTE 更直观。实践中常结合：用 CTE 建模多系统维度并细化取值，再用 Pairwise 生成组合用例，兼顾可视化与效率。

CTE 强在"可视化建模与沟通"，Pairwise 强在"高效组合生成"。多系统测试维度多、组合爆炸，常用"CTE 建模 + Pairwise 生成"的组合，用 CTE 理清维度、用 Pairwise 压规模。取舍依据是"是否强调可视化/沟通"与"是否追求最小用例数"。

• 缺陷发现能力的评估维度
• 覆盖率与交互缺陷
• 实证方法

组合测试的缺陷发现能力评估可从几方面进行：一是交互缺陷覆盖——统计 t-way 覆盖率（已覆盖 t 组合/总 t 组合），覆盖率越高，潜在的高阶交互缺陷被覆盖的可能性越大；二是历史缺陷回归——把历史缺陷与组合测试生成的用例对照，检查"历史缺陷是否由已覆盖的组合触发"，若历史缺陷集中在未覆盖的组合，说明需要提升 t 或补充用例；三是缺陷注入/变异测试——人为注入组合相关的缺陷（如某参数对组合下的错误行为），验证组合测试能否发现，评估检出率；四是与全组合对比——在可承受范围内，比较 Pairwise 与全组合在缺陷发现上的差距，量化"牺牲的高阶组合"实际漏检了多少缺陷。经验表明，Pairwise 能发现绝大多数组合缺陷，但存在"高阶交互缺陷漏检"的固有局限，评估重点是"确认 2-way 覆盖充分 + 识别需要 3-way 补强的关键交互区域"。

组合测试缺陷发现能力的评估是"覆盖度量 + 实证验证"的结合：用 t-way 覆盖率量化覆盖广度，用历史缺陷/变异测试验证检出率，用全组合对比衡量牺牲。评估结果用于指导"是否提升 t 值、补充关键交互用例"，是组合测试质量保障的关键。

• 约束求解在 pairwise 的角色
• 禁止组合的声明
• 生成合规保证

约束求解在 pairwise 生成中的角色是"把业务规则转化为生成时的硬约束，保证生成的用例集不违反任何业务限制"。声明禁止组合的方式：在工具（如 PICT/ACTS）中用声明式约束表达，如 PICT 的"If 浏览器 = IE Then 操作系统 <> macOS"（条件约束），或直接列出禁止组合对；工具内部的约束求解器在选择参数组合时，会自动排除违反约束的组合，并尽量用其他合法组合替代被禁止的组合，以维持覆盖。保证合规的步骤：正确声明约束 → 工具生成时规避 → 生成后校验（核对用例集不含禁止组合）→ 对禁止组合本身，单独补充"防御测试"（验证系统拒绝该组合）。约束求解的价值在于让"生成的用例"在业务上合法，避免把非法组合作为测试输入。

约束求解是 Pairwise 从"纯数学"走向"工程可用"的关键一环：它把"哪些组合不能测"硬编码进生成过程，保证用例合规。声明方式（If-Then 或直接禁止）与生成后校验是保证合规的双保险。对禁止组合的防御行为需单独补测。

• 种子用例的作用
• 权重的作用
• 关键组合的保留

种子用例（seed）是"预先指定的、必须保留的用例"，pairwise 生成时会把种子用例作为生成结果的一部分，再补充其他用例以满足覆盖，从而保证"业务指定必须测的组合"一定被包含、不被优化算法丢弃。权重（weight）用于指定"某些取值/组合的优先级"，权重高的值组合被优先覆盖，权重低的组合可能被延后或覆盖较少，使生成结果向关键取值倾斜。为保证业务关键组合不被丢弃：把关键组合（如高风险、高频、头条目）作为种子用例显式加入；对关键取值设高权重，让生成算法优先覆盖；生成后校验关键组合是否都出现在结果中，缺失则补充。这样既利用 Pairwise 压缩用例数，又保证业务关键组合的覆盖不受影响。

种子与权重是 Pairwise 的"人为干预"手段：种子保证"必须测的组合"强制保留，权重引导"关键取值"优先覆盖。二者防止优化算法为了"最小化用例数"而把业务关键组合优化掉。工程上"关键组合用种子强制保留 + 关键取值用权重提优先 + 生成后校验"是保证业务覆盖不被牺牲的标准做法。