CN118069519A - 电子商业汇票业务测试方法、装置及电子设备 - Google Patents

Abstract

本申请提出了一种电子商业汇票业务测试方法、装置及电子设备，由测试人员直接从目标票据的业务测试界面显示的多个交易项目中灵活选择出待测交易项目，获取其测试数据、测试交易脚本和测试次数后，自动使用该测试数据运行测试交易脚本多次，重复对这一个待测交易项目进行测试，来随机模拟实现待测交易项目的多个票据报文的处理顺序，通过验证每次测试是否符合相应的交易验证规则，得到待测交易项目的测试结果后输出，有效提高了票据报文的处理逻辑存在偶发性缺陷的发现率，无需人工过多干预，省时省力，提高了测试效率以及所得测试结果的可靠性。

Description

电子商业汇票业务测试方法、装置及电子设备

技术领域

本申请涉及电子商业汇票应用领域，更具体地说是涉及一种电子商业汇票业务测试方法、装置及电子设备。

背景技术

电子商业汇票是一种电子票据，是由出票人以数据电文形式制作，委托付款人在指定日期无条件支付确定金额给收款人或者持票人的票据，可以通过电子商业汇票系统(即业务处理平台)依据流转的票据报文，对其执行如票据状态、流通标志或本/下手持票人等变更操作，实现如背书、质押或贴现等票据业务。

在实际票据交易场景(如任一票据业务的任一票据交易流程)下，通常是由多个票据报文组合完成该票据交易，且受票交所环境等因素影响，多个票据报文到达系统前置机的顺序是随机的，若某票据报文的处理逻辑存在缺陷，按照不同到达顺序执行这多个票据报文的处理逻辑，可能会对相应票据执行正确变更操作，也可能会执行错误变更操作，从而影响后续票据业务。

因此，在测试人员对上述票据交易场景进行测试过程中，即按照实现该票据交易的多个票据报文的随机处理顺序，编写相应的测试案例进行测试，很难发现其中的某票据报文的处理逻辑存在缺陷，降低了票据业务测试结果的可靠性和测试效率。

发明内容

为了解决上述技术问题，提高票据报文偶发性缺陷发现率，保证业务测试结果的可靠性，提高不同票据业务场景的测试效率和便利性，本申请提供了以下技术方案：

一方面，本申请提出了一种电子商业汇票业务测试方法，所述方法包括：

输出针对目标票据的业务测试界面，在所述业务测试界面显示有所述目标票据的多个交易项目；所述交易项目是指实现所述目标票据的任一票据业务的任一交易流程；

响应于对所述交易项目的测试选择指令，确定所选择的待测交易项目；

获取所述待测交易项目的测试数据、测试交易脚本以及测试次数；所述测试交易脚本能够表示实现所述待测交易项目的票据交易链路以及交易验证规则；

响应于对所述待测交易项目的测试触发指令，利用所述测试数据、所述交易验证规则以及所述测试次数，运行所述测试交易脚本，得到针对所述待测交易项目的测试结果；所述测试交易脚本运行过程中按照所述票据交易链路对实现所述待测交易项目的多个所述交易流程各自的票据报文的处理顺序具有随机性；

输出所述测试结果。

可选的，所述获取所述待测交易项目的测试交易脚本，包括：

确定已生成并存储针对所述目标票据的全量交易脚本；

从所述全量交易脚本中，确定出用于实现所述待测交易项目的测试交易脚本；

其中，所述全量交易脚本包括用于实现所述目标票据的不同票据业务的各交易流程的交易脚本。

可选的，所述生成并存储针对所述目标票据的全量交易脚本，包括：

响应于针对所述目标票据的交易流程信息获取指令，依据用于实现所述目标票据的不同票据业务的各交易流程，获取相应所述交易流程的接口传输信息；

基于所述接口传输信息，确定不同所述交易流程的票据报文之间的流转关系；

获取不同所述票据业务的各所述交易流程的交易验证规则；

响应于针对所述目标票据的脚本生成触发指令，调用脚本生成工具，利用所述流转关系和所述交易验证规则，生成针对所述目标票据的全量交易脚本；

将所述全量交易脚本与所述目标票据关联后存储。

可选的，所述基于所述接口传输信息，确定不同所述交易流程的票据报文之间的流转关系，包括：

基于所述接口传输信息，确定所述目标票据的不同所述票据业务包含的各交易流程之间的业务逻辑关系；

基于所述业务逻辑关系，确定不同所述交易流程的票据报文传输接口之间的连接关系；

利用所述连接关系，得到不同所述交易流程的票据报文之间的流转关系。

可选的，所述获取所述待测交易项目的测试数据，包括：

确定已存储有所述目标票据的全量初始化数据；所述全量初始化数据包括用于实现所述目标票据的不同票据业务的各票据流程的必要输入数据，所述必要输入数据基于通过正则表达式从所述票据交易链路中提取出的票据报文传输接口参数确定；

从所述全量初始化数据中，读取用于实现所述待测交易项目的必要输入数据为测试数据。

可选的，所述获取所述待测交易项目的测试数据，包括：

输出针对所述待测交易项目的测试配置界面；

响应于对所述测试配置界面的测试数据输入操作，得到所述待测交易项目的测试数据；

其中，所述测试数据输入操作是基于所述测试配置界面中显示的数据输入提示信息执行，所述数据输入提示信息用于引导输入实现所述待测交易项目的必要输入数据，所述必要输入数据基于通过正则表达式从所述票据交易链路中提取出的票据报文传输接口参数确定。

可选的，所述利用所述测试数据、所述交易验证规则以及所述测试次数，运行所述测试交易脚本，得到针对所述待测交易项目的测试结果，包括：

利用所述测试数据，运行所述测试交易脚本，以按照所述票据交易链路，响应相应所述交易流程的票据报文，确定所述待测交易项目执行后的票据交易结果；

检测所述票据交易结果是否符合所述交易验证规则，得到本次针对所述待测交易项目的测试结果。

可选的，所述交易验证规则用于在按照所述票据交易链路执行所述待测交易项目后，验证所述目标票据的票据状态、流程标志、本手持票人以及下手持票人是否为对应的预期更新信息。

另一方面，本申请还提出了一种电子商业汇票业务测试装置，所述装置包括：

业务测试界面输出模块，用于输出针对目标票据的业务测试界面，在所述业务测试界面显示有所述目标票据的多个交易项目；所述交易项目是指实现所述目标票据的任一票据业务的任一交易流程；

待测交易项目确定模块，用于响应于对所述交易项目的测试选择指令，确定所选择的待测交易项目；

获取模块，用于获取所述待测交易项目的测试数据、测试交易脚本以及测试次数；所述测试交易脚本能够表示实现所述待测交易项目的票据交易链路以及交易验证规则；

