CN108197914A - 一种信息获取方法、装置及服务器 - Google Patents

Abstract

本发明实施例提供了一种信息获取方法、装置及服务器，所述信息获取方法，包括：接收客户端发送的目标交易的支付请求；模拟第三方支付平台生成目标交易的支付票据信息，作为第一支付票据信息；将第一支付票据信息发送至客户端；接收目标服务器发送的目标交易的支付票据信息，作为第二支付票据信息，其中，目标服务器为：为客户端提供服务的服务器；将第二支付票据信息与第一支付票据信息进行匹配，得到匹配结果；从预先存储的支付验证信息中，获得与匹配结果相匹配的支付验证信息；将所查找到的支付验证信息发送至所述目标服务器。通过本发明实施例提供的技术方案，便于开发人员对客户端中用于支持第三方支付流程的功能进行测试。

Description

一种信息获取方法、装置及服务器

技术领域

本发明涉及软件测试技术领域，特别是涉及一种信息获取方法、一种信息获取装置及一种服务器。

背景技术

随着智能手机和iPad等智能终端的普及，越来越多的用户使用智能终端。用户在使用智能终端的过程中，会使用各种各样的客户端，例如，淘宝，京东，当当网，有道词典、ofo共享单车等。

用户在使用上述客户端的过程中，经常会用到第三方支付，举例而言，用户在使用淘宝购物的过程中，可以通过储蓄卡、***、支付宝等第三方支付平台来付款，以购买到自身需要的商品。

为了确保用户在使用客户端的过程中，能够安全地通过第三方支付平台付款。在客户端发行之前，需要开发人员对客户端中用于支持第三方支付流程的功能进行测试。

现有技术中，对客户端中用于支持第三方支付流程的功能进行测试时，一般需要借助于第三方支付平台完成测试，在测试过程中，需要对第三方支付平台向客户端反馈的支付验证信息进行分析，从而确定出客户端中用于支付第三方支付流程的功能是否还存在问题，其中，上述支付验证信息可以理解为：第三方支付平台是否正常收到付款的确认信息。但是由于第三方支付平台的种类较多，且支付验证信息的表现形式是由各个第三方支付平台自身设定的，因此，当客户端中用于支持第三方支付流程的功能存在问题时，客户端获得支付验证信息的种类也较多，从而难以根据这些支付验证信息定位客户端中用于支持第三方支付流程的功能中存在的问题。

发明内容

本发明实施例的目的在于提供一种测试方法、装置及服务器，以便于开发人员对客户端中用于支持第三方支付流程的功能进行测试。具体技术方案如下：

第一方面，本发明实施例提供了一种信息获取方法，应用于服务器，所述方法包括：

接收客户端发送的目标交易的支付请求；

模拟第三方支付平台生成所述目标交易的支付票据信息，作为第一支付票据信息；

将所述第一支付票据信息发送至所述客户端；

接收目标服务器发送的所述目标交易的支付票据信息，作为第二支付票据信息，其中，所述目标服务器为：为所述客户端提供服务的服务器，所述目标服务器中的目标交易的支付票据信息是所述客户端向所述目标服务器发送的所述目标交易的支付票据信息；

将所述第二支付票据信息与所述第一支付票据信息进行匹配，得到匹配结果；

从预先存储的支付验证信息中，获得与所述匹配结果相匹配的支付验证信息；

将所查找到的支付验证信息发送至所述目标服务器。

可选的，所述将所查找到的支付验证信息发送至所述目标服务器，包括：

通过所述目标服务器的预设支付回调接口，将所查找到的支付验证信息发送至所述目标服务器。

可选的，所述接收目标服务器发送的所述目标交易的支付票据信息，包括：

接收目标服务器通过自身的预设支付回调接口发送的所述目标交易的支付票据信息。

可选的，所述支付请求为：通过执行测试脚本触发所述客户端生成订单信息后生成的、用于请求对所述目标交易进行支付的请求。

可选的，所述接收目标服务器发送的所述目标交易的支付票据信息，包括：

接收所述目标服务器验证所述目标交易的订单信息和对应的交易标识与所述目标服务器预先保存的所述已完成的订单信息和对应的交易标识不匹配后、发送的所述目标交易的支付票据信息。

第二方面，本发明实施例还提供了一种信息获得装置，应用于服务器，所述装置包括：

支付请求接收模块，用于接收客户端发送的目标交易的支付请求；

第一支付票据信息生成模块，用于模拟第三方支付平台生成所述目标交易的支付票据信息，作为第一支付票据信息；

第一支付票据信息发送模块，用于将所述第一支付票据信息发送至所述客户端；

