基于代码变更的服务化接口测试方法、系统与流程

本申请涉及自动化测试技术领域，尤其涉及基于代码变更的服务化接口测试方法、系统。

背景技术：

在互联网技术普及并快速发展的今天，往往通过综合性研发测试平台全天24小时提供项目环境，并在此基础上进行高效率的项目产品研发及测试，以加快产品发布。

上述研发测试平台在实际应用中，在项目研发及版本更新过程时，往往存在大量代码变更，其中涉及了服务化接口的代码变更，而服务化接口(特别是底层的服务化接口)的变更可能会对一个或多个对外服务造成影响，这些均应划入测试范围内；因此，在进行测试前，测试人员需要先通过自行判断或者通过与研发人员进行沟通来确定各个服务化接口的变更信息，并确定各个变更的服务化接口的影响范围，进而根据该影响范围确定测试范围，从而可以更加测试范围准确选择对应的测试用例进行测试。而在人工确定测试范围的过程中，极有可能由于人为的疏忽导致所确定的变更服务或测试范围不够精准，进而导致测试遗漏。

因此，亟需一种可以自动并精准定位变更服务及测试范围的方案，以节省测试时间、提高测试效率及测试完整度。

技术实现要素：

为克服相关技术中存在的问题，本申请提供一种基于代码变更的服务化接口测试方法、系统。

本申请第一方面，提供一种基于代码变更的服务化接口测试方法，包括：

基于测试环境获取测试对象的当前版本分支信息；

比较所述当前版本分支信息与历史版本分支信息，得到各个分支的代码变更文本信息；

解析所述代码变更文本信息得到变更接口信息，并从所述变更接口信息中筛选出变更服务化接口信息；

根据所述变更服务化接口信息执行筛选数据库中已覆盖测试用例和添加未覆盖测试用例两种操作中的至少一种。

结合第一方面，在第一方面第一种可行的实施方式中，所述方法还包括：

在筛选出变更服务化接口信息之后，根据代码依赖关系，确定受所述变更服务化接口依赖影响的服务相关接口信息；

根据所述服务相关接口信息执行筛选数据库中已覆盖测试用例和添加未覆盖测试用例两种操作中的至少一种。

结合第一方面，或者第一方面第一种可行的实施方式，在第一方面第二种可行的实施方式中，基于测试环境获取测试对象的版本分支信息，包括：

在部署测试环境时，触发并复用覆盖率统计来获取所述版本分支信息。

结合第一方面，或者第一方面第一种可行的实施方式，在第一方面第三种可行的实施方式中，比较所述当前版本分支信息与历史版本分支信息，得到各个分支的代码变更文本信息，包括：

通过版本控制系统svn的路径比较命令对所述当前版本分支信息与历史版本分支信息进行比较，得到所述代码变更文本信息。

结合第一方面，或者第一方面第一种可行的实施方式，在第一方面第四种可行的实施方式中，所述变更接口信息至少包括变更接口名。

结合第一方面第四种可行的实施方式，在第一方面第五种可行的实施方式中，从所述变更接口信息中筛选出变更服务化接口信息，包括：

解析各个分支中提供服务的实体对象类bean的配置文件，得到各个分支中所有的服务化接口名；

通过对比所述服务化接口名和所述变更接口信息中的变更接口名，得到变更服务化接口名，并根据所述变更服务化接口名确定对应的变更服务化接口信息。

结合第一方面第四种可行的实施方式，在第一方面第六种可行的实施方式中，根据所述变更服务化接口信息执行筛选数据库中已覆盖测试用例和添加未覆盖测试用例两种操作中的至少一种，包括：

根据所述变更服务化接口信息中的变更服务化接口名获取对应的二方库仓库地址；

对于获取到所述二方库仓库地址的第一变更服务化接口名，从所述二方库仓库地址中下载所述第一变更服务化接口名对应的二方包，并解析所述二方包得到相应的已覆盖测试用例；

