测试开发的技术 - 持续集成化

Posted 2021-08-12 测试baby

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了测试开发的技术 - 持续集成化相关的知识，希望对你有一定的参考价值。

在这里插入图片描述

持续集成化

持续集成包含的范围也很广阔，然而很多人认为持续集成不就是搞个jenkins嘛，这还用讲？我就遇到过这样的质疑，有面试官认为持续集成很简单，没什么价值，还替我总结了“那你就是装了个jenkins，配了两个job呗？”这样的认识过于片面。

我来谈一谈我对持续集成的认识与理解，以及其技术要点。

持续集成做的事是，在自动化的基础上更进一步，让测试不需要人手工来触发。但，这绝非把触发自动化测试的脚本移动到jenkins上那么简单。这里涉及到了很多麻烦的问题，今天挑其中四个主要的来讲：测试环境的管理、持续集成工具本身的安装配置与维护、待测软件和测试脚本的分支管理及各分支测试策略的制定、持续集成工具与其他工具的集成。

一、测试环境的管理

为什么测试环境的管理也成了个问题呢？在做不涉及持续集成的自动化测试时，我们是人工搭建和确认测试环境准备好了，才开始触发自动化测试的。而持续集成要减少人工干预，第一步就是让测试自动触发，而不是人工触发，那么问题就来了，触发测试时，测试环境是否已经准备好了？

为了解决这个问题，我们要管理测试环境，管理测试环境有两种主流做法。

1.第一种是“羊群法”。持续集成的流水线（pipeline）从待测软件源代码开始，先用源代码装出一个待测软件的环境。然后再开始在这个新安装出来的环境上做测试。这种方法通常应用于云计算环境中，因为可以快速建立相同的虚拟硬件。此时，测试环境就像羊群，每一只都很相似，饲养时不需要特殊对待其中某一只羊。羊群里的羊，我们没有给他们起名字，而是动态命令，比如env_001，env_002，

2.第二种是“宠物法”，使用工具或手工维护一系列可以用的测试环境，人工保证这些环境一直都处于能用的情况下。持续集成直接不搭建环境而针对这些人工维护的环境来做。此时，测试环境就像宠物，每一只都有各自的个性（比如服务器硬件不同），而且测试人员还喜欢给环境起宠物名字，比如我们在诺基亚曾经用过一些名字来称呼那些测试环境：Venus，Mars，等等。还要经常由专人伺候这些宠物，比如我负责维护Venus，你负责维护Mars。谁要用Venus得通知我一声才能用。

通常，当待测软件的安装耗时较短、安装操作较简单时，我们选择第一种方法，反之选第二种。举个例子，在诺基亚我们安装一台通信设备上的测试环境，非常麻烦，要从操作系统开始装一直到装好我们的待测软件。耗时3-8小时不等，还有失败几率。当时我们主要选第二种方式，人工维护设备，且有冗余设备以备不时之需。后来，我们架构改成了x86的云架构，不再需要通信设备，直接改成在云平台上虚拟设备，此时，我们改成了使用第一种方法（其实在通信设备的自动化成熟后就改成了第一种方法，但环境准备仍然有时会失败）。此时，搭建环境非常的简单，只需要20-60分钟时间，且配置文件极其简单。

二、持续集成工具本身的安装配置与维护

持续集成工具，比如jenkins本身的安装、配置、维护其稳定性，并没有想象中的容易。如果用户少，自然简单，用户越多，这个任务难度越大。我一个人用的话，我甚至可以要用的时候开，不用的时候关掉。而如果有两百个人使用我这台jenkins，即使我要升级它的版本，我都得考虑我是做热备份还是冷备份，备份完了才能升级。

觉得jenkins搞搞很简单的朋友们请看以下这些问题：

主节点（master node）装在哪儿，硬盘用多大，可以扩展吗，几个cpu，多少内存，用户怎么鉴权，用户权限怎么控制，插件装哪些，怎么升级jenkins版本，怎么升级插件版本，日志把磁盘控件占满了怎么办，jvm参数配哪些怎么配，用哪种安装方式（rpm？war？docker？），master挂掉了怎么处理，从节点（slave node）装哪儿，要动态创建动态销毁吗，日志存哪里，怎么监控各个slave资源使用情况，每个slave配几个执行器（executor）效率最高，配到多少运行多少job会卡死，slave卡死了怎么恢复，数据怎么保证不丢，怎么处理长期不用的job，怎样清理没用但占用极大硬盘控件的文件，怎么给job合理分组，怎么配置jenkins的https证书，怎么配csrf token，怎么用job触发另一个job，怎么把主要job的状态集中展示，怎么配时区和时间同步。等等。

