PICT组合测试实战：成对覆盖压缩配置矩阵用例

组合测试这个词，很多做过客户端、做过配置后台的人都听过，但真正把工具用起来的比例并不高。我见过太多团队的用例表：四五个配置项一列，全组合铺开，几百条用例里有一半是重复的手工复制粘贴，跑一轮回归要两天，最后发现漏掉的恰恰是某个"看起来不可能出现"的交叉组合。PICT 就是专门干这件事的——你给它一个参数和取值的模型文件，它吐出一组覆盖面足够、条数极少的测试用例组合。这篇内容我按照自己这几年用它做配置矩阵、兼容性矩阵、接口参数组合的实际过程来写，从建模思路、语法细节、约束写法，到生成结果怎么接回测试流程，还有几个我踩过、当时排查了半天才发现原因的坑，都会讲到。适合两类人看：一类是手上正被"组合爆炸"按在地上摩擦的测试同学，另一类是想给自己项目的配置组合找一套可复现、可版本化管理方案的技术负责人。不需要你有很深的数学背景，但需要你愿意动动手跑几遍命令。

1. 参数一多，用例数就像滚雪球：PICT 切入的那个具体痛点

先说清楚它解决的是什么问题，不然很容易把它当成"随机抽几条用例的工具"，那就完全跑偏了。

1.1 一个五个下拉框的真实组合场景

举个我自己项目里的例子。某图像导出模块，界面上有五个可选项：平台、架构、导出格式、透明通道策略、目标分辨率。每个下拉框三个选项，看着平平无奇。但产品经理一句"这些配置要保证都能正常导出"，测试同学就要面对 3×3×3×3×3 = 243 种组合。243 条用例，一条跑三十秒，光这一个模块就是两个多小时，还不算准备素材和记录结果的时间。

更麻烦的是维护成本。配置文件改一个默认值，243 条用例的表要跟着改，改完还要重新人工核对一遍有没有漏。时间一长，这张表就没人敢动了，最后变成"上线前挑几条眼熟的跑一下"，覆盖率全靠感觉。这不是执行力问题，是方法问题——用全组合的方式去覆盖多维参数空间，成本是指数级的，而收益是线性的。

PICT 的思路很直接：不去覆盖所有组合，只保证任意两个参数之间的所有取值组合都至少出现一次。这个目标在数学上叫"成对覆盖"（pairwise coverage），也叫二阶组合覆盖。它是"用最少的用例数拿到最高性价比缺陷发现率"这个命题下，工程界公认的一个折中点。

1.2 成对覆盖能砍掉多少用例：算一遍就明白

很多人第一次看到生成结果是不信的——243 种组合，工具只给了 10 条左右。这里得把账算明白，不然你没法跟团队解释为什么这么测。

假设有 k 个参数，每个参数 v 个取值。全组合是 v 的 k 次方。而任意两个参数构成一个"参数对"，这样的参数对一共有 C(k,2) 个，每个参数对有 v² 种取值组合。要全覆盖这些参数对，需要覆盖 C(k,2) × v² 个"对"。每条测试用例本身包含了 C(k,2) 个参数对（因为它在这 k 个参数上各取了一个值）。所以理论下界是：

用例数 ≥ (C(k,2) × v²) / C(k,2) = v²

也就是说，成对覆盖的理论下界只跟单个参数的取值数有关，跟参数个数几乎无关。5 个参数各 3 值，下界是 9 条；10 个参数各 3 值，下界还是 9 条。参数越多，成对覆盖相对全组合的压缩比越夸张。实际生成的条数会比下界多一些，因为贪心算法很难每次都凑到完美，另外约束也会打破一部分可组合性。

下面这张表是我在自己项目里实测的大致区间，供你建立数量级的直觉：

看到这个数量级，你应该能理解为什么它值得花半天时间学。但这里必须泼一盆冷水：成对覆盖不是万能的。它发现的是"两个参数互相影响"这一类缺陷，而三个参数同时才触发的缺陷（比如"只有 Linux + ARM64 + 4K 这个组合才有问题"）它可能覆盖不到。所以我的做法是：成对覆盖作为配置矩阵的基线防护网，三阶覆盖或者定向补充留给高风险模块，PICT 的/o:3就是干这个的，后面会讲。

