上周三下午，测试我在公司内部测试环境里点开了一个刚部署上线的测试页面。页面加载用了4.7秒，测试白屏期间我以为服务器挂了。测试刷新第二次，测试3.2秒。测试第三次，测试正常了，测试1.1秒。测试这种波动本身就说明问题——缓存没配好，测试或者数据库连接池在冷启动时抢不到资源。测试我截了图，测试丢进项目群，测试附了一句“这玩意儿上线必炸”。测试没人回我。测试第二天上午，同样的页面在预发布环境里，又卡了。

测试的网站跟正式网站最大的区别，不是域名多一个“test”前缀，也不是页面顶部那条黄底黑字的警告横幅。真正的区别在于，测试站承受的“恶意”远比正式站多。开发随手传个10MB的未压缩图片，测试人员故意在输入框里塞SQL注入字符串，产品经理反复点击提交按钮看会不会重复下单。正式用户不会这么干。他们只会正常操作，然后在你最想不到的地方卡住。

我见过一个测试站，登录功能在Chrome里正常，在Safari里输入密码后光标直接消失。前端查了两小时，发现是一个CSS的caret-color属性写成了transparent。这种bug在测试阶段不修，上线后就是客服电话被打爆。但测试人员往往只用自己的主力浏览器，Safari？那是“有空再测”的选项。

还有一个更隐蔽的问题：测试站的数据。很多团队直接拿生产库的脱敏数据往测试环境灌。听着挺合理，但脱敏脚本经常漏字段。我见过用户手机号中间四位被星号替换了，结果地址栏里的收货人姓名还是真名。测试站没有HTTPS，或者证书过期了没人管。浏览器地址栏那个“不安全”红色警告，测试人员点“继续访问”点习惯了，正式用户看到直接关页面。

性能测试最容易被糊弄。开发在本地跑个ab -n 100 -c 10，看着QPS有200，就说“没问题”。实际上测试站和正式站的硬件配置差了三档。测试站跑在2核4G的虚拟机上，正式站是8核16G的容器集群。你在测试站压出来的200 QPS，到了正式站可能因为负载均衡策略不同、数据库连接数限制、甚至防火墙规则，直接掉到20。更别说测试站通常没有CDN，静态资源全走源站。正式站一上CDN，缓存命中率一上来，表现完全两码事。

我现在的习惯是，任何测试站上线前，先手动做三件事。第一，用手机4G网络打开，不是连公司WiFi。第二，把浏览器缓存清干净，模拟第一次访问的用户。第三，在输入框里粘贴一段5000字的文本，看后端有没有做长度校验。这三招能筛掉八成低级问题。

测试站就像工地上的样板间。看着跟交付标准一样，但墙里的电线可能是临时拉的，水管接口没缠生料带。你站在样板间里觉得“挺好”，等真住进去，楼下邻居一冲马桶，你家天花板就渗水。所以别太信测试站的表现。它只能告诉你“功能大概能跑”，不能告诉你“用户会舒服”。舒服这件事，得靠正式环境里真实流量去磨。磨到某个凌晨三点，你被报警短信吵醒，爬起来改配置，那才是真正的测试。