一种Web系统测试方法及装置的制作方法

专利名称：一种Web系统测试方法及装置的制作方法
技术领域：
本申请涉及互联网应用技术领域，特别是涉及一种Web系统测试方法及装置。
背景技术：
在网站的开发和调试过程中，对开发内容的测试工作尤其重要。目前，很多网站的功能变得越来越完善，相应的测试工作也就变得更为复杂。面对日益复杂的测试需求，相应也出现了很多种自动化测 试工具，以提高测试效率。现有技术中，一种常用的Web自动化测试方法是基于页面元素操控的自动化测试方法，这种方法通过录制分析、代码定位等手段操控网页元素，来达到模拟用户操作的目的，这类测试工具包括Selenium、Watir等。但是，这种测试方法存在的问题是需要模拟完整的用户操作流程，即便对于测试者并不关心的部分，也必须在测试用例中实现。例如，对于电子商务应用，当前需要对第三方的中介支付系统进行测试，由于支付系统本身要和各种外部系统打交道，例如购物网站系统、网上银行系统等等，这些系统内部的操作是支付系统所不必关心的，对于支付系统的测试而言，需要关心的内容是其自身内部的核心逻辑，以及与这些外部系统之间的接口，但是在实际的测试过程中，测试人员往往先要在这些外部系统进行许多操作，才能完成测试前的准备，以走到预期的逻辑测试分支。可见，现有的基于页面元素操控的自动化测试方法，应用于较大规模的Web测试时，往往需要浪费大量的时间和人力在测试本身并不关注的部分，从而导致整体的测试效率低下。

发明内容
为解决上述技术问题，本申请实施例提供一种Web系统测试方法及装置，以提高测试效率，技术方案如下本申请提供一种Web系统测试方法，包括接收测试用例的执行触发，所述测试用例为针对被测系统的测试用例；根据所述测试用例中所包含的运行于非被测系统的流程，选择与所述运行于非被测系统的流程所对应的流程封装包，并利用所选择的流程封装包构成测试序列；所述流程封装包内，包括基于网络协议进行封装的针对非被测系统的操作；执行所述测试序列； 将测试序列的执行结果转换为被测系统可识别的信息。根据本申请的一种实现方式，在构成测试序列之后，还包括在测试序列中添加测试参数。根据本申请的一种实现方式，所述在测试序列中添加测试参数，包括利用所述测试用例中定义的测试参数，和/或当前已完成测试进程所获得的结果，向流程封装包中的操作传递测试参数。
根据本申请的一种实现方式，所述在测试序列中添加测试参数，包括为流程封装包中的操作随机生成测试参数。根据本申请的一种实现方式，所述将测试序列的执行结果转换为被测系统可识别的信息，包括创建用于模拟用户在被测系统的登录状态cookie ；根据测试序列的执行结果，获得与所创建cookie相对应的用户历史行为信息。根据本申请的一种实现方式，在将测试序列的执行结果转换为被测系统可识别的信息之后，还包括将转换后的信息发送至被测系统，以继续执行测试用例。 本申请还提供一种Web系统测试装置，包括测试用例触发模块，用于接收测试用例的执行触发，所述测试用例为针对被测系统的测试用例；测试序列构成模块，用于根据所述测试用例中所包含的运行于非被测系统的流程，选择与所述运行于非被测系统的流程所对应的流程封装包，并利用所选择的流程封装包构成测试序列；所述流程封装包内，包括基于网络协议进行封装的针对非被测系统的操作；测试序列执行模块，用于执行所述测试序列；执行结果转换模块，用于将测试序列的执行结果转换为被测系统可识别的信息。根据本申请的一种实现方式，上述装置还包括测试参数添加模块，用于在所述测试序列构成模块构成的测试序列中添加测试参数。根据本申请的一种实现方式，所述测试参数添加模块，包括测试参数传递单元，用于利用所述测试用例中定义的测试参数，和/或当前已完成测试进程所获得的结果，向流程封装包中的操作传递测试参数。根据本申请的一种实现方式，所述测试参数添加模块，包括测试参数生成单元，用于为流程封装包中的操作随机生成测试参数。根据本申请的一种实现方式，所述执行结果转换模块，包括cookie创建单元，用于创建用于模拟用户在被测系统的登录状态cookie ；信息获得单元，用于根据测试序列的执行结果，获得与所创建cookie相对应的用户历史行为信息。根据本申请的一种实现方式，，所述装置还包括信息发送模块，用于在所述执行结果转换模块将测试序列的执行结果转换为被测系统可识别的信息之后，将转换后的信息发送至被测系统，以继续执行测试用例。本申请实施例所提供的技术方案，针对测试的具体需求，预先将大量与被测系统无关的操作流程以网络协议的形式封装起来，当在测试过程中需要调用这些操作时，直接利用流程封装包构成测试序列并执行，从而能够自动从其他的系统获得测试所需的数据或状态，以避免或减少测试人员对这些与测试对象无关第三方系统的操作，提高整体的测试效率。


