14年接口测试老兵的失败反哺心法

　　去年六月那场事故，我现在想起来还后槽牙发酸。当时测试环境里有个支付接口，参数校验写得跟筛子似的——我原以为这种老系统大家都门儿清，结果测试用例覆盖漏了小数点后两位的金额校验。线上跑起来，某个合作方传了个带三位小数的金额，直接把订单状态卡死在“待支付”，用户那边疯狂刷页面，客服电话被打爆，运维半夜爬起来查日志，机器嗡嗡响得跟拖拉机似的。

　　那会儿我蹲在工位上改测试用例，旁边小张叼着辣条刷手机，突然抬头说：“哥，你说咱这接口测试是不是越测越怂？”我手一抖，键盘敲出俩错别字——他这话戳到痛处了。我们组那会儿刚接了个新项目，测试用例写得比字典还厚，连“用户ID为空但手机号正确”这种边缘场景都覆盖了，结果上线还是出问题。后来复盘发现，根本不是用例不够，是有些接口的逻辑太野，连开发自己都没理清楚。

　　我后来跟开发老王吵过一架。他说：“你们测试就是太死板，非得按文档来，实际业务哪有那么规范？”我拍桌子怼回去：“那你们开发倒是把文档写清楚啊！上次那个用户权限接口，文档里写‘管理员可操作’，结果代码里偷偷加了‘创建时间超过30天的用户不可操作’，这谁能测出来？”他搓了搓手指，低头说：“那是临时加的，没来得及更新文档。”我气得直笑——这种“临时加”的逻辑，最后都成了测试的坑。

文章配图，仅供参考

　　对了，那天复盘会开到一半，外卖小哥敲门送奶茶，我顺手接了，发现是冰的——我明明点的热饮。这事儿跟接口测试没关系，但我现在想起来还觉得憋屈——连外卖都能搞错，更别说接口了。后来我跟团队说：“别太信文档，也别太信开发，更别太信自己。测试用例得像筛子，筛得越细，漏的越少。”

　　我原以为“优胜劣汰”是句空话，结果在接口测试里真能落地。去年我们组淘汰了三个测试工具——一个是因为不支持异步接口的并发测试，一个是因为日志分析太慢，还有一个是因为……记不清了，好像是界面太丑？反正用着不顺手的工具，最后都会被扔进垃圾桶。反倒是那些“难用但稳定”的工具，比如Postman，用了八年还在用——虽然它界面丑得像上世纪的产品，但至少不会突然崩溃。

　　现在我带新人，第一句话就是：“别怕测出问题，怕的是测不出问题。”上个月有个新人测支付接口，传了个超大的金额，把系统搞崩溃了。他慌得直搓手，问我：“哥，我是不是闯祸了？”我拍拍他肩膀：“干得漂亮！这种极端情况现在不测，上线后就是事故。”后来我们针对大金额场景加了压力测试，现在那个接口稳得像块石头。

　　但我也得承认，有些失败是测不出来的。比如去年那个合作方接口，文档写得清清楚楚，测试用例也覆盖了所有场景，结果上线后他们偷偷改了逻辑——把“用户ID”换成了“设备ID”，连通知都没发。我们监控到异常流量时，已经影响了两千多个用户。这事儿后来我跟合作方负责人吵了一架，他居然说：“我们以为你们能自动适配……”我气得直接挂了电话——这种“以为”，就是接口测试最大的敌人。

　　现在我还是会偶尔漏测，但漏得少了。上个月测一个新接口，我盯着文档看了半小时，突然觉得哪里不对——文档里写“状态码200表示成功”，但代码里有个隐藏逻辑：如果用户余额不足，会返回200但带错误信息。我赶紧补了用例，结果真测出个bug。开发老王看到测试报告时，叹了口气说：“你们测试真是越来越刁钻了。”我笑了笑——刁钻点好，刁钻点能少挨骂。

　　至于“失败反哺心法”到底有没有用？我说不准。但有一点我敢打包票：接口测试这行，没有“一劳永逸”这回事。今天测通的接口，明天可能因为开发改了一行代码就崩；今天漏掉的场景，明天可能就成了线上事故。所以别信什么“最佳实践”，也别信什么“万能用例”——测得越多，越觉得自己像个傻子。但至少，当傻子当久了，能少踩点坑。

　　对了，昨天下班时，我发现工位上的绿萝死了——可能是忘了浇水，也可能是根烂了。这事儿跟接口测试也没关系，但我现在觉得，测试和养植物有点像：都得耐心，都得细心，都得随时准备应对意外。至于能不能养活，能不能测准……谁知道呢？先干着再说。

（编辑：我爱制作网_沈阳站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!