1.3 PICT 的输入输出到底是什么样子

把它的工作方式说清楚，你就不会对它有不切实际的期待。PICT 是一个命令行程序，不进 GUI、不连数据库、不生成测试脚本。它的全部工作就是一个转换：

• 输入：一个纯文本的模型文件，里面写清楚有哪些参数、每个参数有哪些取值、哪些取值组合是非法的不需要测。
• 输出：一张表格（默认制表符分隔），每一行是一条测试用例，每一列是一个参数的取值。

它最早由一家大型软件公司的工程团队在内部孵化，后来对外免费发布，一直是个单文件的可执行程序，没有依赖、没有运行时、不需要装环境。这个特点在真实工作里价值很大——你可以把它塞进 CI 流水线，也可以把它拷到一台没有网络的测试机上用。正因为格式简单，模型文件天然适合放进版本管理，改了什么、为什么改，走一次代码评审就记录下来了。这一点比 Excel 用例表强太多，Excel 的 diff 基本没法看。

另外要说明一个定位问题：PICT 生成的是"参数组合"，不是"操作步骤"。它不会告诉你先点哪个按钮、后填哪个字段。它解决的是"这些配置项怎么搭配着测"，业务流的顺序、状态迁移、异常注入，还得靠你另外设计。搞清楚这个边界，用起来才不会拧巴。

2. 从零跑通第一个模型：环境、语法和第一次输出

这一节是纯操作，跟着做一遍，十分钟内你应该能看到第一份结果。

2.1 把可执行文件放进 PATH 这件事为什么值得做

PICT 是单文件程序，Windows 下是pict.exe，拿到之后可以直接双击运行——但双击只会弹一个窗口瞬间关掉，因为它是纯命令行工具，没有参数时不会做任何有意义的事。正确的做法是把它所在目录加进系统环境变量PATH，或者干脆把 exe 丢进C:\Windows这类已经在 PATH 里的目录（不推荐，容易被清理工具误删）。

放进 PATH 的好处不只是省得敲全路径。你后面大概率会写批处理脚本、CI 步骤、Makefile，这些地方如果用绝对路径，换一台机器就全废了；用pict这个命令名，脚本可以跟着仓库走。我自己的习惯是在项目里建一个tools/目录放二进制，然后在脚本里用相对于仓库根目录的路径调用，这样整个测试工程克隆下来就能跑，不依赖个人机器配置。

如果你在非 Windows 环境，需要拿到源码自己构建一个二进制。这一步对熟悉 C++ 工具链的人来说不复杂，几分钟的事；如果本地没有完整的编译环境，建议直接在现有的 Windows 机器上跑，把模型文件和输出结果同步过去就行——因为这个工具的工作量小得可以忽略，没必要为了它去折腾一套编译环境。

验证是否装好，直接敲：

pict /h

能打印出帮助信息，说明可执行文件正常。这个帮助页建议完整看一遍，选项不多，但每个都挺有用，后面我会挑几个高频的讲。

2.2 模型文件的三段式结构

模型文件就是个.txt，我一般命名成export-config.txt这种能看出业务含义的名字。它的结构可以理解为三段，虽然语法上不强制分区：

第一段是参数定义，每行一个参数，格式是参数名: 值1, 值2, 值3。冒号是分隔符，后面用逗号列出所有取值。参数名和值都不需要加引号（除非值里有特殊字符），行首#开头是注释，空行会被忽略。

第二段是约束，用IF ... THEN ...;的形式描述"哪些组合不成立"。这一段是可选的，但真实业务里几乎总是需要——总有一些组合在物理上或业务上没意义，比如"JPG 格式下开透明通道"。

第三段是子模型和权重，属于进阶内容，第一版可以先不写。

下面是我实际用的一个模型文件，你可以直接抄下来跑：

# # 导出功能配置模型 # 参数：平台 / 架构 / 格式 / 透明通道 / 目标分辨率 # 平台: Windows, macOS, Linux 架构: x64, ARM64 格式: PNG, JPG, WebP 透明通道: 支持, 不支持, 自动 目标分辨率: 720p, 1080p, 4K # ---- 约束区 ---- # JPG 不支持透明通道 IF [格式] = "JPG" THEN [透明通道] <> "支持"; # Linux + ARM64 目前不支持 4K 输出 IF [平台] = "Linux" AND [架构] = "ARM64" THEN [目标分辨率] <> "4K";