测试模块，用于响应于对所述待测交易项目的测试触发指令，利用所述测试数据、所述交易验证规则以及所述测试次数，运行所述测试交易脚本，得到针对所述待测交易项目的测试结果；所述测试交易脚本运行过程中按照所述票据交易链路对实现所述待测交易项目的多个所述交易流程各自的票据报文的处理顺序具有随机性；

测试结果输出模块，用于输出所述测试结果。

又一方面，本申请还提出了一种电子设备，所述电子设备包括：显示器和处理器，其中：

所述显示器，用于输出针对目标票据的业务测试界面，在所述业务测试界面显示有所述目标票据的多个交易项目；所述交易项目是指实现所述目标票据的任一票据业务的任一交易流程；

所述处理器，用于响应于对所述交易项目的测试选择指令，确定所选择的待测交易项目，获取所述待测交易项目的测试数据、测试交易脚本以及测试次数，响应于对所述待测交易项目的测试触发指令，利用所述测试数据、交易验证规则以及所述测试次数，运行所述测试交易脚本，得到针对所述待测交易项目的测试结果；其中，所述测试交易脚本能够表示实现所述待测交易项目的票据交易链路以及所述交易验证规则，所述测试交易脚本运行过程中按照所述票据交易链路对实现所述待测交易项目的多个所述交易流程各自的票据报文的处理顺序具有随机性；

所述显示器还用于输出所述测试结果。

由此可见，本申请提出了一种电子商业汇票业务测试方法、装置及电子设备，可以由测试人员直接选择目标票据的任一票据业务的任一交易流程为待测交易项目，获取其测试数据、测试交易脚本和测试次数后，自动使用该测试数据运行测试交易脚本多次，重复对这一个待测交易项目进行测试，来随机模拟实现待测交易项目的多个票据报文的处理顺序，通过验证每次测试是否符合相应的交易验证规则，得到待测交易项目的多个测试结果，相对于人工只能对目标票据的待测交易项目执行一次测试，得到一个测试结果的测试方法，本申请有效提高了票据报文的处理逻辑存在偶发性缺陷的发现率，无需人工过多干预，省时省力，提高了测试效率以及所得测试结果的可靠性。

附图说明

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

图1为本申请提出的电子商业汇票业务测试方法的可选实施例一的流程示意图；

图2为本申请提出的电子商业汇票业务测试方法的可选实施例二的流程示意图；

图3为本申请提出的电子商业汇票业务测试方法的可选实施例三的流程示意图；

图4为本申请提出的电子商业汇票业务测试方法中，实现任一票据业务场景的多个票据报文之间的流转关系示意图；

图5为本申请提出的电子商业汇票业务测试装置的可选实施例一的结构示意图；

图6为本申请提出的电子商业汇票业务测试装置的可选实施例二的结构示意图；

图7为适用于本申请提出的电子商业汇票业务测试方法的电子设备的一可选实施例的硬件结构示意图。

具体实施方式

对于背景技术部分描述的技术问题，下面以测试质押业务场景为例进行说明，在流转的票据报文为参与者申请方向票交所(如上海票据交易所)发送质押申请NES.009.001报文，票交所收到该质押申请报文后，会向参与者申请方发送通用业务确认CIM.001.002报文，向参与者回复方发送通用业务转发CIM.003.002报文和票据详细信息下发CIM.025.001报文，票据状态不发生变化，为已收到票据，票据状态由可流通状态变为已锁定状态，本手持票人不变，下手持票人更新为质权人。

在上述票据质押交易过程中，若票交所同时发送CIM.001.002报文和CIM.003.002报文，受网络和硬件资源等因素影响，这两个票据报文到达前置机的顺序随机，而这两个票据报文的处理逻辑是不同的，可能会造成不同的票据处理结果。假设CIM.001.002报文和CIM.003.002报文都是用于对本/下手持票人信息进行更新，而CIM.001.002报文的处理逻辑存在缺陷，会导致对本/下手持票人信息的更新不正确，CIM.003.002报文的处理逻辑存在缺陷，据此对本/下手持票人信息的更新正确。

基于此，在票据质押交易过程中，若CIM.001.002报文先流转到达前置机，CIM.003.002报文后流转到达前置机，按照先后达到顺序执行相应票据报文的处理逻辑，因CIM.003.002报文的处理逻辑不存在缺陷，对相应票据的本/下手持票人信息的更新正确；反之，若前置机先收到CIM.003.002报文，后收到CIM.001.002报文，会因CIM.001.002报文的处理逻辑存在缺陷，导致对相应票据的本/下手持票人信息的更新不正确，影响后续的票据业务。

目前测试人员在测试票据质押业务时，电子商业汇票业务(即票据业务)的测试数据不可重复使用，一条测试数据只能使用一次，由于多个业务报文到达顺序的随机性，对其执行一次测试，很可能未发现CIM.001.002报文的处理逻辑存在缺陷，此时不会继续测试同一票据交易(也可以称为一种票据业务场景)，会给出票据业务测试通过的测试结果，显然，该测试结果是不正确的。若一次测试发现上述缺陷，由于电子商业汇票业务的交易流程往往较长，票据业务间依赖关系强，测试票据质押业务之前需要先完成如出票申请、提示承兑申请、承兑回复、提示收票申请、提示收票回复等票据业务，才能够进行票据质押申请。所以，在需要复现缺陷时，至少需要手动做一次这些票据交易流程，大大增大了复现缺陷的成本，耗时耗力，也容易出现其他纰漏而影响这种偶发性缺陷的发现概率。

为了解决采用手工方式实现电子商业汇票业务(即票据业务)测试方法中存在的上述技术问题，提高电子商业汇票报文(即票据报文)偶发性缺陷的发现概率，降低测试成本，保证测试结果可靠性，提高票据业务测试效率，本申请提出依据目标票据(即任一种电子商业汇票)的任一待测交易项目的票据交易链路以及交易验证规则，来生成相应的测试交易脚本，这样，测试人员只需要选择需要对目标票据的任一票据业务的哪个交易流程进行测试，即选择待测交易项目，获取实现该待测交易项目必须输入的测试数据，以及需要对目标票据的同一个待测交易项目执行多少次测试即测试次数之后，可以使用测试数据，循环运行该测试交易脚本，直至运行次数达到该测试次数，实现待测交易项目的多次测试，得到相应的测结果。

其中，结合上文示例分析，按照票据交易连续实现同一个待测交易项目的多个交易流程(其可以属于目标票据的一个或多个票据业务)的票据报文的处理顺序具有随机性，使得每次运行测试交易脚本所执行的这多个票据报文的处理顺序并不一致，能够得到不同的测试结果，相对于上述一个测试结果，本申请有效提高了票据报文偶发性缺陷的发现概率，从而提高了这一个待测交易项目的测试结果的可靠性，提升了测试质量。而且，本申请能够重复执行同一个测试交易脚本，无需测试人员多次编写，省时省力，提高了测试效率。

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。且下文方法实施例描述的前面或后面操作步骤不一定按照顺序来精确地执行，根据实际情况需求，也可以按照倒序或同时处理各个步骤，或者互换特定的顺序或先后次序，还可以依据票据业务处理需求，将其他操作步骤添加到这些实施例描述的实现过程中，或从这些实现过程移除某一步或数步操作步骤，以使下文描述的本申请实施例能够以除了附图所示或文字描述以外的顺序实施，本申请并未一一举例详述。因此，基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

