一种持续集成持续交付的验收系统的制作方法

本发明涉及软件开发技术领域，具体而言，为一种持续集成持续交付的验收系统。

背景技术：

不断变化的用户需求、缩短的开发周期、频繁的部署上线，传统的人工部署和测试已经心有余而力不足。随着软件产品的应用范围越来越广、功能越来越复杂，以现有技术，产品在从需求到部署的过程中，会经历若干种不同的环境，例如qa环境、各种自动化测试运行环境、生产环境等。这些环境的搭建、配置、管理，产品在不同环境中的具体部署，状况非常复杂，需要花费大量的时间运行这些脚本，它们会一遍遍地安装这些重复的工具，而且可能会有新的功能加进来，从安装到各类型测试到交付的时间会继续被拉长。如果等到所有开发都完成才向下个环节交付，导致所有的问题只能在最后才爆发出来，解决成本巨大甚至无法解决。

有鉴于此，特提出本发明。

技术实现要素：

针对现有技术中的缺陷，本发明提供一种持续集成持续交付的验收系统，提高测试效率。

为了实现上述目的，本发明的技术方案为：

一种持续集成持续交付的验收系统，包括持续集成部署模块和持续测试模块以及持续交付单元；其中

持续集成部署模块：用于接收开发机开发代码到svn，触发jenkins构建，扫描该代码并将代码打成docker镜像，推送到私服docker-registry，以供kubernetes-master在k8s-master上执行rc和service的创建，进而创建pod，从私服拉取镜像，根据不同的tag名称部署不同的环境；

持续测试模块：用于根据测试策略调用不同的测试类型组件，并行测试，收集测试结果，形成测试报告；并将测试通过的版本推送到私服docker-registry，并标记为release版本；

持续交付单元：用于拉取release版本的镜像部署到线上环境。

进一步的，所述持续集成部署模块包括svn、jenkins、kubernetes以及docker-registry仓库。

进一步的，所述持续集成部署模块的工作步骤包括：

s11.通过在svn上打tag，每个tag根据策略生成一个版本号；

s12.svn代码仓库对commit操作配置钩子webhook，svn通过webhook，通知jenkins更新；

s13.jenkins更新本地代码，启动代码扫描工具，根据代码规范对代码进行扫描，代码检测通过后进行s14.操作，否则发送邮件代码检测失败并退出；

s14.jenkins接收到构建任务后，从svn拉取最新源码，进行编译打包；

s15.根据dockerfile文件生成镜像，push镜像到镜像仓库；

s16.jenkins调用kubernetes集群的master节点，更新pod的模板yaml文件，调用kubectl命令进行发布操作；

s17.jenkins执行远程脚本，kubernetes集群的node节点从镜像仓库拉取镜像，启动pod和应用容器，停止老版本容器；

s18.发送消息通知自动化测试平台测试环境部署完成。

进一步的，所述持续测试模块包括单元测试组件、接口测试组件、ui测试组件、性能测试组件以及测试报告分析模块；

测试报告分析模块用于获取单元测试组件、接口测试组件、ui测试组件以及性能测试组件对代码的测试结果，输出质量分析报告。

进一步的，所述持续测试模块的工作步骤包括：

s21.接收测试环境部署完成消息，启动自动化测试平台；

s22.根据测试策略调用自动化测试平台各类型测试组件进行并行测试，将测试结果根据产品名称、测试类型和测试版本输入对应的测试报告中；

s23.将带有标签的测试结果经过测试报告分析模块的数据统计分析器，形成多维度产品质量分析测试报告。

进一步的，所述持续测试模块的工作步骤包括：

所述s23.将带有标签的测试结果经过测试报告分析模块的数据统计分析器，形成多维度产品质量分析测试报告，包括

同一产品同类型的测试结果进行迭代测试的纵向分析；

同一产品不同类型测试结果进行横向分析；

不同产品间的差异程度分析。

进一步的，所述持续测试模块的工作步骤还包括：

s24.通知jenknis将测试通过的镜像推送到私服docker-registry，并标记为release版本；测试失败发送邮件通知并退出该版本测试。