几个语法细节值得单独说一下，因为新手最容易在这上面卡住：

参数名和取值里如果出现空格，必须用双引号包起来，比如操作系统: "Windows 11", "Windows 10", Linux。不加引号的话，PICT 会把空格后面的部分当成别的东西，报错信息还不一定直观。

约束里的参数名必须用方括号包起来，[平台]，不能直接写平台。取值必须加双引号，"JPG"。这两条是硬性要求，少一个就是语法错误。

每一行约束必须以分号结尾，包括最后一条。忘了分号，PICT 会把下一行当成这一行的延续，报出来的错会指向一个莫名其妙的位置。

2.3 第一次执行与结果解读

保存好文件，在同一个目录下执行：

pict export-config.txt

屏幕上会直接打出制表符分隔的表格，长这样（具体内容每次可能略有不同，因为默认行为是确定性的，但只要模型改了就变）：

平台 架构 格式 透明通道 目标分辨率 Windows x64 JPG 不支持 1080p Windows ARM64 PNG 支持 720p macOS x64 WebP 自动 4K Linux ARM64 PNG 不支持 1080p macOS ARM64 JPG 自动 720p Linux x64 WebP 支持 4K Windows x64 PNG 自动 720p Linux x64 JPG 支持 1080p macOS x64 PNG 不支持 4K

第一行是参数名（表头），后面每一行是一条用例。五列对应五个参数，顺序和模型文件里的声明顺序一致。

我建议第一次跑的时候顺手加上/s，它会额外打印一行统计：

pict export-config.txt /s

输出末尾会多出类似这样的信息：

Combinations: 243 Generated tests: 10 Generation time: 0:00:00

Combinations是模型在应用约束之后的有效全组合数，Generated tests是实际生成的用例数。这个数字非常关键——它是你做"这次覆盖是否合理"判断的第一手依据。如果Generated tests突然变成了几百条，那基本可以确定模型写错了，八成是某个参数的取值被意外拆成了好多个。

把结果重定向到文件，就是最常见的用法：

pict export-config.txt /s > cases.tsv

注意/s的统计信息默认是输出到标准错误流的，所以上面这条命令里cases.tsv只会包含表格，统计信息会打在屏幕上。如果你想把统计也存进去，用2>&1合并一下就行。

3. 约束表达式：PICT 真正拉开差距的地方

第一版模型跑通之后，绝大多数人卡住的下一步都是约束——想表达"这两个值不能同时出现"，写了一堆，结果要么报错，要么生成结果里全是非法组合。这一节把约束的写法讲透。

3.1 IF-THEN 的四种等价写法与选型

约束的核心就一句话：当某个条件成立时，另一个参数的取值必须被限制在某个范围内。同样的语义，PICT 允许好几种写法，选哪种主要看可读性和后续维护。

最直白的是排除法，用不等号：

IF [格式] = "JPG" THEN [透明通道] <> "支持";

读起来就是"如果是 JPG，那透明通道不能是『支持』"。这种写法适合"只排除一个取值"的场景。

第二种是限定法，用等号把取值锁死：

IF [平台] = "Linux" AND [架构] = "ARM64" THEN [目标分辨率] = "720p";

这是"在这个前提下只能是这个值"。注意它和排除法的区别：排除法是"不能是 X"，限定法是"必须是 Y"。如果你的业务规则是"ARM64 上只测 720p"，用限定法表达最准确，因为它顺带把 1080p 和 4K 都排掉了，但语义上更清晰，后续改规则也好改。

第三种是 ELSE 分支：

IF [格式] = "JPG" THEN [透明通道] = "不支持" ELSE [透明通道] <> "不支持";

这条的意思是"JPG 必须不支持透明通道，非 JPG 必须不是『不支持』"。ELSE 在处理二值互斥关系时特别顺手，一条顶两条。

第四种是值集合写法，用IN：

IF [架构] = "ARM64" THEN [格式] IN {"PNG", "WebP"};

这是"限定在某个集合里"，比写两个 OR 干净得多。格式支持IN {值1, 值2, ...}，取值一样要加引号，集合用花括号包起来，元素之间用逗号分隔。

