万叶集🎉 隐约雷鸣，阴霾天空。 🎉🎉 但盼风雨来，能留你在此。 🎉
前言：
✌ 作者简介：渴望力量的哈士奇 ✌，大家可以叫我 🐶哈士奇🐶 ，一位致力于 TFS 赋能的博主 ✌
🏆 CSDN博客专家认证、新星计划第三季全栈赛道 top_1 、华为云享专家、阿里云专家博主 🏆
📫 如果文章知识点有错误的地方，请指正！和大家一起学习，一起进步👀
💬 人生格言：优于别人,并不高贵,真正的高贵应该是优于过去的自己。💬
🔥 如果感觉博主的文章还不错的话，还请👍关注、点赞、收藏三连支持👍一下博主哦
专栏系列（点击解锁）学习路线指引知识定位 🔥Python全栈白皮书🔥 零基础入门篇 以浅显易懂的方式轻松入门，让你彻底爱上Python的魅力。 语法进阶篇 主要围绕多线程编程、正则表达式学习、含贴近实战的项目练习 。 自动化办公篇 实现日常办公软件的自动化操作，节省时间、提高办公效率。 自动化测试实战篇 从实战的角度出发，先人一步，快速转型测试开发工程师。 数据库开发实战篇 更新中 爬虫入门与实战 更新中 数据分析篇 更新中 前端入门+flask 全栈篇 更新中 django+vue全栈篇 更新中 拓展-人工智能入门 更新中 网络安全之路 踩坑篇 记录学习及演练过程中遇到的坑，便于后来居上者 网安知识扫盲篇 三天打鱼，不深入了解原理，只会让你成为脚本小子。 vulhub靶场漏洞复现 让漏洞复现变得简单，让安全研究者更加专注于漏洞原理本身。 shell编程篇 不涉及linux基础，最终案例会偏向于安全加固方向。 [待完结] WEB漏洞攻防篇 2021年9月3日停止更新，转战先知社区等安全社区及小密圈 渗透工具使用集锦 2021年9月3日停止更新，转战先知社区等安全社区及小密圈 点点点工程师 测试神器 - Charles 软件测试数据包抓包分析神器 测试神器 - Fiddler 一文学会 fiddle ，学不会倒立吃翔，稀得！ 测试神器 - Jmeter 不仅是性能测试神器，更可用于搭建轻量级接口自动化测试框架。 RobotFrameWork Python实现的自动化测试利器，该篇章仅介绍UI自动化部分。 Java实现UI自动化 文档写于2016年，Java实现的UI自动化，仍有借鉴意义。该工具目前的应用场景已不多，文档已删，为了排版好看才留着。
文章目录
今天要和大家来聊聊关于自动化测试的持续集成，通过前文的学习，我们的自动化测试框架、测试的思想已经融入到了整体的代码编写过程中了。接下里的下一步就是如何让自动化测试能够像开发一样、敏捷思想一样，能够持续集成的跑起来。可能大家对持续集成还不是太了解，那就先简单的了解一下持续集成的思想吧。
🐳 持续集成思想
现如今的互联网软件的开发与发布，已经形成了一套标准流程，最重要的组成部分就是持续集成。（简称
CI
，其实就是
Continuous integration
）
见下图：（这个图的描述的就是持续集成在不断的开发、发布、测试… 这样的轮回的一个过程 ，快速的进行迭代。这就是持续集成的一个核心概念。）
所以，持续集成指的就是
"频繁的（一天多次）将代码集成到骨干"
；
集成的好处主要有以下几点：
- 1、
快速发现错误；定位错误也比较容易，精确的知道是哪次提交导致了这个错误。- 2、
防止分支大幅偏离主干；如果像是以前的瀑布式开发，大家都在自己的本地进行开发。当开发的差不多的时候 ，在推到主干上去（此时经常已经过去了一个比较长的周期）。如果不是这样的经常集成，会导致以后的集成难度越来越大，设置会出现太多的错误导致难以集成的情况。
持续集成的目的：
让产品可以快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。
Martin Fowler 说过："持续集成并不能消除Bug，而是让它们非常容易发现和改正。"
持续集成的前提是能够做到完善的自动化测试、能够自动的构建部署，所以这里面就有了自动化测试的集成。其实准确来说，自动化测试的持续集成也分为两个方向：
- 1、
针对代码:就像开发人员一样，开发每次提交代码，都会开始自动部署、自动化测试。自动化代码也是一样的，当每次进行提交的时候，可以让其自动的执行自动化测试。自动的跑一遍，来验证我们的代码。（当然了这不是我们的目的，我们的主要目的是下面的第二种）- 2、
验证最新版本的代码：当开发进行最新的代码的部署之后，我们利用最新版本的自动化代码去验证开发部署的代码是否有问题。这是自动化测试的集成非常重要的一点，所以才在这一章节中带着大家一起去了解怎么样将前面写好的自动化测试脚本，做成持续集成的样子。
ps：要使用集成，必然要有对应的工具，这里我们使用的是最常用的工具 ---> "Jenkins"
🐳 Jenkins 介绍
Jenkins 简单介绍及优点:
Jenkins是一款 非常简单、非常好用、也是非常通用化的持续集成引擎，即使是如今国内的一线大厂自己研发的集成工具，本质而言底层使用的也依然是Jenkins；所以我们也说 "Jenkins" 是一款可以扩展的持续集成引擎。Jenkins是所有 CI 产品中在安装和配置上最简单的- 基于 WEB 访问， 用户界面非常友好、直观、灵活。
Jenkins 主要应用场景：
- 持续、自动地构建 / 测试软件项目
- 监控一些定时执行的任务
Jenkins 特点：
- 是基于 Java 开发的（这首先就代表着其拥有很强的扩展性）
- 不仅限于构建基于 JAVA 的软件，所以它又拥有着强大的通配性
Jenkins 拥有大量的插件，这些插件极大的扩展了 Jenkins 的功能，可以直接通过 WEB 界面来进行安装与管理，使用起来非常的快捷和迅速。- 可以和现有的代码库：git、ant、maven 等快速的集成，并且能很好的执行自动化测试。
关于安装、配置、搭建 Jenkins 继承环境的场景参考下面两篇文章：
- Mac 安装 homebrew 详细教程
- Mac 利用 homebrew 安装部署 Jenkins 持续集成环境
🐳 利用 Jenkins 配置部署自动化测试的集成环境
- 1、新建项目，选择自由风格。
- 2、进入集成项目的配置页面- 2.1、general 【描述这里随便填写，一般填写项目的简述】---
---- 2.2、源码管理 - 如果有SVN、Git 的情况下，选择 Subversion ，然后填写我们的SVN、Git 地址- 这里因为我们没有SVN，所以我们选择 None---
---- 2.3、构建触发器（比较重要的是 【其他 "工程构建后触发 " - “build after other projects are built” 与 “定时构建” - “build periodically”】）- 触发远程构建- 其他工程构建后触发 —> 英文为 “build after other projects are built” ，其实也就是
持续集成。- 定时构建 —> 英文为 “build periodically”- GitHub hook trigger for GITScm polling- 轮询 SCM —> 英文为 “poll scm”------
🐬 定时构建任务 - build periodically
这里我们先来介绍一下
定时构建的任务（主要有5个参数，见下图）
定时构建语法如下：
* * * * * 注意：五个“*”之间有空格，从左到右分别是 分钟 小时内的分钟数（0-59） 小时 一天中的小时（0-23） DOM 每月的一天（1-31） 月 月份（1-12） DOW 星期几（0-7），其中0和7是星期日。要为一个字段指定多个值，可以使用以下运算符。按照优先顺序
* 指定所有有效值 M-N 指定一个值的范围 M-N/X或者*/X在整个指定范围或整个有效范围内以X为间隔步进 A,B,...,Z 枚举多个值为了允许定期安排的任务在系统上产生均匀负载，H应尽可能使用符号（对于"散列"）。例如，使用
0 0 * * *十几份日常工作将会在午夜造成大量高峰。相比之下，使用
H H * * *仍然会每天执行一次，但并非全部同时执行，而是使用 有限的资源。
所述H符号可以与范围内使用。例如，
H H(0-7) * * *意味着在凌晨12:00（午 夜）至上午7:59之间的某段时间。您也可以使用H带或不带范围的步距。
该H符号可以被认为是一个范围内的随机值，但它实际上是作业名称的散列， 而不是随机函数，因此对于任何给定的项目，该值都保持稳定。
请注意，对于月份日的字段，由于月份长度可变，因此短周期（例如
*/3或
H/3不会在大多数月份结束时保持一致）。例如，
*/3将在一个月的第
1,4和
31天运行，然后再在下个月的第二天运行。哈希总是选在
1-28范围内，所以
H/3在一个月的月底之间会产生3到6天的间隔。（更长的周期也会有不一致的长度，但效果可能相对较不明显。）
以空格开头的空行和#行将被忽略为注释。
此外，
@yearly，
@annually，
@monthly，
@weekly，
@daily，
@midnight，并且
@hourly也支持方便的别名。这些使用散列系统进行自动平衡。例如，在一小时内的任何时间
@hourly都是相同的
H * * * *,并且可能意味着
@midnight实际上是指从凌晨12:00到凌晨2:59之间的某段时间。
（怎么读都感觉这里有些不通顺，但是又想不出来怎么组织语言）例子：
＃每十五分钟一次（可能在：07，：22，：37，：52） H / 15 * * * * ＃每小时上半场每十分钟一次（三次，也许是：04，：14， 24） H（0-29）/ 10 * * * * ＃从上午9:45开始每小时45分钟，每个工作日下午3:45结束，每两小时一次。 459-16 / 2 * * 1-5 ＃每周工作日上午9点至下午5点每隔两小时一次（可能在上午10:38，下午12:38，下午2:38，下午4:38） HH （9-16）/ 2 * * 1-5 ＃每月1号和15号每天一次（12月除外） HH 1,151-11 *
🐬 持续集成（其他工程构建后触发 ） - build after other projects are built
🐬 构建环境
PS：关于
构建环境
， 根据需要选择（可不选）
🐬 构建
MAC 配置环境遇到了个问题卡住了，明天补上。
这里因为我使用的是 Mac ，所以我选择的就是
Execute shell
，然后输入 启动、运行脚本命令
cd /Users/caoke/PycharmProjects/test
python3 test_login_suite.py
这里构建会遇到各种稀奇古怪的问题，我就记录下来两个，参考如下：
Mac环境下Jenkins部署Python报错 - ModuleNotFoundError: No module named ‘selenium‘ (已完美解决)
Jenkins部署Python报错 - selenium.common.exceptions.WebDriverException: Message: ‘chromedriver‘ executabl
运行结果如下：
OKK，搞定！太难受了啊！
🐳 如何让 Jenkins 拥有一个属于自己的报告
接下来我们想要做的更多一些，比如想要
Jenkins
完成构建之后生成一份属于自己的报告。OK，那么久进入
配置
里面配置一下我们的报告吧。
进入配置页面后选择
构建后操作
（也就是最后一个）
选择
Publish JUnit test result report
。
需要注意的地方哈，其实我们的脚本里并没有生成 “.xml” 格式的报告，所以即使保存了也不会生成。
所以这个时候，我们需要回到我们的脚本中，将我们的代码修改为生成
".xml"
格式的测试报告。
修改脚本之前，需要安装一个第三方模块
xmlrunner
，安装命令
pip install xmlrunner
，或者直接在设置中心安装。
test_login_suite.py
模块的脚本修改如下：
# coding:utf-8import sys
sys.path.append("/Users/caoke/PycharmProjects/test")import unittest
from travel_login_ddt import TestTravel
from HTMLTestReportCN import HTMLTestRunner
from xmlrunner import xmlrunner
suite = unittest.TestSuite()
suite = unittest.TestLoader().loadTestsFromTestCase(TestTravel)# file = open("result.html", "wb")# HTMLTestRunner(stream=file, title="UI自动化测试报告", description="User:Husky\nCase:test_login").run(suite)
xmlrunner.XMLTestRunner(verbosity=2, output='测试报告').run(suite)# 这里的"outout"的值要与 Jenkins 设置的报告名称路径一致if __name__ =='__main__':
unittest.main()
此时，再次重新构建回生成一个
XML
格式的报告，可以在
Jenkins
中查看，但是这里因为我配置的路径有问题，始终无法在 Jenkins 查看到，但是目前我也不想解决了，耽搁我太多时间了。报错内容如下，就是配置的报告路径的问题。（
后续解决了我会回来把这个坑埋了的，哪位大佬如果知道如何解决的话，还请不吝赐教。
）
错误信息如下：
ERROR: Step ‘Publish JUnit test result report’ failed: No test report files were found. Configuration error?
如果哪位在运维领域有涉足，知道如何解决这个问题的话，还望不吝赐教。后续如果我解决了的话，我也会更新上来！
版权归原作者 不渴望力量的哈士奇 所有， 如有侵权，请联系我们删除。