看到上述一大堆令人头皮发麻的问题之后，我们以后看到一个稳定运行复杂业务的jenkins时，就直到背后维护人员付出的努力有多大了。为了解决这些问题，我采用的方法是脚本化。写脚本来处理各种麻烦事情。jenkins支持使用http api做简单操作，也支持groovy脚本来做复杂操作。这仅仅是工具本身带来的麻烦的一半内容，另一半麻烦在持续集成工具与其他工具集成的时候才会出现。

三、待测软件和测试脚本的分支管理及各分支测试策略的制定

这里，测试策略、分支管理模型都和持续集成关系极大。因为，我们如果要触发一个持续集成任务（job）。那么有三个层次的触发方式：

1.手动触发。测试人员打开job点一下。

2.定时触发。每天或每周到点了自动触发。

3.通过服务端接口（hook，也有人直译为钩子。）触发。提交代码到版本控制工具比如git后，由该工具的服务端比如github触发job。

如果我们要做到3，那么就要定义好在不同的代码分支上触发不同的job或者pipeline。这里问题就多了，代码要分几个分支来管理，用哪种git flow模型，不同分支上触发的job或者叫pipeline里要包含哪些步骤，其中哪几步是做测试，做什么测试，怎样判断其通过与否，能否允许代码进入下一个分支的条件是什么，hook发送失败怎么办，job应该触发时jenkins不巧正好挂掉了怎么办，需要同时触发多任务来的特殊代码怎么办（比如一个微服务应用包括几百个服务，需要并行部署，而不是一个一个部署，一个一个部署实在太慢了），在哪一个分支引入哪些第三方工具（比如代码扫描），在紧急情况比如需要紧急修复bug时怎么跳过耗时很久的流水线步骤（pipeline stage）。怎么控制各个job的权限，避免job A误删job B的资料。等等。

这都是持续集成化要考虑的问题。所以就别说持续集成简单了。这里面很复杂的。

四、持续集成工具与其他工具的集成。

今天讲的最后一点是工具集成。首先科普一个概念，jenkins的插件一般不包含功能本身，功能本身大多数是由对应的软件来提供的。比如jenkins上安装了git插件之后，不代表就能在jenkins上使用git了，我们哪台slave要用git，就必须在这台slave上安装git。插件只是起到一个接口和管理的功能。大家可能看过运维开发（devops，说句题外话，devops翻译成运维开发实在不妥，因为devops是开发、运维、测试三者的交集，起名字的人直接把test从devtestops里省略掉了。同理，测试开发这个词把运维给省略了，但其实测试开发要掌握很多运维知识）的工具链，围绕着jenkins由几十种第三方工具可以集成上来。我们还可以自研一些工具，把工具化和持续集成化结合起来用。

然后，这里有一个巨大的坑，值得我单独起一段来强调。那就是：这些第三方工具和jenkins插件，都有可能有Bug，而这些Bug谁来修？就只有我们自己修啦。千万别觉得持续集成简单，光这个修bug就够喝一壶的了。有一些bug很麻烦，很难修，很隐蔽，危害很大。比如，我们目前遇到却没修的一个bug：jenkins上使用github的oauth鉴权的插件，会在我们打开任意job的url时，对整个jenkins所有job的权限做检查，检查当前用户有没有权限访问这些job。当job很多的时候（我的测试jenkins最多的时候几百几千个job），jenkins就直接卡住了，jvm内存不够用，然后cpu占用100%，动都动不了了。谁说持续集成简单的，很麻烦的。所以有jenkins的付费版cloudbee，有专业公司来替用户解决这些问题，但是那个价格嘛，高到足以劝退一般用户。

持续集成平台或工具的研发

正因为上述难点和cloudbee的高费用问题，导致了有条件的企业可能选择自己研发持续集成工具，我之前诺基亚也有不少人想要研发各种各样的持续集成工具。包括但不限于：用两个jenkins master 一主一从做热备；用jenkins+docker+zookeeper等一些工具来搭建master 节点集群化且能动态新建销毁的jenkins；在jenkins上面开发一层web平台，底层仍然用jenkins 触发job的完全自研平台；从头开发一个持续集成平台，并且可以用jenkins master做它的slave，但这个和上一个区别在于，它还支持其他类型的slave（只可惜我未见到成品）。

要不要自研持续集成平台或工具，我觉得主要取决于有多少资源。没人没资源硬要搞，是非常困难的。因为这些自研工具平台会引出测试开发界最大的问题：测试脚本/工具/平台本身的质量问题。于是，我们遇到过为持续集成平台开发持续集成测试的需求，这就变成套娃了。要解决这个问题，只有一个办法，让开发工具平台的开发人员接地气，自己使用这些工具平台做业务测试，至少也要用自己的工具平台来测试自己的工具平台。

这里给大家整理了一份《软件测试工程师进阶的技术栈》，包含了诸多技术栈，希望能帮助在升级打怪中提供中坚力量