一种多服务测试方法和装置

技术领域

本发明涉及计算机技术领域，尤其涉及一种多服务测试方法和装置。

背景技术

对于具有上下游关系的服务来说，测试上游服务需要用到下游服务返回的结果，测试下游服务需要用上游服务发过来的请求。目前，对于通过远程过程调用框架进行交互的服务，获取上游服务发送给下游服务的请求的方式就是将请求打印到日志中，然后去日志中查找请求数据。

在实现本发明过程中，发明人发现现有技术中至少存在如下问题：

上下游服务间的功能测试耦合性较强；测试场景覆盖不全；下游服务无法单独进行功能测试。

发明内容

有鉴于此，本发明实施例提供一种多服务测试方法和装置，以解决上下游服务间的功能测试耦合性较强的技术问题。

为实现上述目的，根据本发明实施例的一个方面，提供了一种多服务测试方法，包括：

配置上游服务的请求；

将所述上游服务的请求发送至所述上游服务，以使所述上游服务构造下游服务的请求数据，将所述下游服务的请求数据发送至所述下游服务的桩服务，并使所述下游服务的桩服务将所述下游服务的请求数据写入缓存；

从所述缓存中获取所述下游服务的请求数据。

可选地，配置上游服务的请求之后，还包括：

生成所述上游服务的请求的唯一标识，以及，配置所述上游服务的业务类型。

可选地，所述缓存中的主键包括所述上游服务的请求的唯一标识和所述下游服务的服务名，所述缓存中的值为所述下游服务的请求数据。

可选地，还包括：

配置所述下游服务的服务名、请求、IP和端口号；

根据所述IP和所述端口号，将所述下游服务的请求发送至所述下游服务；

接收所述下游服务返回的结果。

可选地，配置所述下游服务的请求，包括：

将从所述缓存中获取的所述下游服务的请求数据配置为所述下游服务的请求。

可选地，还包括：

将返回结果写入配置文件中；

通过所述下游服务的桩服务加载所述配置文件，以使所述下游服务的桩服务将所述返回结果返回至所述上游服务。

可选地，所述返回结果为预置的返回结果，或者，所述下游服务返回的结果。

另外，根据本发明实施例的另一个方面，提供了一种多服务测试装置，包括：

配置模块，用于配置上游服务的请求；

发送模块，用于将所述上游服务的请求发送至所述上游服务，以使所述上游服务构造下游服务的请求数据，将所述下游服务的请求数据发送至所述下游服务的桩服务，并使所述下游服务的桩服务将所述下游服务的请求数据写入缓存；

获取模块，用于从所述缓存中获取所述下游服务的请求数据。

可选地，所述配置模块还用于：

配置上游服务的请求之后，生成所述上游服务的请求的唯一标识，以及，配置所述上游服务的业务类型。

可选地，所述缓存中的主键包括所述上游服务的请求的唯一标识和所述下游服务的服务名，所述缓存中的值为所述下游服务的请求数据。

可选地，所述配置模块还用于：

配置所述下游服务的服务名、请求、IP和端口号；

根据所述IP和所述端口号，将所述下游服务的请求发送至所述下游服务；

接收所述下游服务返回的结果。

可选地，所述配置模块还用于：

将从所述缓存中获取的所述下游服务的请求数据配置为所述下游服务的请求。

可选地，所述配置模块还用于：

将返回结果写入配置文件中；

通过所述下游服务的桩服务加载所述配置文件，以使所述下游服务的桩服务将所述返回结果返回至所述上游服务。

可选地，所述返回结果为预置的返回结果，或者，所述下游服务返回的结果。

根据本发明实施例的另一个方面，还提供了一种电子设备，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行时，所述一个或多个处理器实现上述任一实施例所述的方法。

根据本发明实施例的另一个方面，还提供了一种计算机可读介质，其上存储有计算机程序，所述程序被处理器执行时实现上述任一实施例所述的方法。

