CN109408382A - 一种持续集成方法和持续集成系统 - Google Patents

Abstract

本申请实施例提供了一种持续集成方法和持续集成系统，涉及自动化测试技术领域，该方法包括：持续集成系统获取待测软件的待测试代码和待测软件对应的操作系统信息，然后根据操作系统信息确定待测试代码的编译环境和测试环境，编译环境和测试环境与待测软件对应的操作系统匹配，最后在编译环境中对待测试代码进行编译和打包；在测试环境中对打包后的待测试代码进行测试。针对不同待测软件的待测试代码，可以同时在对应的编译环境和测试环境进行编译和测试，实现同时对不同的软件进行测试的目的，便于对接不同的开发部门的测试要求，实现了持续集成系统的产品化。

Description

一种持续集成方法和持续集成系统

技术领域

本发明涉及自动化测试技术领域，尤其涉及一种持续集成方法和持续集成系统。

背景技术

在软件开发过程中，采用的开发流程大多是先需求分析、然后设计和编码，最后再测试。在软件开发过程中，原本存在的问题没有在开发过程中及时处理，而是到最后集成测试的时候再去测试和处理，导致问题处理效率低。为了提高处理效率，现有技术中采用持续集成的方式进行软件开发，即开发人员经常集成他们的工作，每次集成都通过自动化的构建来验证，从而尽早地发现开发过程中的问题。然而现有技术中的持续集成系统都是针对单一软件开发设计，不适用于同时对多个软件进行持续集成和测试。

发明内容

由于现有的持续集成系统针对单一软件开发设计，不适用于同时对多个软件进行持续集成和测试的问题，本申请实施例提供了一种持续集成方法和持续集成系统。

第一方面，本申请实施例提供了一种持续集成方法，包括：

持续集成系统获取待测软件的待测试代码和所述待测软件对应的操作系统信息；

所述持续集成系统根据所述操作系统信息确定所述待测试代码的编译环境和测试环境，所述编译环境和所述测试环境与所述待测软件对应的操作系统匹配；

所述持续集成系统在所述编译环境中对所述待测试代码进行编译和打包；

所述持续集成系统在所述测试环境中对打包后的所述待测试代码进行测试。

由于持续集成系统预先设置不同的编译环境和测试环境，不同的编译环境和测试环境对应不同的操作系统，在获取待测软件的待测试代码时，根据待测软件对应的操作系统信息可以确定待测试代码的编译环境和测试环境，然后对待测软件的待测试代码进行编译和测试，故针对不同待测软件的待测试代码，可以同时在对应的编译环境和测试环境进行编译和测试，实现同时对不同的软件进行测试的目的，便于对接不同的开发部门的测试要求。

可选地，所述持续集成系统在所述编译环境中对所述待测试代码进行编译和打包之前，还包括：

所述持续集成系统确定所述待测试代码的编程语言；

所述持续集成系统根据所述待测试代码的编程语言确定对应的静态扫描工具；

所述持续集成系统采用所述静态扫描工具对所述待测试代码进行静态扫描。

由于在对待测试代码进行编译和打包之前，对待测试代码进行静态扫描，故能尽早发现待测试代码的编码错误，从而提高待测试代码的测试效率。由于预先设置多种静态扫描工具，故针对不同编程语言的待测试代码，可以选择对应的静态扫描工具，满足不同开发人员的需求，提高了持续集成系统的适用性。

可选地，所述持续集成系统在所述编译环境中对所述待测试代码进行编译和打包，包括：

所述持续集成系统确定所述待测试代码中的更新代码；

所述持续集成系统在所述编译环境中对所述更新代码进行编译，确定更新包；

所述持续集成系统下载并安装所述待测软件对应的公共依赖包，所述依赖包是由所述持续集成系统在本地编译生成的；

所述持续集成系统获取所述待测软件对应的需要重新打包的旧软件包；

所述持续集成系统对所述更新包、所述公共依赖包以及所述旧软件包进行打包。

由于持续集成系统在本地编译生成公共依赖包，在接收到待测试代码时，直接使用本地编译生成的公共依赖包，而不需要开发人编译生成，统一不同组件的编译环境，避免不同编译环境引起的系统不兼容，从而避免了公共依赖包多次编译导致的上线升级冲突。

