CN114205273A - 系统测试方法、装置和设备及计算机存储介质 - Google Patents

Abstract

本申请公开了一种系统测试方法、装置和设备及计算机存储介质，涉及系统测试技术领域，用于提升券商交易系统的ETE测试的便捷性和可靠性。该方法包括：响应于测试指令，执行测试指令指定的测试用例，测试指令用于指示对待测交易系统的网关进行测试；根据每一测试用例所需的用例数据，生成每一测试用例对应的业务请求包；用例数据包括为每一测试用例设定的业务场景参数信息，以及从实时行情系统获取的每一测试用例所需的行情参数信息；利用业务请求包通过网关模拟每一测试用例对应的业务交互过程；根据从网关获取的日志文件中每一测试用例对应的日志内容确定每一测试用例的执行结果，并根据各测试用例的执行结果得到网关的测试结果。

Description

系统测试方法、装置和设备及计算机存储介质

技术领域

本申请涉及系统测试技术领域，提供一种系统测试方法、装置和设备及计算机存储介质。

背景技术

端到端(End-to-End，ETE)测试是券商交易系统的一种协议级验收测试，当券商交易系统出现重要升级时，需申请参加此测试并提交测试报告，并等待证券交易所审核通过后才能进行系统升级。

目前，ETE测试一般需要人工设定测试用例的请求类型以及所需的参数，如委托类型、股票代码和价格等，进而发送请求到券商交易服务器进行测试。但是，该方案需要根据繁杂的用例要求去准备每个测试用例所需的参数，测试所需的准备工作较多，需要大量的时间和人力成本。此外，由于部分参数需要根据测试时的实时行情进行调整，而证券交易所ETE测试的时间短以及压力大，存在一定的人为操作错误风险。

因此，如何提升券商交易系统的ETE测试的便捷性和可靠性是目前亟待解决的问题。

发明内容

本申请实施例提供一种系统测试方法、装置和设备及计算机存储介质，用于提升券商交易系统的ETE测试的便捷性和可靠性。

一方面，提供一种系统测试方法，所述方法包括：

响应于测试指令，执行所述测试指令指定的测试用例，所述测试指令用于指示对待测交易系统的网关进行测试；其中，不同测试用例用于模拟所述待测交易系统中不同业务场景对应的业务过程；

根据所述每一测试用例所需的用例数据，生成所述每一测试用例对应的业务请求包；所述用例数据包括为所述每一测试用例设定的业务场景参数信息，以及从实时行情系统获取的所述每一测试用例所需的行情参数信息；

利用所述业务请求包通过所述网关模拟所述每一测试用例对应的业务交互过程；

根据从所述网关获取的日志文件中所述每一测试用例对应的日志内容确定所述每一测试用例的执行结果，并根据各测试用例的执行结果得到所述网关的测试结果。

一方面，提供一种系统测试装置，所述装置包括：

用例执行单元，用于响应于测试指令，执行所述测试指令指定的测试用例，所述测试指令用于指示对待测交易系统的网关进行测试；其中，不同测试用例用于模拟所述待测交易系统中不同业务场景对应的业务过程；

请求包生成单元，用于根据所述每一测试用例所需的用例数据，生成所述每一测试用例对应的业务请求包；所述用例数据包括为所述每一测试用例设定的业务场景参数信息，以及从实时行情系统获取的所述每一测试用例所需的行情参数信息；

所述用例执行单元，还用于利用所述业务请求包通过所述网关模拟所述每一测试用例对应的业务交互过程；

测试结果确定单元，用于根据从所述网关获取的日志文件中所述每一测试用例对应的日志内容确定所述每一测试用例的执行结果，并根据各测试用例的执行结果得到所述网关的测试结果。

可选的，所述请求包生成单元，用于：

根据所述业务场景参数信息确定所述每一测试用例对应的协议；

根据所述协议中为每一行情参数信息设定的填充位置，在相应的位置填充相应的行情参数信息，以得到所述业务请求字符串。

可选的，所述装置还包括异常构造单元：

所述异常构造单元用于：根据为所述每一测试用例设置的异常测试要求以及所述行情参数信息，确定所述每一测试用例完成所述异常测试要求所需的异常数据；

则所述请求包生成单元，用于：根据为所述每一测试用例所需的用例数据以及所述异常数据得到所述每一测试用例对应的业务请求字符串。

可选的，所述请求包生成单元，用于：

确定所述待测交易系统所属商户的标识信息；

根据所述标识信息调用对应的发包工具将所述业务请求字符串封装为所述业务请求包。

可选的，所述装置还包括日志筛选单元，用于：

根据业务请求包以及业务响应包对应的关键字段，从所述日志文件中筛选得到各测试用例的业务请求包与业务响应包；

对筛选得到的各测试用例的业务请求包与业务响应包进行解析，获取各所述业务请求包与所述业务响应包的内容；

从各所述业务请求包与所述业务响应包的内容中提取设定的关键字段对应内容，并将提取的内容存储至数据库中。

可选的，所述日志筛选单元，用于：

遍历日志文件列表，并确定当前日志文件列表的末尾位置与上一次查询的日志文件列表的末尾位置是否相同；

当确定当前日志文件列表的末尾位置与上一次查询的日志文件列表的末尾位置不相同时，确定存在更新的日志文件；

从更新的日志文件中筛选各测试用例的业务请求包与业务响应包。

可选的，所述测试结果确定单元，用于：

按照所述每一测试用例包括的各执行步骤的执行顺序，逐步确定每一执行步骤的执行结果是否正确；

在确定每一测试用例包括的其中一个执行步骤的执行结果不正确，确定所述每一测试用例测试未通过；或者，

在所述每一测试用例包括的所有执行步骤的执行结果均正确时，确定所述每一测试用例测试通过。

可选的，所述装置还包括报告填充单元，用于：

根据测试报告中各行或者列对应的测试用例标识，从数据库中获取该测试用例对应的测试数据；

根据各行或者列包括的表项对应的关键字段，从所述测试数据中获取所述关键字段对应值，并填充至所述表项中。

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

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

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

本申请实施例中，不同测试用例用于模拟待测交易系统中不同业务场景对应的业务，在测试用例执行时，可以根据每一测试用例设定的测试所需的行情参数，从实时行情系统获取每一测试用例所需的行情参数信息，并根据每一测试用例所需的行情参数信息，生成每一测试用例对应的业务请求包，进而可以利用业务请求包通过网关模拟每一测试用例对应的业务交互过程，最后根据从网关获取的日志文件中每一测试用例对应的日志内容确定每一测试用例的测试结果，从而确定网关是否正常。这样，无需人工来设定测试用例的请求类型以及所需的参数，降低人工参与，提升交易系统的ETE测试的便捷性，此外，由于人工参与更少，因而认为操作失误带来的风险相应减少，从而使得交易系统的ETE测试的可靠性更高。

