CN103176895A - 一种回归测试方法和系统 - Google Patents

Abstract

本申请提供了一种回归测试方法和系统，其中的方法具体包括：收集变更代码，并依据所述变更代码分析得到相应的变更代码信息，所述变更代码信息包括变更的类及方法；依据预置的类与类、方法与方法之间的关联关系，对所述变更的类及方法进行依赖分析，得到所有可能受到变更影响的类及方法；依据预置的类及方法与测试用例之间的对应关系，得到与所述所有可能受到变更影响的类及方法相应的测试用例，作为回归测试用例；执行所述回归测试用例，得到相应的用例执行结果。本申请能够减少人工干预，实现回归测试的自动化，提高回归测试的效率。

Description

一种回归测试方法和系统

技术领域

本申请涉及测试技术领域，特别是涉及一种回归测试方法和系统。

背景技术

在软件生命周期的各个阶段，无论是由于修改软件自身的缺陷还是由于用户的需求变更，都必须对软件进行针对性的回归测试，以检查各项修改或变更是否能满足用户的需求。

在大规模的软件研发企业，每天有大量的系统、功能更新，因此大量代码的新增等变更不可避免。

在回归测试领域，现有技术是比较死板的，就是在每天某个时刻对所有预设系统进行回归测试，如果需要立即对某个系统或某个功能进行回归测试，则需要人工干预：用户需要首先登陆测试用例管理系统，人工判断并选择出需要运行的测试用例，然后启动之，这导致回归测试的效率大大降低。这里，测试用例(TC，Test Case)，指对被测的特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。

总之，需要本领域技术人员迫切解决的一个技术问题就是：如何能够提高回归测试的效率。

发明内容

本申请提供一种回归测试方法和系统，以减少人工干预，实现回归测试的自动化，提高回归测试的效率。

为了解决上述问题，本申请公开了一种回归测试方法，包括：

收集变更代码，并依据所述变更代码分析得到相应的变更代码信息，所述变更代码信息包括变更的类及方法；

依据预置的类与类、方法与方法之间的关联关系，对所述变更的类及方法进行依赖分析，得到所有可能受到变更影响的类及方法；

依据预置的类及方法与测试用例之间的对应关系，得到与所述所有可能受到变更影响的类及方法相应的测试用例，作为回归测试用例；

执行所述回归测试用例，得到相应的用例执行结果。

优选的，所述方法还包括：

在执行回归测试用例前，获取所述回归测试用例的目标应用和目标机器；

在执行所述回归测试用例的过程中，记录相应目标机器中的目标应用运行过的代码；

在所述用例执行结果为失败时，通过分析所记录的目标应用运行过的代码，定位相应的软件缺陷中的类及方法。

优选的，所述变更代码信息还包括变更的应用、jar包或URL；

所述方法还包括：

依据预置的应用与类、应用与方法、应用与应用、jar包与类、jiar包与方法、URL与类或URL与方法之间的关联关系，对所述变更的应用、jar包或URL进行依赖分析，得到所有可能受到变更影响的类及方法或应用；

在得到所有可能受到变更影响的应用时，所述方法还包括：

依据预置的应用与测试用例之间的对应关系，得到与所述所有可能受到变更影响的应用相应的测试用例，作为回归测试用例。

优选的，在对所述变更的类及方法进行依赖分析前，所述方法还包括：

依据预置的代码变更次数参数或时间参数，对收集和分析得到的变更的类及方法进行汇总；

对汇总的变更的类及方法进行去重处理。所述去重处理包括在：在遍历所述汇总的变更的类及方法的过程中，相同的变更的类及方法仅记录一次；

所述对所述变更的类及方法进行依赖分析为，依据预置的类与类、方法与方法之间的关联关系，对去重处理后的变更的类及方法进行依赖分析，得到所有可能受到变更影响的类及方法。

优选的，所述执行所述回归测试用例的步骤包括：

依据所述所有可能受到变更影响的类及方法所在的应用，发布所述应用的最新程序；