我在实际项目里的选型习惯是：能用 IN 就不用多个 OR，能用 ELSE 就不用两条互斥的 IF。原因很简单，模型文件是会被人读的，尤其是新同事接手或者做评审的时候，一条约束能在一行里读完，比拆成三条好理解得多。

3.2 值集合运算：LIKE 与否定条件

除了精确匹配，PICT 还有一个很多人不知道的LIKE，支持通配。它在参数取值有命名规律的时候特别好用，比如你有一堆错误码、一堆机型编号：

IF [平台] LIKE "Windows%" THEN [架构] = "x64";

%是通配符，Windows%能匹配Windows 10、Windows 11、Windows Server这类所有以 Windows 开头的取值。用一个 LIKE 就把一整类平台都管住了，不用每加一个新版本就去补一条约束。这在长期维护的项目里省事非常多。

否定条件用NOT，可以包在条件前面，也可以包在单个表达式前面：

IF NOT ([格式] = "JPG") THEN [透明通道] <> "自动";

注意运算符优先级。AND的优先级高于OR，NOT最高。跟写代码一样，混用的时候一定要加括号，别指望读者（包括三个月后的你自己）记得优先级表。我见过一条写了三个 AND 两个 OR 的约束，当时觉得对，后来改需求时谁也不敢动，最后整条重写了。

另外提醒一个容易误会的点：约束只能引用已经定义的参数和已经存在的取值。写THEN [透明通道] = "半透明"，但"半透明"不在透明通道的取值列表里，PICT 会直接报错。它的逻辑是"从已有取值里筛掉不符合约束的"，不会帮你凭空造一个值出来。

3.3 约束写矛盾了会怎样：一个真实的排查过程

这是我认为最值得单独讲的一段，因为它的表现非常隐蔽，我当时排查了快一个小时。

有一次我给一个接口参数建模，六个参数，写了七八条约束。跑出来的结果是Combinations: 36、Generated tests: 36——全组合等于生成数，说明成对覆盖完全没起作用。而正常情况应该是几十条全部组合、生成十几条。当时我第一反应是 PICT 坏了，重装了一遍，还是一样。

排查过程是这样的：

第一步，先看模型有没有语法错误。PICT 对语法错误的报错还算明确，会指出哪一行有问题，这里没报错，说明语法层面是通的。

第二步，把所有约束注释掉重跑。结果生成数从 36 掉到了 14，正常了。说明问题确实出在约束里。

第三步，把约束一条一条加回去，每加一条跑一次。加到第三条的时候，生成数突然跳到和全组合相等。定位到那条约束是：

IF [重试策略] = "指数退避" THEN [超时时间] = "长"; IF [重试策略] = "指数退避" THEN [超时时间] = "短";

两条约束的意图是"指数退避策略下，长超时和短超时这两种情况都要覆盖到"，但我把它们都写成了 IF-THEN 的强制限定——这在逻辑上等价于"如果是指数退避，超时时间必须同时是长和短"，也就是这个组合被彻底排除了。PICT 处理得很宽容，它不报"约束冲突"，只是把这一整块组合从可能空间里剔掉了，剩下的组合自然退化成全组合。

正确的写法是压根不该写这两条约束。如果我是想表达"指数退避策略要重点测长超时和短超时两种情况"，那应该用权重，而不是约束。约束管的是"不可能"和"不允许"，权重管的是"多测几遍"，这两个概念混淆是新手最常见的错误之一。

这个经历给我的教训很直接：约束的数量和生成用例数是有联动关系的，每次改约束都要看一眼/s的统计。如果Generated tests接近Combinations，八成是约束把取值空间压得太小了，需要退回去逐条检查。我现在养成一个习惯，模型文件里每加一条约束，就在同一行上面写一行注释说明"为什么这条约束成立"，业务上站不住脚的约束，写不出注释，也就写不出来了。

4. 权重、子模型与种子文件：进阶用法

到这一步，基础的模型已经能跑出可用的结果了。但真实项目里总有几个参数你更关心，或者某几个参数之间必须覆盖到三阶组合，这时候就要动用 PICT 的进阶特性。

4.1 权重不是"优先级"，是出现频率

权重写在取值后面，用小括号包起来，格式是值(权重)：

平台: Windows(10), macOS(5), Linux(1);

