CN114371866A - 业务系统的版本重构测试方法、装置和设备 - Google Patents

Abstract

本申请公开了一种业务系统的版本重构测试方法、装置和设备，涉及计算机技术领域，尤其涉及协议测试技术领域，用于提升应用版本重构后的测试效率和效果。该方法包括：以同一输入参数值分别在原始版本和重构版本的业务系统中发起目标业务；分别获取原始版本和重构版本的业务系统执行目标业务时的运行日志；对原始版本和重构版本分别对应的运行日志进行日志解析处理，获得包括业务系统执行目标业务时调用的各个协议接口信息的日志解析文件；根据设定的版本重构比对规则，将原始版本和重构版本分别对应的日志解析文件进行比对，获得比对差异结果；根据比对差异结果确定重构版本的业务系统的测试结果。

Description

业务系统的版本重构测试方法、装置和设备

技术领域

本申请涉及计算机技术领域，尤其涉及协议测试技术领域，提供一种业务系统的版本重构测试方法、装置和设备。

背景技术

为了提升用户的使用体验，后台技术人员需要不断的对业务系统进行版本重构，重构的业务系统版本需要测试通过后才能投入使用。

而目前对于重构的版本通常是进行灰度测试，即将指定的人群使用新版本的业务系统，并逐渐扩大测试的灰度，但是这种灰度测试对于受众较广且功能使用频率较高的业务系统能够有较好的测试效果，而在受众较少或者功能使用频率不是很高时，例如，针对某一城市使用的支付系统，由于一个城市的用户数量有限，且支付系统一般只有需要支付时才会使用，因而使用频率显然不高，灰度测试无法起到很好的测试效果。

因而，对于这些业务系统，通常是人工对新旧版本进行对比，但是人工测试的效率极低，且容易出错。例如对于支付系统的重构版本人工进行测试时，需要人工完成整个测试流程，人工测试的效率极低，且容易出错，并且由于支付类系统涉及到资金安全，灰度测试风险大，灰度方法无法保证重构版本支付场景完全覆盖到。

发明内容

本申请实施例提供一种业务系统的版本重构测试方法、装置和设备，用于提升版本重构后的业务系统的测试效率和效果。

一方面，提供一种业务系统的版本重构测试方法，所述方法包括：

以同一输入参数值分别在原始版本和重构版本的业务系统中发起目标业务；

分别获取所述原始版本和所述重构版本的业务系统执行所述目标业务时的运行日志；

对所述原始版本和所述重构版本分别对应的运行日志进行日志解析处理，获得包括所述业务系统执行所述目标业务时调用的各个协议接口信息的日志解析文件；

根据设定的版本重构比对规则，将所述原始版本和所述重构版本分别对应的日志解析文件进行比对，获得比对差异结果；其中，所述比对规则中设定了待比对的协议接口和协议接口参数；

根据比对差异结果确定所述重构版本的业务系统的测试结果。

一方面，提供一种业务系统的版本重构测试装置，所述装置包括：

业务发起单元，用于以同一输入参数值分别在原始版本和重构版本的业务系统中发起目标业务；

日志获取单元，用于分别获取所述原始版本和所述重构版本的业务系统执行所述目标业务时的运行日志；

日志解析单元，用于对所述原始版本和所述重构版本分别对应的运行日志进行日志解析处理，获得包括所述业务系统执行所述目标业务时调用的各个协议接口信息的日志解析文件；

比对单元，用于根据设定的版本重构比对规则，将所述原始版本和所述重构版本分别对应的日志解析文件进行比对，获得比对差异结果；其中，所述比对规则中设定了待比对的协议接口和协议接口参数；

确定单元，用于根据比对差异结果确定所述重构版本的业务系统的测试结果。

可选的，所述日志获取单元，具体用于：

根据所述原始版本的业务系统执行所述目标业务时生成的业务唯一标识，从运行日志文件中查询获取所述原始版本对应的运行日志；以及，

根据所述重构版本的业务系统执行所述目标业务时生成的业务唯一标识，从运行日志文件中查询获取所述重构版本对应的运行日志。

可选的，所述日志解析单元，具体用于：

对所述运行日志包括的日志行逐行进行日志解析处理；

根据对每一行日志的解析处理结果，将同一次协议接口调用的解析结果关联记录至日志解析文件中的同一数据块中。

可选的，所述日志解析单元，具体用于：

对所述每一日志行进行日志行有效性判断；

若有效性判断结果指示所述每一日志行为有效日志行，则对所述每一日志行进行日志类型判断；其中，有效日志行为调用协议接口执行所述目标业务相关的日志行；

根据确定的日志类型，采用与日志类型对应的解析方式对所述每一日志行进行日志解析处理。

可选的，所述日志解析单元，具体用于：

在所述每一日志行包括最后接口返回标记时，确定所述每一日志行为最后接口返回行；或者，

在所述每一日志行未包括密文请求标记或者风控请求标记时，确定所述每一日志行为明文数据日志行；或者，

在所述每一日志行包括所述风控请求标记时，确定所述每一日志行为风控接口日志行；或者，

在所述每一日志行包括所述密文请求标记时，确定所述每一日志行为密文数据日志行。