可选地，所述持续集成系统在所述测试环境中对打包后的所述待测试代码进行测试，包括：

所述持续集成系统确定所述待测试代码的测试触发方式；

所述持续集成系统根据所述测试触发方式触发打包后的所述待测试代码在所述测试环境进行测试。

由于持续集成系统中预先设置多种不同的测试触发方式供开发人员选择，适用于不同开发人员的测试需求，给开发人员带来便利。

可选地，所述持续集成系统在所述测试环境中对打包后的所述待测试代码进行测试之后，还包括：

所述持续集成系统将测试通过的所述待测试代码发布到预发布环境；

所述持续集成系统在所述预发布环境中对所述待测试代码进行预发布测试。

由于对待测试代码进行测试后发布至预发布环境中进行预发布测试，故能提前发现待测软件与线上测试机器之间的兼容性、冲突问题，从而提高待测软件线上发布的成功率。

可选地，还包括：

所述持续集成系统生成编译报告和测试报告；

所述持续集成系统将所述编译报告和所述测试报告发送至开发人员。

第二方面，本申请实施例提供了一种持续集成系统，包括：

获取模块，用于获取待测软件的待测试代码和所述待测软件对应的操作系统信息；

处理模块，用于根据所述操作系统信息确定所述待测试代码的编译环境和测试环境，所述编译环境和所述测试环境与所述待测软件对应的操作系统匹配；

编译模块，用于在所述编译环境中对所述待测试代码进行编译和打包；

测试模块，用于在所述测试环境中对打包后的所述待测试代码进行测试。

可选地，还包括扫描模块；

所述扫描模块具体用于：

在所述编译环境中对所述待测试代码进行编译和打包之前，确定所述待测试代码的编程语言；

根据所述待测试代码的编程语言确定对应的静态扫描工具；

采用所述静态扫描工具对所述待测试代码进行静态扫描。

可选地，所述编译模块具体用于：

确定所述待测试代码中的更新代码；

在所述编译环境中对所述更新代码进行编译，确定更新包；

下载并安装所述待测软件对应的公共依赖包，所述依赖包是由所述持续集成系统在本地编译生成的；

获取所述待测软件对应的需要重新打包的旧软件包；

对所述更新包、所述公共依赖包以及所述旧软件包进行打包。

可选地，所述测试模块具体用于：

确定所述待测试代码的测试触发方式；

根据所述测试触发方式触发打包后的所述待测试代码在所述测试环境进行测试。

可选地，还包括预发布模块；

所述预发布模块具体用于：

在所述测试模块在所述测试环境中对打包后的所述待测试代码进行测试之后，将测试通过的所述待测试代码发布到预发布环境；

在所述预发布环境中对所述待测试代码进行预发布测试。

可选地，所述测试模块还用于：

生成编译报告和测试报告；

将所述编译报告和所述测试报告发送至开发人员。

第三方面，本申请实施例提供了一种自动化测试设备，包括至少一个处理单元以及至少一个存储单元，其中，所述存储单元存储有计算机程序，当所述程序被所述处理单元执行时，使得所述处理单元执行第一方面所述方法的步骤。

第四方面，本申请实施例提供了一种计算机可读存储介质，其存储有可由自动化测试设备执行的计算机程序，当所述程序在自动化测试设备上运行时，使得所述自动化测试设备执行第一方面所述方法的步骤。

本申请实施例中，由于持续集成系统预先设置不同的编译环境和测试环境，不同的编译环境和测试环境对应不同的操作系统，在获取待测软件的待测试代码时，根据待测软件对应的操作系统信息可以确定待测试代码的编译环境和测试环境，然后对待测软件的待测试代码进行编译和测试，故针对不同待测软件的待测试代码，可以在对应的编译环境和测试环境进行编译和测试，实现同时对不同的软件进行测试的目的，便于对接不同的开发部门的测试要求，实现了持续集成系统的产品化。持续集成系统中加入静态扫描功能，针对待测试代码的编程语言选择不同的静态扫描工具，实现对不同代码的静态扫描，便于提前发现待测试代码的编码错误，提高待测试代码的测试效率。持续集成系统中加入预发布测试，故能提前发现待测软件与线上测试机器之间的兼容性，从而提高待测软件线上发布的成功率。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简要介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的一种应用场景图；

