4. 测试用例设计方法论：等价类划分、边界值分析、状态转换测试、场景法设计、正交实验法
各位好，我是老周。今天咱们聊聊测试用例设计的方法论。说实话，很多刚入行的工程师拿到协议栈规范，第一反应就是“我照着文档一条一条测不就行了？”——嗯，真这么干，你大概率会漏掉最隐蔽的 bug。
协议栈测试有个特点：输入空间巨大，状态组合爆炸。你不可能穷举所有情况。所以，我们需要一些系统化的方法，用最少的用例覆盖最多的风险。这章我把自己十几年积累的“工具箱”摊开给你看。
核心思想：测试用例设计不是“拍脑袋”，而是基于对输入域、状态空间和业务场景的结构化分析。每种方法解决一类特定问题。
4.1 等价类划分：把无限输入切成有限份
等价类划分，说白了就是把输入数据按“是否触发相同处理逻辑”分组。你只需要从每个组里挑一个代表值来测。
举个实际例子： 我记得在做一个 TCP 窗口缩放选项的测试时，窗口缩放因子（shift count）的取值范围是 0~14。如果逐值测试，要测 15 次。但用等价类划分，我只需要测 3 个值：
- 有效等价类： shift count = 7（中间值，代表正常缩放）
- 无效等价类（下边界外）： shift count = -1（非法负值）
- 无效等价类（上边界外）： shift count = 15（超出最大值）
你看，15 个用例压缩到 3 个，覆盖率一点没降。为什么？因为协议栈对 0~14 范围内的所有值，处理逻辑是一样的——都是左移窗口大小。而对负数或大于 14 的值，协议栈会直接丢弃或回复错误码。
我的习惯： 先画一张输入域表格，把“有效类”和“无效类”分开列。无效类往往比有效类更容易发现 bug。我曾经在测试 MQTT 协议时，就靠一个“无效的保留标志位”用例，揪出了 Broker 的状态机异常。
4.2 边界值分析：bug 最爱藏在边界上
边界值分析是等价类划分的“黄金搭档”。经验告诉我，80% 的协议实现 bug 都发生在边界附近。为什么？因为程序员写 if (x >= 0 && x <= 14) 时，很容易把 <= 写成 <，或者把 0 写成 1。
边界值选取原则： 对每个边界，取 min-1、min、min+1、max-1、max、max+1 这 6 个点。还是拿 shift count 举例：
| 边界类型 | 取值 | 预期行为 |
|---|---|---|
| 下边界 - 1 | -1 | 协议栈拒绝（无效） |
| 下边界 | 0 | 正常处理（无缩放） |
| 下边界 + 1 | 1 | 正常处理 |
| 上边界 - 1 | 13 | 正常处理 |
| 上边界 | 14 | 正常处理（最大缩放） |
| 上边界 + 1 | 15 | 协议栈拒绝（无效） |
避坑指南： 我曾经在测试 CoAP 协议的 Token 长度时，规范说 Token 长度范围是 0~8 字节。我测了 0、1、7、8、9，以为够了。结果上线后，某个设备发了长度为 0 的 Token（合法），但接收端把空 Token 当成了“无 Token”处理，导致会话复用逻辑崩溃。教训是：边界值不仅要测“数值边界”，还要测“语义边界”——0 长度 Token 和 1 字节 Token 虽然数值相邻，但语义完全不同。
4.3 状态转换测试：协议栈的灵魂
协议栈本质上就是一个状态机。从 TCP 的 CLOSED → SYN_SENT → ESTABLISHED，到 HTTP/2 的流状态迁移，再到 MQTT 的会话生命周期——状态转换测试是协议栈一致性测试的“灵魂”。
我习惯用 状态转换图（STD） 来建模。每个状态是一个节点，每个事件（收到报文、超时、应用层调用）是一条边。测试用例就是覆盖所有“合法转换”和“非法转换”。
举个简化例子： 一个简单的连接状态机：
状态: CLOSED, SYN_SENT, ESTABLISHED, FIN_WAIT_1
事件:
- 应用层调用 connect()
- 收到 SYN+ACK
- 收到 FIN
- 超时
合法转换:
CLOSED --[connect()]--> SYN_SENT
SYN_SENT --[收到 SYN+ACK]--> ESTABLISHED
ESTABLISHED --[收到 FIN]--> FIN_WAIT_1
非法转换（需要测试的负向用例）:
CLOSED --[收到 FIN]--> ? (预期：协议栈应忽略或回复 RST)
ESTABLISHED --[connect()]--> ? (预期：协议栈应返回错误)
我的方法： 我会用 状态转换树 来生成测试序列。从初始状态开始，每次选择一个事件，深度优先遍历所有可达状态。这样能保证每条路径都被测到。但要注意状态爆炸——对于复杂协议（如 TCP 有 11 个状态），我会用正交实验法来压缩路径数量。
4.4 场景法设计：从用户视角出发
等价类和边界值都是“点”上的测试，状态转换是“线”上的测试。但用户真正关心的是“面”——也就是完整的业务场景。
场景法设计，就是模拟真实用户的操作流程。我通常分三步走：
- 识别基本流： 用户最常用的“快乐路径”。比如 MQTT 客户端连接 → 订阅主题 → 接收消息 → 断开连接。
- 识别备选流： 每个步骤可能出错的地方。比如连接时服务器拒绝、订阅时主题不存在、接收消息时网络中断。
- 组合场景： 把基本流和备选流组合成完整的测试场景。
举个例子： 测试 HTTP/2 的“服务器推送”功能。
- 基本流： 客户端发起 GET 请求 → 服务器推送 2 个相关资源 → 客户端接收并缓存。
- 备选流 1： 客户端在 SETTINGS 中设置
SETTINGS_ENABLE_PUSH = 0→ 服务器不应推送任何资源。 - 备选流 2： 服务器推送的资源数量超过客户端在
SETTINGS_MAX_CONCURRENT_STREAMS中声明的限制 → 客户端应拒绝多余的推送流。 - 备选流 3： 客户端在收到推送资源前发送 RST_STREAM → 服务器应停止推送。
你看，一个基本流 + 三个备选流，就覆盖了“服务器推送”这个功能的所有关键场景。
4.5 正交实验法：用最少的组合覆盖最多的因素
当你有多个输入参数，每个参数又有多个取值时，组合数会爆炸。比如 4 个参数，每个 3 种取值，全组合是 3^4 = 81 个用例。但用正交实验法，你可能只需要 9 个用例。
正交表的核心思想： 任意两个参数的取值组合，在整个测试集中出现的次数相等。这样就能保证“两两组合覆盖”，而不用测全组合。
实际案例： 测试 TLS 1.3 握手参数组合。我选了 4 个因素：
| 因素 | 取值 1 | 取值 2 | 取值 3 |
|---|---|---|---|
| 密码套件 | TLS_AES_128_GCM_SHA256 | TLS_AES_256_GCM_SHA384 | TLS_CHACHA20_POLY1305_SHA256 |
| 密钥交换模式 | (EC)DHE | PSK | PSK + (EC)DHE |
| 签名算法 | RSA-PSS | ECDSA | EdDSA |
| 协议版本 | TLS 1.3 | TLS 1.2 (降级) | TLS 1.3 + 中间人 |
全组合需要 3^4 = 81 个用例。我用 L9(3^4) 正交表，只设计了 9 个用例，就覆盖了所有“两两组合”。上线后，这 9 个用例发现了 3 个兼容性问题，而之前用全组合测了 50 个用例都没发现。
注意： 正交实验法只保证“两两组合覆盖”，不保证“三三组合”或更高阶的覆盖。对于协议栈测试，两两组合通常已经能发现 90% 以上的交互 bug。如果某个参数组合有已知的高风险，我会单独补充几个“三三组合”用例。
4.6 方法选择矩阵：什么时候用哪个？
这么多方法，到底怎么选？我整理了一个选择矩阵，你可以直接拿来用：
| 测试目标 | 推荐方法 | 典型场景 |
|---|---|---|
| 单个字段/参数的取值验证 | 等价类划分 + 边界值分析 | 报文头部的标志位、长度字段、类型字段 |
| 协议状态机行为验证 | 状态转换测试 | 连接建立/释放、流控制、会话迁移 |
| 端到端业务流程验证 | 场景法设计 | 资源推送、重连机制、错误恢复 |
| 多参数组合交互验证 | 正交实验法 | 密码套件 + 密钥交换 + 签名算法组合 |
4.7 本章知识体系总览
下面这张图，我把这五种方法的关系和适用层级画了出来。你可以把它当作一个“测试方法导航图”。
这张图你看懂了吗？从下往上，第一层解决“单个字段对不对”，第二层解决“状态迁移对不对”，第三层解决“业务流程和组合交互对不对”。每层的方法可以独立使用，也可以组合使用。我个人习惯是：先做第一层，再做第二层，最后做第三层——这样能保证从微观到宏观，层层递进，不留死角。
总结一句话： 等价类划分和边界值分析是“点”，状态转换测试是“线”，场景法和正交实验法是“面”。点线面结合，才能构建一个立体的测试覆盖网。