酒店测试环境 V3.0 设计和实践

李景康，2018 年加入去哪儿旅行，测试开发工程师，负责酒店直连和国际酒店的测试工作。期间负责酒店环境 3.0 设计和实践，获得公司金项奖潜力奖，推动公司软路由推广。目前致力于提升测试环境的工作效率和用户体验。

一、背景

去哪儿旅行非常重视测试环境治理，提高开发和测试人员的使用效率。从 2018 年就开始了测试环境治理和优化之路，到目前为止总共进行了三轮环境治理和优化。

1. 测试环境1.0

环境 1.0 中使用的固定环境，总共有十台固定机器组成，每台机器部署全链路的环境，但随着业务不断发展，原有环境已经不能满足需求：

• 随着微服务越来越多，人工在 beta 机器上维护越来越难；
• 环境有限，经常出现环境争抢，导致环境使用效率低下。

2. 测试环境2.0

测试环境 2.0 使用了基础研发自研的 noah 环境管理系统（下面简称 Noah ），通过模板化解决测试环境微服务应用的管理问题。所有环境信息（应用配置，数据库，配置）都在模板中维护。

需要创建环境时，使用最新的模板数据构建全新环境：

• 创建环境速率的提升，从配置一套固定环境的几天到 noah 拉起一套酒店环境 30 分钟左右（整个环境约 200+ 服务(应用+数据库/ redis / es ))；
• 随着环境交付速率提升，每个项目可以单独创建一套环境，减少环境争抢和干扰现象。

3. 测试环境3.0

测试环境 2.0 在同规模环境管理/创建方面已经做到行业前列，在 2021 年进行环境效率摸底，收集环境使用痛点问题，准备进行下一轮优化。

问题主要有：

• 排查问题很难，全链路的问题排查耗费时间长；
• 测试环境机器服务容易宕机；
• 创建环境是不是能更快一点，等待时间还是有点长。

将大家使用遇到的痛点问题归纳成三类问题（交付效率，基础可靠性，业务连通性）：

二、环境 3.0 设计

1. 交付效率如何提升

1.1 交付效率提升分析

在环境 2.0 阶段，酒店同规模环境创建速率已经达到行业前列（200模块/30分钟交付）。

如果想进一步提高环境交付速率，有两种思路：

• 提升单个模块构建时间；
• 降低模块规模。

第一个方案，和基础研发同学分析一下，单个模块的时间优化空间不大（投入时间长收益较少），最终我们选择从第二个思路开始优化，是否能够降低单个环境的应用规模。

而在实际项目中，项目环境其实并不需要全部模块，我们可以让项目环境按需拉取所需要的模块即可，这种方式既可以降低整体创建时间，也可以提高测试环境资源利用率。

1.2 软路由提升交付效率

这里需要介绍下软路由机制，软路由环境主要包含两部分：

• 基准环境， 基准环境是一套全链路的稳定环境，当线上代码发布的时候，基准环境代码也会同步更新；
•  软路由环境，软路由是我们日常使用的项目环境。每个项目都只需要按需拉取自己使用的模块即可，缺省的模块会由基准环境的稳定服务代替，组成一套互不干扰的软路由环境。

1.3 软路由的整体方案

软路由方案整体包括两大核心功能，环境绑定和流量分发：

1.3.1 环境绑定功能

环境使用者通过 Noah 环境绑定工具将 uid （去哪儿用户标识，下称 uid ）和环境绑定，建立环境绑定关系并存储。绑定完环境后，请求到网关（openresty）时读取环境绑定关系，将 uid 转换成环境标识，然后将环境标识植入 HTTP Header 中，方便后续的流量分发。

1.3.2 软路由环境的流量分发

流量分发中涉及 or/dubbo/qmq（去哪儿消息中间件）三个中间件，主要分为服务感知和服务选择两个步骤：

(1) 服务的感知

核心思路是将环境信息统一上报，方便后续路由选择。

