利用 jenkins 关联 Job 方式完善 RobotFramework 测试 Setup 以及 Teardown 后操作

1.前言

2.Jekins 关联 Job 方式

1.前言

Jenkins是一个流行的持续集成和交付工具，它可以帮助自动化构建、测试和部署软件。与Robot Framework结合使用，可以实现更高效的测试工作流程。

在Robot Framework中，Setup和Teardown是测试用例中的两个重要部分。Setup用于准备测试环境和数据，而Teardown用于清理测试环境和数据。通过与Jenkins的关联，可以在测试执行前后执行一些额外的操作，以进一步完善测试流程。

一种常见的做法是使用Jenkins的"Pre-build"和"Post-build"操作来关联Robot Framework的Setup和Teardown。在"Pre-build"操作中，可以执行一些准备工作，例如启动应用程序、配置测试环境等。在"Post-build"操作中，可以执行一些清理工作，例如关闭应用程序、清理测试数据等。

2.Jekins 关联 Job 方式

这个都说到烂了，就不再多说了，就说我遇到的问题，我这里自动化测试其实有几个过程，其实是走持续集成的方法 (可能只是看起来而已)，就是从收到开发代码 build 成功的 hook 开始，触发测试环境获取新的安装包部署，检查部署是否成功，执行自动化测试，输出测试报告发送邮件或其他通知方式，过程大概是这样

(1) 说明一下那个测试通知和邮件报告的，因为有一个通知方式是直接接入到我们项目的（通讯工具），所以这里就补充了一下，说到这里有人会想到，自动化测试这一块可以直接放到 RobotFramework（以下简称 RF），但更新测试环境和发送通知和邮件测试报告这些模块如果直接放到 RF 的 Setup 和 Teardown 显然会有些鸡肋，毕竟想让自动化测试的执行过程更加独立，而且更好地控制整个流程，一开始我也想不到什么好方法，后面某天突然脑袋一闪想起 Jenkins 是有关联 Job 的功能，一切解决了，后面就开始我上图的设计了

(2) Jenkins 的 Job 可以如下图这么分

a、第一执行的 Job 是更新测试版本的 Job，这个 Job 是通过收到开发代码 build 成功的通知之后自动触发的，具体怎么触发用过 jenkins 的小伙伴都应该知道，就不多说了，获取了新包之后就会更新部署测试环境，在此之前测试环境会清理一遍环境，更新完成之后检查是否更新版本成功，目前我自己设置的检查点可能还有点简单，看新包是否有成功部署到测试环境，前端方面看是否能正常打开页面登录，后端方面调登录接口是否能正常登录返回正确数据，都通过的话，更新就算成功了，更新测试版本的 Job 构建为 stable 后就会触发执行自动化用例，如果更新失败就会发送更新失败的通知到相应负责人（一般就是我了=。=），然后就去检查测试环境情况，把环境等问题都弄 ok 了，再手工触发一下，所以要执行自动化测试的前提是测试环境新版本可以用啊，都不能用还怎么测呢

b、执行完自动化测试用例后，如果出现非 Stable 的情况，就会触发失败用例重跑的 Job，至于 RF 的失败用例重跑的方法，之前也有很多人问，在这里就说一下，在本地操作是这样的

要结合 Jenkins 的话只要能拿到对应的 output.xml 就能做到了，这里就不多说了，自己摸索试试，然后就可以将失败的用例重跑，一般也就重跑一次，都完成之后就触发发送测试完成通知的 Job，一般是执行用例的 JOB 为 Stable 或重跑用例的 JOB 完成后关联自动触发，主要是邮件测试报告和消息通知，说到邮件测试报告，RF 的测试报告有个坑就是报告源码里有 JS，邮件都不会支持 JS 的话，除非你想来 XSS，所以只能用别的方法了，说到这里先展示一下我自己做的邮件测试报告

测试通过（第一期）
测试失败的（今天优化了一下）

这个测试报告分 4 个模板，版本信息，测试基用例统计，跳转链接和失败的测试用例展示，版本信息是直接去测试环境取的，测试用例统计是通过调 jenkins 的 api 获得的，怎么获得，来到页面点一下这个你就明白了

在点点就会看到

这样子测试用例统计就能做了，然后第三模块就是那几个跳转到 jenkins 看测试报告和测试日志，最后的失败测试用例的获取是通过 python 爬虫实现的，就是把 job/3/robot 下 fail test 那里爬下来，自己作一下优化展示就好，就这样，邮件的一个比较基本的测试报告也完成了，整个自动化测试的过程大概就是这样子，现在在我们项目中每天都会跑一次来过每个 dev 版本的核心功能，这样一来把自动化测试过程的 Setup 和 Teardown 都很好地分离开来，也方便以后地扩展和维护