CN115543837A - 软件测试方法、装置、电子设备及存储介质 - Google Patents

Abstract

本申请涉及金融科技技术领域，公开了一种软件测试方法、装置、电子设备及存储介质，该方法应用于前置系统，该方法包括：获取外部系统发送的交易请求；从交易请求中获取交易属性；将交易属性与配置文件中的交易属性验证条件进行匹配；若交易请求中的交易属性与交易属性验证条件匹配，将交易请求转发到第一计算设备，第一计算设备中部署的待测试版本的目标软件对交易请求进行处理，并根据待测试版本的目标软件对交易请求的处理结果确定待测试版本的测试结果；若交易请求中的交易属性与交易属性验证条件不匹配，将交易请求转发到第二计算设备。本申请可以降低因软件测试不通过对后置系统的影响。

Description

软件测试方法、装置、电子设备及存储介质

技术领域

本申请涉及金融科技技术领域，更具体地，涉及一种软件测试方法、装置、电子设备及存储介质。

背景技术

相关技术中，由于交易业务的需要，后置系统需要承担的交易功能越来越多，从而，为了满足交易的需要，需要对后置系统中部署的用于进行交易处理的目标软件进行版本更新。但是，在新版本的目标软件测试过程中，若确定该新版本的目标软件验证失败，需要将该新版本的目标软件进行回退处理，即后置系统整体进行停机处理，在后置系统停机处理期间，无法正常进行交易请求处理。

发明内容

鉴于上述问题，本申请实施例提出了一种软件测试方法、装置、电子设备及存储介质，以解决相关技术中因新版本的软件测试不通过造成后置系统整体停机的问题。

根据本申请实施例的一个方面，提供了一种软件测试方法，应用于前置系统，所述前置系统与后置系统通信连接，所述后置系统包括第一计算设备和第二计算设备，所述第二计算设备是指所述后置系统中除所述第一计算设备外部署了目标软件的其他计算设备；所述目标软件的待测试版本部署在所述第一计算设备上，所述第二计算设备上所部署目标软件的版本低于所述待测试版本；所述前置系统中存储了待测试版本的目标软件对应的配置文件，所述配置文件包括为待测试版本配置的交易属性验证条件和所述第一计算设备的目标网络地址，该方法包括：获取外部系统发送的交易请求；从所述交易请求中获取交易属性；将所述交易属性与所述配置文件中的交易属性验证条件进行匹配；若所述交易请求中的交易属性与所述交易属性验证条件匹配，将所述交易请求转发到所述第一计算设备，所述第一计算设备中部署的待测试版本的目标软件对所述交易请求进行处理，并根据所述待测试版本的目标软件对所述交易请求的处理结果确定所述待测试版本的测试结果；若所述交易请求中的交易属性与所述交易属性验证条件不匹配，将所述交易请求转发到所述第二计算设备，以通过所述第二计算设备中部署的目标软件对所述交易请求进行处理。

在本申请的一些实施例中，所述将所述交易属性与所述配置文件中的交易属性验证条件进行匹配之前，所述方法还包括：在所述前置系统中的服务启动后，获取内存中所述配置文件的修改时间；若确定内存中所述配置文件的修改时间与缓存中配置文件的最后一次修改时间不同，则将内存中的配置文件加载到缓存中；所述将所述交易属性与所述配置文件中的交易属性验证条件进行匹配，包括：从加载的配置文件中读取交易属性验证条件；将所述交易属性与所读取的交易属性验证条件进行匹配。

在本申请的一些实施例中，所述在所述前置系统中的服务启动后，获取内存中所述配置文件的修改时间之后，所述方法还包括：若确定内存中所述配置文件的修改时间与缓存中配置文件的最后一次修改时间相同，从缓存中的配置文件中读取交易属性验证条件；所述将所述交易属性与所述配置文件中的交易属性验证条件进行匹配，包括：将所述交易属性与从所述缓存中读取的交易属性验证条件进行匹配。

在本申请的一些实施例中，所述方法还包括：确定所述配置文件中验证开关的状态；若所述验证开关的状态为打开状态，执行所述从所述交易请求中获取交易属性的步骤。

在本申请的一些实施例中，所述确定所述配置文件中验证开关的状态之后，所述方法还包括：若所述验证开关的状态为关闭状态，将所述交易请求转发到所述第二计算设备。

在本申请的一些实施例中，所述从所述交易请求中获取交易属性，包括：从所述交易属性验证条件中获取验证字段的值，所述验证字段的值用于指示交易属性；按照所述验证字段的值从所述交易请求中提取对应的交易属性。

在本申请的一些实施例中，所述将所述交易请求转发到所述第一计算设备之后，所述方法还包括：接收所述第一计算设备返回的处理结果；将所述处理结果转发至所述外部系统。