参照图1，为本申请提出的电子商业汇票业务测试方法的可选实施例一的流程示意图，该方法可以适用于电子设备，如智能手机、笔记本电脑、台式电脑或其他业务终端等终端设备，该终端设备也可以与服务器配合实现本申请提出的电子商业汇票业务测试方法。基于此，如图1所示，本实施例提出的电子商业汇票业务测试方法可以包括：

步骤S11，输出针对目标票据的业务测试界面，在业务测试界面显示有目标票据的多个交易项目；

其中，交易项目可以是指实现目标票据的任一票据业务的任一交易流程，也可以称为是一种票据业务场景。票据业务通常可以包括申请类、回复类以及通用信息类等多种类型的业务，每一类票据业务通常需要经过多个交流流程才能实现，本申请对目标票据支持的票据业务类型及其实现包含的交易流程内容不做限制，可视情况而定。需要说明，不同票据业务以及不同交易流程之间往往具有一定依赖关系，可以依据票据法规以及行业内的电子商业汇票系统报文处理规则确定，本申请不做详述。

示例性的，票据业务可以包括但并不局限于票据的出票业务、背书业务、质押业务以及贴现业务等。对于每一个票据包含的多个交易流程，以票据出票业务为例，其可以包括出票申请、提示承兑申请、承兑回复、提示收票申请、提示收票回复等若干交易流程，完成出票业务。

本申请实施例中，在测试人员需要对目标票据的某交易流程(即某一业务场景)进行测试，可以登录票据测试系统，选择该目标票据，进入针对该目标票据的业务测试界面，与此同时，电子设备会依据所选择的目标票据，从服务器或本地存储空间等来源，获取实现目标票据的各票据业务的各交易流程，将每一交易流程作为一个交易项目，显示于业务测试界面的相应区域，本申请对业务测试界面的显示内容及其布局格式不做限制，可以依据实际情况灵活配置/调整。

在一可能实现的实施例中，对于目标票据的多个票据业务可以按照实际处理顺序(即依赖关系)进行顺次排序显示，且每一个票据业务对应的显示区域或级联显示菜单中，也可以按照实现该票据业务的多个交易流程的处理顺序进行排序显示相应交易流程名称或其他标识等，以方便测试人员快速查找当前需要测试的待测交易项目。需要说明的是，关于目标票据的多个票据业务以及每一票据业务包含的多个交易流程的显示方式，并不局限于本实施例描述的排序显示方式，也可以随机显示，或者按照各票据业务和交易流程的显示内容首字母排序进行排序显示等，测试人员也可以依据个人习惯灵活调整显示方式，实现过程本申请不做详述。

步骤S12，响应于对交易项目的测试选择指令，确定所选择的待测交易项目；

继上述分析，测试人员能够从当前输出的业务测试界面上，直观看到目标票据所支持的各业务场景，即上文描述的多个交易项目，可以依据当前测试需求，直接从中选择任一业务场景为当前的待测交易项目。如对业务测试界面上显示的交易项目名称或其他标识进行点击选择或触控选择或语音选择等任一种测试选择操作，电子设备响应该测试选择操作，确定当前选择测试的待测交易项目。本申请对待测交易项目的选择实现方法不做限制。

步骤S13，获取待测交易项目的测试数据、测试交易脚本以及测试次数；测试交易脚本能够表示实现待测交易项目的票据交易链路以及交易验证规则；

在实际应用中，不同票据业务或交易流程可以由相应的参与者实现，如银行机构、非银行机构、资管部门以及存托类业务办理渠道的业务参与者等，在完成一交易流程后会输出相应的票据报文，以触发执行下一交流流程。该票据报文是电子商业汇票系统节点(如交易流程节点)间交换业务数据的基本单位，通常由报文头和报文体组成，其中报文体可以由多个报文块组成，本申请对票据报文的格式及其内容不做限制，可视情况而定。

结合上文对本申请技术方案的相关描述，由于实现票据的任一业务场景的多个票据报文的到达前置机的顺序随机，导致对这多个票据报文的处理顺序随机，本申请希望可以对一个业务场景重复执行多次测试，来提高票据报文偶发性缺陷(如上述示例分析，某一票据报文的处理逻辑存在缺陷，且仅在特定的处理顺序下才能导致票据交易结果异常，其他处理顺序不会影响票据交易结果)的发现概率，以便及时进行纠正，提高票据业务可靠性。

基于此，本申请可以获取实现待测交易项目的票据交易链路，其可由执行待测交易项目及其执行前需要执行的至少一个票据业务的不同交易流程之间的接口参数传输关系表示。每一交易流程具有对应的票据报文传输接口，可以接收其他交易流程的票据报文传输或其他设备接口发送的一种票据报文或数据，按照该交易流程自身的票据报文对应的处理逻辑进行处理，将得到的另一票据报文发送至其他交易流程的票据报文传输接口，经过不同票据报文的流转实现相应票据业务。

因此，票据交易链路所表示的接口参数传输关系可以是实现待测交易项目的多个交易流程各自的票据报文传输接口之间票据报文流转关系，保证了哪个票据报文传输接口输入的票据报文来自哪个票据报文，其处理得到的票据报文将发送至哪个票据报文，这可以依据目标票据的实际业务逻辑关系确定，获取过程本实施例在此不做详述。

待测交易项目的交易验证规则可以依据目标票据的相应票据业务要求(其也可以依据电子商业汇票报文业务处理规则确定)确定，可以包括但并不局限于票据状态、流通标志、本/下手持票人等至少一种变更操作的验证，确定执行待测交易项目后的相应票据交易结果是否为票据业务要求的预期更新信息，如背书申请后，验证票据状态是否为已收票，流通标志是否由可流通更新为已锁定，本手持票人是否为背书申请人，下手持票人是否更新为被背书人等。需要说明的是，对于不同的待测交易项目的交易验证规则的内容可以不同，但并不排除某些待测交易项目的交易验证规则部分相同或完全相同的情况，可以依据实际票据业务要求确定，本实施例不做一一举例详述。

在至少获得待测交易项目的票据交易链路以及交易验证规则后，可以据此生成针对待测交易项目的测试交易脚本，该测试交易脚本可以包含按照该票据交易链路，实现该待测交易项目的各交易流程的处理逻辑，以及按照交易验证规则，对所得票据交易结果进行验证的处理逻辑等，以便后续可以该处理逻辑自动执行相应的计算机指令，无需人工干预。

