系统测试方法、装置和服务器

技术领域

本说明书属于大数据技术领域，尤其涉及系统测试方法、装置和服务器。

背景技术

一些大型机构(例如，银行、购物网站等)的业务请求处理系统每天都需要接收并处理海量的业务请求。

目前，随着主机应用架构的转型和处理要求的提升，许多请求处理系统正逐步由原来的基于集中式部署的主机系统改造为基于分布式部署的平台系统。通常对于改造后的业务请求处理系统还需要进行大量的系统测试，以保证改造后的业务请求处理系统稳定、有效。

但是，基于现有的系统测试方法在对改造后的业务请求处理系统进行测试时往往存在测试过程复杂繁琐，测试效率低、测试效果差的技术问题。

针对上述问题，目前尚未提出有效的解决方案。

发明内容

本说明书提供了一种系统测试方法、装置和服务器，可以高效且有针对性地完成对改造后的第二请求处理系统的功能性测试，准确地确定出第二请求处理系统是否符合相应的功能性要求，获得较好的测试效果。

本说明书实施例提供了一种系统测试方法，包括：

获取历史请求日志，并从所述历史请求日志中提取出多个历史联机接口请求报文；

调用预设的请求处理模型基于预设的筛选规则，处理所述多个历史联机接口请求报文，以筛选出符合要求的测试请求；其中，所述测试请求符合目标应用场景的覆盖度要求和典型性要求；

利用所述测试请求，测试第一请求处理系统，得到第一反馈结果；其中，所述第一请求处理系统为基于集中式部署的负责处理联机接口请求的主机系统；

切换第二请求处理系统，并利用所述测试请求，测试所述第二请求处理系统，得到第二反馈结果；其中，所述第二请求处理系统为改造第一请求处理系统所得到的基于分布式部署的负责处理联机接口请求的平台系统；

根据第一反馈结果和第二反馈结果，确定第二请求处理系统是否符合功能性要求。

在一些实施例中，预设的请求处理模型包括基于XGBoost算法训练得到的模型。

在一些实施例中，所述预设的筛选规则包括以下至少之一：交易业务参数、交易量统计参数、交易场景参数、请求地区参数。

在一些实施例中，所述交易业务参数包括：对公交易明细查询业务和/或对个人交易明细查询业务。

在一些实施例中，所述交易场景参数包括以下至少之一：手机银行场景、网银场景、柜面场景、自助终端场景。

在一些实施例中，利用所述测试请求，测试第一请求处理系统，得到第一反馈结果，包括：

调用模拟请求测试工具根据所述测试请求，模拟下游设备向第一请求处理系统发送相应的数据处理请求，并采集第一请求处理系统基于所述数据处理请求生成的处理结果，作为所述第一反馈结果。

在一些实施例中，根据第一反馈结果和第二反馈结果，确定第二请求处理系统是否符合功能性要求，包括：

比较第一反馈结果和第二反馈结果，确定反馈结果的差异值；

检测所述反馈结果的差异值是否小于预设的差异阈值；

在确定所述反馈结果的差异值小于预设的差异阈值的情况下，确定所述第二请求处理系统符合功能性要求。

在一些实施例中，在检测所述反馈结果的差异值是否小于预设的差异阈值之后，所述方法还包括：

在确定所述反馈结果的差异值大于等于预设的差异阈值的情况下，确定所述第二请求处理系统不符合功能性要求；

相应的，根据反馈结果的差异值，从所述第二反馈结果中确定出异常反馈结果；

根据所述异常反馈结果，定位出第二请求处理系统中的异常接口；并对所述异常接口进行修复处理。

在一些实施例中，所述方法还包括：

获取异常请求特征；

根据所述异常请求特征和所述测试请求，构造异常请求；

利用所述异常请求，测试所述第二请求处理系统，得到第三反馈结果；

根据所述第三反馈结果，确定第二请求处理系统是否符合安全性要求。

在一些实施例中，所述异常请求特征包括以下至少之一：特殊符号、恶意代码、SQL指令、非法字典值、空值、超长值。

本说明书实施例还提供了一种系统测试装置，包括：

获取模块，用于获取历史请求日志，并从所述历史请求日志中提取出多个历史联机接口请求报文；

调用模块，用于调用预设的请求处理模型基于预设的筛选规则，处理所述多个历史联机接口请求报文，以筛选出符合要求的测试请求；其中，所述测试请求符合目标应用场景的覆盖度要求和典型性要求；

第一测试模块，用于利用所述测试请求，测试第一请求处理系统，得到第一反馈结果；其中，所述第一请求处理系统为基于集中式部署的负责处理联机接口请求的主机系统；

第二测试模块，用于切换第二请求处理系统，并利用所述测试请求，测试所述第二请求处理系统，得到第二反馈结果；其中，所述第二请求处理系统为改造第一请求处理系统所得到的基于分布式部署的负责处理联机接口请求的平台系统；

确定模块，用于根据第一反馈结果和第二反馈结果，确定第二请求处理系统是否符合功能性要求。

本说明书实施例还提供了一种服务器，包括处理器以及用于存储处理器可执行指令的存储器，所述处理器执行所述指令时实现以下内容：获取历史请求日志，并从所述历史请求日志中提取出多个历史联机接口请求报文；调用预设的请求处理模型基于预设的筛选规则，处理所述多个历史联机接口请求报文，以筛选出符合要求的测试请求；其中，所述测试请求符合目标应用场景的覆盖度要求和典型性要求；利用所述测试请求，测试第一请求处理系统，得到第一反馈结果；其中，所述第一请求处理系统为基于集中式部署的负责处理联机接口请求的主机系统；切换第二请求处理系统，并利用所述测试请求，测试所述第二请求处理系统，得到第二反馈结果；其中，所述第二请求处理系统为改造第一请求处理系统所得到的基于分布式部署的负责处理联机接口请求的平台系统；根据第一反馈结果和第二反馈结果，确定第二请求处理系统是否符合功能性要求。

