随着科技日新月异的发展，人工智能正逐渐渗透到我们生活的各方各面，从智能语音助手到自动驾驶汽车，从智能家居到人脸识别技术，AI正以其卓越的智能和学习能力引领着新时代的发展方向。

在这个快速演进的时代中，软件测试领域也受到了不小的冲击。虽然在当下，传统的软测技术仍然是绝对的主力，但是身为IT行业中的一员，近几年AI的全新业务体验与其超强的算力所带来的震撼感受也应该远超其他行业。

所以为了跟上时代的步伐，作为软测的大家是不是也应该考虑如何让AI辅助我们更加完整高效的完成日常的各类质量保障工作呢？

作为DevTestOps工作流中极其重要的一环，如何将CI/CD更加灵活完善的融入项目开发交付中的各类场景，一直是广大公司与团队的一项持久课题。而依托于现在一些主流的CI/CD软件的强大兼容性与接入能力，mabl自身强大的自动化测试能力可以灵活地被运用起来，在部署过程中集成mabl平台，那么相关的自动化测试代码部署到 CI/CD 管道中的托管环境后就可以立即在多个浏览器中测试端到端的用户体验。针对于测试活动中存在多个环境的情况，那么就更适合使用此类的集成方式了，因为它本身就是可以集成在CI/CD中进行跨环境运行测试任务。

本文主要以目前主流的jenkins为介绍对象，其他的CI/CD软件环境本期暂不介绍。

我们进行环境集成前需要先下载jenkins中的mabl插件，具体的地址为：[mabl Jenkins 插件](https://plugins.jenkins.io/mabl-integration/)

此插件可以帮助我们在自己团队的jenkins环境中运行mabl平台服务，并针对mabl服务进行一些灵活的调整。

安装的时候需要注意Java的版本不能低于8，Jenkins的版本不能低于2.319.1，不然在安装的步骤就会报错。安装的步骤与其他的jenkins插件相同，通过GUI或CLI中输入命令都可以，或者在上面给出的链接中下载完上传到你的Jenkins实例。

✔️可以到我的个人号：atstudy-js

即可加入领取【转行、入门、提升、需要的各种干货资料】

内含AI测试、 车载测试、AI大模型开发、银行测试、游戏测试、数据分析、AIGC...

安装完毕后，为了让jenkins可以顺利的接入mabl的服务，我们需要先配置一下mabl的API key。进入mabl选择侧边栏的Settings，进入后点击右侧画面的APIS选项，这个是管理所有API key的地方。点击Create API Key按钮，这里因为是用于CI/CD环境集成调用使用，类型一定不能选错哦。

完成后我们可以在API Keys列表中看见我们刚创建的API Key信息，具体的密钥值可以点击记录中的眼睛图标显示。

有了对应类型的API Key之后，我们就可以在Jenkins中创建对应的凭证，记得创建的时候要选择全局凭证，类型选择Secret text，ID随意，Secret内填入刚才在mabl中创建的密钥值即可。

这里需要注意的是，如果你的本地自动化测试环境与CI/CD中的不一样，前几期文章中提到的mabl的对应测试程序环境与测试用例中的被测对象一定要按照实际情况进行修改，以防出现换了个环境用例全部都跑不通的情况出现。具体的设置方法之前已经介绍过了，需要的同学可以去前几期看一下，这里就不再展开介绍了。

接下来我们为了顺利在Jenkins中出发mabl的任务，获取mabl中对应应用程序的ID则是必不可少的，这里可以理解为在Jenkins中触发mabl中的测试用例集，就必须调用对应被测对象的所属mabl应用ID，这个对应的ID可以在mabl的Settings中的workspace标签找到。

同样的，如果要获取资源的ID或者应用程序的ID，我们也可以在Tests中点击某一个测试用例集界面上方的命令行按钮。

这里同样会显示出测试用例集的ID和应用程序的ID，大家可以根据实际的测试需求来进行对应的任务触发和调用。另外还需要注意的是，如果你配置了某个用例集和应用程序的任务，但是将他在mabl中禁用了，那么在Jenkins中是不会进行触发和执行的。

做完以上的这些步骤之后，我们就可以在Jenkins中进行对应的设置。这里是新建自由项目还是管道，还是使用旧的项目都是可以的，具体根据自己的情况判断。我们在构建页面中点击Add build step按钮，就可以在菜单中看到Run mabl tests的选项了。

选择后，在对应的构建步骤中，我们在API列表中选择之前在Jenkins中创建的API Keys。在应用程序ID或环境ID中选择一个，这里必须和你在mabl中存在的应用ID或者workspace ID对应上。

最后比较重要的就是mabl的管道添加，我们选择配置选项，然后在脚本框内插入对应的脚本即可。可以使用“Pipeline Syntax”工具来进行编写。可用的参数如下：

• applicationId：应用程序的ID，和之前的一样这里无论是填写环境ID还是应用程序ID都是可以的，选其一。

• continueOnMablError：当mabl执行出现错误的时候仍然继续处理

• continueOnPlanFailure：当mabl中的用例或者计划失败仍然继续处理

• environmentId：运行的环境ID

• restApiKeyId：所需部署workspace的API Keys的ID，这里需要注意ID是Jenkins中分配给对应密钥的ID

• labels：标签，可以为任务打上自定义的标签，执行的时候可以区分标签来继续执行

• mablBranch：分支，指定的话会执行对应分支下的所有测试集和用例

如果管道语法中有不想要配置的参数项，需要置空，保留参数名。

声明性管道：

脚本化管道：

我们在全部设置完之后就可以正常的运行Jenkins中的测试任务了，如果之前已经有了任务触发条件也不用做任何的修改，维持原状即可。

Jenkins中的任务执行完成之后，我们可以在mabl中查看或者利用Junit插件来查看。插件的安装不再重复介绍，在构建步骤中添加Publish JUnit test result report，在下方的界面中配置报告XML的文件名，勾选Do not fail the build on empty test resultsr，然后保存。

之后运行每次的测试任务，完成时都会生成一份名为report.xml的测试结果报告，界面如下：

另外将mabl平台集成进CI/CD环境后，我们还可以使用无头模式对被测对象进行端到端测试，但这里需要用到mabl的CLI（命令行接口），一般的测试场景都是处于项目开发阶段的前期，对于还未提测的浏览器产品版本进行测试左移，相较于已经趋于功能成熟的被测对象，开发阶段的软件最大的特点就是逻辑与功能变更频繁，那么基于快速灵活的CI来说就是再适合不过了，我们可以按照自身产品测试业务的条件来设置合适的任务触发条件，比如当某个分支的代码出现了改动，我们的测试任务就会自动执行，从而在项目生命周期较早的阶段来进行测试介入与问题快速修复，从而有效降低整个项目的开发成本。

当然，以上的这些都是一些比喻，真实的工作情况肯定要复杂的多，所以在CI/CD的环境下，在业务逻辑复杂度适当的情况下，mabl代替某些自动化测试框架的实战场景，其中的性价比高低显然不言而喻，毕竟与其苦哈哈的花大时间用在调整自己的测试框架，还不如用专业的测试saas服务商提供的成熟测试平台？这里相信大家心里自有各自的一杆秤。