根据本申请实施例的一个方面，提供了一种软件测试装置，应用于前置系统，所述前置系统与后置系统通信连接，所述后置系统包括第一计算设备和第二计算设备，所述第二计算设备是指所述后置系统中除所述第一计算设备外部署了目标软件的其他计算设备；所述目标软件的待测试版本部署在所述第一计算设备上，所述第二计算设备上所部署目标软件的版本低于所述待测试版本；所述前置系统中存储了待测试版本的目标软件对应的配置文件，所述配置文件包括为待测试版本配置的交易属性验证条件和所述第一计算设备的目标网络地址，所述装置包括：交易请求获取模块，用于获取外部系统发送的交易请求；交易属性获取模块，用于从所述交易请求中获取交易属性；匹配模块，用于将所述交易属性与所述配置文件中的交易属性验证条件进行匹配；第一转发模块，用于若所述交易请求中的交易属性与所述交易属性验证条件匹配，将所述交易请求转发到所述第一计算设备，所述第一计算设备中部署的待测试版本的目标软件对所述交易请求进行处理，并根据所述待测试版本的目标软件对所述交易请求的处理结果确定所述待测试版本的测试结果；第二转发模块，用于若所述交易请求中的交易属性与所述交易属性验证条件不匹配，将所述交易请求转发到所述第二计算设备，以通过所述第二计算设备中部署的目标软件对所述交易请求进行处理。

根据本申请实施例的一个方面，提供了一种电子设备，包括：处理器；存储器，所述存储器上存储有计算机可读指令，所述计算机可读指令被所述处理器执行时，实现如上所述软件测试方法。

根据本申请实施例的一个方面，提供了一种计算机可读存储介质，其上存储有计算机可读指令，当所述计算机可读指令被处理器执行时，实现如上所述软件测试方法。

根据本申请实施例的一个方面，提供了一种计算机程序产品，其包括计算机指令，所述计算机指令被处理器执行时实现如上的软件测试方法。

在本申请中，将待测试版本的目标软件部署在后置系统中的第一计算设备上，将低于待测试版本的其他版本的目标软件部署在后置系统中的第二计算设备上，这样，可以基于配置文件中的交易属性验证条件，筛选出用于作为测试用例的交易请求，并将作为测试用例的交易请求转发到第一计算设备上进行处理，以测试第一计算设备上所部署待测试版本的目标软件的性能。而将其他的交易请求转发到第二计算设备上进行处理，这样，即使测试结果确定第一计算设备上所部署待测试版本的目标软件验证失败，也不影响第二计算设备继续进行交易业务处理，也不需要对全部交易请求进行二次处理，仅需要对作为测试用例的交易请求进行二次处理，由此可以降低因待测试版本的目标软件测试不通过的情况下对后置系统整体交易业务处理造成的影响。

此外，如果验证确定待测试版本的目标软件测试不通过，也可以仅对第一计算设备进行停机隔离处理，而第二计算设备可以继续提供交易业务处理服务，从而，避免目标软件的测试过程中因测试不通过导致后置系统完全瘫痪的情况。进一步的，由于在本申请中，前置系统是通过配置文件中的交易属性验证条件来筛选需要转发到第一计算设备的交易请求，则可以通过修改配置文件中的交易属性验证条件，在第一计算设备停机隔离处理期间，使原本需要转发到第一计算设备进行处理的交易请求转发到第二计算设备进行处理。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是根据本申请一实施例示出的本申请的应用场景的示意图。

图2是根据本申请的一个实施例示出的软件测试方法的流程图。

图3是根据本申请一实施例示出步骤230之前步骤的流程图。

图4是根据本申请另一实施例示出的软件测试方法的流程图。

图5是根据本申请一具体实施例示出的软件测试方法的流程图。

图6是根据本申请一实施例示出的软件测试装置的框图。

图7示出了适于用来实现本申请实施例的电子设备的结构示意图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本申请将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。

附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。

需要说明的是：在本文中提及的“多个”是指两个或两个以上。“和/或”描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

实际中，由于后置系统需要承担的交易功能越来越多，为了满足交易的需要，需要对目标软件进行版本更新。但是，在新版本的目标软件测试过程中，若确定该新版本的目标软件验证失败，则需要将该新版本的目标软件进行回退处理，即后置系统整体进行停机处理，在后置系统停机处理期间，无法正常进行交易请求处理。

而且，如果新版本的目标软件进行回退处理，这样，需要在更新后对在测试过程中所接收到的全部交易请求再次进行处理，影响了后置系统开展正常的交易业务处理，而且，这样导致软件的测试周期长。基于此，提出了本申请的方案。

图1是根据本申请一实施例示出的本申请的应用场景的示意图，如图1所示，该应用场景中包括至少一外部系统110、前置系统120和后置系统130，其中，外部系统110与前置系统120通过有线或者无线网络通信连接，前置系统120和后置系统130通过有线或者无线网络通信连接。

