CN111831574B - 回归测试规划方法、装置、计算机系统和介质 - Google Patents

Abstract

本公开提供了一种回归测试规划方法，包括：从代码仓库中获取待测应用的当前版本源代码和前一版本源代码；比较当前版本源代码和前一版本源代码，以确定当前版本源代码相对于前一版本源代码的增量代码函数清单；确定与增量代码函数清单相关联的目标代码路径；以及，从测试案例库中确定针对目标代码路径的历史测试案例，以作为待测应用的回归测试案例。本公开还提供了一种回归测试规划装置、计算机系统和介质。本公开提供的回归测试规划方法和装置可以应用于金融领域以及其他相关领域的软件回归测试场景，既可以避免回归测试用例覆盖不足，也可以降低低价值回归测试用例本的投入，进而有效提高回归测试效率及有效性。

Description

回归测试规划方法、装置、计算机系统和介质

技术领域

本公开涉及计算机技术领域，更具体地，涉及一种回归测试规划方法、装置、计算机系统和介质。

背景技术

在软件生命周期中的任何一个阶段，只要软件发生改变，就可能给该软件带来问题。回归测试用于在软件发生更新、修改之后，对其进行重新测试，以确保所实施的更改不会对现有代码产生不利的影响。回归测试是软件测试中的一个十分重要且成本昂贵的过程，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行得更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。如何减少回归测试成本，提高回归测试效率，具有十分重要的意义。

发明内容

本公开的一个方面提供了一种回归测试规划方法，包括：从代码仓库中获取待测应用的当前版本源代码和前一版本源代码；比较当前版本源代码和前一版本源代码，以确定当前版本源代码相对于前一版本源代码的增量代码函数清单；确定与增量代码函数清单相关联的目标代码路径；以及，从测试案例库中确定针对目标代码路径的历史测试案例，以作为待测应用的回归测试案例。

可选地，上述确定与增量代码函数清单相关联的目标代码路径包括：利用深度优先搜索算法，对当前版本源代码进行遍历，以确定当前版本源代码中多个函数各自的执行路径；基于增量代码函数清单，从上述多个函数中筛选出新增函数的执行路径、以及与所述新增函数存在调用关系的存量函数的执行路径；以及，由上述新增函数的执行路径和存量函数的执行路径，构成目标代码路径。

可选地，上述方法还包括：获取针对待测应用的历史测试案例，每个历史测试案例包括：业务场景标签和代码调用分支；以及，将历史测试案例添加存储至测试案例库中。

可选地，上述从测试案例库中确定针对目标代码路径的历史测试案例包括：从测试案例库中查找与目标代码路径相匹配的历史测试案例，由该相匹配的历史测试案例作为回归测试案例，并由回归测试案例中的业务场景标签来指示回归测试案例的业务场景。

可选地，上述方法还包括：在获取针对待测应用的历史测试案例之前，响应于针对待测应用中的指定业务功能的测试操作，在针对指定业务功能的业务请求中添加针对指定业务功能的业务场景标签，以得到标记业务请求；将标记业务请求发送至待测应用的服务器，由服务器基于标记业务请求进行函数执行过程，并构造由业务场景标签和函数执行过程所涉及的代码调用分支构成的历史测试案例。

可选地，上述在针对指定业务功能的业务请求中添加针对指定业务功能的业务场景标签包括：拦截业务请求；以及，在业务请求的报文头中添加业务场景标签。

可选地，上述由服务器基于标记业务请求进行函数执行过程，并构造由业务场景标签和函数执行过程所涉及的代码调用分支构成的历史测试案例包括由服务器执行如下操作：对标记业务请求进行解析，以得到业务请求和业务场景标签；对待测应用的编译后代码进行插桩操作，以跟踪针对业务请求的函数执行过程，从而确定函数执行过程所涉及的代码调用分支；以及，为代码调用分支添加业务场景标签，以得到一个历史测试案例。

可选地，上述方法还包括：在得到待测应用的回归测试案例之后，基于回归测试案例中的业务场景标签，对待测应用的服务器进行回归测试。