附图说明

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

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

图2为本申请实施例提供的另一种应用场景示意图；

图3为本申请实施例提供的测试工具的一种架构示意图；

图4为本申请实施例提供的系统测试方法的流程示意图；

图5为本申请实施例提供的结合测试工具的测试流程示意图；

图6为本申请实施例提供的前端执行层提供的测试界面的示意图；

图7为本申请实施例提供的以证券交易系统为例，与待测券商交易系统适配的逻辑示意图；

图8为本申请实施例提供的测试中ETE测试中的场景示意图；

图9为本申请实施例提供的日志筛选脚本的工作过程示意图；

图10为本申请实施例提供的结果审查服务模块的工作过程示意图；

图11为本申请实施例提供的测试报告自动填充脚本的工作流程示意图；

图12为本申请实施例提供的对证券交易系统的网关进行测试的流程示意图；

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

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

具体实施方式

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

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

待测交易系统：待测交易系统可以为基于实时行情参数进行交易的交易系统，例如可以为证券交易系统，当然，也可以为其他可能的交易系统，本申请实施例对此不做限制。

测试用例：每一测试用例预先设置了该用例对应的业务场景、请求类型以及所需的行情参数等，当该测试用例执行时，则会自动的获取行情参数信息，并组装成业务请求包，调用网关进行发送，从而达到对网关进行测试的目的。

行情参数：交易系统中行情参数是可以发生变化的，因而在发起业务请求时，需要获取最新的行情参数。例如对于证券交易系统而言，行情参数例如可以为股票的价格以及每手数量(不同价格的股票每手数量可能不一样)等等，或者，对于商品交易系统而言，行情参数也可以是商品的价格和存货等等。

网关：网关提供协议级别的数据处理，例如将封装完后的业务请求包发送给交易所，或者接收交易所返回的业务响应包等。其中，网关一旦接收到消息，如业务请求包或者业务响应包，就对所有消息执行常用处理，例如添加协议级的头、协议解析或者记录该消息等操作。

交易所：例如对于证券交易系统而言，交易所可以为证券交易所。

订单数量：业务请求包请求的交易中交易的数量。以股票为例，订单数量可以是指一个请求中交易股票的股数。

目前，对于券商交易系统而言，ETE测试是券商交易系统升级时所必须的。而现在的ETE测试一般需要人工设定测试用例的请求类型以及所需的参数，如委托类型、股票代码和价格等，进而发送请求到券商交易服务器进行测试，需要根据繁杂的用例要求去准备每个测试用例所需的参数，测试所需的准备工作较多，需要大量的时间和人力成本。此外，由于部分参数需要根据测试时的实时行情进行调整，而证券交易所ETE测试的时间短以及压力大，存在一定的人为操作错误风险。

此外，ETE测试结果一般是在测试结束后通过券商交易系统服务端日志进行检查，人工判断用例的执行结果，且在人工判断结果后，还需要一条条录入测试报告，时间成本巨大。一旦用例执行失败，又需要耗费人工定位问题并重新进行测试，需要消耗大量的时间和人力成本。

考虑到目前的ETE测试人工参与度过高，从而造成了ETE测试繁琐且可靠性不高的问题，因此，为了提升券商交易系统的ETE测试的便捷性和可靠性，势必需要降低人工参与度。基于此，本申请实施例提供一种系统测试方法，在该方法中，不同测试用例用于模拟待测交易系统中不同业务场景对应的业务，在测试用例执行时，可以根据每一测试用例设定的测试所需的行情参数，从实时行情系统获取每一测试用例所需的行情参数信息，并根据每一测试用例所需的行情参数信息，生成每一测试用例对应的业务请求包，进而可以利用业务请求包通过网关模拟每一测试用例对应的业务交互过程，最后根据从网关获取的日志文件中每一测试用例对应的日志内容确定每一测试用例的测试结果，从而确定网关是否正常。这样，无需人工来设定测试用例的请求类型以及所需的参数，降低人工参与，提升交易系统的ETE测试的便捷性，此外，由于人工参与更少，因而认为操作失误带来的风险相应减少，从而使得交易系统的ETE测试的可靠性更高。

本申请实施例中，通过将不同商户进行标识化，从而可以通过商户适配，来获取对应商户的协议，进而封装业务请求包，因此，本申请实施例的测试方案可以支持多商户接入，对于各商户进行个性化实现，自动选择对应商户执行路径，无需针对各商户进行个性定制测试工具，提升测试工具的适用范围。在证券交易系统中，商户例如可以为券商。

本申请实施例中，在用例执行过程中或者之后，可以从网关监测业务请求包以及业务响应包，获取响应数据包中的响应数据，进而判断测试用例的执行结果，从而无需人工判断审核测试用例执行结果，降低测试的繁杂程度。

本申请实施例中，还可以自动分析测试报告文件，从数据库(DataBase，DB)中读取对应用例的执行日志，解析日志参数后自动填充到报告。

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

本申请实施例提供的方案可以适用于大多数需要进行交易系统的网关测试的场景中，尤其适用于券商交易系统的网关测试场景中，如图1所示，为本申请实施例提供的一种场景示意图，在该场景中，可以包括测试终端101和交易所服务器102。

测试终端10中安装有测试客户端，测试人员可以通过该测试客户端发起测试，并可通过测试客户端提供的可视化界面展示测试进度和测试结果。此外，还可以将待测交易系统的网关部署于测试终端10上。

在具体进行测试时，测试人员可以在测试客户端提供的可视化界面上发起测试，从而测试客户端自动执行测试用例进行测试，以生成用于对网关进行测试的业务请求包，进而可调用待测交易系统的网关将业务请求包发送给交易所，其中，网关会对业务请求包进行协议合法性验证，根据网关的日志可以判断各测试用例的执行结果是否正常，从而判断网关的协议合法性验证是否正常。

当然，网关也可以部署于其他设备上，例如可以部署于待测交易系统对应的后台服务器上，那么测试客户端生成业务请求包之后，则可以将业务请求包发送给待测交易系统的后台服务器，以调用后台服务器上部署的网关将业务请求包发送给交易所。

交易所服务器102为是用于测试的服务器，其运行环境为测试环境，其执行逻辑是与真实交易所服务器是相同的。