本申请中，上下文提出的交易脚本是使用一种特定的描述语言，依据一定格式编写的可执行文件，可以使用脚本生成工具，至少利用获取的相应交易项目的票据交易链路以及交易验证规则，自动生成对应的交易脚本，无需人工手动编写，省时省力，且避免了因人工编写错误导致测试失败或测试结果不正确的情况发生，提高了测试结果的可靠性。

可选的，本申请可以使用但并不局限于JMeter这种接口测试工具中的脚本生成功能，来生成各交易脚本，实现过程本申请不做详实。其中，JMeter的运行过程中，可以模拟用户发起各类HTTP(Hypertext Transfer Protocol，超文本传输协议)请求，将请求数据发送至服务端，获取对应的响应结果即票据交易结果，以验证其包含的数据是否和预期值匹配，如票据交易结果是否与相应验证规则中的预期更新信息一致等，本申请对JMeter的接口测试过程及其功能实现过程不做详述。

此外，关于对待测交易项目的测试次数，可以依据实际情况确定，如依据运行测试交易脚本的电子设备的资源配置信息、测试交易脚本的资源消耗量，以及测试场景的测试时长要求等多方面因素确定；当然，也可以依据测试人员的实际经验确定后输入，本申请对测试次数的确定方法及其数值不做限制。通常情况下，执行测试次数越大，发现票据报文偶发性缺陷的概率越高，但会占用电子设备更长时间的资源，本申请可以合理设置测试次数。

步骤S14，响应于对待测交易项目的测试触发指令，利用测试数据、交易验证规则以及测试次数，运行测试交易脚本，得到针对待测交易项目的测试结果；

结合上述分析可知，测试交易脚本运行过程中按照票据交易链路对实现待测交易项目的多个交易流程各自的票据报文的处理顺序具有随机性，使得每次运行测试交易脚本时，在相应测试环境下自动执行该票据交易链路，模拟多个票据报文(即实现待测交易项目的一个票据报文组合)的处理顺序不同，验证这一个待测交易项目按照该处理顺序执行相应票据报文的处理逻辑，能否正确完成业务，即所得票据交易结果是否与交易验证规则指示的期望更新信息一致，从而得到多个(其数量可以与测试次数一致)测试结果。本申请对每次运行测试交易脚本，随机模拟不同票据报文的处理顺序，实现待测交易项目的一次测试的实现过程不做详述。

在一些实施例中，本申请可以循环运行该测试次数的测试交易脚本，每次运行该测试交易脚本，都会得到相应的测试结果，这样，在某测试结果表示待测交易项目的测试未通过，可以停止运行测试交易脚本，使得测试交易脚本实际运行次数小于预先配置的测试次数。在另一些实施例中，本申请也可以在确定测试交易脚本的重复运行次数达到测试次数时，再停止运行该测试交易脚本，之后，可以结合这多次测试得到的验证结果，得到待测交易项目的测试结果，或直接将这多次验证结果确定为待测交易项目的测试结果。

步骤S15，输出测试结果。

本申请中，测试结果能够指示待测交易项目的测试通过或未通过，如实现待测交易项目的各票据报文的处理逻辑正常，表示其测试通过；或至少一个票据报文的处理逻辑存在缺陷等异常情况，导致其测试未通过。因此，在一种可能的实现方式中，本申请可以将得到的待测交易项目的测试结果直接显示于电子设备的显示屏上，以供测试人员查看。

在另一种可能的实现方式中，也可以按照预设的测试报告模板，利用待测交易项目的标识(如名称等)以及得到的测试结果等信息，生成针对待测交易项目的测试报告后，再将测试报告显示于电子设备的显示屏，或者发送至打印设备进行打印输出等，本申请对步骤S15的实现方法不做限制，可视情况而定。

综上，在本申请实施例中，在需要对目标票据的任一票据业务的任一交易流程，测试其实现过程中传输的各票据报文的处理逻辑是否存在缺陷等异常情况，测试人员直接选择其为待测交易项目，获取其测试数据、测试交易脚本和测试次数后，就可以使用该测试数据自动运行测试交易脚本多次，重复对这一个待测交易项目进行测试，来随机模拟实现待测交易项目的多个票据报文的处理顺序，通过验证每次测试是否符合相应的交易验证规则，得到待测交易项目的多个测试结果，相对于人工只能对目标票据的待测交易项目执行一次测试，得到一个测试结果的测试方法，本申请有效提高了票据报文的处理逻辑存在偶发性缺陷的发现率，无需人工过多干预，省时省力，提高了测试效率以及所得测试结果的可靠性。

参照图2，为本申请提出的电子商业汇票业务测试方法的可选实施例二的流程示意图，本实施例可以是对上文提出的电子商业汇票业务测试方法的一可选细化实现方式进行描述，但并不局限于本实施例描述的细化实现方法。

如图2所示，本实施例提出的电子商业汇票业务测试方法可以包括：

步骤S21，输出针对目标票据的业务测试界面，在业务测试界面显示有目标票据的多个交易项目；

步骤S22，响应于对交易项目的测试选择指令，确定所选择的待测交易项目；

关于步骤S21和步骤S22的实现过程，可以参照上文实施例对应部分的描述，本实施例在此不做详述。应该理解的是，受票据业务依赖关系的约束，在对某一交易流程进行测试，需要执行其依赖实现的其他交易流程，如测试人员需要测试质押交易项目，那么在测试交易脚本中会自动选择运行出票、承兑、收票和质押交易，即在执行质押交易之前，需要先执行出票、承兑和收票业务，实现过程本申请不做详述。

步骤S23，确定已生成并存储针对目标票据的全量交易脚本，从该全量交易脚本中，确定出用于实现待测交易项目的测试交易脚本；

本申请实施例中，为了减少每个交易流程的测试时长，可以预先生成目标票据所涉及得到的需要测试的各交易流程的交易脚本，将该交易脚本称为目标票据的全量交易脚本，可以是包含实现目标票据的各票据业务的各交易流程的交易脚本构成的一个全量交易脚本，也可以将用于测试每个交易流程的交易脚本作为独立的可执行文件存储，此时可以得到多个交易脚本，本申请对全量交易脚本的内容及其存储实现方式不做限制。

可以理解的是，对于不同类型的票据，其包含的票据业务类型，以及实现每一票据业务的各交易流程可能不同，据此生成的实现各交易流程测试的交易脚本内容也会存在差异。所以，本申请可以在确定目标票据的所有票据业务，以及每一票据业务实现过程中所执行的各交易流程后，再有针对性地生成相应的交易脚本。关于交易脚本的生成过程可以参照上下文实施例对应部分的描述，本实施例不做详述。

