一种自动化软件系统质量检查和快速迭代方法与流程

文档序号:17536696发布日期:2019-04-29 14:04阅读:475来源:国知局
一种自动化软件系统质量检查和快速迭代方法与流程

本发明专利属于软件开发与测试领域,面向复杂软件系统研制质量管理和效率需要,提供了一种自动化软件质量检测和快速迭代方法,支持软件的协同开发、代码质量管理、持续集成与测试。



背景技术:

随着软件设计技术的更新,软件或系统规模的扩大,软件产品复杂度不断提高,传统“模块开发-集成产品”的研发模式导致很多问题集中暴露在产品集成或发布阶段;与此同时,复杂软件系统在开发集成、测试以及产品迭代更新等方面越来越困难,耗时长且代价较高,并且难以保证产品质量和交付周期。持续集成是软件开发的一个重要实践[1,2]。持续集成是一种敏捷的开发方式[3],持续集成的引入,降低了软件开发的风险,提高软件开发效率,提高代码质量,使项目管理人员更好地了解项目的开发进度。每次集成过程包括编译、构建、部署、测试、发布等多个过程,每一个过程都可以进行优化和改进。

张兆晨,罗铁坚[4]搭建了一个基于docker容器的持续集成的构建系统,将持续集成环境容器化,可以大大提升软件开发效率。张高毓,张建强[5]提出一种提升软件产品服务质量的自动构建系统,实现软件产品的自动打包,并保证安装程序的正确性,可以为用户提供更高质量的安装服务。赵霞[6]提出一种软件自动化测试方法,即基于脚本式的测试流程完成不同对象的测试,以提高软件自动化测试的成功率。周颖,欧中红[7]等人提出一种持续集成自动部署方案,引入依赖管理工具ivy和制品管理工具artifactory,通过设计相应的脚本,来获取正确版本的制品组成部署安装包。

然而,上述方法存在一定的缺点:(1)自动构建系统缺乏代码质量的要求,没有进行关键的质量评审,在后期部署使用中可能出现问题;(2)测试方法不够自动化,且测试反馈日志不够具体,测试完毕之后的修改不够快速灵活,不能持续跟踪;(3)没有很好地使用持续集成框架和自定义扩展应用,只是简单地使用一些工具,没有能够考虑到框架自身应有的高可扩展性和可维护性。



技术实现要素:

本发明的目的是提供一种自动化软件系统质量检查和快速迭代方法,解决当前复杂系统软件在开发、测试、发布等过程中流程不连续、测试时间长、软件迭代慢等问题,减少软件或系统开发设计过程中的缺陷和问题,保证软件质量。

本发明采用的技术方案是:首先,采用基于脚本技术的流水线控制方法,设计软件持续集成用与交付过程模型,形成覆盖代码评审、编译构建、软件测试、发布部署等研制环节的产品自动化生产线,每个环节完成后自动触发下一个环节;其次,采用主从架构分布式调度构建机制,将过程模型中的环节通过任务编排顺序或并行方式执行,每个环节又可以划分为多个子过程,高效利用计算空间和时间;最后,通过灵活自适应的第三方工具扩展方法,构建持续集成和交付工具链,实现软件的质量检查和快速迭代。

一种自动化软件系统质量检查和快速迭代方法的具体步骤如下:

(1)开发人员增量开发结束后将代码提交至源码服务器gerrit的待审核分支;

(2)ci服务器jenkins通过触发检测插件gerrit-trigger检测到审核分支有代码变动时,自动触发静态分析任务sonar,对当前提交的代码进行质量分析,得到质量分析结果;

(3)根据预先设定的质量阀qdefine,并对比本次检测的结果qstatic,如果qstatic满足qdefine的判定条件则表示通过质量评审,此时通过sonar-gerrit插件实现自动评审,将本次提交自动合并至主干,并触发下一步任务;否则,中止后续步骤,并将结果反馈给开发人员;

(4)根据项目的开发语言,选择不同的单元测试框架junit或cppunit,调度分布式构建节点,执行单元测试和在线构建任务,依据单元测试质量utq及构建是否成功决定是否进入步骤(5),否则中止后续步骤,并将结果反馈给开发人员;

(5)将构建成功的产物进行归档存入制品库,自动执行部署任务,调度分布式分布节点,根据项目类型通过部署工具ssh或ftp将其部署至目标测试环境或生产环境中,然后自动触发步骤(6);

(6)选择不同的测试框架完成自动化软件测试,并将测试结果发送给相关人员;