图2为本申请实施例提供的一种持续集成方法的流程示意图；

图3为本申请实施例提供的一种静态扫描方法的流程示意图；

图4为本申请实施例提供的一种编译方法的流程示意图；

图5为本申请实施例提供的一种持续集成方法的流程示意图；

图6为本申请实施例提供的一种编译方法的流程示意图；

图7为本申请实施例提供的一种持续集成系统的结构示意图；

图8为本申请实施例提供的一种自动化测试设备的结构示意图。

具体实施方式

为了使本发明的目的、技术方案及有益效果更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

本申请实施例中的持续集成方法可以应用于如图1所示的应用场景，在该应用场景中包括持续集成系统101、开发人员终端102。持续集成系统101可以是基于jenkins的持续集成系统，持续集成系统101中包括版本控制系统(Subversion，简称SVN)1011、编译系统1012、提测机器1013、测试系统1014、持续集成平台1015。开发人员终端102为开发人员开发软件的电子涉笔，该电子设备可以是智能手机、平板电脑或便携式个人计算机等等。

开发人员终端102显示测试提交界面，开发人员可以在测试提交界面中提交待测软件的待测试代码，同时也可以提交待测软件对应的操作系统信息、编程语言信息、测试触发方式等配置信息。开发人员终端102将待测软件的待测试代码提交至版本控制系统1011。编译系统1012从版本控制系统1011中读取待测试代码，然后根据待测试代码的编程语言选择静态扫描工具，采用选择的静态扫描工具对待测试代码进行静态扫描。静态扫描成功后，根据配置信息中的操作系统信息确定待测试代码的编译环境。然后初始化编译环境，从版本控制系统1011中下载待测软件对应的依赖包，使用编译命令在待测试代码的编译环境中编译待测试代码，然后将编译后的待测试代码打包后上传至提测机器1013。提测机器1013根据配置信息中的测试触发方式触发测试系统1014对打包后的待测试代码进行测试。具体地，测试系统1014根据配置信息中待测软件的操作系统信息确定待测试代码的测试环境，然后初始化待测试代码的测试环境，下载测试用例对待测试代码进行测试。测试系统1014确定待测试代码测试通过后，将打包后的待测试代码发布至预发布环境进行预发布测试。另外，在持续集成平台1015在每天特定时间段内，比如每天0点至7点，自动从提测机器获取当天测试的每一个软件的最新版本的包以及最新版本前一个版本的包，然后触发在软件对应的测试环境中对上述两个包进行回归测试，生成测试报告以及统计报告，然后以邮件的形式将测试报告和统计报告发送至公司管理层，编译公司管理层了解软件产品的质量以及测试情况。

基于图1所示的应用场景图，本申请实施例提供了一种任持续集成方法的流程，该方法的流程可以由持续集成系统执行，如图2所示，包括以下步骤：

步骤S201，持续集成系统获取待测软件的待测试代码和待测软件对应的操作系统信息。

开发人员将待测试代码提交至持续集成系统中的版本控制系统(Subversion，简称SVN)或分布式版本控制系统(GIT)。

待测软件对应的操作系统信息指待测软件在使用时适用的操作系统。操作系统包括但不限于Windows操作系统、UNIX操作系统、Linux操作系统、iOS操作系统、Android操作系统。每一个软件在使用时，都依托对应的操作系统，为了避免软件在投入市场使用时，软件与操作系统不兼容，在开发软件时，需要在软件对应的操作系统中进行测试。

待测试代码可以是待测软件的所有代码，也可以是待测试软件的部分代码。

步骤S202，持续集成系统根据操作系统信息确定待测试代码的编译环境和测试环境。

持续集成系统根据需求设置不同的编译环境和测试环境。

