去年冬天，测试逻辑我帮朋友排查一个线上故障。测试逻辑接口偶尔返回空数据，测试逻辑概率大概百分之三。测试逻辑开发查了两天，测试逻辑日志翻烂了，测试逻辑没找到原因。测试逻辑我让他把最近改动的测试逻辑代码发我看看。

他改了一个查询条件。测试逻辑原来的测试逻辑逻辑是：如果用户传了筛选参数，就按参数过滤；如果没传，测试逻辑就返回全部。测试逻辑他改成了：如果用户传了筛选参数，测试逻辑就按参数过滤；如果没传，测试逻辑就返回空。测试逻辑我问他为什么这么改，他说产品经理说“不传参数应该返回空，更安全”。

这就是典型的测试逻辑断裂。产品经理的意图是“避免误返回全量数据”，但开发实现成了“无参数即空”。测试的时候，开发只测了“传参数”的情况，没测“不传参数”的情况。而线上大部分请求恰恰是不传参数的。

逻辑不是流程，是因果链

很多人把测试逻辑理解成“按步骤执行”：打开页面、输入账号、点击登录、检查结果。这是操作流程，不是逻辑。逻辑是：因为用户输入了错误的密码，所以系统应该拒绝登录并提示错误。如果系统拒绝了但没提示，逻辑就断了。

我见过一个测试用例，写的是“验证登录功能正常”。这等于没写。正常是什么？输入正确账号密码返回成功？那输入错误密码呢？账号不存在呢？密码为空呢？账号被锁定呢？每个“因为”都要对应一个“所以”。缺一个，就是逻辑漏洞。

边界值不是数字游戏

教科书上说，边界值要测上点、离点、内点。比如输入范围1到100，要测0、1、2、99、100、101。这没错，但太机械了。

实际项目里，边界往往不是数字。比如一个文件上传功能，限制大小10MB。你测了9.9MB和10.1MB，都通过了。但你没测10MB整。更关键的是，你没测“上传过程中网络中断”。这才是真正的边界——异常边界。

我习惯把边界分成三类：数值边界、状态边界、时间边界。数值边界是大小、长度、数量。状态边界是登录/未登录、有权限/无权限、已支付/未支付。时间边界是超时、并发、顺序。这三类交叉起来，才是完整的边界测试。

测试逻辑的核心是“反证”

开发写代码是正向思维：输入A，经过B，得到C。测试要反过来：如果得到C，能不能推导出B一定执行了？如果不能，那B就可能没执行或者执行错了。

举个例子。一个电商下单接口，返回“下单成功”。你怎么知道库存真的扣了？怎么知道优惠券真的用了？怎么知道订单真的写库了？你不能只看接口返回。你要去查库存表、优惠券表、订单表。这就是反证。

很多测试人员只测“正向路径”，因为正向路径好写、好过。但bug往往藏在反向路径里。比如“下单成功但库存没扣”，这种bug在正向测试里永远发现不了。

逻辑覆盖不是越多越好

有人追求100%逻辑覆盖率，每个分支都测到。但分支覆盖不等于逻辑正确。比如一个if-else，你两个分支都测了，但if的条件写错了呢？条件里的变量用错了呢？

我见过一个案例：判断用户是否成年，代码写的是if (age > 18)。测试测了17和19，都通过了。但18岁呢？18岁在法律上是成年，但代码里>18排除了18。这个bug分支覆盖测不出来，因为17走else，19走if，都符合预期。只有测18才能发现。

所以测试逻辑不是“覆盖所有分支”，而是“覆盖所有等价类和边界”。等价类划分比分支覆盖更重要。

最后说一个真实教训

我曾经负责一个支付系统的测试。所有用例都通过了，上线后却出现重复扣款。查了两天，发现是并发问题：两个请求同时到达，都查了余额，都判断足够，都扣了款。测试的时候是单线程，永远测不出来。

从那以后，我写测试用例时，会专门加一列：“并发场景”。不是每个功能都需要，但涉及金额、库存、状态的，必须考虑。测试逻辑不只是功能逻辑，还包括并发逻辑、时序逻辑、异常逻辑。

逻辑这东西，看不见摸不着，但缺一块，系统就塌一块。测试不是点按钮，是推因果。