从防御性编程到混沌工程
📖 目录导读
- 异常测试的本质：为什么代码需要“不完美”验证？
- 核心原理解剖：6大异常触发机制与应对策略
- 实战问答：如何设计让代码“崩溃”的黄金用例？
- 工具与框架：从JUnit到Chaos Monkey的演化路径
- 行业误区：90%的团队错误理解“异常覆盖率”
异常测试的本质：代码的“疫苗”机制
Q：源码级别测试已经覆盖所有分支，为什么还需要专项异常场景测试？
A： 常规单元测试验证的是“代码按预期运行”，而异常场景测试验证的是“代码在非预期环境下如何生存”，根据Google Testing Blog统计，生产环境中70%的故障源于未预料到的外部依赖异常（如数据库连接超时、第三方API返回空指针、内存溢出等）。异常测试的本质是模拟“反模式”输入或环境失控，强制代码暴露隐式假设的脆弱性。
关键原理：
- 防御性编程的盲区：代码中的
try-catch可能仅处理了文档中列出的异常类型，但实际环境可能抛出子类、自定义异常或链式异常（如NullPointerException被包装在RuntimeException中）。 - 隐式依赖陷阱：即使代码正确，依赖的运行时状态（如时区、语言环境、磁盘空间）变化可能触发未预期的行为。
Locale.getDefault()在CI/CD环境突然返回en_US而非zh_CN时，日期格式化函数可能抛出异常。
核心原理解剖：6大异常触发机制
1 输入噪声原理
向方法传递合法但边界外的数据：
- 空对象（
null）、空集合、负值、极大值（Integer.MAX_VALUE + 1引发溢出）。 - 非ASCII字符串、超长字符串（MySQL的VARCHAR(255)被传入300字符时触发截断异常）。
案例： 某支付系统因未验证金额字段的decimal位数，用户输入001时，数据库四舍五入后直接触发DataTruncation，导致订单状态不一致。
2 资源枯竭原理
模拟系统资源耗尽的连锁反应：
- 内存溢出（分配超大数据对象）、文件句柄耗尽（循环打开文件不关闭）、线程池队列满（拒绝执行
RejectedExecutionException）。
关键发现： 消息队列消费者在Kafka分区重平衡时，若线程池耗尽，会导致OffsetOutOfRangeException不被捕获，引发消费者组永久卡死。
3 时间扭曲原理
模拟异步操作超时或僵尸进程：
- 数据库连接
timeout=5s，但真实网络延迟突然升至15秒。 - 过期锁（带TTL的分布式锁在持有期间被自动释放，导致重复执行）。
问答： 如何测试代码对“半开连接”的容忍度？
工具方案： 使用Hystrix的fallback机制配合MockServer随机返回Connection reset by peer，验证电路断路器是否在连续失败后自动熔断，并在“半开”状态下正确重试。
4 版本漂移原理
依赖库升级时接口突变：
- JSON序列化库从
FastJson切换到Jackson后，@JsonSerialize注解行为不一致。 - 数据库迁移：旧版MySQL的
utf8mb3字符集在新版中报Incorrect string value。
实战策略： 在CI/CD中设置兼容性矩阵测试，使用diff工具对比新旧版本对相同输入的输出结果，而非仅验证无异常抛出。
实战问答：如何设计“杀死代码”的黄金用例？
Q：异常场景用例是否越多越好？
A： 否，过度测试会陷入“覆盖幻觉” —— 须遵循80/20法则：
| 测试类型 | 优先级 | 示例 |
|---|---|---|
| 输入边界 | P0 | 空字符串、负数、NaN（Double.NaN比较行为） |
| 资源竞争 | P0 | 多线程对同一集合的并发读写（ConcurrentModificationException） |
| 外部依赖中断 | P0 | 数据库连接池耗尽、Redis超时导致JedisConnectionException |
| 环境差异 | P1 | 文件路径分隔符（Windows的 vs Linux的） |
| 极端负载 | P1 | 单进程处理10万条消息时触发OutOfMemoryError |
设计公式： 异常用例数 = 方法中try-catch块数量 × 3（至少覆盖：显式抛出的异常类型、其超类、以及未预期的异常）。
工具与框架：从JUnit到Chaos Monkey的演化
- JUnit 5 + AssertJ：通过
assertThatThrownBy验证异常信息片段，而非简单expect(SomeException.class)。 - Faker库：生成随机恶意数据（如邮箱格式“abc@@def”，Unicode零宽度字符注入）。
- Chaos Monkey for Spring Boot：在生产环境注入随机故障（如强制抛出
TimeoutException），验证熔断器的正确行为。 - Resilience4j：在单元测试中通过
RetryConfig.custom().maxAttempts(3)模拟连续失败后成功。
反直觉真相： 许多团队对异常测试的“断言”仅停留在assertThrows(RuntimeException.class)，而忽略了异常中的错误消息内容，使用assertThat(exception.getMessage()).contains("orderId")可检验错误上下文是否对排查问题有价值。
行业误区：90%的团队错误理解“异常覆盖率”
误区1： “异常覆盖率=try-catch覆盖的行数”——❌
纠正： 真正的覆盖率是已知异常路径数量 / 被触发的异常类型数量，即使每行都有catch，若catch分支使用e.printStackTrace()（忽略异常），其防御效果为0。
误区2： “生产环境有Sentry监控，无需预测异常”——❌
事实： Sentry只能捕获已发生的异常，而程序可能在此前已进入不安全状态（如局部变量因null被提前修改，后续逻辑未触发异常但结果错误）。
最佳实践：
- 对每个外部调用添加遥测断点：在方法入口记录输入参数，异常时对比预期日志。
- 使用模糊测试（Fuzz Testing），自动生成非法参数：例如
RestAssured传递{“price”:“abc”}验证JSON解析器在Jackson中的异常处理。 - 定期执行Chaos Engineering演练：在预发布环境随机关闭一台数据库节点，验证应用是否能优雅降级（如显示缓存数据而非抛出HTTP 500）。
异常场景测试不是“找茬”，而是代码的免疫力锻炼，真正的原理在于强制系统在失控状态下维持可观测性、可恢复性和可解释性。最可怕的异常不是被抛出的，而是被静默吞没的 —— 就像《三体》中的“黑暗森林”法则，未知异常才是系统崩溃的终极导火索。
标签： 测试原理