可选的，所述日志解析单元，具体用于：

根据对每一行日志的解析处理结果，获取属于同一次协议接口调用的解析结果，其中，同一次协议接口调用的解析结果包括协议接口名称、所述协议接口的请求参数信息和针对所述请求参数信息的响应参数信息；

对同一次协议接口调用的解析结果进行数据格式转换处理，以按照设定的数据格式记录解析结果，以得到所述日志解析文件。

可选的，所述装置还包括结果显示单元，用于：

根据设定的比对差异结果类别，对比对差异结果中各比对差异结果进行类别划分处理；

根据类别划分结果将比对差异结果按照划分的类别进行显示。

一方面，提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述任一种方法的步骤。

一方面，提供一种计算机存储介质，其上存储有计算机程序指令，该计算机程序指令被处理器执行时实现上述任一种方法的步骤。

一方面，提供一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述任一种方法的步骤。

本申请实施例中，分别通过两个版本的业务系统，即原始版本和重构版本的业务系统执行目标业务，并分别对不同版本的运行日志进行解析处理，得到日志解析文件，进而根据设定的版本重构比对规则自动进行比对，从而得到两个版本之间的差异，以确定重构版本是否存在错误，完成对重构版本进行测试需求，且无需人工参与协议解析和比对，降低人工参与度，提升测试效率和效果。

附图说明

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

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

图2为本申请实施例提供的测试客户端的测试架构示意图；

图3为本申请实施例提供的业务系统的版本重构测试方法的流程示意图；

图4为本申请实施例提供的发起两次支付业务的对比示意图；

图5为本申请实施例提供的每一个日志行的解析流程示意图；

图6为本申请实施例提供的日志解析文件的部分示例图；

图7为本申请实施例提供的日志解析文件的另一部分示例图；

图8为本申请实施例提供的比对规则的示例图；

图9为本申请实施例提供的参数或者协议的选择界面示意图；

图10为本申请实施例提供的比对差异结果显示示意图；

图11为本申请实施例提供的业务系统的版本重构测试装置的一种结构示意图；

图12为本申请实施例提供的计算机设备的一种结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚明白，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

为便于理解本申请实施例提供的技术方案，这里先对本申请实施例使用的一些关键名词进行解释：

版本重构：或称为版本更新，业务系统的版本重构可以包括业务系统前台和后台的更新，例如可以包括业务系统后台的协议重构，或者其他方面的版本重构。

协议：业务执行接口调用时涉及的协议接口调用约束规则，不同的协议接口调用用于实现不同的功能。例如对于一个支付系统而言，后台在进行支付业务的处理时可涉及明文传输相关的明文协议、密文传输相关的密文协议、风控相关的风控协议和前置机协议等。协议接口信息可以包括调用的协议接口名称、协议中涉及的一个或者多个参数以及各个参数名称和参数值等信息。

比对规则：本申请实施例中，是指针对版本重构对比测试设置的比对规则，对于待测试的业务系统，根据测试需求设置需要比对的协议和各个协议涉及的参数。例如对于支付业务系统，通常涉及到支付协议相关的接口和风控协议相关的接口，支付接口需要比对的参数例如可以包括：支付用户名、支付金额、收款方和支付金额等，风控接口需要比对的参数例如可以包括：系统余额、支付额度和用户身份信息(身份证，住址等)等。

相关技术中，在受众较少或者功能使用频率不是很高时，例如，针对某一城市使用的支付系统，由于一个城市的用户数量有限，且支付系统一般只有需要支付时才会使用，因而使用频率显然不高，对于这些业务系统灰度测试无法起到很好的测试效果。

以支付系统为例，版本重构时一般要求保证新版本的执行逻辑与旧版本一致，并且不存在资金不一致的问题。而相关技术中对于支付系统的重构版本人工进行测试时，需要人工完成整个测试流程，即需要通过人工获取两次操作日志，人工过滤选择合法的协议内容解密，再人工检查参数，人工测试的效率极低，且容易出错，手工测试完成后还需要再进行灰度测试，并且由于支付类系统涉及到资金安全，灰度测试风险大，灰度方法无法保证重构版本支付场景完全覆盖到。

鉴于此，本申请实施例提供一种业务系统的版本重构测试方法，在该方法中，分别通过两个版本的业务系统，即原始版本和重构版本的业务系统执行目标业务，并分别对不同版本的运行日志进行解析处理，得到日志解析文件，进而根据设定的版本重构比对规则自动进行比对，从而得到两个版本之间的差异，以确定重构版本是否存在错误，完成对重构版本进行测试需求，且无需人工参与协议解析和比对，降低人工参与度，提升测试效率和效果。

此外，本申请实施例中，可以对需要进行比对的协议和参数进行设置，进而后续在比对时，仅会对设定的协议和采纳数进行比对，进而测试人员可以根据测试需求进行设定，提升对比测试的灵活性。

在介绍完本申请实施例的设计思想之后，下面对本申请实施例的技术方案能够适用的应用场景做一些简单介绍，需要说明的是，以下介绍的应用场景仅用于说明本申请实施例而非限定。在具体实施过程中，可以根据实际需要灵活地应用本申请实施例提供的技术方案。

