CN102855182A - 一种Web***测试方法及装置 - Google Patents

Abstract

本申请公开了一种Web***测试方法及装置。一种Web***测试方法包括：接收测试用例的执行触发，所述测试用例为针对被测***的测试用例；根据所述测试用例中所包含的运行于非被测***的流程，选择与所述运行于非被测***的流程所对应的流程封装包，并利用所选择的流程封装包构成测试序列；所述流程封装包内，包括基于网络协议进行封装的针对非被测***的操作；执行所述测试序列；将测试序列的执行结果转换为被测***可识别的信息。应用上述方案预先将与被测***无关的操作流程以网络协议的形式封装起来，通过执行流程封装包自动从其他的***获得测试所需的数据或状态，以避免或减少测试人员对这些与测试对象无关第三方***的操作，提高整体测试效率。

Description

一种Web***测试方法及装置

技术领域

本申请涉及互联网应用技术领域，特别是涉及一种Web***测试方法及装置。

背景技术

在网站的开发和调试过程中，对开发内容的测试工作尤其重要。目前，很多网站的功能变得越来越完善，相应的测试工作也就变得更为复杂。面对日益复杂的测试需求，相应也出现了很多种自动化测试工具，以提高测试效率。

现有技术中，一种常用的Web自动化测试方法是基于页面元素操控的自动化测试方法，这种方法通过录制分析、代码定位等手段操控网页元素，来达到模拟用户操作的目的，这类测试工具包括Selenium、Watir等。

但是，这种测试方法存在的问题是：需要模拟完整的用户操作流程，即便对于测试者并不关心的部分，也必须在测试用例中实现。例如，对于电子商务应用，当前需要对第三方的中介支付***进行测试，由于支付***本身要和各种外部***打交道，例如购物网站***、网上银行***等等，这些***内部的操作是支付***所不必关心的，对于支付***的测试而言，需要关心的内容是其自身内部的核心逻辑，以及与这些外部***之间的接口，但是在实际的测试过程中，测试人员往往先要在这些外部***进行许多操作，才能完成测试前的准备，以走到预期的逻辑测试分支。

可见，现有的基于页面元素操控的自动化测试方法，应用于较大规模的Web测试时，往往需要浪费大量的时间和人力在测试本身并不关注的部分，从而导致整体的测试效率低下。

发明内容

为解决上述技术问题，本申请实施例提供一种Web***测试方法及装置，以提高测试效率，技术方案如下：

本申请提供一种Web***测试方法，包括：

接收测试用例的执行触发，所述测试用例为针对被测***的测试用例；

根据所述测试用例中所包含的运行于非被测***的流程，选择与所述运行于非被测***的流程所对应的流程封装包，并利用所选择的流程封装包构成测试序列；所述流程封装包内，包括基于网络协议进行封装的针对非被测***的操作；

执行所述测试序列；

将测试序列的执行结果转换为被测***可识别的信息。

根据本申请的一种实现方式，在构成测试序列之后，还包括：

在测试序列中添加测试参数。

根据本申请的一种实现方式，所述在测试序列中添加测试参数，包括：

利用所述测试用例中定义的测试参数，和/或当前已完成测试进程所获得的结果，向流程封装包中的操作传递测试参数。

根据本申请的一种实现方式，所述在测试序列中添加测试参数，包括：

为流程封装包中的操作随机生成测试参数。

根据本申请的一种实现方式，所述将测试序列的执行结果转换为被测***可识别的信息，包括：

创建用于模拟用户在被测***的登录状态cookie；

根据测试序列的执行结果，获得与所创建cookie相对应的用户历史行为信息。

根据本申请的一种实现方式，在将测试序列的执行结果转换为被测***可识别的信息之后，还包括：

将转换后的信息发送至被测***，以继续执行测试用例。

本申请还提供一种Web***测试装置，包括：

测试用例触发模块，用于接收测试用例的执行触发，所述测试用例为针对被测***的测试用例；

测试序列构成模块，用于根据所述测试用例中所包含的运行于非被测***的流程，选择与所述运行于非被测***的流程所对应的流程封装包，并利用所选择的流程封装包构成测试序列；所述流程封装包内，包括基于网络协议进行封装的针对非被测***的操作；

测试序列执行模块，用于执行所述测试序列；

执行结果转换模块，用于将测试序列的执行结果转换为被测***可识别的信息。