其中，测试终端10是具有一定处理能力的计算机设备，例如可以为个人计算机(personal computer，PC)或者笔记本电脑等。测试终端10可以包括一个或多个处理器、存储器以及与其他设备交互的I/O接口等。此外，测试终端10还可以配置显示器，用于为测试人员呈现可视化测试界面。其中，测试终端10的存储器中可以存储本申请实施例提供的系统测试方法的程序指令，这些程序指令被处理器执行时能够用以实现本申请实施例提供的系统测试方法的步骤，以对待测交易系统的网关进行测试。

其中，通常待测交易系统的网关与交易所服务器102之间通过特定的网络进行连接，当网关服务与测试工具部署于不同的设备时，则网关服务与测试工具之间可以通过网络进行连接，该网络例如可以是局域网络。

如图2所示，为本申请实施例提供的另一种场景示意图，在该场景中，可以包括测试终端201、测试服务器202和交易所服务器203。

测试终端201可以为手机、平板电脑(PAD)、个人计算机(personal computer，PC)或者笔记本电脑等计算机设备。测试终端201安装有测试客户端或者能够通过浏览器打开WEB测试页面，测试人员可以通过该测试客户端或者测试页面发起测试，并可通过测试客户端或者测试页面提供的可视化界面展示测试进度和测试结果。

测试服务器202可以为测试客户端或者测试页面对应的服务器，当测试人员在测试客户端提供的可视化界面上发起测试后，测试服务器202可以基于该测试指令开始进行测试，即测试服务器202执行测试用例进行测试，以生成用于对网关进行测试的业务请求包。其中，待测交易系统的网关可以部署于测试服务器202上，当然，网关也可以部署于其他设备上，例如可以部署于待测交易系统对应的后台服务器上。

这里以部署于测试服务器202为例，测试服务器202生成业务请求包之后，可以调用网关将业务请求包发送给交易所服务器203，其中，网关会对业务请求包进行协议合法性验证，根据网关的日志可以判断各测试用例的执行结果是否正常，从而判断网关的协议处理是否正常。

交易所服务器203为是用于测试的服务器，其运行环境为测试环境，其执行逻辑是与真实交易所服务器是相同的。

其中，测试服务器202可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器，但并不局限于此。

测试服务器202可以包括一个或多个处理器、存储器以及与其他设备交互的I/O接口等。其中，测试服务器202的存储器中可以存储本申请实施例提供的系统测试方法的程序指令，这些程序指令被处理器执行时能够用以实现本申请实施例提供的系统测试方法的步骤，以对待测交易系统的网关进行测试。

测试终端201和测试服务器202之间可以通过一个或者多个网络204进行直接或间接的通信连接。该网络204可以是有线网络，也可以是无线网络，例如无线网络可以是移动蜂窝网络，或者可以是无线保真(Wireless-Fidelity，WIFI)网络，当然还可以是其他可能的网络，本发明实施例对此不做限制。

同样的，待测交易系统的网关与交易所服务器203之间也是通过特定的网络进行连接，当网关服务未部署于测试服务器202时，则网关服务与测试服务器202之间可以通过网络进行连接，该网络例如可以是局域网络。

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

本申请实施例的测试方法是基于测试工具进行的，该测试工具例如为图1对应描述部分中所述的测试客户端或者图2对应描述部分中所述的测试客户端和测试服务器上部署的测试工具的结合，因此，在介绍测试方法之前，先对本申请实施例的测试工具进行介绍。如图3所示，为本申请实施例提供的测试工具的一种总体架构示意图，该测试工具可以包括前端执行层、用例执行层、底层支撑层和辅助脚本层。

(1)前端执行层

本申请实施例中，前端执行层用于提供可视化界面，便于测试人员进行可视化操作，例如可提供选择执行用例的功能，以及实时日志的回显等功能。测试人员可以在前端执行层提供的可视化界面上选择需要执行的用例并进行确认之后，则会请求到后台对应的接口，开始进行测试。且在测试用例执行过程中，会将测试用例执行的相关日志实时推送到可视化界面进行展示，并在测试用例执行完成后，前端展示最终结果，即当前测试用例是通过或是未通过。

具体的，前端执行层可以为基于WEB应用框架开发的，例如可以基于Django框架进行开发，当然，也可以采用其他可能的架构，本申请实施例对此不做限制。

(2)用例执行层

本申请实施例中，用例执行层用于实现测试用例的执行，以及调用底层支撑层辅助实现测试用例的执行。其中，自动化用例可以采用自动化框架，实现测试用例的自动执行，例如可以采用单元测试(unit test)框架，或者也可以采用其他的python自动化框架，如pytest。以证券交易系统的ETE测试为例，通常证券交易所会提供ETE测试所需的测试用例，那么自动化用例则会按照ETE测试的测试用例，按步骤准备请求类型(如下单、改单或者撤单等)、买卖方向、订单价格和数量数据，生成业务请求包，然后调用证券交易系统的网关向证券交易所发送请求。

(3)底层支撑层

本申请实施例中，底层支撑层用于辅助用例执行层实现测试用例的实现。底层支撑层可以包括协议解析(Protocol parser)服务模块、异常构造(Exception Maker)服务模块、行情查询(Quote query)模块、交易适配模块和结果审查服务(Rule Server)模块。

1)协议解析服务模块

ETE测试的业务场景覆盖面广，例如涉及不同的请求类型，不同的时段等，协议解析服务可以根据对于不同类型的请求，可以根据调用参数进行自动协议串拼接，返回符合测试用例要求的业务请求字符串。

具体的，协议解析服务可以以python模块方式放入工程项目，上层的用例执行层会根据用例要求，传入对应的参数，从而获取业务请求字符串。

2)异常构造服务模块

在ETE测试场景中存在许多异常场景，因此，异常构造服务模块用于提供异常构造函数进行异常数据的构造，以模拟异常场景进行测试。例如对于证券交易系统，可以根据当前价和步长计算超过24档的价格，或者根据委托价格和每手数量，计算委托金额超过100W的数量，或者根据已有请求串，剔除目标参数等。

具体的，异常构造服务模块也可以以python模块的方式，提供给用例执行层进行使用。

3)行情查询模块

用例执行层在执行测试用例的过程中，需要获取行情参数信息，来生成相应的业务请求包，因此，行情查询模块用于从实时行情系统中查询相应的行情参数信息，并按照一定的协议格式返回给用例执行层使用。

具体的，行情查询模块可以根据配置文件确定当前执行的测试用例对应的商户，选择对应商户的实时行情系统进行查询，并返回给用例执行层。

以证券交易系统为例，行情参数信息例如可以为当前价、价格步长以及每手数量等参数信息，而这些行情参数信息一般需要通过券商行情系统进行查询，因此需要一个适配模块与券商行情系统对接，实现行情查询服务的自动切换，最终按照一定的协议格式返回行情信息结果。

4)交易适配模块