这段的意思是：Windows 的出现频率大约是 Linux 的 10 倍，macOS 是 5 倍。默认权重是 1（不写就是 1）。

很多人第一次看到这个语法会理解成"优先级"或者"重要程度"，这不完全对。权重的准确含义是该取值在生成结果中出现的相对频率。它不是排序，不会让 Windows 永远排第一行；它是频次控制，Windows 会在 10 条用例里出现七八次，Linux 可能只出现一两次。

这个特性在什么场景下有用？想想你真实的用户分布：绝大部分用户在 Windows 上，Linux 只是个位数的比例。这时候如果生成 10 条用例，五种平台平分两条，等于把测试资源平均分配给了重要性完全不同的场景。用权重把主流场景的比例抬上来，生成的用例分布就更贴近真实的风险分布。

我的经验值是：不要给差异超过 10 倍的权重。超过这个量级，权重低的那几个取值可能在某些用例里一次都不出现，成对覆盖的效果就被破坏了。另外权重只影响同一参数内部的取值分布，不影响不同参数之间的组合覆盖保证——这一点别搞混。

调整完权重记得看一眼生成数，权重设置极端的情况下，PICT 为了满足覆盖保证，总条数可能会上升。这不是 bug，是它在额外补充用例去覆盖那些低频取值。

4.2 子模型拆解：让关键参数对获得更高阶覆盖

前面说过，成对覆盖只能保证两个参数之间的组合，三参数同时触发的缺陷可能漏掉。而全模型上三阶覆盖（/o:3）的代价是巨大的——尤其参数多的时候，生成数可能几百条，不现实。

PICT 给的折中方案是子模型：你可以把模型拆成几块，每块单独指定覆盖阶数，最后合并生成结果。

语法是这样的：

# 子模型定义，放在参数定义之后 { 格式, 透明通道, 目标分辨率 } @ 3 { 平台, 架构 } @ 2

花括号里列出这个子模型包含的参数，@后面是覆盖阶数。三个参数@ 3就是完全覆盖这三个参数的所有组合（3×3×3=27 种，生成数会相应增加），两个参数@ 2就是成对。

这个特性的价值在于把有限的用例预算花在刀刃上。比如导出格式、透明通道、分辨率这三个参数在代码里走的是同一条编码管线，互相影响很大，那就给它们三阶覆盖；而平台和架构主要是编译期决定的，成对就够。这样整体用例数量可控，重点区域的覆盖深度上去了。

用子模型的时候有几点要注意。一是多个子模型之间用|分隔，写在一行里：{ A, B } @ 3 | { C, D } @ 2。二是子模型的参数不能重复出现在不同子模型里，否则会报错。三是没有出现在任何子模型里的参数，仍然会被全模型级别的成对覆盖管着，不会被忽略掉——这一点很多人会担心，其实不用。

还有一个命令行选项/n是配合子模型用的，控制多个子模型生成结果怎么合并。它的取值语义在不同版本上有细微差别，我不建议凭记忆硬写，直接用pict /h看一眼当前版本的说明，再决定要不要调。默认行为在大多数场景下是够用的。

4.3 种子文件让回归用例不漂移

这个特性是我觉得最被低估的，讲清楚它能省你很多麻烦。

先说问题。PICT 的生成算法是确定性的——同样的模型文件，同样的参数，每次跑出来的用例完全相同。这本来是好事。但如果你改了一点点模型（比如给某个参数加了一个新取值），重新生成的用例会整体重排，跟上一版的用例对不上号。这时候你的自动化脚本里写死的用例编号全乱了，历史缺陷关联也断了。

PICT 的/e:选项就是解决这个的，它接受一个"种子文件"，里面放一批你希望优先保留的用例：

pict model.txt /e:existing-cases.tsv > new-cases.tsv

PICT 会先把你给的这些用例原样纳入结果集，然后在此基础上补充新用例去满足剩余的覆盖要求。也就是说，老用例不会被改写，只会在后面追加新的。

这个机制在什么场景下必用？我觉得有两个：一是回归测试集需要保持稳定，不能每次发版都换一套用例；二是你想把上一轮发现缺陷的那些组合固化下来，确保它们永远在测试集里。我的做法是每轮回归结束后，把出过问题的用例挑出来追加进种子文件，这个文件就成了一个"重点组合库"，越跑越厚，但每次生成的总数不会失控——因为 PICT 会识别哪些覆盖已经被满足了，不重复生成。