本公开的另一方面提供了一种回归测试规划装置，包括：获取模块、比对模块、分析模块和规划模块。获取模块用于从代码仓库中获取待测应用的当前版本源代码和前一版本源代码。比对模块用于比较当前版本源代码和前一版本源代码，以确定当前版本源代码相对于前一版本源代码的增量代码函数清单。分析模块用于确定与增量代码函数清单相关联的目标代码路径。规划模块用于从测试案例库中确定针对目标代码路径的历史测试案例，以作为待测应用的回归测试案例。

本公开的另一方面提供了一种计算机系统，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时用于实现如上所述的方法。

本公开的另一方面提供了一种计算机可读存储介质，存储有计算机可执行指令，所述指令在被执行时用于实现如上所述的方法。

本公开的另一方面提供了一种计算机程序，所述计算机程序包括计算机可执行指令，所述指令在被执行时用于实现如上所述的方法。

根据本公开实施例的回归测试规划方法通过比较待测应用的新旧版本的代码确定增量代码函数清单，进而确定可能会受到增量代码函数清单影响的目标代码路径。结合测试案例库中的历史测试案例及目标代码路径，得到需要进行回归测试的测试案例清单，从而完成回归测试规划工作。上述过程将回归测试的测试范围从待测应用的全部代码路径整体缩小定位至仅与代码变化相关联的目标代码路径，既可以避免回归测试用例覆盖不足的问题，同时还可以降低低价值回归测试用例本的投入。能够有效提高回归测试效率及有效性。

附图说明

为了更完整地理解本公开及其优势，现在将参考结合附图的以下描述，其中：

图1示意性示出了根据本公开实施例的应用回归测试规划方法和装置的示例性系统架构；

图2示意性示出了根据本公开实施例的回归测试规划方法的流程图；

图3示意性示出了根据本公开实施例的图1中的路径分析模块132的示例结构图；

图4示意性示出了根据本公开实施例的代码路径的示例示意图；

图5示意性示出了根据本公开实施例的图1中的测试终端代理模块111的示例结构图；

图6示意性示出了根据本公开实施例的图1中的待测应用代理模块121的示例结构图；

图7示意性示出了根据本公开另一实施例的回归测试规划方法的示例流程图；

图8示意性示出了根据本公开实施例的回归测试规划装置的框图；以及

图9示意性示出了根据本公开实施例的计算机系统的框图。

具体实施方式

以下，将参照附图来描述本公开的实施例。但是应该理解，这些描述只是示例性的，而并非要限制本公开的范围。在下面的详细描述中，为便于解释，阐述了许多具体的细节以提供对本公开实施例的全面理解。然而，明显地，一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。

在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了所述特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。

在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。

在使用类似于“A、B和C等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有A、B和C中至少一个的系统”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的系统等)。在使用类似于“A、B或C等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有A、B或C中至少一个的系统”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的系统等)。

本公开的实施例提供了一种回归测试规划方法和装置。该回归测试规划方法可以包括获取过程、比对过程、分析过程和规划过程。在获取过程中，从代码仓库中获取待测应用的当前版本源代码和前一版本源代码。在比对过程中，比较当前版本源代码和前一版本源代码，以确定当前版本源代码相对于前一版本源代码的增量代码函数清单。然后通过分析过程，确定与增量代码函数清单相关联的目标代码路径。接着在规划过程，从测试案例库中确定针对目标代码路径的历史测试案例，以作为待测应用的回归测试案例。

在软件生命周期中的任何一个阶段，只要软件发生改变，就可能给该软件带来问题。回归测试用于在软件发生更新、修改之后，对其进行重新测试，以确保所实施的更改不会对现有代码产生不利的影响。回归测试是软件测试中的一个十分重要且成本昂贵的过程，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行得更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。如何减少回归测试成本，提高回归测试效率，具有十分重要的意义。因此，通过规划正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的。

为了帮助测试人员制定回归测试策略，避免因回归测试用例覆盖不足导致程序缺陷，同时降低低价值回归测试用例本的投入，提高回归测试效率及有效性，本公开提出了一种回归测试规划方法和装置，请参阅图1。

图1示意性示出了根据本公开实施例的可以应用回归测试规划方法和装置的示例性系统架构。需要注意的是，图1所示仅为可以应用本公开实施例的系统架构的示例，以帮助本领域技术人员理解本公开的技术内容，但并不意味着本公开实施例不可以用于其他设备、系统、环境或场景。

