测试环境搭建

测试环境搭建这事儿，测试干过的环境人都懂，最怕的搭建不是环境本身多复杂，而是测试你花了一下午装好依赖，最后发现版本号差了一个小数点，环境整个服务起不来。搭建今天聊点实在的测试，直接说怎么搭、环境怎么避坑。搭建

先讲个真事。测试上个月我帮一个团队排查问题，环境他们的搭建测试环境跑了两周，突然某天接口全部超时。测试查了半天，环境发现是搭建有人手动在服务器上装了个新版本的数据库客户端，把系统自带的旧版给覆盖了。没人记得这事，但环境就这么废了。所以第一条铁律：测试环境必须脚本化、容器化，能自动化就别手动碰。

我习惯的做法是，用Docker Compose把中间件都编排起来。Redis、MySQL、Kafka，每个服务一个容器，端口映射到宿主机。配置文件统一放在一个目录里，用环境变量区分不同环境——开发、测试、预发，只改一个参数就行。刚开始可能会觉得麻烦，但一旦跑通，后面省心到你想哭。

但容器化不是万能药。有个坑我踩过好几次——网络模式。默认的bridge模式在单机测试够用，可一旦你要模拟多机部署或者测试跨服务调用，就得用自定义网络。否则容器之间用localhost访问，永远连不上，你还以为是代码写错了。这个细节，文档里写得含含糊糊，实际一跑就露馅。

数据是另一个大坑。测试环境最怕数据脏。我见过有人直接连生产库的备份来测，结果把线上用户信息改得一塌糊涂。正确做法是，每次跑测试前，用脚本重置数据库到基线状态。别嫌慢，一条`docker exec -i mysql sh -c 'exec mysql -uroot -p"$MYSQL_ROOT_PASSWORD"' < ./test_data.sql`就能搞定。数据量大的话，用定时任务凌晨自动恢复，早上来直接测，不耽误事。

还有依赖服务的mock。不是所有服务都值得起一个完整的实例。比如支付回调，你总不能真去调第三方接口。我常用WireMock或者MockServer，把预期响应写死在JSON文件里，测试代码里直接指定场景。好处是快，坏处是——你得维护这些mock数据。别偷懒，mock数据过期了比没有更可怕，因为它会让测试通过但实际功能是坏的。

说到验证环境是否可用，别光看进程起来了。写个健康检查接口，用curl或者脚本去探活，看返回的JSON是不是预期的。我见过太多人只看`docker ps`显示UP就觉得万事大吉，结果内部线程池没初始化，一压测就崩。检查要分层：端口通、接口有响应、关键数据能读写，三层都过了，才算真的好了。

最后说个没人提但很实际的事——给环境贴标签。比如“测试环境-张三专用-勿动”，或者“临时环境-可随时删除”。团队里总有人图方便，看到空闲的机器就拿来用，结果别人跑了一周的回归测试被一键清空。用标签钉死归属权，比任何权限管理都管用。别问我怎么知道的，说多了都是泪。

搭建测试环境不是一次性的活，它是个持续维护的过程。你越早把脚本化、容器化、数据隔离这三件事做扎实，后面就越少在半夜被叫起来处理环境问题。技术选型不重要，重要的是你愿不愿意花那半天时间，把重复劳动变成一次性投资。反正我是愿意的，毕竟，谁不想早点下班呢。