会员测试环境治理之路

会员测试团队2023年03月03日约 8 分钟

背景

会员业务是公司的重要业务之一，为广大会员用户承载最基础的服务保障，随着会员数的破亿，业务复杂度也是呈现几何倍的增加，如何高效的支持会员业务的测试，也成为了会员测试团队不得不面对客观挑战，这其中最核心也是最基础的莫过于测试环境的治理，现将测试环境特点总结如下：

特点1：基础应用服务数量多达数百个，分布在几十个域名下，维护成本高。
特点2：调用关系复杂，应用之间互相调用，并且相互依赖，联调成本高。
特点3：服务之间调用依靠路由转发、服务发现，定位成本高。

基于如上特点，测试过程中环境会有如下问题：

问题1：应用数量众多，每个应用基础配置随意，且存在个性化配置，不好管
理。
问题2：测试环境公用情况严重，依赖于各个研发或测试私服，稳定性比较差。
问题3：路由功能无法统一管理，调用关系混乱，环境出现问题时，排查问题时间成本高，需按调用关系逐一排查。
问题4：测试改进基建不稳定，一些基础测试工作稳定性较差，收效甚微。

会员测试环境发展史

阶段一：手动阶段

经过一段时间对项目测试时间的积累，经过细致系统的分析后，测试环境是项目测试中耗时较多、最为不可控的环节，本着质量可控的原则，测试团队决定重点建设测试环境，从根本上对测试质量和效率进行把控。申请到若干台固定虚机作为测试机，结合业务打包方式和部署流程，手动在虚机上进行搭建，我们称之为“手动阶段”，具体流程如图所示：

由于机器有限，单台需求需要部署多个应用，为防止端口号冲突，使用wiki进行机器、应用、端口号的维护工作。

解决问题：

测试团队接手测试环境打包-部署-维护流程，质量和效率可控。

存在问题：

每次在新机器部署应用时需要安装依赖，此依赖无固定版本、使相同的应用在不同机器部署时配置、启动命令等不一致。
一个机器部署多个应用，未避免冲突及后续nginx配置，人为规定相同机器不能部署相同应用，且端口号依靠wiki维护，维护成本高且时效性差，准确率不高。
个人习惯不同导致应用配置、启动脚本不一致，难于统一进行集中管理。
无代码编译过程，部署代码包完全依赖研发，时效性低。
配置类工作较多，操作繁琐、效率低。
对环境部署人员能力要求高。

阶段二：脚本阶段

随着会员业务的不断壮大，服务的逻辑愈加复杂，原手工方式的部署不堪重负，出现了很多的特殊处理，已经不能满足业务测试需求，决定使用Jenkins能力进行规范化部署，将应用配置信息统一在mysql数据库中进行维护，该阶段我们称之为“脚本阶段”，整体流程图如下：

在数据库中对每个应用基础信息进行维护，包括代码路径，基础依赖，编译命令，启动脚本，具体如下图：

前端页面支持单应用部署，在Jenkins构建选择对应应用、填写分支、选择机器后可进行部署：

Jenkins构建的过程如下图展示：

代码部署到服务器详解：

解决问题：

每个应用在数据库有基础配置，可进行统一管理及维护。
依赖、服务器初始化、应用启动等工作通过脚本统一完成，规范化且版本统一好维护。
代码进行统一管理，接手代码编译打包过程，服务质量可把控。
部署环境实现自动化，提高部署效率。
对部署环境人员要求降低。

存在问题：

配置内容没有页面操作，只能在数据库操作，操作不方便。
机器固定且无法动态扩容，出现问题后无人维护，无法支持个性化部署。
路由配置文件无法统一维护。
环境未按使用方式、场景进行区分。
扩展性差，遇到服务器迁移时成本过高。

阶段三：平台化

随着业务上代码架构的升级，微服务化，容器化，云原生化的不断升级，单独脚本化的配置已经无法适配业务的迭代，测试环境的部署仿佛一夜之间又回到的最初始手动阶段。同时业务上又出现了新的诉求：