用例执行层从协议解析服务获取到符合测试用例要求的业务请求字符串后，需要进行业务请求字符串的发送，而不同商户的交易服务协议不尽相同，因此，交易适配模块可以根据各商户的通信方式，实现各自的发包工具，将业务请求字符串封装为符合商户的交易服务协议的业务请求包。

具体的，交易适配模块可以根据传入的统一格式的业务请求字符串，通过配置文件确定当前执行的测试用例对应的商户，将业务请求字符串转化为指定发包工具的预期请求格式，进而获取业务请求包并进行发送。

5)结果审查服务模块

当一个测试用例的所有步骤执行完毕后，则可以调用结果审查服务模块，来获取该测试用例的测试结果。

具体的，结果审查服务模块针对该测试用例中的所有步骤，逐步进行结果验证，每一个步骤验证通过后才会进行下一步的结果验证，所有步骤结果验证通过时，则该测试用例测试通过。例如，对于每一个测试用例对应的每一笔请求，都会有对应的唯一标识，通过该标识可以从数据库中查询对应的日志信息，进而进行步骤匹配，每一个步骤有对应的校验规则，结果审查服务模块将日志进行解析，判断对应字段的返回值是否符合规则，即每一个步骤都会设置一个预期结果，将日志中的实际结果与预期结果进行比较，则可以确定该步骤是否通过测试。

(4)辅助脚本层

本申请实施例中，辅助脚本层包括日志筛选脚本和测试报告自动填充脚本。

1)日志筛选(LogTail)脚本

日志实时筛选脚本主要包括两部分的功能，即对新增日志文件的监控功能和对已有日志文件的筛选功能。

通常交易所的下单成功响应包以及成交响应包是异步的，而生产环境的数据库不允许非交易服务进行查询，所以用例执行层无法感知到目前测试用例中交易订单的变化，因此，本申请实施例设置了额外的日志筛选脚本，将测试用例测试结果审查所需的信息进行实时筛选，并记录到数据库中。

日志筛选脚本通过遍历网关的日志文件列表，从列表获取各日志文件的名称、大小以及上次查询的文件位置等信息，若当前文件末尾等于上次查询的文件最终位置则表示无新的日志信息，否则需要将新增的日志内容进行解析。解析时主要关注发送的业务请求包和交易所的业务响应包内容，并将解析出的关键字段存储到数据库中。

在具体实施过程中，网关在日志过大时可能会写入新的日志文件，因此，日志筛选脚本可以linux内核自带的用于通知用户空间程序文件系统变化的机制，即inotify机制，来维护网关的日志的监听列表log_list，从而保证日志信息的完整性。

2)测试报告自动填充脚本

测试报告是需要按照交易所提供的格式进行填写，测试报告自动填充脚本通过解析测试报告中各个工作表，判断当前行是否需要进行数据填充，若需要填充，则根据测试报告中各行或者列对应的测试用例标识，从数据库中获取该测试用例对应的测试数据，再根据各行或者列包括的表项对应的关键字段，从测试数据中获取关键字段对应值，并填充至所述表项中。

例如，可以根据当前行的测试用例标识，从数据库中获取对应的请求串信息以及业务响应包信息等，再根据各列对应的字段，从获取到的数据中解析出对应值，记录下对应的坐标，最后测试报告自动填充脚本遍历已解析出的数据，填充到指定的工作表坐标中。

具体的，测试报告自动填充脚本可以基于python的xlrd模块和xlwt库来实现。

下面结合上述的测试工具对本申请实施例侧系统测试方法进行介绍。如图4和图5所示，图4为本申请实施例提供的系统测试方法的流程示意图，图5为结合该测试工具的测试流程示意图。

步骤401：获取测试指令。

本申请实施例中，测试人员可以通过上述测试工具的前端执行层发起测试，相应的，测试终端则可以获取到基于测试人员操作生成的测试指令。

具体的，测试工具可以完全部署于测试终端上，那么测试人员可以前端执行层发起测试之后，相应的，响应于测试人员的操作，会生成测试指令，并将测试指令提供给自动用例层；或者，当前端执行层部署于测试终端上，而测试工具包括的其余部分设置于测试服务器时，则测试终端会将生成的测试指令通过网络发送给测试服务器，相应的，测试服务器也会将测试指令提供给自动用例层。

如图6所示，为一种前端执行层提供的测试界面的示意图。其中，在该测试界面中，测试人员可以设置测试用例文件的网际互连协议(Internet Protocol，IP)地址和存储路径，并可以选择需要执行的测试用例，在确定“执行”按钮之后则可以发起测试，相应的，响应于测试人员的操作，则可以生成测试指令，该测试命令用于指示执行测试人员选定的测试用例，以对待测交易系统的网关进行测试。

以证券交易系统为例，当券商的行情系统出现故障时，无法获取准确的参数行情信息，因此如图6所示，为测试界面的示意图，在该测试界面上，还可以提供股票代码、当前价和每手数量等设置，测试人员也可以手动输入相应参数信息，以实现行情服务容灾，提升了自动化用例的可执行性，避免了行情查询单点异常而自动化用例完全失效的灾难。

步骤402：响应于测试指令，执行该测试指令指定的测试用例。

本申请实施例中，具体的，可以通过测试工具的用例执行层来执行测试指令指定的测试用例。

具体的，由于在ETE测试中，不同测试用例对应的业务场景可能会被限制时段进行，因此不同测试用例对应着各自的可执行时段，为减少测试人员的操作，测试人员可一键发起部分测试用例或者全部测试用例的测试，用例执行层可监测各测试用例的可执行时间是否到达，在监测到至少一个测试用例的可执行时间到达时，则执行这至少一个测试用例，或者，测试人员也可以设置各个测试用例的执行时间，当监控到至少一个测试用例的执行时间到达时，则执行这至少一个测试用例。

由于每一测试用例执行的过程是类似的，因此下面以一个测试用例为例进行介绍。

步骤403：根据测试用例设定的测试所需的行情参数，从实时行情系统获取测试用例所需的行情参数信息。

本申请实施例中，用例执行层在执行测试用例的过程中，为生成业务请求包，首先需要准备好每个测试用例所需的用例数据。

如图5中用例数据准备过程所示，用例数据包括行情参数信息，从而根据行情参数信息来生成相应的业务请求包，因此，用例执行层可以调用行情查询模块来从实时行情系统中查询相应的行情参数信息，行情查询模块可按照一定的协议格式返回给用例执行层使用。

如图7所示，为以证券交易系统为例，与待测券商交易系统适配的逻辑示意图。在用例执行层执行测试用例且需要获取行情参数信息时，可以调用行情查询模块获取行情参数信息，行情查询模块则可以根据预先设定的配置文件确定当前执行的测试用例对应的商户，选择对应商户的实时行情系统进行查询，并返回给用例执行层。

