测试设计技术
把黑盒设计技术、探索式测试、组合测试、fuzzing、property-based testing 和 contract testing 放进同一个测试设计工具箱里。
[!info] related notes
- 所属 MOC: Testing MOC
- 相关概念: 软件测试基础, 软件测试过程与治理
- 相关主题: 契约测试与 CDC, TDD 中测什么与测试金字塔
测试设计技术
范围
这篇笔记不讨论测试流程，而是整理“怎么系统性地设计测试集”。
为什么要把这些技术放在一起理解
穷举测试几乎不可能，所以真正重要的问题不是“多写一些测试”，而是“用合适的技术选出更高价值的测试”。
这些技术本质上都在回答同一件事：
在有限成本下，如何用更小但更有效的测试集发现更多问题。
经典黑盒技术
等价类划分
把输入空间按行为等价的方式分组，然后选代表值来测，避免重复劳动。
边界值分析
很多 bug 都出现在边界附近，所以边界通常比中间值更值得重点测。
判定表
当业务规则由多个条件组合决定时，判定表非常适合整理组合逻辑。
状态迁移
当系统行为依赖前一状态时，状态迁移测试比孤立输入输出更能覆盖真实风险。
探索式测试与 checklist
探索式测试
当规格不完整、需求还在变化、时间很紧时，探索式测试很有价值。
它更像“边理解系统边设计测试”，适合补足形式化测试的盲区。
checklist-based testing
当团队已经有稳定经验时，checklist 很适合把经验沉淀成一致性检查。
它的价值不是替代思考，而是降低遗漏常见问题的概率。
组合测试
多参数系统里，真正的风险常来自参数交互，而不是单个输入值。
这时 combinatorial / t-way testing 的价值很高：
- 不做穷举
- 重点覆盖高价值参数交互
- 以较小测试集逼近穷举测试的故障发现能力
它特别适合配置组合、表单规则、兼容性矩阵这类问题。
fuzzing
fuzzing 会向系统提供无效、意外或随机输入，再监控崩溃和异常行为。
这类技术对安全和鲁棒性特别有价值，因为很多漏洞不会出现在“正常用户输入”的路径里。
property-based testing
如果系统有稳定不变量，property-based testing 会比固定示例更有力量。
它的思路是：
- 先描述“对一类输入都应成立的性质”
- 再让工具自动生成大量输入，包括你未必想到的边界与角落情况
这特别适合规则密集、纯逻辑、变换类代码。
contract testing
当系统是服务化架构时，contract testing 的价值很高。
它适合回答：
- 消费者真正依赖 provider 的哪部分交互
- provider 的响应有没有破坏既有约定
- 是否能用更便宜、更稳定的方式替代一部分大集成测试
详见 契约测试与 CDC。
这些技术怎么选
可以先按问题类型判断：
- 输入空间很大：等价类、边界值
- 规则组合复杂：判定表、组合测试
- 状态依赖明显：状态迁移
- 规格不完整：探索式测试
- 安全与健壮性风险高：fuzzing
- 不变量清晰：property-based testing
- 服务边界复杂：contract testing
最短记忆方式
测试设计不是拍脑袋写 case，而是在不可能穷举的前提下，用更聪明的技术挑出更值钱的测试。