待测试代码的编译环境与待测软件的操作系统匹配，示例性地，设定待测软件A对应的操作系统为Windows 7操作系统，则在持续集成系统中选择操作系统为Windows 7操作系统的编译机器B，将该编译机器B确定为待测软件A的编译环境。

待测试代码的测试环境与待测软件对应的操作系统匹配。示例性地，设定待测软件A对应的操作系统为Windows 7操作系统，则在持续集成系统中选择操作系统为Windows7操作系统的测试机器C，将该测试机器C确定为待测软件A的测试环境。

步骤S203，持续集成系统在编译环境中对待测试代码进行编译和打包。

步骤S204，持续集成系统在测试环境中对打包后的待测试代码进行测试。

示例性地，确定编译机器B确定为待测软件A的编译环境以及测试机器C确定为待测软件A的测试环境后，初始化编译机器B的编译环境，然后根据配置的编译目录，采用开发人员指定的编译命令在编译机器B中编译待测软件A的待测试代码，然后对编译后的待测试代码进行打包后上传至提测机器。测试机器C从提测机器中获取打包后的待测试代码，下载测试用例，然后采用测试用例对待测试代码进行测试。

由于持续集成系统预先设置不同的编译环境和测试环境，不同的编译环境和测试环境对应不同的操作系统，在获取待测软件的待测试代码时，根据待测软件对应的操作系统信息可以确定待测试代码的编译环境和测试环境，然后对待测软件的待测试代码进行编译和测试，故针对不同待测软件的待测试代码，可以同时在对应的编译环境和测试环境进行编译和测试，实现同时对不同的软件进行测试的目的，便于对接不同的开发部门的测试要求，实现了持续集成系统的产品化。

在上述步骤S203之前，持续集成系统对待测试代码进行静态扫描，具体包括以下步骤，如图3所示：

步骤S301，持续集成系统确定待测试代码的编程语言。

待测试代码的编程语言包括但不限于：C#、Basic、C语言、C++、JAVA、python。持续集成系统可以根据开发人员提交的配置信息确定待测试代码的编程语言，也可以在获取待测试代码后，根据待测试代码的性质确定编程语言。

步骤S302，持续集成系统根据待测试代码的编程语言确定对应的静态扫描工具。

具体地，不同的编程语言对应不同的静态扫描工具，示例性地，C语言可以采用Tscancode、cppcheck等静态扫描工具，python可以采用pylint等静态扫描工具，JAVA以采用PMD等静态扫描工具。

持续集成系统可以根据开发人员提交的配置信息确定静态扫描工具，也可以根据待测试代码的编程语言分配静态扫描工具。

步骤S303，持续集成系统采用静态扫描工具对待测试代码进行静态扫描。

静态扫描结束后，可以生成对应的静态扫描报告，然后以邮件的形式将静态扫描报告发送至开发人员、测试人员等。

由于在对待测试代码进行编译和打包之前，对待测试代码进行静态扫描，故能尽早发现待测试代码的编码错误，从而提高待测试代码的测试效率。由于预先设置多种静态扫描工具，故针对不同编程语言的待测试代码，可以选择对应的静态扫描工具，满足不用开发人员的需求，提高了持续集成系统的适用性。

可选地，在上述步骤S203中，持续集成系统在编译环境中对待测试代码进行编译和打包，具体包括以下步骤，如图4所示：

步骤S401，持续集成系统确定待测试代码中的更新代码。

具体地，开发人员将待测试代码提交至SVN中后，触发编译系统获取待测试代码在SVN中存储地址，然后根据存储地址从SVN中获取代码更新列表，然后判断代码更新列表中各个文件的代码是否有更新，将有更新的文件中代码确定为待测代码中的更新代码。然后将更新的文件读取至待测软件在编译环境中的配置目录中，配置目录中包括待测软件上一个版本对应的软件包。然后根据配置目录对更新的文件中的更新代码进行静态扫描。

步骤S402，持续集成系统在编译环境中对更新代码进行编译，确定更新包。

当更新代码静态扫描通过后，初始化编译环境，然后根据配置目录，在编译环境中采用编译指令对更新代码进行编译，确定更新包，更新包可以是RPM包。编译结束后，可以生成对应的编译报告，然后以邮件的形式将编译报告发送至开发人员、测试人员等。

