这篇文章，继续分享工作笔记中关于性能测试的内容。
上一篇文章聊了如何快速上手压测工作的几个切入点和注意事项，这些内容可以帮助我们更快介入项目。但实际工作中，前期的准备工作也是很繁琐的，其中测试环境和测试数据的准备是前期准备阶段的主要工作。
这篇文章，以实际的一些场景出发，来聊聊如何准备测试环境和测试数据。
测试环境
生产全链路压测这种在生产环境进行的压测案例这里就不讲了，因为难度较大，且对大部分同学来说没太多参考意义。
以日常的压测场景展开来说，正常压测都是在测试环境展开的。那么是选择功能测试环境，还是独立的性能测试环境呢？功能测试环境通常具备这几个特点：
- 发布频繁；
- 功能&服务不稳定；
- 测试场景较多且交叉影响较大；
而性能测试一次压测运行的时间相对较长（短则10min长则12小时甚至几天），且为了获得误差较小的压测结果，性能测试对服务的稳定性要求较高。因此我建议如果有条件，还是搭建一套独立的性能测试环境更好。
搭建独立的性能测试环境要注意如下几点：
1.独立的域名或请求入口；
2.应用服务器配置和生产保持一致；
3.应用服务数量可以最小化（生产是集群，测试环境1台服务器部署1个服务）；
4.边缘服务&弱依赖服务&高性能服务（全读缓存，rt几毫秒）可以考虑1台服务器部署多个应用服务或者mock解决；
5.缓存、消息队列、数据库配置按比例降低（比如一个mysql实例，4C8G/8C16G足以满足日常压测需要）；
6.服务的发布版本要注意如下亮点：
a.本次测试范围内的服务，发布对应的分支；
b.本次测试范围外的服务，和生产版本保持一致；
当然，近几年的流量染色等技术的应用成熟，可以在一定程度上降低搭建和维护环境的成本，但如果有能力落地流量染色服务，那搭建性能测试环境的注意事项，也就不用看了。
流量染色技术的应用实践，可以参考这里：得物染色环境落地实践
测试数据
聊完测试环境的准备工作后，聊聊测试数据的准备。当然，从某种程度上来说，测试数据也可以归纳到测试环境这个大的范畴中。
压测所涉及的数据，主要分为如下几种类型：
铺底数据
铺底数据可以理解为冷数据，因为正常的线上业务，数据库的表中一般是要存在一定的铺底数据的，如电商的库存数据，用户基础数据如电话号码、收货地址等。
在独立的性能测试环境中，也需要准备对应的铺底数据，因为SQL执行过程中，空表和大表对性能的影响还是很大的。
准备铺底数据，最常见的有如下2种方式：
- 从生产环境同步（需要进行敏感数据脱敏处理）；
- 调用业务接口，用脚本批量生成写入（无需脱敏，符合业务逻辑即可）；
热点数据
什么是热点数据？比如用户的登录态信息(token)、比如优惠券、比如商品图片(常存储于CDN)。
我见过很多同学在压测时先压测登录接口，然后将登录后的token拿出来再传递给下一个请求，完全没必要这么麻烦。
可以先准备一批虚拟的测试账号，跑批登录，然后将token预热到缓存中，过期时间设置的比较长即可。
在后续的测试工作中，只需要在请求头中将token和userid按照对应顺序参数化到请求中即可。
压测的场景要符合实际的业务场景，但要考虑到效率和实现成本。
其他热点数据的准备也可以参照上述的方式，提前生成，然后预热到缓存（也有本地缓存或jar包方式）。
参数化数据
参数化数据指的是压测过程中脚本中需要引用到的数据。以电商业务来说，常见的有用户id、商品数据、库存数据、订单数据等。准备参数化数据，最常见的有如下3种方式：
- 业务逻辑上强验证的，通过脚本跑批提前生成，再从数据库中拿出来使用；
- 简单的自增逻辑(如订单编号)，可以通过压测工具提供的插件自增生成或写代码实现；
- 只校验字符串位数或不为空的场景，用随机数或uuid生成即可；
准备参数化数据的过程中，需要注意如下几点：
- 数据的幂等性（是否可重复使用）；
- 数据的关联性（是否需要前置动作来更新状态）；
- 数据的有效性（数据需要在使用阶段内一直生效）；
- 数据的唯一性（数据在逻辑处理中仅且只有某些场景才可用）；
做完了上述的几点数据准备工作，最后要做的就是对数据可用性进行验证，看看它是否如预期满足压测需要。
以上就是关于测试环境和测试数据准备过程中需要注意的事项。
下篇整理的笔记内容，会聊聊如何设计一个简单可用的压测平台。