如图1所示，根据该实施例的系统架构可以包括测试终端110、多个应用服务器120、回归测试规划系统130和代码仓库服务器140。

测试终端110为测试人员所使用的用于访问待测应用的服务器的电子设备，包括但不限于手机、平板电脑、PC电脑等。多个应用服务器120分别为针对各种应用的服务器，在确定待测应用后，可以将该待测应用的服务器作为被测对象。回归测试规划系统130在各种测试场景下生成测试案例，以使测试人员根据测试案例来进行具体的测试操作。代码仓库服务器140用于存储各个应用的各个版本的代码。

示例性地，测试终端110上可以部署测试终端代理模块111，针对待测应用的应用服务器120上可以部署待测应用代理模块121，回归测试规划系统130上可以部署测试案例库131、路径分析模块132和回归测试规划模块133。根据本公开实施例的回归测试规划方法可以由上述测试终端代理模块111、待测应用代理模块121、测试案例库131、路径分析模块132和回归测试规划模块133相互配合实现。

应该理解，图1中的测试终端、应用服务器、回归测试规划系统和代码仓库服务器的数目和类型仅仅是示意性的。根据实际需要，可以具有任意数目和类型的测试终端、应用服务器、回归测试规划系统和代码仓库服务器。

根据本公开的实施例，提供了一种回归测试规划方法。下面结合附图进行示例性说明。应注意，以下方法中各个操作的序号仅作为该操作的表示以便描述，而不应被看作表示该各个操作的执行顺序。除非明确指出，否则该方法不需要完全按照所示顺序来执行。

图2示意性示出了根据本公开实施例的回归测试规划方法的流程图，该方法例如可以由如图1所示的回归测试规划系统130执行。

如图2所示，该回归测试规划方法可以包括操作S201～S204。

在操作S201，从代码仓库中获取待测应用的当前版本源代码和前一版本源代码。

示例性地，代码仓库可以为上文图1所示的代码仓库服务器140。

在操作S202，比较当前版本源代码和前一版本源代码，以确定当前版本源代码相对于前一版本源代码的增量代码函数清单。

示例性地，当前版本源代码相对于前一版本源代码的增量代码函数清单可以表征当前版本源代码相对于前一版本源代码所发生的代码变化。后续在回归测试时需要针对待测应用中与该代码变化相关的功能进行测试，而对于与该代码变化无关的功能无需进行测试。本操作S202例如可以由图1所示的路径分析模块132实施。

在操作S203，确定与增量代码函数清单相关联的目标代码路径。

示例性地，与增量代码函数清单相关联的目标代码路径表征与上述代码变化相关联的各个函数的调用路径，可以统称为目标代码路径。例如，待测应用包括功能A、功能B和功能C，待测应用的当前版本相对于前一版本的变化为针对功能A进行了代码变化。在本操作S203中，首先可以确定与功能A相关的函数调用路径为目标代码路径。此外，由于功能B的执行过程会调用功能A，故功能A的代码变化可能影响到功能B，故将功能B中涉及到功能A的函数调用路径也作为目标代码路径。由于功能C的执行过程与功能A和B均无关，因此功能C的函数调用路径不属于目标代码路径。本操作S203例如可以由图1所示的路径分析模块132实施。可以理解，目标代码路径中既可以包括增量代码路径也可以包括与增量代码函数清单相关联的存量代码路径。

在操作S204，从测试案例库中确定针对目标代码路径的历史测试案例，以作为待测应用的回归测试案例。

示例性地，测试案例库例如为图1所示的测试案例库131，可以包括多个历史测试案例。在确定目标代码路径后，可以从测试案例库中找到与目标代码路径相匹配的历史测试案例，以生成针对待测应用的当前版本的回归测试案例。测试人员可以根据该回归测试案例对待测应用的服务器进行测试，从而实现仅针对与代码变化相关的函数调用路径的回归测试。本操作S204例如可以由图1所示的回归测试规划模块133实施。