本申请实施例提供的方案可以适用于大多数版本重构后的测试场景中，如图1所示，为本申请实施例提供的一种应用场景示意图，在该场景中，可以包括终端设备101、服务器102、测试设备103和数据库104。

终端设备101和测试设备103可以是平板电脑(PAD)、手机、笔记本电脑或者个人计算机(Personal Computer，PC)等设备，当然，也可以为其他可能的设备，本发明实施例对此不做限制。终端设备101上安装有被测业务系统的客户端，可以从客户端上发起目标业务。具体的，原始版本的业务系统和重构版本的业务系统可以分别对应有客户端，那么可以从两个版本对应的客户端发起目标业务，且两个版本的业务输入参数保持一致。

测试设备103上可以安装测试客户端。在实际应用中，为了方便测试，终端设备101上的客户端可以通过测试设备103控制自动发起业务，即测试设备103测试开始后，则可以自动控制客户端发起目标业务。当然，终端设备101和测试设备103亦可以设置为同一设备，那么可通过测试客户端调用原始版本和重构版本分别执行同一业务，例如业务系统为支付系统时，则可以调用不同版本的支付应用发起相同金额的支付，以便后续进行比对。

测试设备103可以包括一个或多个处理器、存储器、与服务器102和终端设备101交互的I/O接口、显示面板等。其中，测试设备103的存储器中可以存储本申请实施例提供的对比方法的程序指令，这些程序指令被处理器执行时能够用以实现本申请实施例提供的业务系统的版本重构测试方法的步骤，以对业务系统进行新旧版本的对比测试。

服务器102可以为业务系统的后台服务器，在发起业务时，相应的，则会向服务器102发起业务请求，服务器102则可以实现相应的业务，并返回业务响应。同时，业务系统在执行目标业务时会同步产生运行日志，例如服务器102为实现目标业务，需要执行目标业务的业务逻辑，即需要调用业务涉及的协议接口实现整个流程，其生成的日志可存储至数据库104中，则后续测试终端101上测试客户端则可以根据业务唯一标识，例如针对支付业务的支付订单号，从数据库104中获取相应的运行日志，进而对运行日志进行解析，得到日志解析文件，从而根据日志解析文件对两个版本进行比对，以确定新版本与旧版本的逻辑是否一致，以及执行结果是否一致等，最终确定新版本是否存在错误(Bug)。

在一种可能的实施方式中，测试设备103上安装的测试客户端可以实现测试人员的可视化交互，而测试逻辑可部署于服务器上，利用服务器的计算资源实现测试逻辑，即测试人员可通过测试客户端远程发起测试，使得服务器上部署的测试工具开始测试，即，从数据库104中获取相应的运行日志，进而对运行日志进行解析，得到日志解析文件，从而根据日志解析文件对两个版本进行比对，以确定新版本与旧版本的逻辑是否一致，以及执行结果是否一致等，而测试客户端可以同步显示测试过程，如日志解析过程和最终结果显示等。

上述的各个设备之间可以通过一个或者多个网络进行直接或间接的通信连接。该网络可以是有线网络，也可以是无线网络，例如无线网络可以是移动蜂窝网络，或者可以是无线保真(Wireless-Fidelity，WIFI)网络，当然还可以是其他可能的网络，本申请实施例对此不做限制。

当然，本申请实施例提供的方法并不限用于图1所示的应用场景中，还可以用于其他可能的应用场景，本申请实施例并不进行限制。对于图1所示的应用场景的各个设备所能实现的功能将在后续的方法实施例中一并进行描述，在此先不过多赘述。

在介绍测试方法流程之前，首先对本申请实施例提供的测试客户端的架构进行介绍。如图2所示，为测试客户端的测试架构示意图，在该架构中，主要包括如下的几个模块：

(1)日志分析器

日志分析器为测试方案的核心，为测试工具的驱动引擎，用于协调其他的模块实现日志抓取、协议解析和比对等工作，例如调用工具模块的工具实现工具相应的功能。

(2)工具模块

工具模块包括测试过程中涉及的多个工具，各个工具被日志分析器调用以实现相应的功能。例如，工具模块可以包括远程控制工具、加密/解密工具、格式转换工具和比对工具，当然，也可以包括其他可能的工具，本申请实施例对此不做限制。

远程控制工具可以辅助实现远程控制功能，例如可以为安全外壳协议(SecureShell Protocol，SSH Client)工具。

加密/解密工具(Encrypt Manager)用于对待传输的内容进行加密和解密，在本申请实施例中，主要用于在进行日志解析时对密文日志行进行解密。

格式转换(convert)工具用于将解析得到日志数据设定的格式进行存储，例如可以按照JSON(Java Script Object Notation)格式进行存储，JSON是一种轻量的数据表示方法，采用key-value的方式记录数据，更为直观简洁。

比对工具(Compare Manager)用于在日志解析文件的比对阶段，对两个版本的日志解析文件按照设定比对规则进行比对。

(3)比对规则和结果存储模块

比对规则和结果存储模块用于存储设定的比对规则，和存储比对完成后得到的比对结果集合。

(4)日志解析数据模块