(7)自动化测试通过后,将本次提交合并至发布分支,进行产品发布。

进一步的,所述静态分析包括编码风格、潜在的bug或漏洞。

进一步的,所述单元测试质量utq的计算方法为:utq=0.80*cov+0.20*uts,其中cov为代码覆盖率,uts为单元测试成功密度。

进一步的,调度分布式构建采用主/从架构来管理,所述节点包括主节点和从节点,所述主节点处理调度构建作业,把构建分发到从节点进行实际执行,监视从节点,并且记录和发布构建产物,同时可进行多线程触发调度运行;所述从节点通过主节点进行配置,以javaweb、ssh通道、控制台方式连接控制从节点,使从节点加入主节点的资源调度列表中。

进一步的,所述从节点通过在一台服务器上创建多个docker容器进行创建,所述从节点包括执行特定任务的从节点、在特定环境或系统上运行的从节点和自动选择调度的从节点。

进一步的,所述的部署工具包括ssh或ftp。

进一步的,实现权利要求1所述的自动化软件系统质量检查和快速迭代方法所涉及到的第三方工具包括代码管理与评审工具、静态分析工具、单元测试工具、构建工具、容器工具、动态测试工具和打包发布工具。

本发明的有益效果是:1)减少软件开发人员、配置管理人员、测试人员等角色的人工操作,提高软件研发的自动化水平;2)建立了软件系统自动化代码评审方法,降低了人工评审的复杂度;3)建立了多种语言的自动测试框架,自动化完成代码的单元测试、集成测试、性能测试等,减少了人工参与成本,节省了人力资源;4)建立了软件系统研发各阶段的持续反馈机制,出现问题,及时反馈,实现工程化的软件质量控制。

附图说明

图1是自动化系统软件质量测试和快速迭代的流程示意图;

图2是持续反馈策略图;

图3是代码自动评审策略图;

图4是自动部署结构图;

图5是产品分支策略图;

图6是第三方工具扩展机制图。

具体实施方式

下面结合具体实施例来进一步描述本发明,但实施例仅是范例性的,并不对本发明的范围构成任何限制。本领域技术人员应该理解的是,在不偏离本发明的精神和范围下可以对本发明技术方案的细节和形式进行修改或替换,但这些修改和替换均落入本发明的保护范围内。

实施例1

本发明提供了一种自动化软件质量检查和快速迭代方法,基于流水线控制的持续交付自动化过程模型和统一的持续集成框架,具体工具选型如下:

代码管理与评审工具:gerrit;

静态分析工具:sonar;

单元测试工具:junit、cppunit;

构建工具:maven、msbuild;

容器工具:docker、tomcat;

动态测试工具:jmeter、grpof;

打包发布工具:maven、nsis。

利用上述工具形成持续集成研发流水线,自动化开发、质量检查和快速迭代的运作步骤如下:

(1)开发人员增量开发结束后将代码提交至源码服务器(gerrit)的待审核分支;

(2)ci服务器(jenkins)通过触发检测插件(gerrit-trigger)检测到审核分支有代码变动时,自动触发静态分析任务(sonar),对当前提交的代码进行质量分析,得到质量分析结果;

(3)根据预先设定的质量阀qdefine,并对比本次检测的结果qstatic,如果qstatic满足qdefine的判定条件则表示通过质量评审,此时通过sonar-gerrit插件实现自动评审,将本次提交自动合并至主干,并触发下一步任务;否则,中止后续步骤,并将结果反馈给开发人员;

(4)根据项目的开发语言,选择不同的单元测试框架(junit、cppunit等),调度分布式构建节点,执行单元测试和在线构建任务,依据单元测试质量utq及构建是否成功决定是否进入步骤(5),否则中止后续步骤,并将结果反馈给开发人员;

(5)将构建成功的产物进行归档存入制品库,自动执行部署任务,调度分布式分布节点,根据项目类型通过部署工具ssh或ftp将其部署至目标测试环境或生产环境中,然后自动触发步骤(6);

(6)选择不同的测试框架完成自动化软件测试,并将测试结果发送给相关人员;

(7)自动化测试通过后,将本次提交合并至发布分支,进行产品发布。

实施例2

下面详细说明本发明的技术方案所依据的科学原理。

1、基于流水线控制的持续交付自动化过程模型

流水线持续交付模型基于持续集成框架,采用脚本驱动结合相关工具,构建交付流水线(pipeline),将软件研发过程分解成若干个阶段(stage),前一个stage为下一个stage创造执行条件,每一个stage可以与其他stage同时进行,并且每个stage可以划分多个子过程(step),子过程可以顺序或并行执行。从而实现空间上顺序依次进行,时间上重叠并行,保证研发的高效性。其中stage涉及自动化评审、自动化构建、自动化测试、自动化部署等过程。

