CN103176897A - 一种软件回归测试的方法及系统 - Google Patents

Abstract

本申请公开了一种软件回归测试的方法及系统，其中，所述软件回归测试的方法应用于包括有持续集成装置以及集成管理装置的系统中，包括如下步骤：基于测试任务，从所述集成管理装置中确定出要参与回归测试的与所述测试任务对应的集成管理单元，所述集成管理单元内存放有所述软件的待测试脚本；其中，所述集成管理单元和所述持续集成装置中的与所述集成管理装置相匹配的持续集成单元关联；将所述待测试脚本发送至所述持续集成单元；在所述持续集成单元内，执行所述待测试脚本。

Description

一种软件回归测试的方法及系统

技术领域

本申请主要涉及计算机软件技术领域，尤其涉及一种软件测试的方法和系统。

背景技术

软件测试是提高软件可靠性、保证软件质量的重要手段，软件测试活动已经融入软件全生命周期的各个阶段中。其中，回归测试作为软件测试生命周期的一个重要组成部分，在整个软件测试过程中占有很大的比重，软件开发的各个阶段都会进行多次回归测试。

回归测试是指修改了旧代码后，重新对代码进行测试，以确定修改没有产生新的错误或者导致其它代码产生错误。回归测试将大幅度降低系统测试、维护升级等阶段的成本。

目前的回归测试大部分都是用持续集成系统来完成。软件对应的不同的脚本语言，都有其对应的持续集成系统对其进行测试。例如，Automan脚本对应的持续集成系统是STAF、iTest脚本的对应的持续集成系统是Hudson。如图1所示，为回归系统与STAF持续集成系统的交互图。具体包括如下步骤：

S101：回归系统创建Automan脚本任务；

S102：STAF持续集成系统从回归系统中获得Automan脚本任务；

S103：在STAF持续集成系统内执行Automan脚本任务；

S104：在STAF持续集成系统内创建Automan脚本任务的脚本执行结果日志；

S105：将Automan脚本的执行结果回写入回归系统；

S106：在回归系统内创建Automan脚本的执行结果。

目前，在进行回归测试时，负责回归测试的工程师要基于不同的脚本语言，选择与这种脚本语言相对应的持续集成系统。然后将回归测试的结果分散的存储于各个持续集成系统中。另外，如果回归测试失败或者所述脚本执行结果中包含漏洞信息时，还需要在缺陷管理系统里记录漏洞信息。

在实现本申请的过程中，申请人发现现有技术至少存在如下问题：

(1)由于进行回归测试时，要在不同的持续集成系统间切换，所以存在着测试较为繁琐，且效率较低的技术问题；

(2)由于测试结果分散不同的持续集成系统，所以存在着对于测试结果的管理不方便的技术问题；

(3)由于在缺陷管理系统录入漏洞信息时，需要基于不同的持续集成系统分开录入，所以存在着操作较为繁琐的技术问题。

发明内容

本申请实施例提供了一种软件测试的方法，用以解决由于现有技术中回归测试时需要在不同的持续集成系统间切换从而导致软件测试较为繁琐的技术问题。

一方面，本申请通过本申请中的一个实施例，提供如下技术方案：

一种软件回归测试方法，应用于包括有持续集成装置以及集成管理装置的系统中，包括如下步骤：

基于测试任务，从所述集成管理装置中确定出要参与回归测试的与所述测试任务对应的集成管理单元，所述集成管理单元内存放有所述软件的待测试脚本；其中，所述集成管理单元和所述持续集成装置中的与所述集成管理装置相匹配的持续集成单元关联；

将所述待测试脚本发送至所述持续集成单元；

在所述持续集成单元内，执行所述待测试脚本。

进一步的，所述测试任务，具体为：

包含有进行测试的时间信息以及参与测试的集成管理单元信息的任务。

进一步的，在执行所述待测试脚本之后，还包括：

创建所述待测试脚本的脚本执行结果日志。

进一步的，在所述创建所述待测试脚本的脚本执行结果日志之后，还包括：

向所述集成管理装置发送脚本执行结果并存储所述脚本执行结果。

进一步的，在在执行所述待测试脚本之后之后，还包括：

如果所述回归测试失败或者所述脚本执行结果中包含漏洞信息，利用所述集成管理装置的缺陷管理单元提供的接口，向所述缺陷管理单元创建漏洞信息。

另一方面，本申请通过本申请中的另一实施例提供如下技术方案：

一种软件回归测试的系统，包括如下结构：

集成管理装置，包括：

触发单元：用于基于测试任务，从所述集成管理单元中确定出要参与回归测试的与所述测试任务对应的集成管理单元；

