测试漏洞

测试漏洞这回事，测试漏洞我见过最荒唐的测试漏洞一次，是测试漏洞在银行核心系统里。

那是测试漏洞个转账模块，金额校验写得天衣无缝——正数、测试漏洞上限、测试漏洞余额，测试漏洞层层把关。测试漏洞可偏偏漏了个不起眼的测试漏洞角落：当金额是负数时，整数部分能通过校验，测试漏洞但小数部分直接被丢掉。测试漏洞结果呢？测试漏洞你转-0.01元，系统只校验整数0，测试漏洞然后实际扣款时，测试漏洞它把你的测试漏洞余额多扣了一分钱。对，你没看错，是往你账户里多扣一分钱，不是少扣。那个测试用例写的是"-0.01"，开发人员一看是负数直接跳过了，测试人员呢，压根没想过负数能进到这一步。

后来怎么发现的？一个客户投诉说账户少了0.01元，客服查了半天，发现是系统退款时反向操作导致的。整个团队盯着那行代码看了半小时，才有人小声说：“这地方...是不是得加个绝对值判断？”

这事让我想起另一个更经典的漏洞——时间。你看，很多系统测试时都爱用当前时间，或者干脆写死一个“2024-01-01”。可时间这东西会变啊，跨年、闰秒、夏令时，哪个不是坑？我认识一个做航空订票系统的哥们，他们系统在2019年3月31日那天大面积崩溃，因为欧洲那天换夏令时，他们的时间处理逻辑没考虑“时钟往前跳一小时”的情况。所有航班起降时间全乱了，乘客在机场干等，客服电话被打爆。修复方案倒是简单——加个if判断，可谁能在测试时想到，时钟会“凭空消失”一小时呢？

测试漏洞往往不是技术问题，是想象力问题。你测试的是“正常情况”，可现实世界从来不给“正常情况”面子。有次我在一个电商平台做测试，发现购物车里的商品价格在凌晨12点整会突然变成0。排查下来，是促销模块的定时任务在跨天时，把“开始时间”和“结束时间”搞混了——它们用了同一个时间戳，只是时区换算时差了8小时。你说这算谁的错？开发觉得是需求没写清楚，测试觉得是开发没理解需求，产品经理觉得是测试用例没覆盖边界。

说真的，我见过太多测试报告写得漂漂亮亮，覆盖率95%以上，缺陷数清零，可一上线就出幺蛾子。为啥？因为那些测试用例都是“照着需求写”的，需求里没写的，测试自然不测。可真正的漏洞，恰恰藏在需求没写的那些地方。

后来我学乖了，测试时专门挑“不合理”的输入——负数、超大数、空字符串、emoji、SQL注入语句、甚至直接把字段删了。同事笑我神经质，可每次都能捞出几个真问题。前阵子测一个登录功能，我随手在密码框里粘贴了一段乱码，结果系统提示“密码格式错误”，但日志里显示那段乱码被原样存进了数据库。你猜怎么着？这个“错误”密码，居然能直接登录——因为登录时它只比对前8位，而那段乱码的前8位恰好和某个用户的密码一致。

测试漏洞的本质，是我们总假设系统会按预期运行，可它偏偏喜欢在不经意间耍脾气。你堵住一个洞，它从另一个洞冒出来。就像打地鼠，永远打不完，但至少你得盯着那些最不起眼的角落——往往最致命的问题，就藏在你觉得“不可能出错”的地方。