日志解析数据模块用于存储解析得到的日志解析文件，日志解析文件按照设定的日志解析结构(LogModule)进行存储，每一日志解析文件包括多个日志解析条目(LogItem)。

请参见图3，为本申请实施例提供的业务系统的版本重构测试方法的流程示意图，该方法可以通过图1中的测试设备103来执行，该方法的流程介绍如下。

步骤301：以同一输入参数值分别在原始版本和重构版本的业务系统中发起目标业务。

本申请实施例中，为了方便对新旧两个版本的业务系统进行对比，可以将两次业务发起时输入的参数保持一致。例如，对于支付系统，则可以使得两次业务发起时的收款方、支付金额和支付方式等信息保持一致，这样，后续直接根据解析得到的参数数据是否一致，则可以确定新版本是否有故障。

如图4所示，为以支付系统为例，在前台发起两次支付业务的对比示意图。其中，两次支付的发起方式可以一致，如都可以是扫码支付或者转账付款等方式，且在支付页面输入的支付相关的参数也是一致，如图4所示在原始版本和重构版本的支付页面的收款方、支付金额和支付方式都是相同的。

步骤302：分别获取原始版本和重构版本的业务系统执行目标业务时的运行日志。

通常来讲，对于每一次业务执行，都会对应有业务唯一标识，因而可以根据业务唯一标识从运行日志文件中查询获取相应的运行日志。

具体的，根据原始版本的业务系统执行目标业务时生成的业务唯一标识，从业务系统的运行日志文件中查询获取原始版本对应的运行日志；以及，根据重构版本的业务系统执行目标业务时生成的业务唯一标识，从业务系统的运行日志文件中查询获取重构版本对应的运行日志。

例如，以支付系统为例，每一次的支付都可以认为是一个支付订单，在系统中可以对应一个支付订单号，支付订单号相当于每一次支付的染色体，可以区别发起的不同支付订单，进而可以根据支付订单号从运行日志文件中查询获取该支付订单号相关的所有运行日志。

或者，通常来讲用户发起的每一次请求都对应着唯一的请求标识(message_number，MSG_NO)，因而也可以将MSG_NO作为本次执行业务的业务唯一标识，进而根据MSG_NO从运行日志文件中查询获取该MSG_NO相关的所有运行日志。

具体的，在进行运行日志查询时，可以调用日志查询工具进行查询，如grep(Globally search a Regular Expression and Print)工具，grep是一种强大的文本搜索工具，它能使用特定模式匹配搜索文本，例如：正则表达式，并默认输出匹配行，当然，也可以采用其他的搜索工具进行查询，本申请实施例对此不做限制。

步骤303：对原始版本和重构版本分别对应的运行日志进行日志解析处理，获得包括业务系统执行目标业务时调用的各个协议接口信息的日志解析文件。

本申请实施例中，由于对于原始版本和重构版本分别对应的运行日志的日志解析处理过程是类似的，因此下面以一个运行日志的解析处理过程为例进行介绍。

针对一个运行日志，对运行日志进行日志解析处理，获得日志解析文件时，可以逐行解析运行日志包括的日志行，并根据对每一行日志的解析结果，将同一次协议接口调用的解析结果关联记录至日志解析文件中的同一数据块中。

在逐行对运行日志包括的日志行进行解析处理时，可以针对每一日志行，对每一日志行进行日志行有效性判断，确定每一日志行是否为有效日志行，如果为有效日志行，则对该日志行进行解析处理，如果不是有效日志行，则丢弃该日志行。其中，有效日志行为调用协议接口执行目标业务相关的日志行，例如对于支付系统而言，有效日志行则可以为支付业务强相关的日志行，如支付强相关的协议有关的日志行，而一些调试日志行等则可以认为是与业务无关的日志行，则可以丢弃不进行解析。

具体在进行日志行有效性判断时，可以根据日志行中包括的关键字进行判断。例如对于支付系统而言，有效日志行通常为支付协议相关的日志行，而这些日志行中通常包括“request”或者“response”等这些关键字，因而可以将包括这些关键字的日志行确定为有效日志行。

针对每一有效日志行，不同的日志类型通常涉及不同的业务协议，各业务协议需要收集的数据不同，且各业务协议的处理方式不同，例如密文协议需要先进行解密才可进行解析，因此可以先判断该日志行的日志类型，进而按照确定的日志类型所对应的解析方式进行解析处理。

日志类型可以包括如下的日志类型的一种或者多种：

(1)最后接口返回行，为执行目标业务调用接口调用的最终返回行，携带业务执行结果。

(2)明文数据日志行，为明文数据协议调用相关的日志行。

(3)风控接口日志行，为风控协议调用相关的日志行。

(4)密文数据日志行，为密文数据协议调用相关的日志行。

当然，日志类型和各日志类型对应的解析方式可以根据实际需求进行合理的设置。

通常而言，不同的日志类型，在日志行中通常包括对应的类型标记，因此对于每一有效日志行，判断该日志行的日志类型时，可以根据日志行中包括的具体信息进行判断。

具体的，在每一日志行包括最后接口返回标记时，确定每一日志行为最后接口返回行；在每一日志行未包括密文请求标记或者风控请求标记时，确定每一日志行为明文数据日志行；在每一日志行包括风控请求标记时，确定每一日志行为风控接口日志行；在每一日志行包括密文请求标记时，确定每一日志行为密文数据日志行。

