前两年我负责的一个配置模块4个下拉框、每个框3个选项后面还挂着两个开关。需求分析会开完我拿着笔记本回工位列组合列到一半就不想列了——3×3×3×3×2×2整整324条。当时一个迭代才两周测试环境还经常抢不到硬着头皮把用例全写出来评审时被开发反问了一句“你这些用例哪些是真正有价值的”我答不上来。后来老测试组长扔给我一个词正交表。我研究了一晚上把模块里的可变项拆成因素和水平套了一张标准表324条压到18条。执行完上线线上没有因为这个模块出过问题。那之后我才意识到正交表不只是一个“少写用例”的技巧它背后是一整套解决组合爆炸的测试方式影响了我后来所有的测试设计思路。这篇就围绕“正交表——测试方式”这个话题把我从原理理解、查表选表、用例生成到踩坑复盘的经验完整写下来。适合刚接触测试用例设计的新人也适合正在被全组合测试折磨到怀疑人生的功能测试、接口测试同学。文章里所有例子都来自真实可复现的场景你可以直接拿自己手头的项目照着做。1. 从“全组合测试”到“代表性抽样”正交表要解决的核心矛盾1.1 什么时候组合数会失控先看一个非常常见的场景你要验证一个页面在不同配置下是否正常。页面有3个下拉框每个下拉框有4个选项看起来不多但全组合是4的3次方等于64条用例。如果这个页面再叠加2个开关就是64乘以4等于256条。很多测试同学在这个阶段已经开始焦虑了。真正让组合数爆炸的往往是这几类情况兼容性测试操作系统、浏览器、网络类型、屏幕分辨率、接口测试多个入参组合、不同的鉴权方式、不同的数据状态、权限管理用户角色、资源类型、操作方式、以及各种配置项组合的验证。这些场景的共同点是每一个因素单独看都不难测难的是它们之间的相互作用。我见过最夸张的一个项目环境矩阵有8个维度每个维度2到5个水平不等全组合超过百万条。这种测试方式显然是不现实的但你也不能拍脑袋随便挑几条测。用户可能从任意一种环境组合里访问你的系统漏掉某个组合上线后就有可能在特定环境下暴露问题。1.2 等价类、边界值为什么救不了组合问题等价类划分和边界值分析是测试设计的两大基本功但它们的强项在“单输入维度”。等价类告诉你“手机号输入框”可以分为有效、无效、边界三类边界值告诉你“验证码”的6位和7位是边界。它们都没有回答这样一个问题当操作系统取Android、网络取5G、账号类型取第三方时这几个条件凑在一起会不会出问题。组合问题出在“交互”上而不是单点上。两个因素之间可能产生特定条件下的冲突三个因素之间也可能存在更隐蔽的依赖。这种问题用等价类分析不出来用边界值也覆盖不到只能通过组合测试的方式去碰。而正交表正是组合测试里最经典、最容易上手的一种。1.3 用一组数字感受差距只看概念容易觉得抽象看数字最直观。下面这张表是我做测试设计时经常拿出来给组里同学看的也是我对“是否需要用正交表”这个问题的第一判断依据场景规模全组合用例数常用正交表正交表用例数3因素3水平3^3 27L9(3^4)94因素3水平3^4 81L9(3^4)95因素4水平4^5 1024L16(4^5)166因素5水平5^6 15625L25(5^6)2513因素2水平2^13 8192L16(2^15)16全组合数量是指数级上涨而正交表的用例数只是线性、甚至更低地增长。这不是拍脑袋减出来的而是数学上保证了“单因素和任意两两组合都被覆盖到”。换句话说你从81条里抽出9条丢掉的是“重复覆盖”而不是“覆盖内容”。2. L9(3^4)读法拆解因素、水平与“正交”到底是什么2.1 一张标准正交表长什么样正交表的标准写法是L9(3^4)这种形式。L后面的9代表这张表有9行也就是能生成9条测试用例括号里3的4次方代表最多容纳4个因素每个因素有3个水平。先看一张最常用的L9(3^4)表行号列1列2列3列4111112122231333421235223162312731328321393321这里的列就是因素行就是用例表格里的1、2、3是每个因素的可选水平值。使用时把列对应到具体因素把数字替换成实际取值一张正交表就变成了测试用例矩阵。2.2 “正交”的两个直观感觉均匀分散、整齐可比“正交”这个词听起来很数学但它的含义在测试场景下并不难理解。第一个感觉叫“均匀分散”。想象一下如果不加任何限制你在81个组合点里随便挑9个很容易挑到一堆扎堆的组合有的区域密集覆盖有的区域完全空白。正交表选出来的9个点则像在四维空间里均匀撒网保证每个维度的每个水平出现次数完全相同。第二个感觉叫“整齐可比”。观察L9这张表列1取1的三行里列2、列3、列4都分别取了1、2、3一次。这意味着当你固定某一个因素的水平时其他因素的水平分布是完全均匀的。这样比较某个因素不同水平产生的效果时不会被其他因素干扰。就好比你想比较三种肥料对苹果产量的影响但每块地土壤不一样最靠谱的做法是让三种肥料在每种土壤上都种同样多的树最后比出来的差异才是肥料本身的差异。2.3 对测试最有用的性质任意两列的每个组合都出现一次正交表还有一个更强的性质也是它对测试最有价值的点任意两列之间同一行所有水平对的组合都出现且仅出现一次。以L9的列1和列2为例9行对应的序对是(1,1)(1,2)(1,3)(2,1)(2,2)(2,3)(3,1)(3,2)(3,3)正好是3乘以3等于9种组合的全部。不光是列1和列2任意两列都是这样。用人话说就是这张表确保每个因素和其他任意一个因素的每一对取值都至少碰面一次。绝大多数兼容性问题、参数冲突问题本质上是两个因素相互作用引发的。正交表把一个因素和所有其他因素的两两组合都覆盖到了等于把所有最容易出问题的“组合关系”都验了一遍。这才是它用极少的用例数就能兜住大部分风险的真正原因。3. 从需求到用例正交表设计测试用例的完整步骤3.1 第一步把需求里的“可变项”拆成因素和水平假设现在要验证一个App的登录模块在不同环境下的兼容性。拿到需求后先不要急着写用例把需求里所有可能影响结果的可变项列出来。我通常会画一张因素水平表因素水平1水平2水平3操作系统Android 12Android 13iOS 16运行环境原生App微信内置浏览器Safari网络类型4G5GWiFi账号类型手机号邮箱第三方登录这张表看起来简单但它其实是整个测试设计最核心的产物。因素列少了组合覆盖不完整因素列多了用例规模会膨胀。经验是把需求里的名词、选项、环境属性都过一遍凡是可能影响行为的变量都先放进来再根据测试重点做取舍。3.2 第二步选一张能装下的表选表的原则很简单因素数不能超过表的列数每个因素的水平数必须和表的水平数一致。上面的例子是4个因素、每个因素3个水平正好匹配L9(3^4)的容量4列、3水平所以选L9。如果因素少于表的列数比如只有3个因素3个水平L9依然可以用空列不用管生成的用例不会受影响。如果因素超过列数就不建议硬塞了得换更大的表或者用后面会讲到的Pairwise工具。选表时最常犯的错误是水平数不匹配想把一个4水平的因素塞进3水平的列里这种操作会破坏正交性直接导致覆盖缺失。3.3 第三步把因素水平映射到表中生成用例把因素水平表里的水平1、水平2、水平3对应到L9的1、2、3逐行翻译成可执行的测试用例。第1列对应操作系统第2列对应运行环境第3列对应网络类型第4列对应账号类型映射出来的
正交表测试设计：从组合爆炸到高效用例生成的实践指南
前两年我负责的一个配置模块4个下拉框、每个框3个选项后面还挂着两个开关。需求分析会开完我拿着笔记本回工位列组合列到一半就不想列了——3×3×3×3×2×2整整324条。当时一个迭代才两周测试环境还经常抢不到硬着头皮把用例全写出来评审时被开发反问了一句“你这些用例哪些是真正有价值的”我答不上来。后来老测试组长扔给我一个词正交表。我研究了一晚上把模块里的可变项拆成因素和水平套了一张标准表324条压到18条。执行完上线线上没有因为这个模块出过问题。那之后我才意识到正交表不只是一个“少写用例”的技巧它背后是一整套解决组合爆炸的测试方式影响了我后来所有的测试设计思路。这篇就围绕“正交表——测试方式”这个话题把我从原理理解、查表选表、用例生成到踩坑复盘的经验完整写下来。适合刚接触测试用例设计的新人也适合正在被全组合测试折磨到怀疑人生的功能测试、接口测试同学。文章里所有例子都来自真实可复现的场景你可以直接拿自己手头的项目照着做。1. 从“全组合测试”到“代表性抽样”正交表要解决的核心矛盾1.1 什么时候组合数会失控先看一个非常常见的场景你要验证一个页面在不同配置下是否正常。页面有3个下拉框每个下拉框有4个选项看起来不多但全组合是4的3次方等于64条用例。如果这个页面再叠加2个开关就是64乘以4等于256条。很多测试同学在这个阶段已经开始焦虑了。真正让组合数爆炸的往往是这几类情况兼容性测试操作系统、浏览器、网络类型、屏幕分辨率、接口测试多个入参组合、不同的鉴权方式、不同的数据状态、权限管理用户角色、资源类型、操作方式、以及各种配置项组合的验证。这些场景的共同点是每一个因素单独看都不难测难的是它们之间的相互作用。我见过最夸张的一个项目环境矩阵有8个维度每个维度2到5个水平不等全组合超过百万条。这种测试方式显然是不现实的但你也不能拍脑袋随便挑几条测。用户可能从任意一种环境组合里访问你的系统漏掉某个组合上线后就有可能在特定环境下暴露问题。1.2 等价类、边界值为什么救不了组合问题等价类划分和边界值分析是测试设计的两大基本功但它们的强项在“单输入维度”。等价类告诉你“手机号输入框”可以分为有效、无效、边界三类边界值告诉你“验证码”的6位和7位是边界。它们都没有回答这样一个问题当操作系统取Android、网络取5G、账号类型取第三方时这几个条件凑在一起会不会出问题。组合问题出在“交互”上而不是单点上。两个因素之间可能产生特定条件下的冲突三个因素之间也可能存在更隐蔽的依赖。这种问题用等价类分析不出来用边界值也覆盖不到只能通过组合测试的方式去碰。而正交表正是组合测试里最经典、最容易上手的一种。1.3 用一组数字感受差距只看概念容易觉得抽象看数字最直观。下面这张表是我做测试设计时经常拿出来给组里同学看的也是我对“是否需要用正交表”这个问题的第一判断依据场景规模全组合用例数常用正交表正交表用例数3因素3水平3^3 27L9(3^4)94因素3水平3^4 81L9(3^4)95因素4水平4^5 1024L16(4^5)166因素5水平5^6 15625L25(5^6)2513因素2水平2^13 8192L16(2^15)16全组合数量是指数级上涨而正交表的用例数只是线性、甚至更低地增长。这不是拍脑袋减出来的而是数学上保证了“单因素和任意两两组合都被覆盖到”。换句话说你从81条里抽出9条丢掉的是“重复覆盖”而不是“覆盖内容”。2. L9(3^4)读法拆解因素、水平与“正交”到底是什么2.1 一张标准正交表长什么样正交表的标准写法是L9(3^4)这种形式。L后面的9代表这张表有9行也就是能生成9条测试用例括号里3的4次方代表最多容纳4个因素每个因素有3个水平。先看一张最常用的L9(3^4)表行号列1列2列3列4111112122231333421235223162312731328321393321这里的列就是因素行就是用例表格里的1、2、3是每个因素的可选水平值。使用时把列对应到具体因素把数字替换成实际取值一张正交表就变成了测试用例矩阵。2.2 “正交”的两个直观感觉均匀分散、整齐可比“正交”这个词听起来很数学但它的含义在测试场景下并不难理解。第一个感觉叫“均匀分散”。想象一下如果不加任何限制你在81个组合点里随便挑9个很容易挑到一堆扎堆的组合有的区域密集覆盖有的区域完全空白。正交表选出来的9个点则像在四维空间里均匀撒网保证每个维度的每个水平出现次数完全相同。第二个感觉叫“整齐可比”。观察L9这张表列1取1的三行里列2、列3、列4都分别取了1、2、3一次。这意味着当你固定某一个因素的水平时其他因素的水平分布是完全均匀的。这样比较某个因素不同水平产生的效果时不会被其他因素干扰。就好比你想比较三种肥料对苹果产量的影响但每块地土壤不一样最靠谱的做法是让三种肥料在每种土壤上都种同样多的树最后比出来的差异才是肥料本身的差异。2.3 对测试最有用的性质任意两列的每个组合都出现一次正交表还有一个更强的性质也是它对测试最有价值的点任意两列之间同一行所有水平对的组合都出现且仅出现一次。以L9的列1和列2为例9行对应的序对是(1,1)(1,2)(1,3)(2,1)(2,2)(2,3)(3,1)(3,2)(3,3)正好是3乘以3等于9种组合的全部。不光是列1和列2任意两列都是这样。用人话说就是这张表确保每个因素和其他任意一个因素的每一对取值都至少碰面一次。绝大多数兼容性问题、参数冲突问题本质上是两个因素相互作用引发的。正交表把一个因素和所有其他因素的两两组合都覆盖到了等于把所有最容易出问题的“组合关系”都验了一遍。这才是它用极少的用例数就能兜住大部分风险的真正原因。3. 从需求到用例正交表设计测试用例的完整步骤3.1 第一步把需求里的“可变项”拆成因素和水平假设现在要验证一个App的登录模块在不同环境下的兼容性。拿到需求后先不要急着写用例把需求里所有可能影响结果的可变项列出来。我通常会画一张因素水平表因素水平1水平2水平3操作系统Android 12Android 13iOS 16运行环境原生App微信内置浏览器Safari网络类型4G5GWiFi账号类型手机号邮箱第三方登录这张表看起来简单但它其实是整个测试设计最核心的产物。因素列少了组合覆盖不完整因素列多了用例规模会膨胀。经验是把需求里的名词、选项、环境属性都过一遍凡是可能影响行为的变量都先放进来再根据测试重点做取舍。3.2 第二步选一张能装下的表选表的原则很简单因素数不能超过表的列数每个因素的水平数必须和表的水平数一致。上面的例子是4个因素、每个因素3个水平正好匹配L9(3^4)的容量4列、3水平所以选L9。如果因素少于表的列数比如只有3个因素3个水平L9依然可以用空列不用管生成的用例不会受影响。如果因素超过列数就不建议硬塞了得换更大的表或者用后面会讲到的Pairwise工具。选表时最常犯的错误是水平数不匹配想把一个4水平的因素塞进3水平的列里这种操作会破坏正交性直接导致覆盖缺失。3.3 第三步把因素水平映射到表中生成用例把因素水平表里的水平1、水平2、水平3对应到L9的1、2、3逐行翻译成可执行的测试用例。第1列对应操作系统第2列对应运行环境第3列对应网络类型第4列对应账号类型映射出来的