步骤S403，持续集成系统下载并安装待测软件对应的公共依赖包，依赖包是由持续集成系统在本地编译生成的。

公共依赖包为开发人员都可以使用的包，公共依赖包在持续集成系统中统一编译，故开发人员不用在本地编译公共依赖包，避免公共依赖包在不同的操作系统上多次编译，引发上线升级冲突。

步骤S404，持续集成系统获取待测软件对应的需要重新打包的旧软件包。

步骤S405，持续集成系统对更新包、公共依赖包以及旧软件包进行打包。

配置目录中不仅包括待测软件的更新包，还包括待测软件上一个版本的旧软件包，由于旧软件包对应的代码并没有修改，所以可以不需要到重新编译，但是在对待测软件的待测试代码进行测试时，不仅需要测试更新包的功能，同时还需要测试更新包是否对旧软件包的功能造成影响。因此需要将更新包、公共依赖包以及旧软件包进行打包后测试，打包后的格式可以使zip包、rar包等。

示例性地，待测软件A的发送消息的功能包括单独发送消息以及群发消息，在待测软件A的旧版本包中包括两个RPM包1，单独发送消息对应RPM包1，群发消息对应RPM包2。待测软件A的旧版本中，群发消息没有问题，而单独发送消息有问题，故开发人员修改了单独发送消息的代码，然后将单独发送消息的代码和未修改的群发消息的代码作为待测试代码提交至SVN，持续集成系统从SVN中获取单独发送消息的代码并进行编译，得到更新的RPM包1。持续集成系统下载待测软件A的公共依赖包后，将公共依赖包、更新的RPM包1以及RPM包2进行打包，确定待测软件A的新版本包。

由于持续集成系统在本地编译生成公共依赖包，在接收到待测试代码时，直接使用本地编译生成的公共依赖包，而不需要开发人编译生成，从而避免了公共依赖包多次编译导致的上线升级冲突。其次，在获取待测试代码时，只对有修改的代码文件进行编译，而不需要对所有的待测试代码都进行编译，从而提高了编译效率。

可选地，在上述步骤S204中，为了适用不同开发人员以及开发项目的需求，持续集成系统预先设置多种可供开发人员选择的测试触发方式。测试触发方式包括但不限于立即触发、定时触发、延时触发、手动触发。具体地，持续集成系统将待测试代码打包后，确定待测试代码的测试触发方式，然后根据测试触发方式触发打包后的待测试代码在测试环境进行测试。可选地，持续集成平台可以根据开发人员提交配置信息确定开发人员选择的测试触发方式，然后根据开发人员选择的测试触发方式触发打包后的待测试代码在测试环境进行测试。可选地，在对打包后的待测试代码进行测试之前，先触发测试启动配置测试环境，具体包括获取打包后的待测试代码、下载测试用例、更新测试用例的公共操作等。然后根据测试触发方式在测试环境中对打包后的待测试代码进行测试。可选地，测试包括回归测试、单位测试、功能测试等等。可选地，测试结束后，生成测试报告，然后将测试报告已邮件的形式发送至开发人员或者测试人员等等。由于持续集成系统中预先设置多种不同的测试触发方式供开发人员选择，适用于不同开发人员的测试需求，给开发人员带来便利。

可选地，在上述步骤S203之后，为了方便公司管理层统计软件产品质量以及软件中出现的bug的类型，持续集成系统中设置持续集成平台，该持续集成平台在每天的设定时间段从提测机器中获取当天测试的每一个待测软件的最新版本包和上一个版本包进行回归测试。具体地，持续集成平台在每天0点至7点自动触发持续集成。编译系统对待测试代码进行编译和打包后上传至提测机器，提测机器将打包后的待测试代码在提测机器中的存储地址发送至持续集成平台。持续集成平台在每天0点根据存储地址从提测机器中获取前一天每一个待测软件的最新版本包和上一个版本包。然后将每一个待测试软件的最新版本包和上一个版本包发送至该待测软件对应的测试环境，在对应的测试环境中触发回归测试。持续集成平台在每天7点根据测试结果生成测试报告和统计报告，然后以邮件的形式将测试报告和统计报告发送至公司管理层，从而便于公司管理层及时获知软件产品的质量以及软件产品中出现的bug。