对于未获取到所述二方库地址的第二变更服务化接口名，添加所述第二变更服务化接口名对应的未覆盖测试用例。

本申请第二方面，提供一种基于代码变更的服务化接口测试系统，包括：

分支信息获取单元，用于基于测试环境获取测试对象的当前版本分支信息；

变更信息确定单元，用于比较所述当前版本分支信息与历史版本分支信息，得到各个分支的代码变更文本信息；

服务化变更筛选单元，用于解析所述代码变更文本信息得到变更接口信息，并从所述变更接口信息中筛选出变更服务化接口信息；

测试用例确定单元，用于根据所述变更服务化接口信息执行筛选数据库中已覆盖测试用例和添加未覆盖测试用例两种操作中的至少一种。

结合第二方面，在第二方面第一种可行的实施方式中，所述系统还包括：

相关接口确定单元，用于在所述服务化变更筛选单元筛选出变更服务化接口信息之后，根据代码依赖关系，确定受所述变更服务化接口依赖影响的服务相关接口信息；

相应的，所述测试用例确定单元还用于，根据所述服务相关接口信息执行筛选数据库中已覆盖测试用例和添加未覆盖测试用例两种操作中的至少一种。

结合第二方面，或者第二方面第一种可行的实施方式，在第二方面第二种可行的实施方式中，为实现基于测试环境获取测试对象的版本分支信息，所述分支信息获取单元具体被配置为：

在部署测试环境时，触发并复用覆盖率统计来获取所述版本分支信息。

结合第二方面，或者第二方面第一种可行的实施方式，在第二方面第三种可行的实施方式中，为得到所述代码变更文本信息，所述变更信息确定单元具体被配置为：

通过版本控制系统svn的路径比较命令对所述当前版本分支信息与历史版本分支信息进行比较，得到所述代码变更文本信息。

结合第二方面，或者第二方面第一种可行的实施方式，在第二方面第四种可行的实施方式中，所述服务化变更筛选单元解析得到的变更接口信息至少包括变更接口名。

结合第二方面第四种可行的实施方式，在第二方面第五种可行的实施方式中，为实现从所述变更接口信息中筛选出变更服务化接口信息，所述服务化变更筛选单元被配置为：

解析各个分支中提供服务的实体对象类bean的配置文件，得到各个分支中所有的服务化接口名；

通过对比所述服务化接口名和所述变更接口信息中的变更接口名，得到变更服务化接口名，并根据所述变更服务化接口名确定对应的变更服务化接口信息。

结合第二方面第四种可行的实施方式，在第二方面第六种可行的实施方式中，为实现根据所述变更服务化接口信息执行筛选数据库中已覆盖测试用例和添加未覆盖测试用例两种操作中的至少一种，所述测试用例确定单元被配置为：

根据所述变更服务化接口信息中的变更服务化接口名获取对应的二方库仓库地址；

对于获取到所述二方库仓库地址的第一变更服务化接口名，从所述二方库仓库地址中下载所述第一变更服务化接口名对应的二方包，并解析所述二方包得到相应的已覆盖测试用例；

对于未获取到所述二方库地址的第二变更服务化接口名，添加所述第二变更服务化接口名对应的未覆盖测试用例。

由以上技术方案可知，本申请实施例首先通过对比测试对象的当前版本分支信息个历史版本分支信息来确定代码变更文本信息，再通过解析该代码变更文本信息得到变更接口信息，继而从中筛选出变更服务化接口信息，根据该变更服务化接口信息即可确定测试所需的具体测试用例，进而可以通过从数据库中筛选或者直接添加得到各个测试用例。可见，本实施例中，变更服务化接口的确定过程及测试用例的获取过程完全不需要测试人员人为干预，可以通过研发测试平台中的相关软硬件执行，相对于现有技术，不仅可以减少测试人员的工作量，提高测试效率，还可以避免因认为疏忽导致的测试不完整。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。

图1是本申请实施例提供的一种基于代码变更的服务化接口测试方法的流程图。