第二支付票据信息接收模块，用于接收目标服务器发送的所述目标交易的支付票据信息，作为第二支付票据信息，其中，所述目标服务器为：为所述客户端提供服务的服务器，所述目标服务器中的目标交易的支付票据信息是所述客户端向所述目标服务器发送的所述目标交易的支付票据信息；

支付票据信息匹配模块，用于将所述第二支付票据信息与所述第一支付票据信息进行匹配，得到匹配结果；

支付验证信息获取模块，用于从预先存储的支付验证信息中，获得与所述匹配结果相匹配的支付验证信息；

支付验证信息发送模块，用于将所查找到的支付验证信息发送至所述目标服务器。

可选的，所述支付验证信息发送模块，具体用于：

通过所述目标服务器的预设支付回调接口，将所查找到的支付验证信息发送至所述目标服务器。

可选的，所述第二支付票据信息接收模块，具体用于：

接收所述目标服务器通过自身的预设支付回调接口发送的所述目标交易的支付票据信息。

可选的，所述支付请求为：通过执行测试脚本触发所述客户端生成订单信息后生成的、用于请求对所述目标交易进行支付的请求。

可选的，所述第二支付票据信息接收模块，具体用于：

接收所述目标服务器验证所述目标交易的订单信息和对应的交易标识与所述目标服务器预先保存的所述已完成的订单信息和对应的交易标识不匹配后、发送的所述目标交易的支付票据信息。

第三方面，本发明实施例提供了一种服务器，包括处理器、通信接口、存储器和通信总线，其中，处理器，通信接口，存储器通过通信总线完成相互间的通信；

存储器，用于存放计算机程序；

处理器，用于执行存储器上所存放的程序时，实现第一方面所述的任一信息获取方法。

第四方面，本发明实施例提供了一种计算机可读存储介质，所述计算机可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现第一方面所述的任一信息获取方法。

与现有技术相比，执行主体服务器接收客户端发送的目标交易的支付请求后，模拟第三方支付平台生成目标交易的支付票据信息，作为第一支付票据信息；并将第一支付票据信息发送至客户端；客户端接收到服务器发送的第一票据信息后，将第一票据信息存储为第二支付票据信息，并发送至目标服务器，目标服务器将第二支付票据信息发送至执行主体服务器；执行主体服务器接收到第二支付票据信息之后，将第二支付票据信息与第一支付票据信息进行匹配，得到匹配结果；然后从预先存储的支付验证信息中，获得与匹配结果相匹配的支付验证信息；将所查找到的支付验证信息发送至所述目标服务器。

可见，通过本发明实施例提供的技术方案，目标服务器接收到的支付验证信息是执行主体服务器预先存储的支付验证信息，因此，开发人员能够容易地根据支付验证信息判断出客户端中用于支付第三方支付流程的功能正常或存在的问题；而不像现有技术那样，开发人员在对客户端中用于支持第三方支付流程的功能进行测试时，目标服务器接收到的支付验证信息的种类较多，导致开发人员难以根据这些支付验证信息定位客户端中用于支持第三方支付流程的功能中存在的问题。因此，本发明实施例提供的技术方案，便于开发人员对客户端中用于支持第三方支付流程的功能进行测试。

附图说明

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

图1为本发明实施例所提供的一种信息获取方法的流程图；

图2为本发明实施例所提供的一种信息获取装置的结构示意图；

图3为本发明实施例所提供的一种服务器的结构示意图。

具体实施方式

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

为了解决现有技术问题，本发明实施例提供了一种信息获取方法、装置、服务器，以便于开发人员对客户端中用于支持第三方支付流程的功能进行测试。

需要说明的是，本发明实施例中，信息获取方法的执行主体为服务器，该服务器能够模拟第三方支付平台生成所述目标交易的支付票据信息。为了将该服务器与本发明实施例所提到的目标服务器区分开来，在下面的描述中，将该服务器称为：执行主体服务器。

第一方面，将对本发明实施例所提供的一种信息获取方法进行介绍。

如图1所示，本发明实施例所提供的一种信息获取方法，包括如下步骤：

S110，接收客户端发送的目标交易的支付请求；

S120，模拟第三方支付平台生成目标交易的支付票据信息，作为第一支付票据信息；

S130，将第一支付票据信息发送至客户端；

S140，接收目标服务器发送的目标交易的支付票据信息，作为第二支付票据信息，其中，目标服务器为：为客户端提供服务的服务器,目标服务器中的目标交易的支付票据信息是客户端向目标服务器发送的目标交易的支付票据信息；

S150，将第二支付票据信息与第一支付票据信息进行匹配，得到匹配结果；