后置系统至少包括第一计算设备131和至少一第二计算设备132，第一计算设备131和第二计算设备132分别与前置系统120通信连接。在本申请中，将需要进行测试的软件称为目标软件。其中，目标软件的待测试版本部署在第一计算设备131上，目标软件的稳定运行版本部署在第二计算设备132上。或者，可以理解为，第二计算设备132上所运行目标软件的版本低于目标软件的待测试版本。

其中，前置系统120作为后置系统130与外部系统进行对接的通道，或者前置系统120是后置系统130与外部系统之间的中间业务交换平台，后置系统130用于处理交易业务。前置系统120不具有处理交易业务的功能，只能进行报文转换、报文的加解密处理、通讯协议转换，以及，通过路由功能进行通讯报文的转入或转出处理。

实际中，与前置系统120所通信连接的外部系统可能为多个，由于不同的外部系统使用的通信协议不同，不同的外部系统可能采用的通信协议不同，这样，可以通过前置系统120统一将外部系统所发起的交易请求进行格式转换，以将外部系统发起的交易请求转换为后置系统130所支持的指定通信协议所要求的格式，从而，后置系统130可以专注于对交易请求进行处理，而不需要关注所接收到的交易请求的通信协议。同理，在后置系统130在对交易请求处理结束后，将交易请求发送到前置系统120，由前置系统120将交易请求的处理结果转换为交易请求所来源外部系统支持的格式，然后将格式转换后的处理结果转发到对应的外部系统。

在一些实施例中，前置系统120还可以对后置系统130和外部系统之间所传递的数据进行加密和解密处理，即，前置系统120可以将所接收到来自外部系统的交易请求进行解密处理，然后将解密处理后的交易请求转发到后置系统130；同理，前置系统120在接收到来自后置系统130的处理结果后，将处理结果进行加密处理，然后将加密处理后的处理结果转发到对应的外部系统。

在一具体实施例中，前置系统120可以是银行前置系统，后置系统130可以是银行后置系统130，外部系统可以是银行外部的公积金系统、养老保险系统、医保系统或者某一企业的企业系统(例如财务系统等)。

在本申请中，对于后置系统中部署的目标软件，将目标软件的待测试版本部署在后置系统中的第一计算设备上，将目标软件的其他版本(例如稳定运行版本)部署在后置系统中的第二计算设备上，这样，借助于前置系统的路由功能，将外部系统发起的部分交易请求转发到第一计算设备上进行处理，以验证第一计算设备上所部署的待测试版本的目标软件的性能；而将外部系统发起的其他交易请求转发到第二计算设备上进行处理。这样，即使第一计算设备上所部署的待测试版本的目标软件验证存在异常，也不会影响第二计算设备处理其他的交易请求。

以下对本申请实施例的技术方案的实现细节进行详细阐述：

图2是根据本申请的一个实施例示出的软件测试方法的流程图，该方法可以由具备处理能力的电子设备，例如前置系统中的服务器执行。该方法应用于前置系统，前置系统与后置系统通信连接，后置系统包括第一计算设备和第二计算设备，第二计算设备是指后置系统中除第一计算设备外部署了目标软件的其他计算设备；目标软件的待测试版本部署在第一计算设备上，第二计算设备上所部署目标软件的版本低于待测试版本；前置系统中存储了待测试版本的目标软件对应的配置文件，配置文件包括为待测试版本配置的交易属性验证条件和第一计算设备的目标网络地址。如图2所示，该方法包括步骤210至250，详细介绍如下：

步骤210，获取外部系统发送的交易请求。

目标软件是指后置系统中用于处理交易业务的应用程序。

其中，外部系统可以社保系统、医保系统、公积金系统、企业系统等，在此不进行具体限定。交易请求可以是转账交易请求、扣款交易请求、号码绑定请求、账单还款交易请求等，在此不进行具体限定。在一具体实施例中，该外部系统还可以是测试系统，该测试系统可以模拟向前置系统发送作为测试用例的交易请求。

步骤220，从交易请求中获取交易属性。

交易属性是指用于反映交易请求的属性特征的信息。交易属性可以是协议号、账户类型、业务类型等，在此不进行具体限定。可以理解的是，从交易请求中获取的交易属性相当于是交易属性的具体内容，或者称为交易属性的值。距离来说，若需要获取的交易属性为协议号，则从交易请求中所获取的是协议号的具体内容，例如协议号为402222。

在一些实施例中，步骤220包括：从交易属性验证条件中获取验证字段的值，验证字段的值用于指示交易属性；按照验证字段的值从交易请求中提取对应的交易属性。