根据本申请的一种实现方式，上述装置还包括：

测试参数添加模块，用于在所述测试序列构成模块构成的测试序列中添加测试参数。

根据本申请的一种实现方式，所述测试参数添加模块，包括：

测试参数传递单元，用于利用所述测试用例中定义的测试参数，和/或当前已完成测试进程所获得的结果，向流程封装包中的操作传递测试参数。

根据本申请的一种实现方式，所述测试参数添加模块，包括：

测试参数生成单元，用于为流程封装包中的操作随机生成测试参数。

根据本申请的一种实现方式，所述执行结果转换模块，包括：

cookie创建单元，用于创建用于模拟用户在被测***的登录状态cookie；

信息获得单元，用于根据测试序列的执行结果，获得与所创建cookie相对应的用户历史行为信息。

根据本申请的一种实现方式，，所述装置还包括：

信息发送模块，用于在所述执行结果转换模块将测试序列的执行结果转换为被测***可识别的信息之后，将转换后的信息发送至被测***，以继续执行测试用例。

本申请实施例所提供的技术方案，针对测试的具体需求，预先将大量与被测***无关的操作流程以网络协议的形式封装起来，当在测试过程中需要调用这些操作时，直接利用流程封装包构成测试序列并执行，从而能够自动从其他的***获得测试所需的数据或状态，以避免或减少测试人员对这些与测试对象无关第三方***的操作，提高整体的测试效率。

附图说明

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

图1为本申请实施例的测试体系结构示意图；

图2为本申请实施例的Web***测试方法的一种流程图；

图3为本申请实施例的Web***测试方法的第二种流程图；

图4为本申请实施例的Web***测试方法的第三种流程图；

图5为本申请实施例的Web***测试装置的一种结构示意图；

图6为本申请实施例的Web***测试装置的第二种结构示意图；

图7为本申请实施例的Web***测试装置的第三种结构示意图。

具体实施方式

首先对本申请实施例所提供的一种Web***测试方法进行说明，该方法可以包括以下步骤：

接收测试用例的执行触发，所述测试用例为针对被测***的测试用例；

根据所述测试用例中所包含的运行于非被测***的流程，选择与所述运行于非被测***的流程所对应的流程封装包，并利用所选择的流程封装包构成测试序列；所述流程封装包内，包括基于网络协议进行封装的针对非被测***的操作；

执行所述测试序列；

将测试序列的执行结果转换为被测***可识别的信息。

上述步骤的执行主体，可以是一个能够与被测***和非被测***进行通信的测试装置，图1所示为根据本申请实施例的测试体系结构示意图，其中测试装置100是针对被测***200设置，目的是实现对被测***200的自动化测试。同时，测试装置100还可以与一个或多个非被测***300(如图1所示的非被测***a、非被测***b......非被测***n)进行交互，主要目的是触发测试流程中需要运行于这些非被测***300的操作，将运行这些操作的请求发送至对应的非被测***300，并且从非被测***300获得这些操作的运行结果，从而得到对于被测***100进行测试所需的数据或状态。

在实际应用中，测试装置100与被测***200可以位于同一实体中，例如被测***200所在的服务器；测试装置100也可以是独立于被测***200的实体，例如，采用一独立的测试终端对被测***200所在的服务器进行测试，该测试终端与被测***200可以直接连接或通过网络进行连接。

此外，在实际应用中，被测***200与各个非被测***300一般对应着网络中的不同***，例如电子商务应用中所涉及的购物网站***、中介支付***、网上银行***等等，测试装置100一般是通过网络与各个非被测***300连接，而在流程封装包中所封装的都是针对非被测***的操作，因此这些操作需要基于一定的网络协议进行封装。常用的方式是基于HTTP(HyperText Transfer Protocol，超文本传输协议)对操作进行封装，当然也可以采用其他的方式进行封装，例如基于RPC(Remote Procedure Call Protocol，远程过程调用协议)、Socket通信等方式进行封装等等，本申请实施例对此并不需要进行限定。

本申请实施例所提供的Web***测试方法，针对测试的具体需求，预先将大量与被测***无关的操作流程以网络协议的形式封装起来，当在测试过程中需要调用这些操作时，直接利用流程封装包构成测试序列并执行，从而能够自动从其他的***获得测试所需的数据或状态，以避免或减少测试人员对这些与测试对象无关第三方***的操作，提高整体的测试效率。