S160，从预先存储的支付验证信息中，获得与匹配结果相匹配的支付验证信息；

S170，将所查找到的支付验证信息发送至所述目标服务器。

与现有技术相比，通过本发明实施例提供的技术方案，目标服务器接收到的支付验证信息是执行主体服务器预先存储的支付验证信息，因此，开发人员能够容易地根据支付验证信息判断出客户端中用于支付第三方支付流程的功能正常或存在的问题；而不像现有技术那样，开发人员在对客户端中用于支持第三方支付流程的功能进行测试时，目标服务器接收到的支付验证信息的种类较多，导致开发人员难以根据这些支付验证信息定位客户端中用于支持第三方支付流程的功能中存在的问题。因此，本发明实施例提供的技术方案，便于开发人员对客户端中用于支持第三方支付流程的功能进行测试。

下面将对图1所示实施例所提供的信息获取方法等进行详细描述。

S110，接收客户端发送的目标交易的支付请求；

开发人员对客户端中用于支持第三方支付流程的功能进行测试时，需要模拟真实的交易过程。因此，需要客户端向执行主体服务器发送目标交易的支付请求，在客户端向执行主体服务器发送支付请求后，执行主体服务器即接收到了客户端发送的支付请求。

在一种实施方式中，上述客户端向执行主体服务器发送的目标交易的支付请求可以携带订单信息和对应的交易标识，其中，订单信息可以包括商品信息、交易时间、交易金额等，目标交易对应的交易标识可以为订单编号、交易编号等等，目标交易的交易标识是在目标交易的订单信息生成时自动产生的。本发明实施例对订单信息和交易标识不做具体限定。

可以理解的是，客户端在生成订单信息之后才向执行主体服务器发送支付请求。客户端生成订单信息的方式有多种。具体的：

第一种方式可以为：人工手动触发的方式。可选的，用户手动打开客户端，选择商品，客户端即生成了订单信息。

第二种方式为：通过执行测试脚本触发的方式。可选的，通过执行测试脚本来触发客户端自动选择商品，客户端即生成了订单信息。其中，可以在目标服务器中执行测试脚本，只要在目标服务器中执行测试脚本，一台客户端或者就可以自动生成订单信息。

很显然，第二种生成订单信息的方式与第一种生成订单信息的方式相比，第二种生成订单信息的方式能够降低人工成本，并节省时间。

在客户端生成订单信息之后，选择第三方支付，此时，客户端向目标服务器发送请求，目标服务器接收到该请求之后，向客户端发送支付地址信息，该支付地址信息所指的地址为执行主体服务器的地址；客户端接收到该虚拟支付地址信息后，将订单信息发送至执行主体服务器，即客户端向执行主体服务器发送支付请求，此时，执行主体服务器接收到了客户端发送的目标交易的支付请求。

当然，在本发明实施例中，还可以通过其他方式来生成订单信息，本发明实施例对生成订单信息的方式并不做具体限定。

S120，模拟第三方支付平台生成目标交易的支付票据信息，作为第一支付票据信息；

其中，支付票据信息为：证明用户已经对订单进行支付的收据信息，支付票据信息可以包括订单信息、对应的交易标识和第三方支付平台加密验证码等信息。

为了能够准确地对客户端中用于支持第三方支付流程的功能进行测试，服务器接收到客户端发送的目标交易的支付请求后，模拟第三方支付平台生成目标交易的支付票据信息。

S130，将第一支付票据信息发送至客户端；

执行主体服务器在生成第一支付票据信息后，模拟真实的交易场景，服务器将生成的第一支付票据信息发送给客户端。

S140，接收目标服务器发送的目标交易的支付票据信息，作为第二支付票据信息,其中，目标服务器为：为客户端提供服务的服务器，目标服务器中的目标交易的支付票据信息是客户端向目标服务器发送的目标交易的支付票据信息；

客户端接收到第一支付票据信息后，可以将第一支付票据信息存储为第二支付票据信息，客户端将第二支付票据信息发送至目标服务器，目标服务端在接收到第二支付票据信息后，将第二支付票据信息发送至执行主体服务器。

由于执行主体服务器在将第一支付票据信息发送给客户端以及客户端将其存储为第二支付票据信息并发送至目标服务器的过程中，可能因网络传输错误、网络攻击等原因而导致第一支付票据信息、第二支付票据信息被篡改。若第一支付票据信息与第二支付票据信息中的任一支付票据信息被篡改，第二支付票据信息与第一支付票据信息不完全一致；若第一支付票据信息与第二支付票据信息均没有被篡改，第二支付票据信息与第一支付票据信息完全一致。