在一些实施例中，配置文件可以是由后置系统发送到前置系统的。在该种情况下，开发人员可以在后置系统中的终端中进行配置，得到配置文件，然后通过后置系统与前置系统之间的通信连接，将配置文件发送到前置系统中，并对应将配置文件存储在前置系统的内存中。

在另一些实施例中，配置文件可以是由测试人员在前置系统中进行配置得到的。在该种情况下，测试人员可以在前置系统中的终端中进行配置，得到配置文件，之后，将配置文件发送到前置系统的服务器中，并将配置文件存储在前置系统的服务器的内存中。

交易属性验证条件用于限定用于对待测试的目标版本的交易请求所需要满足的条件，换言之，若一交易请求对应的交易属性满足交易属性验证条件所限定的条件，则确定该交易请求是用于对待测试版本的目标软件进行测试的请求，用于对待测试版本的目标软件进行测试的请求也可以理解为待测试版本的目标软件对应的测试用例。

在交易属性验证条件中，可以通过验证字段来指示所要提取的交易属性。其中，交易属性验证条件中的验证字段可以是一个也可以是多个，一个验证字段用于指示一种交易属性。例如，用字段A来指示协议号，用字段B来指示账户类型，用字段C来指示业务类型等。由于交易属性验证条件中通过交易字段来指示了所需要验证的交易属性，因此，按照交易字段的值来进行交易属性提取，保证可以提取到用于验证的交易属性，而交易请求中不需要用于验证的交易属性可以不用提取，从而避免浪费处理资源和存储资源。

例如，通过交易属性验证条件可以限定以40222开头的协议号发起的交易请求用于测试待测试版本的目标软件。例如，通过如下的代码来作为交易属性验证条件：

其中，keyBody为验证字段，在如上的代码中，keyBody的值为SignSN，SignSN用于表示协议号，交易属性验证条件中所限定的协议号为以40222开头的协议号。从而，基于如上的属性验证条件可以从交易请求中提取协议号这一交易属性，对应获得交易请求所对应协议号的具体内容，或者是获得交易请求中协议号的值。

在具体实施例中，交易属性验证条件中所指定的验证字段可以为一个或者多个，这样，当交易属性验证条件中所指定的验证字段为多个的情况下，则对应指示用于验证的交易属性为多种。

举例来说，将如下的代码来作为交易属性验证条件：

其中，keyHead和keyBody为验证字段，在如上的代码中，keyHead的值为MagTp，MagTp用于表示业务类型；keyBody这一验证字段的值为BizTP，BizTP用于表示账户类型；如上的交易属性验证条件表示将业务类型为epcc.211.001.01且账户类型为13000或者14000的交易请求作为用于测试待测试版本的目标软件。

步骤230，将交易属性与配置文件中的交易属性验证条件进行匹配。

交易属性验证条件包括各交易属性配置的参考属性条件。如上所描述，交易属性验证条件可以包括一个验证字段，也可以包括多个验证字段。在交易属性验证条件包括一个验证字段的情况下，交易属性条件中对应包括为该验证字段所指示交易属性设定的参考属性条件。在该种情况下，对应将从交易请求中所提取到的交易属性的属性内容与交易属性验证条件中该交易属性对应的参考属性条件进行对比，以确定交易请求中该交易属性的属性内容是否满足所对应的参考属性条件，若满足，则确定从交易请求中获取的交易属性与交易属性验证条件相匹配；反正，若不满足，则确定从交易请求中获取的交易属性与交易属性验证条件不匹配。

在交易属性验证条件中包括多个验证字段的情况下，交易属性验证条件指示了多个交易属性所分别对应的参考属性条件，以及多个参考属性条件之间的逻辑运算关系，其中，逻辑运算关系包括逻辑与、逻辑或、逻辑非等。从而，交易属性验证条件是通过多个交易属性对应的参考属性条件和多个参考属性条件之间的逻辑运算关系所共同限定的。

步骤240，若交易请求中的交易属性与交易属性验证条件匹配，将交易请求转发到第一计算设备，第一计算设备中部署的待测试版本的目标软件对交易请求进行处理，并根据待测试版本的目标软件对交易请求的处理结果确定待测试版本的测试结果。

如上所描述，如果交易请求中的交易属性与交易属性验证条件匹配，表明该交易请求是用于对待测试版本的目标软件进行测试，因此，对应将该交易请求转发到第一计算设备。之后，由第一计算设备中所部署待测试版本的目标软件对交易请求进行处理，得到该交易请求对应的处理结果。

如果第一计算设备确定该交易请求的处理结果无误，则需要将该交易请求的处理结果返回到前置系统，并由前置系统进行处理后，由前置系统将处理结果转发至对应的外部系统。即，在步骤240之后，该方法还包括：接收第一计算设备返回的处理结果；将处理结果转发至外部系统。反之，如果第一计算设备确定交易请求的处理结果有误，则第一计算设备可以向前置系统发送处理失败提示信息，并将该处理失败提示信息发送到前置系统，由该前置系统将处理失败提示信息转发至外部系统。