整个交付流水线的脚本结构如下:

pipeline{

……

stages{

stage('代码签出'){//定义"代码签出"stage

steps{

//执行和"代码签出"stage相关的step

}

}

stage('自动评审'){//定义"自动评审"stage

steps{

//执行和"自动评审"stage相关的step--------------①

}

}

stage('自动构建'){//定义"自动构建"stage

steps{

//执行和"自动构建"stage相关的step--------------②

}

}

stage('自动部署'){//定义"发布生产"stage

steps{

//执行和"发布生产"stage相关的step--------------③

}

}

……

stage('发布生产'){//定义"发布生产"stage

steps{

//执行和"发布生产"stage相关的step--------------④

}

}

}

}

①stage('自动评审')

自动评审用于检查开发者提交的代码是否满足质量要求,包括静态分析和代码审查。

静态分析是在不运行代码的情况下检测代码质量,包括编码风格、潜在的bug和漏洞等。基本原理是:当签出源代码之后,利用预设的触发器自动触发静态分析任务,系统调度分布式静态分析服务器节点进行代码质量检查,检查完成后上传质量检查报告,并将检查结果通过邮件反馈给开发人员,开发人员根据反馈结果修复问题后重新提交代码,直至代码满足质量要求。

质量判断是基于静态分析结果,与预先定义的质量阀进行比对,判断代码是否合格。其基本原理是:预先根据静态分析的bug、漏洞、坏味道等几个维度进行代码质量的度量标准,可设定一个或多个判定条件,例如:

新增bug数量/bug数量[>|<|=|≥|…]n

新增漏洞数量/漏洞数量[>|<|=|≥|…]n

新增问题数量/问题数量[>|<|=|≥|…]n

其中n为正整数,关系运算符包括>、<、=、≥、≤等,这些判定条件可以进行组合作为质量阀qdefine,并与静态分析的结果qstatic进行判断是否通过。如果通过质量判断则自动合并本次提交至主干,否则直接打回并邮件通知。

②stage('自动构建')

自动构建利用持续集成框架的监听机制,一旦仓库主分支有代码更新就自动完成单元测试和在线编译。

自动化单元测试使用测试用例自动生成工具生成初始测试用例代码,供开发人员;持续集成框架检测到有代码更新时,利用触发器自动触发测试任务,每次任务执行时,调用覆盖率扫描工具对测试代码进行自动扫描,生成覆盖率报告,并调用不同开发语言各自的单元测试框架对代码进行单元测试,生成测试报告;综合覆盖率和单元测试报告计算测试质量utq,具体如下:

utq=0.80*cov+0.20*uts,其中

cov=codecoverage(代码覆盖率)

uts=unittestssuccessdensity(单元测试成功密度)

根据预先设置的单元测试质量指标判断单元测试是否通过,决定是否进行下一步(step)的在线编译,并反馈结果给开发人员,重新修改并提交代码直至代码满足质量要求。

在线编译保证项目每天频繁地集成,每次集成可尽快发现系统中的错误,以最大限度减少最后集成阶段集中发现问题的风险。其基本原理是:单元测试完成后,触发器自动触发在线编译任务,通过负载均衡策略,自动从分布式构建节点中选择适当的节点,执行编译环境部署和源码编译构建;在线编译完成后通过邮件将检查结果反馈给开发人员;开发人员根据反馈结果完成问题修复,重新提交代码,直至代码满足质量要求。

③stage('自动部署')

发布部署在编译构建成功后,将满足质量要求的代码及相应的依赖项打包部署至目标机器中,完成软件的持续部署。其基本原理是:利用预设的触发器监测仓库一旦有稳定代码版本,则自动触发发布部署任务,系统调用分布式构建执行并完成发布部署,将软件包传输至产品库或部署服务器,并通过邮件将检查结果反馈给开发人员。

④stage('发布生产')

自动化测试完成后,通过测试的版本进行发布,将其传到生产环境中,完成持续交付环节。其基本原理是:自动化测试结束后,通过测试的版本自动触发发布生产任务,将通过测试的稳定版本提交至发布分支,执行产品发布任务,之后利用自动部署工具将其部署至生产系统环境中。

2、主从架构分布式调度构建原理

