CN104468655B - 对反向代理软件进行测试的方法及系统 - Google Patents

Abstract

本申请公开了对反向代理软件进行测试的方法及系统，其中，所述方法包括：接收到案例场景可执行文件后，按照所述案例场景可执行文件启动测试；当客户端节点向反向代理节点发送第一请求消息、反向代理节点向服务器节点发送携带有所述第一请求消息的报文内容的第二请求消息时，驱动所述服务器节点通过预先在客户端节点与服务器节点之间建立的消息通道，向所述客户端节点获取所述第一请求消息的原始报文内容；获取所述第二请求消息中携带的第一请求消息的报文内容相对于所述第一请求消息的原始报文内容发生的第一变更信息；判断所述第一变更信息是否符合预置的期望信息，如果不符合，则提供第一提示信息。通过本申请，能够获得更有效的测试结果。

Description

对反向代理软件进行测试的方法及系统

技术领域

本申请涉及反向代理软件测试技术领域，特别是涉及对反向代理软件进行测试的方法及系统。

背景技术

反向代理（Reverse Proxy）方式是指以代理服务器来接收Internet上的连接请求消息，然后将请求消息转发给内部网络上的服务器，并将从服务器上得到的结果返回给Internet上请求消息连接的客户端。参见图1，反向代理位于Internet用户与原始web服务器之间，它负责接收和处理所有对原始web服务器的请求消息。如果Internet用户请求消息的页面在代理服务器上有缓存，代理服务器直接将缓存内容发送给用户；如果没有缓存，则先向原始web服务器发出请求消息，从原始web服务器取回数据并在本地缓存后再发送给用户。此时，代理服务器对外就表现为一个服务器。这种方式通过降低向web服务器的请求消息数，降低了web服务器的负载。

具体实现时，一般需要安装反向代理软件来实现反向代理服务器的上述功能。目前业界以及各大公司在使用的反向代理软件有多种，反向代理软件在实现对客户端请求消息报文、原始服务器端的响应消息报文进行转发的过程中，还可能会涉及到对请求消息报文或者响应消息报文的变更，当然，这种变更前提是，变更后的内容符合用户的预期。也就是说，假设反向代理软件对某报文中的某个字段的值进行了修改，则修改后的值应该符合HTTP（Hypertext transfer protocol，超文本传输协议）协议中对该字段的值的规定。

但是随着业务种类、访问流量的不断的上升，CDN（Content Delivery Network，内容分发网络）线上所暴露的HTTP请求消息处理异常情况也呈现多样化复杂化，软件开发人员在开发反向代理软件的过程中，需要确定某些特定请求消息下反向代理软件到底执行何种动作才是符合协议规定的，而不是把仅仅能够满足业务需求作为目标。因此，需要开发出一套对反向代理软件的协议一致性进行测试的工具，以期既能够堵住协议标准支持方面存在的漏洞，把问题提前暴露于线下，又可以评估出不同产品不同版本间对HTTP/1.1标准协议支持程度，方便做纵向、横向对比。

参见图2，现有技术中提供的测试工具的具体原理如下：

首先，采用某种HTTP请求消息模拟工具（例如linux上Curl工具），用以模拟Internet上的用户行为，部署在测试机器1上；机器2上部署被测反向代理软件；机器3上部署常用HTTP Server软件，例如lighthttp、apache等，用以模拟原始Web服务器；并进行配置，使得机器1上HTTP模拟工具发出的请求消息，能够通过被测反向代理从HTTP Server上正确获得所请求消息的内容数据，HTTP Server能够接收和响应消息来自被测反向代理转发的请求消息。之后就可以进入具体的测试流程：

步骤一：手工填充HTTP模拟发送工具所需要的参数，发送请求消息报文至反向代理；

步骤二：反向代理根据报文内容将请求消息转发至HTTP Server软件；

步骤三：HTTP Server软件根据自身HTTP/1.1协议实现方案，回复响应消息报文至反向代理；

步骤四：在机器1处HTTP请求消息发送端，借助某些工具，人工查看返回的报文内容是否符合预期；同时登陆机器2，执行反向代理的内置命令，查看反向代理的当前状态和缓存行为是否符合预期。

上述测试方法中，通过最后人工查看报文内容等是否符合预期，可以判断出上述流程中是否存在问题，但是，其缺陷在于：无法确定问题是出现在反向代理软件一端，还是HTTP Server一端，或者是整个流程中的其他环节，因此，测试结果的有效性有待提高。

发明内容

本申请提供了对反向代理软件进行测试的方法及系统，能够获得更有效的测试结果。

本申请提供了如下方案：

一种对反向代理软件进行测试的方法，其特征在于，包括：

接收到案例场景可执行文件后，按照所述案例场景可执行文件启动测试；

当客户端节点向反向代理节点发送第一请求消息、反向代理节点向服务器节点发送携带有所述第一请求消息的报文内容的第二请求消息时，按照所述案例场景可执行文件，驱动所述服务器节点通过预先在客户端节点与服务器节点之间建立的消息通道，向所述客户端节点获取所述第一请求消息的原始报文内容；其中，所述反向代理节点中部署有被测反向代理软件；

获取所述第二请求消息中携带的第一请求消息的报文内容相对于所述第一请求消息的原始报文内容发生的第一变更信息；

根据所述案例场景可执行文件，判断所述第一变更信息是否符合预置的期望信息，如果不符合，则提供第一提示信息。

一种对反向代理软件进行测试的方法，包括：

接收到案例场景可执行文件后，按照所述案例场景可执行文件启动测试；

当客户端节点向反向代理节点发送第三请求消息、反向代理节点根据缓存的报文内容返回响应消息时，按照所述案例场景可执行文件，驱动所述客户端节点通过预先在客户端节点与服务器节点之间建立的消息通道，查询服务器节点是否收到发自反向代理节点的第四请求消息，并向所述服务器节点获取针对所述第三请求消息的响应消息的原始报文内容；其中，所述反向代理节点中部署有被测反向代理软件；

如果服务器节点收到了发自反向代理节点的第二请求消息，则提供第四提示信息；

获取所述反向代理节点返回的响应消息的报文内容相对于所述原始报文内容发生的变更信息；

根据所述案例场景可执行文件，判断所述变更信息是否符合预置的期望信息，如果不符合，则提供第五提示信息。

一种对反向代理软件进行测试的系统，包括：

测试启动单元，用于接收到案例场景可执行文件后，按照所述案例场景可执行文件启动测试；

第一报文内容检查单元，用于当客户端节点向反向代理节点发送第一请求消息、反向代理节点向服务器节点发送携带有所述第一请求消息的报文内容的第二请求消息时，按照所述案例场景可执行文件，驱动所述服务器节点通过预先在客户端节点与服务器节点之间建立的消息通道，向所述客户端节点获取所述第一请求消息的原始报文内容；其中，所述反向代理节点中部署有被测反向代理软件；

第一变更信息获取单元，用于获取所述第二请求消息中携带的第一请求消息的报文内容相对于所述第一请求消息的原始报文内容发生的第一变更信息；