为了使本技术领域的人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行详细地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都应当属于本申请保护的范围。

图2所示为本申请所提供的一种Web***测试方法的流程示意图，该方法可以包括以下步骤：

S101，接收测试用例的执行触发；

根据具体的测试需求，测试人员可以将设计好的各种测试用例输入测试装置，并且触发测试装置执行该测试用例。当然，测试用例内容也可以预先保存于测试装置中，这种情况下，测试人员在本步骤中，仅需要向测试装置输入一个触发条件，以触发某个测试用例的执行。在实际的Web***中，对应触发条件可以是点击Web页面的某个页面元素，例如连接、按钮等等。

目前，很多大规模的Web中，往往需要由多个***进行协作而实现的，而且从***开发的角度而言，这些***的开发一般也是独立的，测试只是针对其中的某一个***而言。因此，这里所提到的测试用例，尽管在其内容中可能涉及针对多个***的操作，但是测试的目的是针对某一个特定的***，在本申请实施例中，将这个特定的***成为被测***，将测试用例中所涉及的其他***称为非被测***。

例如，在电子商务应用中，一个基本的网上交易流程需要涉及购物网站***、中介支付***、网上银行***三个***。这些***本身就是由不同的机构开发并运营的。假设当前需要测试其中的中介支付***是否能够正常实现其在网上交易流程中的功能，则中介支付***即为当前的被测***。另一方面，为了模拟一个完整的网上交易流程，在针对中介支付***的测试用例中，可能需要包含对购物网站***和网上银行***的调用，然而这些部分并不是测试所真正关心的，因此这里将购物网站***和网上银行***称为非被测***。

S102，根据所述测试用例中所包含的运行于非被测***的流程，选择相应的流程封装包，并利用所选择的流程封装包构成测试序列；

在测试用例中定义了若干流程，其中一部分是仅需要在当前的被测***运行的(以下简称为A类流程)，另一部分则需要运行于非被测***(以下简称为B类流程)。对于当前的测试而言，真正关注的是A类流程，但是为了让被测***达到可以运行A类流程的状态，往往需要首先执行一个或多个B类流程。也就是说，可以将B类流程看作是运行A类流程的先序条件。

在本申请所提供的方案中，针对需要运行于非被测***的流程，预先将一个或多个操作进行封装，组成若干的流程封装包存储于测试装置内，在测试过程中，这些流程封装包可以直接被调用，当一个流程封装包被调用时，测试***将按照流程封装包的内容顺序执行其中定义的各种操作。通过调用这些封装包，可以快速实现先序条件，使被测***达到可以运行A类流程的状态。

仍以电子商务应用为例进行说明，假设当前是要针对支付***进行测试，然而在执行“支付”的相关操作之前，首先需要存在购买行为，为例实现购买行为，又进一步需要存在买方用户、卖方用户、商品等等，而获得这些状态的操作，都是要在购物网站***完成的。因此，可以根据实际的需求，将这些运行于购物网站***的操作进行封装。

例如，对于“卖方用户发布商品”这一流程，其包括以下4种操作：

1)卖方用户登陆

2)卖方用户开店

3)卖方用户创建商品信息

4)卖方用户将商品上架

由于“发布商品”这一操作在各种测试中的复用程度很高，因此可以直接将上面种操作封装起来，构成一个“发布商品”的封装包。当这个封装包被调用时，会自动顺序执行上述4种操作，并且产生一个商品的ID，也即相当于完成了“发布商品”的流程。

当然，除了“发布商品”之外，例如“买方用户购买商品”、“买方用户退货”等流程都可以分别进行封装。具体封装的内容可以根据实际应用的业务需求和测试中的复用程度确定，本申请实施例对此并不需要进行限定。

由于测试装置是通过网络与非被测***连接，而在流程封装包中所封装的都是针对非被测***的操作，因此这些操作需要基于一定的网络协议进行封装，例如利用HTTP、RPC等方式进行封装，本申请实施例对封装的具体实现方式并不需要进行限定。

测试装置在步骤S101接收到测试用例执行触发之后，首先对测试用例的内容进行分析。确定哪些流程是仅需要在当前的被测***运行的(即A类流程)、哪些流程是需要运行于非被测***的(即B类流程)对于B类流程，然后对于B类流程，选择与其对应的一个或多个流程封装包，如果选择了多个封装包，则还应进一步确定这些封装包的执行顺序，然后利用所选择的一个或多个流程封装包构成测试序列。