种子文件的格式和输出格式一致，就是制表符分隔的表格，第一行是参数名。这意味你可以直接把上一次的输出存下来当种子用，格式天然兼容。

5. 生成结果落回测试流程的几个实际问题

生成出表格只是第一步，真正决定这套方法能不能在团队里活下去的，是后面这些落地细节。

5.1 输出格式、分隔符与表格软件的兼容

默认输出是制表符分隔，粘进 Excel 或者表格软件通常能自动分列，但有两种情况会翻车：一是取值里本身带制表符（少见但存在），二是你的表格软件区域设置导致分隔符识别异常。

PICT 提供了/d:选项改分隔符：

pict model.txt /d:, > cases.csv

这样就输出逗号分隔的 CSV。但要注意，如果某个取值本身包含了逗号，输出会给这个值加双引号，符合 CSV 标准。这时候如果你的下游脚本是自己写split(",")来解析的，就会被这些带引号的字段搞乱。所以我的建议是：给下游程序用的输出，坚持用默认的制表符；给人看的表格，才转成 CSV。制表符出现在业务取值里的概率远低于逗号，安全性高很多。

另外一个小技巧：如果生成的用例要导入到测试管理平台，通常需要额外的字段（用例编号、优先级、执行人）。我一般是用一段简单的脚本在原表基础上加一列自增编号，而不是在 PICT 的输出上想办法。让工具只干它擅长的事，格式转换交给后处理。

5.2 用例编号与可追溯性：把模型当活文档

这一条是方法论层面的，比任何语法细节都重要。

组合测试生成的用例有个天然弱点：它是"算"出来的，不是"人写"的，所以看的人容易一头雾水——这行Linux / ARM64 / PNG / 不支持 / 1080p到底是什么业务含义？为什么会生成这么一条？

我的解决办法是把模型文件本身当成配置矩阵的活文档，放进代码仓库，跟业务代码一起走评审。模型文件里每个参数、每条约束都写清楚业务背景（用#注释），这样任何人打开文件就知道"哦，Linux + ARM64 不支持 4K 是因为某次架构调整"。用例编号则用"模型名 + 行号"的形式，比如EXPORT-007，行号对应生成结果的第 7 行。

这样做还有两个额外好处。一是产品、开发、测试可以对着同一个文件讨论，而不是各拿一份 Excel 互相版本对不上。二是模型变更会留下 diff，"这次为什么多了一条约束"，在提交记录里一目了然。我经历过一次线上问题回溯，靠的就是模型文件的提交历史，直接定位到哪次需求变更引入了一个不合理的约束，把某个组合从测试集里排除了。这种追溯能力，手工维护的用例表基本做不到。

还有一点：模型文件要跟版本号绑定。我习惯在文件头注释里写清楚这个模型对应哪个版本、最后修改人和日期。生成用例的时候，把这个版本号一起写进用例的备注字段。这样一份用例表拿出来，就知道它是基于哪一版业务规则算出来的，不会出现"用例是三个月前的，业务规则改了两轮"这种尴尬。

5.3 组合覆盖补不上什么：边界、时序与状态

必须明确说清楚 PICT 的能力边界，否则团队会对它产生错误的期待，用一阵子发现"怎么还有漏测"就把它否了。

它不测边界值。参数取值是离散的枚举，目标分辨率: 720p, 1080p, 4K这三条就是三个独立的值，它不会帮你生成"0p"、"分辨率上限 +1"这类边界用例。边界值要另外设计，跟组合覆盖是正交互补的关系，不是替代关系。

它不测时序。它生成的是一个静态的配置组合，不包含"先做 A 再做 B"的顺序信息。如果缺陷是"在导出过程中切换格式导致崩溃"，这属于时序问题，成对覆盖完全覆盖不到，得靠状态迁移测试或者人工场景设计。

它不测数据内容。参数值只表示"类别"，不代表"数据"。格式: PNG这条用例里用什么图片素材去测，它管不着。素材的多样性（超大图、损坏图、特殊色彩空间图）要另外补。