在一种实施方式中，目标服务器在将第二支付票据信息发送至执行主体服务器时，可以调用其自身的预设支付回调接口，将第二支付票据信息发送至执行主体服务器，也就是说，执行主体服务器接收到的第二支付票据信息可以是：目标服务器通过其自身的预设支付回调接口向执行主体服务器发送的目标交易的支付票据信息。

在一种实施方式中，由于目标服务器会保存所有已完成的订单信息和对应的交易标识，因此，目标服务器在向执行主体服务器发送第二支付票据信息之前，可以先验证客户端向其发送的目标交易的订单信息和对应的交易标识与其自身保存的已完成的订单信息和对应的交易标识是否匹配，若客户端向其发送的目标交易的订单信息和对应的交易标识与目标服务器保存的已完成的订单信息和对应的交易标识匹配，因其订单已经交易完成，无需再次请求，因此，目标服务器自身就可以验证出客户端中用于支持第三方支付流程的功能存在异常；若客户端向其发送的目标交易的订单信息和对应的交易标识与目标服务器保存的已完成的订单信息和对应的交易标识不匹配，再将第二支付票据信息发送至执行主体服务器，以使得执行主体服务器在接下来的步骤中，进一步判断第二支付票据信息与第一支付票据信息是否匹配，以对客户端中用于支持第三方支付流程的功能进行测试。

S150，将第二支付票据信息与第一支付票据信息进行匹配，得到匹配结果；

执行主体服务器接收到第二支付票据信息，为了能够测试出客户端中用于支付第三方支付流程的功能是否存在问题，需要将第二支付票据信息与第一支付票据信息进行匹配，得到匹配结果，可选的，在验证票据信息时，只需验证第一支付验证信息与第二支付验证信息中的第三支付平台加密验证码是否相同，得到匹配结果。

举例而言，当第二支付票据信息与第一支付票据信息完全一致时，则得到的匹配结果可以为“匹配成功”、“完全一致”等，这种情况下，客户端中用于支付第三方支付流程的功能正常；

当第二支付票据信息与第一支付票据信息不完全一致时，则得到的匹配结果可以为“匹配不成功”、“不完全一致”、“支付响应超时”、“支付票据信息无法验证”等，这种情况下，客户端客户端中用于支付第三方支付流程的功能异常。

S160，从预先存储的支付验证信息中，获得与匹配结果相匹配的支付验证信息；

在得到第一支付票据信息与第二支付票据信息的匹配结果之后，在预先存储的支付验证信息中，查找与匹配结果相匹配的支付验证信息。

举例而言，当第一支付票据信息与第二支付票据信息的匹配结果为“匹配成功”、“完全一致”等时，执行主体服务器查找到的与匹配结果相匹配的支付验证信息可以为“验证成功”。

当第一支付票据信息与第二支付票据信息的匹配结果为“响应超时”时，执行主体服务器查找到的支付验证信息可以为“响应超时”。

可以理解的是，在对客户端中用于支持第三方支付流程的功能进行测试时，为了保证测试的准确性，需要进行大量反复的测试，也就是说，在对客户端中用于支持第三方支付流程的功能进行测试的过程中，会涉及到多个交易，通常情况下，不同的交易具有不同的交易标识。

在一种实现方式中，预先设置的支付验证信息不仅与匹配结果具有对应关系，还与交易标识具有对应关系。也就是说，对于不同的交易，由于交易标识不同，在第一支付票据信息与第二支付票据信息的匹配结果相同时，执行主体服务器预先设置的支付验证信息可能相同，也可能不同。其中，支付验证信息可以包括：代码和代码所表示的含义。

举例而言，在对客户端中用于支持第三方支付流程的功能进行测试的过程中，有两个交易，分别为交易A和交易B，其中，交易A的交易标识为：001；交易B的交易标识为：002。当目标交易为交易A时，将第一支付票据信息与第二支付票据信息进行匹配后，得到的匹配结果为“匹配成功”；此时执行主体服务器查找到的与匹配结果相匹配的支付验证信息为：“代码为200，该代码表示的含义为验证成功”；当目标交易为交易B时，将第一支付票据信息与第二支付票据信息进行匹配后，得到的匹配结果也为“匹配成功”；此时执行主体服务器查找到的与匹配结果相匹配的支付验证信息也为“代码为200，该代码表示的含义为验证成功”。