S103，执行所述测试序列；

在本步骤中，测试装置将执行在步骤S102中所构成的测试序列，如果在测试序列中包含了多个流程封装包，则在前一个流程封装包执行完毕后，其执行结果将被传递至后面的流程封装包。

例如，在一个测试序列中，调用了“卖方用户发布商品”和“买方用户购买商品”两个流程封装包，则在执行完“卖方用户发布商品”这个流程封装包之后，即获得了商品ID，该商品ID和卖方用户ID将被传递至“买方用户购买商品”的流程封装包内，后续执行的“购买”操作即是基于该卖方用户ID和该商品ID进行的操作。“买方用户购买商品”这个流程封装包执行完毕之后，将产生一条交易信息，该信息的具体内容可以包括：买方用户ID、卖方用户ID、商品ID、成交价格、付款方式等等。至此，测试序列执行完毕，因此，这条交易信息也就是整个测试序列的执行结果。

S104，将测试序列的执行结果转换为被测***可识别的信息。

根据前面的描述可知，测试序列中所涉及的操作，实际是在非被测***中执行的。而利用网络协议对各种操作进行封装，可以实现本地的测试装置触发远端的非被测***执行各种操作。测试序列执行完毕之后，执行结果也会返回本地的测试装置。

但是，非被测***所返回的执行结果并不能被直接被被测***所识别。因此在本步骤中，还需要对执行结果进行转换，以保证后续的针对被测***的流程能够继续进行。

由于Web应用一般都是基于浏览器实现的，因此可以利用cookie实现执行结果的转换。Cookie是指网站为了辨别用户身份、进行进程跟踪而储存在用户本地终端上的数据，在本申请实施例中，测试装置在收到非被测***所返回的执行结果后，首先根据执行结果的内容以及后续的测试需要，创建cookie，以模拟用户在被测***的登录状态；然后，进一步根据测试序列的执行结果，获得与所创建cookie相对应的用户历史行为信息，这些信息后续可以用于传递给被测***，以继续在被测***上的测试流程。

例如，当前已获得了购物网站***所返回的一条交易信息，并且需要对买方的支付功能进行测试，则可以根据买方用户的ID，创建cookie，以模拟买方用户在支付***的登录状态，然后，可根据需要，将执行结果中的其他信息传递给支付***，这些信息可以包括例如交易金额、付款方式、卖方用户ID等等，也就是说，将买方用户之前在购物网站***的行为信息，对应于该买方用户的cookie传递给支付***，使得支付***能够识别这名用户之前在购物***中都进行过哪些行为、当前处于什么状态、下一步需要做什么，等等。

其中，将用户历史行为信息传递给被测***，可以采用直接将用户信息写入之前所创建cookie的方式，例如，创建买方用户cookie后，进一步将买方用户的历史行为信息作为参数写入cookie，这样，支付***就可以识别出针对这名买方用户的用于进行后续支付流程的信息。例如：这名买方用户之前与哪位卖方用户达成了交易、当前需要支付多少金额、采用何种支付方式等等。至此，支付***已经获得了一个用户的登录状态，并且获得了支付金额、支付方式、支付对象等数据，满足了对支付功能进行测试的先序条件，后续就可以进一步对支付功能进行测试。

上述传递用户历史行为信息的方法，比较适用于需要传递的信息较少的情况。为了避免cookie文件过大，在本申请的另一种实现方式中，也可以通过URL(Universal Resource Locator，统一资源定位符)携带，将用户历史行为信息传递给被测***，在传递信息的过程中，需要标识出所携带的信息是针对于之前所创建的某个cookie的，这样就可以把用户的行为信息和用户对应起来，以便于被测***进行识别。

当然，本领域技术人员还可以想到其他的用于传递户历史行为信息的方案，例如通过简单的GET、POST命令携带信息发送给被测***，这些方式可以分别独立使用，也可以相互结合使用，本申请实施例对此并不需要进行限定。

可见，应用本申请实施例所提供的Web***测试方法，预先将大量与被测***无关的操作流程以网络协议的形式封装起来，当在测试过程中需要调用这些操作时，直接利用流程封装包构成测试序列并执行，从而能够自动从其他的***获得测试所需的数据或状态，以避免或减少测试人员对这些与测试对象无关第三方***的操作，提高整体的测试效率

