一种系统功能的测试方法、装置、设备及存储介质与流程

1.本技术涉及大数据领域，尤其涉及一种系统功能的测试方法、装置、设备及存储介质。


背景技术：

2.由于金融业务的特殊性，银行的联机交易系统一般是多设备集群的构成方式，以保证金融交易的安全性和高并发性。因此，联机交易系统在进行应用部署或者应用版本更新时，通常要涉及几十台甚至上百台设备。这种大规模部署的方式，需要保证各个设备均可以正常工作。
3.联机交易系统在进行应用部署或者应用版本更新后，为了保证新功能的正常工作，避免版本更新对原有业务功能的影响，需要对更新后的联机交易系统进行测试。现有方法是靠人工抽检的方法做应用上的功能测试，这种测试方法不全面，且无法模拟真实的运行环境，难以排查所有的问题，进而导致测试的结果不可靠。在这种情况下，如果将更新后的联机交易系统投产，则容易在投产后暴露问题，对银行造成巨大损失。


技术实现要素：

4.本技术提供一种系统功能的测试方法、装置、设备及存储介质，能够在联机交易系统更新后对系统的功能进行全面的测试，提高了测试结果的可靠性，保证了联机交易系统在投产后的正常运行。
5.第一方面，本技术提供一种系统功能的测试方法，应用于对包括多个子系统的联系交易系统进行系统功能测试的过程中，该方法包括：获取多个目标交易报文，目标交易报文包括以下交易参数：交易账号，交易金额和交易时间，多个目标交易报文中不同目标交易报文至少存在一个交易参数不同：向联机交易系统发送多个目标交易报文，以使得联机交易系统执行多个目标交易报文中每个目标交易报文对应的交易；接收来自联机交易系统返回的与多个目标交易报文一一对应的交易结果，交易结果用于指示对应目标交易报文的交易是否成功；在存在交易结果用于指示对应目标交易报文的交易失败的情况下，获取执行第一交易报文时联机交易系统产生的第一交易日志，以及执行第二交易报文时联机交易系统产生的第二交易日志；其中，第一交易报文为多个目标交易报文中交易失败的报文，第二交易报文为多个目标交易报文中交易成功的报文；根据第一交易日志和第二交易日志，输出测试结果，测试结果用于指示多个子系统中出现故障的子系统。
6.一种可能的实现方式中，多个目标交易报文中不同目标交易报文至少存在一个交易参数不同，包括：多个目标交易报文中，不同交易报文的交易账号和交易金额相同，交易时间不同。
7.另一种可能的实现方式中，第一交易日志包括联机交易系统中参与第一交易报文执行的子系统的日志；第二交易日志包括联机交易系统中参与第二交易报文执行的子系统的日志。
8.又一种可能的实现方式中，获取多个目标交易报文，包括：获取测试交易报文，测试交易报文包括以下交易参数：交易账号，交易金额和交易时间，测试交易报文用于测试一个交易功能；对测试交易报文中的至少一个交易参数进行多次修改，以获得多个目标交易报文。
9.又一种可能的实现方式中，获取测试交易报文，包括：从测试报文库中获取测试交易报文，测试报文库中包括多个测试交易报文，不同测试交易报文用于测试不同交易功能。
10.本技术提供的系统功能的测试方法，通过获取多个目标交易报文，并向联机交易系统发送多个目标交易报文以进行功能测试。并且，还可以获取到联机交易系统执行目标交易报文时产生的交易日志，根据交易日志，输出用于指示产生故障的子系统的交易结果。该系统功能的测试方法，可以自动地对联机交易系统进行测试，且在测试过程使用的大量报文，可以模拟真实交易过程中的交易高峰，防止由于交易量暴涨时联机交易系统可能出现的问题。相比于传统的人工抽检方法，该系统功能的测试方法效率更高，测试的范围更为全面，测试的结果更为可靠。保证了更新后的联机交易系统在投产后正常工作的稳定，避免系统故障对银行造成损失。
11.进一步的，本方案借助灰度测试的思想，通过使用少部分测试人员的真实信息来生成测试交易报文以进行测试，避免使用包含有客户信息的交易报文造成客户的隐私泄漏的情况。还借助了a/b测试的思想，在获取交易成功的报文对应的交易日志和交易失败的报文对应的交易日志后，比对相同功能的交易日志的异常点，可以快速定位故障的产生范围，有利于在开门营业前尽快发现故障并及时修复。另外，本方案节约了人力资源，方案中使用自动化测试的方案，可以应用于各种自动化部署的产品中，大幅度提高测试的效率和准确性。
12.第二方面，本技术提供一种测试装置，该装置包括：获取模块、发送模块、接收模块和输出模块；获取模块，用于获取多个目标交易报文，目标交易报文包括以下交易参数：交易账号，交易金额和交易时间，多个目标交易报文中不同目标交易报文至少存在一个交易参数不同：发送模块，用于向联机交易系统发送多个目标交易报文，以使得联机交易系统执行多个目标交易报文中每个目标交易报文对应的交易；接收模块，用于接收来自联机交易系统返回的与多个目标交易报文一一对应的交易结果，交易结果用于指示对应目标交易报文的交易是否成功；获取模块，还用于在存在交易结果用于指示对应目标交易报文的交易失败的情况下，获取执行第一交易报文时联机交易系统产生的第一交易日志，以及执行第二交易报文时联机交易系统产生的第二交易日志；其中，第一交易报文为多个目标交易报文中交易失败的报文，第二交易报文为多个目标交易报文中交易成功的报文；输出模块，用于根据第一交易日志和第二交易日志，输出测试结果，测试结果用于指示多个子系统中出现故障的子系统。
13.一种可能的实现方式中，多个目标交易报文中不同目标交易报文至少存在一个交易参数不同，包括：多个目标交易报文中，不同交易报文的交易账号和交易金额相同，交易时间不同。
14.另一种可能的实现方式中，第一交易日志包括联机交易系统中参与第一交易报文执行的子系统的日志；第二交易日志包括联机交易系统中参与第二交易报文执行的子系统的日志。
15.又一种可能的实现方式中，获取模块，具体用于获取测试交易报文，测试交易报文包括以下交易参数：交易账号，交易金额和交易时间，测试交易报文用于测试一个交易功能；对测试交易报文中的至少一个交易参数进行多次修改，以获得多个目标交易报文。
16.又一种可能的实现方式中，获取模块，具体用于从测试报文库中获取测试交易报文，测试报文库中包括多个测试交易报文，不同测试交易报文用于测试不同交易功能。
17.第三方面，本技术提供一种电子设备，该电子设备包括：处理器和存储器；存储器存储有处理器可执行的指令；处理器被配置为执行指令时，使得电子设备实现上述第一方面的方法。
18.第四方面，本技术提供一种计算机可读存储介质，该计算机可读存储介质包括：计算机软件指令；当计算机软件指令在电子设备中运行时，使得电子设备实现上述第一方面的方法。
19.第五方面，本技术提供一种计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述第一方面描述的相关方法的步骤，以实现上述第一方面的方法。
20.上述第二方面至第五方面的有益效果可以参考第一方面的对应描述，不再赘述。
附图说明
21.图1为本技术提供的一种系统功能的测试方法的应用环境示意图；
22.图2为本技术提供的一种系统功能的测试方法流程示意图；
23.图3为本技术提供的另一种系统功能的测试方法流程示意图；
24.图4为本技术提供的一种输出结果显示示意图；
25.图5为本技术提供的一种测试流程示意图；
26.图6为本技术提供的另一种测试流程示意图；
27.图7为本技术提供的一种测试装置的组成示意图；
28.图8为本技术提供的一种电子设备的组成示意图。
具体实施方式
29.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
30.需要说明的是，本技术实施例中，“示例性地”或者“例如”等词用于表示作例子、例证或说明。本技术实施例中被描述为“示例性地”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性地”或者“例如”等词旨在以具体方式呈现相关概念。
31.为了便于清楚描述本技术实施例的技术方案，在本技术的实施例中，采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分，本领域技术人员可以理解“第一”、“第二”等字样并不是在对数量和执行次序进行限定。
32.在金融行业，银行提供的在线应用服务，后台系统(或者称之为联机交易系统)往往需要满足安全性的要求以及高并发性的要求，与之匹配的是大规模集群部署的方式。现
如今，采用分布式微服务方法设计银行的联机交易系统，已经成为比较常见的架构设计方案。分布式即功能分散部署在不同的设备上，微服务指的是应用的某些功能使用的人数较大，会被频繁访问，或者某些功能的计算量很大，因此将应用拆解为多个子系统，各子系统各自负责各自的功能。
33.这种分布式微服务的架构设计方式可以很好地满足银行的金融业务的安全性和高并发性的要求。但是，由于这种大规模部署的方式往往需要上百台甚至更多的设备，随着带来两个问题：一是怎样部署应用，二是怎样验证应用。
34.以前的后台系统涉及的设备数量比较少，可以手工逐一安装部署，不存在效率高低的问题。现如今部署上百台甚至更多的设备，只有具备自动化部署的能力，才可以提高部署的效率。另一方面，对于自动化部署的系统，没有可靠的测试方式，在正式投产后的风险较大。现有方法是运维人员手动自己编写测试脚本，人工进行某些功能的测试，这种人工抽检的方法效率较低且测试的覆盖面不够全面。并且该方法难以模拟交易高峰中出现的问题，使得银行在开门营业的高峰期，联机交易系统容易出现故障，影响用户的使用体验，造成用户投诉影响银行的声誉。
35.在此背景技术下，本技术实施例提供一种系统功能的测试方法，利用该方法可以在联机交易系统部署应用或更新后对系统的功能进行全面的测试，并且能够确保测试结果的可靠性，保证联机交易系统在投产后的正常运行，给用户带来较好的使用体验。
36.本技术提供的系统功能的测试方法，可以应用于如图1所示的应用环境中。如图1所示，该应用环境可以包括：测试装置101和联机交易系统102。测试装置101和联机交易系统102之间互相连接。
37.其中，测试装置101可以是多个服务器组成的服务器集群、或者单个服务器、又或者计算机、又或者服务器或计算机中的处理器或处理芯片等。本技术实施例对测试装置101的具体设备形态不作限制。图1中以测试装置101为单个服务器为例示出。
38.上述联机交易系统102可以是多个子系统组成的集群。其中，每个子系统可以是多个服务器组成的服务器集群、或者单个服务器、又或者计算机、又或者服务器或计算机中的处理器或处理芯片等。本技术实施例对联机交易系统102的具体形态不作限制。图1中以联机交易系统102为多个服务器(其中多个服务器中的每个服务器可以对应一个子系统)组成的集群为例示出。
39.在一些实施例中，测试装置101可以获取到多个测试交易报文，每个测试交易报文可以用于测试不同的功能。在对某一种功能进行测试时，测试装置可以获取到该功能对应的测试交易报文，对测试交易报文的交易参数进行多次修改，以获取多个目标交易报文。测试装置101可以将这多个目标交易报文发送给联机交易系统102以执行交易过程，并且测试装置101可以获取联机交易系统102执行交易过程时产生的交易日志，根据交易日志可以确定联机交易系统102中可能存在故障的子系统，以便工作人员可及时对出现故障的子系统进行处理，避免影响联机交易系统102在银行开门营业时的正常工作。
40.图2为本技术实施例提供的一种系统功能的测试方法的流程示意图。如图2所示，本技术提供的系统功能的测试方法，可以通过上述测试装置实现，具体可以包括以下步骤：
41.s201、获取多个目标交易报文。
42.其中，目标交易报文包括以下交易参数：交易账号，交易金额和交易时间。多个目
标交易报文中不同目标交易报文至少存在一个交易参数不同。
43.对于银行的联机交易系统来说，用户发起的一次业务操作，实质是产生了一个交易报文以触发联机交易系统执行对应的交易。因此，对于部署应用或版本更新后的联机交易系统，使用交易报文对其功能进行测试，可以更好地模拟真实的交易过程。其中交易报文是符合国际协议的金融交易报文，包括交易账号，交易金额和交易时间等交易参数。目标交易报文可以理解为对某一功能进行测试的交易报文。
44.在需要对联机交易系统的系统功能进行测试时，测试装置可以获取包括交易账号，交易金额和交易时间的多个目标交易报文，以对联机交易系统的某一个功能进行测试。
45.s202、向联机交易系统发送多个目标交易报文，以使得联机交易系统执行多个目标交易报文中每个目标交易报文对应的交易。
46.在获取到多个目标交易报文后，测试装置可以向联机交易系统发送获得的多个目标交易报文，以使得联机交易系统执行多个目标交易报文中每个目标交易报文对应的交易，以对该交易对应联机交易系统中的功能进行测试。
47.s203、接收来自联机交易系统返回的与多个目标交易报文一一对应的交易结果。
48.其中，交易结果用于指示对应目标交易报文的交易是否成功。
49.联机交易系统在接收到多个目标交易报文后，可以执行多次交易，并向测试装置返回用于指示对应目标交易报文的交易是否成功的交易结果。测试装置可以接收来自联机交易系统返回的与多个目标交易报文一一对应的交易结果。
50.s204、在存在交易结果用于指示对应目标交易报文的交易失败的情况下，获取执行第一交易报文时所述联机交易系统产生的第一交易日志，以及执行第二交易报文时所述联机交易系统产生的第二交易日志。
51.其中，第一交易报文为多个目标交易报文中交易失败的报文，第二交易报文为多个目标交易报文中交易成功的报文。
52.若测试装置接收到的褒义结果中不存在用于指示对应目标交易报文的交易失败的交易结果，则说明联机交易系统中不存在故障。若存在交易结果用于指示对应目标交易报文的交易失败，则测试装置可以获取联机交易系统执行交易失败的报文时产生的第一交易日志，还可以获取联机交易系统执行交易成功的报文时系统产生第二交易日志。
53.s205、根据第一交易日志和第二交易日志，输出测试结果。
54.其中，测试结果用于指示多个子系统中出现故障的子系统。
55.测试装置获取到第一交易日志和第二交易日志后，可以根据第一交易日志和第二交易日志，输出用于指示联机交易系统的多个子系统中出现故障的子系统。
56.上述实施例提供的技术方案至少带来以下有益效果，通过获取多个目标交易报文，并向联机交易系统发送多个目标交易报文以进行功能测试。并且，还可以获取到联机交易系统执行目标交易报文时产生的交易日志，根据交易日志，输出用于指示产生故障的子系统的交易结果。该系统功能的测试方法，可以自动地对联机交易系统进行测试，且在测试过程使用的大量报文，可以模拟真实交易过程中的交易高峰，防止由于交易量暴涨时联机交易系统可能出现的问题。相比于传统的人工抽检方法，该系统功能的测试方法效率更高，测试的范围更为全面，测试的结果更为可靠。保证了更新后的联机交易系统在投产后正常工作的稳定，避免系统故障对银行造成损失。
57.以下将结合具体实施例详细阐述本技术实施例提供的一种系统功能的测试方法，该方法可以应用于上述测试装置。如图3所示，该系统功能的测试方法可以包括如下s301-s306。
58.s301、从测试报文库中获取测试交易报文。
59.其中，测试报文库中可以包括多个测试交易报文，不同测试交易报文用于测试不同交易功能。
60.系统在开发新的版本或者进行版本更新后，往往需要进行系统功能的测试，以测试新的系统中新增的功能是否可以实现，更新后的系统是否会影响到原有功能的实现。预先建立的测试报文库中包括多个测试交易报文，不同的测试交易报文可以用于测试不同的交易功能。
61.在一些实施例中，在需要对系统功能进行测试时，测试装置可以从测试报文库中获取测试交易报文，以实现后续对系统功能的测试。
62.例如，银行的联机交易系统支持存款、转账、消费和消费撤销等交易功能。测试报文库存储有：测试交易报文a，测试交易报文b、测试交易报文c和测试交易报文d。其中，测试交易报文a可以用于测试存款功能，测试交易报文b可以用于测试转账功能，测试交易报文c可以用户测试消费功能，测试交易报文d可以用于测试消费撤销功能。测试装置可以从测试报文库中获取到测试交易报文a-测试交易报文d，以实现后续对存款、转账、消费和消费撤销功能的测试。
63.其中，上述测试报文库可以根据测试环境中的测试报文建立。
64.可以理解的是，在新版本的系统投产前，需要将更新的系统在测试环境中进行初步的测试，以测试功能是否正常。但是测试环境是虚拟的环境，无法测试出真实交易环境下的故障问题，例如交易量增多导致系统故障的问题。因此，本技术实施例可以从测试环境中获取测试报文，将测试报文的可替换参数替换为真实的用户信息(测试人员的真实信息，并不是银行客户的真实信息)，以得到用于测试真实的交易环境下的测试交易报文，并基于此建立测试报文库。
65.如，测试装置可以从测试环境中获取多个测试报文(这多个测试报文可以用于测试不同的交易功能)，将测试报文中可替换参数如商户参数、交易账户和交易金额等进行替换，替换为测试人员的真实信息，以得到多个可以执行真实交易过程的测试交易报文。之后，测试装置可以将这多个测试交易报文存储在测试报文库中，以实现测试报文库的建立。
66.需要说明的是，商户参数用于指示交易的发起位置，还包含商户的秘钥等关键参数设置。本技术实施例是模拟真实情况下的功能测试，因此需要对测试报文的商户参数也进行修改，修改为真实可用的商户参数，使得联机交易系统可以识别修改后的测试交易报文。
67.例如，结合上述示例，测试装置可以从测试环境中获取用于测试存款功能的测试报文a，将测试报文a中的商户参数、交易账户和交易金额使用测试人员的参数替换后，得到测试交易报文a。同样的，从测试环境中获取用于测试转账功能的测试报文b，将测试报文b中参数替换后得到测试交易报文b；用于测试消费功能的测试报文c进行参数替换后得到测试交易报文c；用于测试消费撤销功能的测试报文d进行参数替换后得到测试交易报文d。然后，测试装置将测试交易报文a-d存储在测试报文库中，以供后续的系统功能的测试。
68.需要说明的是，测试报文库中所有的测试交易报文可以测试联机交易系统的全部功能。因此，在联机交易系统更新后，如果有新增加的功能，例如新增了购买基金的功能，则将测试购买基金功能的对应测试交易报文添加到测试报文库中，以保证系统功能的全面测试。
69.s302、对测试交易报文中的至少一个交易参数进行多次修改，以获得多个目标交易报文。
70.其中，目标交易报文包括以下交易参数：交易账号，交易金额和交易时间。
71.联机交易系统的版本更新，从物理上可以观察到更新文件参数发生了变化，应用程序文件的大小发生了变化。但是实际的业务功能是否正常，则需要通过真实的交易进行验证与测试才能知道。而且，通常联机交易系统的升级部署都是在夜间，客户交易量较少的时候。这种情况下无法对联机交易系统进行全面化的验证与测试。容易在投产后，白天的业务高峰期出现故障问题，导致用户的使用体验下降。因此，需要在高交易量下测试系统功能是否正常。
72.在一些实施例中，在获取测试交易报文后，测试装置可以将测试交易报文中交易账号，交易金额和交易时间中至少一个参数进行替换，以获得多个目标交易报文。
73.示例性的，在获取测试交易报文后，测试装置可以将测试交易报文中的交易时间中这一参数进行多次替换，以获得多个目标交易报文。也就是说，获得的多个目标交易报文中，不同交易报文的交易账号和交易金额相同，交易时间不同。
74.例如，结合上述实施例中的示例，测试装置获取测试交易报文a，以测试存款功能是否正常。测试装置将测试交易报文a中交易时间这一参数进行替换，如替换为“2021/5/17/12:00”以得到目标交易报文a0，替换为“2021/5/17/12:01”以得到目标交易报文a1
…
替换为“2021/5/17/12:09”以得到目标交易报文a9。目标交易报文a1-目标交易报文a9均为测试存款功能的报文，这些报文中相邻两个报文的交易时间间隔为1分钟，即，每个报文的交易时间不同，其他参数如交易账号和交易金额均相同。
75.应理解的是，本技术实施例中使用真实的测试交易报文进行参数替换，实现使用一个测试交易报文生成大量的目标交易报文的效果。不需要增加测试人员的真实信息就可以在测试过程中模拟实际情况下的交易高峰期，能够更为全面地对联机交易系统的功能进行有效的验证与测试。
76.s303、向联机交易系统发送多个目标交易报文，以使得联机交易系统执行多个目标交易报文中每个目标交易报文对应的交易。
77.可以理解的是，上述目标交易报文是明文格式，目标交易报文中包含有客户的交易账号，交易金额和密码等较为私密的信息。为了保证客户的隐私与金融系统的安全性，发送给联机交易系统的报文，均需要加密为密文格式才能被联机交易系统所接收。因此测试装置在将目标交易报文发送给联机交易系统前，可以使用加密机加密，将目标交易报文由明文格式转换为密文格式后，再发送给联机交易系统执行交易过程。
78.在一些实施例中，测试装置在获取到多个目标交易报文后，将加密后的目标交易报文逐个发送给联机交易系统，以使得联机交易系统执行每个目标交易报文对应的交易。
79.例如，结合上述实施例中的示例，测试装置将目标交易报文a1-a9使用加密机加密后，将加密后的目标交易报文a1-a9逐个发送给联机交易系统执行交易过程。
80.s304、接收来自联机交易系统返回的与多个目标交易报文一一对应的交易结果。
81.其中，交易结果用于指示对应目标交易报文的交易是否成功；
82.如前述实施例所述，对于银行的联机交易系统来说，用户发起的一次业务操作，实质是产生了一个交易报文以触发联机交易系统执行对应的交易。因此，联机交易系统在接收到目标交易报文后，可以执行对应的交易过程，并产生交易结果(如，称为交易返回值)，还可以将交易结果发送给测试装置。
83.在一些实施例中，测试装置将多个目标交易报文发送给联机交易系统后，可以接收到来自联机交易系统发送的与多个目标交易报文一一对应的交易结果，测试装置可以根据交易结果确定目标交易报文对应的交易是否成功。
84.例如，结合上述实施例中的示例，联机交易系统执行目标交易报文a1-a5，目标交易报文a7-a9的交易结果均为200。联机交易系统执行目标交易报文a6的交易结果为400。其中，交易结果：200用于指示交易成功，交易结果：400用于指示交易失败。基于返回的这些交易结果，测试装置可以确定目标交易报文a1-a5，a7-a9的交易成功，目标交易报文a6的交易失败。
85.s305、在存在交易结果用于指示对应目标交易报文的交易失败的情况下，获取执行第一交易报文时联机交易系统产生的第一交易日志，以及执行第二交易报文时联机交易系统产生的第二交易日志。
86.其中，第一交易报文为多个目标交易报文中交易失败的报文，第二交易报文为多个目标交易报文中交易成功的报文。交易日志为系统产生的，可以反映交易执行情况的数据。测试装置可以根据目标交易报文中的关键参数如交易账号和交易金额等参数，从联机交易系统中查询并获取交易日志。
87.在存在交易结果用于指示对应目标交易报文的交易失败的情况下，测试装置可以获取执行交易失败的交易报文时联机交易系统产生的第一交易日志，以及执行交易成功的交易报文时联机交易系统产生的第二交易日志。
88.需要说明的是，联机交易系统包括多个子系统，每一类交易均对应一个交易链条，该交易链条由联机交易系统中的一个或多个子系统组成。不同类型交易对应的交易链条包括的子系统可能相同，也可以不同。因此，第一交易日志可以包括联机交易系统中参与第一交易报文执行的子系统的日志，第二交易日志可以包括联机交易系统中参与第二交易报文执行的子系统的日志。即，测试装置可以获取交易失败的报文对应的一个或多个子系统上产生的第一交易日志，以及获取交易成功的报文对应的一个或多个子系统上产生的第二交易日志。
89.示例性的，如前述实施例的描述，多个目标交易报文中只有交易时间不一样，其他参数均保持一致。因此，交易成功的报文，在被子系统执行时，子系统中生成的交易日志除了日志的产生时间不一样，其他的值均一致。基于此，测试装置可以使用交易账号和交易金额等作为关键参数从一个或多个子系统上查询对应交易日志。
90.例如，结合上述实施例中的示例，联机交易系统包含子系统a、b、c、d、e、f和g。上述示例中目标交易报文a1-a9是用于测试存款功能的交易报文，存款功能对应的交易链条可以描述为a-b-d-e，即子系统a，子系统b，子系统d和子系统e为执行存款交易的子系统。进一步的，由于目标交易报文a6的交易结果为400，说明目标交易报文a6为交易失败的交易报
文。测试装置可以使用目标交易报文的交易账号和交易金额等参数分别从子系统a，子系统b，子系统d和子系统e中查询交易日志。例如，查询到的交易日志如下表1所示：
91.表1
[0092] 子系统a子系统b子系统d子系统e目标交易报文a11234目标交易报文a21234目标交易报文a31234目标交易报文a41234目标交易报文a51234目标交易报文a61204目标交易报文a71234目标交易报文a81234目标交易报文a91234
[0093]
如表1所示，目标交易报文a6在子系统a中查询的交易日志的值描述为1，在子系统b中查询的交易日志的值描述为2，在子系统d中查询的交易日志的值描述为0，在子系统e中查询的交易日志的值描述为4。因此，目标交易报文a6对应的第一交易日志可以描述为1-2-0-6，与交易链条a-b-d-e一一对应。
[0094]
另外，测试装置还可以获取到交易成功的报文对应的第二交易日志。如表1所示，测试装置查询到目标交易报文a1在子系统a中的交易日志的值可以描述为1，在子系统b中的交易日志的值可以描述为2，在子系统d中的交易日志的值可以描述为3，在子系统e中的交易日志的值可以描述为4。因此，目标交易报文a1对应的第二交易日志可以描述为1-2-3-4。其余的目标交易报文均交易成功，因此对应的交易日志的值与目标交易报文a1的交易日志的值是一致，在此不再一一赘述。需要说的是，在实际使用时，可以仅获取一个交易成功的目标交易报文的交易日志。
[0095]
s306、根据第一交易日志和第二交易日志，输出测试结果。
[0096]
其中，测试结果用于指示多个子系统中出现故障的子系统。
[0097]
如前述实施例的描述，对于某种功能，测试使用的目标交易报文都是一样的，可能只是交易时间不一样。因此，联机交易系统中一个或多个子系统中对应的交易日志中应该只有时间不一致，其他的日志参数都应当保持一致。当某次交易的上一次交易成功，这次交易失败时，通过比较两次交易的交易日志，既可以快速诊断故障发生在哪个子系统上。
[0098]
在一些实施例中，测试装置在获取到第一交易日志和第二交易日志后，可以根据第一交易日志和第二交易日志，确定出多个子系统中出现故障的子系统并输出相关测试结果，以便于相关人员及时对故障的子系统进行维护。
[0099]
例如，结合上述实施例中的示例，测试装置可以根据目标交易报文a6的第一交易日志和目标交易报文a1的第二交易日志，确定出现故障的子系统。其中，第一交易日志的值描述为1-2-0-4，第二交易日志的值描述为1-2-3-4，通过对比两者的值，可以确定正常状态下子系统d的交易日志的值应该为3，但是目标交易报文a6在被子系统d执行时，子系统d产生的交易日志的值为0，说明在子系统d上出现了故障，然后测试装置可以输出测试结果。如，测试装置可以显示测试结果，测试结果的显示效果可以如图4中a所示，即显示存款对应
的交易链条上所有的子系统的标识，并突出显示出现故障的子系统的标识，如出现故障的子系统d的标识高亮显示，以用于指示该子系统d出现故障，方便技术人员快速确定存款交易中存在的故障点。技术人员还可以触发测试装置显示子系统d的故障详情，如图4中b所示。其中，故障详情可以包括子系统d的交易日志包括数据库日志和系统日志的具体描述信息，技术人员可以根据日志的具体描述信息确定故障的原因，以及时采取有效措施解决故障。
[0100]
需要说明的是，交易失败的报文的第一交易日志，可以与任一条交易成功的报文的第二交易日志对比，也可以选择使用与交易失败的报文时间最近的交易成功的报文来进行对比，例如上述示例中目标交易报文a6的上一个目标交易报文a5，时间相近的报文对比确定故障的效果更好。本技术实施例对此不做限制。
[0101]
上述实施例提供的技术方案至少带来以下有益效果，通过获取多个目标交易报文，并向联机交易系统发送多个目标交易报文以进行功能测试。并且，还可以获取到联机交易系统执行目标交易报文时产生的交易日志，根据交易日志，输出用于指示产生故障的子系统的交易结果。该系统功能的测试方法，可以自动地对联机交易系统进行测试，且在测试过程使用的大量报文，可以模拟真实交易过程中的交易高峰，防止由于交易量暴涨时联机交易系统可能出现的问题。相比于传统的人工抽检方法，该系统功能的测试方法效率更高，测试的范围更为全面，测试的结果更为可靠。保证了更新后的联机交易系统在投产后正常工作的稳定，避免系统故障对银行造成损失。
[0102]
进一步的，本方案借助灰度测试的思想，通过使用少部分测试人员的真实信息来生成测试交易报文以进行测试，避免使用包含有客户信息的交易报文造成客户的隐私泄漏的情况。还借助了a/b测试的思想，在获取交易成功的报文对应的交易日志和交易失败的报文对应的交易日志后，比对相同功能的交易日志的异常点，可以快速定位故障的产生范围，有利于在开门营业前尽快发现故障并及时修复。另外，本方案节约了人力资源，方案中使用自动化测试的方案，可以应用于各种自动化部署的产品中，大幅度提高测试的效率和准确性。
[0103]
本技术还提供一种测试流程图，如图5所示。首先构建真实报文库(相当于上述实施例中构建测试报文库)，然后发送报文给联机交易系统。进一步的，进行全链条提取数据(相当于上述实施例中从联机交易系统获取交易日志)，最后结果分析展示(相当于上述实施例中输出测试结果)。
[0104]
本技术还提供另一种测试流程图，如图6所示。在生产环境联机交易中，匹配抽取业务自有卡信息(相当于上述实施例中将测试报文将交易参数替换为测试人员的真实信息)，然后建立生产报文库(相当于上述实施例中构建测试报文库)。在联机系统投产后，向联机系统推送生产报文(相当于上述实施例中向联机交易系统发送目标交易报文)。最后，联机系统接收到生成报文后在生产环境中验证联机交易。
[0105]
在示例性的实施例中，本技术还提供一种测试装置。该测试装置可以包括一个或多个功能模块，用于实现以上方法实施例的系统功能的测试方法。
[0106]
例如，图7为本技术实施例提供的一种测试装置的组成示意图。如图7所示，该测试装置包括：获取模块701、发送模块702、接收模块703和输出模块704。获取模块701、发送模块702、接收模块703和输出模块704互相连接。
[0107]
获取模块701，用于获取多个目标交易报文，目标交易报文包括以下交易参数：交易账号，交易金额和交易时间，多个目标交易报文中不同目标交易报文至少存在一个交易参数不同。
[0108]
发送模块702，用于向联机交易系统发送多个目标交易报文，以使得联机交易系统执行多个目标交易报文中每个目标交易报文对应的交易。
[0109]
接收模块703，用于接收来自联机交易系统返回的与多个目标交易报文一一对应的交易结果，交易结果用于指示对应目标交易报文的交易是否成功。
[0110]
获取模块701，还用于在存在交易结果用于指示对应目标交易报文的交易失败的情况下，获取执行第一交易报文时联机交易系统产生的第一交易日志，以及执行第二交易报文时联机交易系统产生的第二交易日志；其中，第一交易报文为多个目标交易报文中交易失败的报文，第二交易报文为多个目标交易报文中交易成功的报文。
[0111]
输出模块704，用于根据第一交易日志和第二交易日志，输出测试结果，测试结果用于指示多个子系统中出现故障的子系统。
[0112]
在一些实施例中，多个目标交易报文中不同目标交易报文至少存在一个交易参数不同，包括：多个目标交易报文中，不同交易报文的交易账号和交易金额相同，交易时间不同。
[0113]
在一些实施例中，另一种可能的实现方式中，第一交易日志包括联机交易系统中参与第一交易报文执行的子系统的日志；第二交易日志包括联机交易系统中参与第二交易报文执行的子系统的日志。
[0114]
在一些实施例中，获取模块701，具体用于获取测试交易报文，测试交易报文包括以下交易参数：交易账号，交易金额和交易时间，测试交易报文用于测试一个交易功能；对测试交易报文中的至少一个交易参数进行多次修改，以获得多个目标交易报文。
[0115]
在一些实施例中，获取模块701，具体用于从测试报文库中获取测试交易报文，测试报文库中包括多个测试交易报文，不同测试交易报文用于测试不同交易功能。
[0116]
在示例性的实施例中，本技术实施例还提供了一种电子设备，该电子设备可以是上述方法实施例中的测试装置。图8为本技术实施例提供的电子的组成示意图。如图8所示，该测试装置可以包括：处理器801和存储器802；存储器802存储有处理器801可执行的指令；处理器801被配置为执行指令时，使得电子设备实现如前述方法实施例中描述的方法。
[0117]
在示例性的实施例中，本技术实施例还提供一种计算机可读存储介质，其上存储有计算机程序指令；当计算机程序指令被计算机执行时，使得计算机实现如前述实施例中描述的方法。其中，计算机可以是上述电子设备。计算机可读存储介质可以是非临时性计算机可读存储介质，例如，非临时性计算机可读存储介质可以是rom、随机存取存储器(ram)、cd-rom、磁带、软盘和光数据存储设备等。
[0118]
在示例性的实施例中，本技术实施例还提供了一种计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述相关方法步骤，以实现上述实施例中的系统功能的测试方法。
[0119]
以上，仅为本技术的具体实施方式，但本技术的保护范围并不局限于此，任何在本技术揭露的技术范围内的变化或替换，都应涵盖在本技术的保护范围之内。因此，本技术的保护范围应该以权利要求的保护范围为准。