在一些实施例中，在后置系统中还可以部署测试管理设备，该测试管理设备中可以存储满足交易属性验证条件的交易请求所对应的参考处理结果，该参考处理结果为在待测试版本的目标软件针对该交易请求的处理逻辑准确的情况下，该交易请求的准确的处理结果。由此，在第一计算设备对所接收到的交易请求进行处理后，将所得到的处理结果发送到测试管理设备，测试管理设备对应将该交易请求对应的处理结果和参考处理结果进行比较，如果二者一致，表明交易请求的处理结果准确无误，反之，如果二者不一致，则表明待测试版本的目标软件针对交易请求的处理结果有误。

步骤250，若交易请求中的交易属性与交易属性验证条件不匹配，将交易请求转发到第二计算设备，以通过第二计算设备中部署的目标软件对交易请求进行处理。

如上所描述，如果交易请求中的交易属性与交易属性验证条件不匹配，则表明该交易请求不是用于对待测试版本的目标软件进行测试的。从而，将该交易请求发送到第二计算设备，由第二计算设备中所部署的目标软件对交易请求进行处理。

在步骤250之后，该方法还包括：接收第一计算设备返回的处理结果；将处理结果转发至外部系统。可以理解的是，前置系统可以是在对处理结果进行协议转换或者加密处理后再将处理结果转发至对应的外部系统。

在本申请的后置系统中，将待测试版本的目标软件部署在第一计算设备上，将低于待测试版本的其他版本的目标软件部署在第二计算设备上，这样，可以基于配置文件中的交易属性验证条件，筛选出用于作为测试用例的交易请求，并将作为测试用例的交易请求转发到第一计算设备上进行处理，以测试第一计算设备上所部署待测试版本的目标软件的性能。而将其他的交易请求转发到第二计算设备上进行处理，这样，即使测试结果确定第一计算设备上所部署待测试版本的目标软件验证失败，也不影响第二计算设备进行交易业务处理，也不需要对全部交易请求进行二次处理，仅需要对作为测试用例的交易请求进行二次处理，由此可以降低因待测试版本的目标软件测试不通过的情况下对后置系统整体交易业务处理造成的影响。

此外，如果验证确定待测试版本的目标软件测试不通过，也可以仅对第一计算设备进行停机隔离处理，而第二计算设备可以继续提供交易业务处理服务，从而，避免目标软件的测试过程中因测试不通过导致后置系统完全瘫痪的情况。进一步的，由于在本申请中，前置系统是通过配置文件中的交易属性验证条件来筛选需要转发到第一计算设备的交易请求，则可以通过修改配置文件中的交易属性验证条件，在第一计算设备停机隔离处理期间，使原本需要转发到第一计算设备进行处理的交易请求转发到第二计算设备进行处理。

进一步的，若确定待测试版本的目标软件测试通过，则可以对应将待测试版本的目标软件部署到第二计算设备中，实现待测试版本的目标软件在后置系统中的全部署。

在一些实施例中，如图3所示，步骤230之前，该方法还包括：

步骤310，在前置系统中的服务启动后，获取内存中配置文件的修改时间。

步骤320，若确定内存中配置文件的修改时间与缓存中配置文件的最后一次修改时间不同，则将内存中的配置文件加载到缓存中。

在本实施例中，步骤230，包括：从加载的配置文件中读取交易属性验证条件；将交易属性与所读取的交易属性验证条件进行匹配。

可以理解的是，如果内存中配置文件的修改时间与缓存中配置文件的最后一次修改时间不同，表明，相较于缓存中被加载的配置文件，内存中的配置文件被修改了，从而，在该种情况下，为了保证交易请求准确被识别为是否用于对待测试版本的目标软件进行测试的交易请求，需要将内存中的配置文件加载到缓存中，以替换缓存中的配置文件。

而且，在本实施例中，由于在前置系统中的服务启动后，先判断内存中配置文件的修改时间与缓存中配置文件的最后一次修改时间是否相同，这样，在内存中的配置文件被修改的情况下，可以保证最新的配置文件可以实时生效，而不需要将前置系统进行重启才生效。从而，可以满足配置文件的动态更新需要，被更新的配置文件实时生效。

在一些实施例中，步骤310之后，该方法还包括：若确定内存中配置文件的修改时间与缓存中配置文件的最后一次修改时间相同，从缓存中的配置文件中读取交易属性验证条件；在本实施例中，步骤230，包括：将交易属性与从缓存中读取的交易属性验证条件进行匹配。

也就是说，如果内存中的配置文件未更新的情况下，表明内存和缓存中的配置文件是相同的，从而，若确定内存中配置文件的修改时间与缓存中配置文件的最后一次修改时间相同，直接从缓存中的配置文件中读取交易属性验证条件，而不需要重新将内存中的配置文件加载到缓存中。