第一提示单元，用于根据所述案例场景可执行文件，判断所述第一变更信息是否符合预置的期望信息，如果不符合，则提供第一提示信息。

一种对反向代理软件进行测试的系统，包括：

测试启动单元，用于接收到案例场景可执行文件后，按照所述案例场景可执行文件启动测试；

第三报文内容检查单元，用于当客户端节点向反向代理节点发送第三请求消息、反向代理节点根据缓存的报文内容返回响应消息时，按照所述案例场景可执行文件，驱动所述客户端节点通过预先在客户端节点与服务器节点之间建立的消息通道，查询服务器节点是否收到发自反向代理节点的第四请求消息，并向所述服务器节点获取针对所述第三请求消息的响应消息的原始报文内容；其中，所述反向代理节点中部署有被测反向代理软件；

第四提示单元，用于如果服务器节点收到了发自反向代理节点的第二请求消息，则提供第四提示信息；

第三变更信息获取单元，用于获取所述反向代理节点返回的响应消息的报文内容相对于所述原始报文内容发生的变更信息；

第五提示单元，用于根据所述案例场景可执行文件，判断所述变更信息是否符合预置的期望信息，如果不符合，则提供第五提示信息。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例，使得服务器端在收到反向代理节点发送的第二请求消息之后，可以进行报文内容检查，也即通过预先建立的专用的消息通道，向客户端索取第一请求消息的原始报文信息，然后将第二请求消息中携带的第一请求消息的报文内容与原始报文内容进行比对，找出其中发生变更之处，并与案例场景文件中写明的期望信息进行比对，便可以确定反向代理软件在此次转发过程中，是否对报文内容进行了不符合用户期望的变更，也即，反向代理软件是否满足协议一致性的要求。因此，通过这种方式，可以有效地检测出反向代理软件可能存在的问题。并且，客户端节点与服务器节点之间传送消息的原始报文内容时，可以通过专用的消息通道来进行，从而实现将报文内容与消息/信号的传递隔离开来，分别形成数据层面和控制层面，这样既可以保证数据报文的安全准确，又可以保证消息/信号的高效传递。

另外，通过对案例场景的格式化描述，可以降低案例提交者的门槛，提高测试案例场景的编写效率；更为重要的是，使得系统可以识别出每一步骤的含义，实现对一些必须字段的智能补全。并且，通过对每一步骤的目的进行识别，甚至还可以对各个步骤之间的上下文依赖关系进行识别，可以获知整个案例场景的测试目的，以此更准确地确定智能补全时需要填充的字段或者取值等信息，以便更真实的反映测试案例场景的需要。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

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

图1是反向代理系统结构示意图；

图2是现有技术中的测试方案示意图；

图3是本申请实施例提供的方法的流程图；

图4是本申请实施例提供的方法中的报文交互时序图；

图5是本申请实施例提供的另一方法的流程图；

图6是本申请实施例提供的另一方法中的报文交互时序图；

图7是本申请实施例提供的数据一致性检查方法流程图；

图8是本申请实施例提供的复杂案例场景示意图；

图9是本申请实施例提供的测试案例场景描述文件编译方法的流程图；

图10是本申请实施例提供的智能补全方法流程图；

图11是本申请实施例提供的系统的示意图；

图12是本申请实施例提供的另一系统的示意图。

具体实施方式

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

在本申请实施例中，提供了对反向代理软件进行测试的套件，该套件中可以包括客户端以及服务器端，用户可以在其机器上安装该套件，用以对被测反向代理软件进行测试。也就是说，在本申请实施例中，客户端以及服务器端可以安装在同一机器上。其中，为了得到更有效的测试结果，更好的定位问题出现的位置，在客户端和服务器端分别增加agent代理，在部署测试套件的过程中，就可以在两agent之间通过socket连接建立起专用消息通道，以供后续的测试过程使用。当然，由于客户端以及服务器端可以部署在同一台机器上，因此，为了能够在两者之间建立起socket连接，可以使得客户端与服务器端对应不同的端口。另外，被测反向代理软件也可以部署在测试套件所在的同一机器上，并且，也可以使得反向代理软件对应其他的端口，这样可以在同一机器上模拟不同的网络节点。当然，在实际应用中，具体的测试工具也可以不必以套件的形式存在，而是分别在不同的机器上部署客户端、被测反向代理软件以及服务器端，在客户端所在机器与服务器端所在机器之间建立起专用的消息通道，以供具体的测试过程使用。需要说明的是，关于本申请实施例的测试套件中涉及到的各端，无论是部署与同一台机器上，还是部署在不同的机器上，但是每一端可以看作是一个节点，在测试的过程中，需要在各个节点之间进行报文交互，并判断交互过程中是否出现不符合用户预期的变更，等等，以此对被测反向代理软件对协议一致性的支持方面进行测试。下面就对具体的测试过程进行详细地介绍。

实施例一

本申请实施例一首先提供了一种对反向代理软件进行测试的方法，在该方法中，针对的是报文交互过程中反向代理节点的缓存未命中(miss)的情况，参见图3，具体可以包括以下步骤：

S301：接收到案例场景可执行文件后，按照所述案例场景可执行文件启动测试；

具体实现时，在机器上部署了本申请实施例提供的测试套件，并建立起客户端节点与服务器节点之间的专用消息通道之后，就可以执行具体的测试过程。但在具体实现时，在执行测试之前，还需要获取到案例场景可执行文件，在收到该案例场景可执行文件之后，才会启动具体的测试过程。其中，所谓的案例场景就是由测试人员根据需要，手动或者自动生成的对测试过程中具体交互流程的描述，例如，驱动客户端产生请求消息，等等。也就是说，在机器中部署了本申请实施例中的测试套件之后，相当于搭建起了测试的基本架构，但是，如何使用该架构进行测试，还取决于案例场景可执行文件中的描述，该基本架构相当于可以支持案例场景的执行，各端可以测试执行模块的驱动下产生请求消息、响应消息等。

其中，具体的案例场景最初可以是由Java等语言描述的，之后进行编译，得到可执行文件，然后就可以将案例场景可执行文件输入到本申请实施例中的测试执行模块来执行。也就是说，具体测试过程中，报文消息具体应该如何流动，客户端、服务器端分别应该执行哪些处理，都可以是在案例场景中规定好的。在执行该可执行文件的过程中，就相当于驱动客户端、服务器端按照可执行文件中的规定执行具体的操作，包括发送请求消息、响应消息，此外，在本申请实施例中还包括对内容进行检查等，关于此，下文中会有详细的介绍。

S302：当客户端节点向反向代理节点发送第一请求消息、反向代理节点向服务器节点发送携带有所述第一请求消息的报文内容的第二请求消息时，按照所述案例场景可执行文件，驱动所述服务器节点通过预先在客户端节点与服务器节点之间建立的消息通道，向所述客户端节点获取所述第一请求消息的原始报文内容；其中，所述反向代理节点中部署有被测反向代理软件；