图2是本申请实施例提供的基于代码变更的服务化接口测试方法应用于宙斯盾测试平台中的信号流图。

图3是本申请实施例提供的基于代码变更的服务化接口测试系统的结构框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本发明相一致的所有实施方式。相反，它们仅是与如 所附权利要求书中所详述的、本发明的一些方面相一致的装置和方法的例子。

图1为本申请实施例提供的一种基于代码变更的服务化接口测试方法的流程图。参照图1，该方法包括以下步骤。

s11、基于测试环境获取测试对象的版本分支信息。

s12、比较所述当前版本分支信息与历史版本分支信息，得到各个分支的代码变更文本信息。

在项目开发、更新及维护等过程中，通常将项目任务分为基于同一主干的多个分支，在主干对应的源代码确定后，对各个分支的源代码进行并行开发或变更，从而可以提高工作效率。本申请实施例中，在进行测试之前，首先获取测试对象的当前版本分支信息，通过比较代码变更后的当前版本分支信息和代码变更前的历史版本分支信息，即可得到各个分支的代码变更文本信息。

s13、解析所述代码变更文本信息得到变更接口信息，并从所述变更接口信息中筛选出变更服务化接口信息。

通过对步骤s12得到的代码变更文本信息进行解析，可以得到变更的代码类、变更的详细行信息等，进一步基于java反射原理分析变更的代码类，可以得到变更的代码类对应的变更接口信息。

本申请实施例中，上述变更接口信息至少包括变更接口的接口名，以下称变更接口名。根据变更接口信息中的变更接口名，可以判断出那个变更接口是服务化接口，从而相应的变更接口信息即为变更服务化接口信息。

可选的，上述变更接口信息还可以变更接口的方法名、方法入参信息、方法返回值信息等。

s14、根据所述变更服务化接口信息执行筛选数据库中已覆盖测试用例和添加未覆盖测试用例两种操作中的至少一种。

本实施例中，每次测试过程所使用的测试用例都可以存储在数据库中，从而在后续测试过程中，对于同一测试目标，可以直接在该数据库中获取相应的测试用例。在此基础上，在上述步骤s14中可以根据变更服务化接口信息中的变更服务化接口名获取相应的测试用例，进而通过以下两种方式获取这些测试用例：对于数据库中存储的(即在历史测试过程中使用过的)测试用例，即已覆盖测试用例，可以直接从数据库中获取；对于数据库中不存在的(即在历史测试过程中没有使用过的)测试用例，即未覆盖测试用例，则自动添加相应新的测试用例。进一步的，自动化测试平台或测试人员可以根据上述已覆盖测试用例和未覆盖测试用例对测试对象的各个服务化接口(各项服务性能)进 行测试。

由以上技术方案可知，本申请实施例首先通过对比测试对象的当前版本分支信息个历史版本分支信息来确定代码变更文本信息，再通过解析该代码变更文本信息得到变更接口信息，继而从中筛选出变更服务化接口信息，根据该变更服务化接口信息即可确定测试所需的具体测试用例，进而可以通过从数据库中筛选或者直接添加得到各个测试用例。可见，本实施例中，变更服务化接口的确定过程及测试用例的获取过程完全不需要测试人员人为干预，可以通过研发测试平台中的相关软硬件执行，相对于现有技术，不仅可以减少测试人员的工作量，提高测试效率，还可以避免因认为疏忽导致的测试不完整。

在本申请一个可行的实施例中，本申请实施例提供的基于代码变更的服务化接口测试方法还可以包括以下步骤：

s13’、在筛选出变更服务化接口信息之后，根据代码依赖关系，确定受所述变更服务化接口依赖影响的服务相关接口信息；

s14’、根据所述服务相关接口信息执行筛选数据库中已覆盖测试用例和添加未覆盖测试用例两种操作中的至少一种。