我的实际做法是把这三类内容做成独立的测试类别，跟组合用例并行存在，在测试计划里明确标注"这部分是组合覆盖不负责的"。这样既发挥了工具的长处，也不会让团队产生"用了工具就万事大吉"的错觉。说到底，工具只是把"参数搭配"这个维度的覆盖率从凭感觉变成了可计算，其他维度该怎么测还是怎么测。

6. 我踩过的几个坑与避坑清单

最后这部分是纯经验，都是我自己或者同事踩过的，写出来让你少走点弯路。

6.1 大小写、全角字符与看不见的空白

PICT 默认对大小写不敏感，也就是说Windows和windows在它眼里是同一个值。这个默认行为在大部分场景下是对的，但如果你有两个取值确实只靠大小写区分（比如某些标识符），就会出问题——它们会被合并成一个，然后你死活找不出为什么少了一个取值。这种场景加/c参数强制区分大小写。

比大小写更容易出事的是全角字符和不可见空白。我在一个中文项目里遇到过：约束里写的[平台] = "Linux"，但参数定义那一行的Linux后面跟了一个全角空格，结果约束怎么都不生效，也没有明确报错，只是生成结果里该排除的组合还在。后来用编辑器的"显示空白字符"功能才看出来。从那以后我养成了两个习惯：模型文件统一用 ASCII 字符写参数名和取值，中文只出现在#注释里；保存时确认文件编码是 UTF-8 无 BOM，因为带 BOM 的文件在某些环境下会导致第一行的参数名解析出错。

还有一个相关的坑：从 Excel 复制粘贴到模型文件。Excel 里的单元格经常带不可见的格式字符，粘过来肉眼看不出来，但解析会出问题。如果一定要从表格转过来，建议先粘到纯文本编辑器里过一遍，或者干脆手写。

6.2 参数顺序改变导致用例数变化

这是 PICT 的一个算法特性，不算 bug，但不知道的话会困惑很久：同样的一组参数，只调整它们在模型文件里的声明顺序，生成出来的用例条数和内容都会变，有时候条数会差好几条。

原因是它内部的贪心算法按参数顺序逐层处理组合，先处理的参数会影响后续的搭配选择，顺序不同，贪心的路径就不同，最终解的质量也不同——有的顺序能找到更紧的解，有的顺序会多出几条。

知道这一点之后，我的做法是：对生成条数敏感的项目，把参数按取值数量从多到少排列。实测下来这个顺序往往能得到更紧凑的结果，因为取值多的参数先固定下来，后面取值少的参数更容易被塞进已有的用例里，不需要额外开新行。这个规律不是绝对的，模型复杂的时候值得试两三种顺序，对比一下/s的输出，挑条数最少的那版。这也算是个白捡的优化。

另外，参数顺序会影响输出列的顺序，这一点在对接下游脚本时要注意。如果下游是按列索引取值的，改了模型顺序就得同步改脚本，否则会取错列，而且不会报错——这种静默错误排查起来很痛苦。所以我现在都要求下游脚本按列名取值，而不是按索引。

6.3 一份可以直接照着做的自查清单

每次模型写完之后，我会跑一遍下面这几项，基本能拦掉百分之九十的低级错误：

我现在基本形成了一套固定的工作流：先在纸上把参数和取值列出来，问清楚每个取值的业务含义（不经得起这个追问的取值，往往就是多余的），然后写模型，跑一遍看统计，调顺序和约束，最后生成结果、加编号、入种子文件。整个流程下来，一个中等复杂度的配置模块，从零到一份可用的用例集大概两三个小时。相比手工铺几百条用例再维护半年，这个投入是划算的。

踩过几次坑之后，我最大的体会是：这类生成工具的价值不在于"帮你省事"，而在于"逼你把参数空间想清楚"。很多时候写着写着就会发现，某个参数的两个取值在业务上其实是等价的，或者某两个参数的组合根本不可能是并存的——这些问题在手工写用例的时候会被淹没在几百行表格里，而在一个几十行的模型文件里，它藏不住。这个副作用，可能比工具本身生成的用例更有价值。后续如果团队规模再大一点，我会考虑把模型文件和需求文档做个自动化的关联检查，在需求评审阶段就把参数矩阵拉出来过一遍，那样就能把组合覆盖从测试阶段往前挪到设计阶段，效果应该会更好。