再例如，对客户端中用于支持第三方支付流程的功能进行测试的过程中，有两个交易，分别为交易A和交易B，其中，交易A的交易标识为：001；交易B的交易标识为：002。当目标交易为交易A时，将第一支付票据信息与第二支付票据信息进行匹配后，得到的匹配结果为“匹配成功”；此时执行主体服务器查找到的与匹配结果相匹配的支付验证信息为“代码为200，该代码表示的含义为验证成功”，其中，支付验证信息1表示“验证成功”；当目标交易为交易B时，将第一支付票据信息与第二支付票据信息进行匹配后，得到的匹配结果也为“匹配成功”；此时执行主体服务器查找到的与匹配结果相匹配的支付验证信息为“代码为300，该代码表示的含义也为验证成功”。

S170，将所查找到的支付验证信息发送至所述目标服务器。

执行主体服务器查找到支付验证信息后，将查找到的支付验证信息发送至目标服务器，由于目标服务器接收到的支付验证信息是执行主体服务器预先存储的支付验证信息，因此，开发人员能够容易地根据支付验证信息判断出客户端中用于支付第三方支付流程的功能正常或存在的问题。在客户端中用于支持第三方支付流程的功能存在问题时，针对所存在的问题，对客户端进行调试。

在一种实施方式中，执行主体服务器可以通过目标服务器的预设支付回调接口，将所查找到的支付验证信息发送至目标服务器。

与现有技术相比，执行主体服务器接收客户端发送的目标交易的支付请求后，模拟第三方支付平台生成目标交易的支付票据信息，作为第一支付票据信息；并将第一支付票据信息发送至客户端；客户端接收到执行主体服务器发送的第一票据信息后，将第一支付票据信息存储为第二支付票据信息，目标服务器验证成功后，将第二支付票据信息发送至执行主体服务器；执行主体服务器接收到第二支付票据信息之后，将第二支付票据信息与第一支付票据信息进行匹配，得到匹配结果；然后从预先存储的支付验证信息中，获得与匹配结果相匹配的支付验证信息；将所查找到的支付验证信息发送至所述目标服务器。

可见，通过本发明实施例提供的技术方案，目标服务器接收到的支付验证信息是执行主体服务器预先存储的支付验证信息，因此，开发人员能够容易地根据支付验证信息判断出客户端中用于支付第三方支付流程的功能正常或存在的问题；而不像现有技术那样，开发人员在对客户端中用于支持第三方支付流程的功能进行测试时，目标服务器接收到的支付验证信息的种类较多，导致开发人员难以根据这些支付验证信息定位客户端中用于支持第三方支付流程的功能中存在的问题。因此，本发明实施例提供的技术方案，便于开发人员对客户端中用于支持第三方支付流程的功能进行测试。

为了更加清楚地描述本发明实施例的技术方案，下面结合具体的实施例，对本发明实施例所提供的一种信息获取方法进行介绍。

实施例一：客户端中用于支付第三方支付流程的功能正常。在该实施例中，以第三方支付为苹果支付为例。测试过程主要分为以下几个步骤：

一、客户端生成订单信息；

二、在客户端生成订单信息之后，用户选择苹果支付，此时，客户端向目标服务器发送请求，目标服务器接收到该请求后，向客户端返回支付地址信息，该支付地址信息所指的地址为执行主体支付服务器，客户端将订单信息和对应的交易标识发送到执行主体支付服务器，即客户端向执行主体服务器发送支付请求；

三、执行主体服务器接收到支付请求后，模拟苹果支付平台，自行拼接生成支付票据信息，作为第一支付票据信息；

四、执行主体服务器将第一支付票据信息发送至客户端；

五、客户端接收到执行主体服务器发送的第一支付票据信息后，将其第一支付票据信息存储为第二支付票据信息，并将第二支付票据信息发送至目标服务器，其中，目标服务器为：为客户端提供服务的服务器；

六、目标服务器将第二支付票据信息发送至执行主体服务器；

七、执行主体服务器接收到第二支付票据信息后，将第一支付票据信息与第二支付票据信息进行匹配，得到匹配结果为“匹配成功”；

八、执行主体服务器将预先设置的支付验证成功的信息，通过目标服务器预设的支付回调接口发送给目标服务器；

九、目标服务器接收到支付验证成功的信息后，开发人员即可判断出客户端中用于支付第三方支付流程的功能正常。

实施例二：客户端中用于支付第三方支付流程的功能异常。在该实施例中，仍以第三方支付为苹果支付为例。测试过程主要分为以下几个步骤：

一、客户端生成订单信息；

二、在客户端生成订单信息之后，用户选择苹果支付，此时，客户端向目标服务器发送请求，目标服务器接收到该请求后，向客户端返回支付地址信息，该支付地址信息所指的地址为执行主体支付服务器，客户端将订单信息和对应的交易标识发送到执行主体支付服务器，即客户端向执行主体服务器发送支付请求；

三、执行主体服务器接收到支付请求后，模拟苹果支付平台，自行拼接生成支付票据信息，作为第一支付票据信息；

