上线前三天，平台支付模块的测试测试用例只跑了不到六成。不是平台不想跑，是测试环境又挂了。这已经是平台本周第三次。测试同学在群里发了个截图，测试日志里一行红字：连接池耗尽。平台开发说配置没问题，测试运维说机器负载正常。平台没人知道问题出在哪，测试但所有人都知道，平台再不解决，测试上线就得延期。平台

这就是测试平台测试最真实的样子。它不是平台一份漂亮的文档，也不是某个自动化工具跑出来的绿色报告。它是一堆人围着同一个问题转，转到最后发现，问题根本不在代码里。

先搞清楚测什么

平台类系统和普通业务系统不一样。业务系统测的是功能对不对，平台测的是别人用你的平台时会不会崩。这两件事的难度差了一个量级。你没法预判所有调用方会怎么用你的接口，也没法保证每个上游系统的数据都规规矩矩。

去年我们做开放平台，接口文档写了三百多页。测试阶段找了个外部团队做接入模拟，对方上来就传了个字段类型不对的参数。按文档，这个字段应该是字符串，他传了个数组。结果整个解析层直接抛异常，连带把消息队列堵了。一个字段，堵了四十分钟。

所以平台测试的第一件事，不是写用例，是先列出所有可能被误用的入口。参数类型、边界值、并发量、调用频率、鉴权方式，每一个都得当成会被踩的坑来对待。

环境比用例更折腾

平台系统依赖的东西太多了。数据库、缓存、消息队列、配置中心、注册中心、网关，少一个都跑不起来。本地开发环境能跑通，到了测试环境就各种超时。查半天发现是网络策略没开，或者某个中间件版本不一致。

我们的做法是，把环境检查做成一个脚本。每次部署完自动跑一遍，把每个依赖的连通性、版本号、关键配置全打出来。谁的环境有问题，自己看输出。这招省了至少一半的扯皮时间。

还有数据。平台测试的数据不能随便造，得符合业务规则。用户ID得是真实的格式，订单号得有校验位，金额字段不能超过系统上限。我们专门写了个数据工厂，按规则生成测试数据，跑完自动清理。不清理的话，下次跑用例全是脏数据冲突。

性能测试要卡在真实场景上

压测最容易自欺欺人。你拿一百个线程去压一个接口，报告很漂亮，QPS两千。上线后真实流量一进来，三百个并发就挂了。为什么？因为真实调用不是均匀的，有突发，有重试，有慢查询叠加。

我们后来改策略，压测场景必须包含三样东西：正常流量、突发流量、以及一个依赖服务的延迟注入。比如把数据库响应时间人为调慢两百毫秒，看系统还能不能撑住。这个比单纯加线程数有用得多。

有一次压测发现，网关层在并发超过五百时开始丢包。查到最后是连接池配置写死了，没根据CPU核数动态调整。改了一行配置，问题消失。这种问题，不压到那个量级根本看不见。

上线不是终点

平台测试有个特点，你永远没法在上线前测完所有情况。所以灰度发布和回滚机制必须提前验证。我们的规矩是，任何平台变更，先切百分之一的流量，观察半小时。指标正常再逐步放量。回滚脚本必须在上线前跑一遍，确认能在三分钟内恢复。

有次上线一个新路由规则，灰度期间发现某个老客户端的请求被错误路由了。因为规则里少写了一个条件。好在只影响了百分之一的流量，回滚后五分钟恢复。要是全量上线，那个客户端的几万用户全得报错。

平台测试方案不用写得太厚。把环境检查、数据工厂、误用清单、压测场景、灰度回滚这几件事说清楚，比堆一百页用例有用。剩下的，靠上线后盯着监控，随时准备动手。