Or：所有环境入口使用同一套域名（比如 ortest.qunar.com )，在环境创建/更新时新增/更新 对应的upstream。

Dubbo：使用一套 Zookeeper，保证软路由服务被及时发现，各软路由环境服务注册时带上环境标识。

Qmq：保证软路由服务被及时发现，各软路由环境 qmq 注册时带上环境标识。

(2) 服务的选择

核心思路是根据链路中环境标识，路由到软路由的服务，如果缺省则路由到基准环境。

Or：通过识别请求中的路由信息和域名中转发规则进行匹配，匹配成功转发到对应软路由环境。如果匹配不到则转发到基准环境。

Dubbo：根据链路中的软路由标识，和注册中心的环境标识做匹配选择。如果能匹配上，则选择对应环境 dubbo 服务。如果匹配不到对应环境则选择基准环境的 dubbo 服务。

Qmq：根据消息体中的软路由标识识别，只消费软路由标识匹配上的消息，如果软路由环境没消费则由基准消费。

除此之外还包括特殊的数据存储部分。

(3) 数据存储部分

软路由方案中数据存储部分没有使用数据流量路由机制，开发和维护成本较高，而是使用较为成熟的物理隔离方案，通过智能推荐策略将选择的应用依赖的数据库和 redis 拉取出来，保证环境中所依赖的数据存储环境隔离，提高环境的稳定性。

根据以上流程，需要对组件做一些改动，下面给大家介绍下各个组件的改造方案。

1.4 中间件改造方案

1.4.1网关改造

网关隔离使用的是逻辑隔离方案，通过请求中不同的路由标识来将请求转发到不同环境。同时网关层作为流量的入口，还承担路由解析的功能。

第一步 路由解析

用户通过 uid 来绑定不同环境，将其存储到 noah 系统并同步到 beta 网关系统。

当后续携带用户信息的请求到网关（or/nginx）后通过 uid 解析出环境标识，然后将环境标识植入 HTTP Header 中，往下透传。

第二步 服务感知

软路由环境和基准环境公用同一套域名。当软路由环境创建成功时，Noah 在会在 or 上给对应域名增加软路由环境的 upstream（用于后续服务选择）。

第三步  服务选择

通过识别请求中的携带的环境标识，寻找对应匹配的 upstream ，如果匹配成功则路由到对应软路由环境（比如图中 从 OR 入口路由到软路由 A1 模块）。

如果没有匹配上的说明软路由环境没有对应模块（或者服务不可用），此时则路由到基准环境（图中从软路由 A1 路由到基准环境 B 模块）。

1.4.2服务改造（dubbo）

服务隔离的思想是通过标识 Provider 与 Consumer ，再通过自定义负载均衡算法，让 Consumer 调用指定的 Provider 服务，达到环境隔离的效果。

第一步 服务感知在 Provider 注册时从 Noah（环境管理系统）获取当前环境标识，然后在 dubbo 服务注册时添加一个参数（ routerId ）用来标识当前环境。

第二步 服务路由，consumer 调用时根据链路中的环境标识 id 筛选出对应的 provider，如果匹配不上则默认调用基准环境 provider 。

1.4.3消息改造（新 qmq ）

第一步 服务感知

qmq consumer 端注册和上报环境标识，同时生成环境隔离的 group 来订阅消息。

第二步 服务的选择

qmq provider 发送消息时携带软路由标识，同时 qmq consumer 向 qmq server 发送拉取请求时也携带软路由标识。

qmq server 处理拉取请求时，根据拉取请求携带的软路由标识和消息携带的软路由标识来判断消息是否要过滤掉。如果能匹配上则可以拉取到消息，不能匹配则过滤消息（如图中环境 A 匹配成功，可以拉取到消息）。

1.4.4 存储隔离

存储隔离一直是环境隔离的一个痛点问题，在环境 3.0 中根据业务线复杂的存储依赖的情况开发了智能推荐方案，保证软路由环境链路完整且数据隔离。智能数据推荐方案分为两个核心步骤，数据依赖感知和智能推荐。