本说明书实施例还提供了一种计算机可读存储介质，其上存储有计算机指令，所述指令被执行时实现：获取历史请求日志，并从所述历史请求日志中提取出多个历史联机接口请求报文；调用预设的请求处理模型基于预设的筛选规则，处理所述多个历史联机接口请求报文，以筛选出符合要求的测试请求；其中，所述测试请求符合目标应用场景的覆盖度要求和典型性要求；利用所述测试请求，测试第一请求处理系统，得到第一反馈结果；其中，所述第一请求处理系统为基于集中式部署的负责处理联机接口请求的主机系统；切换第二请求处理系统，并利用所述测试请求，测试所述第二请求处理系统，得到第二反馈结果；其中，所述第二请求处理系统为改造第一请求处理系统所得到的基于分布式部署的负责处理联机接口请求的平台系统；根据第一反馈结果和第二反馈结果，确定第二请求处理系统是否符合功能性要求。

本说明书提供的一种系统测试方法、装置和服务器，可以先获取历史请求日志，并提取出多个历史联机接口请求报文；再调用预设的请求处理模型基于预设的筛选规则，通过处理多个历史联机接口请求报文，以筛选出符合目标应用场景的覆盖度要求和典型性要求的测试请求；接着，可以利用测试请求，测试第一请求处理系统，得到第一反馈结果；其中，第一请求处理系统为基于集中式部署的负责处理联机接口请求的主机系统；再切换第二请求处理系统，并利用测试请求，测试第二请求处理系统，得到第二反馈结果；其中，第二请求处理系统为基于分布式部署的负责处理联机接口请求的平台系统；根据第一反馈结果和第二反馈结果，确定第二请求处理系统是否符合功能性要求，从而可以高效且有针对性地完成对改造后的第二请求处理系统的相关测试，准确地确定出第二请求处理系统是否符合功能性要求，获得较好的测试效果。

附图说明

为了更清楚地说明本说明书实施例，下面将对实施例中所需要使用的附图作简单地介绍，下面描述中的附图仅仅是本说明书中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是应用本说明书实施例提供的系统测试方法的系统结构组成的一个实施例的示意图；

图2是本说明书的一个实施例提供的系统测试方法的流程示意图；

图3是本说明书的一个实施例提供的服务器的结构组成示意图；

图4是本说明书的一个实施例提供的系统测试装置的结构组成示意图；

图5是在一个场景示例中，应用本说明书实施例提供的系统测试方法的一种实施例的示意图；

图6是在一个场景示例中，应用本说明书实施例提供的系统测试方法的一种实施例的示意图；

图7是在一个场景示例中，应用本说明书实施例提供的系统测试方法的一种实施例的示意图。

具体实施方式

为了使本技术领域的人员更好地理解本说明书中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本说明书一部分实施例，而不是全部的实施例。基于本说明书中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本说明书保护的范围。

本说明书实施例提供一种系统测试方法，所述系统测试方法具体可以应用于包含有多个测试服务器的测试系统中。具体可以参阅图1所示，多个测试服务器可以通过有线或无线的方式相连，以进行具体的数据交互。

在本实施例中，所述测试服务器具体可以包括一种应用于某银行的数据中心的测试系统一侧，能够实现数据传输、数据处理等功能的后台服务器。具体的，所述测试服务器例如可以为一个具有数据运算、存储功能以及网络交互功能的电子设备。或者，所述测试服务器也可以为运行于该电子设备中，为数据处理、存储和网络交互提供支持的软件程序。在本实施例中，并不具体限定所述测试服务器所包含的服务器数量。所述测试服务器具体可以为一个服务器，也可以为几个服务器，或者，由若干服务器形成的服务器集群。

在本实施例中，在对原本负责接收并处理某银行的业务数据处理请求的第一请求处理系统的接口进行相应改造，得到新的第二请求处理系统之后，需要先对第二请求处理系统进行相应的测试，以确定第二请求处理系统是否符合功能性要求：能够较好地代替第一请求处理系统准确地完成主要的数据处理。

在本实施例中，第一测试服务器对接第一请求处理系统。其中，上述第一请求处理系统具体可以理解为改造前的负责接收并处理该银行的业务数据处理请求(例如，账户余额查询请求、交易明细查询请求、转账交易请求等)的系统。具体的，上述第一请求处理系统可以是一种基于集中式部署的负责处理联机接口请求的主机系统。基于该系统，主机系统可以通过多个改造前的联机接口与多个业务应用关联。

具体实施时，第一测试服务器可以通过访问第一请求处理系统，获取预设时间段(例如，最近1个月)的历史请求日志。其中，该历史请求日志中具体可以记载有该预设时间段内该银行所涉及到的海量交易数据的交易日期、交易时间、全息监控链路信息、请求编号、联机接口请求报文等相关数据。进一步，第一测试服务器可以从该历史请求日志中提取出得到多个历史联机接口请求报文；并将上述多个历史联机接口请求报文发送至第二测试服务器。

其中，第二测试服务器可以部署有预先训练好的预设的请求处理模型。上述预设的请求处理模型具体可以理解为一种预先基于XGBoost算法训练得到能够基于相应的预设的筛选规则，从多个历史联机接口请求报文中筛选出同时符合目标应用场景的覆盖度要求和典型性要求的测试请求的识别模型。