可选地，在上述步骤S204之后，为了避免因为测试环境和线上环境的差异性导致待测软件上线失败的问题，持续集成系统将测试通过的待测试代码发布到预发布环境，然后在预发布环境中对待测试代码进行预发布测试。具体地，预发布环境为模拟的线上环境、正式生产环境。将测试通过的待测软件测的新版本包发布到预发布环境中，然后在预发布环境中进行升级、回退、卸载等操作，验证组件间的兼容，及时发现组件间不合理的依赖关系。预发布测试通过后，将待测软件的最新版本包提测到测试组进行线上发布。预发布测试结束后，生成预发布测试报告，然后将预发布测试报告以邮件的形式发送至开发人员、测试人员等。由于对待测试代码进行测试后发布至预发布环境中进行预发布测试，故能提前发现待测软件与线上测试机器之间的兼容性，从而提高待测软件线上发布的成功率。

为了更好的解释本申请实施例，下面结合具体的实施场景描述本申请实施例提供的一种持续集成方法，该方法的流程可以由基于Jenkins的持续集成系统执行，如图5所示，包括以下步骤：

步骤S501，开发人员提交待测软件的待测试代码至SVN。

步骤S502，编译系统从SVN获取待测试代码。

步骤S503，编译系统根据配置信息确定待测试代码的编译环境。

配置信息包括操作系统信息、测试触发方式、编译目录、静态扫描路径、编程语言、打包方式、公共依赖包等。

步骤S504，在编译环境对待测试代码进行编译和打包，确定新版本包。

步骤S505，生成编译报告并发送邮件。

步骤S506，编译系统将新版本包发送至提测机器。

步骤S507，测试系统根据配置信息确定待测试代码的测试环境。

步骤S508，测试系统根据测试触发方式触发下载测试用例、将新版本包上传测试环境。

步骤S509，在测试环境触发回归测试。

步骤S510，测试系统将测试通过的新版本包进行预发布测试。

步骤S511，生成测试报告并发送邮件。

步骤S512，持续集成平台每天零点触发持续集成。

步骤S513，从提测机器中获取前一天每一个待测软件的最新版本包和前一个版本包。

步骤S514，将每一个待测软件的最新版本包和前一个版本包上传至对应的测试环境。

步骤S515，在测试环境触发回归测试。

步骤S516，每天七点结束持续集成，生成测试报告和统计报告并发送邮件。

具体实施中，上述步骤S504中，在编译环境对待测试代码进行编译和打包，确定新版本包，具体包括以下步骤，如图6所示：

步骤S601，编译系统获取待测试代码在SVN中存储地址。

步骤S602，根据存储地址从SVN中获取待测试代码的文件更新列表。

步骤S603，判断文件更新列表中各个文件的代码是否有更新，若是，则执行步骤S604，否则执行步骤S505。

步骤S604，确定更新文件对应的配置目录。

步骤S605，根据配置目录对更新文件中的代码进行静态扫描。

步骤S606，判断静态扫描是否有成功，若是，则执行步骤S607，否则执行步骤S505。

步骤S607，初始化编译环境，从SVN中下载待测试代码对应的公共依赖包。

步骤S608，在编译环境中使用编译指令对更新文件进行编译，确定rpm包。

步骤S609，获取待测软件对应的需要重新打包的旧软件包。

步骤S610，执行打包得到新版本包。

基于相同的技术构思，本申请实施例提供了一种持续集成系统，如图7所示，该持续集成系统700包括：

获取模块701，用于获取待测软件的待测试代码和所述待测软件对应的操作系统信息；

处理模块702，用于根据所述操作系统信息确定所述待测试代码的编译环境和测试环境，所述编译环境和所述测试环境与所述待测软件对应的操作系统匹配；

编译模块703，用于在所述编译环境中对所述待测试代码进行编译和打包；

测试模块704，用于在所述测试环境中对打包后的所述待测试代码进行测试。