在测试之前已经生成目标票据的全量交易脚本的情况下，不再需要在线花费一定时间来生成所需的测试交易脚本，可以直接从中读取待测交易项目对应的测试交易脚本即可，提高了测试交易脚本获取效率，以提高其测试效率。应该理解的是，对于如上文描述的不同内容的全量交易脚本，从中读取测试交易脚本的实现方式可以不同，如从一个全量交易脚本中，提取用于实现待测交易项目对应位置处的脚本内容，由该位置之前的脚本内容构成测试交易脚本；或者从多个交易流程各自对应的交易脚本中，查询待测交易项目对应的交易脚本为测试交易脚本等，本申请对步骤S23的实现方式不做限制。

需要说明，关于获取用于实现待测交易项目的测试交易脚本的实现方法，包括但并不局限于本实施例描述的这种实现方式。也可以在预先未生成针对目标票据的全量交易脚本，或针对待测交易项目的交易脚本的情况下，按照上下文描述的方法，在线生成所需的测试交易脚本，或者生成目标票据的全量交易脚本后，再按照上文描述的步骤内容确定测试交易脚本等，实现过程本实施例在此不做详述。

其中，对于上述交易脚本生成过程，可以由测试人员或开发人员使用电子设备按照上下文描述的方法实现，再将生成的全量交易脚本与目标票据的标识关联后存储，之后，任一测试人员对目标票据的任一待测交易项目进行测试，都可以直接使用该全量交易脚本，获取相应的测试交易脚本，减少在线生成测试交易脚本所花费的时长。

步骤S24，确定已存储有目标票据的全量初始化数据，从全量初始化数据中，读取用于实现待测交易项目的必要输入数据为测试数据；

本实施例中，与上文预先生成的全量交易脚本的思路类似，为了避免测试人员不确定待测交易项目进行测试所必需输入的测试数据包含哪些，本申请可以预先确定目标票据的各票据业务的交流流程执行所必须输入的数据，非执行过程中产生的中间数据，或能够依据业务逻辑关系分析得到的数据，由其作为该目标票据的全量初始化数据进行保存，即维护目标票据的全量初始化数据。本申请对全量初始化数据的内容及其存储方式不做限制。

可见，本申请确定的目标票据的全量初始化数据包括用于实现目标票据的不同票据业务的各票据流程的必要输入数据，如票据的出票人信息、收款人信息、承兑人信息以及交易金额等，该必要输入数据可以基于通过正则表达式从票据交易链路中提取出的票据报文传输接口参数确定，本申请对必要输入数据的确定方法及其内容不做限制。

在另一些实施例中，若预先未存储/维护目标票据的全量初始化数据，需要测试人员在线输入待测交易项目的测试数据，此时可以输出针对待测交易项目的测试配置界面，以便测试人员在该测试配置界面的测试数据输入窗口输入测试数据，可以通过触控或键盘或语音等任一输入方式实现，使得电子设备可以响应于对测试配置界面的测试数据输入操作，得到待测交易项目的测试数据。

可选的，为了保证输入的测试数据完整且不存在冗余数据，可以在测试配置界面的测试数据输入窗口显示相应的数据输入提示信息，使得测试人员可以基于显示的数据输入提示信息执行上述测试数据输入操作。可见，该数据输入提示信息可以用于引导输入实现待测交易项目的必要输入数据，如上述分析，该必要输入数据可以基于通过正则表达式从票据交易链路中提取出的票据报文传输接口参数确定，对于不同的必要输入数据，可以生成对应的数据输入提示信息，以显示于对应测试数据输入窗口，保证输入的测试数据正确且完整。但并不局限于本实施例描述的实现方式，如在经验丰富的测试人员，可以不用提示也能够正确输入测试数据，此时不用显示数据输入提示信息。

步骤S25，响应于对待测交易项目的测试次数配置操作，确定待测交易项目的测试次数；

测试次数可以由测试人员依据实际情况输入，也可以是票据业务测试场景下默认配置的数值，本申请对其获取方式不做限制，本实施例仅以测试人员对待测交易项目有针对性地配置测试次数的实现方式为例进行说明，在该实现方式中，对于不同的待测交易项目，可以配置相同或不同的测试次数，以提高测试灵活性。

步骤S26，响应于对待测交易项目的测试触发指令，利用测试数据运行测试交易脚本，以按照票据交易链路响应相应交易流程的票据报文，确定待测交易项目执行后的票据交易结果；

步骤S27，检测票据交易结果是否符合交易验证规则，得到本次针对待测交易项目的测试结果；

步骤S28，确定测试交易脚本的重复运行次数达到上述测试次数，输出得到的测试结果。

结合上文实施例步骤S14相应部分的描述，在每一次触发运行测试交易脚本，都可以使用初始化获取的测试数据，实现待测交易项目的交易测试，确定所得到的测票据交易结果是否符合交易验证规则，如在按照票据交易链路执行待测交易项目后，验证目标票据的票据状态、流程标志、本手持票人以及下手持票人等变更操作后是否为对应的预期更新信息。

示例性的，以目标票据的背书业务为例进行说明，背书申请这一待测交易项目执行后，校验票据状态是否为已收票，流通标志是否由可流通更新为已锁定，本手持票人是否为背书申请人，下手持票人是否更新为被背书人；背书回复这一待测交易项目执行后的票据状态是否为已收票，流通标志是否由已锁定更新为可流通，本手持票人是否更新为被背书人，下手持票人是否不变，即下手持票人为被背书人等。对于其他内容的交易验证规则的验证过程类似，本申请不做一一举例详述。

应该理解的是，在对待测交易项目的每一次测试后，即每次运行测试交易脚本后，所得到的票据交易结果中的各待验证项信息(如所得票据状态信息、流程标志信息以及下手持票人信息等)都与交易验证规则所指示的预期更新信息匹配(即信息一致)，所得到的测试结果为测试通过；反之，若至少一个待验证项信息与交易验证规则所指示的预期更新信息不匹配，所得到的测试结果为测试未通过。

综上，本申请实施例中，在测试之前，可以先获取目标票据的全量交易脚本以及全量初始化数据，实现了测试数据与交易脚本的分离，这样，测试人员从业务测试界面显示的目标票据的多个交易项目中，选择出本次的待测交易项目后，就可以直接从全量交易脚本中，快速确定用于实现待测交易项目的测试交易脚本，并从全量初始化数据中确定出待测交易项目的测试数据，还可以配置对待测交易项目的测试次数，之后，就可以利用该测试数据，多次运行测试交易脚本，随机模拟实现待测交易项目的多个票据报文的不同处理顺序，来实现对同一待测交易项目的多次测试，有效提高对票据报文的偶发性缺陷的发现概率，提高票据业务测试可靠性。

参照图3，为本申请提出的电子商业汇票业务测试方法的可选实施例三的流程示意图，本实施例可以对上文描述的电子商业汇票业务测试方法中，目标票据的全量交易脚本的一可选生成方法进行描述，关于该电子商业汇票业务测试方法的其他执行步骤，可以参照上文实施例对应部分的描述，本实施例不做详述。基于此，如3所示，上述生成并存储针对目标票据的全量交易脚本的实现过程可以包括：