由于该实施例一针对的是报文交互过程中反向代理节点的缓存未命中的情况，也就是说，客户端发起某请求消息，针对该请求消息的响应消息的报文内容尚未在反向代理节点上进行缓存。在这种情况下，客户端在发出一个请求消息之后，反向代理节点会首先判断在缓存中是否存在针对该请求消息的响应消息的报文内容，在判断发现没有之后，反向代理节点会向服务器节点发送一个请求消息。为了便于区分，将客户端发送的请求消息称为第一请求消息，将反向代理节点发送到服务器节点的请求消息称为第二请求消息。

其中，反向代理节点在收到客户端节点的第一请求消息时，如果发现需要向服务器节点进行转发，则在转发之前，可能会对第一请求消息的报文内容进行一些变更，例如，在消息头中加入一些字段等，然后再在第二请求消息中携带上变更后的第一请求消息的报文内容，并发送给服务器节点。具体如何对第一请求消息的报文内容进行修改，是由反向代理软件来决定的，本申请实施例中的测试过程，主要的测试目的就是判断这种更改是否符合用户预期，也即是否符合协议中的规定。

为了能够达到上述测试目的，在反向代理节点向服务器节点发送了携带有第一请求消息的报文内容的第二请求消息之后，就可以按照案例场景可执行文件中的操作指示，驱动服务器节点通过预先在客户端节点与服务器节点之间建立的消息通道，向客户端节点获取第一请求消息的原始报文内容，以便后续进行比对。也就是说，在本申请实施例中，由于预先已经在客户端节点与服务器节点之间建立了专用的消息通道，因此，在服务器节点收到反向代理节点发送的第二请求消息之后，测试执行模块就可以驱动服务器节点向客户端节点索取第一请求消息的原始报文内容，这样就可以在服务器节点处，将第二请求消息中携带的第一请求消息的报文内容与第一请求消息的原始报文内容进行比对，获取发生的变更信息。

S303：获取所述第二请求消息中携带的第一请求消息的报文内容相对于所述第一请求消息的原始报文内容发生的第一变更信息；

在获取到第一请求消息的原始报文内容之后，就可以判断第二请求消息中携带的第一请求消息的报文内容相对于该原始报文内容发生的第一变更信息，也就是说判断反向代理软件在向服务器节点发送第二请求消息之前，对第一请求消息哪些内容进行了变更，变更后的值是什么，进而确定反向代理软件进行的这种变更是否符合用户的预期，是否符合协议中的规定。

S304：根据所述案例场景可执行文件，判断所述第一变更信息是否符合预置的期望信息，如果不符合，则提供第一提示信息。

关于期望反向代理软件将第一请求消息的报文内容进行怎样的变更，也是在案例场景描述文件中写明的，因此，在步骤S303中获取到第一变更信息之后，就可以判断该第一变更信息与案例场景描述文件中写明的期望值是否相同，如果不相同，则可以证明是反向代理软件进行的变更不符合用户的预期，不符合协议中的规定，因此，可以发出提示信息，并终止测试的进行。当然，在发出提示信息之后，也可以继续执行测试，只要通过提示信息让用户知晓此处发生了问题即可。

为便于描述，本申请实施例中从上述步骤S302中的通过专用消息通道获取客户端的原始报文内容，到步骤S303中获取第一变更信息，再到步骤S304中判断这种第一变更信息是否符合用户的预期的过程，称为服务器节点的报文内容检查过程。

通过本申请实施例一，使得服务器端在收到反向代理节点发送的第二请求消息之后，可以进行报文内容检查，也即通过预先建立的专用的消息通道，向客户端索取第一请求消息的原始报文信息，然后将第二请求消息中携带的第一请求消息的报文内容与原始报文内容进行比对，找出其中发生变更之处，并与案例场景文件中写明的期望信息进行比对，便可以确定反向代理软件在此次转发过程中，是否对报文内容进行了不符合用户期望的变更，也即，反向代理软件是否满足协议一致性的要求。因此，通过这种方式，可以有效地检测出反向代理软件可能存在的问题。并且，客户端节点与服务器节点之间传送消息的原始报文内容时，可以通过专用的消息通道来进行，从而实现将报文内容与消息/信号的传递隔离开来，分别形成数据层面和控制层面，这样既可以保证数据报文的安全准确，又可以保证消息/信号的高效传递。

在上述步骤S304中，如果发现第一变更信息符合预置的期望信息，则可以按照案例场景可执行文件继续执行测试，首先，服务器节点就可以将第一请求消息对应的响应消息发送到反向代理节点，在反向代理节点可能会对服务器节点的响应消息的报文内容进行一定的修改，然后再重新生成响应消息，在其中携带上服务器节点的响应消息的报文内容，返回给客户端。这里，为了便于区分，将服务器节点返回的响应消息称为第一响应消息，将反向代理节点向客户端节点返回的响应消息称为第二响应消息，其中，第二响应消息中携带有第一响应消息的报文内容，并且该报文内容可能是被反向反向代理软件修改过的。因此，案例场景描述文件中一般也会将此处确定为需要对报文内容进行检查的地方。也就是说，需要驱动客户端节点通过预先建立的专用消息通道，向服务器端索取第一响应消息的原始报文内容，然后就可以获取第二响应消息中携带的第一响应消息的报文内容相对于第一响应消息的原始报文内容发生的第二变更信息，并根据案例场景描述文件，判断该第二变更信息是否符合用户预置的期望信息，如果不符合，则提供第二提示信息。也即，可以提示用户反向代理软件在此处出现了问题。具体实现时，在发出第二提示信息之后，可以终止此次测试过程，或者也可以继续执行。

另外，在实际应用中，在进行报文内容检查的过程中，或者执行完某次报文内容检查之后，可能需要获取或者重置对端软件的工作状态，在本申请实施例中，同样可以通过客户端节点与服务器节点之间的专用消息通道实现。例如，在服务器节点执行完一次报文内容检查之后，如果需要获取/重置客户端软件的工作状态，则可以在案例场景中写明，在执行案例场景可执行文件的过程中，就可以根据案例场景中的描述，来驱动服务器向客户端节点发送信号，获取/重置客户端软件的工作状态，达到对控制客户端节点行为的目的。同理，在客户端节点完成某次报文内容检查之后，如果需要获取/重置服务器端软件的工作状态，则可以在案例场景中写明，在执行案例场景可执行文件的过程中，就可以根据案例场景中的描述，来驱动客户端向服务器节点发送信号，获取/重置服务器软件的工作状态，从而更新或维护整体测试环境。

为了更好的理解本申请实施例一提供的上述方法，下面通过一个时序图对上述方法进行详细的介绍。参见图4，在反向代理节点缓存未命中的情况下，报文交互的流程图包括以下步骤：

S401：客户端节点（Client端）发送第一请求消息（Request请求），请求到达反向代理后，缓存中并没有从源服务器Server端事先获得的数据，因此反向代理节点当前处于未命中miss状态；

S402：反向代理向Server端发起新的第二请求消息，并携带第一请求消息的报文内容，请求用户所需要的内容。Server端收到请求后，首先通过以下方式执行报文内容检查操作：Server使用本端的Agent，通过专用消息通道，向Client端索取第一请求消息Request的原始报文内容，从而检查Request请求报文在经过被测反向代理转发后，是否已经发生了用户不期望的内容变更。同时，Server端也可以通过该专用消息通道发送信号，获取或重置Client端软件工作状态，从而达到控制Client行为的目的。