在已发布最新程序的环境下执行所述回归测试用例，得到相应的用例执行结果。

优选的，所述执行所述回归测试用例的步骤包括：

依据定时回归策略或变更次数上限策略，针对所述回归测试用例创建任务对象，确定任务对象的信息，并保存至数据库；

依据所述任务对象的信息，执行数据库中的任务对象。

优选的，所述收集变更代码的步骤为，通过监控代码服务器，收集所有的变更代码。

另一方面，本申请还公开了一种回归测试系统，包括：

收集装置，用于收集变更代码；

变更分析装置，用于依据所述变更代码分析得到相应的变更代码信息，所述变更代码信息包括变更的类及方法；

第一依赖分析装置，用于依据预置的类与类、方法与方法之间的关联关系，对所述变更的类及方法进行依赖分析，得到所有可能受到变更影响的类及方法；

第一回归测试用例获取装置，用于依据预置的类及方法与测试用例之间的对应关系，得到与所述所有可能受到变更影响的类及方法相应的测试用例，作为回归测试用例；

用例执行装置，用于执行所述回归测试用例，得到相应的用例执行结果。

优选的，所述系统还包括：

应用信息获取装置，用于在执行回归测试用例前，获取所述回归测试用例的目标应用和目标机器；

记录装置，用于在执行所述回归测试用例的过程中，记录相应目标机器中的目标应用运行过的代码；及

代码分析装置，用于在所述用例执行结果为失败时，通过分析所记录的目标应用运行过的代码，定位相应的软件缺陷中的类及方法。

优选的，所述变更代码信息还包括变更的应用、jar包或URL；

所述系统还包括：

第二依赖分析装置，用于依据预置的应用与类、应用与方法、应用与应用、jar包与类、jiar包与方法、URL与类或URL与方法之间的关联关系，对所述变更的应用、jar包或URL进行依赖分析，得到所有可能受到变更影响的类及方法或应用；

第二回归测试用例获取装置，用于在得到所有可能受到变更影响的应用时，依据预置的应用与测试用例之间的对应关系，得到与所述所有可能受到变更影响的应用相应的测试用例，作为回归测试用例。

与现有技术相比，本申请具有以下优点：

首先，本申请自动收集并分析所有变更代码得到变更的类及方法，并进一步依据依赖分析得到所有可能受到变更影响的类及方法，以及依据预置的类及方法与测试用例之间的对应关系，得到与所述所有可能受到变更影响的类及方法相应的测试用例，作为回归测试用例；因此，相对于现有技术，本申请能够减少人工干预，实现回归测试的自动化，提高回归测试的效率。

其次，相对于调用全部的测试用例进行测试以避免有漏网之鱼的现有技术，由于本申请收集并分析所有变更代码得到变更的类及方法以确定代码的变更所引起需要回归测试的范围，因此，能够起到缩小回归测试范围的效果，而且能够进一步提高回归测试的效率，节省机器资源。

再者，本申请还可以在执行回归测试用例的过程中，记录相应目标机器中的目标应用运行过的代码；这样，在相应的用例执行结果为失败时，记录的就是含有缺陷的代码，此时，可以通过分析所记录的目标应用运行过的代码，定位相应的软件缺陷中的类及方法；另外，本申请还可以通过人工进一步分析这些代码将目标应用缺陷定位到行的级别。

附图说明

图1是本申请一种回归测试方法实施例1的流程图；

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

图3是本申请一种回归测试方法实施例3的流程图；

图4是本申请一种回归测试方法的应用示例；

图5是本申请一种回归测试系统实施例的结构图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

在需要立即对某个系统或某个功能进行回归测试时，因为代码的变更所引起需要回归测试的范围在原有回归测试方案中不可获得，并且测试用例与变更的代码没有关联关系，所以现有技术在选择需要回归的用例时需要人工干预。

本申请发明人注意到了这一点，创造性地提出了本申请的发明构思：