上述预设的筛选规则具体可以是一种记载有用作预设的请求处理模型的筛选依据的特征参数的规则数据。具体的，上述预设的筛选规则可以是通过对历史数据进行学习所得到的，也可以是用户自定义生成的。其中，上述预设的筛选规则具体可以包含有以下的特征参数：交易业务参数(例如，对公交易明细查询业务、对个人交易明细查询业务等)、交易量统计参数(例如，一天的交易总额等)、交易场景参数(例如，手机银行场景、网银场景、柜面场景、自助终端场景等)、请求地区参数(例如，甲城、乙市、丙区等)。

具体实施时，第二测试服务器可以将多个历史联机接口请求报文输入至预设的请求处理模型中，并运行该预设的请求处理模型。预设的请求处理模型具体运行时，可以识别出历史联机接口请求报文中的关键字段，并根据预设的筛选规则中所记载的特征参数，进行关键字段的匹配；从而可以从多个历史联机接口请求报文中筛选出针对银行业务场景符合覆盖度要求和典型性要求的历史联机接口请求报文，作为符合要求的测试请求(也可以记为核心请求)；并将上述测试请求存入预设的请求库中。

负责具体测试工作的第三测试服务器，可以通过查询预设的请求库获取多个测试请求。并分别利用所述测试请求测试第一请求处理系统和第二请求处理系统。其中，上述第二请求处理系统具体可以理解为改造后的负责接收并处理该银行的业务数据处理请求的系统。具体的，上述第二请求处理系统可以是一种基于分布式部署的负责处理联机接口请求的分布式平台系统。基于该系统，平台系统可以通过多个改造后的联机接口与多个业务应用关联。

具体进行测试时，第三测试服务器可以调用模拟请求测试工具根据所述测试请求，模拟下游设备向第一请求处理系统发送相应的数据处理请求，并采集第一请求处理系统基于所述数据处理请求生成的处理结果，作为所述第一反馈结果，从而可以完成针对第一请求处理系统的测试。

接着，第三测试服务器可以通过控制模式切换开关，切换成第二请求处理系统；再调用模拟请求测试工具根据所述测试请求，模拟下游设备向第二请求处理系统发送相应的数据处理请求，并采集第二请求处理系统基于所述数据处理请求生成的处理结果，作为所述第二反馈结果，从而可以完成针对第二请求处理系统的测试。

进一步，第三测试服务器可以根据第一反馈结果和第二反馈结果，确定第二请求处理系统是否符合功能性要求；并生成对应的第一结果报告。其中，第一结果报告用于表征改造后的第二请求处理系统是否符合功能性要求，是否能够完整、正常地实现改造前的第一请求处理系统所负责的相应业务功能。

具体的，第三服务器可以先比较第一反馈结果和第二反馈结果，确定反馈结果的差异值；再检测所述反馈结果的差异值是否小于预设的差异阈值；在确定所述反馈结果的差异值小于预设的差异阈值的情况下，确定所述第二请求处理系统符合功能性要求。

进而，可以使用改造后的第二请求处理系统来替换原本的第一请求处理系统，来完成该银行相关的业务数据处理请求。

从而可以快速地检测并确定当前改造后的第二请求处理系统针对银行业务场景的大部分情形都能正常适用，不存在异常的联机接口，可以满足绝大部分的数据处理需求。

相反，在确定所述反馈结果的差异值大于等于预设的差异阈值的情况下，确定所述第二请求处理系统不符合功能性要求。

相应的，第三服务器，还可以根据反馈结果的差异值，从所述第二反馈结果中确定出异常反馈结果；根据所述异常反馈结果，定位出第二请求处理系统中的异常接口；并对所述异常接口进行修复处理。

从而可以快速地检测并确定当前改造后的第二请求处理系统针对银行业务场景的大部分情形还无法完全适用，存在部分异常的联机接口；进而可以根据测试所得到的反馈结果，准确地定位出上述异常的联机接口，并对异常的联机接口进行针对性的修复处理，得到符合要求的改造后的第二请求处理系统。

参阅图2所示，本说明书实施例提供了一种系统测试方法，其中，该方法具体应用于服务器一侧。具体实施时，该方法可以包括以下内容：

S201：获取历史请求日志，并从所述历史请求日志中提取出多个历史联机接口请求报文；

S202：调用预设的请求处理模型基于预设的筛选规则，处理所述多个历史联机接口请求报文，以筛选出符合要求的测试请求；其中，所述测试请求符合目标应用场景的覆盖度要求和典型性要求；

S203：利用所述测试请求，测试第一请求处理系统，得到第一反馈结果；其中，所述第一请求处理系统为基于集中式部署的负责处理联机接口请求的主机系统；

S204：切换第二请求处理系统，并利用所述测试请求，测试所述第二请求处理系统，得到第二反馈结果；其中，所述第二请求处理系统为改造第一请求处理系统所得到的基于分布式部署的负责处理联机接口请求的平台系统；

S205：根据第一反馈结果和第二反馈结果，确定第二请求处理系统是否符合功能性要求。

通过上述实施例，可以先利用预设的请求处理模型基于预设的筛选规则，从所获取的海量的历史联机接口请求报文中筛选出数量相对较少，但具有较好的覆盖度和典型性的测试请求；进而可以利用上述测试请求，切换并分别对改造前的第一请求处理系统和改造后的第二请求处理系统进行相关测试，从而可以高效且有针对性地完成对改造后的第二请求处理系统的功能性测试，准确地确定出第二请求处理系统是否符合功能性要求，获得较好的测试效果。

在一些实施例中，服务器具体实施时，可以通过访问第一请求处理系统，或者相应的历史数据库，以获取所述历史请求日志。其中，所述历史请求日志中记录有历史上第一请求处理系统接收并处理过的数据处理请求的相关信息。