四、执行主体服务器通过客户端预设的支付回调接口，将第一支付票据信息发送至客户端；

五、客户端接收到执行主体服务器发送的支付票据信息后，将其第一支付票据信息存储为第二支付票据信息，并将第二支付票据信息发送至目标服务器，其中，目标服务器为：为客户端提供服务的服务器；

六、目标服务器将第二支付票据信息发送至执行主体服务器；

七、执行主体服务器接收到第二支付票据信息后，将第一支付票据信息与第二支付票据信息进行匹配，得到匹配结果为“匹配不成功”。

八、执行主体服务器将预先设置的支付验证异常的信息，通过目标服务器预设的支付回调接口发送给目标服务器。

由于导致客户端中用于支付第三方支付流程的功能异常的原因可能有多种，因此，得到的支付验证异常的信息也可能有多种。其中，支付验证异常的信息可以包括：错误代码和错误代码所表示的含义，举例而言，支付验证异常的信息可以为如下支付验证信息：

1、错误代码为：21000，该错误代码所表示的含义为：苹果商店无法读取客户端提供的JSON对象；

2、错误代码为：21002，该错误代码所表示的含义为：目标服务器向执行主体服务器发送的支付票据信息所包含的数据格式错误或丢失；

3、错误代码为：21003，该错误代码所表示的含义为：目标服务器向执行主体服务器发送的支付票据信息无法验证；

4、错误代码为：21004，该错误代码所表示的含义为：目标服务器向执行主体服务器发送的支付票据信息的密码被篡改；

5、错误代码为：21005，该错误代码所表示的含义为：执行主体服务器当前不能验证目标服务器向其发送的支付票据信息是否正常；

6、错误代码为：21006，该错误代码所表示的含义为：目标服务器向执行主体服务器发送的支付票据信息是有效的支付票据信息，但是，该支付票据信息所订阅的内容已过期；

7、错误代码为：21007，该错误代码所表示的含义为：目标服务器向执行主体服务器发送的支付票据信息来自于测试环境，执行主体服务器将该支付票据信息发送至生产环境，以进一步验证该支付票据信息；

8、错误代码为：21006，该错误代码所表示的含义为：目标服务器向执行主体服务器发送的支付票据信息来自于生产环境，执行主体服务器将该支付票据信息发送至测试环境，以进一步验证该支付票据信息；

9、错误代码为：21010，该错误代码所表示的含义为：目标客户端向执行主体服务器发送的支付票据信息是无效的支付票据信息；

10、错误代码为：21100-21199，这些错误代码所表示的含义均为：目标服务器向执行主体服务器发送的支付票据信息内部数据错误；

11、错误代码为：21200，该错误代码所表示的含义均为：执行主体服务器响应超时。举例而言，假设执行主体服务器预设响应时长为200秒，但是，在实际应用中，执行主体服务器将第一支付票据信息与第二支付票据信息进行匹配所消耗的时长为210秒(大于200秒)，因此，执行主体服务器为目标服务器返回的支付验证异常的信息为“执行主体服务器响应超时”。

九、目标服务器接收到支付验证异常的信息后，开发人员即可判断出客户端中用于支付第三方支付流程的功能异常，并根据所接收到的支付验证异常的信息，判断出客户端中用于支付第三方支付流程的功能所存在的问题。

第二方面、本发明实施例还提供了一种信息获得装置，应用于服务器，如图2所示，所述装置包括：

支付请求接收模块210，用于接收客服端发送的目标交易的支付请求；

第一支付票据信息生成模块220，用于模拟第三方支付平台生成所述目标交易的支付票据信息，作为第一支付票据信息；

第一支付票据信息发送模块230，用于将所述第一支付票据信息发送至所述客户端；

第二支付票据信息接收模块240，用于接收所述目标服务器发送的所述目标交易的第二支付票据信息；

支付票据信息匹配模块250，用于将所述第二支付票据信息与所述第一支付票据信息进行匹配，得到匹配结果；

支付验证信息获取模块260，用于从预先存储的支付验证信息中，获得与所述匹配结果相匹配的支付验证信息；

支付验证信息发送模块270，用于将所查找到的支付验证信息发送至所述客户端。

可选的，所述支付验证信息发送模块270，具体用于：

通过所述目标服务器的预设支付回调接口，将所查找到的支付验证信息发送至所述目标服务器。

可选的，所述第二支付票据信息接收模块240，具体用于：

接收所述目标服务器通过自身的预设支付回调接口发送的所述目标交易的支付票据信息。

可选的，所述支付请求为：通过执行测试脚本触发所述客户端生成订单信息后生成的、用于请求对所述目标交易进行支付的请求。