集成管理单元：用于存放所述软件的待测试脚本；

持续集成装置，包括：

持续集成单元：用于接收来自所述集成管理单元的待测试脚本；以及执行所述待测试脚本；其中，所述持续集成单元和所述集成管理单元相关联。

进一步的，所述触发单元，包括：

时间信息模块：用于存储进行测试的时间信息；

集成管理系统信息模块：用于存储参与测试的集成管理系统信息。

进一步的，所述持续集成单元，还包括：

日志模块：用于创建所述待测试脚本的脚本执行结果日志。

进一步的，所述持续集成单元，还包括：

发送模块：用于向所述集成管理装置发送脚本执行结果。

进一步的，所述集成管理装置，还包括：

结果管理单元：用于存储来自所述持续集成单元的脚本执行结果。

进一步的，所述集成管理装置，还包括：

缺陷管理单元：用于当所述回归测试失败或者所述脚本执行结果中包含漏洞信息时，利用所述缺陷管理单元提供的接口，在所述缺陷管理单元中创建漏洞信息。

上述技术方案中的一个或多个技术方案，具有如下技术效果或优点：

(1)由于采用了对持续集成系统进行集成的技术方案，达到了避免在不同的持续集成系统间切换、提高测试效率的技术效果；

(2)由于采用了对测试结果进行统一管理的技术方案，达到了对测试结果的管理较为方便的技术效果；

(3)由于采用缺陷管理系统的接口对漏洞信息进行统一管理，达到了对于漏洞信息的管理操作较为简便的技术效果。

附图说明

图1为现有技术中利用持续集成系统对软件进行测试的流程图；

图2为本申请实施例一中一种软件回归测试的方法的流程图；

图3为本申请实施例一中执行所述待测试脚本的流程图；

图4为本申请实施例二中一种软件回归测试的系统的方框图；

图5为本申请实施例二中集成管理单元的具体结构的方框图；

图6为本申请实施例二中持续集成单元的具体结构的方框图。

具体实施方式

为了使本申请所属技术领域中的技术人员更清楚地理解本申请，下面结合附图，通过具体实施例对本申请技术方案作详细描述。

请参考图2至图3，本申请实施例一提供一种软件回归测试方法，应用于包括有持续集成装置以及集成管理装置的系统中，如图2所示，所述软件回归测试的方法，包括如下步骤：

S201：基于测试任务，从所述集成管理装置中确定出要参与回归测试的与所述测试任务对应的集成管理单元，所述集成管理单元内存放有所述软件的待测试脚本；其中，所述集成管理单元和所述持续集成装置中的与所述集成管理装置相匹配的持续集成单元关联；

在具体实施过程中，一个集成管理装置内可以包含多个集成管理单元，而这多个持续集成单元中的每一个集成管理单元都与一个持续集成单元关联，其中可以一个集成管理单元对应一个持续集成单元也可以多个集成管理单元对应一个持续集成单元。

进一步的，所述测试任务，具体为：

包含有进行测试的时间信息以及参与测试的集成管理单元信息的任务。

在具体实施过程中，在触发单元中主要定义了如下的信息：

testlabs()：也即是定义的进行回归的集成管理单元信息；

plan()：也即是定义的进行测试的时间信息。

在具体实施过程中，这里定义的进行测试的时间信息，可以定义周期性的触发、也可以基于外界环境满足一定条件后触发参与测试的集成管理单元，然后再进行回归测试。只要本申请所属技术领域的技术人员所定义的进行测试的时间信息所产生的技术效果和本申请中的技术效果等同，都属于本申请的范围。

在系统时间满足触发单元所定义的进行测试的时间信息时，触发单元发送测试任务触发要参与回归测试的集成管理单元。在具体实施过程中，由触发单元定义的集成管理单元可以是一个，也可以是多个，不作限制。

其中，集成管理单元可以以Testlab(软件测试实验室：一种软件测试的工具)为基类，而ItestTestlab或者AutomanTestlab为子类，子类继承了基类的所有信息。

其中，Testlab包含了如下信息：

svn_url：参与回归脚本所在svn地址；

exec_ip：脚本执行所在的机器IP地址；

execute：执行脚本的方法；

syn_script：同步svn地址上的脚本，解析svn地址的结构。

同样地，集成管理单元继承了Testlab的上述信息。在集成管理单元被触发后，即可基于集成管理单元内部的存储的svn_url获得所述软件的待测试脚本。

在具体实施过程中，基于集成管理单元的不同，待测试脚本也不同。例如，如果集成管理单元为ItestTestlab，那么其内部存放的脚本即为Itest脚本，如果集成管理单元为AutomanTestlab，那么其内部存放的脚本即为Automan脚本。

