Jenkins持续集成「编译打包代码检查单元测试环境部署软件测试」

Posted 2021-08-26 软件测试小dao

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Jenkins持续集成「编译打包代码检查单元测试环境部署软件测试」相关的知识，希望对你有一定的参考价值。

Jenkins 就是常说的 CI 平台（持续集成）。持续集成(CI)是一种实践，可以让团队在持续的基础上收到反馈并进行改进，不必等到开发周期后期才寻找和修复缺陷。

改进肯定是自己改进，反馈是谁提供呢？

最先应用在开发团队中，也就是“打包”。大型项目都是 Java 写的，它会遇到一些依赖包缺少了，语法写错了，引用的依赖文件没有或者依赖文件的函数被其它开发改了。

这个情况下去打包，就一定会打包失败并且完整告诉你哪个文件哪行代码出了什么错。开发人员在收到错误反馈后就会修改代码然后重新打包。这个就是尽早得发现它的问题，所以就是 Jenkins 发邮件的形式来反馈的。

没有 Jenkins 平台的时候有这些问题遇到：
Bug 总是在最后才发现（一定要提交到测试才会发现比较严重的 bug，在开发阶段可能发现不了）
越到项目后期，问题越难解决
软件交付时机无法保障
程序经常需要变更（前期不怎么改问题，到后面要上线了没办法，加班加点改，改完测试就得测）
无效的等待变多
长期得开发过程中无人监控，只构建打包无法保证产品质量。Jenkins 的定时任务在固定的周期内检测代码Jenkins 做全方位的质量监控。

版本管理提交代码，同时也要下载到本地更新一下。这个过程中开发是有很多个的：

可能出现 2 个人都要更改这个文件。或者我更改 A 和 B，但是我的 A 当中是有引用 B 的。我每天都要提交代码。既然有这么多人向版本管理系统提交代码，我需要检测下他们的代码能否能正常打包成一个文件，有没有引用的错误，语法的错误，有没有缺依赖包等等，这个都是通过将文件编译打包。

编译是将它打包成.class文件，这个文件更好得让机器执行。编译成.class文件得时候，假如文件 A 里面引入了文件 B，那么在编译得时候所有依赖得第三方库以及外部文件必须都能访问得到并且正确才能编译成功。

打包很简单，重要得是编译过程。打包包含了编译。每天都去编译打包，每天都能发现问题。

1.开发阶段
静态代码检测是个什么意思？
通过 Jenkins 平台来自动对代码进行静态检查。sonarQube 可以做这些事，它可以帮你发现基本的语法规范出错了和安全隐患问题。

1.什么是静态代码？

就是你的源码，就是在 svn 上面下载下来的源码库。去解析处理，如果这些都通过了就上线，没通过就修改你的代码。

sonarQube 可以和 Jenkins 完美得集成。sonarQube 会扫描出来到底是谁写的代码。哪一个文件，哪一行存在安全隐患。是什么安全隐患，应该如何修改以及哪一行代码有这个语法规范问题。请及时修改。

2.什么语法规范？

重复度。做一个大型的系统讲究分层设计，降低它的重复度，提高它的灵活度。如果给一个项目的代码给我，我扫描出来达到 50%的重复度。重复度太高就意味着非常得不灵活，通用共享做的太少。sonarQube 会给出提示，很明白告诉你，哪些文件的多少行是重复的。

就需要召集开发团队赶紧把问题改改，将重复度降下来。

复杂度。如果一个函数或者一个类里面的复杂度太高（for 循环，if else，for 循环不宜做的太深，2 层就够了。3-4 层，再下去复杂度就太高）。复杂度越高就意味着这个函数太难懂了，问题的可能性也非常大。

如果复杂度偏高，那你就要想办法将这个偏高的函数想办法将它简单化，降低它的复杂度，这样它的流程以及 bug 方面就不会有那么多。sonarQube 会从全方位的角度帮你检测你的整个项目在代码层面有哪些问题需要你去改。

sonarQube 会集成单元测试、自动化测试。还可以检测自动化代码的覆盖率。它不分语言，python、java 等都是可以做的。每一种语言都有对应的规则库，你都是可以下载的。自动化代码也是代码，你拿它去扫一扫，一样会给你个结果。

在正式编译打包之前，把静态代码检查先做了。如果尽早介入，不是等代码全部开发完成才介入。

定时来做这 2 件事：
可以从开发层面很好地把控代码质量。既然加入了 Jenkins，就会有邮件通知也会有报告展示。开发人员可以每周做一次总结并处理。

可以通过 Jenkins 再做单元测试，这个需要开发人员自己配合了，他们自己写了单元测试代码，我们才能将单元测试代码集成到 Jenkins 平台。如果开发不写，我们怎么测呢？
先做完静态检查，将它编译打包后，对打包后的代码进行单元测试，这个从整体的代码层面不是从业务层面，而是你代码的优质程度。单元测试从自己写的业务函数层面、系统功能层面，来自我检测一下这个有没有问题。