实际应用中，由于代码之间的依赖关系，某个服务化接口的代码变更，不仅会影响该服务化接口自身，还有可能影响与该服务化接口存在代码依赖关系的其他接口，这些服务相关接口都应同服务化接口一样作为测试目标进行测试。有鉴于此，本实施例在步骤s13得到变更服务化接口信息后，还可以通过上述代码依赖关系，确定与变更服务化接口相关的其他一个或多个接口信息，即上述服务相关接口信息，进而可以通过如步骤s14所述的两种方式获取各个服务相关接口的测试用例。

可见，上述服务相关接口信息的确定过程也可以完全由软件或硬件执行，不需要人为干预，既可以保证测试效率，又可以保证测试的完整度。

在本申请一个可行的实施例中，上述步骤s11具体可以为：在部署测试环境时，触发并复用覆盖率统计来获取所述版本分支信息。

在代码测试中，覆盖率是指运行测试用例过程中被执行的代码量与测试对象的总代码量之间的百分比；所述代码量的度量单位可以为代码行数、代码块个数等。例如,测试对象是一个函数,该函数共有100行代码,当测试用例执行完后,只有其中的60行代码被执行,还有40行的代码没有被执行,则该函数的代码覆盖率即为60％。实际应用中，一般通过覆盖率统计来查找被测代码中执行不到的代码，并基于此对代码进行优化(如消除bug或删除执行不到的无用代码)。

本申请实施例复用覆盖率统计步骤，以获取各个分支中被执行的代码，即上述版本 分支信息。

在本申请一个可行的实施例中，上述步骤s12具体可以为，通过版本控制系统(subversion，svn)的路径比较命令，即svndiff，对所述当前版本分支信息与历史版本分支信息进行比较，得到所述代码变更文本信息。

基于变更接口信息中的变更接口名，在本申请一个可行的实施例中，上述步骤s13所述的从所述变更接口信息中筛选出变更服务化接口信息，具体可以包括：

s131、解析各个分支中提供服务的实体对象类bean的配置文件，得到各个分支中所有的服务化接口名；

s132、通过对比所述服务化接口名和所述变更接口信息中的变更接口名，得到变更服务化接口名，并根据所述变更服务化接口名确定对应的变更服务化接口信息。

软件开发领域中，往往将可以重复使用的代码打包，以供后续直接调用，实体对象类bean即为一个无参数的可复用组件，用于定义、配置公共的数值、操作等。本实施例中，通过解析服务相关的bean配置文件，来获取bean配置文件中携带的服务化接口名，进而通过对比测试对象各个分支的所有服务化接口名(假设为集合a)和变更接口信息中的变更接口名(假设为集合b)，即取二者的交集(a∩b)，该交集中包含的接口名即为变更服务化接口名，相应的，变更服务化接口名对应的变更接口信息即为需要筛选出的变更服务化接口信息。

在本申请一个可行的实施例中，上述步骤s14所述的根据所述变更服务化接口信息执行筛选数据库中已覆盖测试用例和添加未覆盖测试用例两种操作中的至少一种，具体可以包括：

s141、根据所述变更服务化接口信息中的变更服务化接口名获取对应的二方库仓库地址；

s142、对于获取到所述二方库仓库地址的第一变更服务化接口名，从所述二方库仓库地址中下载所述第一变更服务化接口名对应的二方包，并解析所述二方包得到相应的已覆盖测试用例；

s143、对于未获取到所述二方库地址的第二变更服务化接口名，添加所述第二变更服务化接口名对应的未覆盖测试用例。

即本申请实施例中，优先在数据库中查找是否存在相应的已覆盖测试用例，如果存在，则直接从数据库中调取，如果不存在，再添加相应的未覆盖测试用例。实际应用中，数据库中以二方包的形式存储测试用例，每个二方包在数据库中存在唯一地址，通过接口名在数据库管理器等模块可以查询得到是否存在对应的仓库地址，如果查找到，说明 相应的测试用例为数据库中的已覆盖测试用例，如果查找不到，说明相应的测试用例为数据库中不存在的未覆盖测试用例。