由于集成管理单元ItestTestlab管理着Itest脚本信息，故而与集成管理单元ItestTestlab相关联的持续集成单元是包含Hudson持续集成系统的单元；而集成管理单元AutomanTestlab管理着Automan脚本信息，故而与集成管理单元AutomanTestlab相关联的持续集成单元是包含STAF持续集成系统的单元。

在具体实施过程中，本申请中的待测试脚本不限于Itest脚本和Automan脚本。所述持续集成单元中包含的持续集成系统也不限于STAF、Hudson持续集成系统。只要该持续集成系统能够继承本申请中的集成管理装置，并且存在集成管理装置能对外提供相应的程序接口，那么该系统即可支持包含其他持续集成系统的持续集成单元，例如：CruiseControl、CruiseControl.NET等。只要本申请所属技术领域的技术人员所采用的持续集成系统所产生的技术效果与本申请实施例中采用的技术方案产生的技术效果等同，都属于本申请的范围。

S202：将所述待测试脚本发送至所述持续集成单元；

在具体实施过程中，获得与集成管理单元相关的持续集成单元后，就可以将与之对应的脚本发送至与之相关的持续集成单元。其中将Itest脚本发送至包含Hudson持续集成系统的持续集成单元；将Automan脚本发送至包含STAF持续集成系统的持续集成单元。

S203：在所述持续集成单元内，执行所述待测试脚本。

其中，在所述持续集成单元内，执行所述待测试脚本的过程，也就是对所述待测试脚本对应的软件进行回归测试的过程。

其中，具体的在所述持续集成单元内构建待测试脚本信息以及运行脚本，如图3所示，包括如下步骤：

S301：执行脚本：在所述持续集成系统内，执行所述待测试脚本；

S302：创建脚本执行的日志：创建所述待测试脚本的脚本执行结果日志。

在具体实施过程中，集成管理装置内部可包含有一个存储执行结果的结果管理单元。结果管理单元包含了脚本运行的结果、时常等信息。结果管理单元提供了执行结果的接口，用于基于不同的持续集成单元保存不用的执行结果信息。

在本申请实施例中，用ItestResult指代第一结果管理单元，AutomanResult指代第二结果管理单元。第一结果管理单元ItestResult和第二结果管理单元AutomanResult都是结果管理单元的子类，继承了基类结果管理单元的所有信息。第一结果管理单元ItestResult管理着Itest脚本在Hudson持续集成系统内执行的结果；而第二结果管理单元AutomanResult则管理着Automan脚本在STAF持续集成系统内的执行结果。

但是，在具体实施过程中，结果管理单元的子类不限于AutomanResul以及ItestResult，也即是在结果管理系统中提供的接口不限于Automan以及Itest脚本语言执行结果存储的接口，也包括其他一切集成管理装置能够测试的脚本语言的接口，只要本申请所述技术领域的技术人员所提供的接口和本申请实施例中提供接口等同，都属于本申请的范围。

并且，在具体实施过程中，执行结果的储存也不限于集成管理装置内部，可以利用数据存储、文件存储以及内存存储等等。只要本申请所述技术领域的技术人员所采用的存储介质与本申请实施例中所采用的介质进行存储时达到的技术效果等同，都属于本申请的范围。

可选的，在所述持续集成系统内运行所述待测试脚本之后，还包括如下步骤：

如果所述回归测试失败或者所述脚本执行结果中包含漏洞信息，利用缺陷管理系统提供的接口，向所述缺陷管理系统创建漏洞信息。

在具体实施过程中，在进行回归测试时，还可以在所述集成管理装置内部提供一个缺陷管理单元。如果出现回归测试失败的情况或者基于待测试脚本的执行结果日志，分析出测试过程遇到测试失败或者测试中发现一些漏洞信息(也即是BUG)，那么调用缺陷管理单元提供的接口，记录漏洞信息。

当然，所述缺陷管理单元也不限于所述所述集成管理装置内部，可以利用数据存储、文件存储以及内存存储等等。只要本申请所述技术领域的技术人员所采用的存储介质与本申请实施例中所采用的介质进行存储时达到的技术效果等同，都属于本申请的范围。

请参考图4至图6，本申请实施例二提供一种软件回归测试系统，如图4所示，包括如下结构：

集成管理装置41，包括：

触发单元411：用于基于测试任务，从所述集成管理单元中确定出要参与回归测试的与所述测试任务对应的集成管理单元；

集成管理单元412：用于存放所述软件的待测试脚本；进一步的，所述触发单元411，包括：

时间信息模块：用于存储进行测试的时间信息；

