干货 | 携程机票前端UI自动化与持续集成升级实践

关注

原创最新推荐文章于 2026-05-21 05:00:58 发布 1.1k 阅读 AI 写同款· GEO 优化 ›

4.4 自动化测试集成开启gitlab pages vim /etc/gitlab/gitlab.rb ##! Define to enable GitLab Pages pages_external_url "http://pages.gitlab.com/" gitlab_pages['enable'] = true gitlab_pages['inplace_chroot'] = true gitlab-ctl reconfigure 更新gitlab.yml文件 containers: - name 阅读详情

作者简介

JinG、YuWang，携程前端开发工程师，负责机票主流程预定React Native技术栈相关开发工作。

一、前言

随着携程机票APP全流程由Native技术栈转向RN（React Native，以下均称RN），同时引入了BDD的敏捷开发模式，以应对日益增长的产品需求。高速的开发迭代过程中，如何确保稳定且可持续的交付质量，显得尤为重要。本篇旨在介绍携程机票APP主流程团队使用与升级持续集成/持续交付（以下均称CI/CD）来兼顾前端开发高效率及高质量的实践。

二、机票APP主流程CI/CD

2.1 持续集成/持续交付

在软件工程中，持续集成是一种在保证质量的前提下将每天新增代码合并到共享主线中的做法。持续交付是一种能够使得软件在较短的循环中可靠发布的方法。

传统的持续交付过程着重于代码的安全交付，对于持续交付流程的执行效率没有足够重视，往往使得整个持续交付过程时间成本过高。对于前端工程而言，传统的持续交付缺乏快速、便捷、及时响应的UI自动化测试方案，页面展示的正确性难以得到保障。

面对这些问题，携程机票通过采用更为高效的CI/CD策略，实现快速、便捷、及时响应的UI自动化测试方案，达到了从代码提交到发布上线的全UI闭环的持续交付效果。

2.2 机票主流程前端开发现状

本次CI/CD升级实践前，机票APP主流程前端流程中，开发人员完成功能开发后，大致有以下几个步骤：

1）在代码仓库上提交代码时，会进行CI检测，通过后会合并进主分支；

2）QA通过发布平台进行测试环境的打包部署等操作；

3）QA进行手工测试，并进行本地UI自动化脚本测试，测试完成后进行结果反馈；

4）通过测试，进入下一步的生产发布流程。

主流程CI/CD流程图

整个过程，虽然使用了自动化手段，但是，还是存在一些问题：

1）人工干预过多：平台的发布、部署，运行UI自动化，这些重复的固化步骤都需要人工参与；

2）发布回归成本高：在每周常规发布两次的节奏下，人力回归测试加上集成反馈链路过长，都会增加验证成本；

3）UI自动化测试参与度不够：整个测试过程中，手工测试占比大，UI自动化测试由于用例数量庞大以及真机运行效率瓶颈，仅在测试阶段进行辅助测试，并不能保证UI功能验证的完整度，远没有发挥真正的效用。

我们针对这些问题进行了流程改进。

2.3 携程机票CI/CD改进后流程

改进后主流程CI/CD流程图

与之前相比，开发阶段：

1）CI检查的过程中增加了ESLint校验和增强了UT检验，可以在根源上排除低质量却难以发现的bug；

2）自动发布免除繁杂的人力操作和漫长等待编译的过程；

3）增加了自动触发CRN-WEB的UI自动化测试，使得UI自动化测试提前介入，将简单功能提前进行测试，早一步发现问题，减少测试成本和沟通成本。

测试阶段：

由原来的手工测试为主，UI自动化测试为辅，切换成UI自动化真机测试为主。

关于最大效率发挥UI自动化的作用，自动打包发布等，会在下面的内容里进行详细介绍。

三、CI检验完善

3.1 完善检验机制

完善CI检验机制，可有助于问题暴露前置，避免无必要的排查成本。除基本的针对TypeScript代码规范的ESLint检测，加强了对UT的检测，在达不到指定阈值时，拦截分支合并，通过规范性要求和自动化CI检验保障代码的质量。

