测试用例设计的本质是在"穷尽测试不可行"这一基本约束下，用有限且具有代表性的输入组合覆盖尽可能多的缺陷风险。本文系统梳理七大经典设计方法，并补充 2024-2026 年间 AI 辅助用例生成、基于模型的测试（MBT）、Property-Based Testing 与探索式测试的工程化新趋势。
"好的"测试用例不应被定义为"发现了缺陷的用例"——这会陷入"傻子吃烧饼"式的归因谬误：缺陷被修复后，同一个用例难道就不再"好"了吗？更合理的定义是："好的"测试用例是一个完备的集合，能够覆盖所有等价类与各种边界值，而跟能否发现缺陷无关。
工程上还需引入基于风险的测试策略（Risk-Based Testing, RBT）作为补充：在有限资源下，"好的"用例集是对高风险等价类与关键边界值实现充分覆盖的集合，而非追求绝对完备。
等价类划分（Equivalence Partitioning）的核心假设是：等价类中任意一个输入对于揭露程序潜在错误具有同等效果。因此只需从每个等价类中选取一个代表值，即可用少量输入取得较好的覆盖效果。
需求：考试成绩取值 0~100 之间的整数，及格线 60。划分结果：
| 等价类 | 范围 | 代表值 |
|---|---|---|
| 有效等价类 1 | 0~59 | 50 |
| 有效等价类 2 | 60~100 | 80 |
| 无效等价类 1 | <0 的负数 | -1 |
| 无效等价类 2 | >100 的整数 | 101 |
| 无效等价类 3 | 0~100 之间的浮点数 | 75.5 |
| 无效等价类 4 | 非数字字符 | "abc" |
工程经验表明，大量缺陷发生在输入输出的边界上，而非中心区域。边界值分析（Boundary Value Analysis）作为等价类划分的补充，选取正好等于、刚刚大于、刚刚小于边界的值作为测试数据。
[a, b]，选取 a-1, a, a+1, b-1, b, b+1 共 6 个边界点n，选取长度 0, 1, n-1, n, n+1 的输入等价类划分关注"代表性"，边界值分析关注"极端性"，二者必须组合使用。继续以考试成绩为例，结合后的边界值为：-1, 0, 1, 59, 60, 61, 99, 100, 101，与等价类代表值（50, 80）共同构成完整用例集。
错误推测法（Error Guessing）依赖测试人员的经验、直觉与对被测系统的深入理解，推测程序可能存在的缺陷，从而有针对性地设计用例。其本质与"探索式测试"的思想一脉相承。
经典经验清单包括：
null 时的内部处理为降低对个人能力的依赖，工程上通常建立**缺陷知识库（Defect Knowledge Base）**作为 Checklist：
当输入条件之间存在逻辑组合关系时，等价类划分难以系统化覆盖所有组合，此时需要因果图法（Cause-Effect Graph）与判定表法（Decision Table）。
因果图法通过识别**原因（输入条件）与结果（输出动作）**之间的逻辑关系（与、或、非、恒等），构建因果图，再转换为判定表。其核心价值在于：揭示需求规约中模糊或矛盾的逻辑约束。
判定表将原因组合作为列、动作作为行，每列对应一条测试用例。判定表的构建步骤：
需求：订单金额 > 100 且为 VIP 用户时享受 8 折；订单金额 > 100 且非 VIP 用户时享受 9 折；订单金额 ≤ 100 不享受折扣。
| 用例编号 | 金额 > 100 | 是 VIP | 优惠 |
|---|---|---|---|
| TC1 | Y | Y | 8 折 |
| TC2 | Y | N | 9 折 |
| TC3 | N | Y | 无折扣 |
| TC4 | N | N | 无折扣 |
当输入因素较多且每个因素有多个水平时，全组合测试用例数量呈指数级增长。正交实验法（Orthogonal Experimental Design）借助正交表，从全组合中挑选出具有"均匀分散、整齐可比"特性的子集，实现用例数量大幅缩减。
例如 L_9(3^4) 表示 4 因素、每因素 3 水平，仅需 9 条用例即可覆盖，而全组合需要 3^4=81 条。
假设某注册接口有 4 个参数：用户名（A/B/C）、密码（强/中/弱）、邮箱（QQ/163/Gmail）、性别（男/女/-）。直接组合为 3×3×3×3=81 条用例，使用正交表可缩减至 9 条，且任意两因素的所有水平组合至少出现一次。
Pairwise（成对测试）是正交实验法的简化版本，仅保证任意两个因素的所有水平组合至少出现一次，不要求三阶及以上组合覆盖。主流工具如 PICT（Microsoft）、AllPairs 算法均基于此思想。
对于状态机驱动的系统（如订单流转、审批工作流、协议栈），状态迁移法（State Transition Testing）是首选设计方法。它通过状态图建模系统行为，再基于覆盖准则生成用例。
上图展示了一个典型电商订单的状态机：从"待支付"到"已完成"或"已退款/已取消/已退货"等终态。基于迁移覆盖准则，可设计出覆盖所有合法迁移的用例集；进一步通过非法迁移（如"待支付"直接跳"已发货"）补充异常路径用例。
2024 年以来，大语言模型（LLM）在测试用例生成上的工程化应用快速成熟：
工程提示：AI 生成的用例必须经过人工 Review，重点检查等价类完备性、边界值选取合理性、业务语义正确性。
MBT（Model-Based Testing）通过构建系统行为模型（状态机、UML 活动图、B-method 形式化模型），由工具自动生成测试用例与测试脚本。2024-2026 的趋势：
Property-Based Testing（PBT）从另一角度补充用例设计：不针对具体输入值设计用例，而是声明输入应满足的不变量（Property），由框架自动生成大量随机输入验证不变量。
# 使用 Hypothesis 进行 Property-Based Testing 示例
from hypothesis import given, strategies as st
# 定义被测函数：对一个列表进行升序排序
def sort_ascending(nums: list[int]) -> list[int]:
return sorted(nums)
# 声明不变量：排序后列表长度不变、非递减、元素集合相同
@given(st.lists(st.integers()))
def test_sort_properties(nums):
result = sort_ascending(nums)
# 不变量 1：长度不变
assert len(result) == len(nums)
# 不变量 2：非递减
assert all(result[i] <= result[i + 1] for i in range(len(result) - 1))
# 不变量 3：元素集合相同（含重复计数）
assert sorted(result) == sorted(nums)主流框架：Hypothesis（Python）、QuickCheck（Haskell）、jqwik（Java）、fast-check（JS/TS）。PBT 与传统用例设计方法互补：传统方法聚焦代表性输入，PBT 聚焦不变量与随机化覆盖，二者结合可显著提升测试深度。
探索式测试（Exploratory Testing）强调测试设计与执行同步进行，依赖测试人员的实时判断。2024-2026 的实践共识是平衡探索与脚本：
测试用例设计的七大方法并非相互替代，而是在不同场景下分层组合使用：等价类与边界值是基础，错误推测是经验增强，因果图与判定表处理条件组合，正交实验法压缩组合空间，状态迁移法建模状态系统。2024-2026 年的新趋势——AI 辅助生成、MBT、Property-Based Testing、探索式测试——并非颠覆经典方法，而是在生成效率、覆盖深度、人机协作三个维度上对经典方法的工程化增强。测试工程师的核心能力，正在从"手工设计用例"演进为"在 AI 与模型的辅助下，聚焦高风险区域、把控用例质量、构建可持续演进的用例集"。