本领域技术人员可以理解，根据本公开实施例的回归测试规划方法通过比较待测应用的新旧版本的代码确定增量代码函数清单，进而确定可能会受到增量代码函数清单影响的目标代码路径。结合测试案例库中的历史测试案例及目标代码路径，得到需要进行回归测试的测试案例清单，从而完成回归测试规划工作。上述过程将回归测试的测试范围从待测应用的全部代码路径整体缩小定位至仅与代码变化相关联的目标代码路径，既可以避免回归测试用例覆盖不足的问题，同时还可以降低低价值回归测试用例本的投入。能够有效提高回归测试效率及有效性。

根据本公开的实施例，上述操作S203确定与增量代码函数清单相关联的目标代码路径的过程可以包括：利用深度优先搜索(Depth First Search，DFS)算法，对待测应用的当前版本源代码进行遍历，以确定当前版本源代码中多个函数各自的执行路径。然后，基于增量代码函数清单，从上述多个函数中筛选出新增函数的执行路径、以及与新增函数存在调用关系的存量函数的执行路径。接着，由上述新增函数的执行路径和存量函数的执行路径，构成目标代码路径。

下面参考图3～图4对上述操作S202～S203的实施过程进行示例性说明。

图3示意性示出了根据本公开实施例的图1中的路径分析模块132的示例结构图。

如图3所示，路径分析模块132可以包括新旧版本对比子模块1321和DFS分析子模块1322。新旧版本对比子模块1321从代码仓库服务器140获取待测应用的当前版本源代码和前一版本源代码并对比分析出当前版本增量代码。DFS分析子模块1322对增量代码进行路径分析，获取与增量代码相关量的目标代码路径，并发送到回归测试规划模块133。

示例性地，新旧版本对比子模块1321用于对代码进行分析，以获取当前版本的增量代码函数清单。DFS分析子模块1322利用深度优先搜索算法，获得增量代码涉及函数及其关联的存量函数的执行路径，以作为目标代码路径。DFS分析子模块1322利用深度优先搜索算法进行搜索的过程例如可以按照如下方式实施。

首先维护一个栈列表和已访问节点列表。从初始函数开始，进行深度优先遍历(DFS)，将当前函数所调用的其他不在已访问节点列表的函数依次加入栈，直到没有其他调用函数时，再将当前函数出栈加入已访问节点。以此类推，直到遍历所有函数为止。此时输出已访问节点列表，即为所有函数的逆拓扑排序，请参考图4。

图4示意性示出了根据本公开实施例的代码路径的示例示意图。如图4所示，F1、F2、F4存在循环调用，在进行DFS时，依次向栈中加入F1、F2、F3。根据DFS算法，F3出栈加入已访问节点列表，随后F4进栈，由于F4调用的F1已在栈中，所以不再重复加入。F4、F2、F1依次出栈，进入已访问节点列表，最终生成的逆拓扑排序为：F3、F4、F2、F1。

在确定所有函数的逆拓扑排序后，从终止函数出发，根据调用函数的逆拓扑排序，构造函数逆向调用链，只将与当前函数相连且排序在当前函数后的函数加入调用链。以图4进行举例说明，虽存在F4调用F1的路径，但由于逆拓扑排序中F4排名比F1靠前，因此不加入调用链，由此保证不会陷入循环调用。在图4所示的例子中，基于上述逆拓扑排序生成的逆向调用链包括：{F3，F2，F1}、{F4，F2，F1}和{F3，F1}。

接着，将包含指定函数的逆向调用链转为正常顺序，以作为目标代码路径，用于后续测试执行。其中指定函数为增量代码函数清单中的函数。此外，还将未加入调用链的函数调用关系进行记录，以供后续单独进行测试。

根据本公开的实施例，图1所示的回归测试规划模块133在从路径分析模块132获取目标代码路径后，从测试案例库131中查找与目标代码路径相匹配的历史测试案例，由该相匹配的历史测试案例作为回归测试案例。

为进一步理解基于测试案例库和目标代码路径来生成回归测试案例的原理，需要对测试案例库的的构建过程进行说明。根据本公开实施例的回归测试规划方法在执行操作S201获取针对待测应用的历史测试案例之前，还可以与部署于测试终端110上的测试终端代理模块111以及部署于待测应用的应用服务器120上的待测应用代理模块121相互配合，以构造测试案例库中的历史测试案例。