1、本申请自动收集并分析所有变更代码得到变更的类及方法，并进一步依据依赖分析得到所有可能受到变更影响的类及方法；所有可能受到变更影响的类及方法能够确定代码的变更所引起需要回归测试的范围；

2、本申请自动集成代码关联测试用例功能，也即，预置类及方法与测试用例之间的对应关系，以在变更的代码和测试用例之间建立关联关系。

上述收集、分析和依赖分析，以及集成代码关联测试用例功能均为自动执行，无需人工干预，因此，相对于现有技术，能够实现回归测试的自动化，提高回归测试的效率。

参照图1，其示出了本申请一种回归测试方法实施例1的流程图，具体可以包括：

步骤101、收集变更代码，并依据所述变更代码分析得到相应的变更代码信息，所述变更代码信息具体可以包括变更的类及方法；

本申请可以用于各种软件，用于在软件生命周期的各个阶段，对软件进行针对性的回归测试，以检查各项修改或变更是否能满足用户的需求，并且，所述回归测试基本无需人工干预，具有较高的测试效率。

在实际中，开发工程师在变更软件的代码后，一般会提交到代码服务器；这样，所述收集变更代码的步骤可以为，通过监控代码服务器，收集所有的变更代码。代码服务器的一个例子是SVN，其全称subversion是著名的软件版本管理的工具。

源代码库中有非常多的有用信息，这些信息不容易提取或及时跟踪。在具体实现中，可以采用各种源码跟踪和管理软件来执行所述收集和分析变更代码的操作。例如，作为一种典型的源码跟踪和管理软件，FishEye可提供如下功能：

1、监控：可跟踪任意开发者的源代码，并提供配置的变更代码日志；

2、搜索：可得到寻找的变更代码.并快速地转到文件；例如，可通过注释、路径、源代码、作者等关键词来搜索；

3、共享：留在同一个页面，链接到仓库中的任何内容：注释、目录、文件历史记录、修订、源代码行和查询结果等；

4.分析：可依据所述变更代码分析得到相应的变更代码信息，并以线图形式展示。

步骤102、依据预置的类与类、方法与方法之间的关联关系，对所述变更的类及方法进行依赖分析，得到所有可能受到变更影响的类及方法；

类指面向对象编程语言中用于描述一类事物的数据模型定义，由类的形式化定义可以看出，类是一种具有相同属性和相同操作的对象的集合，是所有具有共同行为特征和信息结构的对象的集合，它代表一种抽象，是代表对象的本质的、主要的、可观察的行为，它给出了属于该类的全部对象的抽象定义，包括类的属性、操作和其他性质。每个类不是孤立、分割的，而是相互联系、制约的。类之间的依赖关系也正是这种关系的体现。

因此，在类及方法被变更时，与其存在依赖关系的类及方法也很有可能受到影响。于是，本申请依据依赖分析得到所有可能受到变更影响的类及方法。

在实际中，类之间的依赖关系可被细分为数据依赖和方法依赖，这两种类型的依赖可以单独存在，也可以同时存在。由于前面收集并分析得到了变更的类及方法，故本申请实施例在考虑类与类之间的关联关系的同时，还考虑方法与方法之间的关联关系。

在具体实现中，可以提供某个或某些软件开发项目的类及方法，并且预置类与类、方法与方法之间的关联关系，这样，在自动进行回归测试的过程中，就可以自动对所述变更的类及方法进行依赖分析，得到所有可能受到变更影响的类及方法。

步骤103、依据预置的类及方法与测试用例之间的对应关系，得到与所述所有可能受到变更影响的类及方法相应的测试用例，作为回归测试用例；

所有可能受到变更影响的类及方法确定了代码的变更所引起需要回归测试的范围，这里，则是在变更的代码和测试用例之间建立关联关系。在实际中，可以依据软件开发项目的特点及测试需求，预置类及方法与测试用例之间的对应关系，例如可以存储在关联表中，本申请对具体的预置方法不加以限制。

