别只测全开全关：用 allpairspy + pytest 给特性开关做 pairwise 组合覆盖

灰度上线那天，每个特性开关单看都正常：开了没问题，关了也没问题。可线上偏偏有一批用户开始报错，复现半天才发现——出事的只有同时命中「开关 A 开 + 开关 B 关 + 开关 C 开」这一个组合的用户。而团队的测试用例里，只有「全开」和「全关」两种配置，中间那一大片组合，从头到尾没人跑过。

这不是某个开关写错了，是组合测试的覆盖策略出了盲区。N 个布尔开关，理论上就是 2^N 种组合；12 个开关就是 4096 种。全测一遍既不现实，绝大多数组合也根本不会同时出现在同一批用户身上。但只测两个极端，又必然漏掉「开关之间相互作用」才触发的那类 bug。本篇要解决的，就是怎么在这两个极端之间找到一条跑得起、又覆盖得住的路。

灰度组合的 bug 极少藏在单个开关里，它藏在开关的组合里——而全开全关这两个极端，恰恰是组合空间里最没代表性的两个点。

一、这是组合测试，不是新东西

先把概念锚回你熟悉的旧知识：特性开关的组合测试，本质就是**正交表 / 组合测试（Combinatorial Testing）**在灰度场景的落地。你当年用正交表从一堆「浏览器 × 操作系统 × 分辨率」的组合里挑出代表性用例，今天面对的「开关 A × 开关 B × … × 开关 L」是同一道题，只是参数换成了布尔开关。

组合测试里最常用的一档强度叫 pairwise（两两组合覆盖）：它不追求覆盖所有 N 个参数的全部组合，只保证任意两个参数的每一种取值搭配，都至少在某一条用例里出现过一次。背后的经验假设是——绝大多数缺陷由单个参数或两个参数的相互作用触发，三个及以上参数同时耦合才炸的缺陷占比很小。于是 pairwise 用远少于全组合的用例数，覆盖住了最容易出问题的那部分相互作用。

对特性开关来说这个假设尤其成立：「A 开导致走了新逻辑，B 关导致旧缓存没清」这种两两耦合，正是灰度事故的高发区。下面这张表，把三种策略摊开对照：

结论很清楚：全开全关是「假装测过」，全组合是「测不动」，pairwise 才是那个能进 CI、又能压住漏测风险的务实解。

二、用 allpairspy 从开关清单生成 pairwise 组合

先看怎么把一份开关清单喂进去，自动生成 pairwise 组合。allpairspy 是个纯 Python 库，pip install allpairspy 即可：

# gen_pairs.py —— 从特性开关清单生成 pairwise 组合（依赖 allpairspy）
from allpairs import AllPairs

# 每个开关的取值域；布尔开关就是 [开, 关]
FLAGS = {
    "new_checkout":  [True, False],   # A: 新结算流程
    "cache_v2":      [True, False],   # B: 二级缓存
    "risk_engine":   [True, False],   # C: 新风控引擎
    "async_notify":  [True, False],   # D: 异步通知
    "price_ab":      ["v1", "v2"],    # E: 定价 AB（多值开关）
    "gray_region":   ["cn", "sea", "eu"],  # F: 灰度地域（三值）
}


def gen_pairwise(flags):
    """返回 pairwise 组合列表，每条是一个 dict。"""
    return [dict(row) for row in AllPairs(flags)]


if __name__ == "__main__":
    combos = gen_pairwise(FLAGS)
    print(f"开关数 = {len(FLAGS)}，全组合 = {2**len(FLAGS)} 量级")
    print(f"pairwise 生成组合数 = {len(combos)}")
    for i, c in enumerate(combos[:5], 1):
        print(i, c)

为什么这么写。第一，把开关写成 {名: 取值域} 的字典，是刻意让「布尔开关」和「多值开关」（像 price_ab 的 v1/v2、gray_region 的三地域）用同一套结构描述——真实灰度里开关并不都是 True/False，有的本身就是枚举，pairwise 对多值参数一样适用。第二，AllPairs 帮你算的正是「任意两个参数的每种搭配至少出现一次」，你不用自己手写正交表；6 个开关（其中一个还是三值）的全组合是 2×2×2×2×2×3=96 种，pairwise 通常压到十几行量级，直接跑得起。第三，打印里我特意把「全组合量级」和「pairwise 组合数」并排打出来，就是为了让团队直观看到压缩比——这个对比本身就是说服上下游「值得做组合测试」的最好材料。踩过的坑是，一开始有人把每个开关都当独立用例测（开一遍、关一遍），以为覆盖了，其实那连 pairwise 都不是，任意两个开关的搭配一次都没测到，中间盲区原封不动。

三、把每组组合喂给 pytest 参数化跑关键链路

组合生成出来只是清单，得让它真正跑起来。把每组开关配置参数化，逐条注入被测链路并断言关键结果：

# test_flag_combos.py —— pairwise 组合驱动的关键链路回归（pytest）
import pytest
from gen_pairs import gen_pairwise, FLAGS

COMBOS = gen_pairwise(FLAGS)


def run_checkout(config: dict) -> dict:
    """被测关键链路：按开关配置跑一次结算，返回可断言的结果。
    真实场景里这里会带上 config 调用你的服务/接口。"""
    result = {"ok": True, "amount": 100, "notified": False}
    # 模拟一处「开关相互作用」：新结算 + 关二级缓存 时金额计算走另一分支
    if config["new_checkout"] and not config["cache_v2"]:
        result["amount"] = 100  # 期望仍为 100，回归守住这条相互作用
    if config["async_notify"]:
        result["notified"] = True
    return result