在一些实施例中，如图4所示，该方法还包括：

步骤410，确定配置文件中验证开关的状态。

若验证开关的状态为打开状态，执行步骤220。

若验证开关的状态为关闭状态，执行步骤420，将交易请求转发到第二计算设备。

配置文件中可以包括开关字段，通过开关字段的值来指示验证开关的状态。可以理解的是，开关字段的值包括用于指示验证开关为打开状态的值和用于指示验证开关为关闭状态的值。由此，可以通过读取配置文件中开关字段的值来确定配置文件中验证开关的状态。

值得一提的是，在内存中的配置文件的修改时间与缓存中配置文件的最后一次修改时间相同，在步骤410中，是从缓存中的配置文件中确定验证开关的状态；在内存中的配置文件的修改时间与缓存中配置文件的最后一次修改时间不同，在步骤410中，先将内存中的配置文件加载到缓存中，然后再从被加载到缓存中的配置文件中确定验证开关的状态。

在验证开关为打开状态的情况下，表明此时是需要对待测试的目标软件进行测试，从而，需要将交易请求中的交易属性与交易属性验证条件进行匹配；反之，在验证开关为关闭状态的情况下，表明此时不需要对待测试的目标软件进行测试，对应的也不需要将交易请求发送到第一计算设备进行处理，所以，在该种情况下，将交易请求都转发到第二计算设备进行处理即可，也不需要从交易请求中获取交易属性，以及将交易属性与交易属性验证条件进行匹配。

举例来说，若上一次测试确定待测试版本的目标软件测试不通过，需要对第一计算设备进行隔离停机处理，则可以通过配置文件中验证字段的值，使验证开关处于关闭状态，这样，在对第一计算设备进行隔离停机处理期间，可以使全部交易请求都被转发到第二计算设备进行处理。

图5是根据本申请一具体实施例示出的软件测试方法的流程图，该方法可以应用于前置系统，如图5所示，在前置系统中的服务启动后，执行如下的步骤510-步骤580，详细介绍如下：

步骤510，监听外部系统的交易请求。

步骤520，获取交易请求。

步骤530，判断配置文件是否被更新；若未被更新，则执行步骤540，若被更新，执行步骤550，将内存中的配置文件加载到缓存中。具体的，通过比较内存中配置文件的修改时间与缓存中配置文件的最后一次修改时间是否相同来判断配置文件是否被更新，即若两时间相同，则确定配置文件未被更新；若两时间不同，则确定配置文件被更新。

步骤540，读取缓存中的配置文件。

步骤560，判断是否开启验证；若为是，执行步骤570；若为否，执行步骤580。具体的，通过读取配置文件中开关字段的值来判断是否开启验证，若配置文件中开关字段的值指示验证开关为打开状态，则表明开启验证；若配置文件中开关字段的值指示验证开关为关闭状态，则表明未开启验证。

步骤570，判断交易请求中的交易属性与交易属性验证条件是否匹配；若为是，执行步骤571；若为否，执行步骤580。

步骤571，将交易请求转发到第一计算设备。

步骤580，将交易请求转发到第二计算设备。

在步骤571和步骤580之后，返回执行步骤510。

基于如上的实施例，待测试版本的目标软件发布在后置系统中的部分计算设备(例如发布到一台第一计算设备上，当然，后置系统中的第一计算设备也可以是多台)，后置系统中的第二计算设备上部署目标软件的其他版本，在对待测试版本的目标软件进行测试期间，可以由第一计算设备和第二计算设备共同提供服务，即使待测试版本的目标软件测试不通过，也可以由第二计算设备继续提供服务，而不会使后置系统整体退回停机，从而本实施例所提供的方案可以有效避免因新版本的软件测试不通过导致后置系统整体停机的情况，从而，降低因新版本的软件测试不通过对后置系统的业务处理的影响，可以有效避免大量的交易请求被延迟处理或者处理失败的情况；而且，该方案可以减少在新版本的目标软件测试期间后置系统发生生产事件的概率，大大提升了后置系统的安全性和稳定性。而且，本方案对后置系统透明，不需要对后置系统进行大改动。

以下介绍本申请的装置实施例，可以用于执行本申请上述实施例中的方法。对于本申请装置实施例中未披露的细节，请参照本申请上述方法实施例。

图6是根据本申请一实施例示出的软件测试装置的框图，该软件测试装置应用于前置系统，前置系统与后置系统通信连接，后置系统包括第一计算设备和第二计算设备，第二计算设备是指后置系统中除第一计算设备外部署了目标软件的其他计算设备；目标软件的待测试版本部署在第一计算设备上，第二计算设备上所部署目标软件的版本低于待测试版本；前置系统中存储了待测试版本的目标软件对应的配置文件，配置文件包括为待测试版本配置的交易属性验证条件和第一计算设备的目标网络地址。如图6所示，该软件测试装置包括：