步骤104、执行所述回归测试用例，得到相应的用例执行结果。

用例执行结果可以包括成功或失败，以表明检查代码变更能否满足用户的需求。

在本申请的一种优选实施例中，所述执行所述回归测试用例的步骤可以进一步包括：

依据定时回归策略或变更次数上限策略，针对所述回归测试用例创建任务对象，确定任务对象的信息，并保存至数据库；

依据所述任务对象的信息，执行数据库中的任务对象。

本优选实施例在确定需要进行回归测试的回归测试用例后，结合回归策略，创建任务对象，并依据任务对象的信息对数据库中的任务对象进行调度。

本申请可以提供定时回归策略或变更次数上限策略，其中，定时回归策略的原则是每隔一段时间进行一次回归测试，而回归测试的范围由步骤102的结果决定；变更次数上限策略则是指监控到代码变更发生的次数到达指定的上限时，开始回归测试。上述一段时间或代码变更发生的次数均可由本领域技术人员根据回归测试的需求确定，本申请对此不加以限制。

假设使用定时回归策略，定时时间间隔为24小时，则每隔24小时，针对此前24小汇总到的变更所涉及到的类及方法等信息，依据预置的类及方法与测试用例之间的对应关系，得到相应的测试用例信息，并依据测试用例信息创建任务对象，保存到数据库中。

本优选实施例在创建任务对象时，确定任务对象的信息；这里，任务对象的信息主要可以包括任务对象的执行时间。例如，在采用定时回归策略时，可以指定任务对象的执行时间为晚上，因为晚上的执行速度比较快；又如，在采用变更次数上限策略时，可以指定任务对象的执行时间为立即。

由于在创建任务对象时，还会指定任务对象的其他信息，如回归测试用例的唯一标识、任务对象状态(未开始、进行中、成功完成、已失败等)、任务对象的持续时间，任务对象已执行的次数、任务对象的创建时间、任务对象的描述信息等，故本申请还可以依据这些信息对数据库中的任务对象进行监控管理，以做到回归测试的透明化。

总之，本申请能够在基本无人工干预的情况下，自动收集并分析所有变更代码得到变更的类及方法，并进一步依据依赖分析得到所有可能受到变更影响的类及方法，以及依据预置的类及方法与测试用例之间的对应关系，得到与所述所有可能受到变更影响的类及方法相应的测试用例，作为回归测试用例；因此，相对于现有技术，本申请能够实现回归测试的自动化，提高回归测试的效率。

另外，现有技术的回归测试方法，通常对所有系统编的回归脚本人为进行分类，对各分类脚本人工制定调度计划，目前多使用偷懒的做法，那就是不管是否必要，调用全部的测试用例，以避免有漏网之鱼。而本申请的收集并分析所有变更代码得到变更的类及方法能够起到缩小回归测试范围的效果，从而能够进一步提高回归测试的效率，节省机器资源。

在本申请的一种优选实施例中，所述变更代码信息还可以包括变更的应用、jar包或URL(统一资源定位符，Uniform Resource Locator)；

相应地，所述方法还可以包括：

依据预置的应用与类、应用与方法、应用与应用、jar包与类、jar包与方法、URL与类或URL与方法之间的关联关系，对所述变更的应用、jar包或URL进行依赖分析，得到所有可能受到变更影响的类及方法或应用；

在得到所有可能受到变更影响的应用时，所述方法还可以包括：

依据预置的应用与测试用例之间的对应关系，得到与所述所有可能受到变更影响的应用相应的测试用例，作为回归测试用例。

本优选实施例的构思之一在于，在实际中，除了变更的类及方法外，分析得到的变更代码信息还可以包括应用、jar包或URL等，因此，为了进行依赖分析，还应预置应用与类、应用与方法、jar包与类、jar包与方法、URL与类或URL与方法的关联关系；这里，Jar包指java软件的API(应用程序编程接口，Application Programming Interface，)库。

