全栈性能测试技术笔记(二)：如何准备测试环境和数据

这篇文章，继续分享工作笔记中关于性能测试的内容。

上一篇文章聊了如何快速上手压测工作的几个切入点和注意事项，这些内容可以帮助我们更快的介入项目。

但实际工作中，前期的准备工作也是很繁琐的，其中测试环境和测试数据的准备是前期准备阶段的主要工作。

这篇文章，以实际的一些场景出发，来聊聊如何准备测试环境和测试数据。

测试环境

生产全链路压测这种在生产环境进行的压测案例这里就不讲了，因为难度较大，且对大部分同学来说没太多参考意义。

以日常的压测场景展开来说，正常压测都是在测试环境展开的。那么是选择功能测试环境，还是独立的性能测试环境呢？功能测试环境通常具备这几个特点：

1. 发布频繁；
2. 功能&服务不稳定；
3. 测试场景较多且交叉影响较大；

而性能测试一次压测运行的时间相对较长（短则10min长则12小时甚至几天），且为了获得误差较小的压测结果，性能测试对服务的稳定性要求较高。

因此我建议如果有条件，还是搭建一套独立的性能测试环境更好。

搭建独立的性能测试环境要注意如下几点：

1. 独立的域名或请求入口；
2. 应用服务器配置和生产保持一致；
3. 应用服务数量可以最小化（生产是集群，测试环境1台服务器部署1个服务）；
4. 边缘服务&弱依赖服务&高性能服务（全读缓存，rt几毫秒）可以考虑1台服务器部署多个应用服务或者mock解决；
5. 缓存、消息队列、数据库配置按比例降低（比如一个mysql实例，4C8G/8C16G足以满足日常压测需要）；
6. 服务的发布版本要注意如下亮点：

1. 1. 本次测试范围内的服务，发布对应的分支；
   2. 本次测试范围外的服务，和生产版本保持一致；

当然，近几年的流量染色等技术的应用成熟，可以在一定程度上降低搭建和维护环境的成本，但如果有能力落地流量染色服务，那搭建性能测试环境的注意事项，也就不用看了。

流量染色技术的应用实践，可以参考这里：

测试环境治理一直是各大公司非常重要的一个课题，测试环境稳定性很大程度影响迭代开发&测试效率。

综合来看，测试环境不稳定的原因主要有以下几点：

1. 测试环境的变更非终态变更，经常会有代码发布/配置发布导致服务无法启动或者链路有问题的情况。

2. 变更频繁，开发需要联调、测试需要迭代测试，代码需要变更，配置也需要变更，权限控制就比较难做，增加了测试环境不稳定性。

3. 并行需求，同一时间单个应用需要多个分支同时支持多个需求的测试，测试环境资源的抢占和冲突比较明显。

得物测试环境稳定性治理也经历了几个阶段：

• 2020~2021：多套物理环境隔离方案（基于ECS）

  T0、T1、T2三套测试环境，每套环境物理隔离，无资源冲突和共享。

  规划T1用于迭代测试、T0用于集成回归、T2用于独立项目分配使用，但在实际使用过程中，业务测试并行太多，冲突比较明显，环境就开始乱用了，谁有需求就随便占用一套环境使用了。结果就是没有一套稳定的环境，测试有效性无法保障，并行项目环境冲突也无法解决。

• 2021~2022：MF全链路容器环境方案（基于容器）

  随着业务增长，3套测试环境已明显不能满足业务需求，因此去年得物基于容器快速搭建了10套MF环境用于支撑独立项目的测试。

  MF环境基于T0搭建，DB和T0共享，其他所有资源均独立，目的是做到业务只需保障T0的稳定性，所有MF环境可快速基于T0同步最新服务和最新配置，做到环境随用随取，解决并行项目环境冲突问题。

  实际实施过程中，项目环境冲突的问题解决了，但是MF环境的稳定性问题依旧比较严重，维护成本巨大，主要原因集中在：

  T0环境稳定性，并非所有域都在T0集成回归，导致T0稳定性无法保障

  MF同步了T0之后会因为各种各样的原因需要二次调试验收（新增服务丢失、配置不全/错乱等）

  MF环境使用过程中，基础服务（