3.2 提高检验效率

CI检测基本是一个串行的流程，但中间的一些检验过程可以并行，缩减检验时间，例如：TSC、UT以及ESLint校验并行运行：

优化效果：

1）每个stages的检测内容一目了然，某个job出现问题也能够迅速定位。

Pipeline运行结构图

2）TSC、UT、ESLint并行运行后，build阶段仅需1min59s，相较串行执行的5min48s，节约了3min49s；串行下的整体平均耗时为8min，改为并行后的平均耗时为4min，提升了50%的执行效率。

Jobs耗时图

四、UI自动化测试

实现CI/CD，需要全网自动化回归来保证质量，而UI自动化测试是前端测试中针对业务逻辑自动化测试的有效方法。针对UI自动化测试实施复杂、运行慢、排查问题效率低的问题，携程机票在一步步的升级过程中通过不断自研和完善测试工具，实践得出了较好的解决方案。

4.1 MOCK平台

在UI自动化的测试过程中，数据的稳定性是UI自动化测试能否顺利进行的决定性条件之一。机票业务数据存在高度的变化性，前一时间段存在的航班数据下一刻可能就发生了改变，数据的变化将导致原有的自动化用例无法正常运行。同时在开发过程中，服务端的需求功能也会导致数据变化。

为解决数据问题，提高UI自动化测试的稳定性，引入内部自研的Mock平台，达到以下目的：

1）稳定不变的数据

2）不受服务端影响的数据环境

3）快速响应的UI界面

4.2 分布式UI自动化平台

为了解决UI自动化本地单机运行慢，占用设备和人工资源的问题，部门内部搭建了一套UI自动化分布式运行平台，由原来的本地单台设备运行改为平台共享多台设备并行运作的模式，运行时长由原先的4小时减少到现在20分钟左右。

平台上支持任务、设备和项目的管理，选择需要运行的用例，待用例执行完成后可以查看报告，报告中有相应失败界面截图，便于分析排查问题。

另外，平台可以制定每日定时任务，将每天测试环境更新的功能接入监控。

平台用例报告汇总样例图

4.3 自动化框架

4.3.1 MEC框架

BDD（行为驱动开发）是一种敏捷软件开发的技术，鼓励开发者、QA和非技术人员之间的协作，为保障质量携程机票落实了BDD开发模式。部门内部基于Cucumber和Macaca自研了真机运行的UI自动化框架MEC（Macaca Eating Cucumber），便于QA人员使用自然语言编写自动化测试脚本。

MEC框架结构图

每条自然语句对应一个可执行的方法，以下是用MEC编写的脚本示例：

@p1
   场景大纲:筛选航空公司
        假如 启用MockCase[<caseID>]
        当   跳转页面到[<列表页>]
        并且 筛选[航空公司]为[选择条件东方航空]
        那么 列表页航班按航空公司[东航]筛选
        并且 移除MockCase




    例子:
        | caseID  | 列表页             |
        | 17470891 | 单程列表页上海-北京 |

国内筛选航空公司用例脚本

4.3.2 Airtest自动化测试工具

上述框架中采用的Macaca是UI自动化测试工具中常用的一种，也可以使用其他自动化测试工具进行替换，对此，部门内部也正在尝试使用其他的同类型工具，如：Appium、Airtest等进行试验。Airtest是网易开发的UI自动化测试工具，目的是通过所见即所得、截图点击等功能，简化测试代码编写工作。

就目前的测试结果来看，Airtest版相较Macaca版具有以下优势：

1）更快的执行速度：查找单个元素可节省约1-3秒的时间，整体用例执行时间可节省75%以上；

2）更丰富的验证功能：Airtest可支持图像比对。

以下是同等用例运行时间对比：

Macaca版运行耗时

Airtest版运行耗时