本优选实施例的构思之二在于，在某些软件开发项目中，应用很关键很重要，一旦发现应用受到变更影响，必须执行该应用；于是，本申请还可以预置应用与应用之间的关联关系以进行依赖分析；另外，为了在变更的代码和测试用例之间建立关联关系，还应预置应用与测试用例之间的对应关系。

在本申请的另一种优选实施例中，在对所述变更的类及方法进行依赖分析前，所述方法还可以包括：

依据预置的代码变更次数参数或时间参数，对收集和分析得到的变更的类及方法进行汇总；

对汇总的变更的类及方法进行去重处理。所述去重处理包括在：在遍历所述汇总的变更的类及方法的过程中，相同的变更的类及方法仅记录一次；

此时，所述对所述变更的类及方法进行依赖分析可以为，依据预置的类与类、方法与方法之间的关联关系，对去重处理后的变更的类及方法进行依赖分析，得到所有可能受到变更影响的类及方法。

本优选实施例的主要思想在于，对变更的类及方法进行去重处理，以避免执行重复的回归测试，进一步提升回归测试的效率。

由于在收集和分析变更代码时，通常会记录下本次变更涉及到的类及方法等变更代码信息，这样，如果下次变更涉及与本次变更相同的类及方法，则不需要重复记录，这就是去重的原理；而汇总的目的在于去重；所述遍历可以是从后到前遍历，也可以是从前到后遍历。

关于预置的代码变更次数参数或时间参数的实现方案，在具体实现中，可以设置一个数字或者一个汇总时间。如果设置的是数字，那么当代码变更次数达到此数字时，则可以进行汇总，并触发后续动作(依赖分析)，如果设置的是汇总时间，那么可以每隔一段时间汇总变更，然后触发后续动作。

参照图2，其示出了本申请一种回归测试方法实施例2的流程图，具体可以包括：

步骤201、收集变更代码，并依据所述变更代码分析得到相应的变更代码信息，所述变更代码信息包括变更的类及方法；

步骤202、依据预置的类与类、方法与方法之间的关联关系，对所述变更的类及方法进行依赖分析，得到所有可能受到变更影响的类及方法；

步骤203、依据预置的类及方法与测试用例之间的对应关系，得到与所述所有可能受到变更影响的类及方法相应的测试用例，作为回归测试用例；

步骤204、在执行回归测试用例前，获取所述回归测试用例的目标应用和目标机器；

步骤205、执行所述回归测试用例，得到相应的用例执行结果；

步骤206、在执行所述回归测试用例的过程中，记录相应目标机器中的目标应用运行过的代码；

步骤207、在所述用例执行结果为失败时，通过分析所记录的目标应用运行过的代码，定位相应的软件缺陷中的类及方法。

通常，任何一个类都隶属于一个或者多个应用的，这里的应用可以包括程序等等；那么，在执行回归测试用例的过程中，相应的目标应用必然会运行相应的代码。

本实施例与实施例1的区别在于，在执行回归测试用例的过程中，记录相应目标机器中的目标应用运行过的代码；这样，在相应的用例执行结果为失败时，记录的就是含有缺陷的代码，此时，可以通过分析所记录的目标应用运行过的代码，定位相应的软件缺陷中的类及方法。

上面将目标应用缺陷定位到类及方法的级别，当然缺陷可能只是包含在运行过代码的某一行中，此时，需要通过人工进一步分析这些代码才能精确定位到行的级别。

需要说明的是，在相应的用例执行结果为成功时，记录代码是不含有缺陷的，因此可以抛弃该记录。

对于方法实施例2而言，由于其与方法实施例1基本相似，所以描述的比较简单，相关之处参见方法实施例1的部分说明即可。

参照图3，其示出了本申请一种回归测试方法实施例3的流程图，具体可以包括：

步骤301、收集变更代码，并依据所述变更代码分析得到相应的变更代码信息，所述变更代码信息包括变更的类及方法；

