一、前言

我们经常听到研发人员和测试人员抱怨：“测试环境怎么又不能用了！”、“测试环境现在部署的是 master 包！”、“测试环境数据又被人改了？”、“测试环境怎么部署的这么慢！”、“测试环境里的公共服务，你用的时候我只能等着？”、“测试环境挂了，我自动化脚本全失败了！” 测试环境是是测试实施的基础，测试环境健全以及是否稳定直接影响了项目的进度，而测试环境的指标包含质量、效率、成本，质量主要是环境的稳定性，效率是环境部署更新、环境使用的情况，成本主要是资源使用成本和人员维护成本，测试环境的质量、效率、成本会直接影响到项目的交付质量和交付效率

测试环境问题是每个测试团队都面临的问题，在 2022 年 1024 黑马午餐会和技术大佬的交流中，有同学也提出了环境治理、提高环境使用效率的问题，京东集团技术委员会主席曹鹏也给出了建议

解决测试环境问题理想状态下是存在多套环境，但是服务器资源成本和人员维护成本都不允许，那么我们就需要考虑在现有的工具、资源下，如何更好的通过规范和流程前更好的使用我们现在工具以保证我们的测试环境稳定性、提高测试环境的使用效率是我们需要去思考的问题，本文主要是介绍我们在整个测试环境治理中所做的一些探索和优化；

二、问题调研

我们为了针对性的解决大家在测试环境使用中的痛点，在二级部门内部发起了一次关于测试环境的调研，针对不同的岗位选取了 20 个样本，调研结果如下：

1、测试环境使用群体

结果：使用到测试环境的人大部分是研发和测试人员

2、使用测试环境一般作为什么用途

结果：使用测试环境一般功能测试>研发自测>性能测试

3、对现在环境编译部署的时间是否满意

结果：对于现在测试环境部署的效率不满意

4、觉得现在的测试环境是否稳定随时可用

结果：对于现在测试环境的稳定性不满意

5、对于编译部署的时间不满意，主要是哪些应用比较慢

| 应用 | 反馈次数 |
| tms-bid-web-test | 1 |
| tms-tfc-web-test | 1 |
| tms-workbench-client-test | 3 |
| tms-workbench-web-test | 1 |
| tms-basic-web-test | 1 |

以下是我们调研后针对反馈的编译速度慢的应用取样部署编译时间：

•tms-bid-web-test：

•tms-tfc-web-test：

•tms-workbench-client-test：

tms-workbench-web-test：

•tms-basic-web-test：

6、大家认为环境不稳定不可用的原因主要是

•大家共用一套测试环境，研发联调，测试回归，很容易出问题

•偶尔存在中间件测试环境 host 地址变更情况

•目前 workbench 测试环境有两台机器，部署时正常来讲是为了保证服务可用，部署重启时至少 1 台提供服务，但是实际两台部署的中间间隔是固定的 60s，第一台从部署到提供服务大于 60s，这样导致两台服务均不可用，而 workbench 又是多团对开发，导致很多时候在等待服务启动，研发测试效率变低

•接口经常超时

•下游业务测试依赖应用较多，如测试京驿 app 如较下游系统：京驿 app 需求，需后端 tfc，rfq，basic，cmc，jdi 等环境持续可用，排查时，服务可用状态不持续在线

7、现在测试环境最令人不满意或者影响工作的地方

•测试环境共有一套，不做区分，不稳定

•测试环境比较稳定，目前暂无这些问题

•配置更新还需要重新编译

•workbench 用的人多，经常有人部署导致耽误测试时间

•不同分组 jmq 未隔离

•高可用

•环境太少，如果有上线回归，就占用测试环境了

•下游下单需多次排查测试环境，平台连接后端服务不可用/无可用的后端服务实例

•经常宕机

•频繁部署，编译时间长，部署后杰夫服务不可用

•部署起来太慢啦，有的宿主机好久不动，突然服务停了，比如通联，不清楚代码是否有问题

•basic 环境部署时，其他系统基本都用不了了，需要等

•部署时间长，部署人员多，长时间处于部署中 货航系统还比较满意，偶尔系统间交互会有问题

•频繁部署，影响工作效率

8、用户期望测试环境能满足用户哪些需求

•研发联调，集成测试有单独环境支持

•测试回归环境有单独环境，不要跟功能测试环境混用

•稳定版本提供单独环境，对应线上环境，以对外提供稳定的环境

•稳定性

•单测覆盖率的提升方面是否有助力方案；

•研发是否可操作自动化的验证方式；

•高可用

•聊天环境，测试环境，独立的

•环境稳定

三、解决方案

我们针对调研反馈的问题和现在已知的测试环境问题进行解决，主要解决内容如下：

1、问题：系统编译部署的等待时间长

解决方案：寻求行云部署帮助，优化编译命令和配置

优化结果：编译速度由原来的 5～10 分钟，降低至 3 分钟以内；

tms-bid-web-test 优化前：

tms-bid-web-test 优化后：

tms-tfc-web-test 优化前：

tms-tfc-web-test 优化后：

2、问题：系统稳定性不好，公用的应用 basic、workbench 等部署频繁，部署时候影响别人使用

解决方案：使用行云现有编排部署方式，核心尤其是对其他应用提供服务的应用，主干测试分组中增加到 2 台实例，在部署的时候采取滚动部署，即一台机器部署且探活 jsf 接口可用后，再执行第二台机器的部署，在部署过程中保持有一台实例能够提供服务，减少因为频繁部署导致的测试系统不稳定问题

编排部署配置方式：

（1）扩容

大部分测试分组当前都是一台机器部署，所以在滚动部署之前需要扩容到两台机器，在实例列表页面选择测试分组，在容器状态中选择扩/缩容，选择扩容操作