S403：当Server端Request报文内容检查通过后，将根据HTTP/1.1协议相关规定，发送响应消息即Response报文。

S404：Response报文经过被测反向代理后，将在反向代理处缓存一份副本，之后反向代理将Response报文转发至Client端。同上所述，Client端首先执行报文内容检查操作：Client使用本端的Agent，通过专用消息通道，向Server端索取Response消息的原始报文内容，从而检查Response报文内容是否在经过反向代理后发生不可预期的变更。Client端同样可以通过该通道发送信号至Server端，获取或重置Server端软件状态，从而更新或维护整体测试环境。

实施例二

以上实施例一对反向代理节点未命中的情况下，本申请实施例提供的测试方法，在该实施例二中，对反向代理节点命中(hit)的情况下，具体的测试过程进行详细的介绍。

参见图5，本申请实施例二提供的对反向代理软件进行测试的方法可以包括以下步骤：

S501：接收到案例场景可执行文件后，按照所述案例场景可执行文件启动测试；

该步骤与步骤S301相同。

S502：当客户端节点向反向代理节点发送第三请求消息、反向代理节点根据缓存的报文内容返回响应消息时，按照所述案例场景可执行文件，驱动所述客户端节点通过预先在客户端节点与服务器节点之间建立的消息通道，查询服务器节点是否收到发自反向代理节点的第四请求消息，并向所述服务器节点获取针对所述第三请求消息的响应消息的原始报文内容；其中，所述反向代理节点中部署有被测反向代理软件；

对于反向代理节点的缓存命中了第三请求消息的情况下，反向代理节点就会直接向客户端节点返回响应消息，并携带之前缓存的报文内容。也就是说，在正常的情况下，反向代理节点应该不再向原始服务器节点发送第四请求消息。另外，反向代理节点提供的响应消息的报文内容相对于原始服务器节点提供的原始报文内容可能已经发生了变更，而在正常情况下，这种变更应该符合用户的预期。因此，在本申请实施例中，就可以对以上两点进行检查，从而达到测试的目的。

具体实现时，这两部分检查的触发以及用户预期的变更后的信息都可以写在案例场景描述文件中，这样在执行案例场景可执行文件的过程中，就可以直接按照案例场景的描述，来驱动客户端节点通过预先在客户端节点与服务器节点之间建立的专用消息通道向服务器节点发送消息，查询服务器节点是否收到发自反向代理节点的第四请求消息，并向服务器节点获取针对第三请求消息的响应消息的原始报文内容。

S503：如果服务器节点收到了发自反向代理节点的第四请求消息，则提供第四提示信息；

由于正常情况下，服务器节点应该不会收到反向代理节点发送的请求消息，而如果服务器节点收到了该消息，则证明反向代理软件的处理是不符合用户预期的，因此，可以向用户发出相应的提示信息，提醒用户发现了该问题。

S504：获取所述反向代理节点返回的响应消息的报文内容相对于所述原始报文内容发生的变更信息；

在获取到服务器节点的原始报文内容之后，可以将从反向代理节点获取到的响应消息中携带的报文内容与原始报文内容进行比对，从而获取到发生的变更信息。

S505：根据所述案例场景可执行文件，判断所述变更信息是否符合预置的期望信息，如果不符合，则提供第五提示信息。

由于案例场景描述信息中写明了期望的变更信息，因此就可以判断变更信息是否符合用户的预期，如果不符合，则可以进行提示，告知用户发现了该问题，提醒用户注意。

也就是说，在该实施例二中，对于反向代理节点能够命中客户端请求的情况，也提供了相应的测试方式，从而可以及时的发现反向代理节点在此过程中是否进行不符合用户预期的操作，获得有效的测试结果。

为了更好地理解本申请实施例二中提供的测试方法，下面通过一个时序图对上述方法进行详细的介绍。参见图6，在反向代理节点缓存命中的情况下，报文交互的流程图包括以下步骤：

S601：客户端节点（Client端）发送Request请求后，报文内容在反向代理缓存中已经存在，此时缓存为hit命中状态；

S602：反向代理不再重新向源服务器节点（Server端）发起请求，而是直接将缓存中中命中的内容作为响应回复Client端。在此过程中，Server端没有收到Request报文，Client端可以使用本端Agent通过专用的消息通道向Server端发送消息，查询Server端是否如同预期一样没有收到发自反向代理的Request请求。并且，Client端在收到来自反向代理节点的响应消息后，同样可以执行报文内容检查动作，检查来自反向代理缓存中的Response副本相对于Server端的原始报文内容，是否发生不符合用户预期的变化。同时也可以通过专用消息管道，获取Server端当前状态。

下面对以上实施例一以及实施例二中的具体实现进行以下补充介绍。

首先，在上述实施例一以及实施例二中，关于驱动服务器节点/客户端节点通过预先建立的消息通道向客户端节点/服务器节点索取原始报文内容，都是在案例场景描述中写好的。也就是说，测试人员在写案例场景描述文件时，可以先确定好需要在何时对报文进行检查，并写好期望的变更是怎样的，这样在执行可执行文件的过程中，在对应的环节上，测试执行模块就会驱动对应的服务器节点/客户端节点通过专用的消息通道向对端节点索取原始报文内容。这种在案例场景描述文件中指定的报文检查时机，一般是测试人员认为可能会出现问题的地方。但是，在实际应用中，在报文传递的整个流程中，除了测试人员指定的可能会出现问题的地方之外，还有很多其他环节可能会出现问题。例如，在网络传输的过程中，还可能导致传输的报文内容出错等等。也就是说，假设通过报文内容检查发现反向代理节点发送给服务器节点的第二请求消息中携带的第一请求消息的报文内容相对于原始报文内容发生的变更不符合预期，可能不完全是由于反向代理软件在修改时造成的，还可能是由于报文内容在传输的过程中，由于网络环境的因素，使得报文内容被篡改或者发生了不可预期的变化，等等。因此，如果能够对这种环节也进行测试，则可以获得更准确的测试结果。

但是对于测试人员而言，在写案例场景描述文件时，一般不会对报文传输中的各个环节都进行检查，而是仅在其最为关心的结果地方进行检查。为此，在本申请实施例中，可以由系统中的测试执行模块驱动执行在其他环节上的检查操作。其中，这里的测试执行模块就是前文所述的用于执行案例场景可执行文件的模块，也就是说，该模块在按照案例场景可执行文件的规定驱动各端进行报文交互以及报文内容检查的过程中，还可以对网络传输过程中的数据一致性进行检查，以便获取到更准确的测试结果。

