2022全网最全的持续集成基础【你知道的和不知道都在这里】

小码哥说测试

已于 2022-05-14 16:50:41 修改

阅读量372

点赞数 1

分类专栏：技术分享自动化测试干货分享文章标签： ci jenkins git 测试工程师自动化测试

于 2022-05-14 16:50:35 首次发布

本文链接：https://blog.csdn.net/jiangjunsss/article/details/124770306

版权

技术分享同时被 3 个专栏收录

1868 篇文章 74 订阅

订阅专栏

自动化测试

1651 篇文章 64 订阅

订阅专栏

干货分享

273 篇文章 20 订阅

订阅专栏

这一篇讲一讲持续集成的基础。没有持续集成，做自动化是不完整的，为了减少人工介入和提高迭代速度，现在越来越多的公司引入了持续集成系统。如果你自动化测试入了，下一步就是搞一个持续集成系统，不要再手工在本地触发你的自动化测试脚本啦。

所以为了让大家阅读此文后有尽可能强烈的获得感，本文行文结构如下：

一、持续集成之前自动化测试是怎么样做的

二、持续集成之后自动化测试是怎么样做的

三、关于如何学习持续集成

四、关于jenkins这个工具要了解的

五、小惊喜

一、持续集成之前

首先，看一下没有引入持续集成之前自动化测试是怎样做的：

这里引入了测试机的概念，测试机是指我们执行自动化测试脚本的环境。比如，我在自己电脑上执行一个selenium脚本做自动化测试，那测试机就是我的电脑。

测试人员在测试机上手工触发测试执行工具去执行某个自动化测试。并在测试执行完毕后由测试执行工具给出测试结果。

那么这里有几个问题：

我测试机上的测试脚本是不是最新版？
测试机上跑出来的测试结果保存在哪里，以后还能翻阅吗？
这次测试测了服务器代码的哪个版本？
如果我想让工具半夜自动执行这些测试可以吗？

等等，问题还有很多。

以上，在持续集成之前的自动化测试有很多问题需要解决。而持续集成可以很好地解决上述问题。

二、持续集成之后

当你引入了持续集成工具之后，初步的持续集成测试流程是这样的：

和之前的流程最大的不同是，测试不再由人工触发，测试结果被收集到持续集成系统中展示。

让我们再从整个项目的持续集成角度来看引入持续集成后的整个过程：

为了让描述更简单，以下用jenkins代替了持续集成系统，用git代表配置管理工具，一个简化过的持续集成流程是这样的：

首先，由jenkins在测试机上（通常是一个jenkinsslave），把待测软件的源代码从git里checkout，然后执行单元测试。单元测试通过后，源代码被部署到服务器上，之后开始系统测试。系统测试以自动化的形式执行，首先也是jenkins把测试脚本从git里checkout，然后调用测试执行工具执行测试，并生成报告。最后由测试执行工具生成的报告被jenkins收集起来，并展示在jenkin里。

于是，之前的问题都有了答案：

1.我测试机上的测试脚本是不是最新版？

git插件保证你执行的一定是最新版。（当然也可以自己指定版本）

2.测试机上跑出来的测试结果保存在哪里，以后还能翻阅吗？

结果自动收集在jenkins上，当然你还可以从jenkins上把结果再收集起来放到独立的存储空间里。

3.这次测试测了服务器代码的哪个版本？

git会checkout待测软件代码，然后开始整个流程，所以测试了待测软件的哪个版本只要看一下上游的记录就知道了。

4.如果我想让工具半夜自动执行这些测试可以吗？

当然，持续集成系统提供定时触发方式来触发整个流程。（也提供其他触发方式。）

最后，以上的持续集成流程图，是简化过的。实际上在一个真实系统里，这个流程一步一步，是比较长的。还要考虑各个测试环境的管理，代码配置管理策略，jenkins的使用策略，各种静态分析，资源监控等等。但如果你想做持续集成，不妨从一个简单的流程开始。我会在后续的文章里先把各种自动化测试基础理论介绍完，之后再涉及复杂的内容的探讨，敬请期待。

三、关于如何学习持续集成

前面已经讲了，持续集成之前和之后，整个自动化测试流程乃至待测软件版本发布过程有了很大的变化。

那么持续集成到底是干什么的呢？一般我们理解，就是为了加快迭代速度，尽早开始测试，尽早得到反馈，以最终提高交付的软件的质量。这个问题我记得我去应聘持续集成测试工程师时也被问到过。

然后这几年持续集成测试做下来之后，又有一点自己的理解。对于自动化测试，可能很多人都在搞，以至于大家耳熟能详的都是一些selenium、requests、jmeter、testng之类的自动化测试相关工具。但是，真正把自动化测试做好的，都离不开持续集成。