分布式构建通常用来吸收额外的负载,例如通过动态添加额外的机器应对构建作业中的高峰期,或者在特定的操作系统或环境运行专门的构建作业,或者是针对某些特定需求的项目而进行的构建作业。构建服务器的需要随着时间的推移会波动。例如在发布生产阶段前可能需要运行更多的构建作业,比如更多的冒烟测试、性能测试等测试环节可能会更加频繁。本方法采用“1+n”的主/从架构来管理分布式构建,可以在任意数量的从节点上批量执行不同的任务,且可以根据任务类型进行动态调度并快速构建,实现软件系统研发的快速迭代,具体描述如下:

(1)主节点:处理调度构建作业,把构建分发到从节点来进行实际执行,监视从节点,并且记录和发布构建产物。同时可以进行多线程触发调度运行,确保调度精确执行,不被堵塞;

(2)从节点:通过主节点进行配置,以javaweb、ssh通道、控制台等方式连接控制从节点,使从节点加入主节点的资源调度列表中。在本方法中采用在一台服务器上创建多个docker容器充当从节点,以节省服务器资源。将其分为三类:

执行特定任务的从节点;

在特定环境或系统上运行的从节点;

自动选择调度的从节点。

一旦从节点实例运行,它就通过tcp/ip连接主实例进行通信。根据操作系统和网络架构的不同,本方法可以灵活选择不同的节点进行构建,构建作业运行在从节点的方式及怎么被管理对于终端用户来说都是透明的,构建结果和构建产物最后总是会在主服务器上。

以下为对附图的详细解释:

图1为本发明提供的一种自动化系统软件质量测试和快速迭代方法的流程示意图。首先,开发人员提交代码至待审核分支,当监控服务器检测到该分支有代码变动时,触发静态分析任务,进行代码自动评审;在代码审查通过后,自动分支合并到主干并触发单元测试和在线编译任务;在单元测试和在线编译没有问题时,进行打包和部署,同时启动自动化系统软件测试;最后将通过的测试的软件产品进行发布。

图2为本发明的持续反馈策略图。将软件系统研发开发各阶段加入消息通知机制(邮件、即时消息等),当任何一个步骤或阶段发生问题或状态改变时,快速响应,及时触发并反馈结果,并将日志信息或分析报告等发送给相关人员。

图3为本发明的代码自动评审策略图。首先开发人员提交代码至待审核分支,自动触发静态检查,从源码仓库审核拉取本次提交代码进行静态分析,将静态分析的结果与预先设定的质量阀值(新增bug、新增漏洞等)进行对比,通过则进行下一步,不通过则返回。

图4为本发明的自动部署结构图。当软件系统在线构建结束后,自动触发任务,根据项目类型或开发语言,将生成的构件(exe、jar、war等)自动调度和部署至相关联的环境中,实现不同环境的自动化部署。

图5为本发明的产品分支策略图。本方法的分支策略采取主干加分支的管理方式。分支的目的是帮助团队进行并行开发,即同一时刻多个工作流同时进行而互不影响。每个分支代码合并至主干时都会进行一系列测试,其中测试和合并都是自动完成,最后将代码交付到发布分支或主干。

图6是本发明的第三方工具扩展机制图。持续集成和持续交付涉及众多第三方工具,基于统一的开放集成框架,通过配置相应工具的参数和脚本,串联研发各阶段,构建持续集成和交付工具链,使系统具备高可扩展性和伸缩性。整个持续交付自动化过程中可灵活自适应适配的第三方工具包括代码管理与评审工具、静态分析工具、单元测试工具、构建工具、容器工具、动态测试工具、打包发布工具等。

参考文献:

[1]chenggang,qianglingling.researchoncontinuousintegrationinsoftwaredevelopment[j].projectmanagementtechnology,2011,12(12):1.

[2]julianaclarke.theresearchandapplicationofcontinuousintegrationbasedonhudson[j].computersystems&applications,2010(12).

[3]swartoutp.continuousdeliveryanddevops–aquickstartguide[m].birmingham:packtpublishingltd,2014:3.

[4]张兆晨,罗铁坚.cci:一种基于容器化的持续集成系统[j].中国科学院大学学报,2018,35(04):569-575。

[5]张高毓,张建强.一种基于jenkins提升软件产品安装服务质量的自动构建系统[j].软件,2017,38(12):175-179。

[6]赵霞.一种软件自动化测试方法及装置[p].河南:cn106598874a,2017-04-26。

[7]周莹,欧中红,李俊.基于jenkins的持续集成自动部署研究[j].计算机与数字工程,2016,44(02):267-270。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1