可选地，还包括扫描模块705；

所述扫描模块705具体用于：

在所述编译环境中对所述待测试代码进行编译和打包之前，确定所述待测试代码的编程语言；

根据所述待测试代码的编程语言确定对应的静态扫描工具；

采用所述静态扫描工具对所述待测试代码进行静态扫描。

可选地，所述编译模块703具体用于：

确定所述待测试代码中的更新代码；

在所述编译环境中对所述更新代码进行编译，确定更新包；

下载并安装所述待测软件对应的公共依赖包，所述依赖包是由所述持续集成系统在本地编译生成的；

获取所述待测软件对应的需要重新打包的旧软件包；

对所述更新包、所述公共依赖包以及所述旧软件包进行打包。

可选地，所述测试模块704具体用于：

确定所述待测试代码的测试触发方式；

根据所述测试触发方式触发打包后的所述待测试代码在所述测试环境进行测试。

可选地，还包括预发布模块706；

所述预发布模块706具体用于：

在所述测试模块704在所述测试环境中对打包后的所述待测试代码进行测试之后，将测试通过的所述待测试代码发布到预发布环境；

在所述预发布环境中对所述待测试代码进行预发布测试。

可选地，所述测试模块704还用于：

生成编译报告和测试报告；

将所述编译报告和所述测试报告发送至开发人员。

基于相同的技术构思，本申请实施例提供了一种自动化测试设备，如图8所示，包括至少一个处理器801，以及与至少一个处理器连接的存储器802，本申请实施例中不限定处理器1801与存储器802之间的具体连接介质，图8中处理器801和存储器802之间通过总线连接为例。总线可以分为地址总线、数据总线、控制总线等。

在本申请实施例中，存储器802存储有可被至少一个处理器801执行的指令，至少一个处理器801通过执行存储器802存储的指令，可以执行前述的持续集成方法中所包括的步骤。

其中，处理器801是自动化测试设备的控制中心，可以利用各种接口和线路连接自动化测试设备的各个部分，通过运行或执行存储在存储器802内的指令以及调用存储在存储器802内的数据，从而持续集成。可选的，处理器801可包括一个或多个处理单元，处理器801可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器801中。在一些实施例中，处理器801和存储器802可以在同一芯片上实现，在一些实施例中，它们也可以在独立的芯片上分别实现。

处理器801可以是通用处理器，例如中央处理器(CPU)、数字信号处理器、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，可以实现或者执行本申请实施例中公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

存储器802作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块。存储器802可以包括至少一种类型的存储介质，例如可以包括闪存、硬盘、多媒体卡、卡型存储器、随机访问存储器(Random AccessMemory，RAM)、静态随机访问存储器(Static Random Access Memory，SRAM)、可编程只读存储器(Programmable Read Only Memory，PROM)、只读存储器(Read Only Memory，ROM)、带电可擦除可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，EEPROM)、磁性存储器、磁盘、光盘等等。存储器802是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。本申请实施例中的存储器802还可以是电路或者其它任意能够实现存储功能的装置，用于存储程序指令和/或数据。

基于相同的技术构思，本申请实施例还提供一种计算机可读存储介质，该可读存储介质存储有计算机指令，当该计算机指令在自动化测试设备上运行时，使得自动化测试设备执行如前述的持续集成的方法的步骤。

本领域内的技术人员应明白，本发明的实施例可提供为方法、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (14)

1.一种持续集成方法，其特征在于，包括：

持续集成系统获取待测软件的待测试代码和所述待测软件对应的操作系统信息；

所述持续集成系统根据所述操作系统信息确定所述待测试代码的编译环境和测试环境，所述编译环境和所述测试环境与所述待测软件对应的操作系统匹配；

所述持续集成系统在所述编译环境中对所述待测试代码进行编译和打包；

所述持续集成系统在所述测试环境中对打包后的所述待测试代码进行测试。

2.如权利要求1所述的方法，其特征在于，所述持续集成系统在所述编译环境中对所述待测试代码进行编译和打包之前，还包括：

所述持续集成系统确定所述待测试代码的编程语言；

所述持续集成系统根据所述待测试代码的编程语言确定对应的静态扫描工具；

