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

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

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

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

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

测试环境

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

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

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环境使用过程中，基础服务（sso、网关、中间件）等相关变更无法及时更新到MF环境，影响业务测试

  因此在2022年下半年，开始尝试用染色环境解决环境稳定性问题。

• 2022年：染色环境方案（基于流量隔离）

  染色环境是基于流量隔离的方案，通过流量标透传的方式，把基准环境流量和染色环境流量隔离开，实现多环境的方案，支持并行测试互不影响。

  相较于MF环境而言，不需要维护多套全链路环境，维护成本降低了。所有变更的服务都在染色环境部署的话，基准环境稳定性就会提升，相当于所有环境的稳定性都提升了。

  下面主要介绍得物染色环境是如何做的

2

染色环境方案

2.1 基本思路

如下图所示，最初的设想是：

1. 服务可以按照流量标把流量路由到相应染色服务上

2. 如果染色标对应染色环境没有此服务，则流量会走到基准环境

3. 如果染色环境服务添加了，没有部署，或者部署了服务进程挂了，则流量会报错而并非走到基准环境（避免一些服务异常问题没有暴露）

4. DB、MQ、Redis等中间件期望用同一套，避免浪费

基于此设想，需要从哪些地方入手去改造以支持染色环境呢？可以从设想拆解去解决：

1. 流量标如何透传？

2. 流量路由如何路由到染色节点？

   1. rpc接口如何路由到染色节点？

   2. MQ消息如何让染色环境consumer消费？

3. 解决完流量标透传问题，以及染色路由问题后，需要考虑流量发起方如何把染色标带上？

2.2 实现方案

以下方案只做流量隔离，DB数据层不做隔离

1. 流量标如何透传？

首先流量标在流量入口层会放到http header里面的x-infr-flowtype字段：

x-infr-flowtype:<CE_ColoringEnv> ##CE_是固定前缀，为了和压测标做区分

从流量到网关后，服务链路上面流量标往下透传的方式是通过OpenTracing规范中的baggage能力，从header里面获取染色标，并塞到trace里面向下透传。

这样整个链路里面就都能拿到染色标了

1. 流量路由如何路由到染色节点？

这里分两块考虑：

（1）rpc调用，拿到染色标之后，如何找到染色节点？这里要解决的是怎么识别染色节点

（2）MQ消息，producer如何发送带染色标的消息，consumer如何处理带染色标的消息

• 服务注册--识别染色节点

• • 首先染色环境创建的时候，会定义好染色标：

• • 在此染色环境添加服务部署的时候，默认会把染色标注入到环境变量COLORING_ENV

    容器发布配置页面会自动增加COLORING_ENV变量

• • 至此，服务启动时已可以读到COLORING_ENV环境标变量了，下一步就看注册中心怎么去区分染色节点了.

首先服务在添加到染色环境的时候，服务会在注册中心染色场增加一个节点，标明该服务在此染色环境是有服务节点存在的。

染色场主要解决的问题是：如果染色节点挂了，染色环境流量应该判断该染色环境是否应该有染色节点，有的话就报错，没有的话才会走到基准环境。避免测试问题未暴露。

染色场：CE_<ServiceName>

染色场服务节点：<COLORING_ENV>:80

其次在服务注册时候，服务节点信息和方法注册会携带染色标<coloring_env>：

至此，注册中心就可以基于染色标识别染色节点，业务服务（基于fusion框架）可以根据Trace中的染色标结合注册中心染色节点做染色流量路由。

• MQ改造--识别和处理MQ消息

MQ主要解决的是，染色环境的消息生产者producer发送的消息，只被染色环境的消费者消费，染色环境如果没有消费节点，则由基准环境消费者消费。

这里之前讨论了两种做法：

第一种是基于Topic隔离的方案，每套染色环境使用不同的topic进行通信，这样隔离性比较好，消息不容易串掉。

第二种是Topic不隔离，所有染色环境共用一个topic，生产者Producer在生产消息时候把染色标带上，consumer每套染色环境有一个，consumer在做消费时候会判断消息里面的染色标和本地染色标是否一致，如果一致则消费，如果不一致则直接返回ACK不走具体消费逻辑。

目前选择的是第二种方案，下面基于第二种方案做详细介绍：

基本流程

如图所示：

1. ServiceB_Color1会自动注册GID_Color1_Topic消费组，监听Topic_A。Color2和Color3环境一样。

2. 带Color1的消息由ServiceA_Color1生产，ServiceB_Color1消费。

3. 带Color2的消息由ServiceA_Color2生产，ServiceB消费，因为ServiceB在Color2染色环境没有节点

4. 带Color3的消息由于染色环境Color3没有ServiceA_Color3节点，则带Color3的流量会打到基准环境ServiceA，此时ServiceA会生产带Color3的消息，此消息由ServiceB_Color3消费

配合业务说明：

染色环境在启动时候，带染色标的GID会自动创建，eg：原GID是GID_AAA，染色自动创建的GID为GID_<coloring_env>_AAA

下面看消息的内容和处理逻辑：

如上图：染色消息属性里面会增加DMQ_ENV_TAG字段，添加染色标，然后对应染色环境订阅组才会消费。