图2为将本申请实施例应用于宙斯盾测试平台的信号流图。

宙斯盾测试平台，即aegis，简称宙斯盾是alibaba.com和aliexpress.com、cun.taobao.com三大网站所有开发和测试使用的大型综合性统一研发测试平台，涵盖了多个子系统，如图2所示，包括环境管理系统(aenv)、覆盖率中心(asura)、代码依赖中心(blade)、版本控制系统svn、服务化接口测试平台(serviceautomatedtesting，sat)、软件项目管理系统(maven)。

参照图2，基于上述子系统，宙斯盾执行基于代码变更的服务化接口测试方法的过程如下：

s1、通过aenv部署测试环境；

s1'、aenv在部署测试环境是，触发asura进行覆盖率统计；

s2、asura将覆盖率统计过程中获取到的版本分支信息转发至blade；

s3、blade将接收到的版本分支信息发送至svn，使得svn通过svndiff命令对版本分支信息进行比较；

s4、svn向blade返回比较得到的代码变更文本信息；

s5、blade解析代码变更文本信息得到变更接口信息，并从所述变更接口信息中筛选出变更服务化接口信息；

s6、blade将变更服务化接口信息发送至sat；

s7、sat根据变更服务化接口信息中的变更服务化接口获取其在maven中的二方库仓库地址；

s8、sat访问所述二方库仓库地址，请求相应的二方包；

s9、maven向sat返回相应的二方包；

s10、sat解析所述二方包得到已覆盖测试用例，并自动添加未覆盖测试用例；

上述步骤s1、s1’和s2相当于前文实施例所述的步骤s11，目的在于获取测试对象的当前版本分支信息，在宙斯盾测试平台中主要由aenv和asura两个子系统交互执行完成；上述步骤s3至s4相当于前文实施例所述的步骤s12，目的在于获取各个分支的代码变更文本信息，在宙斯盾测试平台中主要由blade和svn两个子系统交互执行完成；上述步骤s5相当于前文实施例所述的步骤s13，目的在于得到变更服务化接口信息，在宙斯盾测试平台中由子系统blade执行完成；上述步骤s7至s10相当于前文实施例所述 的步骤s14，目的在于推送出测试所需的测试用例(包括已覆盖测试用例和未覆盖测试用例)，在宙斯盾测试平台中主要由sat和maven两个子系统交互执行完成。

可见，本申请提供的基于代码变更的服务化接口测试方法应用于宙斯盾测试平台，由其相关子系统执行，确定测试代码变更的服务化接口所需的测试用例，实现全自动智能推送测试用例，进而可以通过sat根据所确定的测试用例对相应的服务化接口进行自动化测试，上述过程不需要人为干预，相对于现有的需要测试人员人工确定代码变更的服务化接口并人工选择测试用例的方式，本申请不仅可以减少测试人员的工作量，提高测试效率，还可以避免因认为疏忽导致的测试不完整。

另外，本申请实施例还提供了一种计算机存储介质，例如可以是rom、随机存取存储器(ram)、cd-rom、磁带、软盘和光数据存储设备等；该计算机存储介质中存储有程序，当所述存储介质中的程序由研发测试平台中相关子系统执行时，使得该研发测试平台能够执行上述方法实施例中记载的基于代码变更的服务化接口测试方法的部分或全部步骤。

相应于上述方法实施例，本申请实施例还提供了一种基于代码变更的服务化接口测试系统。图3为该系统的一种结构框图，具体包括：分支信息获取单元100、变更信息确定单元200、服务化变更筛选单元300和测试用例确定单元400。

其中，该分支信息获取单元100用于，基于测试环境获取测试对象的当前版本分支信息。

该变更信息确定单元200用于，比较所述当前版本分支信息与历史版本分支信息，得到各个分支的代码变更文本信息。

该服务化变更筛选单元300用于，解析所述代码变更文本信息得到变更接口信息，并从所述变更接口信息中筛选出变更服务化接口信息。

