测试环境的搭建和配置

测试环境搭不起来，测试后面所有测试都是环境空谈。我见过太多团队把测试环境当成“差不多就行”的建和临时工地，结果Bug复现不了、配置数据对不上、测试性能压测结果忽高忽低。环境去年帮一个做电商的建和朋友排查问题，他们测试环境的配置订单状态和线上完全不一致，查了两天才发现是测试测试库的定时任务没关，半夜把待付款订单全改成了已取消。环境这种坑，建和踩一次就够记一辈子。配置

先说硬件和网络。测试别一上来就追求和线上1:1，环境那是建和理想国。实际做法是：核心链路必须对齐，边缘服务可以降配。比如你们线上用了8台应用服务器，测试环境两台就够，但这两台的CPU、内存、JVM参数得和线上一致。数据库更是如此——线上MySQL是16核64G，测试环境至少给8核32G，否则慢查询根本压不出来。网络延迟要模拟，用tc命令加200ms延迟，比你在代码里写Thread.sleep靠谱得多。

操作系统和依赖版本，这是最容易埋雷的地方。线上跑CentOS 7.9，测试环境装了个Ubuntu 22.04，glibc版本不一样，编译出来的二进制直接崩。我的习惯是：用Docker镜像锁定基础环境，Dockerfile里写清楚FROM centos:7.9.2009，所有依赖用yum install指定版本号。中间件同理，Redis 6.2和7.0的持久化行为有差异，测试环境必须和线上大版本一致。别偷懒用latest标签，那是给自己挖坑。

配置管理要分开。application-test.yml和application-prod.yml必须物理隔离，别搞什么环境变量覆盖。我见过一个项目，测试环境的数据库密码和线上一样，结果开发误操作连上了生产库，删了半张表。正确的做法是：测试环境用独立的配置中心，或者至少用不同的Git分支。敏感信息加密存储，测试环境也别明文写密码。另外，日志级别调成DEBUG，但记得加滚动策略，否则磁盘两天就满。

数据准备是门手艺。空库跑测试等于没跑。我们团队的做法是：每天凌晨从生产库脱敏后导一份快照到测试库，字段加密、手机号替换成随机数字。但要注意外键约束和自增ID——直接mysqldump导入经常报错。后来改用pt-archiver按表迁移，再写脚本重置序列。对于需要特定状态的测试用例，比如“已发货未签收”的订单，单独写SQL脚本插入，别依赖全量数据。测试数据要能一键重置，否则跑完一轮自动化，环境就脏了。

服务依赖怎么处理？别傻乎乎地把所有下游服务都真连上。支付网关、短信通道这些，用Mock Server挡掉。我们用的是WireMock，配置好请求匹配规则和返回报文，启动一个jar包就行。但要注意：Mock的响应延迟要设成和真实服务相近，否则性能测试结果会骗你。对于内部微服务，可以用服务网格的流量镜像功能，把生产流量复制一份到测试环境，但记得过滤掉写操作。

最后说监控和清理。测试环境挂了没人知道，这是常态。至少装个Prometheus node_exporter，CPU、内存、磁盘告警发到团队群里。日志用Loki收集，出问题能快速grep。每周五下午定时清理：删掉七天前的日志、重置数据库、重启所有服务。别小看这个动作，我见过测试环境跑了三个月没重启，内存泄漏到OOM，结果所有人都以为是自己代码的问题。

搭建测试环境没有银弹。你花三天搭好的环境，可能第四天就被某个新依赖搞崩。保持简单，能脚本化的绝不手动，能容器化的绝不裸装。每次变更记录在案，出问题回滚只要五分钟。这比写一百页文档都管用。