参见图3所示，在本申请的另一种实现方式中，所提供的Web***测试方法可以包括以下步骤：

S101，接收测试用例的执行触发；

S102，根据所述测试用例中所包含的运行于非被测***的流程，选择相应的流程封装包，并利用所选择的流程封装包构成测试序列；

S105，在测试序列中添加测试参数；

S103，执行所述测试序列；

S104，将测试序列的执行结果转换为被测***可识别的信息。

与前一实施例相比，本实施例在步骤S102和步骤S103之间增加了新的步骤S105。下面主要对该步骤进行详细描述：

在测试过程中，有时为了实现同一测试流程的不同路径选择，例如，在对买方用户支付功能进行测试的时候，可能需要针对特定的买方用户、特定的卖方用户、特定的商品等等，这种情况下，可以通过在测试序列中添加测试参数的方式来实现。

为测试序列添加测试参数有两种实现方式：一种方式是根据当前已有的数据，向流程封装包中的操作传递测试参数。例如，将测试用例中所定义的测试参数直接传递给流程封装包中的操作；或者，在测试序列执行之前，可能已经完成了一些其他的测试流程，这些流程的所得到的结果，也可以传递给流程封装包中的操作。

另一种测试序列添加测试参数的方式是，由测试装置自动为流程封装包中的操作生成测试参数，由于是要实现对同一测试流程的不同路径选择，因此这里可以采用随机生成测试参数的方式，例如，在每次执行测试序列时，随机生成不同的用户ID、商品ID等，以实现更为全面的测试操作。

相应地，在本实施中，步骤S103中所执行的测试序列应该理解为已添加了测试参数的测试序列。而步骤S101、S102、S104则与前一实施例相同，这里不再重复描述。

参见图4所示，在本申请的另一个实施例中，在步骤S104之后，还可以进一步包括以下步骤：

S106，将转换后的信息发送至被测***，以继续执行测试用例。

步骤104执行完毕之后，实际上已经完成了对被测***进行测试的先序条件的准备。此时可以将所当前在非被测***所获得的状态或数据以被测***可识别的形式发送被测***，以继续执行运行在被测***的测试流程，完成整个测试

S107，对转换后得到的信息进行显示输出。

为了令测试人员可以随时了解测试的进行状况，在步骤104执行完毕之后，也可以将转换后的信息进行显示输出，例如以Web页面的形式进行渲染，以供测试人员通过浏览器查看。

需要说明的是，步骤S106和S107并没有执行的先后顺序，二者可以分别独立执行，也可以同时执行。此外，本领域技术人员可以理解的是，尽管在图4中并未示出，然而在本实施例中也可以包含上一实施例里中的步骤S105。

相应于上面的方法实施例，本申请还提供一种Web***测试装置，该装置对应与图1中所示的测试装置100，参见图5所示，该装置具体可以包括以下模块：

测试用例触发模块110，用于接收测试用例的执行触发，所述测试用例为针对被测***的测试用例；

根据具体的测试需求，测试人员可以将设计好的各种测试用例输入测试装置，并且触发测试装置执行该测试用例。当然，测试用例内容也可以预先保存于测试装置中，这种情况下，测试人员通过向测试用例触发模块110输入一个触发条件，以触发某个测试用例的执行。在实际的Web***中，对应触发条件可以是点击Web页面的某个页面元素，例如连接、按钮等等。

这里所提到的测试用例，尽管在其内容中可能涉及针对多个***的操作，但是测试的目的是针对某一个特定的***，在本申请实施例中，将这个特定的***成为被测***，将测试用例中所涉及的其他***称为非被测***。

测试序列构成模块120，用于根据所述测试用例中所包含的运行于非被测***的流程，选择与所述运行于非被测***的流程所对应的流程封装包，并利用所选择的流程封装包构成测试序列；所述流程封装包内，包括基于网络协议进行封装的针对非被测***的操作；

在测试用例中定义了若干流程，其中一部分是仅需要在当前的被测***运行的(以下简称为A类流程)，另一部分则需要运行于非被测***(以下简称为B类流程)。对于当前的测试而言，真正关注的是A类流程，但是为了让被测***达到可以运行A类流程的状态，往往需要首先执行一个或多个B类流程。也就是说，可以将B类流程看作是运行A类流程的先序条件。