可选的，所述第二支付票据信息接收模块240，具体用于：

接收所述目标服务器验证所述目标交易的订单信息和对应的交易标识与所述目标服务器预先保存的所述已完成的订单信息和对应的交易标识不匹配后、发送的所述目标交易的支付票据信息。

与现有技术相比，执行主体服务器接收客户端发送的目标交易的支付请求后，模拟第三方支付平台生成目标交易的支付票据信息，作为第一支付票据信息；并将第一支付票据信息发送至客户端；客户端接收到执行主体服务器发送的第一票据信息后，将第一支付票据信息存储为第二支付票据信息，目标服务器验证成功后，将第二支付票据信息发送至执行主体服务器；执行主体服务器接收到第二支付票据信息之后，将第二支付票据信息与第一支付票据信息进行匹配，得到匹配结果；然后从预先存储的支付验证信息中，获得与匹配结果相匹配的支付验证信息；将所查找到的支付验证信息发送至所述目标服务器。

可见，通过本发明实施例提供的技术方案，目标服务器接收到的支付验证信息是执行主体服务器预先存储的支付验证信息，因此，开发人员能够容易地根据支付验证信息判断出客户端中用于支付第三方支付流程的功能正常或存在的问题；而不像现有技术那样，开发人员在对客户端中用于支持第三方支付流程的功能进行测试时，目标服务器接收到的支付验证信息的种类较多，导致开发人员难以根据这些支付验证信息定位客户端中用于支持第三方支付流程的功能中存在的问题。因此，本发明实施例提供的技术方案，便于开发人员对客户端中用于支持第三方支付流程的功能进行测试。

第三方面，本发明实施例还提供了一种服务器，如图3所示，包括处理器301、通信接口302、存储器303和通信总线304，其中，处理器301，通信接口302，存储器303通过通信总线304完成相互间的通信，

存储器303，用于存放计算机程序；

处理器301，用于执行存储器303上所存放的程序时，实现第一方面所述的任一信息获取方法。

上述服务器提到的通信总线可以是外设部件互连标准(Peripheral ComponentInterconnect，PCI)总线或扩展工业标准结构(Extended Industry StandardArchitecture，EISA)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

通信接口用于上述服务器与其他设备之间的通信。

存储器可以包括随机存取存储器(Random Access Memory，RAM)，也可以包括非易失性存储器(Non-Volatile Memory，NVM)，例如至少一个磁盘存储器。可选的，存储器还可以是至少一个位于远离前述处理器的存储装置。