本申请实施例中，在进行日志解析时，对于日志的判断还可以按照一定的顺序执行，例如最后接口返回行和明文数据日志行的解析工作量相对于密文数据日志行的解析工作量而言是更小的，因此可以将最后接口返回行和明文数据日志行的解析过程设置的靠前一些，这样，对于测试人员而言，在对比测试开始之后，可以很快速的感知到结果的输出。

如图5所示，为一个日志行的解析流程示意图，图5为一个日志行为例，通过如下的过程进行解析处理。

S501：对日志行进行日志行有效性判断。

即判断当前处理的日志行是否为有效日志行，若当前处理的日志行为有效日志行，则继续后续的处理流程，若不是，则丢弃当前日志行，并跳转至下一日志行进行处理。

S502：若该日志行为有效日志行，则对该日志行进行最后接口返回行判断。

若当前处理的日志行为有效日志行，则确定该日志行是否为最后接口返回行，若当前处理的日志行是最后接口返回行，则可以对该日志行进行最后接口返回行解析处理，即按照最后接口返回行对应的解析规则对该日志行进行解析处理。

对于各个日志类型的判断在前已经进行了介绍。因此在此不再进行赘述。

S503：若该日志行为最后接口返回行，则对该日志行进行最后接口返回行解析处理。

S504：若该日志行并非最后接口返回行，则对该日志行进行明文数据日志行判断。

若当前处理的日志行并非最后接口返回行，则继续后续的处理流程，即判断该日志行是否为明文数据日志行。

S505：若该日志行为明文数据日志行，对该日志行进行明文数据日志行解析处理。

若当前处理的日志行是明文数据日志行，则可以对该日志行进行明文数据日志行解析处理，即按照明文数据日志行对应的解析规则对该日志行进行解析处理。

S506：若该日志行并非明文数据日志行，则对该日志行进行风控接口日志行判断。

若当前处理的日志行并非明文数据日志行，则继续后续的处理流程，即判断该日志行是否为风控接口日志行。

S507：若该日志行为风控接口日志行，对该日志行进行风控接口日志行解析处理。

若当前处理的日志行是风控接口日志行，则可以对该日志行进行风控接口日志行解析处理，即按照风控接口日志行对应的解析规则对该日志行进行解析。

S508：若该日志行并非风控接口日志行，则对该日志行进行密文数据日志行判断。

若当前处理的日志行并非风控接口日志行，则继续后续的处理流程，即判断该日志行是否为密文数据日志行。

S509：若该日志行为密文数据日志行，对该日志行进行密文数据日志行解析处理。

若当前处理的日志行是密文数据日志行，则可以对该日志行进行密文数据日志行解析处理，即按照密文数据日志行对应的解析规则对该日志行进行解析。例如对密文数据日志行进行解析时，需要先调用加密/解密工具对日志行进行解密，然后然对日志行的数据进行解析处理。

通过上述的解析过程对每一有效日志行进行解析处理之后，则可以得到各个日志行的解析结果，为了方便进行对比分析，可以将同一次协议接口调用的解析结果关联记录至日志解析文件中的同一数据块中，其中，同一次协议接口调用的解析结果包括协议接口名称、协议接口的请求参数信息和协议接口的响应参数信息，针对解析结果，可以调用格式转换工具对解析结果进行数据格式转换处理，以按照设定的数据格式记录解析结果，以得到日志解析文件。

如图6所示，为得到的日志解析文件的部分示例图。如图6所示，“5550886289685852931366578314668”即为执行目标业务时的业务唯一标识，即MSG_NO，“ia_sitg_wx_deal_server”为执行目标业务的业务系统的工程名称，可对应原始版本或者重构版本的业务系统，“ia_sitg_wx_efast_pay_c”指示目标业务为支付业务。“overview”部分为协议接口调用总览，即在执行目标业务时所调用的协议接口名称和顺序。

如图7所示，为得到的日志解析文件的另一部分示例图。图7具体以JSON格式存储日志解析结果为例，展示了一次协议接口调用的数据块的示例。其中，“ia_b2c_orderquery_service”为调用的协议接口名称，后续的两个大括号内的内容分别对应该协议接口调用时的协议请求数据和协议返回数据，这两部分数据采用JSON格式存储，如协议请求数据中“"MSG_NO"："5550886289685852931366578314668M"”表示"MSG_NO"为“5550886289685852931366578314668M”，表达更为简洁清楚，方便后续存在问题时测试人员进行核查。

步骤304：根据设定的版本重构比对规则，将所述原始版本和所述重构版本分别对应的日志解析文件进行比对，获得比对差异结果。

本申请实施例中，比对规则中设定了需要比对的协议接口和协议接口参数对运行日志解析完成后，则可以根据设定的比对规则对两个版本的日志解析文件进行比对，比对规则中设定了需要比对的协议接口和协议接口参数。

具体的，在进行测试之前，测试人员可以根据本次的测试需求设置比对规则，或者选择默认的比对规则，或者设置比对规则的路径等，从而测试客户端可以获取比对规则。比对规则为根据需要测试的目标业务涉及的协议配置的参数集合，在进行测试时候，可以对比对规则中的比对项目进行增加或者删除。

