一句话定义：属性测试（Property-based Testing）是一种测试方法——你不写“输入 A 应该得到输出 B”的具体用例，而是声明代码在任何情况下都必须成立的性质（property，也叫不变量，invariant），再由测试框架自动生成成百上千个随机输入去试着推翻它。
打个比方
举例测试像质检员随手拆三个箱子看看，没问题就放行。属性测试则是写下一句规则：“所有箱子重量必须大于 0，且标签条码能扫出同一串编号”，然后让机器造出成千上万个奇形怪状的箱子——空箱、超重箱、标签贴反的箱子——逐个验。它专挑你没想到的角落下手。
一旦发现反例，框架还会做“收缩”（shrinking）：把那个复杂输入一层层剥掉，直到剩下最小、最容易看懂的反例，比如一个长度为 2 的列表。失败时还会记下随机种子（seed），让这次失败可以稳定复现，之后就能当成普通回归用例长期跑。
最常见的几类性质
- 不变量：排序后列表长度不变
- 往返（round-trip）：解码(编码(x)) 等于 x
- 幂等：去重两次和去重一次结果一样
- 边界：概率输出永远落在 0 到 1 之间
- 差分：新旧两版实现，在同样输入下结果一致
和举例测试的区别
| 维度 | 举例测试 | 属性测试 |
|---|---|---|
| 输入来源 | 人手挑选 | 框架随机生成 |
| 断言方式 | 具体输入对应具体输出 | 所有输入都满足某条性质 |
| 覆盖面 | 受限于你的想象力 | 容易撞上边界和异常组合 |
| 失败信息 | 就是那条用例 | 最小化反例 + 随机种子 |
| 主要成本 | 写起来快，维护量大 | 想清楚性质难，长期收益高 |
两者不是替代关系。属性测试擅长回答“这段逻辑在任何输入下都不会崩、不会自相矛盾”，但回答不了“业务上到底该退多少钱”。涉及具体业务规则的判断，仍然要靠举例测试或人来看。
局限也要说清楚
有些东西写不出性质，比如界面布局好不好看、文案是否得体；生成器（generator）质量差，就只会生成千篇一律的输入，测了等于没测；纯随机还可能导致偶发失败，必须固定种子。所以属性测试通常和模糊测试（fuzzing）配合使用——后者更关心“会不会崩”，前者断言更丰富的性质。想找现成工具，可以看 Haskell 的 QuickCheck、Python 的 Hypothesis、JavaScript 的 fast-check 这类库，具体支持情况以各项目官方页面为准。
对从业者的意义
数据清洗、特征变换、序列化、分词器、分布式一致性协议，这类“输入空间很大、规则却很清晰”的代码最适合属性测试。比如“分词后再拼回来应还原原文”“数据增强不该改变标签”，写成性质后，机器会替你反复试。
对普通职场人来说，它其实是一种思维习惯：把“我觉得这样应该没问题”，改写成“无论什么情况都必须成立”。光是这一步，往往就能提前发现不少漏洞。