该测试用例确定单元400用于，根据所述变更服务化接口信息执行筛选数据库中已覆盖测试用例和添加未覆盖测试用例两种操作中的至少一种。

由以上装置结构可知，本申请实施例首先通过对比测试对象的当前版本分支信息个历史版本分支信息来确定代码变更文本信息，再通过解析该代码变更文本信息得到变更接口信息，继而从中筛选出变更服务化接口信息，根据该变更服务化接口信息即可确定测试所需的具体测试用例，进而可以通过从数据库中筛选或者直接添加得到各个测试用例。可见，本实施例中，变更服务化接口的确定过程及测试用例的获取过程完全不需要 测试人员人为干预，可以通过研发测试平台中的相关软硬件执行，相对于现有技术，不仅可以减少测试人员的工作量，提高测试效率，还可以避免因认为疏忽导致的测试不完整。

本申请提供的基于代码变更的服务化接口测试系统可以应用于包括上述宙斯盾测试平台在内的多种研发测试平台；具体的，当应用于宙斯盾测试平台时，上述分支信息获取单元100设置于aenv和asura两个子系统中，变更信息确定单元200设置于blade和svn两个子系统中，服务化变更筛选单元300设置于子系统blade中，测试用例确定单元400设置于sat和maven两个子系统中，其执行过程中各个子系统之间的信号流可参照图2。

在本申请一个可行的实施例中，上述基于代码变更的服务化接口测试系统还可以包括：相关接口确定单元，用于在所述服务化变更筛选单元筛选出变更服务化接口信息之后，根据代码依赖关系，确定受所述变更服务化接口依赖影响的服务相关接口信息。

基于上述相关接口确定单元，测试用例确定单元400还用于，根据所述服务相关接口信息执行筛选数据库中已覆盖测试用例和添加未覆盖测试用例两种操作中的至少一种。

可见，本申请变更服务化接口信息后，还可以通过代码依赖关系，确定与变更服务化接口相关的其他一个或多个接口信息，即上述服务相关接口信息，进而可以通过测试用例确定单元获取各个变更服务化接口和服务相关接口的测试用例，不需要人为干预，既可以保证测试效率，又可以保证测试的完整度。

在本申请一个可行的实施例中，上述分支信息获取单元具体被配置为：在部署测试环境时，触发并复用覆盖率统计来获取所述版本分支信息。

在本申请一个可行的实施例中，上述变更信息确定单元具体被配置为：通过版本控制系统svn的路径比较命令对所述当前版本分支信息与历史版本分支信息进行比较，得到所述代码变更文本信息。

在本申请一个可行的实施例中，上述所述服务化变更筛选单元解析得到的变更接口信息至少包括变更接口名。相应的，变更服务化接口信息中至少包括变更服务化接口名，基于该变更服务化接口名，上述服务化变更筛选单元可以被配置为：

解析各个分支中提供服务的实体对象类bean的配置文件，得到各个分支中所有的服务化接口名；

通过对比所述服务化接口名和所述变更接口信息中的变更接口名，得到变更服务化接口名，并根据所述变更服务化接口名确定对应的变更服务化接口信息。

同样基于变更服务化接口信息中的变更服务化接口名，测试用例确定单元可以被配置为：

根据所述变更服务化接口信息中的变更服务化接口名获取对应的二方库仓库地址；

对于获取到所述二方库仓库地址的第一变更服务化接口名，从所述二方库仓库地址中下载所述第一变更服务化接口名对应的二方包，并解析所述二方包得到相应的已覆盖测试用例；

对于未获取到所述二方库地址的第二变更服务化接口名，添加所述第二变更服务化接口名对应的未覆盖测试用例。

关于上述实施例中的测试系统，其中各个单元执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本发明的其它实施方案。本申请旨在涵盖本发明的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本发明的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本发明的真正范围和精神由下面的权利要求指出。

应当理解的是，本发明并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本发明的范围仅由所附的权利要求来限制。