测试的最终目标不是追求某个数字，而是用尽可能少的用例，覆盖尽可能多的风险点。测试覆盖率是衡量“测了多少”的指标，边界用例设计则是决定“测得准不准”的关键手段。两者结合，才能真正提升测试的有效性。
19.4.1 测试覆盖率的真实含义
覆盖率工具（如 JaCoCo、Cobertura）通过对字节码插桩，追踪测试过程中哪些代码行、分支或方法被执行过。常见的覆盖率指标包括：
- 行覆盖率（Line Coverage）：被执行的代码行数占总行数的比例。
- 分支覆盖率（Branch Coverage）：在
if、switch、三元表达式等判断结构中，每个分支是否都被执行到。 - 方法覆盖率（Method Coverage）：方法是否被调用过。
- 路径覆盖率（Path Coverage）：理论上所有可能的执行路径是否被覆盖（通常难以做到100%）。
一个普遍的误区是高覆盖率等于高质量。100% 的行覆盖率只能说明每一行代码都被执行过，但无法保证逻辑正确性——很多 Bug 隐藏在“覆盖了但未验证行为”的灰色地带。因此，覆盖率指标应当用作发现测试盲区的工具，而非测试完成的唯一标准。
在实际项目中，更实用的做法是：
- 对核心业务逻辑（如订单计算、状态流转、金额处理）要求分支覆盖率 ≥ 80%，强制覆盖所有分支条件。
- 对简单的 getter/setter、配置类、常量定义等，可以明确排除（通过覆盖率工具的 exclude 配置），避免无意义的追逐。
- CI/CD 流水线中设置覆盖率阈值，低于阈值则构建失败，但允许对特殊文件人工豁免。
19.4.2 边界值分析：在“临界点”上找 Bug
绝大多数逻辑错误都出现在边界条件上：数组越界、数值溢出、等于或仅差一点点、空字符串、空集合、时间刚好到期的瞬间等。边界值分析（Boundary Value Analysis）的核心思想是：不仅要测正常值，更要特意挑选正好等于边界、刚好超出边界以及刚好在边界内的值。
以经典的年龄校验为例，假设业务规则为“年龄必须在 18 到 60 岁之间（含两端）”。等价类可以划分为：
| 等价类 | 代表值 | 预期结果 |
|--------|--------|----------|
| 有效年龄（内部） | 25, 40 | 通过 |
| 下边界 - 有效 | 18 | 通过 |
| 下边界前一个 | 17 | 失败 |
| 上边界 - 有效 | 60 | 通过 |
| 上边界后一个 | 61 | 失败 |
| 无效负值 | -1 | 失败 |
| 无效超大值 | 200 | 失败 |
在代码中，这类测试会覆盖到比较运算符（>=、<=）可能出现的 off-by-one 错误。比如有人误写了 if (age > 18 && age < 60)，那么刚好 18 岁就会被错误拒绝，边界测试能立即暴露问题。
19.4.3 常见边界类型与实战案例
1. 数值边界
重点关注零值、负数、最大/最小值、溢出点。例如在金额计算中，0.00 元、0.01 元、极大金额（如 Long.MAX_VALUE 分）以及负金额都是必测边界。
测试用例示例（Java & JUnit 5）：
@ParameterizedTest
@ValueSource(ints = {0, 1, -1, Integer.MAX_VALUE})
void shouldHandleEdgePrices(int amount) {
if (amount <= 0) {
assertThrows(IllegalArgumentException.class,
() -> service.process(amount));
} else {
assertDoesNotThrow(() -> service.process(amount));
}
}2. 字符串与集合边界
空字符串、空白字符串、超长字符串（超过数据库字段长度）、特殊字符、null 值等都是经典的边界。集合则需要测试空列表、单元素列表、刚好装满和即将溢出的列表。
@Test
void shouldRejectEmptyProductName() {
assertThrows(ValidationException.class,
() -> validator.validateName(""));
}
@Test
void shouldRejectNullProductList() {
assertThrows(ValidationException.class,
() -> orderService.createOrder(null));
}3. 时间与日期边界
时间逻辑中的边界包括：当天开始/结束时刻、闰秒、跨月、跨年、时区切换点。例如，一个优惠券的到期时间为“2025-12-31 23:59:59”，测试时必须构造一个恰好等于该时间的请求，验证是否仍有效，以及下一秒过期的请求是否被拒绝。
4. 并发与顺序边界
并发场景下的边界更多体现在时序上：两个线程同时修改同一资源、消息乱序到达、重试与幂等性。这类边界无法仅靠单元测试覆盖，需要结合集成测试或压力测试工具来验证。但依然可以在单元测试中使用 CyclicBarrier 等同步工具模拟并发边界。
@Test
void shouldPreventDuplicateOrderConcurrently() throws Exception {
CyclicBarrier barrier = new CyclicBarrier(2);
ExecutorService executor = Executors.newFixedThreadPool(2);
Future<Boolean> f1 = executor.submit(() -> {
barrier.await();
return service.submitOrder("same-request-id");
});
Future<Boolean> f2 = executor.submit(() -> {
barrier.await();
return service.submitOrder("same-request-id");
});
boolean r1 = f1.get();
boolean r2 = f2.get();
// 只有一个成功（幂等控制）
assertTrue(r1 ^ r2);
}19.4.4 将边界设计融入开发流程
边界用例不是一次性补全的任务，而应作为开发习惯持续执行：
- 需求评审阶段：识别关键业务规则，直接在需求文档或接口文档中标注出等价类和边界值，作为验收条件的一部分。
- 编码阶段：在方法注释中写出预期处理的边界，如
/* 产品数量 >= 1 且 <= 9999，超过则抛出异常 /，然后即刻编写对应测试。 - 代码审查阶段：评审者应特别检查边界条件是否有测试覆盖，尤其是
if分支和循环终止条件。 - 缺陷修复阶段：每个 Bug 修复后，必须补上至少一个边界用例，确保同类问题不再出现。
最后，覆盖率工具生成的报告需要与边界用例设计结合起来看待。如果一个方法达到了 100% 的分支覆盖率，但所有测试都是正常值，那么它的风险依然很高。只有将边界值分析植入测试设计的基因里，才能让测试从“走过场”变成真正的质量守卫。