上述发明中的一个实施例具有如下优点或有益效果：因为采用配置上游服务的请求，将上游服务的请求发送至上游服务，以使上游服务构造下游服务的请求数据以及将下游服务的请求数据发送至下游服务的桩服务，并使下游服务的桩服务将下游服务的请求数据写入缓存的技术手段，所以克服了现有技术中上下游服务间的功能测试耦合性较强的技术问题。对于涉及多个服务改动的项目，本发明实施例将下游服务用桩的方式进行测试，这样解除了上下游服务之间的强耦合性，实现了服务测试的解耦；当一个项目涉及到需要升级多个相互依赖的服务时，可以单独对升级完成的服务进行测试，无需再等待所依赖的服务开发完成，提高了测试效率及迭代效率；而且可以直接从缓存中获取上游服务发往各种下游服务的请求数据，不再需要去日志中查找。

上述的非惯用的可选方式所具有的进一步效果将在下文中结合具体实施方式加以说明。

附图说明

附图用于更好地理解本发明，不构成对本发明的不当限定。其中：

图1是根据本发明实施例的多服务测试方法的主要流程的示意图；

图2是根据本发明实施例的远程过程调用框架的示意图；

图3是根据本发明实施例改造后的远程过程调用框架的示意图；

图4是根据本发明实施例的在web页面配置上游服务的请求的示意图；

图5是根据本发明实施例的将缓存读取结果展示在web页面上的示意图；

图6是根据本发明一个可参考实施例的多服务测试方法的主要流程的示意图；

图7是根据本发明实施例的在web页面配置下游服务的请求的示意图；

图8是根据本发明另一个可参考实施例的多服务测试方法的主要流程的示意图；

图9是根据本发明实施例的桩服务加载配置文件的示意图；

图10是根据本发明实施例的多服务测试装置的主要模块的示意图；

图11是本发明实施例可以应用于其中的示例性系统架构图；

图12是适于用来实现本发明实施例的终端设备或服务器的计算机系统的结构示意图。

具体实施方式

以下结合附图对本发明的示范性实施例做出说明，其中包括本发明实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本发明的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

目前，对于通过远程过程调用框架(比如RPC框架或者BRPC框架等)进行交互的服务，获取上游服务发送给下游服务的请求的方式就是将请求打印到日志中，然后去日志中查找请求数据。因此，现有技术存在如何技术问题：

1)上下游服务间的功能测试耦合性较强，对于涉及到上下游服务都有升级的项目时，各个服务的功能测试都会依赖彼此，如果两个服务不是同时开发完成，则会阻塞另一个服务的测试。

2)对于上游服务需要下游返回各种场景的结果以及对于下游服务需要上游发出各种场景的请求，无法全面测试，导致测试场景覆盖不全。

3)由于需要通过打印日志的方式获取上游发送给下游的请求，并且获得请求后无法单独将请求发送给下游服务，因此获取上游发送给下游的请求比较困难，导致下游服务无法单独进行功能测试。

为了解决现有技术中存在的技术问题，本发明实施例提供了一种多服务测试方法，该方法对上下游服务间的功能测试进行解耦，能够覆盖更全面的测试场景，还能够实现下游服务的独立测试。

图1是根据本发明实施例的多服务测试方法的主要流程的示意图。作为本发明的一个实施例，如图1所示，所述多服务测试方法可以包括：

步骤101，配置上游服务的请求。

如果要对远程过程调用框架(比如RPC框架或者BRPC框架等)的上游服务进行测试，则需要对所述上游服务的请求进行配置。如图2所示，所述远程过程调用框架可以包含多个服务，例如A服务、B服务、C服务等，其中A服务为上游服务，B服务和C服务均为下游服务。

在本发明的实施例中，可以在脚本中配置上游服务的请求，也可以在web客户端的页面上配置上游服务的请求。如图3所示，为了方便测试人员配置请求，可以在web页面上配置上游服务的请求，比如可以在web页面的请求输入框中输入HTTP请求。

可选地，在步骤101之后，还包括：生成所述上游服务的请求的唯一标识，以及，配置所述上游服务的业务类型。如图3所示，当测试人员在web客户端的页面上配置完请求后，web服务端会自动地为该请求生成唯一标识(sid)，并将该请求的唯一标识发送至web客户端，从而在web页面上展示。进一步地，测试人员还可以在页面上配置请求的业务类型，由于上游服务具有不同的业务类型，而且不同业务类型访问的下游服务也是不一样的，因此需要对请求的业务类型进行配置。例如，以广告业务为例，业务类型可以包括首页焦点、推荐、搜索、站外等。

