1. 为什么测试老手都在用正交表压缩用例做测试这行时间长了你会发现一个很尴尬的现象功能稍微复杂一点用例数量就爆炸。一个页面有5个下拉框每个下拉框4个选项全排列组合下来就是4的5次方1024条用例。真要把这些跑完别说一天一周都够呛而且大部分组合根本跑不出新问题。正交表就是来解决这个问题的。它的核心思路很朴素用最少的用例覆盖最多的两两组合。注意关键词是两两组合不是全组合。大量工程实践表明绝大多数缺陷是由单个因素或者两个因素相互作用触发的三个及以上因素同时作用才出问题的概率极低。所以只要保证任意两个因素的每一对取值组合都至少出现过一次就能用极少的用例抓住绝大部分问题。allpairs就是干这件事的工具。它读取你给的参数和取值自动生成一张正交表把用例数量压到原来的几分之一甚至几十分之一。我手上一个项目6个参数、每个参数3个取值全排列729条用allpairs跑出来只有十几条覆盖了所有两两组合。这个压缩比做测试的看了都会心动。这篇内容适合谁看如果你正在被组合爆炸的用例数量折磨或者听说过正交表但一直没搞明白怎么落地那这篇就是写给你的。我会从allpairs的获取、安装、参数文件怎么写、命令怎么跑、结果怎么读一路讲到实际项目里的踩坑经验。不堆理论全是能直接抄作业的操作。提示正交表不是万能的它适合多参数、多取值、缺陷以两两交互为主的场景。如果参数之间存在强依赖比如A选了某个值B就完全不能选正交表生成的结果需要人工二次筛选这一点后面会详细说。2. allpairs的获取与运行环境准备2.1 这个工具到底是什么来头allpairs最早是微软内部使用的一个小工具用来做组合测试的用例生成。它本身非常轻量核心就是一个可执行文件加一个参数文件没有图形界面纯命令行操作。也正因为如此它跨平台能力不错Windows上直接跑exeLinux和macOS上也有对应的版本或者可以通过兼容层运行。很多人第一次找allpairs会有点懵因为它不像那些商业测试工具有一个花哨的官网。它更像是一个传下来的老工具在测试圈子里靠口碑流传。你搜索的时候会看到各种下载站这里要提醒一句尽量从可信的渠道获取下载后先做基本的安全检查毕竟是要在本地执行的可执行文件。2.2 环境准备中最容易忽略的细节allpairs对运行环境的要求极低低到很多人反而忽略了几个关键点结果跑不起来。第一个细节是文件编码。allpairs读取参数文件时对编码比较敏感。如果你在Windows上用记事本编辑参数文件默认可能存成带BOM的UTF-8或者GBK工具读进去就可能出现乱码或者解析失败。我的习惯是统一用UTF-8无BOM格式保存编辑器用VS Code或者Notepad保存时明确选择编码。第二个细节是路径中不要有中文和空格。这个坑我踩过。当时把工具放在我的文档\测试工具\allpairs下面命令行一跑就报错折腾了半天才发现是路径里的中文和空格导致的。后来统一放到类似D:\tools\allpairs这种纯英文无空格的路径下问题消失。第三个细节是参数文件的行尾符。Windows是CRLFLinux是LF。如果你在Windows上编辑好文件拿到Linux上跑或者反过来偶尔会遇到解析异常。稳妥的做法是用编辑器把行尾符统一或者干脆在目标平台上重新保存一次。2.3 目录结构怎么组织我建议的目录结构是这样的allpairs/ ├── allpairs.exe # 可执行文件 ├── input/ # 存放参数文件 │ └── params.txt └── output/ # 存放生成结果 └── result.txt把输入和输出分开好处是批量跑多个参数文件时不会乱。命令里用相对路径或者绝对路径都行但路径分隔符要注意Windows用反斜杠Linux用正斜杠。注意如果你是在团队里推广这个工具建议把整个目录打包成一个压缩包附上一份简短的README说明编码和路径要求能省掉大量为什么我跑不起来的沟通成本。3. 参数文件的写法决定了结果质量3.1 参数文件的基本格式allpairs的参数文件是纯文本格式非常直观。第一行写参数名用逗号分隔从第二行开始每一行是一个参数的取值也是用逗号分隔。举个例子假设我们要测试一个登录功能涉及三个参数浏览器、用户名类型、密码类型。浏览器,用户名类型,密码类型 Chrome,正常用户,正确密码 Firefox,锁定用户,错误密码 Edge,不存在用户,空密码这里要注意第一行的参数个数必须和后面每一行的取值个数对应。上面这个例子第一行3个参数后面每行也是3个值一一对应。如果某一行少了一个值工具会报错或者生成错误的结果。3.2 取值顺序和参数顺序的门道很多人写参数文件很随意想到哪写到哪。但顺序其实有讲究。参数顺序方面建议把最重要的、最需要优先覆盖的参数放在前面。虽然正交表理论上会均匀覆盖所有两两组合但生成结果的顺序和参数顺序有关把核心参数放前面生成的用例读起来更符合直觉人工检查时也更容易发现遗漏。取值顺序方面建议把正常值、边界值、异常值交错排列而不是把所有的正常值堆在一起。这样生成的用例里正常和异常的搭配会更均匀。比如密码类型不要写成正确密码、正确密码、正确密码、错误密码而是正确密码、错误密码、空密码、超长密码这样交错。3.3 参数和取值的数量控制正交表的用例数量增长和参数个数、每个参数的取值个数都有关系。经验上参数个数每参数取值数全排列用例数正交表用例数约3327943819-125324312-156372915-184425616可以看到参数越多正交表的压缩效果越明显。但也不是参数越多越好如果参数超过10个生成的用例数也会上去而且人工维护参数文件的成本变高。我的建议是单次正交表测试控制在8个参数以内超过的话考虑拆分成多轮测试。3.4 一个真实项目的参数文件示例拿一个电商下单场景来说涉及参数用户等级、商品类型、支付方式、配送方式、优惠券状态。用户等级,商品类型,支付方式,配送方式,优惠券状态 普通会员,实物商品,在线支付,普通快递,无券 白银会员,虚拟商品,货到付款,次日达,满减券 黄金会员,预售商品,余额支付,自提,折扣券5个参数每个3个取值全排列243条。用allpairs跑一下大概能压到12条左右。这12条用例覆盖了任意两个参数的所有取值组合性价比极高。提示参数文件里的取值名称尽量用英文或拼音避免中文在命令行输出时出现编码问题。如果必须用中文确保文件编码和终端编码一致。4. 命令行实操从输入到生成结果4.1 基本命令格式allpairs的命令行用法很简单allpairs.exe params.txt result.txt或者指定输出文件allpairs.exe params.txt -o result.txt不同版本的参数可能略有差异用allpairs.exe -h或者allpairs.exe --help可以看帮助。我用的版本是直接支持重定向输出的所以第一种写法最常用。4.2 生成结果怎么读跑完之后result.txt里就是生成的正交表。格式和输入文件类似第一行是参数名后面每一行是一条用例。但会多出一列通常是Pairwise或者类似的标记列用来标识这条用例覆盖了哪些组合。一个典型的输出长这样用户等级,商品类型,支付方式,配送方式,优惠券状态,Pairwise 普通会员,实物商品,在线支付,普通快递,无券,... 白银会员,虚拟商品,货到付款,次日达,满减券,... 黄金会员,预售商品,余额支付,自提,折扣券,... ...最后那一列的内容比较长是工具内部用来记录覆盖情况的实际使用时可以忽略或者用脚本把这列删掉只保留前面的用例数据。4.3 验证覆盖率的实操方法生成结果后怎么确认它真的覆盖了所有两两组合靠人眼数是不现实的。我的做法是写一个小脚本把所有两两组合枚举出来然后逐条检查生成结果里是否都出现过。用Python写的话大概是这样import itertools # 读取参数文件 params {} with open(params.txt, r, encodingutf-8) as f: lines [line.strip() for line in f if line.strip()] names lines[0].split(,) for i, name in enumerate(names): params[name] [line.split(,)[i] for line in lines[1:]] # 枚举所有两两组合 all_pairs set() for p1, p2 in itertools.combinations(names, 2): for v1 in params[p1]: for v2 in params[p2]: all_pairs.add((p1, v1, p2, v2)) # 读取生成结果检查覆盖 covered set() with open(result.txt, r, encodingutf-8) as f: lines [line.strip() for line in f if line.strip()] for line in lines[1:]: values line.split(,) for p1, p2 in itertools.combinations(range(len(names)), 2): covered.add((names[p1], values[p1], names[p2], values[p2])) missing all_pairs - covered print(f总组合数: {len(all_pairs)}) print(f已覆盖: {len(covered all_pairs)}) print(f遗漏: {len(missing)}) if missing: for m in list(missing)[:10]: print(m)这个脚本跑一遍覆盖率一目了然。如果发现有遗漏说明参数文件或者工具使用有问题需要排查。4.4 批量处理的技巧实际项目里往往不止一组参数。比如一个系统有多个模块每个模块的参数不同。这时候可以写一个批处理脚本遍历input目录下的所有参数文件逐个跑allpairs输出到output目录。Windows批处理示例echo off for %%f in (input\*.txt) do ( echo Processing %%f allpairs.exe %%f output\%%~nf_result.txt )Linux shell示例for f in input/*.txt; do echo Processing $f ./allpairs $f output/$(basename $f .txt)_result.txt done这样一次能处理几十个参数文件效率提升明显。5. 正交表落地时的真实坑与应对5.1 参数之间存在依赖关系怎么办这是正交表使用中最常见的问题。举个例子参数A是是否使用优惠券参数B是优惠券类型。如果A选了不使用那B的取值就应该是无而不是满减券或折扣券。但正交表生成时不知道这个依赖会生成A不使用B满减券这种无效组合。应对方法有两种。第一种是生成后人工筛选把无效组合删掉然后看剩下的用例是否还满足覆盖要求。如果删掉太多导致覆盖不足就手动补几条。第二种是在参数文件里做预处理把有依赖的参数合并成一个参数。比如把是否使用优惠券和优惠券类型合并成优惠券状态取值就是无券、满减券、折扣券这样依赖关系就消失了。我一般优先用第二种方法因为合并参数能从根本上避免无效组合而且参数个数减少用例数也会进一步压缩。5.2 生成结果里出现重复用例有时候你会发现生成的结果里有完全相同的两行。这通常是因为参数文件里有重复的取值或者某个参数的取值个数和其他参数差异太大。allpairs在平衡覆盖时偶尔会生成重复行来凑覆盖。处理办法很简单用sort和uniq去重sort result.txt | uniq result_dedup.txt去重后再检查覆盖率如果覆盖仍然完整那就没问题。如果去重后覆盖不全说明参数文件本身有问题需要调整取值。5.3 用例数量比预期多很多理论上正交表应该很精简但有时候跑出来用例数远超预期。原因通常有几个某个参数的取值个数特别多比如其他参数都是3个值它却有10个值。正交表为了覆盖这个参数和其他参数的两两组合用例数会被拉高。参数文件里有空行或者格式错误导致工具解析异常。参数个数太多比如超过10个用例数自然上去。针对第一种情况可以考虑把取值多的参数做等价类划分把10个值合并成3-4个等价类。针对第二种仔细检查文件格式。针对第三种拆分成多轮测试。5.4 中文取值导致的乱码问题前面提过编码问题这里再强调一次。如果参数文件里有中文生成结果里出现乱码按这个顺序排查确认参数文件的编码是UTF-8无BOM。确认命令行的编码设置Windows下可以用chcp 65001切换到UTF-8。确认输出文件的编码重定向时终端编码会影响输出。如果实在搞不定最省事的办法是把中文取值改成英文或拼音生成结果后再映射回中文。虽然多了一步但能避免大量编码相关的折腾。注意团队协作时参数文件的编码规范要统一写进文档。我见过因为编码不一致同一个人在不同电脑上跑出不同结果的案例排查起来非常浪费时间。6. 把正交表用出花进阶思路与经验沉淀6.1 正交表和其他测试设计方法的配合正交表不是孤立的。实际项目里我通常把它和等价类划分、边界值分析结合使用。先用等价类划分把每个参数的取值精简到最有代表性的几个再用边界值补充临界情况最后用正交表做组合。这样生成的用例既精简又全面。举个例子一个输入框的长度参数等价类划分后可能是空、正常、超长三个值边界值分析会补充最小长度、最大长度、最大长度1。综合起来这个参数的取值可能是空、1字符、正常长度、最大长度、最大长度1五个值。然后把这个参数和其他参数一起丢给正交表生成的用例就能同时覆盖等价类和边界值。6.2 用脚本自动化整个流程如果项目里频繁使用正交表建议把整个流程脚本化。我的做法是写一个Python脚本输入是一个Excel或者CSV文件里面按sheet或者按区块定义多组参数脚本自动解析、调用allpairs、验证覆盖率、输出最终用例到新的Excel。这样测试同学只需要维护参数定义不用关心命令行和格式转换。脚本里还可以加入用例编号、优先级标记等逻辑生成的用例直接能导入测试管理平台。6.3 正交表结果的评审要点生成用例后评审时重点看几个地方覆盖率报告确认所有两两组合都覆盖了。无效组合人工检查是否有依赖冲突的组合。业务合理性有些组合虽然数学上有效但业务上不可能发生比如未登录用户查看订单。优先级正交表生成的用例默认是平级的实际执行时需要根据业务重要性排优先级。评审通过后这些用例就可以纳入回归测试集。下次版本迭代时如果参数没变直接复用如果参数变了重新跑一遍正交表对比新旧用例的差异快速更新测试集。6.4 我个人在实际操作中的体会用了这么多年正交表最大的体会是它解决的是组合爆炸的问题但解决不了该测什么的问题。参数和取值的设计仍然依赖测试人员对业务的理解。正交表只是一个放大器你把好的参数设计喂给它它产出高效的用例你把垃圾参数喂给它它产出的也是一堆垃圾。另外不要迷信工具生成的用例数量。有时候多几条用例覆盖更充分比强行压缩到最少更划算。工具是辅助判断还得靠人。最后分享一个小技巧把常用的参数文件模板存下来比如登录、下单、支付这些场景下次遇到类似功能直接改改取值就能用能省不少时间。正交表这东西用顺手了真的回不去。