为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。图I为本申请实施例的测试体系结构示意图；图2为本申请实施例的Web系统测试方法的一种流程图；图3为本申请实施例的Web系统测试方法的第二种流程图；图4为本申请实施例的Web系统测试方法的第二种流程图；
图5为本申请实施例的Web系统测试装置的一种结构示意图；图6为本申请实施例的Web系统测试装置的第二种结构示意图；图7为本申请实施例的Web系统测试装置的第三种结构示意图。
具体实施例方式首先对本申请实施例所提供的一种Web系统测试方法进行说明，该方法可以包括以下步骤接收测试用例的执行触发，所述测试用例为针对被测系统的测试用例；根据所述测试用例中所包含的运行于非被测系统的流程，选择与所述运行于非被测系统的流程所对应的流程封装包，并利用所选择的流程封装包构成测试序列；所述流程封装包内，包括基于网络协议进行封装的针对非被测系统的操作；执行所述测试序列；将测试序列的执行结果转换为被测系统可识别的信息。上述步骤的执行主体，可以是一个能够与被测系统和非被测系统进行通信的测试装置，图I所示为根据本申请实施例的测试体系结构示意图，其中测试装置100是针对被测系统200设置，目的是实现对被测系统200的自动化测试。同时，测试装置100还可以与一
个或多个非被测系统300 (如图I所示的非被测系统a、非被测系统b......非被测系统η)
进行交互，主要目的是触发测试流程中需要运行于这些非被测系统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种操作I)卖方用户登陆2)卖方用户开店3)卖方用户创建商品信息
4)卖方用户将商品上架由于“发布商品”这一操作在各种测试中的复用程度很高，因此可以直接将上面种操作封装起来，构成一个“发布商品”的封装包。当这个封装包被调用时，会自动顺序执行上述4种操作，并且产生一个商品的ID，也即相当于完成了 “发布商品”的流程。当然，除了 “发布商品”之外，例如“买方用户购买商品”、“买方用户退货”等流程都可以分别进行封装。具体封装的内容可以根据实际应用的业务需求和测试中的复用程度确定，本申请实施例对此并不需要进行限定。由于测试装置是通过网络与非被测系统连接，而在流程封装包中所封装的都是针对非被测系统的操作，因此这些操作需要基于一定的网络协议进行封装，例如利用HTTP、RPC等方式进行封装，本申请实施例对封装的具体实现方式并不需要进行限定。测试装置在步骤SlOl接收到测试用例执行触发之后，首先对测试用例的内容进行分析。确定哪些流程是仅需要在当前的被测系统运行的(即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的方式,例如,仓Il建买方用户cookie后,进一步将买方用户的历史行为信息作为参数写入cookie，这样，支付系统就可以识别出针对这名买方用户的用于进行后续支付流程的信息。例如这名买方用户之前与哪位卖方用户达成了交易、当前需要支付多少金额、采用何种支付方式等等。至此，支付系统已经获得了一个用户的登录状态，并且获得了支付金额、支付方式、支付对象等数据，满足了对支付功能进行测试的先序条件，后续就可以进一步对支付功能进行测试。上述传递用户历史行为信息的方法，比较适用于需要传递的信息较少的情况。为了避免cookie文件过大，在本申请的另一种实现方式中，也可以通过URL (UniversalResource 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系统测试装置，该装置对应与图I中所示的测试装置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，用于将测试序列的执行结果转换为被测系统可识别的信
肩、O根据前面的描述可知，测试序列中所涉及的操作，实际是在非被测系统中执行的。而利用网络协议对各种操作进行封装，可以实现本地的测试装置触发远端的非被测系统执行各种操作。测试序列执行完毕之后，执行结果也会返回本地的测试装置。但是，非被测系统所返回的执行结果并不能被直接被被测系统所识别。因此执行结果转换模块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，以通过向测试序列中添加测试参数的方式，实现同一测试流程的不同路径选择。为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如R0M/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。以上所述仅是本申请的具体实施方式
，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。
权利要求
1.一种Web系统测试方法,其特征在于,包括 接收测试用例的执行触发，所述测试用例为针对被测系统的测试用例； 根据所述测试用例中所包含的运行于非被测系统的流程，选择与所述运行于非被测系统的流程所对应的流程封装包，并利用所选择的流程封装包构成测试序列；所述流程封装包内，包括基于网络协议进行封装的针对非被测系统的操作； 执行所述测试序列； 将测试序列的执行结果转换为被测系统可识别的信息。
2.根据权利要求I所述的方法，其特征在于，在构成测试序列之后，还包括 在测试序列中添加测试参数。
3.根据权利要求2所述的方法，其特征在于，所述在测试序列中添加测试参数，包括 利用所述测试用例中定义的测试参数，和/或当前已完成测试进程所获得的结果，向流程封装包中的操作传递测试参数。
4.根据权利要求2所述的方法，其特征在于，所述在测试序列中添加测试参数，包括 为流程封装包中的操作随机生成测试参数。
5.根据权利要求I所述的方法，其特征在于，所述将测试序列的执行结果转换为被测系统可识别的信息，包括 创建用于模拟用户在被测系统的登录状态cookie ； 根据测试序列的执行结果，获得与所创建cookie相对应的用户历史行为信息。
6.根据权利要求I所述的方法，其特征在于，在将测试序列的执行结果转换为被测系统可识别的信息之后，还包括 将转换后的信息发送至被测系统，以继续执行测试用例。
7.一种Web系统测试装置，其特征在于，包括 测试用例触发模块，用于接收测试用例的执行触发，所述测试用例为针对被测系统的测试用例； 测试序列构成模块，用于根据所述测试用例中所包含的运行于非被测系统的流程，选择与所述运行于非被测系统的流程所对应的流程封装包，并利用所选择的流程封装包构成测试序列；所述流程封装包内，包括基于网络协议进行封装的针对非被测系统的操作； 测试序列执行模块，用于执行所述测试序列； 执行结果转换模块，用于将测试序列的执行结果转换为被测系统可识别的信息。
8.根据权利要求7所述的装置，其特征在于，还包括 测试参数添加模块，用于在所述测试序列构成模块构成的测试序列中添加测试参数。
9.根据权利要求8所述的装置，其特征在于，所述测试参数添加模块，包括 测试参数传递单元，用于利用所述测试用例中定义的测试参数，和/或当前已完成测试进程所获得的结果，向流程封装包中的操作传递测试参数。
10.根据权利要求8所述的装置，其特征在于，所述测试参数添加模块，包括 测试参数生成单元，用于为流程封装包中的操作随机生成测试参数。
11.根据权利要求7所述的装置，其特征在于，所述执行结果转换模块，包括 cookie创建单元，用于创建用于模拟用户在被测系统的登录状态cookie ； 信息获得单元，用于根据测试序列的执行结果，获得与所创建cookie相对应的用户历史行为信息。
12.根据权利要求7所述的装置，其特征在于，所述装置还包括 信息发送模块，用于在所述执行结果转换模块将测试序列的执行结果转换为被测系统可识别的信息之后，将转换后的信息发送至被测系统，以继续执行测试用例。
全文摘要
本申请公开了一种Web系统测试方法及装置。一种Web系统测试方法包括接收测试用例的执行触发，所述测试用例为针对被测系统的测试用例；根据所述测试用例中所包含的运行于非被测系统的流程，选择与所述运行于非被测系统的流程所对应的流程封装包，并利用所选择的流程封装包构成测试序列；所述流程封装包内，包括基于网络协议进行封装的针对非被测系统的操作；执行所述测试序列；将测试序列的执行结果转换为被测系统可识别的信息。应用上述方案预先将与被测系统无关的操作流程以网络协议的形式封装起来，通过执行流程封装包自动从其他的系统获得测试所需的数据或状态，以避免或减少测试人员对这些与测试对象无关第三方系统的操作，提高整体测试效率。
文档编号G06F11/36GK102855182SQ20111033770
公开日2013年1月2日 申请日期2011年10月31日 优先权日2011年6月28日
发明者谷云, 李磊 申请人:乐活在线(北京)网络技术有限公司