交易请求获取模块610，用于获取外部系统发送的交易请求；

交易属性获取模块620，用于从交易请求中获取交易属性；

匹配模块630，用于将交易属性与配置文件中的交易属性验证条件进行匹配；

第一转发模块640，用于若交易请求中的交易属性与交易属性验证条件匹配，将交易请求转发到第一计算设备，第一计算设备中部署的待测试版本的目标软件对交易请求进行处理，并根据待测试版本的目标软件对交易请求的处理结果确定待测试版本的测试结果；

第二转发模块650，用于若交易请求中的交易属性与交易属性验证条件不匹配，将交易请求转发到第二计算设备，以通过第二计算设备中部署的目标软件对交易请求进行处理。

在本申请的一些实施例中，软件测试装置还包括：修改时间获取模块，用于在前置系统中的服务启动后，获取内存中配置文件的修改时间；加载模块，用于若确定内存中配置文件的修改时间与缓存中配置文件的最后一次修改时间不同，则将内存中的配置文件加载到缓存中；在本实施例中，匹配模块630进一步被配置为：从加载的配置文件中读取交易属性验证条件；将交易属性与所读取的交易属性验证条件进行匹配。

在本申请的一些实施例中，软件测试装置还包括：读取模块，用于若确定内存中配置文件的修改时间与缓存中配置文件的最后一次修改时间相同，从缓存中的配置文件中读取交易属性验证条件；在本实施例中，匹配模块630进一步被配置为：将交易属性与从缓存中读取的交易属性验证条件进行匹配。

在本申请的一些实施例中，软件测试装置还包括：状态确定模块，用于确定配置文件中验证开关的状态；若验证开关的状态为打开状态，执行从交易请求中获取交易属性的步骤。

在本申请的一些实施例中，软件测试装置还包括：第三转发模块，用于若验证开关的状态为关闭状态，将交易请求转发到第二计算设备。

在本申请的一些实施例中，交易属性获取模块620包括：获取单元，用于从交易属性验证条件中获取验证字段的值，验证字段的值用于指示交易属性；提取单元，用于按照验证字段的值从交易请求中提取对应的交易属性。

在本申请的一些实施例中，软件测试装置还包括：处理结果接收模块，用于接收第一计算设备返回的处理结果；第四转发模块，用于将处理结果转发至外部系统。

图7是根据本申请一实施例示出的电子设备的结构示意图。该电子设备可以是前置系统中的服务器，用于执行本申请所提供的软件测试方法。

如图7所示，该电子设备可以包括：处理器701，例如CPU，网络接口704，用户接口703，存储器705，通信总线702。其中，通信总线702用于实现这些组件之间的连接通信。用户接口703可以包括显示屏(Display)、输入单元比如键盘(Keyboard)，可选的，用户接口703还可以包括标准的有线接口、无线接口。网络接口704可选的可以包括标准的有线接口、无线接口(如WI-FI接口)。存储器705可以是高速RAM存储器，也可以是稳定的存储器(non-volatile memory)，例如磁盘存储器。存储器705可选的还可以是独立于前述处理器701的存储装置。值得一提的是，图7中示出的电子设备的结构并不构成对电子设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

如图7所示，作为一种计算机可读存储介质的存储器705中可以包括操作系统、网络通信模块、用户接口模块以及实现软件测试方法的程序。

在图7所示的电子设备中，网络接口704主要用于与其他设备进行通信连接，例如与图1中外部系统，或者与后置系统中的第一计算设备、与第二计算设备等。用户接口703主要用于连接客户端(用户端)，与客户端进行数据通信；而处理器701可以用于调用存储器705中存储的实现软件测试方法的程序，并执行如上任一方法实施例中的物品派送方法的步骤。

根据本申请实施例的一个方面，提供了一种计算机可读存储介质，其上存储有计算机可读指令，当计算机可读指令被处理器执行时，实现如上任一方法实施例中的软件测试方法。