具体的，以交易业务场景为例，上述历史请求日志中具体可以记载有历史上的预设的时间段内该第一请求处理系统所涉及到的海量交易数据、交易数据的交易日期、交易时间、全息监控链路信息、请求编号、联机接口请求报文等相关数据。

在一些实施例中，服务器具体实施时，可以通过检索并根据目标字段，从历史请求日志中检测并提取出多个联机接口请求报文。

由于在大数据处理领域，在历史上的某个预设的时间段内，第一请求处理系统可能会接收并处理数量庞大的数据处理请求，导致所提取出的多个历史联机接口请求报文的数量也相对较为庞大。如果利用所提取出的所有的历史联机接口请求报文进行测试，势必需要耗费较大的数据处理量，以及较长的数据处理时间。因此，考虑可以从数量庞大的多个历史联机接口请求报文中进一步筛选出覆盖度较高、较为典型的数据处理请求，作为测试请求(也可以称为核心请求)；这样后续可以使用数量相对较少的测试请求，耗费较少的数据处理量以及较短的数据处理时间，就能够高效地完成针对系统的覆盖度较高、效果较好的功能性测试。

在一些实施例中，上述第一请求处理系统具体可以理解为改造前负责接收并处理接入的数据处理请求的系统。具体的，上述第一请求处理系统可以是基于集中式部署的主机系统。

在一些实施例中，上述第二请求处理系统具体可以理解为改造后负责接收并处理接入的数据处理请求的系统。具体的，上述第二请求处理系统可以是基于分布式部署的平台系统。

在一些实施例中，可以在第一请求处理系统的基础上，通过相应改造，得到改造后的第二请求处理系统。

在一些实施例中，针对不同的应用场景，上述数据处理请求具体可以是不同类型的业务请求。例如，以银行业务场景为例，上述数据处理请求具体可以包括：账户余额查询请求、交易明细查询请求、转账交易请求等等。当然上述所列举的数据处理请求只是一种示意性说明。具体实施时，根据具体的应用场景和处理需求，上述数据处理请求还可以包括其他类型的业务请求。对此，本说明书不作限定。

在一些实施例中，上述符合要求的测试请求具体可以理解为针对目标应用场景(例如，银行业务场景等)能够同时满足覆盖度要求(具有较高的覆盖度)和典型性要求(具有对主要接入并处理的数据处理请求较好的代表性)的数据处理请求。

在一些实施例中，上述预设的请求处理模型具体可以理解为预先训练好的能够基于相应的预设的筛选规则，从多个历史联机接口请求报文中筛选出同时符合目标应用场景的覆盖度要求和典型性要求的测试请求的识别模型。

在一些实施例中，上述预设的筛选规则具体可以是一种记载有用作预设的请求处理模型的筛选依据的特征参数的规则数据。

在一些实施例中，以银行业务场景为例，上述预设的筛选规则具体可以包含有以下的特征参数：交易业务参数、交易量统计参数、交易场景参数、请求地区参数等。此外，上述预设的筛选规则进一步还可以包含有预设的阈值参数。

在一些实施例中，以银行业务为例，所述交易业务参数具体可以包括：对公交易明细查询业务和/或对个人交易明细查询业务等。

其中，上述对个人交易明细查询业务具体可以包括针对个人的活期、信用卡、工资单、理财、基金、贵金属等明细的查询。上述对公交易明细查询业务具体可以包括针对企业或单位的往来户、现金管理户、综合账户等明细的查询。

在一些实施例中，以银行业务为例，所述交易场景参数具体包括以下至少之一：手机银行场景、网银场景、柜面场景、自助终端场景等。

其中，上述手机银行场景具体可以理解为使用手机上的手机银行APP发送相关的数据处理请求的场景。上述网银场景具体可以理解为使用诸如台式电脑、平台电脑、笔记本电脑等PC端的网页访问网上银行并发送相关的数据处理请求的场景。上述柜面场景具体可以理解为在银行的业务办理大厅与柜面业务员交互，人工办理相关的数据处理的场景。上述自助终端场景具体可以理解为使用诸如ATM机、自助服务机等自助设备发送相关的数据处理请求的场景。

在一些实施例中，上述请求地区参数具体可以理解为发送数据处理请求时定位到的所在地理位置，和/或，发送数据处理请求的终端设备的物理地址或IP地址。

在一些实施例中，上述交易量统计参数具体可以包括：交易金额的统计量、交易笔数的统计量、交易周期的统计量等等。

通过上述实施例，基于预设的筛选规则所包含的上述多样且丰富的特征参数，可以较为细致、精准地筛选出同时具有较高的覆盖度和典型性的测试请求。

在一些实施例中，具体实施前，服务器可以通过对历史数据进行学习总结，得到上述预设的筛选规则。也可以是服务器接收用户自定义的特征参数，并根据用户自定义的特征参数，结合相应的模板规则，配置得到对应的预设的筛选规则。

在一些实施例中，上述预设的请求处理模型具体可以包括基于XGBoost算法训练得到的模型。其中，XGBoost(eXtreme Gradient Boosting)算法具体可以理解为一种基于GBDT(Gradient Boosting Decision Tree)改进得到的，应用于机器学习，能够高效地实现GBDT运算等的算法。

通过上述实施例，利用基于XGBoost算法训练得到的模型，配合预设的筛选规则，能够精准地筛选出符合要求的测试请求。

在一些实施例中，具体实施时，可以将多个历史联机接口请求报文作为模型输入，输入至预设的请求处理模型中，并运行该预设的请求处理模型。预设的请求处理模型具体运行时，可以根据预设的筛选规则，通过对多个历史联机接口请求报文进行关键字段的检索匹配，以找出符合要求的历史联机接口请求报文，输出模型，作为所述测试请求。