步骤S31，响应于针对目标票据的交易流程信息获取指令，依据用于实现目标票据的不同票据业务的各交易流程，获取相应交易流程的接口传输信息；

在实际应用中，对于目标票据的任一交易流程，可以通过接收或发送票据报文的方式与其他交易流程通信，以完成相应的票据业务，对于传输票据报文的流程接口可以称为票据报文传输接口，可以调用信息抓取工具，来获取每一交易流程的票据报文传输接口的接口传输信息，如该票据报文传输接口接收和发送的票据报文，以及该票据报文来自其他哪个票据报文传输接口，或发送至其他哪个票据报文传输接口等，本申请对接口传输信息的内容及其获取方法不做限制，可视情况而定。

步骤S32，基于接口传输信息，确定不同交易流程的票据报文之间的流转关系；

继上文对接口传输信息的相关描述，通过对目标票据的所有票据业务的各交易流程之间具有一定的依赖关系，可以通过不同交易流程对应的票据报文传输接口的输入参数和输出参数(其可以是输入/输出的票据报文，可以由一个接口传输或多个接口分别传输，可以依据该接口所支持的通信协议确定，本申请对此不做限制)进行分析确定，因此，本实施例可以对包含这两类参数的接口传输信息进行分析，来确定接口间的业务逻辑关系，如某个交易流程输出的票据报文发送至哪个交易流程等，这样，就可以按照该业务逻辑关系，将实现目标票据的各票据业务的各交易流程所使用到的票据报文传输接口之间的串联起来，形成如树型结构的票据报文流转关系。

示例性的，参数图4所示的票据业务场景下的票据报文流转关系示意图，假设其包含交易流程A、交易流程B和交易流程C，每一交易流程对应有票据报文传输接口，依次记为接口A、接口B和接口C，如图4所示，在该票据业务场景下，接口A的返回值O1.1和O1.2依次作为接口B的输入值I2.1、I2.2，使得接口B得到返回值O2.1，该接口B的返回值O2.1和接口A的返回值O1.3分别作为接口C的输入值I3.1和I3.2，使得接口C得到返回值O3.1。基于此，接口A、接口B和接口C顺次串联，且接口A与接口C连接，可以依据该连接关系确定接口A、接口B和接口C之间的票据报文流转关系。

因此，在一些实施例中，上述步骤S32的实现过程可以包括但并不局限于：基于接口传输信息，确定目标票据的不同票据业务包含的各交易流程之间的业务逻辑关系，从而基于该业务逻辑关系，确定不同交易流程的票据报文传输接口之间的连接关系，利用该连接关系，得到不同交易流程的票据报文之间的流转关系。

在确定上述流转关系后，可以由此得知实现该票据业务场景的必要输入数据，如图4所示的接口A的返回值O1.1、O1.2和O1.3，对于其他接口的输入和返回值，可以结合上述确定的流转关系自动生成，无需测试人员手动输入，减少了测试人员的工作量，且避免了因人工错误输入操作造成所得测试数据不正确，进而降低测试结果可靠性。

在一些实施例中，本申请可以通过正则表达式实现接口间参数化，即通过正则表达式方式，从表示上述流转关系的票据交易链路中，提取出票据报文接口参数，进而据此确定实现目标票据的票据业务的相应票据流程的必要输入数据，即实现相应票据业务场景的必要输入数据，如图4所示票据业务场景下交易流程A的接口A的返回值O1.1、O1.2和O1.3，通常可以是目标票据的出票人信息、收款人信息、承兑人信息、交易金额等，本申请对该必要输入数据的内容不做限制，对于不同票据业务场景的必要输入数据可以不同，也可以将各票据业务场景的必要输入数据作为全量初始化数据维护起来，以供后续测试人员对某票据业务场景进行测试时直接调用/读取。当然，也可以通过由此生成的数据输入提示信息，引导测试人员正确且快速输入待测交易项目的测试数据，实现过程可以参照上文实施例对应部分的描述，本实施例不做详述。

步骤S33，获取不同票据业务的各交易流程的交易验证规则；

步骤S34，响应于针对目标票据的脚本生成触发指令，调用脚本生成工具，利用该流转关系和交易验证规则，生成针对目标票据的全量交易脚本；

步骤S35，将该全量交易脚本与目标票据关联后存储。

关于不同票据业务场景的交易验证规则的获取方法，可以参照上文实施例对应部分的描述，这样，可以触发独立的脚本生成工具，或接口测试工具中的脚本生成功能启动，利用上述获取的交易验证规则以及票据报文流转关系，自动生成针对目标票据的全量交易报文，后续可以从中确定出用于实现目标票据的任一票据业务场景的交易脚本，无需测试人员一一手动编写，降低了对测试人员的技术要求，也避免了人工编写错误导致测试失败或测试结果不可靠的问题发生，关于全量交易脚本的生成过程本申请不做详述。

参照图5，为本申请提出的电子商业汇票业务测试装置的可选实施例一的结构示意图，如图5所示，该电子商业汇票业务测试装置可以包括：

业务测试界面输出模块51，用于输出针对目标票据的业务测试界面，在所述业务测试界面显示有所述目标票据的多个交易项目；所述交易项目是指实现所述目标票据的任一票据业务的任一交易流程；

待测交易项目确定模块52，用于响应于对所述交易项目的测试选择指令，确定所选择的待测交易项目；

获取模块53，用于获取所述待测交易项目的测试数据、测试交易脚本以及测试次数；所述测试交易脚本能够表示实现所述待测交易项目的票据交易链路以及交易验证规则；

测试模块54，用于响应于对所述待测交易项目的测试触发指令，利用所述测试数据、所述交易验证规则以及所述测试次数，运行所述测试交易脚本，得到针对所述待测交易项目的测试结果；所述测试交易脚本运行过程中按照所述票据交易链路对实现所述待测交易项目的多个所述交易流程各自的票据报文的处理顺序具有随机性；

测试结果输出模块55，用于输出所述测试结果。

在一些实施例中，如图6所示，上述获取模块53可以包括：

全量交易脚本确定单元531，用于确定已生成并存储针对所述目标票据的全量交易脚本；

测试交易脚本确定单元532，用于从所述全量交易脚本中，确定出用于实现所述待测交易项目的测试交易脚本；

其中，所述全量交易脚本包括用于实现所述目标票据的不同票据业务的各交易流程的交易脚本。

在一种可能的实现方式中，如图6所示，用于生成并存储针对所述目标票据的全量交易脚本的全量交易脚本生成模块56，可以包括：

接口传输信息获取单元561，用于响应于针对所述目标票据的交易流程信息获取指令，依据用于实现所述目标票据的不同票据业务的各交易流程，获取相应所述交易流程的接口传输信息；

流转关系确定单元562，用于基于所述接口传输信息，确定不同所述交易流程的票据报文之间的流转关系；

交易验证规则获取单元563，用于获取不同所述票据业务的各所述交易流程的交易验证规则；