需要说明的是，本申请实施例所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(Erasable Programmable Read Only Memory，EPROM)、闪存、光纤、便携式紧凑磁盘只读存储器(Compact Disc Read-Only Memory，CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。

根据本申请实施例的一个方面，提供了一种计算机程序产品，其包括计算机指令，计算机指令被处理器执行时实现如上任一方法实施例中的软件测试方法。

附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。其中，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

本领域技术人员在考虑说明书及实践这里公开的实施方式后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。

Claims (10)

1.一种软件测试方法，其特征在于，应用于前置系统，所述前置系统与后置系统通信连接，所述后置系统包括第一计算设备和第二计算设备，所述第二计算设备是指所述后置系统中除所述第一计算设备外部署了目标软件的其他计算设备；所述目标软件的待测试版本部署在所述第一计算设备上，所述第二计算设备上所部署目标软件的版本低于所述待测试版本；所述前置系统中存储了待测试版本的目标软件对应的配置文件，所述配置文件包括为待测试版本配置的交易属性验证条件和所述第一计算设备的目标网络地址，所述方法包括：

获取外部系统发送的交易请求；

从所述交易请求中获取交易属性；

将所述交易属性与所述配置文件中的交易属性验证条件进行匹配；

若所述交易请求中的交易属性与所述交易属性验证条件匹配，将所述交易请求转发到所述第一计算设备，所述第一计算设备中部署的待测试版本的目标软件对所述交易请求进行处理，并根据所述待测试版本的目标软件对所述交易请求的处理结果确定所述待测试版本的测试结果；

若所述交易请求中的交易属性与所述交易属性验证条件不匹配，将所述交易请求转发到所述第二计算设备，以通过所述第二计算设备中部署的目标软件对所述交易请求进行处理。

2.根据权利要求1所述的方法，其特征在于，所述将所述交易属性与所述配置文件中的交易属性验证条件进行匹配之前，所述方法还包括：

在所述前置系统中的服务启动后，获取内存中所述配置文件的修改时间；

若确定内存中所述配置文件的修改时间与缓存中配置文件的最后一次修改时间不同，则将内存中的配置文件加载到缓存中；

所述将所述交易属性与所述配置文件中的交易属性验证条件进行匹配，包括：

从加载的配置文件中读取交易属性验证条件；

将所述交易属性与所读取的交易属性验证条件进行匹配。

3.根据权利要求2所述的方法，其特征在于，所述在所述前置系统中的服务启动后，获取内存中所述配置文件的修改时间之后，所述方法还包括：

若确定内存中所述配置文件的修改时间与缓存中配置文件的最后一次修改时间相同，从缓存中的配置文件中读取交易属性验证条件；

所述将所述交易属性与所述配置文件中的交易属性验证条件进行匹配，包括：

将所述交易属性与从所述缓存中读取的交易属性验证条件进行匹配。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括：

确定所述配置文件中验证开关的状态；

若所述验证开关的状态为打开状态，执行所述从所述交易请求中获取交易属性的步骤。

5.根据权利要求4所述的方法，其特征在于，所述确定所述配置文件中验证开关的状态之后，所述方法还包括：

若所述验证开关的状态为关闭状态，将所述交易请求转发到所述第二计算设备。

6.根据权利要求1所述的方法，其特征在于，所述从所述交易请求中获取交易属性，包括：

从所述交易属性验证条件中获取验证字段的值，所述验证字段的值用于指示交易属性；

按照所述验证字段的值从所述交易请求中提取对应的交易属性。

7.根据权利要求1所述的方法，其特征在于，所述将所述交易请求转发到所述第一计算设备之后，所述方法还包括：

接收所述第一计算设备返回的处理结果；

将所述处理结果转发至所述外部系统。

8.一种软件测试装置，其特征在于，应用于前置系统，所述前置系统与后置系统通信连接，所述后置系统包括第一计算设备和第二计算设备，所述第二计算设备是指所述后置系统中除所述第一计算设备外部署了目标软件的其他计算设备；所述目标软件的待测试版本部署在所述第一计算设备上，所述第二计算设备上所部署目标软件的版本低于所述待测试版本；所述前置系统中存储了待测试版本的目标软件对应的配置文件，所述配置文件包括为待测试版本配置的交易属性验证条件和所述第一计算设备的目标网络地址，所述装置包括：

交易请求获取模块，用于获取外部系统发送的交易请求；

交易属性获取模块，用于从所述交易请求中获取交易属性；

匹配模块，用于将所述交易属性与所述配置文件中的交易属性验证条件进行匹配；

第一转发模块，用于若所述交易请求中的交易属性与所述交易属性验证条件匹配，将所述交易请求转发到所述第一计算设备，所述第一计算设备中部署的待测试版本的目标软件对所述交易请求进行处理，并根据所述待测试版本的目标软件对所述交易请求的处理结果确定所述待测试版本的测试结果；

第二转发模块，用于若所述交易请求中的交易属性与所述交易属性验证条件不匹配，将所述交易请求转发到所述第二计算设备，以通过所述第二计算设备中部署的目标软件对所述交易请求进行处理。

9.一种电子设备，其特征在于，包括：

处理器；

存储器，所述存储器上存储有计算机可读指令，所述计算机可读指令被所述处理器执行时，实现如权利要求1至7中任一项所述的方法。

10.一种计算机可读存储介质，其上存储有计算机可读指令，其特征在于，当所述计算机可读指令被处理器执行时，实现如权利要求1至7中任一项所述的方法。

Images