在一些实施例中，具体实施前，可以按照以下方式训练得到预设的请求处理模型：基于XGBoost算法构建初始模型；同时，获取样本联机接口请求报文，并根据样本筛选规则，为样本联机接口请求报文设置相应的标签，得到标注后的样本联机接口请求报文；根据预设的划分规则，划分出一部分的样本联机接口请求报文(例如，占60％)作为训练集，另一部分的样本联机接口请求报文(例如，占20％)作为测试集，剩下部分的样本联机接口请求报文(例如，占20％)作为验证集；依次利用所述训练集、测试集和验证集对初始模型进行相应的训练、测试和验证，以得到符合精度要求的模型，作为预设的请求处理模型。

在一些实施例中，上述利用所述测试请求，测试第一请求处理系统，得到第一反馈结果，具体实施时，可以包括以下内容：调用模拟请求测试工具根据所述测试请求，模拟下游设备向第一请求处理系统发送相应的数据处理请求，并采集第一请求处理系统基于所述数据处理请求生成的处理结果，作为所述第一反馈结果。从而可以高效地完成针对第一请求处理系统的测试。

通过上述实施例，服务器可以使用模拟请求测试工具基于测试请求，来模拟下游设备向第一请求处理系统发送相应的数据处理请求进行测试，而不需要调用到真实的下游设备，从而可以有效地简化测试过程的复杂度，提高测试效率；同时也可以减少测试过程对下游设备所产生的影响。

在一些实施例中，在完成针对第一请求处理系统的测试之后，可以通过控制切换开关，快速地切换到第二请求处理系统；进而可以在相同的测试环境下，对第二请求处理系统进行对应测试。

在一些实施例中，上述切换第二请求处理系统，并利用所述测试请求，测试所述第二请求处理系统，得到第二反馈结果，具体实施实施，可以包括：控制切换开关，将待测试的系统由第一请求处理系统切换为第二请求处理系统；调用模拟请求测试工具根据所述测试请求，模拟下游设备向第二请求处理系统发送相应的数据处理请求，并采集第二请求处理系统基于所述数据处理请求生成的处理结果，作为所述第二反馈结果。从而可以高效地完成针对第二请求处理系统的测试。

在一些实施例中，上述根据第一反馈结果和第二反馈结果，确定第二请求处理系统是否符合功能性要求，具体实施时，可以包括以下内容：

S1：比较第一反馈结果和第二反馈结果，确定反馈结果的差异值；

S2：检测所述反馈结果的差异值是否小于预设的差异阈值；

S3：在确定所述反馈结果的差异值小于预设的差异阈值的情况下，确定所述第二请求处理系统符合功能性要求。

通过上述实施例，可以基于两次系统测试得到的第一反馈结果和第二反馈结果，通过判断出第二请求处理系统在代替第一请求处理系统处理目标应用场景中接入的主要数据处理请求(例如，联机接口请求)时，所实现的功能效果是否与第一请求处理系统一致、是否能够满足正常的工作要求，从而可以较为准确地确定出第二请求处理系统是否符合相应的功能性要求，是否可以代替第一请求处理系统完成目标应用场景中的主要数据处理请求的处理。

在一些实施例中，在检测所述反馈结果的差异值是否小于预设的差异阈值之后，所述方法具体实施时，还可以包括以下内容：在确定所述反馈结果的差异值大于等于预设的差异阈值的情况下，确定所述第二请求处理系统不符合功能性要求；相应的，根据反馈结果的差异值，从所述第二反馈结果中确定出异常反馈结果；根据所述异常反馈结果，定位出第二请求处理系统中的异常接口；并对所述异常接口进行修复处理。

通过上述实施例，可以在确定出第二请求处理系统存在异常的同时，确定并依据第二反馈结果中的异常反馈结果，准确地定位出第二请求处理系统中的异常接口；再对该异常接口进行针对性的修复处理，从而可以得到符合功能性要求的第二请求处理系统。

在一些实施例中，所述方法具体实施时，还可以包括以下内容：

S1：获取异常请求特征；

S2：根据所述异常请求特征和所述测试请求，构造异常请求；

S3：利用所述异常请求，测试所述第二请求处理系统，得到第三反馈结果；

S4：根据所述第三反馈结果，确定第二请求处理系统是否符合安全性要求。

通过上述实施例，还可以利用测试请求和异常请求特征，通过构造并利用对应的异常请求，高效地对第二请求处理系统的安全性进行相关测试，得到较好的测试效果。

在一些实施例中，上述异常请求特征具体可以理解为能够反映出某几类具有攻击性风险的异常请求的特征字符。具体实施前，客户通过查询攻击请求数据库，获取大量具有攻击性风险的异常请求；再对上述大量具有攻击性风险的异常请求依次进行聚类处理和特征提取，以得到所述异常请求特征。

在一些实施例中，所述异常请求特征具体可以包括以下至少之一：特殊符号、恶意代码、SQL指令、非法字典值、空值、超长值等等。其中，每一个异常请求特征对应一类异常请求。

通过上述实施例，可以利用多中不同类型的异常请求特征，结合测试请求，构造出种类较为丰富、齐全的异常请求；进而可以利用上述异常请求，对第二请求处理系统进行更为全面、有效的安全性测试。

在一些实施例中，具体构造异常请求时，可以根据相应的请求构造规则，将上述异常请求特征注入拼接到正常的测试请求中，以得到对应的异常请求。