生成单元564，用于响应于针对所述目标票据的脚本生成触发指令，调用脚本生成工具，利用所述流转关系和所述交易验证规则，生成针对所述目标票据的全量交易脚本；

存储单元565，用于将所述全量交易脚本与所述目标票据关联后存储。

可选的，上述流转关系确定单元562可以包括：

业务逻辑关系确定子单元，用于基于所述接口传输信息，确定所述目标票据的不同所述票据业务包含的各交易流程之间的业务逻辑关系；

连接关系确定子单元，用于基于所述业务逻辑关系，确定不同所述交易流程的票据报文传输接口之间的连接关系；

流转关系确定子单元，用于利用所述连接关系，得到不同所述交易流程的票据报文之间的流转关系。

在一些实施例中，上述全量交易脚本生成模块56可以部署在服务器(或其他设备)中，电子设备可以从服务器(或其他设备)中的全量交易脚本中读取待测交易项目的测试交易脚本。

综合上文各实施例描述的电子商业汇票业务测试装置，其中的获取模块53还可以包括：

全量初始化数据确定单元，用于确定已存储有所述目标票据的全量初始化数据；所述全量初始化数据包括用于实现所述目标票据的不同票据业务的各票据流程的必要输入数据，所述必要输入数据基于通过正则表达式从所述票据交易链路中提取出的票据报文传输接口参数确定；

测试数据读取单元，用于从所述全量初始化数据中，读取用于实现所述待测交易项目的必要输入数据为测试数据。

在另一些实施例中，上述获取模块53也可以包括：

测试配置界面输出单元，用于输出针对所述待测交易项目的测试配置界面；

测试数据得到单元，用于响应于对所述测试配置界面的测试数据输入操作，得到所述待测交易项目的测试数据；

其中，所述测试数据输入操作是基于所述测试配置界面中显示的数据输入提示信息执行，所述数据输入提示信息用于引导输入实现所述待测交易项目的必要输入数据，所述必要输入数据基于通过正则表达式从所述票据交易链路中提取出的票据报文传输接口参数确定。

综合上文各实施例描述的电子商业汇票业务测试装置，其中的测试模块54可以包括：

票据交易结果确定单元，用于利用所述测试数据，运行所述测试交易脚本，以按照所述票据交易链路，响应相应所述交易流程的票据报文，确定所述待测交易项目执行后的票据交易结果；

测试结果得到单元，用于检测所述票据交易结果是否符合所述交易验证规则，得到本次针对所述待测交易项目的测试结果。

可选的，上述交易验证规则可以用于在按照所述票据交易链路执行所述待测交易项目后，验证所述目标票据的票据状态、流程标志、本手持票人以及下手持票人是否为对应的预期更新信息，本申请对其内容和获取方法不做限制，可视情况而定。

需要说明的是，关于上述各装置实施例中的各种模块、单元等，均可以作为程序模块存储在存储器中，由处理器执行存储在存储器中的上述程序模块，以实现相应的功能，关于各程序模块及其组合所实现的功能，以及达到的技术效果，可以参照上述方法实施例相应部分的描述，本实施例不再赘述。

本申请还提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述电子商业汇票业务测试方法的各步骤，具体实现过程可以参照上述方法实施例相应部分的描述。

本申请还提出了一种计算机程序，该计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机程序在电子设备上运行时，用于执行如上任意一个实施例中的电子商业汇票业务测试方法。

参照图7，为适用于本申请提出的电子商业汇票业务测试方法的电子设备的一可选实施例的硬件结构示意图，该电子设备可以包括：显示器7和处理器72，其中：

显示器71可以用于输出针对目标票据的业务测试界面，在业务测试界面显示有目标票据的多个交易项目，还可以用于输出测试结果等，可以依据电子商业汇票业务测试过程中得显示需求确定，本实施例在此不做详述。其中，交易项目是指实现目标票据的任一票据业务的任一交易流程。

本申请实施例中，显示器71可以是触控显示器或非触控显示器，对于不同类型的显示器，可以采用相匹配的数据输入方式，实现对其输出内容的交互操作，需要时可以使用电子设备具有的如鼠标、键盘或拾音器等输入组件实现，本申请在此不做详述。

处理器72可以用于响应于对交易项目的测试选择指令，确定所选择的待测交易项目，获取待测交易项目的测试数据、测试交易脚本以及测试次数，响应于对待测交易项目的测试触发指令，利用测试数据、交易验证规则以及测试次数，运行测试交易脚本，得到针对待测交易项目相应数量的测试结果，通过显示器输出该测试结果。

结合上文方法实施例的相关描述，上述测试交易脚本能够表示实现待测交易项目的票据交易链路以及交易验证规则，测试交易脚本运行过程中按照票据交易链路对实现待测交易项目的多个交易流程各自的票据报文的处理顺序具有随机性，以在多次运行测试交易脚本过程中，可以随机模拟实现待测交易项目的多个票据报文的处理顺序，提高票据报文的处理逻辑存在缺陷的发现概率，进而提高测试可靠性。

在实际应用中，处理器72可以包括中央处理器(Central Processing Unit，CPU)、特定应用集成电路(application-specific integrated circuit，ASIC)、数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件等之中的至少一个。在一些实施例中，处理器72也可以集成存储器，如高速随机存取存储器、非易失性存储器或其他易失性固态存储器件等，处理器72可以加载执行存储器所存储的多个计算机指令，实现本申请提出的电子商业汇票业务测试方法。

另外，电子设备中通常还包括通信元件，用以实现电子设备与其他设备，电子设备内部各组成部分之间的数据传输。因此，通信元件可以包括支持如wifi、蓝牙、5G/6G(第五代/六代移动通信技术)和/或其他无线通信方式的无线通信元件，以使得电子设备通过相应的通信元件，实现与其他设备(如服务器或其他业务终端等)之间的数据交互，如传输来自服务器的全量交易脚本、全量初始化数据等，可以依据实际测试需求确定。

通信元件也可以包括一个或多个支持有线通信方式的接口，如通用输入输出(general-purpose input/output，GPIO)接口、USB接口、通用异步收发传输器(universalasynchronous receiver/transmitter，UART)接口等，以实现电子设备内部各组成部分之间的数据传输，可以通过但并不局限于连接通信总线(如数据总线、指令总线等)实现不同组成部分之间的通信。本申请对电子设备中通信元件的数量及其类型不做限制，可视情况而定。

应该理解的是，图7所示的电子设备的结构并不构成对本申请实施例中电子设备的限定，在实际应用中，电子设备可以包括比图7所示的更多的部件，或者组合某些部件，如键盘、鼠标、摄像头、拾音器等至少一个输入组件；如扬声器、振动机构、灯等至少一个输出组件；天线；传感器模组；电源模组等，可以依据电子设备产品类型及其功能需求确定硬件结构，本申请在此不做一一列举。