在本申请所提供的方案中，针对需要运行于非被测***的流程，预先将一个或多个操作进行封装，组成若干的流程封装包存储于测试装置内，在测试过程中，这些流程封装包可以直接被调用，当一个流程封装包被调用时，测试***将按照流程封装包的内容顺序执行其中定义的各种操作。通过调用这些封装包，可以快速实现先序条件，使被测***达到可以运行A类流程的状态。

由于测试装置是通过网络与非被测***连接，而在流程封装包中所封装的都是针对非被测***的操作，因此这些操作需要基于一定的网络协议进行封装，例如利用HTTP、RPC等方式进行封装，本申请实施例对封装的具体实现方式并不需要进行限定。

测试序列构成模块120首先对测试用例的内容进行分析。确定哪些流程是仅需要在当前的被测***运行的(即A类流程)、哪些流程是需要运行于非被测***的(即B类流程)，然后对于B类流程，选择与其对应的一个或多个流程封装包，如果选择了多个封装包，则还应进一步确定这些封装包的执行顺序，然后利用所选择的一个或多个流程封装包构成测试序列。

测试序列执行模块130，用于执行所述测试序列；

测试序列执行模块130的作用是执行由测试序列构成模块120所构成的测试序列，如果在测试序列中包含了多个流程封装包，则在前一个流程封装包执行完毕后，其执行结果将被传递至后面的流程封装包。

执行结果转换模块140，用于将测试序列的执行结果转换为被测***可识别的信息。

根据前面的描述可知，测试序列中所涉及的操作，实际是在非被测***中执行的。而利用网络协议对各种操作进行封装，可以实现本地的测试装置触发远端的非被测***执行各种操作。测试序列执行完毕之后，执行结果也会返回本地的测试装置。

但是，非被测***所返回的执行结果并不能被直接被被测***所识别。因此执行结果转换模块140将对执行结果进行转换，以保证后续的针对被测***的流程能够继续进行。

本申请实施例所提供的Web***测试装置，是针对被测***设置，目的是实现对被测***自动化测试。同时，该装置还可以与一个或多个非被测***进行交互，主要目的是触发测试流程中需要运行于这些非被测***的操作，将运行这些操作的请求发送至对应的非被测***，并且从非被测***获得这些操作的运行结果，从而得到对于被测***进行测试所需的数据或状态。

在实际应用中，Web***测试装置与被测***可以位于同一实体中，例如被测***所在的服务器；也可以是独立于被测***的实体，例如，采用一独立的测试终端对被测***所在的服务器进行测试，该测试终端与被测***可以直接连接或通过网络进行连接。此外，一般情况下，该Web***测试装置通过网络与各个非被测***连接。

本申请实施例所提供的Web***测试装置，针对测试的具体需求，预先将大量与被测***无关的操作流程以网络协议的形式封装起来，当在测试过程中需要调用这些操作时，直接利用流程封装包构成测试序列并执行，从而能够自动从其他的***获得测试所需的数据或状态，以避免或减少测试人员对这些与测试对象无关第三方***的操作，提高整体的测试效率。

其中，上述的执行结果转换模块140，具体可以包括：

cookie创建单元，用于创建cookie，以模拟用户在被测***的登录状态；

信息获得单元，用于根据测试序列的执行结果，获得与所创建cookie相对应的用户历史行为信息。

其中，信息获得单元可以用直接将用户信息写入之前所创建cookie的方式，以便后续将用户历史行为信息传递给被测***，也可以通过URL携带、或者通过简单的GET、POST命令携带的方式，将用户历史行为信息传递给被测***。这些方式可以分别独立使用，也可以相互结合使用，本申请实施例对此并不需要进行限定。

参见图6所示，本申请所提供的Web***测试装置，还可以进一步包括：

测试参数添加模块150，用于在所述测试序列构成模块120构成的测试序列中添加测试参数。以实现同一测试流程的不同路径选择

在本申请的一种实施方式中，可以在测试参数添加模块150中配置测试参数传递单元，用于根据当前已有的数据向流程封装包中的操作传递测试参数。例如：利用测试用例中定义的测试参数向流程封装包中的操作传递测试参数，或者利用当前已完成测试进程所获得的结果，向流程封装包中的操作传递测试参数，当然，也可以同时利用上述两种方式向流程封装包中的操作传递测试参数。