在一些实施例中，具体构造异常请求时，可以使用自动化工具批量地利用异常请求特征和所述测试来构造异常请求，从而可以快速地构造得到大量用于进行安全性测试的异常请求。再调用模拟请求测试工具根据所述异常请求，模拟下游设备向第二请求处理系统发送相应的数据处理请求，并采集第二请求处理系统基于所述数据处理请求生成的处理结果，作为所述第三反馈结果。

在一些实施例中，具体实施时，可以根据第三反馈结果，确定第二请求处理系统是否存在诸如SQL注入、跨站脚本、软件容错等安全性问题；进而可以针对第二请求处理系统所存在的安全性问题，对第二请求处理系统进行针对性的修复处理，以消除第二请求处理系统的安全性问题，提高第二请求处理系统的可靠性。

由上可见，基于本说明书实施例提供的系统测试方法，可以先获取历史请求日志，并提取出多个历史联机接口请求报文；再调用预设的请求处理模型基于预设的筛选规则，通过处理多个历史联机接口请求报文，以筛选出符合目标应用场景的覆盖度要求和典型性要求的测试请求；接着，可以利用测试请求，测试第一请求处理系统，得到第一反馈结果；其中，第一请求处理系统为基于集中式部署的负责处理联机接口请求的主机系统；再切换第二请求处理系统，并利用测试请求，测试第二请求处理系统，得到第二反馈结果；其中，第二请求处理系统为基于分布式部署的负责处理联机接口请求的平台系统；根据第一反馈结果和第二反馈结果，确定第二请求处理系统是否符合功能性要求，从而可以高效且有针对性地完成对改造后的第二请求处理系统的测试，准确地确定出第二请求处理系统是否符合功能性要求，获得较好的测试效果。

本说明书实施例还提供一种服务器，包括处理器以及用于存储处理器可执行指令的存储器，所述处理器具体实施时可以根据指令执行以下步骤：获取历史请求日志，并从所述历史请求日志中提取出多个历史联机接口请求报文；调用预设的请求处理模型基于预设的筛选规则，处理所述多个历史联机接口请求报文，以筛选出符合要求的测试请求；其中，所述测试请求符合目标应用场景的覆盖度要求和典型性要求；利用所述测试请求，测试第一请求处理系统，得到第一反馈结果；其中，所述第一请求处理系统为基于集中式部署的负责处理联机接口请求的主机系统；切换第二请求处理系统，并利用所述测试请求，测试所述第二请求处理系统，得到第二反馈结果；其中，所述第二请求处理系统为改造第一请求处理系统所得到的基于分布式部署的负责处理联机接口请求的平台系统；根据第一反馈结果和第二反馈结果，确定第二请求处理系统是否符合功能性要求。

为了能够更加准确地完成上述指令，参阅图3所示，本说明书实施例还提供了另一种具体的服务器，其中，所述服务器包括网络通信端口301、处理器302以及存储器303，上述结构通过内部线缆相连，以便各个结构可以进行具体的数据交互。

其中，所述网络通信端口301，具体可以用于获取历史请求日志，并从所述历史请求日志中提取出多个历史联机接口请求报文。

所述处理器302，具体可以用于调用预设的请求处理模型基于预设的筛选规则，处理所述多个历史联机接口请求报文，以筛选出符合要求的测试请求；其中，所述测试请求符合目标应用场景的覆盖度要求和典型性要求；利用所述测试请求，测试第一请求处理系统，得到第一反馈结果；其中，所述第一请求处理系统为基于集中式部署的负责处理联机接口请求的主机系统；切换第二请求处理系统，并利用所述测试请求，测试所述第二请求处理系统，得到第二反馈结果；其中，所述第二请求处理系统为改造第一请求处理系统所得到的基于分布式部署的负责处理联机接口请求的平台系统；根据第一反馈结果和第二反馈结果，确定第二请求处理系统是否符合功能性要求。

所述存储器303，具体可以用于存储相应的指令程序。

在本实施例中，所述网络通信端口301可以是与不同的通信协议进行绑定，从而可以发送或接收不同数据的虚拟端口。例如，所述网络通信端口可以是负责进行web数据通信的端口，也可以是负责进行FTP数据通信的端口，还可以是负责进行邮件数据通信的端口。此外，所述网络通信端口还可以是实体的通信接口或者通信芯片。例如，其可以为无线移动网络通信芯片，如GSM、CDMA等；其还可以为Wifi芯片；其还可以为蓝牙芯片。

在本实施例中，所述处理器302可以按任何适当的方式实现。例如，处理器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application SpecificIntegrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式等等。本说明书并不作限定。

在本实施例中，所述存储器303可以包括多个层次，在数字系统中，只要能保存二进制数据的都可以是存储器；在集成电路中，一个没有实物形式的具有存储功能的电路也叫存储器，如RAM、FIFO等；在系统中，具有实物形式的存储设备也叫存储器，如内存条、TF卡等。

本说明书实施例还提供了一种基于上述系统测试方法的计算机存储介质，所述计算机存储介质存储有计算机程序指令，在所述计算机程序指令被执行时实现：获取历史请求日志，并从所述历史请求日志中提取出多个历史联机接口请求报文；调用预设的请求处理模型基于预设的筛选规则，处理所述多个历史联机接口请求报文，以筛选出符合要求的测试请求；其中，所述测试请求符合目标应用场景的覆盖度要求和典型性要求；利用所述测试请求，测试第一请求处理系统，得到第一反馈结果；其中，所述第一请求处理系统为基于集中式部署的负责处理联机接口请求的主机系统；切换第二请求处理系统，并利用所述测试请求，测试所述第二请求处理系统，得到第二反馈结果；其中，所述第二请求处理系统为改造第一请求处理系统所得到的基于分布式部署的负责处理联机接口请求的平台系统；根据第一反馈结果和第二反馈结果，确定第二请求处理系统是否符合功能性要求。