看上面这张图，会发现“貌似”所有染色环境都消费了，其实是其他环境直接返回了ACK，未走具体的消费逻辑，具体可以看日志。

代码说明：基于Message里面染色标msgTag和本地服务染色标envTag进行判断做消费逻辑区分。

1. 染色流量入口携带染色标

解决完染色标透传，以及染色标逻辑处理后，剩下就是如何在流量发起方把染色标给带上了，其实就是把染色标塞到header里面的x-infr-flowtype字段。

其中染色环境列表的获取由发布平台提供接口给到各流量入口方去选择。

目前业务推广过程中，主要遇到的入口方大致有以下几种：

入口流量携带染色标相对逻辑比较简单，这里就不做详细技术介绍，只做使用层面介绍

流量入口方	染色标传递	备注
App端		从发布平台获取染色标列表，选择染色环境后，所有请求在Header里面添加x-infr-flowtype字段向下透传染色标
Web端	点击ENV弹窗选择染色标	同上
飞书回调	回调URL参数增加x-infr-flowtype=<染色标>字段
Job场景	目前是半自动方案： 染色环境&基准环境注册到同一个Job 默认job会随机选一个节点执行 如果需要指定到染色节点执行，用户可手动在job编辑界面添加染色标	目前不考虑数据隔离场景
Canal订阅	目前是半自动方案： 染色节点和基准节点Consumer订阅同一个topic 默认MQ消息不会带染色标，则只会有基准环境消费 如果需要指定染色环境消费，用户可以手动在job编辑界面添加染色标	目前不考虑数据隔离场景

至此整个业务改造基本完成，从染色流量如何构造、流量标如何透传、染色节点如何识别以及识别后重点染色逻辑如何处理等一整套流程就清晰了。

3

业务应用效果

3.1 实施路径

染色项目整个实施路径包含几个阶段：

1. 项目立项&中间件改造（4月-6月）

   1. 包含基架改造（统一框架、网关、注册中心、配置中心、超时中心、DMQ等）&客户端改造&发布平台改造等等，以及改造完成后基础链路验证

2. 线上灰度&全链路服务适配（7月~8月）

   1. 7月初：5个交易&中间件相关服务升级相关jar包带上线进行验证，保证不会对染色改造不会对生产有影响。

   2. 8月份：开始推进全域应用进行染色相关jar包升级

3. 独立项目使用（9月）

   1. 9月底之前，已经有若干独立项目应用染色环境测试验证完成

4. 业务迭代使用（10月~11月）

   1. 10月份开始尝试推进全业务进行染色环境试用排错

   2. 试用结束，逐步推进迭代使用染色环境

3.2 业务使用效果

独立项目：目前全域的独立项目已全量切换至染色环境测试。

版本迭代：就最新的版本迭代使用结果来看，全域95%以上的需求都可以使用染色环境测试。

剩余5%的需求场景主要是涉及以下两个方面：

1. 数据隔离：目前已有方案在支持，会涉及少量需求支撑。

2. 前端染色：目前染色环境主要解决了后端染色的需求，部分场景需求依赖前端染色（多前端支持），方案也基本落地，会配合后端染色一起应用。

4

总结

染色环境现阶段解决了测试环境冲突和测试环境稳定性的问题，并且相较之前多套独立环境的方案，在成本上也有比较大的节省。后续得物也会尝试用染色的能力解决生产灰度发布问题，相信也会有不错的效果。

测试数据

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

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

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

铺底数据

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

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

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

1. 从生产环境同步（需要进行敏感数据脱敏处理）；
2. 调用业务接口，用脚本批量生成写入（无需脱敏，符合业务逻辑即可）；

热点数据

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

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

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

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

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

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

参数化数据

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

1. 业务逻辑上强验证的，通过脚本跑批提前生成，再从数据库中拿出来使用；
2. 简单的自增逻辑(如订单编号)，可以通过压测工具提供的插件自增生成或写代码实现；
3. 只校验字符串位数或不为空的场景，用随机数或uuid生成即可；

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

1. 数据的幂等性（是否可重复使用）；
2. 数据的关联性（是否需要前置动作来更新状态）；
3. 数据的有效性（数据需要在使用阶段内一直生效）；
4. 数据的唯一性（数据在逻辑处理中仅且只有某些场景才可用）；

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

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

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

   总结：
现阶段很多人都在说软件测试太内卷了，工作太难找了，竞争太激烈了。那么如何在这样的现状下使得自己更具有竞争力呢？笔者认为大家需要迅速学习软件测试的硬技能，提升自己的业务能力，早日摆脱初中级测试的Title，虽然测试人员众多，但是高级的软件测试人员还是很稀缺，有很多人挂着高级测试的头衔却还在干着初中级测试的活。在掌握这些硬技能的同时，软技能的培养同样重要，沟通能力、自主学习能力越来越被企业看重。

如果不想被这个时代淘汰，就要做好持续学习的准备。下方给大家准备了全套的软件测试，自动化测试全套教程。

【需要的可以点击下方官方推广小卡片扫码备注000免费领取】