如图8所示，为一种比对规则的示例图。其中，比对规则为包括了多个比对项目的集合，针对一条比对项目“fill_anlyze_key("uin")\”即指示对参数“uin”进行比对，当然，除了参数之外，也可以设置需要比对的协议。

在具体应用时，为了方便测试人员设置比对规则，还可以对目标业务中的协议进行识别，进而向测试人员展示涉及的所有协议和参数，图9所示，为参数或者协议的选择界面示意图，进而测试人员可以通过界面获知目标业务涉及的所有协议和各个协议的参数，可以在测试进行前勾选本次需求比对的协议或者参数，以得到比对规则。

在将原始版本对应的日志解析文件与重构版本对应的日志解析文件进行比对之后，则可以得到这两个日志解析文件之间的比对差异结果。

步骤305：根据比对差异结果确定重构版本的业务系统的测试结果。

本申请实施例中，根据得到的比对差异结果则可以更新后的重构版本的测试报告，测试报告能够指示重构版本的测试结果。

具体的，比对差异结果指示原始版本和重构版本无差异时，则更新后的重构版本与原始版本的执行逻辑和执行结果是完全一致的，因而重构版本的测试通过。

具体的，为了方便进行结果展示，使得测试人员可以直观的获知测试结果，可以根据设定的比对差异结果类别，将比对差异结果中各比对差异结果划分至对应的类别中，进而按照类别显示比对差异结果。

如图10所示，为本申请实施例提供的比对差异结果显示示意图。其中，图10所示的显示界面包括协议名称缺失(lack)/多出(more)、协议参数缺失/多出和比对成功(success)/失败(failure)这几个分类，当然，在实际应用中，可以根据实际需求进行差异结果的分类，本申请实施例对此不做限制。下面针对每个分类分别进行介绍。

(1)协议名称缺失

协议名称缺失部分指示了原始版本和重构版本在执行目标业务时重构版本中缺少了某个协议接口的调用。例如，原始版本的协议接口调用顺序为协议接口A、协议接口B和协议接口C，而重构版本的协议接口调用顺序为协议接口A和协议接口C，则缺少了协议接口B的调用。

如图10中所示，协议名称缺失的示例“compare differe：service lack：ia_ui_verify_paypwd_service”，则指示在目标业务执行时，重构版本相较原始版本缺少了“ia_ui_verify_paypwd_service”接口的调用。

(2)协议名称多出

协议名称多出部分指示了原始版本和重构版本在执行目标业务时重构版本中多出了某个协议接口的调用。例如，原始版本的协议接口调用顺序为协议接口A、协议接口B和协议接口C，而重构版本的协议接口调用顺序为协议接口A、协议接口B、协议接口B和协议接口C，则多出了一次协议接口B的调用。

如图10中所示，协议名称多出的示例“compare differe：service more：ia_card_encrpt_service”，则指示在目标业务执行时，重构版本相较原始版本多出了“ia_card_encrpt_service”接口的调用；示例“compare differe：service more：ia_card_encrpt_service”，则指示在目标业务执行时，重构版本相较原始版本多出了“ia_card_encrpt_service”接口的调用；示例“compare differe：service more：ia_prom_qry_prizeinfo_v2_c”，则指示在目标业务执行时，重构版本相较原始版本多出了“ia_prom_qry_prizeinfo_v2_c”接口的调用。

(3)协议参数缺失

协议参数缺失部分指示了原始版本和重构版本在执行目标业务时，重构版本与原始版本的接口调用一致，但是重构版本缺失了某个协议参数。

如图10中所示，协议名称多出的示例“compare differe：9001lack:fun＝0”，则指示在目标业务执行时，重构版本在调用9001对应的协议接口时缺少了“fun”参数。

(4)协议参数多出

协议参数多出部分指示了原始版本和重构版本在执行目标业务时，重构版本与原始版本的接口调用一致，但是重构版本多出了某个协议参数。

如图10中所示，协议名称多出的示例“compare differe：9001more:bank_total_fee＝”，则指示在目标业务执行时，重构版本在调用9001对应的协议接口时多出了“bank_total_fee”参数。

(5)比对成功

比对成功部分指示了原始版本和重构版本在执行目标业务时，重构版本与原始版本调用的某个协议接口一致，协议参数一致，且协议参数值一致，那么该条协议接口调用比对成功。

如图10中所示，比对成功的示例“compare Success：ia_ui_query_bankacc_service”，则指示原始版本和重构版本调用“ia_ui_query_bankacc_service”接口信息完全一致。

(6)比对失败

比对失败部分指示了原始版本和重构版本在执行目标业务时，重构版本与原始版本调用的某个协议接口按照比对规则进行比对后，存在错误，即某个协议接口均调用了，协议参数也一致，但是协议参数值不一致，对于参数值的不同，应属于较为严重的错误，尤其在支付系统中，参数值通常涉及收款方、支付金额等等信息，参数值不同可能导致某项信息不一致，会给用户带来资金风险，用户的使用体验也会很差。