动态申请机器部署测试环境，即用即抛。
单应用部署拓展到模板化部署，支持多应用的部署，配置，满足场景级测试诉求。
多角色多用途使用，支持开发联调/测试验证，支持联调环境，测试环境，自动化环境等等。
复杂的路由配置和参数替换，支持不同测试能力的对接等等。
在此背景下，公司测试部基于公司资源搭建环境平台，完成测试环境资源的统一分配、基准环境的统一部署、应用统一管理和部署、环境一键使用等功能，完成测试基础工程能力建设的关键一环，为整体测试效能的提升打下基础，环境平台能力介绍如下图:

依托于测试部提供的测试环境平台进行业务适配，截止到目前，会员业务的测试环境已全面对接平台，支持超过数百应用，日均部署次数百余次，服务人次超百人，使用平台搭建测试环境测试项目覆盖率为 90%+，稳定环境部署成功率为 99%+，项目手动部署成功率为 90%+。该阶段我们称之为“平台阶段”，具体整体流程图如下：

解决问题：

每个应用的基础配置在平台维护，页面可操作，集中管理、灵活配置（配置个性化、nginx、依赖host、注册中心）。
会员测试只需要维护自定义脚本，服务器基本依赖托管平台处理。
代码编译等操作托管公司内部CI/CD，流程规范，提高效率，版本可控。
环境按使用方式进行区分，减少因使用混乱导致的环境问题，避免分支与环境冲突。
通过权限控制人员可见系统及可操作范围。
联调环境方便管理，可集中度量。

解决业务痛点

在结合会员业务特点不断迭代测试环境，我们将重点解决如下几个业务痛点：

1. 测试环境整合

基于用途整合测试环境，按域名区分进行管理，每个域名下按使用功能不同，搭建不同测试环境：

稳定环境：各应用每天定时部署master分支，与线上服务代码保持一致，对内，对外提供联调稳定联调环境、自动化执行环境。
CI环境：当git变更时触发CI模板，进行环境部署后启动个性化脚本，执行自动化和安全测试，确保问题提前暴露。
业务测试：基于稳定分支进行配置和分支信息的修改，部署环境后进行项目测试，测试完成后环境释放，服务器可循环使用。

理想的环境搭建是只部署修改或新增的应用，其他应用使用稳定的，在降低测试环境搭建成本的同时减少因配置因素导致的其他环境问题。

例如图中需要完成项目：测试项目一，此功能需要用到应用A、应用B、应用C、应用D完成整体流程测试，本次只修改应用C、应用D，只部署这2个应用，剩余应用使用稳定环境的即可，环境搭建如下图展示：

2. 路由管理

2.1 nginx 管理

会员应用之间路由强依赖 nginx，会员测试环境是否可用，路由服务是否正确全部依赖于 nginx 配置是否正确，此种配置重要且个性化，经过协商会员测试与环境平台公共管理配置文件，业务负责配置文件管理及研发自定义脚本，环境平台提供配置、替换的能力，按照如下分工进行配合，保障 nginx 稳定运行，流程图如下：

就图中的项目测试而言，如何保证稳定环境中的应用可以回调到项目环境中对应应用，而不是稳定环境中的对应应用，一旦修改了如图应用B的调用地址，就无法保证2套环境可并行使用，此问题可归结为路由问题，如下图展示：

服务之间调用强依赖 nginx，如果 nginx 可动态的获取变更的应用 ip+端口号，未变更的应用则使用稳定环境的应用来提供服务问题就会变得简单，这也就解决了临时环境与稳定环境的相互调用问题，效果如下图：

想实现如上图的效果，需要通过路由来处理，具体流程如下：

路由是转发功能，具体逻辑还在应用中，启动具体应用时除了应用的必要参数外，会员测试团队还添加个性化内容，用于测试及相关质量改进，具体流程如下：

2.2.nginx集成guardro

QAE 是公司内部的基于 Docker 的应用引擎，可实现高效、可靠的自动化运维。guardro 即 Guardro-template，通过订阅 QAE Controller（Guardro）的事件消息，可以实时更新 nginx 的 upstream 文件，并且触发nginx重新载入配置。通过引入 guardro 来解决容器动态申请服务导致 ip 不固定替换 nginx 失败的问题，它实现的过程如下：