具体实现时，在各节点之间都可以预先建立起专用的消息通道，当有消息从上一节点发送到当前节点时，测试执行模块可以自动驱动当前节点通过预先在上一节点与当前节点之间建立的消息通道，获取上一节点发出的消息的报文内容；并判断当前节点接收到的消息报文内容与从消息通道获取到的报文内容是否一致，如果不一致，则提供第三提示信息。这里，各节点就包括测试系统中的客户端节点、反向代理节点、服务器节点，发送的消息就包括请求消息或者响应消息。也就是说，报文在流动到网络中任何节点时，都可以通过专有消息通道获取在上一节点发送的报文内容的拷贝，然后，通过md5校验等方式，对节点通过网络收到的报文内容，与通过专用消息通道获取到的上一节点发出的报文内容进行一致性检查，具体可以包括对报文头部和报文主体内容的一致性检查，当发现不一致时，可以及时给出提示或告警，这样可以避免图3或者图5的测试过程中发生误判。

当然，对于案例场景描述文件中已经指定需要进行检查的环节，测试执行模块可以不必另外启动上述一致性检查过程。例如，参见图7，一个实际应用中的例子中，具体的数据一致性检查过程可以包括以下步骤：

S701：判断案例场景中是否已经指定本端（也即当前接收到某消息的节点）需要检验HTTP报文body字段（报文主体内容），如果已经指定，执行步骤S702，如果未指定，转步骤S703；

S702：数据一致性检查程序结束，数据一致性校验工作将会根据案例场景可执行文件的规定来执行；

S703：读取当前节点接收到的来自上一节点的报文内容；

S704：从该报文内容中抽取body字段内容，定义为body1；

S705：通过当前节点的Agent，通过专用消息通道获取上一节点的原始报文的body内容，定义为body2；

S706：采用md5算法，检验md5(body1)是否与md5(body2)相等，若不相等，执行步骤S707，若相等，则转步骤S708；

S707：提示用户，报文内容发生不可预期变更，同时，当前节点可以通过agent向上一节点发送重置（reset）信号，重置上一节点软件的工作状态；

S708：判断是否为当前节点最后一个检查动作；

S709：若为当前节点最后一个检查动作，则程序结束；否则，转到步骤S701。

也就是说，在本申请实施例中，由于可以在两个节点之间建立起专用消息通道，因此，除了可以在客户端节点与服务器节点之间进行报文内容检查之外，还可以在任意两个节点之间进行数据一致性的检查，从而能够及时发现由于网络环境等原因导致的报文内容被篡改或者其他不可预期的更改，提高最终测试结果的有效性。

另外，关于实施例一以及实施例二中提到的案例场景描述文件以及案例场景可执行文件，如前文所述，按照现有技术中的方法，测试案例场景提交者可以使用Java等计算机语言来编写案例场景描述文件，然后直接进行编译得到案例场景可执行文件后，交由测试执行模块来执行。但是，如果采用这种方法，则至少存在以下问题：一方面，对编写案例场景描述文件的专业性门槛会比较高，因为测试案例场景提交者需要熟知各种计算机语言的语法规则等等，非专业技术人员难以掌握，因此提高了测试案例场景提交者的门槛，不利于大范围推广使用；另一方面，由于每次发送和接收报文都是一个独立的过程，因此多次的发送、接收之间难以体现报文发送的上下文逻辑关系，无法反映出整个案例场景的测试执行目的以及希望获得的结果，进而也就不利于帮助测试人员完成一些自动化的操作，如果案例场景中存在一些错误信息，只能提醒用户有错误存在，但并不能准确的给出修改建议。

为此，在本申请实施例中，还提供了一种格式化描述方式，在该格式化描述方式中，可以将报文交互过程按照步骤进行拆分，每一步骤分配一个关键字。如果需要对案例场景进行描述，则在描述文件中，每一步骤用对应的关键字以及附带的报文内容信息表示。例如，对应于图4中的报文交互流程，可以拆分为如下四步：

第一步为客户端节点Client向被测反向代理节点发起Request请求消息，本申请实施例中可以使用关键字Request来代表该步骤；

第二步为被测反向代理向服务器节点Server发起Request请求消息，Server端在收到Request请求消息后，执行报文内容检查，本申请实施例中可以使用ServerCheck来代表该步骤；

第三步为Server根据HTTP/1.1相关协议规定，向被测反向代理节点发出Response响应消息，本申请实施例中使用关键字Response来代表该步骤；

第四步为Client收到被测反向代理转发的来自Server端的Response报文，Client收到后执行相应报文检查，本申请实施例中使用关键字ClientCheck来代表该步骤。

相应的，图6所示的报文交互过程，就相当于可以拆分成上述第一步和第四步。通过指定的关键字，及相应关键字附带报文内容信息，可以完整的描述本步骤内报文发送的特征和内容。其中，对于发送请求消息或者响应消息的步骤而言，关键字附带的报文内容信息包括本端发送报文的格式、内容；对于进行报文内容检查的步骤而言，关键字附带的报文内容信息中还包括期望接收到的发自对端的报文内容。当然，以上关键字可以使用其他词汇来替代。

通过上述格式化定义，图4中的案例场景可以描述如下：

可见，该格式化描述方法能够精细控制HTTP报文细节设置，使用格式化描述语言完成对案例场景中报文交互内容的描述，降低了案例场景提交者的编程语言门槛，可读性高，利于大范围推广使用。并且通过对关键字的排列和堆砌，还可以自由设置场景案例的报文逻辑交互流程，从而方便验证和探查各种不同复杂场景下被测反向代理对RFC2616等标准协议的支持程度。例如：图8中所述案例场景如下：Client发送3次请求，第一次请求时，发送第一请求消息时期望被测反向代理miss，反向代理想Server端发送第二请求消息，Server端回复第一响应消息，反向代理再向客户端返回第二响应消息；第二次请求时，发送第二请求消息，期望能够从被测反向代理返回的第三响应消息中获取Response报文内容；第三次请求时，发送第四请求消息，更改Request请求报文中附带信息内容，期望从被测代理的第四响应消息中获得不同于第二次请求的变更后的Response报文。也就是说，一个案例场景中，同一步骤可以出现多次，用于描述复杂的案例场景。

当然，按照上述格式化描述方式编写的案例场景描述文件，无法直接被操作系统识别，需要编译成能够被系统识别的可执行文件；然而常规的编程语言编译系统无法对这种格式化的描述文件进行编译，因此，本申请实施例中还提供了一种对案例场景描述文件进行编译的方法，参见图9，该方法可以包括：

S901：接收案例场景描述文件，所述描述文件中，通过多个步骤描述案例场景，每一步骤用对应的关键字以及附带的报文内容信息表示；所述附带的报文内容信息包括本端发送报文的格式、内容以及期望接收到的发自对端的报文内容；

案例场景设计人员按照本申请实施例中的格式化描述方式完成案例场景描述文件的编写之后，可以通过web页面或者命令行等方式提交到测试系统中。需要说明的是，本申请实施例中的案例场景描述文件也可以是自动生成的，也即自动化案例场景提交者可以通过编写自动化脚本，运行于线上系统，用于巡检当前线上系统是否有HTTP异常访问存在，一旦发现有异常访问/响应发生，则自动抽取交互报文，形成案例场景描述文件提交。全部案例场景描述文件均可以提交至固态可分布式存取系统中，例如GIT或SVN库；在需要进行某次具体的测试时，测试人员可以从GIT或SVN库中获取案例场景描述文件列表，从中选择测试所需的案例场景描述文件。

S902：创建可执行文件，初始状态下，所述可执行文件为空；