在本申请的一种实施方式中，可以在测试参数添加模块150中配置测试参数生成单元，用于为流程封装包中的操作随机生成测试参数。

参见图7所示，本申请所提供的Web***测试装置，还可以包括：

信息发送模块160，用于在所述执行结果转换模块140将测试序列的执行结果转换为被测***可识别的信息之后，将转换后的信息发送至被测***，以继续执行测试用例。

显示输出模块170，用于在所述执行结果转换模块140将测试序列的执行结果转换为被测***可识别的信息之后，对转换后得到的信息进行显示输出。

其中，上述的信息发送模块160和显示输出模块170，可以分别单独配置于Web***测试装置中，也可以同时配置于Web***测试装置中，本申请实施例对此并不需要进行限定。此外，本领域技术人员可以理解的是，尽管在图7中并未示出，然而在本实施例中也可以包含上一实施例里中的测试参数添加模块150，以通过向测试序列中添加测试参数的方式，实现同一测试流程的不同路径选择。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

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

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

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

以上所述仅是本申请的具体实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (12)

1.一种Web***测试方法，其特征在于，包括：

接收测试用例的执行触发，所述测试用例为针对被测***的测试用例；

根据所述测试用例中所包含的运行于非被测***的流程，选择与所述运行于非被测***的流程所对应的流程封装包，并利用所选择的流程封装包构成测试序列；所述流程封装包内，包括基于网络协议进行封装的针对非被测***的操作；

执行所述测试序列；

将测试序列的执行结果转换为被测***可识别的信息。

2.根据权利要求1所述的方法，其特征在于，在构成测试序列之后，还包括：

在测试序列中添加测试参数。

3.根据权利要求2所述的方法，其特征在于，所述在测试序列中添加测试参数，包括：

利用所述测试用例中定义的测试参数，和/或当前已完成测试进程所获得的结果，向流程封装包中的操作传递测试参数。

4.根据权利要求2所述的方法，其特征在于，所述在测试序列中添加测试参数，包括：

为流程封装包中的操作随机生成测试参数。

5.根据权利要求1所述的方法，其特征在于，所述将测试序列的执行结果转换为被测***可识别的信息，包括：

创建用于模拟用户在被测***的登录状态cookie；

根据测试序列的执行结果，获得与所创建cookie相对应的用户历史行为信息。

6.根据权利要求1所述的方法，其特征在于，在将测试序列的执行结果转换为被测***可识别的信息之后，还包括：

将转换后的信息发送至被测***，以继续执行测试用例。

7.一种Web***测试装置，其特征在于，包括：

测试用例触发模块，用于接收测试用例的执行触发，所述测试用例为针对被测***的测试用例；

测试序列构成模块，用于根据所述测试用例中所包含的运行于非被测***的流程，选择与所述运行于非被测***的流程所对应的流程封装包，并利用所选择的流程封装包构成测试序列；所述流程封装包内，包括基于网络协议进行封装的针对非被测***的操作；

测试序列执行模块，用于执行所述测试序列；

执行结果转换模块，用于将测试序列的执行结果转换为被测***可识别的信息。

8.根据权利要求7所述的装置，其特征在于，还包括：

测试参数添加模块，用于在所述测试序列构成模块构成的测试序列中添加测试参数。

9.根据权利要求8所述的装置，其特征在于，所述测试参数添加模块，包括：

测试参数传递单元，用于利用所述测试用例中定义的测试参数，和/或当前已完成测试进程所获得的结果，向流程封装包中的操作传递测试参数。

10.根据权利要求8所述的装置，其特征在于，所述测试参数添加模块，包括：

测试参数生成单元，用于为流程封装包中的操作随机生成测试参数。

11.根据权利要求7所述的装置，其特征在于，所述执行结果转换模块，包括：

cookie创建单元，用于创建用于模拟用户在被测***的登录状态cookie；

信息获得单元，用于根据测试序列的执行结果，获得与所创建cookie相对应的用户历史行为信息。

12.根据权利要求7所述的装置，其特征在于，所述装置还包括：

信息发送模块，用于在所述执行结果转换模块将测试序列的执行结果转换为被测***可识别的信息之后，将转换后的信息发送至被测***，以继续执行测试用例。

Images