上述的处理器可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(Digital SignalProcessing，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

与现有技术相比，执行主体服务器接收客户端发送的目标交易的支付请求后，模拟第三方支付平台生成目标交易的支付票据信息，作为第一支付票据信息；并将第一支付票据信息发送至客户端；客户端接收到执行主体服务器发送的第一票据信息后，将第一票据信息存储为第二支付票据信息，并发送至目标服务器，目标服务器将第二支付票据信息发送至执行主体服务器；执行主体服务器接收到第二支付票据信息之后，将第二支付票据信息与第一支付票据信息进行匹配，得到匹配结果；然后从预先存储的支付验证信息中，获得与匹配结果相匹配的支付验证信息；将所查找到的支付验证信息发送至所述目标服务器。

可见，通过本发明实施例提供的技术方案，目标服务器接收到的支付验证信息是执行主体服务器预先存储的支付验证信息，因此，开发人员能够容易地根据支付验证信息判断出客户端中用于支付第三方支付流程的功能正常或存在的问题；而不像现有技术那样，开发人员在对客户端中用于支持第三方支付流程的功能进行测试时，目标服务器接收到的支付验证信息的种类较多，导致开发人员难以根据这些支付验证信息定位客户端中用于支持第三方支付流程的功能中存在的问题。因此，本发明实施例提供的技术方案，便于开发人员对客户端中用于支持第三方支付流程的功能进行测试。

第四方面，本发明实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现第一方面所述的任一信息获取方法。

与现有技术相比，执行主体服务器接收客户端发送的目标交易的支付请求后，模拟第三方支付平台生成目标交易的支付票据信息，作为第一支付票据信息；并将第一支付票据信息发送至客户端；客户端接收到服务器发送的第一票据信息后，将第一票据信息存储为第二支付票据信息，并发送至目标服务器，目标服务器将第二支付票据信息发送至执行主体服务器；执行主体服务器接收到第二支付票据信息之后，将第二支付票据信息与第一支付票据信息进行匹配，得到匹配结果；然后从预先存储的支付验证信息中，获得与匹配结果相匹配的支付验证信息；将所查找到的支付验证信息发送至所述目标服务器。

可见，通过本发明实施例提供的技术方案，目标服务器接收到的支付验证信息是执行主体服务器预先存储的支付验证信息，因此，开发人员能够容易地根据支付验证信息判断出客户端中用于支付第三方支付流程的功能正常或存在的问题；而不像现有技术那样，开发人员在对客户端中用于支持第三方支付流程的功能进行测试时，目标服务器接收到的支付验证信息的种类较多，导致开发人员难以根据这些支付验证信息定位客户端中用于支持第三方支付流程的功能中存在的问题。因此，本发明实施例提供的技术方案，便于开发人员对客户端中用于支持第三方支付流程的功能进行测试。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本说明书中的各个实施例均采用相关的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置、服务器实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等，均包含在本发明的保护范围内。

Claims (10)

1.一种信息获取方法，应用于服务器，其特征在于，所述方法包括：

接收客户端发送的目标交易的支付请求；

模拟第三方支付平台生成所述目标交易的支付票据信息，作为第一支付票据信息；

将所述第一支付票据信息发送至所述客户端；

接收目标服务器发送的所述目标交易的支付票据信息，作为第二支付票据信息，其中，所述目标服务器为：为所述客户端提供服务的服务器，所述目标服务器中的目标交易的支付票据信息是所述客户端向所述目标服务器发送的所述目标交易的支付票据信息；

将所述第二支付票据信息与所述第一支付票据信息进行匹配，得到匹配结果；

从预先存储的支付验证信息中，获得与所述匹配结果相匹配的支付验证信息；

将所查找到的支付验证信息发送至所述目标服务器。

2.根据权利要求1所述的方法，其特征在于，所述将所查找到的支付验证信息发送至所述目标服务器，包括：

通过所述目标服务器的预设支付回调接口，将所查找到的支付验证信息发送至所述目标服务器。

3.根据权利要求1所述的方法，其特征在于，所述接收目标服务器发送的所述目标交易的支付票据信息，包括：

接收目标服务器通过自身的预设支付回调接口发送的所述目标交易的支付票据信息。

4.根据权利要求1至3任一项所述的方法，其特征在于，所述支付请求为：通过执行测试脚本触发所述客户端生成订单信息后生成的、用于请求对所述目标交易进行支付的请求。

5.根据权利要求1-3中任一项所述的方法，其特征在于，所述接收目标服务器发送的所述目标交易的支付票据信息，包括：

接收所述目标服务器验证所述目标交易的订单信息和对应的交易标识与所述目标服务器预先保存的所述已完成的订单信息和对应的交易标识不匹配后、发送的所述目标交易的支付票据信息。

6.一种信息获得装置，应用于服务器，其特征在于，所述装置包括：

支付请求接收模块，用于接收客户端发送的目标交易的支付请求；

第一支付票据信息生成模块，用于模拟第三方支付平台生成所述目标交易的支付票据信息，作为第一支付票据信息；

第一支付票据信息发送模块，用于将所述第一支付票据信息发送至所述客户端；

第二支付票据信息接收模块，用于接收目标服务器发送的所述目标交易的支付票据信息，作为第二支付票据信息，其中，所述目标服务器为：为所述客户端提供服务的服务器，所述目标服务器中的目标交易的支付票据信息是所述客户端向所述目标服务器发送的所述目标交易的支付票据信息；

支付票据信息匹配模块，用于将所述第二支付票据信息与所述第一支付票据信息进行匹配，得到匹配结果；

支付验证信息获取模块，用于从预先存储的支付验证信息中，获得与所述匹配结果相匹配的支付验证信息；

支付验证信息发送模块，用于将所查找到的支付验证信息发送至所述目标服务器。

7.根据权利要求6所述的装置，其特征在于，所述支付验证信息发送模块，具体用于：

通过所述目标服务器的预设支付回调接口，将所查找到的支付验证信息发送至所述目标服务器。

8.根据权利要求6所述的装置，其特征在于，所述第二支付票据信息接收模块，具体用于：

接收所述目标服务器通过自身的预设支付回调接口发送的所述目标交易的支付票据信息。

9.根据权利要求6至8任一项所述的装置，其特征在于，所述支付请求为：通过执行测试脚本触发所述客户端生成订单信息后生成的、用于请求对所述目标交易进行支付的请求。

10.根据权利要求6至8中任一项所述的装置，其特征在于，所述第二支付票据信息接收模块，具体用于：

接收所述目标服务器验证所述目标交易的订单信息和对应的交易标识与所述目标服务器预先保存的所述已完成的订单信息和对应的交易标识不匹配后、发送的所述目标交易的支付票据信息。