其中，由于每个券商行情系统所采用的行情参数信息的格式可能有所不同，行情查询模块还可以将对行情参数信息进行解析，以将格式统一转化为设定的协议格式后，再返给用例执行层。

步骤404：根据为测试用例设置的异常测试要求以及行情参数信息，确定测试用例完成异常测试要求所需的异常数据。

在实际使用场景中，会存在到一些异常委托请求，例如委托请求中委托金额超过100W或者超过24档的价格，以及参数缺失等，因此，在进行测试时，仍然需要考虑这些异常场景。

具体的，当该测试用例并不涉及异常场景时，则用例执行层获取行情参数信息之后，则可以直接根据行情参数信息设置用例数据，例如将订单中的购入数量设置为从行情系统获取的需要购买的最小数量，即每手数量。其中，如图5中所示，用例执行层可以行情计算模块完成用例数据的设置。此外，由于每一笔委托的委托标识(entrust_id)不能重复，如果entrust_id相同可能导致测试用例失败，因此为了保证entrust_id的唯一性，用例执行层还会生成entrust_id，并且还可以通过图5所示的数据处理模块将该委托相关的委托信息写入至数据库中，例如包括entrust_id、买卖方向、订单类型、价格以及数量等信息，后续还可以通过图5中的数据处理模块基于该entrust_id从数据库读取对应的委托信息，从而判断当前委托是否符合预期。

本申请实施例中，针对异常场景设置有对应的异常测试用例，在异常测试用例中，会设置好异常测试要求，用例执行层执行异常测试用例时，则会调用异常构造服务模块，来完成异常数据的构造。例如异常测试要求委托金额超过100W时，则异常构造服务模块可以根据当前价格和每手数量等行情参数信息计算订单的委托金额为100W所需要的购买数量，并返回给测试用例层，则用例执行层可以异常构造服务模块返回的值，以及获取行情参数信息通过行情计算模块完成用例数据的设置。并且，数据处理模块也会确定本次执行的测试用例的entrust_id，并将本次测试用例涉及的entrust_id等委托信息写入数据库。

其中，在图5中的所示中，针对异常测试用例，行情计算模块可以理解为异常构造服务模块的功能和正常用例时的行情计算模块所进行的功能的结合。

需要声明的是，用例执行层可以根据测试用例的要求判断是否需要调用异常构造服务模块，当无需调用异常构造服务模块时，则步骤404也无需执行。

步骤405：用例执行层根据测试用例，设置业务场景参数信息。

本申请实施例中，不同测试用例用于模拟待测交易系统中不同业务场景对应的业务。如图8所示，为测试中ETE测试中的场景示意图。

依据委托的请求类型的不同，场景可以包括基础委托请求、交易报告(TradeCapture Report，TCR)请求和OBO(On Behalf Of)请求等场景。其中，基础委托请求可包括下单(New Order)、改单(Amend Request)、撤单(Cancel Request)和批量撤单(MassCancel Request)等方面的基础委托请求，批量撤单还可进一步针对所有未完成订单、某市场或者某个股票进行批量撤单。TCR请求可包括下单(Trade Submit)和撤单(TradeCancel)等方面的TCR请求。OBO请求是指替代他人进行一定的操作，例如在证券交易系统中，一般某个券商有多个席位，可以通过另一个席位B去撤销之前席位A提交的委托，席位B提交的请求即为OBO请求，OBO请求可以包括OBO撤单(OBO Cancel Request)和OBO批量撤单(OBO Mass Cancel Request)等方面的OBO请求。

依据委托的订单场景的不同，场景可以根据买卖方向、改单类型和订单类型的不同进行划分。其中，买卖方向例如可以包括买入、卖出和卖空；改单类型可以包括改价格和改数量，改价格可进一步包括将价格改高和将价格改低，改数量可进一步包括将数量改大和将数量改小；订单类型可包括竞价单、限价单、竞价限价单、增强限价单和特别限价单等。

依据交易时段的限制，场景可以划分为盘前竞价时段(POS)、持续交易时段(CTS)和收市竞价时段(CAS)等场景。其中，盘前竞价时段可以包括输入买卖盘阶段(OrderInput，OI)、对盘前阶段(Pre-order Matching)、对盘阶段(order Matching)和暂停阶段(Blocking)；收市竞价时段可以包括参考价定价阶段(Reference Price Fixing，RPfixing)、输入买卖盘阶段(Order Input，OI)、不可取消阶段(No Cancellation，NC)、随机收市阶段(Randon Closing，RC)、对盘阶段(order Matching)和交易日结束(Day Close)等。

异常场景可以包括参数异常、委托金额超过市值上限、价格偏离二十档、使用不可用的证券代码发起委托、在特定的交易时段发起错误的委托、CAS时段价格超过参考价定价(Reference Price)的5％、CAS时段的OI阶段对不支持卖空的证券进行卖空操作以及触发时长波动调节机制(VCM)再进行下单等异常场景。其中，参数异常可包括文本(text)字段超长、未知证券代码和证券代码源(Security ID Source)为空等异常；超过市值上限可以包括打开市值校验和关闭市值校验等异常、价格偏离二十档可以包括打开价格校验和关闭价格校验等异常；在特定的交易时段发起错误的委托可包括NC阶段不允许撤单但发起了撤单委托、NC/RC阶段对竞价限价卖空单进行改大、不支持CAS时段的证券、在RP fixing阶段下单以及CAS的OI阶段，竞价限价卖空单，价格低于当前价等。

基于上述的场景划分可组合得到更多的场景，例如将基础委托请求中的下单和订单场景中的买入进行组合，则可以得到一个买卖方向为买入的下单请求。

当然，在实际应用场景中，还可以包括其他的场景，本申请实施例对此不做限制。

每一测试用例设置好了对应的业务场景，进而在测试用例执行过程中，用例执行层相应设置业务场景参数信息，例如设置委托基本属性为订单类型为增强限价单、买卖方向为买入等。

本申请实施例中，基于上述的过程，则可以将测试用例所需的用例数据准备完成，后续则可以利用这些用例数据进行组串，生成业务请求包。

步骤406：根据测试用例所需的用例数据生成该测试用例对应的业务请求包。

本申请实施例中，用例执行层获取用例数据之后，用例数据可以包括行情参数信息以及业务场景参数信息等用例数据，则可以根据用例数据生成该测试用例对应的业务请求包。当然，对于异常场景，用例数据还包括上述异常构造服务模块构造的异常数据。