示例性地，测试终端代理模块111可以响应于测试人员针对待测应用中的指定业务功能的测试操作，在针对指定业务功能的业务请求中添加针对指定业务功能的业务场景标签，以得到标记业务请求。然后将标记业务请求发送至待测应用的服务器，由服务器中的待测应用代理模块121基于标记业务请求进行函数执行过程，并构造由业务场景标签和函数执行过程所涉及的代码调用分支构成的历史测试案例。

例如，上述由服务器基于标记业务请求进行函数执行过程，并构造由业务场景标签和函数执行过程所涉及的代码调用分支构成的历史测试案例可以按照如下方式实施。对标记业务请求进行解析，以得到业务请求和业务场景标签。对待测应用的编译后代码进行插桩操作，以跟踪针对业务请求的函数执行过程，从而确定函数执行过程所涉及的代码调用分支。接着，为代码调用分支添加业务场景标签，以得到一个历史测试案例。

下面参考图5～图6对测试案例库中的历史测试案例的特征以及形成过程进行示例性说明。

图5示意性示出了根据本公开实施例的图1中的测试终端代理模块111的示例结构图。

如图5所示，测试终端代理模块111可以由流量捕获子模块1111和流量标记子模块1112两部分构成。测试人员开始进行某业务场景或测试用例的测试工作时，流量捕获子模块1111可以拦截测试终端期望发送的业务流量，业务流量包括多个业务请求。流量标记子模块1112根据测试人员定义的业务场景标签对业务请求的报文进行标记后，由测试终端110将标记完成的流量继续发送至待测应用的服务器120。

示例性地，流量捕获子模块1111的主要作用为将测试终端上送应用服务器的网络数据包进行截获、编辑与转发。基于流量代理引擎实时捕获所有测试终端的业务流量，将收集到的信息送入流量标记子模块1112做进一步处理。流量标记子模块1112的作用为标记业务流量。在功能测试的过程中，当测试人员开始针对某一业务场景开展测试时，可对测试流量进行自定义标记，流量标记子模块1112将测试人员标记的业务场景信息添加到流量捕获模块拦截的请求报文头中，以实现业务场景标签的标记过程。从而将一系列业务请求处理为带有业务场景标签的标记业务请求。

图6示意性示出了根据本公开实施例的图1中的待测应用代理模块121的示例结构图。

如图6所示，待测应用代理模块121可以由插桩子模块1211、桩点数据采集子模块1212及数据发送子模块1213三部分构成。插桩子模块1211实时获取标记业务请求后进行解析处理，获取请求信息及请求标记的业务场景标签，并在代码调用链入口和出口处进行插桩处理。插桩技术是指在保证原有程序逻辑完整性的基础上，在程序中插入探针，通过探针采集代码中的信息(函数本身、函数参数值、返回值等)在特定的位置插入代码段，从而收集程序运行时的动态上下文信息。桩点数据采集子模块1212实时获取代码执行流(也可称为“代码调用分支”)，并针对代码执行流标记业务场景标签。数据发送子模块1213对采集到的数据进行预处理以得到历史测试案例，并发送到测试案例库131。

示例性地，插桩子模块1211的主要作用是对业务流量解析后获取请求对应的对象，将提取请求信息与业务流量标记。并对应用程序编译后代码进行插桩，可在应用服务器启动后，通过附加进程的方式，将插桩工具加载入应用进程，挂载关键函数。插桩程序运行后，会通过虚拟机工具接口，在字节码加载时，对应用服务器中函数做hook(钩子)操作，加入自定义的代码，以便跟踪获取业务流量在被测应用服务器120对应的函数执行情况。桩点数据采集子模块1212可以利用已经插入的桩点，实时获取应用服务器的代码执行流，并在执行流中标记对应的业务场景标签。数据发送子模块1213的主要作是对采集到的带有业务场景标签的代码执行流数据进行预处理以得到历史测试案例，并按照标准化协议发送到测试案例库131。

基于上述各实施例，可以理解，每个历史测试案例可以由具有映射关系的业务场景标签和代码调用分支构成。在待测应用代理模块121向测试案例库131发送历史测试案例后，回归测试规划系统130可以获取针对待测应用的历史测试案例，并将历史测试案例添加存储至测试案例库中。