在本实施例中，上述存储介质包括但不限于随机存取存储器(Random AccessMemory,RAM)、只读存储器(Read-Only Memory,ROM)、缓存(Cache)、硬盘(Hard DiskDrive,HDD)或者存储卡(Memory Card)。所述存储器可以用于存储计算机程序指令。网络通信单元可以是依照通信协议规定的标准设置的，用于进行网络连接通信的接口。

在本实施例中，该计算机存储介质存储的程序指令具体实现的功能和效果，可以与其它实施方式对照解释，在此不再赘述。

参阅图4所示，在软件层面上，本说明书实施例还提供了一种系统测试装置，该装置具体可以包括以下的结构模块：

获取模块401，具体可以用于获取历史请求日志，并从所述历史请求日志中提取出多个历史联机接口请求报文；

调用模块402，具体可以用于调用预设的请求处理模型基于预设的筛选规则，处理所述多个历史联机接口请求报文，以筛选出符合要求的测试请求；其中，所述测试请求符合目标应用场景的覆盖度要求和典型性要求；

第一测试模块403，具体可以用于利用所述测试请求，测试第一请求处理系统，得到第一反馈结果；其中，所述第一请求处理系统为基于集中式部署的负责处理联机接口请求的主机系统；

第二测试模块404，具体可以用于切换第二请求处理系统，并利用所述测试请求，测试所述第二请求处理系统，得到第二反馈结果；其中，所述第二请求处理系统为改造第一请求处理系统所得到的基于分布式部署的负责处理联机接口请求的平台系统；

确定模块405，具体可以用于根据第一反馈结果和第二反馈结果，确定第二请求处理系统是否符合功能性要求。

需要说明的是，上述实施例阐明的单元、装置或模块等，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本说明书时可以把各模块的功能在同一个或多个软件和/或硬件中实现，也可以将实现同一功能的模块由多个子模块或子单元的组合实现等。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

由上可见，基于本说明书实施例提供的系统测试装置，可以高效且有针对性地完成对改造后的第二请求处理系统的测试，准确地确定出第二请求处理系统是否符合功能性要求，获得较好的测试效果。

在一个具体的场景示例中，可以应用本说明书实施例提供的系统测试方法针对银行业务场景，基于生产请求回溯及异常数据规则库实现对改造后的平台系统接口安全可靠性的验证。具体实施过程可以参阅以下内容。

在本场景示例中，可以基于生产请求回溯，建立异常数据规则库，并构造对应的异常请求的联机接口验证框架。基于该框架，可以通过测试验证保障联机接口的安全可靠性，满足自主可控要求。包括：先获取生产环境主机下移分布式平台(例如，第二请求处理系统)改造投产前的现有请求日志(例如，历史请求日志)，并提取联机接口请求报文(例如，历史联机接口请求报文)纳入请求信息库；再根据不同维度筛选规则(例如，预设的筛选规则)和机器学习算法(例如，预设的请求处理模型)，筛选出典型交易(例如，同时符合银行业务场景的覆盖度要求和典型性要求的测试请求)并纳入核心请求信息库；通过开关控制服务的切流和回切，模拟验证主机下移分布式平台改造前后请求结果的一致性(以进行针对第二请求处理系统的功能性测试)，以保障生产交易平稳运行；同时，还可以建立请求数据规则库，并利用请求数据规则库中的注入非法值、特殊值、空值、超长等请求参数(例如，异常请求特征)，构造异常请求并模拟交易(以进行针对第二请求处理系统的安全性测试)。

具体实施时，参阅图5所示，可以包括以下步骤。

步骤S1，通过生产运维平台获取主机下移分布式平台改造前的历史交易明细查询请求日志文件，并自动打包推送至开发测试环境。其中，请求日志一般包含交易日期、交易时间、全息监控链路信息、请求编号、联机接口请求报文等内容。从请求日志文件中提取出联机接口请求报文纳入到请求信息库。其中，联机接口请求报文记录了历史明细查询交易的请求接口名、请求渠道、请求地区、交易事件编号、终端信息等日志类信息和查询方式、查询范围、账号卡号币种等多种自定义的筛选条件信息。

步骤S2，根据不同维度的筛选规则和机器学习算法进行建模，从请求信息库筛选典型交易纳入核心请求信息库。具体的，首先结合生产接口调用情况对请求进行分级管理，以覆盖不同交易种类库、交易场景库、请求地区等，采用机器学习算法进行建模；再筛选出包含个人交易明细查询业务(例如，活期、信用卡、工资单、理财、基金、贵金属等子业务类型)、对公交易明细查询业务(往来户、现金管理户、综合账户等子业务类型)，以及手机银行、网银、柜面、自助终端等不同交易场景，还有不同请求地区的核心请求报文纳入到核心请求信息库。

步骤S3，主机下移分布式平台应还设置有功能开关(例如，切换开关)，在平台不稳定或改造存在测试环境未发现的缺陷时，支持及时回切至主机系统(例如，第一请求处理系统)，进而可以保障交易持续可用。具体的，在测试环境中，可以使用模拟请求测试工具，切换开关状测试态验证主机下移分布式平台改造前后核心请求的返回结果是否一致。如果确定返回结果一致，表示主机下移分布式平台后可兼容主机历史明细查询，且平台接口服务未新增校验规则和修改筛选逻辑，从而可以实现联机接口查询请求平稳切换至分布式平台。如果返回结果不一致，则可以确定主机下移分布式平台前后接口逻辑发生变化，可以进一步逐一分析平台接口服务是否存在缺陷，并按需进行针对性的修复处理。