步骤102，将所述上游服务的请求发送至所述上游服务，以使所述上游服务构造下游服务的请求数据，将所述下游服务的请求数据发送至所述下游服务的桩服务，并使所述下游服务的桩服务将所述下游服务的请求数据写入缓存。

在步骤102之前，需要分别对各个下游服务进行改造，生成各个下游服务对应的桩服务，使得下游服务的桩服务接收到上游服务发送过来的请求数据后，将请求数据写入缓存且不走其他业务逻辑。改造后的远程过程调用框架的示意图如图3所示，比如当A服务请求B服务的桩服务时，B服务的桩服务收到请求数据后，将请求数据写入缓存中保留下来，然后B服务的桩服务本次处理就结束，A服务继续请求其他下游服务的桩服务。在本发明的实施例中，下游服务的桩服务定义了下游服务的入参和出参，但是桩服务中没有业务逻辑，因此桩服务不对上游服务发送过来的请求数据进行逻辑处理。

如图4所示，web页面上还提供了请求发送按钮，当测试人员完成配置后，点击该按钮后，web服务端接收发送指令，然后将配置好的请求发送给A服务。A服务会根据自己的业务逻辑构造各种下游服务(B、C……)的请求数据，访问下游服务的桩服务(stub)，当下游服务的桩服务接收到A服务发送过来的请求数据后，会将接收到的请求数据直接写入缓存中。

在本发明的实施例中，所述缓存中的主键(key)包括所述上游服务的请求的唯一标识(sid)和所述下游服务的服务名，所述缓存中的值(value)为所述下游服务的请求数据。

步骤103，从所述缓存中获取所述下游服务的请求数据。

下游服务的桩服务将下游服务的请求数据写入缓存后(接近于实时存储)，web服务端会去读取缓存，这样就可以得到上游服务发往各种下游服务的请求数据。测试人员不再需要去日志中查找上游服务发往各种下游服务的请求数据，也可以对上游服务进行单独测试。

可选地，在步骤103之后，还包括：将所述下游服务的请求数据发送至web客户端，以在web页面展示所述下游服务的请求数据。web服务端从缓存中获取上游服务发往各种下游服务的请求数据，然后将读取到的结果展示到web页面上，如图5所示，方便测试人员查看结果。

根据上面所述的各种实施例，可以看出本发明实施例通过配置上游服务的请求，将上游服务的请求发送至上游服务，以使上游服务构造下游服务的请求数据以及将下游服务的请求数据发送至下游服务的桩服务，并使下游服务的桩服务将下游服务的请求数据写入缓存的技术手段，解决了现有技术中上下游服务间的功能测试耦合性较强的技术问题。对于涉及多个服务改动的项目，本发明实施例将下游服务用桩的方式进行测试，这样解除了上下游服务之间的强耦合性，实现了服务测试的解耦；当一个项目涉及到需要升级多个相互依赖的服务时，可以单独对升级完成的服务进行测试，无需再等待所依赖的服务开发完成，提高了测试效率及迭代效率；而且可以直接从缓存中获取上游服务发往各种下游服务的请求数据，不再需要去日志中查找。

测试人员在对远程过程调用框架的下游服务测试时，都是通过搭建一整套上游服务到下游服务的环境，通过给上游服务发送请求，然后查看上游服务的返回结果来判定下游服务是否有问题，这种测试方法不直接，很多隐藏问题都发现不了。为此，本发明实施例对上下服务间的测试进行解耦，实现了直接对下游服务进行测试。本发明实施例直接将从缓存中获取的请求数据发送给要测试的下游服务，然后得到下游服务返回的结果，通过对结果的校验来验证下游服务的改动是否符合预期。

图6是根据本发明一个可参考实施例的多服务测试方法的主要流程的示意图。作为本发明的又一个实施例，如图6所示，所述多服务测试方法可以包括：

步骤601，配置下游服务的服务名、请求、IP和端口号。