如图10中所示，比对失败的示例“compare Failure：ia_ui_query_mer_service:left is cur_tape＝344，right is cur_tape＝840”，则指示原始版本和重构版本调用“ia_ui_query_mer_service”接口时，原始版本的“cur_tape＝344”，而重构版本的“cur_tape＝840”，虽然均调用了该接口，且参数均存在，但是参数值不一致；而“compareFailure：ia_ui_query_mer_service:left is spid＝4220,spid is cur_tape＝3200”，则指示原始版本和重构版本调用“ia_ui_query_mer_service”接口时，原始版本的“spid＝4220”，而重构版本的“cur_tape＝3200”，虽然均调用了该接口，且参数均存在，但是参数值不一致。

进而通过测试报告可以很清楚的分析出应用重构前后的协议调用，无需人工干预操作，保证协议参数完整性一致性，极大提高了测试效率。

综上所述，本申请实施例的测试方案无需人工干预，快速高效的完成重构版本测试，后续的提测非重构版本，也可以借助于此方案，实时解析生成调用的协议顺序表和所有协议出参入参，快速的发现错误，提高测试效率，为编写自动化提供了完整的参数请求示例。

请参见图11，基于同一发明构思，本申请实施例还提供了一种业务系统的版本重构测试装置110，该装置包括：

业务发起单元1101，用于以同一输入参数值分别在原始版本和重构版本的业务系统中发起目标业务；

日志获取单元1102，用于分别获取原始版本和重构版本的业务系统执行目标业务时的运行日志；

日志解析单元1103，用于对原始版本和重构版本分别对应的运行日志进行日志解析处理，获得包括业务系统执行目标业务时调用的各个协议接口信息的日志解析文件；

比对单元1104，用于根据设定的版本重构比对规则，将原始版本和重构版本分别对应的日志解析文件进行比对，获得比对差异结果；其中，比对规则中设定了待比对的协议接口和协议接口参数；

确定单元1105，用于根据比对差异结果确定重构版本的业务系统的测试结果。

可选的，日志获取单元1102，具体用于：

根据原始版本的业务系统执行目标业务时生成的业务唯一标识，从运行日志文件中查询获取原始版本对应的运行日志；以及，

根据重构版本的业务系统执行目标业务时生成的业务唯一标识，从运行日志文件中查询获取重构版本对应的运行日志。

可选的，日志解析单元1103，具体用于：

对运行日志包括的日志行逐行进行日志解析处理；

根据对每一行日志的解析处理结果，将同一次协议接口调用的解析结果关联记录至日志解析文件中的同一数据块中。

可选的，日志解析单元1103，具体用于：

对每一日志行进行日志行有效性判断；

若有效性判断结果指示每一日志行为有效日志行，则对每一日志行进行日志类型判断；其中，有效日志行为调用协议接口执行目标业务相关的日志行；

根据确定的日志类型，采用与日志类型对应的解析方式对每一日志行进行日志解析处理。

可选的，日志解析单元1103，具体用于：

在每一日志行包括最后接口返回标记时，确定每一日志行为最后接口返回行；或者，

在每一日志行未包括密文请求标记或者风控请求标记时，确定每一日志行为明文数据日志行；或者，

在每一日志行包括风控请求标记时，确定每一日志行为风控接口日志行；或者，

在每一日志行包括密文请求标记时，确定每一日志行为密文数据日志行。

可选的，日志解析单元1103，具体用于：

根据对每一行日志的解析处理结果，获取属于同一次协议接口调用的解析结果，其中，同一次协议接口调用的解析结果包括协议接口名称、协议接口的请求参数信息和针对请求参数信息的响应参数信息；

对同一次协议接口调用的解析结果进行数据格式转换处理，以按照设定的数据格式记录解析结果，以得到日志解析文件。

可选的，该装置还包括结果显示单元1106，用于：

根据设定的比对差异结果类别，对比对差异结果中各比对差异结果进行类别划分处理；

根据类别划分结果将比对差异结果按照划分的类别进行显示。

该装置可以用于执行图3～图10所示的实施例中所示的方法，因此，对于该装置的各功能模块所能够实现的功能等可参考图3～图10所示的实施例的描述，不多赘述。

请参见图12，基于同一技术构思，本申请实施例还提供了一种计算机设备120，可以包括存储器1201和处理器1202。

所述存储器1201，用于存储处理器1202执行的计算机程序。存储器1201可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序等；存储数据区可存储根据计算机设备的使用所创建的数据等。处理器1202，可以是一个中央处理单元(central processing unit，CPU)，或者为数字处理单元等等。本申请实施例中不限定上述存储器1201和处理器1202之间的具体连接介质。本申请实施例在图12中以存储器1201和处理器1202之间通过总线1203连接，总线1203在图12中以粗线表示，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。所述总线1203可以分为地址总线、数据总线、控制总线等。为便于表示，图12中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器1201可以是易失性存储器(volatile memory)，例如随机存取存储器(random-access memory，RAM)；存储器1201也可以是非易失性存储器(non-volatilememory)，例如只读存储器，快闪存储器(flash memory)，硬盘(hard disk drive，HDD)或固态硬盘(solid-state drive，SSD)、或者存储器1201是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器1201可以是上述存储器的组合。