现在最流行的持续集成工具是jenkins，这个工具还是很有内涵的。可以说学持续集成就是学好怎样使用jenkins或类似工具。有的人会说，jenkins就是配一下插件完事儿，没啥技术含量。确实我们构建一个简单的持续集成流程是没多少技术含量的。但是，如果要从头搞出一套完整的，高效的，可靠的持续集成系统，就没那么简单。而其学习过程也比较长：

1.要对linux系统有了解，因为我们搭建了jenkins之后多半自己要当系统管理员。那么把jenkins部署在linux上是首选，所以要学linux。学习方法可以从看《鸟哥的linux私房菜》这本书开始。

2.然后对配置管理要有了解。持续集成系统要不断和配置管理系统打交道。换句话说就是你要学git。学习方法为看相关教程。对git的学习我后面也会写。

3.要对jenkins自身比较了解，各种配置、插件要会用。也就是学jenkins本身的使用。学习方法为看帮助文档。

4.要对自动化测试执行工具，及其的命令行模式有了解。也就是学习各个自动化测试工具。可以说，没有自动化测试的持续集成系统里出来的包是没用的。也就是说，持续集成离不开自动化测试。

5.要对软件开发有所了解，jenkins本身有时候功能并不够用。此时需要想办法扩展。举个例子，之前公司有一个jenkins持续集成系统，每次jenkins升级，这个系统就要停机。那么为了解决这个问题，可以用web开发的方式，开发一个小系统，让两个jenkins master变成互相热备份的状态。这样，当一台jenkins master升级时，系统自动切换到另一台上。系统不用再停机了。此外，基于jenkins提供的http接口也可以做一些扩展。当然，开发jenkins插件也是一种扩展方式，我之前公司就开发了一个测试结果自动备份插件，把每次跑出来的结果备份到独立的存储空间里。总之，持续集成要搞得好，你最好学一点开发。

四、关于jenkins这个工具要了解的

关于jenkins这个工具的学习，在具体点说一下。

首先，要理解jenkins的master-slave模型，master负责配置持续集成系统，以及调度slave，具体的业务由slave来做。理解这个分布式机制，我们就知道了，如果把要做的测试分成两半，一半交给一个slave，一半交给另一个slave，那么我们就实现了分布式测试。这里可以压缩很多测试时间。

然后，具体业务都在jenkins job里定义，这里的业务都是指流程，也就是一步一步往下走的。这也是为什么在持续集成之后，整个流程很明显地管道化了（一步一步）。我们要理解这个管道的概念。对以后使用jenkins2.0提供的pipeline功能很有帮助，虽然现在这个pipeline功能用的人还不多，但未来无疑是属于pipeline的。而不会一直像现在这样人肉去配置一个一个的jenkins job。以后你去找工作，面试官可能会问你，用过pipeline吗。

还有，jenkins的各种主要功能都来自于插件。你如果想要一个功能，就要找对应的插件。比如群里有网友问我怎样把测试结果报告展示在jenkins上。显然，首先你需要在你的测试执行工具里生成原始报告。比如testNG可以生成junit格式的xml报告，然后你在jenkins上选择对应的插件读取这个xml报告并转化成html格式展示在jenkins上。

但这些插件的功能可能不够完美，这时你需要自己扩展。比如前面说的测试结果报告插件很可能不能提供美观的报告。还记得jenkins的管道思想吗？这里就可以应用一下：

这样，我只要写一个小工具去读取原来测试执行器生成的原始报告以及读取一些其他我想要的数据，然后在小工具里去自己生成我想要的报告，最后输出。以python为例，python有很多数据可视化的库，随便找一个都可以作出非常漂亮的报告，可以说管理层想看的任何柱状图，饼图，流程图，散点图，3D图，没有做不到，只有想不到。一个比较好的应用就是自己搞一个美观又完善点的性能测试报告来代替jmeter那简陋的测试报告。关于测试工具的开发，我后面会再写文章来介绍，这里只提一个最简单的小工具的思路。其实做自动化测试的人，最好都掌握一定的开发技能，自己可以给自己开发一些工具，好用又方便。

关于jenkins这块，还有很多东西可讲，重点在于我们怎样用jenkins来实现自己想要的持续集成系统。这次就不展开了。

最后，如果你还没有做过持续集成，不妨亲自尝试一下，这是一个提高自动化测试程度的很好的开端。越是大公司，越是大项目，越是需要搞持续集成。持续集成系统也在不断演进，可以说这方面展开来，东西非常多。这也是大家一个很好的进阶方向。