扩容数量、扩容版本默认当前内容，扩容后，容器为 2

确认成功后，系统会新增一台机器，并自动进行部署，部署成功可执行后续操作

（2）编排部署（编译 + 部署）

在部署编排页面点击【新增部署编排】

在公有模版里面选择【编译 + 部署】

在打开的默认模版中，构建任务选择需要编译的分支，通常我们选择的是 test 分支

在滚动部署节点，基本设置中

选择分组：我们要部署的分组，通常是日常测试分组

更新方式：按每分组数量

每次更新容器个数：1

每次更新时间间隔：可以使用默认的 15s

任务步骤环节，需要添加 jsf 下线、jsf 上线 2 个节点，使用默认的配置即可

确认成功后，保存并且运行，会先进行编译构建操作（此处不赘述），编译构建完成之后，会进行滚动部署操作，分 2 个批次进行部署，先进行 jsf 下线

此时，jsf 下线后，会有一台实例仍然存在，一台实例 jsf 下线

部署完成之后，会进行 jsf 存活的验证，验证成功后，才执行后续操作

当 jsf 探活 100% 后，会进行我们设置的 sleep15s 的操作

进行第二台实例的部署，全都部署完成后两台实例 jsf 都可用

全部部署完成后，咚咚提醒执行完成

每次更新版本的时候，直接到部署编排页面，到编译部署任务里面点击运行就可以了！

（3）编排部署 - 可选

应用场景：不需要编译操作，只做部署操作

部署编排页面点击场景化部署编排

选择滚动部署

选择待部署分组（主干测试环境选择日常测试分组），部署配置镜像默认使用当前使用镜像

执行下一步操作，按数量更新，设置每次更新容器数，间隔时间，选择是否 jsf 上下线、负载均衡摘除/挂载，np 下/上线操作，是否勾选负载均衡和 np 下/上线要看是否配置负载均衡和是否在 np 关联域名

保存并运行后开始滚动部署操作

（4）重启操作 - 可选

应用场景：只重启，不编译、不部署

部署编排页面点击场景化部署编排

选择制定 ip 重启

手动输入测试环境的 2 台实例 ip，点击下一步

批次设置 2，每个批次 50%，暂停设置选择自动流转，间隔时间自定义，流量类型选择 jsf 流量上/下线

设置完成后，每次重启的时候过来点击运行就可以了

（5）部署效果（过程详解，不需要操作）

以部署编排为例（编译构建页面的部署一样的效果）

先执行 jsf 下线操作，此时该应用只有一台实例存活

再执行 jsf 上线操作，会一直探活 jsf 接口是否可用，当 jsf 接口可用后，会 jsf 上线验证成功

此时 jsf 接口 2 个都是存活的，其中一个部署的是新程序包，一个部署的是老程序包；

在第一批次部署成功之后，会进入我们设置的 60s 等待时间

等待时间结束后，执行 jsf 下线上线操作

最终两台服务器都可用，部署的都是新的程序包

（6）日志查看

因为两台实例部署后，调用流量可能会随机打到某一台机器上，查看日志可以在实例列表 - 日志服务中选择当前所有机器，选择日志路径以及搜索关键字进行查询

优化后结果：

•一键式部署，一键操作编译 + 部署操作，不需要随时等待编译部署完成，完成之后咚咚给予提醒

•保障环境稳定性，部署过程中随时有一台应用可用，不会因为频繁部署导致环境不可用形象测试效率

3、问题：没有单独的测试回归环境，和功能测试环境一起使用

解决方案：每个测试应用单独搭建一套回归测试环境，部署 master 版本，用于上线前的回归测试以及自动化回归测试

优化后结果：

master 分支和 test 分支进行环境隔离，在回归测试和日常需求测试过程中互不影响

4、问题：每次配置更新还需要重新编译

•解决方案：有重启并更新配置的操作，但是不推荐，推荐重新发布，会生成另一个版本号，这样方便回滚，如果用重启并更新配置，虽然生效快，但是新配置不可回滚

5、问题：测试环境的维护困难，不清楚当前测试环境是否可用，哪些环境当前异常

解决方案：自研测试环境监控看板工具，调用行云接口做应用存活探活，实时查看当前不同业务条线测试环境当前状态（5 分钟自动刷新，支持手动刷新）

测试环境异常不可用的情况下，会同步发送咚咚消息给测试环境操作人员以及维护人员，相关维护人员接收到消息之后去查看环境异常原因

6、问题：测试环境异常导致每天的自动化执行失败

解决方案：提供封装好的接口，每天会配置好的应用测试分组和机器做探活，如果多次失败后重启应用，待探活成功后触发流水线自动化任务

接口：

/** * 获取所有机器 IP * @return */

public List getAllMachine(); /** * 获取机器状态。 * 该方法用于获取机器的当前状态。 * @return 机器的状态 */ public void machineStatus(); /** * 根据应用名称和组名称获取当前状态 * @param appName 应用名称 * @param groupName 组名称 * @return 状态值，true 表示获取成功，false 表示获取失败 */ Boolean getStatusByAppAndGroup(String appName,String groupName);

是否需要做探活的标识：

四、小结

健全、稳定、体验良好的测试环境，一直是影响产品迭代效率和稳定性的关键环节，也是做好自动化测试的必要条件，我们在经过针对性的环境优化后，对不同的目标完善了测试环境、回归环境、自动化环境、性能测试环境等分别独立的测试环境的的隔离，尽可能了保证了测试环境的稳定性，在保障资源预算的前提下，提高了测试环境的使用效率，并且有针对性的做环境监控和异常预警，使环境维护人员有针对性的去解决环境问题，减少环境维护的人员成本。

作者：京东物流 朱飞

来源：京东云开发者社区 自猿其说 Tech 转载请注明来源