处理器1202，用于调用所述存储器1201中存储的计算机程序时执行如图3～图10所示的实施例中设备所执行的方法。

在一些可能的实施方式中，本申请提供的方法的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在计算机设备上运行时，所述程序代码用于使所述计算机设备执行本说明书上述描述的根据本申请各种示例性实施方式的方法中的步骤，例如，所述计算机设备可以执行如图3～图10所示的实施例中设备所执行的方法。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

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

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

Claims (10)

1.一种业务系统的版本重构测试方法，其特征在于，所述方法包括：

以同一输入参数值分别在原始版本和重构版本的业务系统中发起目标业务；

分别获取所述原始版本和所述重构版本的业务系统执行所述目标业务时的运行日志；

对所述原始版本和所述重构版本分别对应的运行日志进行日志解析处理，获得包括所述业务系统执行所述目标业务时调用的各个协议接口信息的日志解析文件；

根据设定的版本重构比对规则，将所述原始版本和所述重构版本分别对应的日志解析文件进行比对，获得比对差异结果；其中，所述比对规则中设定了待比对的协议接口和协议接口参数；

根据比对差异结果确定所述重构版本的业务系统的测试结果。

2.如权利要求1所述的方法，其特征在于，分别获取所述原始版本和所述重构版本的业务系统执行所述目标业务时的运行日志，包括：

根据所述原始版本的业务系统执行所述目标业务时生成的业务唯一标识，从运行日志文件中查询获取所述原始版本对应的运行日志；以及，

根据所述重构版本的业务系统执行所述目标业务时生成的业务唯一标识，从运行日志文件中查询获取所述重构版本对应的运行日志。

3.如权利要求1所述的方法，其特征在于，针对一个运行日志，对运行日志进行日志解析处理，获得包括所述业务系统执行所述目标业务时调用的各个协议接口信息的日志解析文件，具体包括：

对所述运行日志包括的日志行逐行进行日志解析处理；

根据对每一行日志的解析处理结果，将同一次协议接口调用的解析结果关联记录至日志解析文件中的同一数据块中。

4.如权利要求3所述的方法，其特征在于，针对运行日志中的每一日志行，对所述每一日志行进行日志解析处理时，具体包括：

对所述每一日志行进行日志行有效性判断；

若有效性判断结果指示所述每一日志行为有效日志行，则对所述每一日志行进行日志类型判断；其中，有效日志行为调用协议接口执行所述目标业务相关的日志行；

根据确定的日志类型，采用与日志类型对应的解析方式对所述每一日志行进行日志解析处理。

5.如权利要求4所述的方法，其特征在于，对所述每一日志行进行日志类型判断，具体包括：

在所述每一日志行包括最后接口返回标记时，确定所述每一日志行为最后接口返回行；或者，

在所述每一日志行未包括密文请求标记或者风控请求标记时，确定所述每一日志行为明文数据日志行；或者，

在所述每一日志行包括所述风控请求标记时，确定所述每一日志行为风控接口日志行；或者，

在所述每一日志行包括所述密文请求标记时，确定所述每一日志行为密文数据日志行。

6.如权利要求3所述的方法，其特征在于，根据对每一行日志的解析处理结果，将同一次协议接口调用的解析结果关联记录至日志解析文件中的同一数据块中，包括：

根据对每一行日志的解析处理结果，获取属于同一次协议接口调用的解析结果，其中，同一次协议接口调用的解析结果包括协议接口名称、所述协议接口的请求参数信息和针对所述请求参数信息的响应参数信息；

对同一次协议接口调用的解析结果进行数据格式转换处理，以按照设定的数据格式记录解析结果，以得到所述日志解析文件。

7.如权利要求1所述的方法，其特征在于，在根据设定的版本重构比对规则，将所述原始版本和所述重构版本分别对应的日志解析文件进行比对，获得比对差异结果之后，所述方法还包括：

根据设定的比对差异结果类别，对比对差异结果中各比对差异结果进行类别划分处理；

根据类别划分结果将比对差异结果按照划分的类别进行显示。

8.一种业务系统的版本重构测试装置，其特征在于，所述装置包括：

业务发起单元，用于以同一输入参数值分别在原始版本和重构版本的业务系统中发起目标业务；

日志获取单元，用于分别获取所述原始版本和所述重构版本的业务系统执行所述目标业务时的运行日志；

日志解析单元，用于对所述原始版本和所述重构版本分别对应的运行日志进行日志解析处理，获得包括所述业务系统执行所述目标业务时调用的各个协议接口信息的日志解析文件；

比对单元，用于根据设定的版本重构比对规则，将所述原始版本和所述重构版本分别对应的日志解析文件进行比对，获得比对差异结果；其中，所述比对规则中设定了待比对的协议接口和协议接口参数；

确定单元，用于根据比对差异结果确定所述重构版本的业务系统的测试结果。

9.一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，

所述处理器执行所述计算机程序时实现权利要求1至7任一项所述方法的步骤。

10.一种计算机存储介质，其上存储有计算机程序指令，其特征在于，

该计算机程序指令被处理器执行时实现权利要求1至7任一项所述方法的步骤。

Images