第一步 数据依赖感知

应用服务会在代码中配置需要的数据库/redis 缓存的配置信息。Noah 会从发布系统获取应用和数据的依赖关系，并将数据依赖关系存储下来。

第二步  智能推荐

智能推荐通过分析上面采集的数据依赖关系，拉取模块时将依赖的数据库/redis 和公用数据源（同一个数据写入和读取）的模块推荐出来，来保证软路由环境测试链路的完整性。

如下图，在创建模块 A1 的软路由环境时，首先会根据模块 A1 从依赖关系找到需要的数据库 A1 ，再通过数据库 A1 拉取公用数据源的模块（图中 B1,C1 ），同时再次触发推荐过程。

最终通过智能推荐策略拉取出右图的软路由环境，达到链路完整且数据隔离的目标。

2. 测试环境稳定性

说到测试环境稳定性，大多数同学第一反应是测试环境不稳定，将问题详细分类，主要由以下原因造成：

• 测试环境部署的是开发中代码，代码的不稳定；
• 测试环境存在脏数据；
• 对测试环境的不重视，业务和中间件缺少监控等；
• 测试的机器资源没法和线上对齐等因素使用过保机器，存在机器资源超售。

以上原因导致测试环境必然是不稳定的，但其中有两个问题是测试环境不稳定的根源：

• 从成本角度出发，测试环境无法和线上对齐（机器资源，日志，监控无法和线上对齐）；
• 测试环境里面有不稳定的代码。

第一个问题：基础可靠性，受制于成本问题，测试环境无法享受线上服务的基础设施。只能在现有情况下，设计了基准环境保障计划进行可靠性的保证。

第二个问题：业务可靠性，我们通过链路级别业务检查，及时发现环境中不稳定代码及时进行反馈和定位。

2.1 测试环境基础可靠性

基础可靠性分为两个部分，基准环境的可靠性和软路由环境的可靠性。

2.1.1 基准环境可靠性

基准环境是全模块的稳定环境，部署的最新的线上代码，理论上不会受到代码不稳定的干扰，我们希望他能够提供稳定的服务（目标 99%可用），在设计上会为基准环境提供额外的基准环境保障（基准环境保障计划）。

1. 硬件层面

多机部署：基准环境服务机器都使用多机部署，避免单点故障导致服务不可用。

禁用 debug ：避免基准环境 debug ，导致基准环境不可用。

2. 软件层面（基准环境保障计划）

为了提高基准环境稳定性和降低环境维护成本 提出了环境保障计划，主要包括日常环境使用中最容易出现问题的三个部分，代码，配置，数据库。通过建立同步机制来提高基准环境稳定性。

代码同步

Noah 系统会一个小时同步这段时间的线上发布到基准环境，通过基准环境特殊的双机部署，保证基准链路不中断，部署完成触发业务检查，检查环境的链路可用性。并将同步和检查结果发送给环境管理员处理。

配置同步

Qconfig（去哪儿配置中心，下称 qconfig ）同步策略，当时有两种方案：

（1）同步线上配置

第一种方案为同步线上配置，这样可以保证测试环境的配置和线上一致性，不再需要手动维护测试环境配置。但从安全的角度出发，这个方案可能带了系统层面的风险，比如 同步线上配置，可能会导致测试流量请求到线上。

（2）同步测试环境配置

第二种方案为同步测试环境配置，将项目上线过程中准备的测试环境配置，同步到基准环境来使用，这个方案在安全性上有显著提高（测试环境配置一般认为是低风险，可重复使用）。但线上配置变更时，该方案就无法获取到最新的线上配置，在这种情况下 Noah 会通知值班热线，需要人工判断和处理配置变更。

在权衡了安全和效率之后，最终我们选择了安全性更高的方案二，目前已经平稳运行一年。

数据库同步