在选择出所需的案例场景描述文件之后，就可以对描述文件进行编译，在编译过程中，可以首先创建一个空的可执行文件。同时还可以向可执行文件中填充基础信息，包括且不限于案例场景描述、步骤描述（主要是指对步骤的注释）、用户信息、导入可执行程序依赖库等。这里的可执行程序依赖库是指与框架语言相关的一些软件库。

S903：从所述案例场景描述文件中读取各个关键字以及各自附带的报文内容信息；

在创建了空的可执行文件之后，可以从描述文件中读取关键字以及各自附带的报文内容信息。其中，可以首先读取关键字，如果关键字不存在则可以结束程序；如果关键字存在，还可以检查该关键字是否合法，即是否符合场景步骤中定义的关键字，若不合法，则程序返回出错信息。若关键字合法，则从描述文件中继续读取该关键字附带的报文内容信息。

S904：以所述关键字为函数名，所述附带的报文内容信息为函数参数，写入所述可执行文件，以便生成所述案例场景可执行文件。

对于读取到的关键字以及附带的报文内容信息，可以以关键字为函数名，以其附带的报文内容信息为函数参数，写入可执行文件。然后再读取其他的关键字及其附带的报文内容信息，再将心读取到的关键字作为函数名，附带的报文内容信息为函数参数，写入可执行文件，直到将案例场景描述文件中的关键字全部遍历一遍，最终就可以生成案例场景可执行文件。

生成了案例场景可执行文件之后，就可以交由测试执行模块，按照案例场景描述文件中描述的各个步骤来执行具体的测试过程。

需要说明的是，在使用本申请实施例提供的格式化描述方式对案例场景描述文件进行描述之后，可以便于测试系统识别出各个步骤的含义，而一个标准的步骤中，其所需附带的报文内容信息中有一些描述信息（例如协议中的字段等）一般具有协议规定的必须的字段或者取值，因此，在本申请实施例中，对于这些标准的描述信息而言，案例场景的提交者可以不必填写，本申请实施例的测试系统可以提供相应的智能补齐模块，在根据关键词识别出步骤的含义的基础上，实现一些标准化描述信息的自动化填写，从而提高案例场景提交者的描述文件编写效率。

具体实现时，参见图10，智能补全的过程可以包括以下步骤：

S1001：检查关键字附带的报文内容信息中必须的字段是否存在；例如检查Request关键字中content-length头部是否存在；

S1002：如果该必须的字段存在，则检查该字段对应的value值是否存在；

S1003：如果该字段对应的value值不存在，则利用预知的默认值进行填充；

如果该字段对应的value值存在，则相当于案例提交者已经提供了该字段的值，因此该字段的值不需要进行补全，可以继续检查其他关键字。需要说明的是，此处并不检查value值的正确性，因为案例场景允许用户故意设置错误的value值用以检查现实网络中报文内容遭篡改后反向代理的处理逻辑。

S1004：如果所述必须的字段不存在，则检查与所述必须的字段具有同等效用的字段是否存在；

例如假设content-length报文头部不存在，则可以检查可替代的header token是否存在，即检查与必须的header token具有同等效用的其他header token是否存在；例如，可以检查Transfer-encoding是否存在。

当然，如果所述必须的字段不存在，也可以直接用预知的默认字段及其取值来进行填充。

S1005：如果所述同等效用的字段存在，则检查该同等效用的字段对应的值是否存在；

如果同等效用的字段存在，则直接使用该同等效用的字段。

S1006：如果该同等效用的字段对应的值不存在，则利用预知的默认值进行填充；

如果该同等效用的字段对应的value值存在，则相当于案例提交者已经提供了该字段的值，因此该字段的值不需要进行补全。

S1007：如果所述同等效用的字段不存在，则利用预知的默认字段名以及对应的值进行填充。

例如步骤S1004中检查发现可替代的header token不存在，例如Transfer-encoding不存在，则程序自动利用默认的header token和value值进行填充补齐。其中，默认值可以用户配置指定，例如content-length默认值为Request关键字中body字段内容的长度，等等。总之，通过自动智能补全的方式，可以实现在确保不改变描述文件测试执行目的的同时，确保报文内容符合协议要求。

另外，本申请实施例中还可以包括一个逻辑发现模块，也即除了可以识别出单独某个步骤的含义之外，本申请实施例中的逻辑发现模块还可以根据各个步骤的关键字，识别出各个步骤之间的逻辑关系，也即确定出各个步骤上下文之间的依赖关系。这样，在前述智能补全模块中对各个步骤中的字段以及对应的取值进行补全时，就可以根据这种依赖关系来确定需要补全哪些字段以及对应的取值。例如，假设某案例场景中包含步骤一以及步骤二，而根据经验等可知这两个步骤之间存在依赖关系，并且在步骤一出现的情况下，步骤二中所必须的字段以及对应的取值是固定的，则针对该步骤二中附带的报文内容信息，就可以根据这种依赖关系来确定需要补全的字段以及对应的取值。也就是说，在进行智能补全的过程中，可以不仅仅依据本步骤的含义确定需要补全的字段以及取值，还可以依据与上下文其他步骤之间的依赖关系进行确定，这样可以使得补全的结果更能真实反映出案例场景需要。或者，在实际应用中，由于根据上下文之间的依赖关系，能够获知各个步骤中填充哪些字段以及取值能够更真实地反映出案例场景的需要，因此，还可以对步骤中已经填充的字段或者其取值进行修改。也就是说，如果案例场景提交者已经填充了某步骤的某字段的某取值，但是经过上下文依赖关系分析发现，该取值并不能真实反映案例场景的需要，因此，还可以将其修改成更能真实反映案例场景需要的取值。

此外，测试执行模块在执行多个可执行文件时，通常需要根据描述文件场景来调整测试环境，以符合描述文件的测试预设条件；其中包括被测反向代理缓存清空、重启、配置更新、缓存数据预填充等等。因此，测试系统中还可以包括一个测试环境调整模块，用以完成上述对反向代理进行的各种调整操作。

与本申请实施例一提供的对反向代理软件进行测试的方法相对应，本申请实施例还提供了一种对反向代理软件进行测试的系统，参见图11，该系统可以包括：

测试启动单元1101，用于接收到案例场景可执行文件后，按照所述案例场景可执行文件启动测试；

第一报文内容检查单元1102，用于当客户端节点向反向代理节点发送第一请求消息、反向代理节点向服务器节点发送携带有所述第一请求消息的报文内容的第二请求消息时，按照所述案例场景可执行文件，驱动所述服务器节点通过预先在客户端节点与服务器节点之间建立的消息通道，向所述客户端节点获取所述第一请求消息的原始报文内容；其中，所述反向代理节点中部署有被测反向代理软件；

第一变更信息获取单元1103，用于获取所述第二请求消息中携带的第一请求消息的报文内容相对于所述第一请求消息的原始报文内容发生的第一变更信息；

第一提示单元1104，用于根据所述案例场景可执行文件，判断所述第一变更信息是否符合预置的期望信息，如果不符合，则提供第一提示信息。

具体实现时，该系统还可以包括：