步骤302、依据预置的类与类、方法与方法之间的关联关系，对所述变更的类及方法进行依赖分析，得到所有可能受到变更影响的类及方法；

步骤303、依据预置的类及方法与测试用例之间的对应关系，得到与所述所有可能受到变更影响的类及方法相应的测试用例，作为回归测试用例；

步骤304、依据所述所有可能受到变更影响的类及方法所在的应用，发布所述应用的最新程序；

步骤305、在已发布最新程序的环境下执行所述回归测试用例，得到相应的用例执行结果。

本实施例与实施例1的主要区别在于，细化回归测试用例的执行流程，具体而言，首先依据所述所有可能受到变更影响的类及方法所在的应用，发布所述应用的最新程序，以得到回归测试用例的应用环境，然后在这个应用环境下执行所述回归测试用例。在具体实现中，步骤303和步骤304在执行顺序上并无限制。

假设本次回归测试的目标系统为A系统，则可以通过HTTP协议发送请求到相应的程序发布系统，请求的url示例为：

http://www.deploy.com/deployApp.htm？appName＝A

发布系统接收到请求，则开始部署A系统，部署完成后，在请求的响应信息中写入success。

收到此响应即可知A系统部署完毕，然后发送请求到回归测试系统中，请求的url示例：

http://www.automan.com/runTest.htm？testCaseIds＝12，34，53，42

其中，最后以逗号分隔的数字表示用例的数据库记录标识，是计算回归测试用例时回归测试系统回传信息所需的，回归测试系统开始执行这些用例，并记录用例的执行结果，最终将结果回传。

假设本次回归测试一个用例失败(如果多个，则返回结果有多行)，则用例执行结果的一个返回格式示例如下：

result:fail；ip:xxx.xxx.xxx.xxx；appName:xxx；className:xxx。

对于方法实施例3而言，由于其与方法实施例1基本相似，所以描述的比较简单，相关之处参见方法实施例1的部分说明即可。

为使本领域技术人员更好地理解本申请，参照图4，其示出了本申请一种回归测试方法的应用示例，具体可以包括：

步骤1、开发工程师提交代码；

步骤2、SVN监控管理分析系统进行版本监控和变更分析，并向集成回归系统发出变更通知；

其中，所述版本监控主要包括监控SVN等代码服务器以收集、汇总所有代码变更，所述变更分析主要包括分析出变更的应用、jar包、类及方法等变更代码信息，并发送到集成回归系统。

步骤3、集成回归系统针对来自SVN监控管理分析系统的变更代码信息，进行分析汇总、去重，将最终的变更结果发送到depend系统，以查找依赖；

步骤4、Depend系统在收到变更结果后，通过依赖分析，查找出所有有可能受到变更影响的应用、类及方法，并将依赖分析结果回送到集成回归系统；

步骤5、集成回归系统在接收到依赖分析结果后，计算出需要进行回归测试的回归测试用例，并结合用户设定的回归策略，创建任务对象并交由任务由任务调度引擎进行调度，任务调度引擎首先根据涉及到的应用发送构建命令到自动部署系统；

步骤6、自动部署系统开始构建发布目标应用，在发布完毕后，返回环境准备完毕的响应以通知集成回归系统环境可以使用；

步骤7、集成回归系统收到环境准备完毕的消息后，将测试任务发送到测试用例执行系统，测试用例执行系统在执行测试任务中指定的回归测试用例前，将该回归测试用例对应的目标应用、目标机器的IP，端口等信息发回集成回归系统，然后开始执行，并监控用例的用例执行结果，最终将用例执行结果返回到集成回归系统；

步骤8、集成回归系统接到测试用例执行系统在执行回归测试用例前返回的信息，并发送命令到TCC系统；TCC系统根据命令在执行回归测试用例的过程中记录相应目标机器中的目标应用运行过的代码，并在所述用例执行结果为失败时，通过分析所记录的目标应用运行过的代码，定位相应的软件缺陷中的类及方法。