酒店测试环境数据目前都是通过数据构造平台构造出来并固化，但环境使用过程中，会碰到线上数据结构变更但测试环境没有同步变化导致测试环境不可用的情况。

为了解决这个问题，我们在环境保障计划中加入数据库表结构同步，noah 收集关注数据库的线上变更情况，每个小时利用 DBA 同步工具 （同步表结构和调用安全服务数据会进行脱敏处理） 同步一次线上表结构。

并在同步结束后触发环境业务检查，检查基准环境的可用性，并通知环境管理员。

2.1.2 软路由环境可靠性

软路由环境中会部署不稳定的代码，天然会存在不稳定的因素，对环境的可靠性上要求并不像基准环境那么高。软路由环境的可靠性策略是主动发现和快速定位。

1. 软路由环境探测

Noah 系统针对软路由环境开发环境探测功能，通过探测访问应用和机器的使用/存活状态，将相关信息反馈给环境使用者，方便问题的发现和快速定位。

2. 软路由环境自愈

（1）容器化自愈：通过容器机自愈机制保证软路由服务的可用性。

（2）虚拟机检测&重启：对于虚拟机服务，配合软路由探测机制，把不在线的服务自动重启，当重启失败后推送给环境管理员，进行进一步处理。

2.2 测试环境业务连通性

业务连通性是最接近环境使用层面的指标，如何证明当前环境是否能让开发/测试同学上手开箱即用，各种复杂应用之间的业务连通性是否正常。

2.2.1  软路由的业务连通性范围

1. 酒店业务线内部业务连通方案（多模板多基准）

按照业务来划定软路由不同模板，形成了多模板和多基准的情况，彼此之间通过软路由机制关联。

多模板多基准的业务连通性

- 场景一：跨模板联调

当两个模块中应用都有改动，且需要联调时，此时会创建两个不同模板的软路由环境 如图中主流程环境A和酒店评论环境 B ；

当用户同时绑定环境 A 和环境 B 时，后续用户请求根据软路由标识机制转发到对应软路由模块（图中红色链路，从图中 模块 D1 请求到模块 J1 ）。

- 场景二：单个模板内部联调

如果只有单个模板应用有改动，比如只修改模块 C 和模块 D ，创建主流程环境 A，当用户只绑定环境A时，后续用户请求先沿红色链路请求到模块 D1 。

后续软路由标识无法和酒店评论软路由环境匹配，会通过软路由机制将请求转发到基准环境模块J（从软路由模块 D1 到基准环境 J ）。

- 场景三：基准链路

当用户不绑定软路由环境时，用户请求会走基准链路（图中黑色链路，从模块D 路由到模块 J )。

2. 跨业务线的业务连通方案

业务线内是由不同领域的模板/基准环境组成，而到了业务线外部则是按照不同业务线来划分（业务线统一对外提供的对外的基准 OR 域名/ DUBBO 服务/ QMQ 服务)。

跨业务线的业务连通性一般有如下两种场景： 

- 场景一： 跨业务线联调

双方都有改动，由酒店软路由环境调用其他业务线软路由环境（如图中红色链路）。当用户同时绑定酒店环境A和服务环境 C 时，后续用户请求会转发到对应的软路由环境（服务环境 C ）。如果不匹配时则转发到基准环境。

- 场景二：酒店业务线内部联调

当只有酒店业务线有改动时，对应的请求访问时会调用其他业务线的基准环境（如图中绿色链路）。

2.2.2 如何检测业务连通性（侦察系统）

为了检测业务场景连通性，我们开发了业务检查工具－侦察系统。

侦察系统从业务场景出发，一个业务场景中包括业务链路上不同模块的测试用例，下面我们以报价页面展示的业务举例。

一个报价页面的展示业务，包括三个业务处理层的测试用例（每个业务层包括若干应用），只有当此业务场景中所有测试用例通过才代表该业务场景检查通过。

当业务场景不通过时，可以通过业务检查结果快速定位问题，定位到对应的模块和接口，同时可以用 qtrace 排查问题。