在本发明的实施例中，可以在脚本中配置下游服务的服务名、请求、IP和端口号，也可以在web客户端的页面上配置下游服务的服务名、请求、IP和端口号。如图7所示，为了方便测试人员配置下游服务的服务名、请求、IP和端口号，可以在web页面上配置下游服务的服务名、请求、IP和端口号。

可选地，配置所述下游服务或者所述下游服务的桩服务的请求，包括：将从所述缓存中获取的所述下游服务的请求配置为所述下游服务或者所述下游服务的桩服务的请求。比如，将从缓存中获取的请求数据直接填入如图7所示的请求数据输入框中，然后选择要测试的下游服务(B、C、D等)，req1代表的是该服务的默认请求。然后选择要测试的服务所在的环境机器ip及该服务的端口号。如果不在请求数据输入框中手动填写请求，则可以从下拉框里可以选择默认的一些请求。当手动填写时，下拉框里的选择失效。

步骤602，根据所述IP和所述端口号，将所述下游服务的请求发送至所述下游服务。

如图7所示，web页面上还提供了请求发送按钮，当测试人员完成配置后，点击该按钮后，web服务端接收发送指令，然后会根据用户选择的这些选项将请求发送到相应的下游服务。因此下游服务能够独立测试，可以获取到上游服务发来的请求，并且可以单独将请求数据发给下游服务。

步骤603，接收所述下游服务返回的结果。

为了方便测试人员查看下游服务的测试结果，web服务端接收到下游服务返回的结果后，将下游服务返回的结果发送至web客户端，以在web页面展示所述下游服务返回的结果。如图7所示，下游服务返回的结果显示到返回结果处的输入框里，这样测试人员可以根据返回的结果去验证是否符合本次项目的改动。

需要指出的是，在步骤601中配置下游服务的请求时，可以随意改动从缓存中获取的下游服务的请求数据，然后将改动后的请求数据配置为下游服务的请求。因为每次升级点要对应很多测试点，通过修改请求数据里的参数去测试服务的不同逻辑，这样测试场景的全面性就得到了保证。

本发明实施例对上下游服务间的功能测试进行解耦，当一个项目涉及到需要升级多个相互依赖的服务时，可以单独对升级完成的服务进行测试，无需再等待所依赖的服务开发完成，提高测试及开发迭代效率；而且可以直接从缓存中获取上游服务发往各种下游服务的请求，不再需要去日志中查找。因此，本发明实施例能够使服务的测试更加自动化、全面化以及方便，从而提高了测试及开发迭代效率。

图8是根据本发明另一个可参考实施例的多服务测试方法的主要流程的示意图。作为本发明的另一个实施例，如图8所示，所述多服务测试方法，应用于web服务端，可以包括：

步骤801，接收web客户端发送的测试请求，所述测试请求携带上游服务的请求及其业务类型，然后生成所述上游服务的请求的唯一标识。

测试人员可以在web客户端的页面上配置上游服务的请求及其业务类型，web客户端将配置的请求及其业务类型发送至web服务端，web服务端接收到web客户端发送过来的测试请求后，为该上游服务的请求生成唯一标识。

步骤802，将所述上游服务的请求发送至所述上游服务，以使所述上游服务构造下游服务的请求数据，将所述下游服务的请求数据发送至所述下游服务的桩服务，并使所述下游服务的桩服务将所述下游服务的请求数据写入缓存。

web服务端将所述上游服务的请求发送至所述上游服务，上游服务根据自己的业务逻辑构造各种下游服务的请求数据，然后将这些请求数据分别发送至对应的下游服务的桩服务，下游服务的桩服务接收到上游服务发送过来的请求数据后，将这些请求数据写入缓存。其中，所述缓存中的主键包括所述上游服务的请求的唯一标识和所述下游服务的服务名，所述缓存中的值为所述下游服务的请求数据。

步骤803，从所述缓存中获取所述下游服务的请求数据，将所述下游服务的请求数据发送至web客户端，以使所述下游服务的请求数据展示在web页面。

web服务端从缓存中获取所述下游服务的请求数据，然后将获取到的请求数据发送至web客户端。web客户端接收到web服务端发送的下游服务的请求数据后，将其展示在web页面上，方便测试人员查看。