与前述方法实施例相应，本申请还提供了一种回归测试系统，参照图5，具体可以包括：

收集装置501，用于收集变更代码；

变更分析装置502，用于依据所述变更代码分析得到相应的变更代码信息，所述变更代码信息包括变更的类及方法；

第一依赖分析装置503，用于依据预置的类与类、方法与方法之间的关联关系，对所述变更的类及方法进行依赖分析，得到所有可能受到变更影响的类及方法；

第一回归测试用例获取装置504，用于依据预置的类及方法与测试用例之间的对应关系，得到与所述所有可能受到变更影响的类及方法相应的测试用例，作为回归测试用例；及

用例执行装置505，用于执行所述回归测试用例，得到相应的用例执行结果。

在本申请的一种优选实施例中，所述系统还可以包括：

应用信息获取装置，用于在执行回归测试用例前，获取所述回归测试用例的目标应用和目标机器；

记录装置，用于在执行所述回归测试用例的过程中，记录相应目标机器中的目标应用运行过的代码；及

代码分析装置，用于在所述用例执行结果为失败时，通过分析所记录的目标应用运行过的代码，定位相应的软件缺陷中的类及方法。

在本申请的另一种优选实施例中，所述变更代码信息还可以包括变更的应用、jar包或URL；

所述系统还可以包括：

第二依赖分析装置，用于依据预置的应用与类、应用与方法、应用与应用、jar包与类、jiar包与方法、URL与类或URL与方法之间的关联关系，对所述变更的应用、jar包或URL进行依赖分析，得到所有可能受到变更影响的类及方法或应用；及

第二回归测试用例获取装置，用于在得到所有可能受到变更影响的应用时，依据预置的应用与测试用例之间的对应关系，得到与所述所有可能受到变更影响的应用相应的测试用例，作为回归测试用例。

在本申请的再一种优选实施例中，所述系统还可以包括：

汇总装置，用于在对所述变更的类及方法进行依赖分析前，依据预置的代码变更次数参数或时间参数，对收集和分析得到的变更的类及方法进行汇总；

去重处理装置，用于对汇总的变更的类及方法进行去重处理。所述去重处理包括在：在遍历所述汇总的变更的类及方法的过程中，相同的变更的类及方法仅记录一次；

此时，所述第一依赖分析装置503，可具体用于依据预置的类与类、方法与方法之间的关联关系，对去重处理后的变更的类及方法进行依赖分析，得到所有可能受到变更影响的类及方法。

在本申请的一种优选实施例中，所述用例执行装置505可以进一步包括：

发布模块，依据所述所有可能受到变更影响的类及方法所在的应用，发布所述应用的最新程序；

执行模块，用于在已发布最新程序的环境下执行所述回归测试用例，得到相应的用例执行结果。

在本申请的另一种优选实施例中，所述用例执行装置505具体可以包括：

任务对象创建模块，用于依据定时回归策略或变更次数上限策略，针对所述回归测试用例创建任务对象，并保存至数据库；

调度执行模块，用于依据任务对象的信息，依次执行数据库中的任务对象。

在本申请实施例中，优选的是，所述收集装置501，可具体用于通过监控代码服务器，收集所有的变更代码。

对于系统实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

以上对本申请所提供的一种回归测试方法和系统，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (10)

1.一种回归测试方法，其特征在于，包括：

收集变更代码，并依据所述变更代码分析得到相应的变更代码信息，所述变更代码信息包括变更的类及方法；

依据预置的类与类、方法与方法之间的关联关系，对所述变更的类及方法进行依赖分析，得到所有可能受到变更影响的类及方法；

依据预置的类及方法与测试用例之间的对应关系，得到与所述所有可能受到变更影响的类及方法相应的测试用例，作为回归测试用例；

执行所述回归测试用例，得到相应的用例执行结果。

2.如权利要求1所述的方法，其特征在于，还包括：

在执行回归测试用例前，获取所述回归测试用例的目标应用和目标机器；