进一步的，所述持续交付模块工作步骤包括：

s31.通过远程脚本触发jenknis，拉取最新release版本镜像；

s32.部署线上环境；

进一步的，所述持续交付模块工作步骤还包括：

s33.调用验收测试组件测试，若测试未通过，通过还原脚本，快速回滚到上一版本，并发出通知。

本发明的有益效果如下：

1.解决测试环境需要测试人员按照文档全手工命令行部署，流程复杂易出错，上线部署流程不透明且不易控制的问题；

2.低成本创建环境，复现问题，标准化环境，一键搭建，避免多应用干扰；

3.支持多类型的自助测试；

4.多类型多版本测试并行进行，提高测试效率；

5.解决测试环境不稳定问题，可以不间断的进行测试；

6.配置、代码变更、版本管理、测试，交付过程自动化；

7.测试结果自主分析，输出多维度质量分析报告，指导后续产品质量改进。

附图说明

为了更清楚地说明本发明具体实施方式或现有技术中的技术方案，下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍。在所有附图中，类似的元件或部分一般由类似的附图标记标识。附图中，各元件或部分并不一定按照实际的比例绘制。

图1为本发明持续集成持续交付的验收系统一个具体实施例的逻辑框图；

图2为图1中所示持续集成模块一个具体实施例中的工作流程图；

图3为图1中所示持续测试模块一个具体实施例中的工作流程图。

具体实施方式

下面将结合附图对本发明技术方案的实施例进行详细的描述。以下实施例仅用于更加清楚地说明本发明的技术方案，因此只作为示例，而不能以此来限制本发明的保护范围。

需要注意的是，除非另有说明，本申请使用的技术术语或者科学术语应当为本发明所属领域技术人员所理解的通常意义。

首先为对本发明中涉及的技术术语进行解释：

如图1所示，一种持续集成持续交付的验收系统，包括持续集成部署模块和持续测试模块以及持续交付单元；其中

持续集成部署模块：用于接收开发机开发代码到svn，触发jenkins构建，扫描该代码并将代码打成docker镜像，推送到私服docker-registry，以供kubernetes-master在k8s-master上执行rc和service的创建，进而创建pod，从私服拉取镜像，根据不同的tag名称部署不同的环境；

持续测试模块：用于根据测试策略调用不同的测试类型组件，并行测试，收集测试结果，形成测试报告；并将测试通过的版本推送到私服docker-registry，并标记为release版本；

持续交付单元：用于拉取release版本的镜像部署到线上环境。

本发明通过上述持续集成持续交付验收系统框架，实现测试结果自主分析，输出多维度质量分析报告，以指导后续产品质量改进；并具备多类型自助式测试功能，实现配置、代码变更、版本管理、测试，交付过程自动化。

其中所述持续集成部署模块由svn(subversion的缩写，开放源代码的版本控制系统)、jenkins(开源的、可持续集成的、基于web界面的平台)、kubernetes(开源的、用于管理云平台中多个主机上的容器化的应用，提供应用部署、规划、更新、维护的机制)、docker-registry(用于存储和分发docker镜像的registry服务器)仓库组成；其中jenkins的持续集成环境采用集群化，master-slave(主从架构的分布式)运行模式，jenkins的master为jenkins系统的控制节点，slave节点负责具体的项目编译测试等工作。jenkins集成kubernetes以及docker插件，配置pipeline构建。

如图2所示的，该模块的工作步骤包括：

s11.开发人员在svn上打了一个tag(标签)，每个tag根据策略生成一个版本号；

s12.svn代码仓库对commit操作(把事务所做的修改保存到数据库)配置钩子webhook，svn通过webhook，通知jenkins更新；

s13.jenkins更新本地代码，启动代码扫描工具，根据代码规范对代码进行扫描，代码检测通过后进行s14.操作，否则发送邮件代码检测失败并退出；

s14.jenkins接收到构建任务后，从svn拉取最新源码，进行编译打包；

s15.根据dockerfile文件生成镜像，push镜像到镜像仓库；