在此基础上，示例性地，根据本公开实施例的回归测试规划方法中的操作S204从测试案例库中确定针对目标代码路径的历史测试案例的过程可以按照如下方式实施：从测试案例库中查找与目标代码路径相匹配的历史测试案例，由该相匹配的历史测试案例作为回归测试案例，并由回归测试案例中的业务场景标签来指示回归测试案例的业务场景。

进一步地，在确定回归测试案例之后，根据本公开实施例的回归测试规划方法还可以包括：在得到待测应用的回归测试案例之后，基于回归测试案例中的业务场景标签，对待测应用的服务器进行回归测试。

下面再结合一个具体实施例来对根据本公开实施例的回归测试规划方法进行示例性说明，请参阅图7。

图7示意性示出了根据本公开另一实施例的回归测试规划方法的示例流程图。

如图7所示，在开始执行之后，在操作S701，将测试终端代理模块与待测应用代理模块分别部署于测试环境中，例如分别将二者相应的程序按照图1所示的部署方式进行部署。

在操作S702，响应于测试人员在测试环境中进行的功能测试操作，由测试终端代理模块捕获业务流量。并在操作S703，对业务流量标记业务场景标签后发送至待测应用的服务器。上述流量捕获过程和流量标记过程已经在上文中说明，在此不再赘述。

在操作S704，由待测应用代理模块实时获取服务器对应的代码执行流，即代码调用分支信息。

在操作S705，分析采集到的代码调用分支信息，并与相应的业务流量的业务场景标签进行映射，对代码调用分支标记业务场景标签，以形成历史测试案例。

在操作S706，在测试案例库中，存储历史测试案例，包括业务场景及对应的代码调用分支。

上述操作S704～S706的实施方式在上文中介绍待测应用代理模块121的实施例中已说明，在此不再展开赘述。

在操作S707，从代码仓库中获取待测应用的源代码。

在操作S708，通过新旧版本差异对比分析，获得增量代码函数清单。

在操作S709，以增量代码函数清单为基础，通过深度优先遍历算法分析，获得新增代码函数及涉及的存量代码函数的全量函数调用路径，即目标代码路径。

在操作S710，通过测试案例库与目标代码路径映射分析，得到新增版本回归测试场景，从而确定回归测试案例。

上述操作S707～S710的实施方式在上文中介绍回归测试规划系统130的实施例中已说明，在此不再展开赘述。

可以理解，本公开提出一种基于函数调用链深度优先遍历的回归测试规划方法。该方案通过函数调用链及流量标记技术构建一个清晰透明的测试用例库，实现测试用例与代码的映射关系，并通过对增量代码深度优先遍历分析，自动规划出能够全面覆盖增量程序及程序分支的回归测试策略。根据本公开各实施例的回归测试方法及装置可以应用于金融领域及其他相关领域的软件回归测试场景，通过将回归测试的测试范围从待测应用的全部代码路径整体缩小定位至仅与代码变化相关联的目标代码路径，既可以避免回归测试用例覆盖不足的问题，同时还可以降低低价值回归测试用例本的投入，从而能够有效提高回归测试效率及有效性。

图8示意性示出了根据本公开实施例的回归测试规划装置的框图，可以应用于如图1所示的回归测试规划系统130。

如图8所示，该回归测试规划装置800可以包括：获取模块810、比对模块820、分析模块830和规划模块840。

获取模块810用于从代码仓库中获取待测应用的当前版本源代码和前一版本源代码。

比对模块820用于比较当前版本源代码和前一版本源代码，以确定当前版本源代码相对于前一版本源代码的增量代码函数清单。

分析模块830用于确定与增量代码函数清单相关联的目标代码路径。

规划模块840用于从测试案例库中确定针对目标代码路径的历史测试案例，以作为待测应用的回归测试案例。

需要说明的是，装置部分实施例中各模块/单元/子单元等的实施方式、解决的技术问题、实现的功能、以及达到的技术效果分别与方法部分实施例中各对应的步骤的实施方式、解决的技术问题、实现的功能、以及达到的技术效果相同或类似，在此不再赘述。