所述持续集成系统采用所述静态扫描工具对所述待测试代码进行静态扫描。

3.如权利要求1所述的方法，其特征在于，所述持续集成系统在所述编译环境中对所述待测试代码进行编译和打包，包括：

所述持续集成系统确定所述待测试代码中的更新代码；

所述持续集成系统在所述编译环境中对所述更新代码进行编译，确定更新包；

所述持续集成系统下载并安装所述待测软件对应的公共依赖包，所述依赖包是由所述持续集成系统在本地编译生成的；

所述持续集成系统获取所述待测软件对应的需要重新打包的旧软件包；

所述持续集成系统对所述更新包、所述公共依赖包以及所述旧软件包进行打包。

4.如权利要求1所述的方法，其特征在于，所述持续集成系统在所述测试环境中对打包后的所述待测试代码进行测试，包括：

所述持续集成系统确定所述待测试代码的测试触发方式；

所述持续集成系统根据所述测试触发方式触发打包后的所述待测试代码在所述测试环境进行测试。

5.如权利要求1所述的方法，其特征在于，所述持续集成系统在所述测试环境中对打包后的所述待测试代码进行测试之后，还包括:

所述持续集成系统将测试通过的所述待测试代码发布到预发布环境；

所述持续集成系统在所述预发布环境中对所述待测试代码进行预发布测试。

6.如权利要求1至5任一所述的方法，其特征在于，还包括：

所述持续集成系统生成编译报告和测试报告；

所述持续集成系统将所述编译报告和所述测试报告发送至开发人员。

7.一种持续集成系统，其特征在于，包括：

获取模块，用于获取待测软件的待测试代码和所述待测软件对应的操作系统信息；

处理模块，用于根据所述操作系统信息确定所述待测试代码的编译环境和测试环境，所述编译环境和所述测试环境与所述待测软件对应的操作系统匹配；

编译模块，用于在所述编译环境中对所述待测试代码进行编译和打包；

测试模块，用于在所述测试环境中对打包后的所述待测试代码进行测试。

8.如权利要求7所述的持续集成系统，其特征在于，还包括扫描模块；

所述扫描模块具体用于：

在所述编译环境中对所述待测试代码进行编译和打包之前，确定所述待测试代码的编程语言；

根据所述待测试代码的编程语言确定对应的静态扫描工具；

采用所述静态扫描工具对所述待测试代码进行静态扫描。

9.如权利要求7所述的持续集成系统，其特征在于，所述编译模块具体用于：

确定所述待测试代码中的更新代码；

在所述编译环境中对所述更新代码进行编译，确定更新包；

下载并安装所述待测软件对应的公共依赖包，所述依赖包是由所述持续集成系统在本地编译生成的；

获取所述待测软件对应的需要重新打包的旧软件包；

对所述更新包、所述公共依赖包以及所述旧软件包进行打包。

10.如权利要求7所述的持续集成系统，其特征在于，所述测试模块具体用于：

确定所述待测试代码的测试触发方式；

根据所述测试触发方式触发打包后的所述待测试代码在所述测试环境进行测试。

11.如权利要求7所述的持续集成系统，其特征在于，还包括预发布模块；

所述预发布模块具体用于：

在所述测试模块在所述测试环境中对打包后的所述待测试代码进行测试之后，将测试通过的所述待测试代码发布到预发布环境；

在所述预发布环境中对所述待测试代码进行预发布测试。

12.如权利要求7至11任一所述的持续集成系统，其特征在于，所述测试模块还用于：

生成编译报告和测试报告；

将所述编译报告和所述测试报告发送至开发人员。

13.一种自动化测试设备，其特征在于，包括至少一个处理单元以及至少一个存储单元，其中，所述存储单元存储有计算机程序，当所述程序被所述处理单元执行时，使得所述处理单元执行权利要求1～6任一权利要求所述方法的步骤。

14.一种计算机可读存储介质，其特征在于，其存储有可由自动化测试设备执行的计算机程序，当所述程序在自动化测试设备上运行时，使得所述自动化测试设备执行权利要求1～6任一所述方法的步骤。