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

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

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

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

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

测试环境

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

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

1. 发布频繁；

2. 功能 &服务不稳定；

3. 测试场景较多且交叉影响较大；

而性能测试一次压测运行的时间相对较长（短则 10min 长则 12 小时甚至几天），且为了获得误差较小的压测结果，性能测试对服务的稳定性要求较高。因此我建议如果有条件，还是搭建一套独立的性能测试环境更好。

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

1. 独立的域名或请求入口；

2. 应用服务器配置和生产保持一致；

3. 应用服务数量可以最小化（生产是集群，测试环境 1 台服务器部署 1 个服务）；

4. 边缘服务 &弱依赖服务 &高性能服务（全读缓存，rt 几毫秒）可以考虑 1 台服务器部署多个应用服务或者 mock 解决；

5. 缓存、消息队列、数据库配置按比例降低（比如一个 mysql 实例，4C8G/8C16G 足以满足日常压测需要）；

6. 服务的发布版本要注意如下亮点：

7. 本次测试范围内的服务，发布对应的分支；

8. 本次测试范围外的服务，和生产版本保持一致；

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

流量染色技术的应用实践，可以参考这里：得物染色环境落地实践

测试数据

聊完测试环境的准备工作后，聊聊测试数据的准备。

当然，从某种程度上来说，测试数据也可以归纳到测试环境这个大的范畴中。

压测所涉及的数据，主要分为如下几种类型：

铺底数据

铺地数据可以理解为冷数据，因为正常的线上业务，数据库的表中一般是要存在一定的铺底数据的，如电商的库存数据，用户基础数据如电话号码、收货地址等。

在独立的性能测试环境中，也需要准备对应的铺底数据，因为 SQL 执行过程中，空表和大表对性能的影响还是很大的。

准备铺底数据，最常见的有如下 2 种方式：

1. 从生产环境同步（需要进行敏感数据脱敏处理）；

2. 调用业务接口，用脚本批量生成写入（无需脱敏，符合业务逻辑即可）；

热点数据

什么是热点数据？比如用户的登录态信息(token)、比如优惠券、比如商品图片(常存储于 CDN)。

我见过很多同学在压测时先压测登录接口，然后将登录后的 token 拿出来再传递给下一个请求，完全没必要这么麻烦。

可以先准备一批虚拟的测试账号，跑批登录，然后将 token 预热到缓存中，过期时间设置的比较长即可。

在后续的测试工作中，只需要在请求头中将 token 和 userid 按照对应顺序参数化到请求中即可。

压测的场景要符合实际的业务场景，但要考虑到效率和实现成本。

其他热点数据的准备也可以参照上述的方式，提前生成，然后预热到缓存（也有本地缓存或 jar 包方式）。

参数化数据

参数化数据指的是压测过程中脚本中需要引用到的数据。以电商业务来说，常见的有用户 id、商品数据、库存数据、订单数据等。准备参数化数据，最常见的有如下 3 种方式：

1. 业务逻辑上强验证的，通过脚本跑批提前生成，再从数据库中拿出来使用；

2. 简单的自增逻辑(如订单编号)，可以通过压测工具提供的插件自增生成或写代码实现；

3. 只校验字符串位数或不为空的场景，用随机数或 uuid 生成即可；

准备参数化数据的过程中，需要注意如下几点：

1. 数据的幂等性（是否可重复使用）；

2. 数据的关联性（是否需要前置动作来更新状态）；

3. 数据的有效性（数据需要在使用阶段内一直生效）；

4. 数据的唯一性（数据在逻辑处理中仅且只有某些场景才可用）；

做完了上述的几点数据准备工作，最后要做的就是对数据可用性进行验证，看看它是否如预期满足压测需要。

以上就是关于测试环境和测试数据准备过程中需要注意的事项。

下篇整理的笔记内容，会聊聊如何设计一个简单可用的压测平台。