根据本公开的实施例的模块、子模块、单元、子单元中的任意多个、或其中任意多个的至少部分功能可以在一个模块中实现。根据本公开实施例的模块、子模块、单元、子单元中的任意一个或多个可以被拆分成多个模块来实现。根据本公开实施例的模块、子模块、单元、子单元中的任意一个或多个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上系统、基板上的系统、封装上的系统、专用集成电路(ASIC)，或可以通过对电路进行集成或封装的任何其他的合理方式的硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，根据本公开实施例的模块、子模块、单元、子单元中的一个或多个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

例如，获取模块810、比对模块820、分析模块830和规划模块840中的任意多个可以合并在一个模块中实现，或者其中的任意一个模块可以被拆分成多个模块。或者，这些模块中的一个或多个模块的至少部分功能可以与其他模块的至少部分功能相结合，并在一个模块中实现。根据本公开的实施例，获取模块810、比对模块820、分析模块830和规划模块840中的至少一个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上系统、基板上的系统、封装上的系统、专用集成电路(ASIC)，或可以通过对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，获取模块810、比对模块820、分析模块830和规划模块840中的至少一个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

图9示意性示出了根据本公开实施例的适于实现上文描述的方法的计算机系统的框图。图9示出的计算机系统仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图9所示，根据本公开实施例的计算机系统900包括处理器901，其可以根据存储在只读存储器(ROM)902中的程序或者从存储部分908加载到随机访问存储器(RAM)903中的程序而执行各种适当的动作和处理。处理器901例如可以包括通用微处理器(例如CPU)、指令集处理器和/或相关芯片组和/或专用微处理器(例如，专用集成电路(ASIC))，等等。处理器901还可以包括用于缓存用途的板载存储器。处理器901可以包括用于执行根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。

在RAM 903中，存储有系统900操作所需的各种程序和数据。处理器901、ROM 902以及RAM 903通过总线904彼此相连。处理器901通过执行ROM 902和/或RAM 903中的程序来执行根据本公开实施例的方法流程的各种操作。需要注意，所述程序也可以存储在除ROM 902和RAM 903以外的一个或多个存储器中。处理器901也可以通过执行存储在所述一个或多个存储器中的程序来执行根据本公开实施例的方法流程的各种操作。

根据本公开的实施例，系统900还可以包括输入/输出(I/O)接口905，输入/输出(I/O)接口905也连接至总线904。系统900还可以包括连接至I/O接口905的以下部件中的一项或多项：包括键盘、鼠标等的输入部分906；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分907；包括硬盘等的存储部分908；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分909。通信部分909经由诸如因特网的网络执行通信处理。驱动器910也根据需要连接至I/O接口905。可拆卸介质911，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器910上，以便于从其上读出的计算机程序根据需要被安装入存储部分908。

根据本公开的实施例，根据本公开实施例的方法流程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读存储介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分909从网络上被下载和安装，和/或从可拆卸介质911被安装。在该计算机程序被处理器901执行时，执行本公开实施例的系统中限定的上述功能。根据本公开的实施例，上文描述的系统、设备、装置、模块、单元等可以通过计算机程序模块来实现。

本公开还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的设备/装置/系统中所包含的；也可以是单独存在，而未装配入该设备/装置/系统中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的方法。

附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

本领域技术人员可以理解，尽管已经参照本公开的特定示例性实施例示出并描述了本公开，但是本领域技术人员应该理解，在不背离所附权利要求及其等同物限定的本公开的精神和范围的情况下，可以对本公开进行形式和细节上的多种改变。因此，本公开的范围不应该限于上述实施例，而是应该不仅由所附权利要求来进行确定，还由所附权利要求的等同物来进行限定。

Claims (8)

1.一种回归测试规划方法，包括：

从代码仓库中获取待测应用的当前版本源代码和前一版本源代码；

比较所述当前版本源代码和所述前一版本源代码，以确定所述当前版本源代码相对于所述前一版本源代码的增量代码函数清单；

确定与所述增量代码函数清单相关联的目标代码路径；以及

从测试案例库中确定针对所述目标代码路径的历史测试案例，以作为所述待测应用的回归测试案例；

获取针对所述待测应用的历史测试案例，每个历史测试案例包括：业务场景标签和代码调用分支；以及

将所述历史测试案例添加存储至测试案例库中；

