4、测试环境的一致性：硬件环境、软件环境、网络拓扑、数据量的标准化控制

做性能回归对比，最怕什么？

我最怕的是——折腾了半天，发现结果不准。不是代码变快了，是环境变了。

你想想看，同样的脚本，昨天跑 100ms，今天跑 120ms。你以为是代码退步了，结果发现是测试机器被人装了杀毒软件。这种事，我在项目中遇到过不下十次。

所以今天咱们聊聊，怎么把测试环境管死、管严。

4.1 硬件环境：别让机器“偷懒”

硬件环境是基础。说白了，CPU、内存、磁盘、网卡，这些都得锁死。

我个人习惯，做回归对比前，先做一件事：记录硬件基线。

嗯，这里要注意。很多团队只记录“8核16G”，这远远不够。

我见过一个案例：两台机器都是“8核16G”，但一台是 Intel Xeon，另一台是 AMD EPYC。跑同样的压测，结果差了 15%。你说这能比吗？

4.2 软件环境：版本锁死，一个都不能少

软件环境更头疼。操作系统、内核参数、JDK 版本、中间件版本……任何一个变了，结果都可能漂移。

我建议的做法是：用容器化或虚拟机快照来固化环境。

# 示例：用 Docker 固化测试环境
FROM openjdk:11.0.12-slim
RUN apt-get update && apt-get install -y \
    sysstat \
    htop \
    curl
COPY ./app.jar /app/app.jar
CMD ["java", "-jar", "/app/app.jar"]

你看，这样每次跑测试，环境都是一模一样的。连系统工具版本都锁死了。

4.3 网络拓扑：别让网络成为变量

网络拓扑这块，很多人容易忽略。

你想想看，压测客户端和服务器之间，是走同一个交换机，还是跨了三层路由？中间有没有防火墙、负载均衡器？这些都会影响延迟和吞吐量。

我画了一张图，帮你理清思路：

说白了，网络拓扑要标准化，就得做到：每次测试的网络路径一模一样。

4.4 数据量：量级要对，分布要对

数据量这块，我把它分成两个维度：数据规模和数据分布。

维度	说明	常见问题
数据规模	数据库行数、缓存条目数、文件大小	小数据量下性能好，大数据量下原形毕露
数据分布	热点数据比例、索引选择性、数据倾斜度	均匀分布 vs 真实业务分布，结果可能差 3 倍

我个人习惯，做回归对比时，数据量必须和生产环境保持同一量级。至少也要是 1:10 的缩比，不能拿几百条数据去压测。

# 示例：用 sysbench 生成固定数据量
sysbench --db-driver=mysql \
         --mysql-host=127.0.0.1 \
         --mysql-user=root \
         --mysql-password=root \
         --tables=10 \
         --table-size=1000000 \
         oltp_read_write prepare

你看，这里指定了 --table-size=1000000，也就是 100 万行。每次跑回归，都用这个参数重新生成数据，保证数据量一致。

4.5 环境一致性检查清单

最后，我整理了一份检查清单。每次做回归对比前，对着过一遍：

嗯，说实话，这七条能全部做到，你的回归对比结果基本就靠谱了。

我见过太多团队，前面几条都做到了，唯独漏了数据分布。结果压测结果漂亮，上线就崩。为什么？因为生产环境的数据是倾斜的，而测试环境的数据是均匀的。

所以，环境一致性不是一句空话。它需要你一条一条去落实，去检查。

好了，环境一致性这块就聊到这儿。记住一句话：环境控制得越死，结果越可信。