测试环境如何搭建

上周帮一个朋友排查线上bug，测试他本地跑得好好的环境何搭，一到测试环境就挂。测试查了半天，环境何搭发现是测试测试环境的Redis连的是另一套，缓存key前缀没对上。环境何搭这种事太常见了——测试环境搭得随意，测试后面填坑的环境何搭时间比写代码还多。

测试环境的测试核心就一句话：让代码在接近真实的环境里跑，但别把生产数据搅进来。环境何搭听起来简单，测试做起来全是环境何搭细节。

先想清楚要测什么

不是测试所有项目都需要一套完整的测试环境。一个内部工具，环境何搭可能一台机器跑个Docker就够了。测试但如果是电商系统，涉及支付、库存、订单，那就得认真对待。

我一般会问三个问题：需要模拟多少并发？依赖多少外部服务？数据要不要隔离？答案不同，搭建方式差很远。

见过太多团队，测试环境上来就搞Kubernetes集群，结果运维成本比开发还高。如果团队不到十个人，用Docker Compose完全够用。一台4核8G的云服务器，跑五六个容器绰绰有余。

数据库建议单独一台机器，或者至少单独一个实例。测试环境最怕的就是数据库被污染——A同学跑了个批量删除，B同学的测试数据全没了。给每个开发者分配独立的database，或者用schema隔离，成本很低，收益很大。

中间件这块，Redis、RabbitMQ、Nginx，能用Docker就别装宿主机。配置写在docker-compose.yml里，版本控制一提交，谁都能一键拉起。

把数据库密码、API密钥硬编码在代码里，然后提交到Git——这种事每年都能遇到几次。测试环境的配置必须走环境变量，或者独立的配置文件，且这个文件不能进版本库。

我习惯用.env文件加docker-compose的env_file指令。本地开发一套，测试环境一套，生产环境一套。切换的时候只改环境变量，代码一行不动。

还有个坑：测试环境的第三方服务。支付网关、短信服务、地图API，这些在测试环境通常用沙箱或者Mock。别图省事直接连生产密钥，一不小心就发真实短信出去。

直接从生产库拖数据到测试环境，看起来方便，实则危险。用户手机号、地址、订单金额，全是敏感信息。合规上过不去，技术上也有风险。

更好的做法是写数据工厂脚本。用Faker这类库生成假用户、假订单，结构跟生产一致，内容全是虚构的。如果非要真实数据，至少做脱敏——手机号中间四位打码，姓名替换成随机字符串。

数据量也别太大。测试环境跑个几万条就够了，几十万条数据只会让查询变慢，排查问题更费劲。

测试环境要不要公网访问？看情况。如果只有内部开发用，配个VPN或者内网穿透就行。如果需要给产品、测试、客户演示，那就得配域名和HTTPS。

隔离方面，建议按分支或者按功能开环境。比如feature-user-center.test.example.com指向对应的服务实例。用完就销毁，别留着占资源。我们团队用Jenkins加脚本，合并请求创建时自动拉起一套临时环境，合并后自动回收。省心很多。

测试环境出问题，第一反应是看日志。所以日志得集中收集，别分散在十几台机器上。ELK太重的话，用Loki加Grafana，轻量够用。

监控不用太复杂，但CPU、内存、磁盘、接口响应时间这几个指标得有。有一次测试环境响应突然变慢，查了半天是磁盘满了——日志没清理，写了200G。这种事有个基础告警就能避免。

搭建测试环境没有标准答案。小团队怎么快怎么来，大团队怎么稳怎么来。关键是别把它当成一次性任务——环境是活的，代码在变，依赖在变，配置也得跟着调。定期花半小时检查一下，比出事后熬夜强。