第一获取或重置单元，用于按照所述案例场景可执行文件，驱动所述服务器节点通过所述消息通道向客户端节点发送信号，获取或重置客户端节点的工作状态。

另外，该系统还可以包括：

继续执行单元，用于如果所述第一变更信息符合预置的期望信息，则按照所述案例场景可执行文件继续执行测试；

第二报文内容检查单元，用于当服务器节点向反向代理节点返回第一响应消息、反向代理节点向客户端节点返回携带有所述第一响应消息的报文内容的第二响应消息时，按照所述案例场景可执行文件，驱动所述客户端节点通过所述消息通道向所述服务器节点获取所述第一响应消息的原始报文内容；

第二变更信息获取单元，用于获取所述第二响应消息中携带的第一响应消息的报文内容相对于所述第一响应消息的原始报文内容发生的第二变更信息；

第二提示单元，用于根据所述案例场景可执行文件，判断所述第二变更信息是否符合预置的期望信息，如果不符合，提供第二提示信息。

此外，该系统还可以包括：

第二获取或重置单元，用于按照所述案例场景可执行文件，驱动所述客户端节点通过所述消息通道向服务器节点发送信号，获取或重置服务器节点的工作状态。

为了能够获得更准确的测试结果，该系统还可以包括：

自动驱动单元，用于当有消息从上一节点发送到当前节点时，自动驱动当前节点通过预先在上一节点与当前节点之间建立的消息通道，获取上一节点发出的消息的报文内容；所述消息包括请求消息或者响应消息；

数据一致性检查单元，用于判断当前节点接收到的消息报文内容与上一节点发出的消息的报文内容是否一致，如果不一致，则提供第三提示信息。

为了能够降低案例场景提交者的门槛，提高工作效率，该系统还可以包括：

描述文件接收单元，用于接收案例场景描述文件，所述描述文件中，通过多个步骤描述案例场景，每一步骤用对应的关键字以及附带的报文内容信息表示；

可执行文件创建单元，用于创建可执行文件，初始状态下，所述可执行文件为空；

读取单元，用于从所述案例场景描述文件中读取各个关键字以及各自附带的报文内容信息；

可执行文件生成单元，用于以所述关键字为函数名，所述附带的报文内容信息为函数参数，写入所述可执行文件，以便生成所述案例场景可执行文件。

其中，所述多个步骤包括客户端节点向反向代理节点发出请求消息、服务器节点收到反向代理节点发送的请求消息后执行报文内容检查、服务器节点向反向代理节点发送响应消息、客户端节点收到反向代理节点发送的响应消息后执行报文内容检查。其中，对于发送请求消息或者响应消息的步骤而言，关键字附带的报文内容信息包括本端发送报文的格式、内容；对于进行报文内容检查的步骤而言，关键字附带的报文内容信息中还包括期望接收到的发自对端的报文内容。

另外，同一步骤在同一案例场景描述文件中可以出现一次或多次，因此可以描述各种复杂的案例场景。

为了进一步提高效率，该系统还可以包括：

智能补全单元，用于对案例场景描述文件关键字附带的报文内容信息进行补全。

其中，智能补全单元具体可以包括：

第一检查子单元，用于检查关键字附带的报文内容信息中必须的字段是否存在；

第二检查子单元，用于如果所述必须的字段存在，则检查该字段对应的值是否存在；

第一填充子单元，用于如果该字段对应的值不存在，则利用预知的默认值进行填充。

另外，智能补全单元还可以包括：

第三检查子单元，用于如果所述必须的字段不存在，则检查与所述必须的字段具有同等效用的字段是否存在；

第四检查子单元，用于如果所述同等效用的字段存在，则检查该同等效用的字段对应的值是否存在；

第二填充子单元，用于如果该同等效用的字段对应的值不存在，则利用预知的默认值进行填充；

第三填充子单元，用于如果所述同等效用的字段不存在，则利用预知的默认字段名以及对应的值进行填充。

此外，该系统还可以包括：

依赖关系确定单元，用于根据所述案例场景描述文件中的关键字确定各个步骤上下文之间的依赖关系；

补全信息确定单元，用于根据所述依赖关系确定各个关键字附带的报文内容信息中需要补全的字段以及对应的取值。

或者，该系统还可以包括：

依赖关系确定单元，用于根据所述案例场景描述文件中的关键字确定各个步骤上下文之间的依赖关系；

判断单元，用于根据所述依赖关系判断各个关键字附带的报文内容信息中已经写入的信息是否真实反映场景需要；

修改单元，用于如果不能真实反映场景需要，则对所述报文内容信息中已经写入的信息进行修改。

与本申请实施例二提供的对反向代理软件进行测试的方法相对应，本申请实施例还提供了一种对反向代理软件进行测试的系统，参见图12，该系统可以包括：

测试启动单元1201，用于接收到案例场景可执行文件后，按照所述案例场景可执行文件启动测试；

第三报文内容检查单元1202，用于当客户端节点向反向代理节点发送第三请求消息、反向代理节点根据缓存的报文内容返回响应消息时，按照所述案例场景可执行文件，驱动所述客户端节点通过预先在客户端节点与服务器节点之间建立的消息通道，查询服务器节点是否收到发自反向代理节点的第四请求消息，并向所述服务器节点获取针对所述第三请求消息的响应消息的原始报文内容；其中，所述反向代理节点中部署有被测反向代理软件；

第四提示单元1203，用于如果服务器节点收到了发自反向代理节点的第二请求消息，则提供第四提示信息；

第三变更信息获取单元1204，用于获取所述反向代理节点返回的响应消息的报文内容相对于所述原始报文内容发生的变更信息；

第五提示单元1205，用于根据所述案例场景可执行文件，判断所述变更信息是否符合预置的期望信息，如果不符合，则提供第五提示信息

总之，通过本申请实施例，使得服务器端在收到反向代理节点发送的第二请求消息之后，可以进行报文内容检查，也即通过预先建立的专用的消息通道，向客户端索取第一请求消息的原始报文信息，然后将第二请求消息中携带的第一请求消息的报文内容与原始报文内容进行比对，找出其中发生变更之处，并与案例场景文件中写明的期望信息进行比对，便可以确定反向代理软件在此次转发过程中，是否对报文内容进行了不符合用户期望的变更，也即，反向代理软件是否满足协议一致性的要求。因此，通过这种方式，可以有效地检测出反向代理软件可能存在的问题。并且，客户端节点与服务器节点之间传送消息的原始报文内容时，可以通过专用的消息通道来进行，从而实现将报文内容与消息/信号的传递隔离开来，分别形成数据层面和控制层面，这样既可以保证数据报文的安全准确，又可以保证消息/信号的高效传递。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的对反向代理软件进行测试的方法及系统，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。

Claims (16)

1.一种对反向代理软件进行测试的方法，其特征在于，包括：

接收到案例场景可执行文件后，按照所述案例场景可执行文件启动测试；

当客户端节点向反向代理节点发送第一请求消息、反向代理节点向服务器节点发送携带有所述第一请求消息的报文内容的第二请求消息时，按照所述案例场景可执行文件，驱动所述服务器节点通过预先在客户端节点与服务器节点之间建立的消息通道，向所述客户端节点获取所述第一请求消息的原始报文内容；其中，所述反向代理节点中部署有被测反向代理软件；