步骤S4，此外，还可以建立请求数据规则库，并存入诸如注入特殊符号、恶意代码、SQL指令、非法字典值、空值、超长值等(异常请求特征)。接着，可以使用自动化工具批量替换核心请求报文的传入参数，以构造得到不同类型的异常请求。再通过模拟请求测试工具基于上述异常请求进行测试验证，并通过分析返回结果，确定是否存在诸如SQL注入、跨站脚本、软件容错等安全可靠性问题。

基于上述步骤，进一步构建了以下7大模块来自动实现测试验证。可以参阅图6所示，一种主机下平台场景下的基于请求回溯的联机接口验证框架，具体可以包括以下多个结构模块：

生产请求获取模块1：具体可以用于从生产运维获取主机下平台前的请求日志，通过定期从生产获取日志文件，自动打包推送到开发测试环境，按请求日志关键字提取联机接口请求报文，最后存储到请求信息库。

核心请求识别模块2：具体可以用于获取生产核心请求报文，根据不同维度筛选规则和机器学习算法进行特征分析，构建核心请求识别模型，通过该模型对请求信息库的接口请求进行训练，识别出核心请求并纳入到核心请求信息库。

环境准备模块3：具体可以用于提供主机下平台切流前后核心请求测试验证环境，通过批量切换测试环境服务开关，自动控制切流查询新平台分支或回切查询原主机分支，从而快速实现版本切换。

模拟核心请求模块4：具体可以用于在测试环境模拟核心请求，通过交易代码、交易状态、记录条数、字段信息、错误代码、错误提示信息等构建比对规则模型，比对主机下平台开关切换前后返回结果是否一致。如果存在不一致的情况，则表示主机下平台前后接口逻辑发生变化，需逐一分析原因后按需修改，程序部署后需重复该模块操作。

模拟异常请求模块5：具体可以用于主机下平台切流后模拟异常请求发起接口攻击。首先建立请求数据规则库，包含不同类型参数值、特殊符号、恶意代码、SQL指令、非法字典值、空值、超长值等，通过自动化工具使用正交法替换核心请求报文字段值，构造异常请求，通过模拟测试工具模拟异常请求。

报告分析模块6：具体可以用于分析请求模拟测试结果，包括核心请求主机下平台切流前后是否一致，异常请求是否存在SQL注入、跨站脚本、软件容错等安全可靠性问题。

基于上述多个模块，可以参阅图7所示，可以进行以下所示的自动化处理流程：

1)获取生产日志请求10：从生产环境自动获取原始请求日志。

2)解析获取请求报文11：按关键字解析原始请求日志，获取请求报文。

3)核心请求识别12：根据匹配规则和机器学习算法，构建分析模型，结合四项维度以及各项的权重配比公式计算识别核心请求。

4)纳入核心请求库13：将自动将识别出的核心请求纳入核心请求库。

5)主机下平台切换14：通过自动触发开关修改切换主机下平台前后环境。

6)核心请求批量模拟15：主机下平台前后通过批量模拟器自动模拟核心请求查询。

7)一致性比对16：通过自动化工具比对主机下平台前后核心请求模拟查询结果是否一致。

8)异常请求构造17：通过自动化工具使用正交法替换核心请求报文字段值为异常数据规则库的记录，构造不同类型的异常请求。

9)异常请求批量模拟18：通过批量模拟器自动模拟异常请求查询。

10)报告生成19：将主机下平台切换前后核心请求返回结果的比对情况生成报告，以及异常请求报文在主机下平台后的可靠性测试报告，邮件发送至测试人员。

通过上述方式，可以实现主机下移分布式平台场景下生产联机接口的快速验证，提升测试效率，快速响应测试需求，全面守护应用产品稳定。具体可以参阅表1所示的传统测试框架与使用本发明框架进行测试的比较表。

表1

通过上述场景示例，构建并使用的主机下平台场景下基于生产请求回溯的联机接口验证框架，可以全面地覆盖生产核心调用场景，并有效减少上下游沟通，从而提高测试效率。此外，还可以通过构造异常请求可提高主机下平台联机接口的安全可靠性。具体的，该框架主要具有以下3个特性：1，能够智能识别出生产核心请求，对接生产运维获取请求日志，根据匹配规则和机器学习算法，识别出生产上核心请求报文，自动入库，全自动维护应用核心请求报文，可全面覆盖生产核心场景，保障主机下平台切流前后生产运行稳定；2，能够自动构造异常请求，通过异常数据规则库，使用自动化工具批量构造异常请求，验证主机下平台接口的安全稳定性；3，能够自动化模拟报文验证及结果比对，通过批量模拟器自动模拟查询主机下平台前后核心请求以及异常请求，生成测试报告，无需依赖测试人员值守即可实现主机下平台场景下联机接口的快速验证，有效提升测试效率。

虽然本说明书提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的手段可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或客户端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境，甚至为分布式数据处理环境)。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、产品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、产品或者设备所固有的要素。在没有更多限制的情况下，并不排除在包括所述要素的过程、方法、产品或者设备中还存在另外的相同或等同要素。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。

本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内部包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

本说明书可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构、类等等。也可以在分布式计算环境中实践本说明书，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

通过以上的实施例的描述可知，本领域的技术人员可以清楚地了解到本说明书可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本说明书的技术方案本质上可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，移动终端，服务器，或者网络设备等)执行本说明书各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例采用递进的方式描述，各个实施例之间相同或相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。本说明书可用于众多通用或专用的计算机系统环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、置顶盒、可编程的电子设备、网络PC、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。

虽然通过实施例描绘了本说明书，本领域普通技术人员知道，本说明书有许多变形和变化而不脱离本说明书的精神，希望所附的权利要求包括这些变形和变化而不脱离本说明书的精神。