测试三字经

凌晨两点，测试字经李工盯着屏幕上那条刺眼的测试字经红色报错，手里的测试字经咖啡已经凉透。他刚改完的测试字经支付接口，本地跑得好好的测试字经，一上预发环境就崩。测试字经日志翻了十几遍，测试字经最后发现是测试字经测试环境里一个老账号的余额字段被写成了负数——三年前就没人动过的脏数据。这事儿让他想起刚入行时，测试字经师父扔过来的测试字经一句话：“别信自己写的代码，更别信别人留的测试字经数据。”

测试这行，测试字经说穿了就是测试字经跟“想当然”三个字死磕。开发觉得逻辑天衣无缝，测试字经产品觉得流程顺理成章，测试字经运维觉得部署万无一失。你偏要问一句：万一呢？

先拆再测，别急着上手点

见过太多新人，拿到需求文档就开始写用例，一行行“点击按钮”“输入文本”列得整整齐齐。结果呢？漏了最关键的一条——用户没登录直接访问支付页会怎样。测试不是照着说明书走一遍，那是验收，不是测试。

我习惯先画一张图。把功能拆成最小的原子操作，每个原子问三个问题：正常输入给什么？边界值在哪？异常情况怎么触发？比如一个登录框，正常输手机号密码，边界是手机号10位或12位，异常是密码里带空格、账号被锁定、验证码过期。拆到这一步，用例自然就冒出来了，不用硬憋。

数据比代码更会骗人

去年帮一个团队查线上Bug，订单金额偶尔多出0.01元。代码逻辑查了三天没毛病，最后发现是测试库里有个商品价格字段是浮点数，0.1+0.2在计算机里不等于0.3。这种坑，你盯着业务代码看一辈子也看不出来。测试数据得自己造，别偷懒用生产脱敏数据——那些数据里藏着历史遗留的脏值、测试账号的硬编码、甚至前几任开发留下的“临时方案”。

造数据有个笨办法但管用：每次测试前，把数据库相关表清空，用脚本重新灌一套干净的。多花十分钟，省下三小时排查。

自动化不是万能药

老板总爱说“上自动化，提效”。可你见过维护成本比手工测试还高的自动化脚本吗？我见过。一个电商项目，UI自动化脚本写了八百条，每次前端改个按钮ID，得改两百条定位。后来团队学乖了，只把核心链路——登录、下单、支付——做成接口自动化，UI层全靠手工探索。跑一轮接口脚本十五分钟，覆盖了80%的高危场景。剩下的20%，靠人脑去点、去猜、去使坏。

自动化适合什么？回归测试、数据校验、批量接口。不适合什么？UI频繁变动的页面、需要视觉判断的场景、还有那种“说不上哪里不对但就是感觉有问题”的玄学Bug。

别当只会点按钮的工具人

测试工程师的价值不在发现多少Bug，而在判断哪个Bug值得修。一个错别字和一笔金额算错，优先级天差地别。你得懂业务：这个功能上线后谁用？用错了会赔钱还是只是难看？你得懂技术：这个报错是前端拦截了还是后端根本没返回？你得懂沟通：开发说“这不是Bug”时，你能拿出日志、录屏、复现步骤，而不是一句“我这边就是有问题”。

入行第五年，我养成了一个习惯：每次提Bug前，先问自己——如果我是开发，看到这个单子会服气吗？会立刻去改吗？如果答案是否定的，那就再挖深一点。测试的底气，从来不是“我点了，它错了”，而是“我知道它为什么错，还知道怎么让它不再错”。

凌晨三点，李工终于把那行脏数据清了，接口通了。他关掉电脑，心想：明天得给测试环境加个数据校验脚本。这行干久了，看什么都像Bug——包括自己昨晚没洗的咖啡杯。

很赞哦!（91）