在执行所述回归测试用例的过程中，记录相应目标机器中的目标应用运行过的代码；

在所述用例执行结果为失败时，通过分析所记录的目标应用运行过的代码，定位相应的软件缺陷中的类及方法。

3.如权利要求1所述的方法，其特征在于，所述变更代码信息还包括变更的应用、jar包或URL；

所述方法还包括：

依据预置的应用与类、应用与方法、应用与应用、jar包与类、jiar包与方法、URL与类或URL与方法之间的关联关系，对所述变更的应用、jar包或URL进行依赖分析，得到所有可能受到变更影响的类及方法或应用；

在得到所有可能受到变更影响的应用时，所述方法还包括：

依据预置的应用与测试用例之间的对应关系，得到与所述所有可能受到变更影响的应用相应的测试用例，作为回归测试用例。

4.如权利要求1所述的方法，其特征在于，在对所述变更的类及方法进行依赖分析前，所述方法还包括：

依据预置的代码变更次数参数或时间参数，对收集和分析得到的变更的类及方法进行汇总；

对汇总的变更的类及方法进行去重处理。所述去重处理包括在：在遍历所述汇总的变更的类及方法的过程中，相同的变更的类及方法仅记录一次；

所述对所述变更的类及方法进行依赖分析为，依据预置的类与类、方法与方法之间的关联关系，对去重处理后的变更的类及方法进行依赖分析，得到所有可能受到变更影响的类及方法。

5.如权利要求1所述的方法，其特征在于，所述执行所述回归测试用例的步骤包括：

依据所述所有可能受到变更影响的类及方法所在的应用，发布所述应用的最新程序；

在已发布最新程序的环境下执行所述回归测试用例，得到相应的用例执行结果。

6.如权利要求1所述的方法，其特征在于，所述执行所述回归测试用例的步骤包括：

依据定时回归策略或变更次数上限策略，针对所述回归测试用例创建任务对象，确定任务对象的信息，并保存至数据库；

依据所述任务对象的信息，执行数据库中的任务对象。

7.如权利要求1所述的方法，其特征在于，所述收集变更代码的步骤为，通过监控代码服务器，收集所有的变更代码。

8.一种回归测试系统，其特征在于，包括：

收集装置，用于收集变更代码；

变更分析装置，用于依据所述变更代码分析得到相应的变更代码信息，所述变更代码信息包括变更的类及方法；

第一依赖分析装置，用于依据预置的类与类、方法与方法之间的关联关系，对所述变更的类及方法进行依赖分析，得到所有可能受到变更影响的类及方法；

第一回归测试用例获取装置，用于依据预置的类及方法与测试用例之间的对应关系，得到与所述所有可能受到变更影响的类及方法相应的测试用例，作为回归测试用例；

用例执行装置，用于执行所述回归测试用例，得到相应的用例执行结果。

9.如权利要求8所述的系统，其特征在于，还包括：

应用信息获取装置，用于在执行回归测试用例前，获取所述回归测试用例的目标应用和目标机器；

记录装置，用于在执行所述回归测试用例的过程中，记录相应目标机器中的目标应用运行过的代码；及

代码分析装置，用于在所述用例执行结果为失败时，通过分析所记录的目标应用运行过的代码，定位相应的软件缺陷中的类及方法。

10.如权利要求8所述的系统，其特征在于，所述变更代码信息还包括变更的应用、jar包或URL；

所述系统还包括：

第二依赖分析装置，用于依据预置的应用与类、应用与方法、应用与应用、jar包与类、jiar包与方法、URL与类或URL与方法之间的关联关系，对所述变更的应用、jar包或URL进行依赖分析，得到所有可能受到变更影响的类及方法或应用；

第二回归测试用例获取装置，用于在得到所有可能受到变更影响的应用时，依据预置的应用与测试用例之间的对应关系，得到与所述所有可能受到变更影响的应用相应的测试用例，作为回归测试用例。

Images