最后，需要说明，关于上述各实施例中，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。一般说来，术语“包括”与“包含”仅提示包括已明确标识的步骤和元素，而这些步骤和元素不构成一个排它性的罗列，方法或者设备也可能包含其它的步骤或元素。由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。

本申请涉及到的术语诸如“第一”、“第二”等仅用于描述目的，用来将一个操作、单元或模块与另一个操作、单元或模块区分开来，而不一定要求或者暗示这些单元、操作或模块之间存在任何这种实际的关系或者顺序。且不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量，由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。

另外，本说明书中各个实施例采用递进或并列的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置、电子设备而言，由于其与实施例公开的方法对应，所以描述的比较简单，相关之处参见方法部分说明即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种电子商业汇票业务测试方法，其特征在于，所述方法包括：

输出针对目标票据的业务测试界面，在所述业务测试界面显示有所述目标票据的多个交易项目；所述交易项目是指实现所述目标票据的任一票据业务的任一交易流程；

响应于对所述交易项目的测试选择指令，确定所选择的待测交易项目；

获取所述待测交易项目的测试数据、测试交易脚本以及测试次数；所述测试交易脚本能够表示实现所述待测交易项目的票据交易链路以及交易验证规则；

响应于对所述待测交易项目的测试触发指令，利用所述测试数据、所述交易验证规则以及所述测试次数，运行所述测试交易脚本，得到针对所述待测交易项目的测试结果；所述测试交易脚本运行过程中按照所述票据交易链路对实现所述待测交易项目的多个所述交易流程各自的票据报文的处理顺序具有随机性；

输出所述测试结果。

2.根据权利要求1所述的方法，其特征在于，所述获取所述待测交易项目的测试交易脚本，包括：

确定已生成并存储针对所述目标票据的全量交易脚本；

从所述全量交易脚本中，确定出用于实现所述待测交易项目的测试交易脚本；

其中，所述全量交易脚本包括用于实现所述目标票据的不同票据业务的各交易流程的交易脚本。

3.根据权利要求2所述的方法，其特征在于，所述生成并存储针对所述目标票据的全量交易脚本，包括：

响应于针对所述目标票据的交易流程信息获取指令，依据用于实现所述目标票据的不同票据业务的各交易流程，获取相应所述交易流程的接口传输信息；

基于所述接口传输信息，确定不同所述交易流程的票据报文之间的流转关系；

获取不同所述票据业务的各所述交易流程的交易验证规则；

响应于针对所述目标票据的脚本生成触发指令，调用脚本生成工具，利用所述流转关系和所述交易验证规则，生成针对所述目标票据的全量交易脚本；

将所述全量交易脚本与所述目标票据关联后存储。

4.根据权利要求3所述的方法，其特征在于，所述基于所述接口传输信息，确定不同所述交易流程的票据报文之间的流转关系，包括：

基于所述接口传输信息，确定所述目标票据的不同所述票据业务包含的各交易流程之间的业务逻辑关系；

基于所述业务逻辑关系，确定不同所述交易流程的票据报文传输接口之间的连接关系；

利用所述连接关系，得到不同所述交易流程的票据报文之间的流转关系。

5.根据权利要求1-4任一项所述的方法，其特征在于，所述获取所述待测交易项目的测试数据，包括：

确定已存储有所述目标票据的全量初始化数据；所述全量初始化数据包括用于实现所述目标票据的不同票据业务的各票据流程的必要输入数据，所述必要输入数据基于通过正则表达式从所述票据交易链路中提取出的票据报文传输接口参数确定；

从所述全量初始化数据中，读取用于实现所述待测交易项目的必要输入数据为测试数据。

6.根据权利要求1-4任一项所述的方法，其特征在于，所述获取所述待测交易项目的测试数据，包括：

输出针对所述待测交易项目的测试配置界面；

响应于对所述测试配置界面的测试数据输入操作，得到所述待测交易项目的测试数据；

其中，所述测试数据输入操作是基于所述测试配置界面中显示的数据输入提示信息执行，所述数据输入提示信息用于引导输入实现所述待测交易项目的必要输入数据，所述必要输入数据基于通过正则表达式从所述票据交易链路中提取出的票据报文传输接口参数确定。

7.根据权利要求1-4任一项所述的方法，其特征在于，所述利用所述测试数据、所述交易验证规则以及所述测试次数，运行所述测试交易脚本，得到针对所述待测交易项目的测试结果，包括：

利用所述测试数据，运行所述测试交易脚本，以按照所述票据交易链路，响应相应所述交易流程的票据报文，确定所述待测交易项目执行后的票据交易结果；

检测所述票据交易结果是否符合所述交易验证规则，得到本次针对所述待测交易项目的测试结果。

8.根据权利要求1-4任一项所述的方法，其特征在于，所述交易验证规则用于在按照所述票据交易链路执行所述待测交易项目后，验证所述目标票据的票据状态、流程标志、本手持票人以及下手持票人是否为对应的预期更新信息。

9.一种电子商业汇票业务测试装置，其特征在于，所述装置包括：

业务测试界面输出模块，用于输出针对目标票据的业务测试界面，在所述业务测试界面显示有所述目标票据的多个交易项目；所述交易项目是指实现所述目标票据的任一票据业务的任一交易流程；

待测交易项目确定模块，用于响应于对所述交易项目的测试选择指令，确定所选择的待测交易项目；

获取模块，用于获取所述待测交易项目的测试数据、测试交易脚本以及测试次数；所述测试交易脚本能够表示实现所述待测交易项目的票据交易链路以及交易验证规则；

测试模块，用于响应于对所述待测交易项目的测试触发指令，利用所述测试数据、所述交易验证规则以及所述测试次数，运行所述测试交易脚本，得到针对所述待测交易项目的测试结果；所述测试交易脚本运行过程中按照所述票据交易链路对实现所述待测交易项目的多个所述交易流程各自的票据报文的处理顺序具有随机性；

测试结果输出模块，用于输出所述测试结果。

10.一种电子设备，其特征在于，所述电子设备包括：显示器和处理器，其中：

所述显示器，用于输出针对目标票据的业务测试界面，在所述业务测试界面显示有所述目标票据的多个交易项目；所述交易项目是指实现所述目标票据的任一票据业务的任一交易流程；

所述处理器，用于响应于对所述交易项目的测试选择指令，确定所选择的待测交易项目，获取所述待测交易项目的测试数据、测试交易脚本以及测试次数，响应于对所述待测交易项目的测试触发指令，利用所述测试数据、交易验证规则以及所述测试次数，运行所述测试交易脚本，得到针对所述待测交易项目的测试结果；其中，所述测试交易脚本能够表示实现所述待测交易项目的票据交易链路以及所述交易验证规则，所述测试交易脚本运行过程中按照所述票据交易链路对实现所述待测交易项目的多个所述交易流程各自的票据报文的处理顺序具有随机性；

所述显示器还用于输出所述测试结果。