集成管理单元信息模块：用于存储参与测试的集成管理单元信息。

进一步的，所述集成管理装置41，如图5所示，还包括：

结果管理单元413：用于存储来自所述持续集成单元的脚本执行结果。

进一步的，所述集成管理装置41，如图5所示，还包括：

缺陷管理单元414：用于当所述回归测试失败或者所述脚本执行结果中包含漏洞信息时，利用所述缺陷管理单元提供的接口，在所述缺陷管理单元中创建漏洞信息。

持续集成装置42，包括：

持续集成单元421：用于接收来自所述集成管理单元的待测试脚本；以及执行所述待测试脚本；其中所述持续集成单元421和所述集成管理单元412相关联。

进一步的，所述持续集成单元421，如图6所示，还包括：

日志模块61：用于创建所述待测试脚本的脚本执行结果日志。

发送模块62：用于向所述集成管理模块发送脚本执行结果。

由于本申请实施二中的系统为与实施本申请实施例一中的方法所对应的系统，所以基于本申请实施例一中的方法，本领域所属技术人员能够了解本申请实施二中的系统的具体实施方法以及本申请实施二的系统的各种变化形式。所以在此对于该系统的运行不再详细介绍，只要本领域所属技术人员基于本申请实施例一中的方法所采用的系统，都属于本申请所欲保护的范围。

本申请提供的一个或多个技术方案，至少具有如下技术效果或优点：

(1)由于采用了对持续集成系统进行集成的技术方案，达到了避免在不同的持续集成系统间切换、提高测试效率的技术效果；

(2)由于采用了测试结果统一管理的技术方案，达到了对测试结果较好管理的技术效果；

(3)由于采用缺陷管理系统的接口对漏洞信息进行统一管理，达到了对于漏洞信息的管理操作较为简便的技术效果。

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

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

Claims (11)

1.一种软件回归测试方法，应用于包括有持续集成装置以及集成管理装置的系统中，其特征在于，包括：

基于测试任务，从所述集成管理装置中确定出要参与回归测试的与所述测试任务对应的集成管理单元，所述集成管理单元内存放有所述软件的待测试脚本；其中，所述集成管理单元和所述持续集成装置中的与所述集成管理装置相匹配的持续集成单元关联；

将所述待测试脚本发送至所述持续集成单元；

在所述持续集成单元内，执行所述待测试脚本。

2.如权利要求1所述的方法，其特征在于，所述测试任务，具体为：

包含有进行测试的时间信息以及参与测试的集成管理单元信息的任务。

3.如权利要求1所述的方法，其特征在于，在执行所述待测试脚本之后，还包括：

创建所述待测试脚本的脚本执行结果日志。

4.如权利要求3所述的方法，其特征在于，在所述创建所述待测试脚本的脚本执行结果日志之后，还包括：

向所述集成管理装置发送脚本执行结果并存储所述脚本执行结果。

5.如权利要求1或4所述的方法，其特征在于，在在执行所述待测试脚本之后之后，还包括：

如果所述回归测试失败或者所述脚本执行结果中包含漏洞信息，利用所述集成管理装置的缺陷管理单元提供的接口，向所述缺陷管理单元创建漏洞信息。

6.一种软件回归测试的系统，其特征在于，包括：

集成管理装置，包括：

触发单元：用于基于测试任务，从所述集成管理单元中确定出要参与回归测试的与所述测试任务对应的集成管理单元；

集成管理单元：用于存放所述软件的待测试脚本；

持续集成装置，包括：

持续集成单元：用于接收来自所述集成管理单元的待测试脚本；以及执行所述待测试脚本；其中，所述持续集成单元和所述集成管理单元相关联。

7.如权利要求6所述的系统，其特征在于，所述触发单元，包括：

时间信息模块：用于存储进行测试的时间信息；

集成管理系统信息模块：用于存储参与测试的集成管理系统信息。

8.如权利要求6所述的系统，其特征在于，所述持续集成单元，还包括：

日志模块：用于创建所述待测试脚本的脚本执行结果日志。

9.如权利要求8所述的系统，其特征在于，所述持续集成单元，还包括：

发送模块：用于向所述回归系统发送脚本执行结果。

10.如权利要求6所述的系统，其特征在于，所述集成管理装置，还包括：

结果管理单元：用于存储来自所述持续集成单元的脚本执行结果。

11.如权利要求6或9所述的系统，其特征在于，所述集成管理装置，还包括：

缺陷管理单元：用于当所述回归测试失败或者所述脚本执行结果中包含漏洞信息时，利用所述缺陷管理单元提供的接口，在所述缺陷管理单元中创建漏洞信息。

Images