测试 前端 后端

凌晨两点，测试我盯着屏幕上那个红色的前端报错框，第无数次怀疑自己是后端不是选错了行。前端说接口没问题，测试后端说参数传错了，前端产品经理在群里发了个问号。后端这种场景，测试干过测试的前端人都懂——我们不是写代码的人，却是后端最清楚代码怎么烂掉的人。

上周我们上线一个支付功能，测试前端页面写得花团锦簇，前端按钮动画比苹果发布会还炫。后端后端接口文档写得像天书，测试字段命名用拼音缩写，前端连注释都没一句。后端测试环境跑得欢，一到预发布就崩。查了半天，前端把时间戳当字符串传，后端拿它做数值运算，两边都觉得对方是傻逼。最后我翻出三年前的旧代码，发现同样的坑早就踩过，只是当时写代码的人离职了，文档跟着他一起消失了。

这种事见多了，我反而觉得测试这活儿有意思。你得像侦探一样，从前端的交互逻辑里嗅出后端的脾气。按钮点了没反应，可能是JS报错，也可能是接口超时，还可能是数据库锁表。有一次我排查一个加载慢的问题，从前端网络请求看到后端SQL语句，最后发现是运维把缓存服务器IP配错了。你说这算谁的锅？谁都不算，但用户只会觉得你们整个团队是废物。

后来我学乖了，不再纠结于“谁对谁错”这种小学生问题。测试的本质是找茬，但找茬的目的是让两边的人坐在一起，把话说人话。我拉了个群，逼着前端和后端每周对一次接口文档，用最笨的方法——把每个字段的用途写在纸上，贴在白板上。丑是丑了点，但至少没人再甩锅了。

有个后端同事跟我说，他最喜欢我提的bug，因为描述里连复现步骤、环境版本、日志截图都齐了，他直接复制粘贴就能定位。我心想，这不是基本素养吗？但后来我发现，很多测试连“预期结果”和“实际结果”都分不清，只会截图甩到群里喊“这有问题”。你问他什么问题，他说“就是不对”。这种测试，前端恨，后端也恨，因为大家得陪他玩猜谜游戏。

其实前端和后端就像一对闹别扭的夫妻，测试就是那个劝架的邻居。劝得好，两边各退一步，功能顺利上线；劝不好，两边互相拉黑，项目延期。我见过最极端的例子，前端为了等后端修接口，直接在代码里写死假数据，结果上线忘了改，用户看到的是满屏的“测试数据123”。后端呢，觉得前端催得烦，故意把响应时间拖到10秒，就为了让前端“感受一下什么叫真正的慢”。

这种恶性循环，靠流程制度根本治不了。真正管用的，是让前端写几个简单的单元测试，让后端把接口文档当亲儿子养，再让测试在提bug的时候多打几个字，说清楚“在什么环境下、点了什么、看到了什么、期望是什么”。听起来像废话，但能做到的人不到一半。

我干测试五年，最大的感悟是：这活儿不是用来“验证正确”的，是用来“暴露愚蠢”的。代码里的愚蠢、沟通里的愚蠢、流程里的愚蠢，全得靠测试一层层扒出来。所以别抱怨测试烦人，烦人是因为你们太蠢。等哪天前端和后端能自己把问题聊清楚，测试就可以下岗了——但我知道，那天永远不会来。