步骤804，接收web客户端发送的测试请求，所述测试请求携带下游服务的服务名、请求、IP和端口号。

为了实现对下游服务的独立测试，测试人员也可以在web客户端的页面上配置下游服务的服务名、请求、IP和端口号等，web客户端将配置的服务名、请求、IP和端口号发送至web服务端。为了提高测试效率，测试人员可以直接将从缓存中获取的下游服务的请求数据配置为下游服务的请求，将其填入请求数据输入框中。

步骤805，根据所述IP和所述端口号，将所述下游服务的请求发送至所述下游服务。

web服务端接收到web客户端发送的测试请求后，根据所述IP和所述端口号，将下游服务的请求发送至所述下游服务，以测试所述下游服务。

步骤806，接收所述下游服务返回的结果。

所述下游服务将测试结果返回至web服务端。

步骤807，将返回结果写入配置文件中。

web服务端接收到下游服务返回的结果后，将其写入配置文件中。或者，写入配置文件的返回结果是预置的返回结果。

步骤808，通过所述下游服务的桩服务加载所述配置文件，以使所述下游服务的桩服务将所述返回结果返回至所述上游服务。

在一个大的项目中，通常一次升级会涉及到很多服务的改动，当一个服务的测试过程需要用到另一个服务的结果而另一个服务又没开发完时，此时对于测试来说，通常只能等待另一个服务的开发完成，才可以进行此服务的测试，这样比较浪费时间，不符合敏捷开发的思想。为此，本发明实施例实现了服务间的解耦测试，每个服务都可以独立去测试。如图9所示，本发明实施例开发了每个服务的桩服务，桩服务会去加载配置文件，这样桩服务会将配置文件中的结果返回给上游服务，从而可以对上游服务进行独立测试。

另外，在本发明另一个可参考实施例中页面加载方法的具体实施内容，在上面所述页面加载方法中已经详细说明了，故在此重复内容不再说明。

图10是根据本发明实施例的多服务测试装置的主要模块的示意图，如图10所示，所述多服务测试装置1000包括配置模块1001、发送模块1002和获取模块1003；其中，配置模块1001用于配置上游服务的请求；发送模块1002用于将所述上游服务的请求发送至所述上游服务，以使所述上游服务构造下游服务的请求数据，将所述下游服务的请求数据发送至所述下游服务的桩服务，并使所述下游服务的桩服务将所述下游服务的请求数据写入缓存；获取模块1003用于从所述缓存中获取所述下游服务的请求数据。

可选地，所述配置模块1001还用于：

配置上游服务的请求之后，生成所述上游服务的请求的唯一标识，以及，配置所述上游服务的业务类型。

可选地，所述缓存中的主键包括所述上游服务的请求的唯一标识和所述下游服务的服务名，所述缓存中的值为所述下游服务的请求数据。

可选地，所述配置模块1001还用于：

配置所述下游服务的服务名、请求、IP和端口号；

根据所述IP和所述端口号，将所述下游服务的请求发送至所述下游服务；

接收所述下游服务返回的结果。

可选地，所述配置模块1001还用于：

将从所述缓存中获取的所述下游服务的请求数据配置为所述下游服务的请求。

可选地，所述配置模块1001还用于：

将返回结果写入配置文件中；

通过所述下游服务的桩服务加载所述配置文件，以使所述下游服务的桩服务将所述返回结果返回至所述上游服务。

可选地，所述返回结果为预置的返回结果，或者，所述下游服务返回的结果。

根据上面所述的各种实施例，可以看出本发明实施例通过配置上游服务的请求，将上游服务的请求发送至上游服务，以使上游服务构造下游服务的请求数据以及将下游服务的请求数据发送至下游服务的桩服务，并使下游服务的桩服务将下游服务的请求数据写入缓存的技术手段，解决了现有技术中上下游服务间的功能测试耦合性较强的技术问题。对于涉及多个服务改动的项目，本发明实施例将下游服务用桩的方式进行测试，这样解除了上下游服务之间的强耦合性，实现了服务测试的解耦；当一个项目涉及到需要升级多个相互依赖的服务时，可以单独对升级完成的服务进行测试，无需再等待所依赖的服务开发完成，提高了测试效率及迭代效率；而且可以直接从缓存中获取上游服务发往各种下游服务的请求数据，不再需要去日志中查找。