具体的，用例执行层可以调用协议解析服务模块进行协议组装，来得到业务请求字符串。其中，协议解析服务模块对于不同类型的请求，可以根据调用参数进行自动协议串拼接，返回符合测试用例要求的业务请求字符串。

其中，协议解析服务模块可以根据不同类型的请求确定该测试用例对应的协议，再根据协议中为每一用例数据设定的填充位置，在相应的位置填充相应的用例数据，以得到业务请求字符串。

用例执行层从协议解析服务获取到符合测试用例要求的业务请求字符串后，由于每一个商户的交易服务的协议不尽相同，因此在向券商交易系统的网关发送请求之前，需要根据各商户的通信方式，实现各自的发包工具。

具体的，参见图7所示，用例执行层获取业务请求字符串后，可以调用交易适配模块确定待测交易系统所属商户的标识信息，根据标识信息调用对应的发包工具将业务请求字符串封装为业务请求包，然后再发给对应的网关。例如，交易适配模块可以通过配置文件判断所选用的券商，将传入的统一格式的业务请求字符串转化为指定发包工具的预期请求格式的业务请求包，进而将业务请求包送达对应券商的网关。

在证券交易系统中，一个业务请求包则是一项证券交易委托，用于实现一次操作，例如购入一定数量的股票，卖出一定数量的股票等。

步骤407：利用业务请求包通过网关模拟测试用例对应的业务交互过程。

本申请实施例中，获取业务请求包之后，则可以调用网关服务将业务请求包发送给交易所。其中，网关提供网关服务，对业务请求包进行协议级别的合法性校验，再发送给交易所。

当然，在实际测试过程中，一个测试用例可能涉及多次与交易所的交互过程，那么可以预先将多次交互的业务请求包准备好，在确定接收到一个业务响应包之后，再将下一业务请求包通过网关发送给交易所，或者，也可以在确定接收到一个业务响应包之后，再准备本次需要的业务请求包，并通过网关发送给交易所。

步骤408：根据从网关获取的日志文件中测试用例对应的日志内容确定该测试用例的测试结果。

待测交易系统的网关在测试过程中会产生日志文件，则可以根据网关的日志文件进行分析，以确定每一测试用例的执行结果。

在具体实施过程中，通常交易所的下单成功响应包以及成交响应包是异步的，例如下单成功之后，成交可能发生在下单成功的很久之后，而生产环境的数据库不允许非交易服务进行查询，所以用例执行层无法感知到目前测试用例中交易订单的变化，因此，如图5所示，本申请实施例设置了额外的日志筛选脚本，将测试用例测试结果审查所需的信息进行实时筛选，并记录到数据库中。

如图9所示，为日志筛选脚本的工作过程示意图，日志筛选脚本可以遍历网关的日志文件列表(log_list)，获取各日志文件的文件名(file_name)、文件大小(file_size)以及上次查询的文件位置(last_position)等，若确定当前日志文件列表的末尾位置与上一次查询的日志文件列表的末尾位置是否相同，当确定当前日志文件列表的末尾位置与上一次查询的日志文件列表的末尾位置不相同时，确定存在更新的日志文件，进而可以对更新的日志文件进行解析。具体的，日志筛选脚本可以从更新的日志文件中筛选各测试用例的业务请求包与业务响应包。其中，在进行筛选时，可以据业务请求包以及业务响应包对应的关键字段，从日志文件中筛选得到各测试用例的业务请求包与业务响应包，并可将业务请求包与业务响应包或者各业务请求包与业务响应包的关键字段存储至数据库中。

在筛选各测试用例的业务请求包与业务响应包之后，日志筛选脚本还可以对筛选得到的各测试用例的业务请求包与业务响应包进行解析，获取各业务请求包与业务响应包的内容，进而从各业务请求包与业务响应包的内容中提取设定的关键字段对应内容，并将提取的内容存储至数据库中。例如设定的关键字段可以是测试用例的编号或者订单号等能够区分各不同测试用例的业务请求包与业务响应包的内容。

本申请实施例中，如图5所示，一个测试用例的测试步骤全部执行完毕后，用例执行层则可以调用结果审查服务模块进行结果检查，以确定测试用例的执行结果。其中，结果审查服务模块按照测试用例包括的各执行步骤的执行顺序，逐步确定执行步骤的执行结果是否正确，在确定测试用例包括的其中一个执行步骤的执行结果不正确时，确定测试用例测试未通过；或者，在测试用例包括的所有执行步骤的执行结果均正确时，确定测试用例测试通过。

参见图10所示，为结果审查服务模块的工作过程示意图。其中，通常每一个步骤的每一个业务请求包都会有唯一标识，因此结果审查服务模块可以将该步骤对应的业务请求包的标识作为步骤标识，从数据库汇总查询对应的日志信息，以确定该步骤是否测试通过。其中，每一步骤都会设置一个预期执行结果，因而可以将日志中的实际执行结果与预期执行结果进行比较，一致时，则该步骤测试通过，反之则未通过。

步骤409：根据测试报告的要求自动进行填充。

本申请实施例中，测试报告的填充可以通过测试报告自动填充脚本来实现。其中，测试报告是需要按照交易所提供的格式进行填写，参见图11所示，为测试报告自动填充脚本的工作流程示意图，测试报告自动填充脚本通过解析测试报告中各个工作表，判断当前行是否需要进行数据填充，若需要填充，则根据测试报告中各行或者列对应的测试用例标识，从数据库中获取该测试用例对应的测试数据，再根据各行或者列包括的表项对应的关键字段，从测试数据中获取关键字段对应值，并填充至表项中。

例如，可以根据当前行的测试用例标识，从数据库中获取对应的请求串信息以及业务响应包信息等，再根据各列对应的字段，从获取到的数据中解析出对应值，记录下对应的坐标，最后测试报告自动填充脚本遍历已解析出的数据，填充到指定的工作表坐标中。

下面具体以一个测试用例的测试过程为例对本申请实施例的过程进行介绍。如图12所示，为对证券交易系统的网关进行测试的流程示意图，其中，图12中以异常场景为例。

S1201：测试人员在前端页面选择需要执行的测试用例。例如测试人员选的测试用例编号为B1.6.2。

S1202：用例执行层从测试用例库调用指定的测试用例执行。

S1203：用例执行层根据该测试用例配置的股票代码，调用行情查询模块，从对应证券交易系统的行情查询服务获取当前价格、每档增加的价格以及每手数量等行情参数信息。

S1204：用例执行层根据测试用例要求调用异常构造服务模块进行异常数据构造。例如，B1.6.2要求市值超过100W，此时会调用异常构造服务，计算订单的委托金额超过100W所需要的交易数量。当然，对于正常场景的测试用例，不会有异常测试要求。