基于以上优势，接下来底层运作会迁移到Airtest工具上，而得益于自然语言翻译脚本运行的特性，用例集切换Airtest工具上无需增加成本，且可以进一步提高运行效率，获取更多便利。

通过选择不同的测试工具，提升了运行效率，从而带给我们思考还有什么方法可以让UI自动化测试运行的更快？下一节的PAC框架则是一个新的方法。

4.3.3 多进程PAC框架

目前，机票APP主流程UI自动化用例集数千个，需求覆盖率95%以上，通过接入自动化平台，虽然解放部分设备和人力，但是还存在运行时间过长，过度依赖设备，多端差异兼容等问题。

携程机票APP主流的RN项目都是使用内部开发框架CRN进行的，在这基础之上，为了打通项目在iOS、Android、H5三端运行效果，使用内部CRN-WEB框架的同时，自研了多进程UI自动化框架--PAC框架，PAC（Puppeteer And Cucumber）属于MEC BDD测试自动化框架的衍生品，通过Headless Chrome的工具Puppeteer，改善目前UI自动化测试的瓶颈。

PAC框架架构图

通过PAC框架，原先编写的UI自动化测试脚本，可以零成本的对接运行在WEB端，这也为后期UI自动化测试的提前介入打下基础。

优势：

1）缩短的运行时间，将每个UI自动化项目总运行时间缩短在分钟级

2）完全脱离客户端，降低对设备的依赖

3）解决现有的多端差异兼容和环境问题

4）现有Cucumber用例无缝切换，无需再次编写转换

CRN-WEB执行UI自动化项目运行总耗时

五、集成自动发布和UI测试

一个完整的持续构建系统包括三个部分：一个自动构建的过程（比如安装依赖自动编译、代码质量检查、单元测试，自动发布等）、一个代码存储库（构建过程的素材库）、一个持续集成的服务器（自动执行构建的流水线）。以下2点正是对其中的自动构建过程的完善。

5.1 平台自动打包发布

基于发布系统，当代码merge进入主仓库时，进行CRN和CRN-WEB的自动化发布，以及测试环境的部署。

发布平台的CLI工具提供打包功能，对其封装调用。发布完成后，GitLab-CI构建结果上传提供给下游job使用，中间出现问题时，会通过内部IM、邮件形式推送给相关人员。

自动打包流程

5.2 自动触发UI测试

job开始前，使用上游自动打包产生的中间结果，拉取指定测试版本，自动触发平台UI自动化测试任务，执行完成后，使用预设阈值校验自动化通过率，并及时反馈。

自动触发UI自动化测试流程

结合上面两项，在项目.gitlab-ci.yml文件中增加两项Job：分别对应自动化发布和自动化UI测试。任何成员commit push均会触发Pipeline，经过UT、UI自动化等检测，Pipeline整体通过后，才能触发merge request的状态改变，进行merge操作，进一步保障代码质量，一系列流程耗时仅7min左右。整个Pipeline流程如下图所示：

Pipeline流程

六、总结

随着敏捷开发的推动，让每一次提交的代码进行一次完整的编译、测试、打包、发布，及早的发现并修复问题，保证研发质量的同时快速迭代产品，持续集成（CI）、持续交付（CD）在此中就是要体现出这样的价值。

在CI/CD升级实践中，针对CI检测和UI自动化测试等进行了一系效率和质量的优化，以实现最低成本的最高效测试。引入Lint检测和UT测试这种本身低成本的校验，缩短检测时间，而UI自动化这种成本比较高的检测，也利用UI自动化平台和CRN-WEB而达到多频次的测试。在代码合入主分支前，就进行发布、UI测试，提高了检测力度，减少了代码回退风险，使得UI自动化在前端集成中发挥了重要的作用，形成UI测试的闭环。

现在，机票APP主流程UI自动化测试用例覆盖率达到95%，由原来一组数名QA人员存在测试资源的紧张情况，到现在1名QA人员也能够完全承担起整组测试任务的状态。