需要说明的是，在本发明所述多服务测试装置的具体实施内容，在上面所述多服务测试方法中已经详细说明了，故在此重复内容不再说明。

图11示出了可以应用本发明实施例的多服务测试方法或多服务测试装置的示例性系统架构1100。

如图11所示，系统架构1100可以包括终端设备1101、1102、1103，网络1104和服务器1105。网络1104用以在终端设备1101、1102、1103和服务器1105之间提供通信链路的介质。网络1104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备1101、1102、1103通过网络1104与服务器1105交互，以接收或发送消息等。终端设备1101、1102、1103上可以安装有各种通讯客户端应用，例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等(仅为示例)。

终端设备1101、1102、1103可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

服务器1105可以是提供各种服务的服务器，例如对用户利用终端设备1101、1102、1103所浏览的购物类网站提供支持的后台管理服务器(仅为示例)。后台管理服务器可以对接收到的物品信息查询请求等数据进行分析等处理，并将处理结果(例如目标推送信息、物品信息——仅为示例)反馈给终端设备。

需要说明的是，本发明实施例所提供的多服务测试方法一般由服务器1105执行，相应地，所述多服务测试装置一般设置在服务器1105中。

应该理解，图11中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

下面参考图12，其示出了适于用来实现本发明实施例的终端设备的计算机系统1200的结构示意图。图12示出的终端设备仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图12所示，计算机系统1200包括中央处理单元(CPU)1201，其可以根据存储在只读存储器(ROM)1202中的程序或者从存储部分1208加载到随机访问存储器(RAM)1203中的程序而执行各种适当的动作和处理。在RAM 1203中，还存储有系统1200操作所需的各种程序和数据。CPU 1201、ROM 1202以及RAM1203通过总线1204彼此相连。输入/输出(I/O)接口1205也连接至总线1204。

以下部件连接至I/O接口1205：包括键盘、鼠标等的输入部分1206；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分1207；包括硬盘等的存储部分1208；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分1209。通信部分1209经由诸如因特网的网络执行通信处理。驱动器1210也根据需要连接至I/O接口1205。可拆卸介质1211，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1210上，以便于从其上读出的计算机程序根据需要被安装入存储部分1208。

特别地，根据本发明公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本发明公开的实施例包括一种计算机程序，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分1209从网络上被下载和安装，和/或从可拆卸介质1211被安装。在该计算机程序被中央处理单元(CPU)1201执行时，执行本发明的系统中限定的上述功能。

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

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

描述于本发明实施例中所涉及到的模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的模块也可以设置在处理器中，例如，可以描述为：一种处理器包括配置模块、发送模块和获取模块，其中，这些模块的名称在某种情况下并不构成对该模块本身的限定。

作为另一方面，本发明还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，该设备实现如下方法：配置上游服务的请求；将所述上游服务的请求发送至所述上游服务，以使所述上游服务构造下游服务的请求数据，将所述下游服务的请求数据发送至所述下游服务的桩服务，并使所述下游服务的桩服务将所述下游服务的请求数据写入缓存；从所述缓存中获取所述下游服务的请求数据。

根据本发明实施例的技术方案，因为采用配置上游服务的请求，将上游服务的请求发送至上游服务，以使上游服务构造下游服务的请求数据以及将下游服务的请求数据发送至下游服务的桩服务，并使下游服务的桩服务将下游服务的请求数据写入缓存的技术手段，所以克服了现有技术中上下游服务间的功能测试耦合性较强的技术问题。对于涉及多个服务改动的项目，本发明实施例将下游服务用桩的方式进行测试，这样解除了上下游服务之间的强耦合性，实现了服务测试的解耦；当一个项目涉及到需要升级多个相互依赖的服务时，可以单独对升级完成的服务进行测试，无需再等待所依赖的服务开发完成，提高了测试效率及迭代效率；而且可以直接从缓存中获取上游服务发往各种下游服务的请求数据，不再需要去日志中查找。

上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。