S1205：用例执行层根据测试用例的业务场景设置业务场景参数信息，如设置委托基本属性为B1.6.2要求增强现价单和买卖方向为买入。

S1206：用例执行层调用协议解析服务模块，协议解析模块根据业务场景参数信息和行情参数信息拼接对应的业务请求字符串并返回给用例执行层。例如，基于B1.6.2的当前请求类型为普通下单委托请求，以及基本参数包括的股票代码以及行情参数信息，如价格、数量等，拼接对应的网关服务请求串并返回给用例执行层。

其中，当异常为参数缺失等类型的异常时，可以在组装得到业务请求字符串后，再调用异常构造服务模块进行异常构造。

S1207：用例执行层获取到业务请求字符串后，调用交易适配模块，将业务请求字符串封装为业务请求包，并通过待测证券交易系统的网关服务，将该业务请求包发送到证券交易所。交易适配模块对业务请求字符串的封装过程即为将业务请求字符串转化为券商对应的交易服务协议格式的请求。

S1208：用例执行层将该测试用例的用例信息存储至数据库中，例如上述用例数据以及业务请求字符串等信息。

S1209：日志筛选脚本实时监控网关服务的日志中该测试用例的业务请求包和业务响应包，以将该测试用例执行产生的发送请求通过sts_out_str关键字筛选并解析各字段落入数据库，将港交所返回的回报通过sts_in_str关键字筛选并解析各字段落入数据库。

日志筛选脚本的过程可以是循环进行的，即在测试进行过程中，日志筛选脚本的日志监控和筛序是循环持续进行的。

S1210：用例执行层调用结果审查服务模块通过当前测试用例对应关键字段查询数据库，获取对应的用例数据，逐步判断该测试用例的各执行步骤是否通过测试。例如，结果审查服务模块可通过该测试用例生成的txEntrustId关键字段查询数据库，获取对应的港交所回包数据，其委托执行类型应为下单拒绝，订单状态为下单失败，错误原因为超过市值，与预期执行结果符合即该测试用例通过测试。

用例执行层可以将测试用例的执行结果返回给前端进行显示，以便测试人员查看。

综上所述，本申请实施例提供统一的协议解析服务，自动化用例中设置协议参数，并通过行情查询模块查询后自动填充行情参数信息，避免人工组装请求串出现异常，降低人为出错的概率。此外，本申请实施例中可以定时执行或一键发起用例执行，无需人工输入参数，大大降低用例测试时间，并且通过配置化商户标识，以及实现行情查询模块、交易适配模块的架构，从而可支持多商户接入，对于各商户进行个性化实现，自动选择对应商户执行路径。

此外，本申请实施例还可以实时监控待测交易系统的网关日志并录入数据库，通过平台实时展示用例执行的业务响应包内容，排除无关日志信息，便于观察，并且通过结果审查服务，自动判断用例执行结果，提高用例检查效率。此外，还可以使用python xrld模块解析未填充的测试报告，读取对应用例的日志信息，再将解析后的日志信息通过xlwt模块自动填充到报告中，大大降低人工筛选和填写报告的时间成本。

可见，本申请实施例的测试方案大大减少了新测试人员对协议的理解成本，避免了错误的请求信息影响测试有效性，完整覆盖了ETE测试所要求的所有用例，降低人工填写测试报告的时间成本，同时通过配置化支持多券商切换，提高了自动化方案的可移植性，通过前端关键参数选择性输入进行股票行情服务容灾，提升了自动化的可执行性，避免了行情查询单点异常而自动化完全失效的灾难。目前，ETE测试人力投入可由最开始的5人4天，优化到了2人2天，时间成本减少达80％，可见本申请实施例的测试方案大大节约了时间成本。

请参见图13，基于同一发明构思，本申请实施例还提供了一种系统测试装置130，该装置包括：

用例执行单元1301，用于响应于测试指令，执行测试指令指定的测试用例，测试指令用于指示对待测交易系统的网关进行测试；其中，不同测试用例用于模拟待测交易系统中不同业务场景对应的业务过程；

请求包生成单元1302，用于根据每一测试用例所需的用例数据，生成每一测试用例对应的业务请求包；用例数据包括为每一测试用例设定的业务场景参数信息，以及从实时行情系统获取的每一测试用例所需的行情参数信息；

用例执行单元1301，还用于利用业务请求包通过网关模拟每一测试用例对应的业务交互过程；

测试结果确定单元1303，用于根据从网关获取的日志文件中每一测试用例对应的日志内容确定每一测试用例的执行结果，并根据各测试用例的执行结果得到网关的测试结果。

可选的，用例执行单元1301，用于：

监测各测试用例的执行时间是否到达；

在监测到至少一个测试用例的执行时间到达时，执行至少一个测试用例。

可选的，请求包生成单元1302，用于：根据每一测试用例所需的用例数据得到每一测试用例对应的业务请求字符串；

根据业务请求字符串进行封装，得到每一测试用例对应的业务请求包。

可选的，请求包生成单元1302，用于：

根据业务场景参数信息确定每一测试用例对应的协议；

根据协议中为每一行情参数信息设定的填充位置，在相应的位置填充相应的行情参数信息，以得到业务请求字符串。

可选的，该装置还包括异常构造单元1304：

异常构造单元1304用于：根据为每一测试用例设置的异常测试要求以及行情参数信息，确定每一测试用例完成异常测试要求所需的异常数据；

则请求包生成单元1302，用于：根据为每一测试用例所需的用例数据以及异常数据得到每一测试用例对应的业务请求字符串。

可选的，请求包生成单元1302，用于：

确定待测交易系统所属商户的标识信息；

根据标识信息调用对应的发包工具将业务请求字符串封装为业务请求包。

可选的，该装置还包括日志筛选单元1305，用于：

根据业务请求包以及业务响应包对应的关键字段，从日志文件中筛选得到各测试用例的业务请求包与业务响应包；

对筛选得到的各测试用例的业务请求包与业务响应包进行解析，获取各业务请求包与业务响应包的内容；

从各业务请求包与业务响应包的内容中提取设定的关键字段对应内容，并将提取的内容存储至数据库中。

可选的，日志筛选单元1305，用于：

遍历日志文件列表，并确定当前日志文件列表的末尾位置与上一次查询的日志文件列表的末尾位置是否相同；

当确定当前日志文件列表的末尾位置与上一次查询的日志文件列表的末尾位置不相同时，确定存在更新的日志文件；

从更新的日志文件中筛选各测试用例的业务请求包与业务响应包。

可选的，测试结果确定单元1303，用于：

按照每一测试用例包括的各执行步骤的执行顺序，逐步确定每一执行步骤的执行结果是否正确；