获取所述第二请求消息中携带的第一请求消息的报文内容相对于所述第一请求消息的原始报文内容发生的第一变更信息；

根据所述案例场景可执行文件，判断所述第一变更信息是否符合预置的期望信息，如果不符合，则提供第一提示信息。

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

按照所述案例场景可执行文件，驱动所述服务器节点通过所述消息通道向客户端节点发送信号，获取或重置客户端节点的工作状态。

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

如果所述第一变更信息符合预置的期望信息，则按照所述案例场景可执行文件继续执行测试；

当服务器节点向反向代理节点返回第一响应消息、反向代理节点向客户端节点返回携带有所述第一响应消息的报文内容的第二响应消息时，按照所述案例场景可执行文件，驱动所述客户端节点通过所述消息通道向所述服务器节点获取所述第一响应消息的原始报文内容；

获取所述第二响应消息中携带的第一响应消息的报文内容相对于所述第一响应消息的原始报文内容发生的第二变更信息；

根据所述案例场景可执行文件，判断所述第二变更信息是否符合预置的期望信息，如果不符合，提供第二提示信息。

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

按照所述案例场景可执行文件，驱动所述客户端节点通过所述消息通道向服务器节点发送信号，获取或重置服务器节点的工作状态。

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

当有消息从上一节点发送到当前节点时，自动驱动当前节点通过预先在上一节点与当前节点之间建立的消息通道，获取上一节点发出的消息的报文内容；所述消息包括请求消息或者响应消息；

判断当前节点接收到的消息报文内容与上一节点发出的消息的报文内容是否一致，如果不一致，则提供第三提示信息。

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

接收案例场景描述文件，所述描述文件中，通过多个步骤描述案例场景，每一步骤用对应的关键字以及附带的报文内容信息表示；

创建可执行文件，初始状态下，所述可执行文件为空；

从所述案例场景描述文件中读取各个关键字以及各自附带的报文内容信息；

以所述关键字为函数名，所述附带的报文内容信息为函数参数，写入所述可执行文件，以便生成所述案例场景可执行文件。

7.根据权利要求6所述的方法，其特征在于，所述多个步骤包括客户端节点向反向代理节点发出请求消息、服务器节点收到反向代理节点发送的请求消息后执行报文内容检查、服务器节点向反向代理节点发送响应消息、客户端节点收到反向代理节点发送的响应消息后执行报文内容检查；其中，对于发送请求消息或者响应消息的步骤而言，关键字附带的报文内容信息包括本端发送报文的格式、内容；对于进行报文内容检查的步骤而言，关键字附带的报文内容信息中还包括期望接收到的发自对端的报文内容。

8.根据权利要求7所述的方法，其特征在于，同一步骤在同一案例场景描述文件中出现一次或多次。

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

对案例场景描述文件关键字附带的报文内容信息进行补全。

10.根据权利要求9所述的方法，其特征在于，所述对案例场景描述文件关键字附带的报文内容信息进行补全，包括：

检查关键字附带的报文内容信息中必须的字段是否存在；

如果所述必须的字段存在，则检查该字段对应的值是否存在；

如果该字段对应的值不存在，则利用预知的默认值进行填充。

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

如果所述必须的字段不存在，则检查与所述必须的字段具有同等效用的字段是否存在；

如果所述同等效用的字段存在，则检查该同等效用的字段对应的值是否存在；

如果该同等效用的字段对应的值不存在，则利用预知的默认值进行填充；

如果所述同等效用的字段不存在，则利用预知的默认字段名以及对应的值进行填充。

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

根据所述案例场景描述文件中的关键字确定各个步骤上下文之间的依赖关系；

根据所述依赖关系确定各个关键字附带的报文内容信息中需要补全的字段以及对应的取值。

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

根据所述案例场景描述文件中的关键字确定各个步骤上下文之间的依赖关系；

根据所述依赖关系判断各个关键字附带的报文内容信息中已经写入的信息是否真实反映场景需要；

如果不能真实反映场景需要，则对所述报文内容信息中已经写入的信息进行修改。

14.一种对反向代理软件进行测试的方法，其特征在于，包括：

接收到案例场景可执行文件后，按照所述案例场景可执行文件启动测试；

当客户端节点向反向代理节点发送第三请求消息、反向代理节点根据缓存的报文内容返回响应消息时，按照所述案例场景可执行文件，驱动所述客户端节点通过预先在客户端节点与服务器节点之间建立的消息通道，查询服务器节点是否收到发自反向代理节点的第四请求消息，并向所述服务器节点获取针对所述第三请求消息的响应消息的原始报文内容；其中，所述反向代理节点中部署有被测反向代理软件；

如果服务器节点收到了发自反向代理节点的第二请求消息，则提供第四提示信息；

获取所述反向代理节点返回的响应消息的报文内容相对于所述原始报文内容发生的变更信息；

根据所述案例场景可执行文件，判断所述变更信息是否符合预置的期望信息，如果不符合，则提供第五提示信息。

15.一种对反向代理软件进行测试的系统，其特征在于，包括：

测试启动单元，用于接收到案例场景可执行文件后，按照所述案例场景可执行文件启动测试；

第一报文内容检查单元，用于当客户端节点向反向代理节点发送第一请求消息、反向代理节点向服务器节点发送携带有所述第一请求消息的报文内容的第二请求消息时，按照所述案例场景可执行文件，驱动所述服务器节点通过预先在客户端节点与服务器节点之间建立的消息通道，向所述客户端节点获取所述第一请求消息的原始报文内容；其中，所述反向代理节点中部署有被测反向代理软件；

第一变更信息获取单元，用于获取所述第二请求消息中携带的第一请求消息的报文内容相对于所述第一请求消息的原始报文内容发生的第一变更信息；

第一提示单元，用于根据所述案例场景可执行文件，判断所述第一变更信息是否符合预置的期望信息，如果不符合，则提供第一提示信息。

16.一种对反向代理软件进行测试的系统，其特征在于，包括：

测试启动单元，用于接收到案例场景可执行文件后，按照所述案例场景可执行文件启动测试；

第三报文内容检查单元，用于当客户端节点向反向代理节点发送第三请求消息、反向代理节点根据缓存的报文内容返回响应消息时，按照所述案例场景可执行文件，驱动所述客户端节点通过预先在客户端节点与服务器节点之间建立的消息通道，查询服务器节点是否收到发自反向代理节点的第四请求消息，并向所述服务器节点获取针对所述第三请求消息的响应消息的原始报文内容；其中，所述反向代理节点中部署有被测反向代理软件；

第四提示单元，用于如果服务器节点收到了发自反向代理节点的第二请求消息，则提供第四提示信息；

第三变更信息获取单元，用于获取所述反向代理节点返回的响应消息的报文内容相对于所述原始报文内容发生的变更信息；

第五提示单元，用于根据所述案例场景可执行文件，判断所述变更信息是否符合预置的期望信息，如果不符合，则提供第五提示信息。