目前业务检查已经覆盖固化数据 99% 业务场景（ 300+ 业务测试用例），覆盖酒店所有核心主流程。

通过三种方式触发环境业务检查来检查环境可靠性（目前每天执行约 1800 次），在环境不可用时，侦察系统可以帮忙开发/测试同学来快速定位环境问题（从原来约 30 分钟降低到 30 s）。

2.2.3 什么时候检测业务连通性

业务检查主要通过三种方式触发检查，主要为定时任务检查，持续集成 触发检查，环境变更触发。其中定时任务检查更关注基准环境，而 cicd 触发检查更关注于软路由环境（项目环境）。

1. 定时检查

基准环境 高频率检查（1分钟/次），如果未通过 ，通过电话通知 QA 值班热线处理。

软路由环境 全量环境一个小时检查一次（项目环境主要靠流水线触发），如果未通过项目群通知对应开发/测试同学，可以根据业务检查结果排查和解决。

2. 持续集成( CICD )触发

目前将持续集成和业务检查起来，在项目分支上，每次有代码提交，把项目分支最新代码部署到软路由环境上，并且跑一遍链路级别的检查，确保项目新代码不影响环境使用。

3. 环境创建/变更触发

当环境创建/变更时，无论应用/数据库/网络变更时，都会在结束后触发业务检查。

保证环境变更业务连通性依然正常，可以正常交付使用。

三、环境 3.0 指标

1. 交付效率

通过软路由机制，智能拉取改动的模块，降低环境整体交付时间。

目前环境 3.0 模块数对比环境 2.0 平均模块数降低 90%（从平均 200 个模块到目前平均 10 个模块）, 环境创建时间也随之降低（环境创建时间减少 70% ）。

环境创建时间减少 70% 

2. 业务检查通过率提高

2.1 维护核心环境数量变化，快速定位解决

从原来 60+ 独立环境到目前一个核心基准环境，环境维护的同学可以提供更及时和可靠的环境支持，快速解决业务连通性问题。

2.2 业务检查主动发现和定位问题

通过多种业务检查触发途径（定时/ cicd /环境变更），触发业务检查，主动发现环境中问题并反馈给环境维护者进行解决。

3. 环境维护成本降低

4. 环境资源成本降低

四、未来和展望

4.1 环境4.0 （PROD TO BETA）

测试环境 4.0 中，在之前基础上，建立更丰富的同步机制和业务检查机制，让测试环境更好用 同时也更好维护。

4.1.1测试环境同步机制智能化和全面化，提高环境业务连通性，降低环境维护成本

1. 应用层面

• 应用自动同步（应用配置，机器配置等）；
• 代码自动同步；
• 环境自愈机制进一步完善。

2. 数据层面

• 数据库数据同步（数据会进行安全脱敏）；
• 缓存数据同步（数据会进行安全脱敏）。

3. 基础设施层面

• 配置自动同步；
• 网关自动同步。

4.1.2. 业务检查全面自动化，业务覆盖率提升

1. 自动录制和回放 case ，提高业务覆盖度；
2. 业务检查失败原因智能分析和业务场景自愈。

4.2 环境5.0 （Test in Production）

环境 4.0 让测试环境更好用（PROD to BETA),让测试环境更接近线上环境。从而达到提高环境使用效率的目的。

而环境 5.0 中则是进行 Test in Production 的进一步探索，将原有的酒店仿真环境（逻辑隔离，但受限于资源成本只有一套）利用云技术和软路由技术进行拓展。

通过软路由的逻辑隔离方案，让仿真环境人手一套（比如图中的环境 A 和环境 B )，真正做到Test in Production 。

最后： 下方这份完整的软件测试视频学习教程已经整理上传完成，朋友们如果需要可以自行免费领取【保证100%免费】

 这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！

软件测试技术交流群社：786229024（里面还有工作内推机会，毕竟我们是关系社会。）

软件测试面试文档

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。

面试文档获取方式：