在确定每一测试用例包括的其中一个执行步骤的执行结果不正确，确定每一测试用例测试未通过；或者，

在每一测试用例包括的所有执行步骤的执行结果均正确时，确定每一测试用例测试通过。

可选的，该装置还包括报告填充单元1306，用于：

根据测试报告中各行或者列对应的测试用例标识，从数据库中获取该测试用例对应的测试数据；

根据各行或者列包括的表项对应的关键字段，从测试数据中获取关键字段对应值，并填充至表项中。

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

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

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

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

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

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

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

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

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

Claims (15)

1.一种系统测试方法，其特征在于，所述方法包括：

响应于测试指令，执行所述测试指令指定的测试用例，所述测试指令用于指示对待测交易系统的网关进行测试；其中，不同测试用例用于模拟所述待测交易系统中不同业务场景对应的业务过程；

根据所述每一测试用例所需的用例数据，生成所述每一测试用例对应的业务请求包；所述用例数据包括为所述每一测试用例设定的业务场景参数信息，以及从实时行情系统获取的所述每一测试用例所需的行情参数信息；

利用所述业务请求包通过所述网关模拟所述每一测试用例对应的业务交互过程；

根据从所述网关获取的日志文件中所述每一测试用例对应的日志内容确定所述每一测试用例的执行结果，并根据各测试用例的执行结果得到所述网关的测试结果。

2.如权利要求1所述的方法，其特征在于，响应于测试指令，执行所述测试指令指定的测试用例，包括：

监测各测试用例的执行时间是否到达；

在监测到至少一个测试用例的执行时间到达时，执行所述至少一个测试用例。

3.如权利要求1所述的方法，其特征在于，根据所述每一测试用例所需的用例数据，生成所述每一测试用例对应的业务请求包，包括：

根据所述每一测试用例所需的用例数据得到所述每一测试用例对应的业务请求字符串；

根据所述业务请求字符串进行封装，得到所述每一测试用例对应的业务请求包。

4.如权利要求3所述的方法，其特征在于，根据所述每一测试用例所需的用例数据得到所述每一测试用例对应的业务请求字符串，包括：

根据所述业务场景参数信息确定所述每一测试用例对应的协议；

根据所述协议中为每一行情参数信息设定的填充位置，在相应的位置填充相应的行情参数信息，以得到所述业务请求字符串。

5.如权利要求3或4所述的方法，其特征在于，在根据所述每一测试用例所需的用例数据得到所述每一测试用例对应的业务请求字符串前，所述方法包括：

根据为所述每一测试用例设置的异常测试要求以及所述行情参数信息，确定所述每一测试用例完成所述异常测试要求所需的异常数据；

根据所述每一测试用例所需的用例数据得到所述每一测试用例对应的业务请求字符串，包括：

根据为所述每一测试用例所需的用例数据以及所述异常数据得到所述每一测试用例对应的业务请求字符串。

6.如权利要求3所述的方法，其特征在于，根据所述业务请求字符串进行封装，得到所述每一测试用例对应的业务请求包，包括：

确定所述待测交易系统所属经纪席位的标识信息；

根据所述标识信息调用对应的发包工具将所述业务请求字符串封装为所述业务请求包。

7.如权利要求1所述的方法，其特征在于，在根据从所述网关获取的日志文件中所述每一测试用例对应的日志内容确定所述每一测试用例的测试结果之前，所述方法还包括：

根据业务请求包以及业务响应包对应的关键字段，从所述日志文件中筛选得到各测试用例的业务请求包与业务响应包；

对筛选得到的各测试用例的业务请求包与业务响应包进行解析，获取各所述业务请求包与所述业务响应包的内容；

从各所述业务请求包与所述业务响应包的内容中提取设定的关键字段对应内容，并将提取的内容存储至数据库中。

8.如权利要求7所述的方法，其特征在于，根据业务请求包以及业务响应包对应的关键字段，从所述日志文件中筛选得到各测试用例的业务请求包与业务响应包，包括：

遍历日志文件列表，并确定当前日志文件列表的末尾位置与上一次查询的日志文件列表的末尾位置是否相同；

当确定当前日志文件列表的末尾位置与上一次查询的日志文件列表的末尾位置不相同时，确定存在更新的日志文件；

从更新的日志文件中筛选各测试用例的业务请求包与业务响应包。

9.如权利要求1、7或8所述的方法，其特征在于，根据从所述网关获取的日志文件中所述每一测试用例对应的日志内容确定所述每一测试用例的测试结果，包括：

按照所述每一测试用例包括的各执行步骤的执行顺序，逐步确定每一执行步骤的执行结果是否正确；

在确定每一测试用例包括的其中一个执行步骤的执行结果不正确，确定所述每一测试用例测试未通过；或者，

在所述每一测试用例包括的所有执行步骤的执行结果均正确时，确定所述每一测试用例测试通过。

10.如权利要求1所述的方法，其特征在于，在根据从所述网关获取的日志文件中所述每一测试用例对应的日志内容确定所述每一测试用例的测试结果之后，所述方法还包括：

根据测试报告中各行或者列对应的测试用例标识，从数据库中获取该测试用例对应的测试数据；

根据各行或者列包括的表项对应的关键字段，从所述测试数据中获取所述关键字段对应值，并填充至所述表项中。

11.一种系统测试装置，其特征在于，所述装置包括：

用例执行单元，用于响应于测试指令，执行所述测试指令指定的测试用例，所述测试指令用于指示对待测交易系统的网关进行测试；其中，不同测试用例用于模拟所述待测交易系统中不同业务场景对应的业务过程；

请求包生成单元，用于根据所述每一测试用例所需的用例数据，生成所述每一测试用例对应的业务请求包；所述用例数据包括为所述每一测试用例设定的业务场景参数信息，以及从实时行情系统获取的所述每一测试用例所需的行情参数信息；

所述用例执行单元，还用于利用所述业务请求包通过所述网关模拟所述每一测试用例对应的业务交互过程；

测试结果确定单元，用于根据从所述网关获取的日志文件中所述每一测试用例对应的日志内容确定所述每一测试用例的执行结果，并根据各测试用例的执行结果得到所述网关的测试结果。

12.如权利要求11所述的装置，其特征在于，所述用例执行单元，用于：

监测各测试用例的执行时间是否到达；

在监测到至少一个测试用例的执行时间到达时，执行所述至少一个测试用例。

13.如权利要求11所述的装置，其特征在于，所述请求包生成单元，用于:

根据所述每一测试用例所需的用例数据得到所述每一测试用例对应的业务请求字符串；

根据所述业务请求字符串进行封装，得到所述每一测试用例对应的业务请求包。

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

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

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

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

Images