测试环境搭建详细教程

上个月，测试我帮一个初创团队排查线上事故，环境最后发现是搭建测试环境里数据库连接串写错了，指向了生产库的详细备份。那一刻我意识到，教程测试环境搭建这事儿，测试看着简单，环境坑起来真要命。搭建今天这篇，详细直接讲怎么搭一个能用的教程、不坑人的测试测试环境。

先把最核心的环境原则摆出来：测试环境必须和生产环境保持“逻辑等价”。不是搭建版本完全一致，而是详细依赖关系、配置结构、教程数据流走向要一致。比如生产用MySQL 8.0，你测试用5.7，那字符集排序规则不同，一个索引就可能导致慢查询，你查半天还以为是代码问题。

第一步，选机器。别用你笔记本上的Docker Desktop跑全套服务，内存不够，一跑就卡死。我习惯用一台独立的Linux虚拟机，4核8G起步，磁盘至少50G。装好Ubuntu 22.04 LTS，然后执行一条命令：
sudo apt update && sudo apt install -y docker.io docker-compose
这一步没什么技术含量，但很多人卡在权限上。记得把当前用户加入docker组：
sudo usermod -aG docker $USER
然后注销重新登录，不然每次都要sudo，烦死。

接下来是编排文件。我见过太多人直接拿生产K8s的YAML改两行就扔到测试环境，结果服务发现、配置挂载全乱套。测试环境最合适的是docker-compose.yml，单文件搞定所有依赖。下面这个是我常用的骨架：

 version: '3.8' services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: test123 MYSQL_DATABASE: app_db ports: - "3306:3306" volumes: - ./data/mysql:/var/lib/mysql redis: image: redis:7-alpine ports: - "6379:6379" app: build: . depends_on: - mysql - redis environment: DB_HOST: mysql REDIS_HOST: redis ports: - "8080:8080" 

注意看，我把mysql和redis的端口直接映射到宿主机了。为什么？因为测试时你需要用Navicat或者Redis Desktop Manager连进去看数据。你要是只暴露内部端口，每次都得exec进容器里查，效率低到让人想摔键盘。

数据初始化是另一个大坑。生产库有几百张表，测试环境不可能全量导入。我的做法是：写一个init.sql，只包含表结构、索引、以及一小部分脱敏后的业务数据。大概几百条记录就够用，重点是覆盖边界条件——比如用户表里要有一个空昵称的，订单表里要有一个金额为0的。这些极端数据，你跑单测时才会发现缺了它们，整个逻辑根本走不到异常分支。

然后说配置管理。测试环境的配置不能写死在代码里。我见过某团队把测试数据库密码硬编码在application.yml里，结果代码一泄露，整个测试库被人删了。正确做法是用环境变量注入，比如Spring Boot项目，在bootstrap.yml里写：
spring.datasource.password: ${ DB_PASSWORD}
然后在docker-compose里通过environment传入。这样你换环境时，只改环境变量，代码一行不动。

启动顺序也别忽略。docker-compose的depends_on只控制容器启动顺序，不保证服务就绪。MySQL启动到能接受连接，可能要花10到20秒。你要是在app容器里一启动就连数据库，大概率报错。简单粗暴的解决办法是在app的启动脚本里加个重试循环：
for i in { 1..30}; do nc -z mysql 3306 && break; sleep 2; done
这招土，但管用。别用那些复杂的健康检查工具，小团队没时间折腾。

最后，验证环境是否可用。别光看容器状态是up就完事了。写一个冒烟测试脚本，比如curl一下健康检查接口，或者执行一条最简单的SQL查询。我习惯用docker-compose ps看状态，再用curl localhost:8080/actuator/health确认应用真的起来了。如果返回{ "status":"UP"}，才算搭好。否则，你后面写代码时才发现环境有问题，那调试时间直接翻倍。

测试环境搭建，本质上就三件事：依赖隔离、配置外部化、数据可控。把这三件事做到位，后面开发效率能提升一半。那些总说“我本地跑得好好的啊”的人，多半就是测试环境没搭好，导致环境差异全堆到线上才暴露。