在所述获取针对所述待测应用的历史测试案例之前，响应于针对待测应用中的指定业务功能的测试操作，在针对所述指定业务功能的业务请求中添加针对所述指定业务功能的业务场景标签，以得到标记业务请求；以及

将所述标记业务请求发送至待测应用的服务器，由所述服务器基于所述标记业务请求进行函数执行过程，并构造由所述业务场景标签和所述函数执行过程所涉及的代码调用分支构成的历史测试案例；

其中，所述由所述服务器基于所述标记业务请求进行函数执行过程，并构造由所述业务场景标签和所述函数执行过程所涉及的代码调用分支构成的历史测试案例包括：

由所述服务器执行如下操作：

对所述标记业务请求进行解析，以得到所述业务请求和所述业务场景标签；

对待测应用的编译后代码进行插桩操作，以跟踪针对所述业务请求的函数执行过程，从而确定所述函数执行过程所涉及的代码调用分支；以及

为所述代码调用分支添加所述业务场景标签，以得到一个历史测试案例。

2.根据权利要求1所述的方法，其中，所述确定与所述增量代码函数清单相关联的目标代码路径包括：

利用深度优先搜索算法，对所述当前版本源代码进行遍历，以确定所述当前版本源代码中多个函数各自的执行路径；

基于增量代码函数清单，从所述多个函数中筛选出新增函数的执行路径、以及与所述新增函数存在调用关系的存量函数的执行路径；以及

由所述新增函数的执行路径和所述存量函数的执行路径，构成所述目标代码路径。

3.根据权利要求1所述的方法，其中，所述从测试案例库中确定针对所述目标代码路径的历史测试案例包括：

从所述测试案例库中查找与所述目标代码路径相匹配的历史测试案例，由所述相匹配的历史测试案例作为所述回归测试案例，并由所述回归测试案例中的业务场景标签来指示所述回归测试案例的业务场景。

4.根据权利要求1所述的方法，其中，所述在针对所述指定业务功能的业务请求中添加针对所述指定业务功能的业务场景标签包括：

拦截所述业务请求；以及

在所述业务请求的报文头中添加所述业务场景标签。

5.根据权利要求1所述的方法，还包括：

在得到所述待测应用的回归测试案例之后，基于所述回归测试案例中的业务场景标签，对待测应用的服务器进行回归测试。

6.一种回归测试规划装置，包括：

获取模块，用于从代码仓库中获取待测应用的当前版本源代码和前一版本源代码；

比对模块，用于比较所述当前版本源代码和所述前一版本源代码，以确定所述当前版本源代码相对于所述前一版本源代码的增量代码函数清单；

分析模块，用于确定与所述增量代码函数清单相关联的目标代码路径；以及

规划模块，用于从测试案例库中确定针对所述目标代码路径的历史测试案例，以作为所述待测应用的回归测试案例；

其中，获取针对所述待测应用的历史测试案例，每个历史测试案例包括：业务场景标签和代码调用分支；以及

将所述历史测试案例添加存储至测试案例库中；

在所述获取针对所述待测应用的历史测试案例之前，响应于针对待测应用中的指定业务功能的测试操作，在针对所述指定业务功能的业务请求中添加针对所述指定业务功能的业务场景标签，以得到标记业务请求；以及

将所述标记业务请求发送至待测应用的服务器，由所述服务器基于所述标记业务请求进行函数执行过程，并构造由所述业务场景标签和所述函数执行过程所涉及的代码调用分支构成的历史测试案例；

其中，所述由所述服务器基于所述标记业务请求进行函数执行过程，并构造由所述业务场景标签和所述函数执行过程所涉及的代码调用分支构成的历史测试案例包括：

由所述服务器执行如下操作：

对所述标记业务请求进行解析，以得到所述业务请求和所述业务场景标签；

对待测应用的编译后代码进行插桩操作，以跟踪针对所述业务请求的函数执行过程，从而确定所述函数执行过程所涉及的代码调用分支；以及

为所述代码调用分支添加所述业务场景标签，以得到一个历史测试案例。

7.一种计算机系统，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时用于实现如权利要求1～5任一项所述的方法。

8.一种计算机可读存储介质，存储有计算机可执行指令，所述指令在被执行时用于实现如权利要求1～5任一项所述的方法。