s16.jenkins调用kubernetes集群的master节点，更新pod的模板yaml文件，调用kubectl命令进行发布操作；

s17.jenkins执行远程脚本，kubernetes集群的node节点从镜像仓库拉取镜像，启动pod和应用容器，停止老版本容器；

s18.发送消息通知自动化测试平台测试环境部署完成。

本发明基于上述步骤，解决测试环境需要测试人员按照文档全手工命令行部署，流程复杂易出错，上线部署流程不透明且不易控制的问题；并且本发明低成本创建环境，系统在测试工作中能够复现问题，标准化环境，一键搭建，避免多应用干扰。

所述持续测试模块由单元测试组件、接口测试组件、ui测试组件、性能测试组件以及测试报告分析模块组成，

单元测试组件是对代码中的最小单元进行测试和验证，通俗来讲就是代码中的一个函数或一个类；

接口测试组件主要借助于单元测试组件，通过模拟上层应用或者系统上层调用接口的应用场景，是对系统接口功能进行测试的一种手段；属于功能测试的一种。接口测试主要通过分析接口定义以及模拟接口调用的业务应用场景来进行测试用例的设计，从而达到对被测试系统功能进行测试的目的；接口测试的重点是要检查数据的交换、传递和控制管理过程，以及系统间的相互逻辑依赖关系等；

ui测试组件用于用户界面测试，即测试用户界面的风格是否满足客户要求，文字是否正确，页面是否美观，文字，图片组合是否完美，操作是否友好等等；ui测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能，确保用户界面符合公司或行业的标准；

性能测试组件用于获得系统在预设特定条件下(特定的负载条件下)的性能指标数据；

所述测试报告分析模块包括数据统计分析器，用于根据不同类型的测试结果输出多维度质量分析报告。

本发明持续测试模块支持多类型的自助测试、以及多类型多版本测试并行进行，提高测试效率；具体的，如图3所示的，持续测试模块工作步骤包括：

s21.接收测试环境部署完成消息，启动自动化测试平台；

s22.根据测试策略调用自动化测试平台各类型测试组件进行并行测试，将测试结果根据产品名称、测试类型、测试版本输入对应的测试报告中。

s23.将带有标签的测试结果经过数据统计分析器，形成多维度产品质量分析测试报告。

①同一产品同类型的测试结果进行迭代测试的纵向分析。

②同一产品不同类型测试结果进行横向分析。

③不同产品间的差异程度分析。

s24.通知jenknis将测试通过的镜像推送到私服docker-registry，并标记为release版本。测试失败邮件通知相关人员并退出该版本测试。

本发明在测试过程中，能够实现测试结果自主分析，输出多维度质量分析报告，以指导后续产品质量改进。

所述持续交付模块包括验收测试组件；验收测试组件用于部署代码之前的最后一个测试操作；目的是确保代码准备就绪，并且可以让最终用户将其用于执行代码的既定功能和任务；表明系统能够像预定要求那样工作。

所述持续交付模块工作步骤包括：

s31.通过远程脚本触发jenknis，拉取最新release版本镜像。

s32.部署线上环境。

s33.调用验收测试组件测试，若测试未通过，通过还原脚本，快速回滚到上一版本，并通知相关人员。

通过上述实施例中各模块的工作步骤，实现配置、代码变更、版本管理、测试，交付过程自动化；解决传统技术中测试环境不稳定问题，本发明可以不间断的进行测试，测试效率高。

通过上述实施例的说明，本发明系统能够：

1.解决测试环境需要测试人员按照文档全手工命令行部署，流程复杂易出错，上线部署流程不透明且不易控制的问题；

2.低成本创建环境，复现问题，标准化环境，一键搭建，避免多应用干扰；

3.支持多类型的自助测试；

4.多类型多版本测试并行进行，提高测试效率；

5.解决测试环境不稳定问题，可以不间断的进行测试；

6.配置、代码变更、版本管理、测试，交付过程自动化；

7.测试结果自主分析，输出多维度质量分析报告，指导后续产品质量改进。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围，其均应涵盖在本发明的权利要求和说明书的范围当中。