@pytest.mark.parametrize("config", COMBOS,
                         ids=[str(i) for i in range(len(COMBOS))])
def test_key_path_under_flag_combo(config):
    r = run_checkout(config)
    # 关键链路断言：不论开关怎么组合，核心不变量必须成立
    assert r["ok"] is True
    assert r["amount"] == 100
    assert r["notified"] == bool(config["async_notify"])

为什么这么写。@pytest.mark.parametrize 把 pairwise 组合直接变成一批参数化用例，这是组合测试能进回归、进 CI 的关键——每改一个开关逻辑，这几十条组合用例自动重跑一遍，相互作用有没有被改坏立刻见分晓。断言我故意只盯核心不变量（结算成功、金额正确、通知与开关一致），而不是给每种组合写死一套期望值：组合测试的用例数量多，断言越脆越难维护，守住「无论怎么组合都不该被破坏的不变量」比逐组合硬编码更可持续。run_checkout 里我埋了一处「new_checkout 开 + cache_v2 关」的相互作用分支，就是提醒——真正会出事的往往正是这种两两耦合，而它恰好是 pairwise 一定会覆盖到的搭配。踩过的坑是，早期给每条组合都写了精确期望值，开关一多、逻辑一改，用例红一大片全是期望值过期，维护到崩溃；改成守不变量之后才稳下来。

四、把「高危开关对」强制升级为全覆盖

pairwise 有个已知短板：它只保证两两覆盖，三个及以上开关的高阶耦合会漏。而有些组合你明知危险——比如「风控引擎 + 新结算 + 某地域」这三个一起开才会走到一段没测透的新代码。这种就该手动把特定开关对/三元组强制升级为全覆盖：

# force_coverage.py —— 把高危开关对升级为全覆盖，与 pairwise 结果合并去重
from itertools import product
from gen_pairs import gen_pairwise, FLAGS

# 已知高危：这几个开关的取值必须两两/全排列都覆盖到
HIGH_RISK = ["new_checkout", "risk_engine", "gray_region"]


def full_cover(names):
    """对指定开关做全排列组合，其余开关取一个固定基线值。"""
    domains = [FLAGS[n] for n in names]
    base = {k: v[0] for k, v in FLAGS.items()}   # 其余开关给基线值
    out = []
    for combo in product(*domains):
        row = dict(base)
        row.update(dict(zip(names, combo)))
        out.append(row)
    return out


def merged_suite():
    pairs = gen_pairwise(FLAGS)
    forced = full_cover(HIGH_RISK)
    # 合并去重（按规范化后的字符串），得到最终测试套件
    seen, suite = set(), []
    for row in pairs + forced:
        key = str(sorted(row.items()))
        if key not in seen:
            seen.add(key)
            suite.append(row)
    return suite


if __name__ == "__main__":
    suite = merged_suite()
    print(f"pairwise={len(gen_pairwise(FLAGS))} "
          f"高危全覆盖={len(full_cover(HIGH_RISK))} 合并后={len(suite)}")

为什么这么写。这是组合测试里很实用的「强度分层」思路：默认全用 pairwise 控总量，对已知高危的少数开关单独加码到全覆盖，两者合并去重后仍是一个跑得动的规模。full_cover 里对其余开关取固定基线值，是为了让高危组合的全排列不和其他开关再叉乘、把数量重新炸开——你只想把风险押在那几个明确危险的开关上。把「哪些开关对是高危」这件事显式写进代码，本身也是一份可评审、可追溯的风险清单：谁加的、为什么高危，PR 上都留痕，比藏在某个老同事脑子里强得多。踩过的坑是，一开始迷信 pairwise「够了」，结果恰恰栽在一个三开关高阶耦合上，从此对碰钱、碰风控、碰数据的开关一律手动加码全覆盖。

五、pairwise vs 全组合：把指数级压到可跑

把三种策略放回同一张图上，权衡关系就很直观了。横轴是组合数量级，纵轴是漏测风险：只测全开全关落在「组合极少、风险极高」的角落；全组合(2^N)落在「组合爆炸、风险理论最低但根本跑不动」的另一端；pairwise 则在中间——组合数量级只有几十行、漏测风险压到「仅剩高阶耦合」的低位，是那个能真正进 CI 的甜蜜点。而高危开关全覆盖，就是在 pairwise 的基础上，针对你已知最危险的那几个方向再往「组合更多、风险更低」推一小步。

接进 CI 时，把生成组合、跑 pytest、输出覆盖报告串成一条流水线即可：PR 触发时先跑 pairwise 套件（分钟级），nightly 再叠加高危全覆盖跑一遍完整套件。这样每次动开关逻辑，都有几十条组合用例在背后替你验相互作用有没有被改坏。还有一点别漏：把开关清单本身（那份 FLAGS 字典）也纳入版本库，和测试用例一起走 PR，谁新加了一个开关、谁改了取值域，都要在评审里被看到——否则清单悄悄膨胀，你的组合覆盖又会在无人察觉时退回盲区。

开关越加越多是灰度的常态，但组合空间不会因为你「只测了两个极端」就放过你。把组合测试当成正交表那道老题重新做一遍，你才敢在几十个开关同时在线时按下发布键。

灰度事故极少出在单个开关上，几乎都出在你没测过的那个组合里——pairwise 不是省事，是把有限的用例押在最会出事的地方。

你们的特性开关现在是怎么测的，只跑全开全关，还是已经上了 pairwise / 组合覆盖？踩过「组合才复现」的灰度 bug 吗？