逻辑盲区（上）：条件覆盖不足、分支覆盖遗漏、边界值缺失

各位好，今天我们聊聊逻辑盲区。说白了，就是你的测试用例看起来跑过了，但代码里的逻辑分支根本没被真正触达。我见过太多项目，覆盖率报告漂漂亮亮，线上却出了大问题。为什么？因为覆盖率的数字会骗人。

我个人习惯把逻辑盲区分成三类：条件覆盖不足、分支覆盖遗漏、边界值缺失。这三兄弟，任何一个没处理好，都可能成为线上事故的导火索。

一、条件覆盖不足：你以为测了，其实没有

先看一个最简单的例子。你写了个判断逻辑：

if (a > 0 && b > 0) {
    // 执行操作A
} else {
    // 执行操作B
}

很多同学写测试用例时，只测了 a=1, b=1 和 a=0, b=0 两组数据。覆盖率报告显示：语句覆盖100%，分支覆盖100%。完美！

但等等，你想想看——a=1, b=0 这个组合测了吗？a=0, b=1 呢？

这就是条件覆盖不足。语句覆盖和分支覆盖只看整体结果，但没关注每个子条件的真假情况。我在项目中遇到过类似问题，一个支付系统的风控逻辑，条件组合没覆盖全，结果某个特殊场景下风控误判，把正常用户给拦截了。

我建议你在写测试用例时，别只看最终的分支走向。把每个条件拆开，列个真值表，一个一个核对。虽然麻烦，但值得。

二、分支覆盖遗漏：else 分支的隐形陷阱

分支覆盖遗漏，说白了就是有些分支你压根没走到。最常见的就是 else 分支被忽略。

举个例子：

if (user.isVip()) {
    // 处理VIP用户
} else if (user.isNewUser()) {
    // 处理新用户
} else {
    // 处理普通用户
}

很多测试同学会测 VIP 用户和新用户，但普通用户那个 else 分支呢？嗯，经常被遗忘。为什么？因为测试数据构造起来麻烦，或者觉得「普通用户没什么特殊逻辑」。

我曾经就吃过这个亏。一个优惠券发放系统，else 分支里有个隐藏的 bug——普通用户领券时，优惠券状态更新逻辑写反了。线上跑了三天，才发现几千个用户领了券但没扣减库存。那叫一个惨。

怎么避免？我有个小技巧：写代码时，每个 if-else 结构都强制自己先写 else 分支的测试用例，再写 if 分支的。这样能倒逼你思考「不满足条件时会发生什么」。

三、边界值缺失：临界点最容易出问题

边界值缺失，这个大家应该不陌生。但为什么总是漏？我观察下来，原因有两个：一是觉得边界值「差不多就行」，二是对边界值的理解停留在表面。

看个典型例子：

if (score >= 60) {
    // 及格
} else {
    // 不及格
}

边界值是什么？很多人会说：59、60、61。没错，但不够。

你想想看，如果 score 是浮点数呢？59.9 算不算边界？60.0 呢？如果 score 是整数，那 0 和 100 呢？还有负数呢？

我建议你记住边界值测试的「三件套」：

边界类型	测试值	说明
上点	边界值本身	比如 60
离点	边界值相邻的值	比如 59 和 61
内点	边界范围内的典型值	比如 80

但光记住这三个还不够。真正容易漏的是「隐含边界」。比如数组下标、字符串长度、时间戳范围、金额精度……这些边界往往藏在业务逻辑里，代码里不会直接写出来。

四、三种盲区的关联与诊断

这三种盲区不是孤立的。条件覆盖不足会导致分支覆盖遗漏，边界值缺失又会让条件覆盖不完整。它们互相影响，形成一个恶性循环。

我画了一张图，帮你理清它们的关系：

这张图想表达的是：三种盲区互相影响，诊断时不能孤立地看。我个人的做法是，先做条件覆盖分析，再枚举所有分支路径，最后补充边界值。三步走完，基本能把盲区扫干净。

五、实战建议

说了这么多，最后给几个能落地的小建议：

• 写测试用例前，先画逻辑流程图。把每个条件、每个分支、每个边界都标出来。画完你就知道哪里可能漏了。
• 别信覆盖率工具的数字。工具只能告诉你「哪些代码被执行了」，但没法告诉你「哪些逻辑组合没被验证」。我见过覆盖率 95% 的项目，线上照样出大问题。
• 建立检查清单。每次评审测试用例时，对照条件覆盖、分支覆盖、边界值三个维度逐一检查。形成习惯后，盲区会越来越少。

好了，逻辑盲区（上）就聊到这里。记住：测试不是为了证明代码没问题，而是为了找出那些你没想到的问题。条件覆盖、分支覆盖、边界值，这三个基本功打扎实了，很多坑自然就绕过去了。

可可精品资料库