开发代码迭代：每一个星期给测试转一个测试版本，这个版本应该做单元测试。那么下一个星期，在历史的长河中，在软件开发的 2 年当中，逐步加内容改内容的时候一定会影响历史模块。

如果在这个过程中，你开发的每一个模块都带了单元测试，每次你转到测试之前全部都做次单元测试。如果你改了加了新的代码，影响了旧的代码但是你没有改，单元测试马上就会暴露出来。

开发人员在自我的层面来控制代码的质量，这就不用等到测试告诉你这个功能明明是好的，为什么到了这个版本又挂了？你在单元测试阶段就会发现。

但是，国内的场景是没有多少开发有做单元测试的意识。即使有的开发有这个想法，时间上也不允许。开发任务太重了，导致功能层面的代码质量全部压在了测试的身上。但是测试工程师不是万能的，很多隐藏的问题，尤其是开发层面的大 bug，我们一般是看不到的，除非是有些情况把它触发出来了。

所以这 3 个角度，是从开发人员业务和代码质量水平两个维度来把控代码质量。如果开发人员能把这 3 件事做好，到了测试的手上，问题基本上已经解决了一大半，很流畅，即便你要新增什么模块，优化什么的，在单元测试这个地方就直接暴露出来了。

2.测试阶段
1.环境部署
首先，环境部署，可能是测试做，可能不是测试做。环境有很多套：比如 DEV（开发环境）、SIT 环境(系统集成测试)、预发布环境。

DEV 环境有 1 套，SIT 环境有 4 套，预发布环境 1 套，一共 6 套环境。会有专门的环境管理人员，但是人家重点是服务器方面的维护。可通过 Jenkins 平台做自动部署。发布、部署测试版本的时候不需要去找环境管理人员了，直接在 Jenkins 平台上点击触发下这个工程构建就 Ok 了。

自动部署就是打包之后将这个包（这个包和 DEV 环境是同步的），将它部署到测试环境当中，然后解包出来。

测试包部署流程：开发一般只部署自己的测试环境，测完包后给到测试。正式环境一般都是运维。一般部署可能部署到 Linux 服务器上，而我们编译打包是直接可以在 Windows 机制上执行，当然也可以在 Linux 机制上执行。

要下载最新的代码将它打包，打包之后传送到测试服务器上。在测试服务器上再去将这个包解压到对应的路径下面（前提是通过网址访问将测试环境的服务停掉）。把这个包部署上去，更新代码之后，再将这个环境启动起来，完毕以后才能做测试。

如果想做这个事，先找开发好好了解下部署流程怎么做的，就知道怎么部署啦。部署完成之后就可以做自动化测试了。部署过程中会涉及各种操作，会涉及 python 脚本、shell 脚本，还用到上传的软件（vpm\\ftp），全看自己公司内部是怎么做的了。知道流程之后，再想想每一步我用代码如何实现。然后将这个代码纳入到 Jenkins 步骤当中，一步一步去做。

2.自动化测试
测试环节：手工、自动化、性能测试。所以自动化测试也要集成在 Jenkins 平台上。在部署环境成功之后，可以做冒烟测试、回归测试。

当然这里也需要有 svn\\git，互相管理下，这样无论在哪个环境去做自动化测试，脚本都是可以执行的。

也可以 2 台执行机同时做自动化测试。假如 Web 自动化测试，假设有 200 个用例，用 2 台电脑做分布式，怎么做呢？

希望在 Jenkins 上有 2 个 job 同时执行，每一个 job 执行的用例是不一样的，200 个用例本来要花 8 个小时，放在 2 个电脑上就只花 4 个小时。这就是通过 Jenkins 也可以实现一定程度的分布式。2 个 job 定同一时间执行就可以了。

如何从 200 个用例当中筛选 100 个出来？均分到 2 台执行机上。甚至根据模块划分，4 个模块，2 个模块在执行机 A，2 个模块在执行机 B。怎么划分呢？

Jenkins 上可以有 3-4 个 job，实现一定程度上的分布式。

在执行机 A 上执行这一个文件夹下的，执行机 B 上执行另外一个文件夹下的。组合标签，和测试用例文件夹一起来限定范围。pytest 可以执行某一个测试套件，某一个文件夹下的所有用例。

执行机 A 执行 moudleA 下的测试用例，执行机 B 执行 moudleB 下的测试用例。也可以执行单个文件夹下面的。

有目录级别的，加上标签过滤下就可以任意筛选你想执行的。主从模式可以节省你的执行时间。

部署预发布环境也是可以做的，就看实际项目了。

自动化测试的结果全部都是提到缺陷管理平台。

未完待续~