CN101241467B

CN101241467B - 一种面向Web应用的自动化白盒测试方法

Info

Publication number: CN101241467B
Application number: CN2008100266245A
Authority: CN
Inventors: 罗笑南; 马识佳
Original assignee: Individual
Current assignee: Individual
Priority date: 2008-03-05
Filing date: 2008-03-05
Publication date: 2010-06-23
Anticipated expiration: 2028-03-05
Also published as: CN101241467A

Abstract

本发明提供一种面向Web应用的自动化白盒测试系统及方法，包括Web数据采集模块，将测试人员在客户端浏览器提交的数据信息自动保存为web请求信息数据文件，并加入action信息，生成初始测试数据文件；脚本生成模块，其根据初始测试数据文件生成测试脚本；数据生成模块，该模块通过编写一个业务描述文件，描述测试用例执行的逻辑顺序，自动对初始测试数据文件进行修改，生成测试数据文件；集成测试模块，其根据业务描述文件的逻辑顺序对多个测试用例进行耦合。

Description

一种面向Web应用的自动化白盒测试方法

技术领域

本发明属于计算机软件的测试技术，尤其是对于Web应用软件的功能可靠性进行自动化测试的测试技术。

技术背景

目前在软件测试领域中，自动化测试是一项新兴的测试技术，自动化测试的方法主要有两种类型：

1、捕捉/回放机制：直接使用商业测试软件编写测试用例脚本。用商业测试软件对被测试软件进行自动化测试，这类测试软件对web应用进行测试时，共同点是录制web应用页面操作生成测试脚本，测试时是在客户端模拟浏览器操作来实现自动化测试，如附图1所示。这种测试方法的缺点是客户端只能获取到http信息流，但不能够获得软件内部数据结构和相关信息，无法对软件内部进行完整有效的检查和验证，具有一定的局限性。例如，对软件运行时动态生成数据进行验证，而这些动态生成数据不通过http信息流返回到客户端时，捕捉/回放机制的测试方法就难以进行有效测试。

2、自动白盒测试：这类自动化测试工具自动生成测试用例脚本，主要是针对源代码进行分析测试，不具有逻辑测试功能。这类自动测试虽然比较方便，可以发现手工测试中难以发现的错误，但也有局限性：此类工具一般比较昂贵，初始投入非常高，而且不能对软件的业务功能进行有效测试。

而且现有技术中，不管是捕捉/回放机制还是自动白盒测试，这些测试方法还存在一个不足之处，就是只能单独的执行测试用例，不能把多个用例根据业务逻辑有效的耦合起来。当某个用例需要以其它用例的运行结果作为初始条件，目前的测试方法难以将结果自动输出到其它用例，需要手工实现，更缺乏把大量用例根据业务逻辑自动化耦合起来的方法。

发明内容

本发明的目的在于克服现有技术的不足，提出一种实现web应用自动化白盒测试的系统，该系统适用于基于J2EE及struts技术B/S架构的web应用。

本发明的另一目的在于提出一种实现web应用自动化白盒测试的方法，测试时，对测试用例进行一次手工测试，在测试过程中自动记录测试数据，并按照固定格式保存。根据保存的数据自动生成该用例的测试脚本，该测试脚本和测试数据就可以实现对这个测试用例的自动化白盒测试，当业务复杂时会有大量的测试用例，本发明提出的方法还可以自动化构建不同测试用例之间的业务逻辑关系，使测试脚本可以根据业务逻辑关系批量运行。当脚本自动化测试时，测试脚本部署在服务端的表示层，脚本在服务端组件内部模拟软件业务操作，测试结束后，输出测试结果报表。

为了实现发明目的一，采用的技术方案如下：

一种面向Web应用的自动化白盒测试系统，包括如下组成部件：

Web数据采集模块，将测试人员在客户端浏览器提交的数据信息自动保存为web请求信息数据文件，并加入action信息，生成初始测试数据文件；

脚本生成模块，其根据初始测试数据文件生成测试脚本；

数据生成模块，该模块通过编写一个业务描述文件，描述测试用例执行的逻辑顺序，自动对初始测试数据文件进行修改，生成测试数据文件；

集成测试模块，其根据业务描述文件的逻辑顺序对多个测试用例进行耦合。

上述技术方案中，所述Web数据采集模块通过在客户端浏览器安装数据采集插件实现，所述数据采集插件调用浏览器提供的API，将浏览器所提交的数据请求信息记录下来，并按照固定格式保存。

所述action信息通过在struts的描述文件中获取，其记录web操作时的业务映射关系。

所述脚本生成模块根据初始测试数据文件生成初始测试脚本，如果测试用例需要检查更多的验证点，则通过对初始测试脚本进行修改，得到测试脚本，如果测试用例不需检查更多的验证点时，则初始测试脚本即是测试脚本。

所述集成测试模块将测试脚本部署在服务端的表示层，在服务端的表示层进行集成测试，测试过程中，用例将生成数据按业务逻辑输出到相应的数据文件，以便相关用例使用该用例的运行结果，测试结束后，输出测试结果报表。

为了实现发明目的二，采用的技术方案如下：

一种面向Web应用的自动化白盒测试方法，包括如下步骤：

(1)手工进行测试用例的测试；

(2)Web数据采集模块自动记录并保存浏览器提交的数据信息；

(3)对步骤(2)保存的数据文件进行修改，加入action信息，得到初始测试数据文件；

(4)脚本生成模块根据步骤(3)得到的初始测试数据文件，生成测试脚本；

(5)根据业务逻辑关系编写业务描述文件；

(6)数据生成模块根据步骤(5)的业务描述文件生成测试数据文件，以满足复杂业务逻辑的批量自动化测试；

(7)部署步骤(4)得到的测试脚本，测试脚本运行时调用步骤(6)得到的测试数据文件，实现自动化白盒测试。

上述技术方案中，所述步骤(4)具体包括脚本生成模块根据初始测试数据文件自动生成初始测试脚本，并可根据更多验证点检查需要进行修改，生成测试脚本，不需要对脚本修改时初始测试脚本即为测试脚本。

所述步骤(7)还包括测试结束后输出测试结果报表。

与现有技术相比较，本发明具有如下优点：

1、本发明提出的是基于白盒测试的自动化测试方法。

本发明的测试脚本部署在web应用软件的表示层进行测试，如附图2所示，是基于软件代码的测试，可以对软件运行时的细节进行细致的检查，在测试时可以利用软件内部的逻辑结构及有关信息，确定实际状态是否与预期的状态一致。软件出现bug时，可以根据测试结果报表确定到具体的函数或类出现问题。而现有技术对于业务逻辑的自动化测试方法多是黑盒测试，本发明与黑盒测试比较，更能有效地检验软件运行的正确性，对代码内部结构进行有效测试，保证软件质量。

2、本发明数据和脚本的编写简便易用，效率高。

传统的白盒测试方法耗时，对测试人员技术要求高，成本高。本发明提出了数据自动采集的方法，在手工测试的同时便可自动采集保存测试数据，测试脚本根据数据文件自动生成，使得测试数据及测试脚本的编写自动化，测试框架简便易用，具有成本低、效率高的优点。

3、测试脚本和测试数据分离，测试数据便于维护，可重用性好。

目前常用的测试工具，测试数据和测试脚本统一在一个脚本文件中，该脚本包含业务流程和大量的数据，web应用过程中捕获的数据都保存下来，包含大量的无用信息，这样的脚本难于管理维护。本发明将测试数据从脚本中分离出来，单独保存为测试数据文件，而且只保存页面提交数据，测试数据清晰明了，便于长期维护。当软件业务流程中的数据结构有变化时，只需要对数据文件进行修改维护即可，测试脚本不需要改动。

4、测试框架灵活，验证点即插即用。

本发明自动生成的脚本可以进行有效的测试，包括数据是否正常提交，业务流程是否正常运行，服务器是否能正确返回结果。本发明提供灵活的架构，可以通过调整脚本生成模块，以满足不同项目的测试需要。同一个项目中，有些用例需要对更多的验证点进行检查，本发明提供的测试架构，只需在测试脚本中增加相应程序，就可以获得软件运行中的内部逻辑结构及有关信息，检查软件内部实际状态是否与预期的状态一致，同时可以方便地对数据库进行查询，验证点即插即用。

5、能够快捷构建不同测试用例之间业务逻辑关系。

不同测试脚本如何根据业务逻辑方便快捷地组织起来进行联合测试，这是自动化测试面临的难题。本发明提出了大量测试用例根据业务逻辑关系自动化耦合的机制，使业务逻辑的测试更加便捷，对复杂业务的测试更加有效。

附图说明

图1为已有B/S自动化测试框架图；

图2为本发明测试框架图；

图3为本发明测试架构图；

图4为测试数据流程图；

图5为测试脚本流程图；

图6为具体实施流程图。

具体实施方式

下面结合附图对本发明做进一步的说明。

本发明的测试架构图如附图3所示，包括4个功能模块：

Web数据采集模块

Web数据采集模块具有将浏览器的提交信息采集并保存的功能。通过在浏览器安装数据采集插件实现该功能，插件调用浏览器提供的API，将浏览器所提交的数据请求信息记录下来，并按照固定格式保存。测试人员在客户端通过浏览器访问web服务器，进行所需要的测试用例的手工测试。在测试过程中，浏览器提交的数据信息被自动保存在本地，一个测试用例会有多步操作，该数据信息文件按照测试步骤保存每步提交的请求信息，包括测试数据的值和变量名，这时的数据文件称为web请求信息数据文件。浏览器提交的数据信息和action信息是本发明测试时的所需要的参数，action信息记录web操作时的业务映射关系，可在struts的描述文件获取，因而需要对web请求信息数据文件作少量数据修改，加入action信息，得到的数据文件称为初始测试数据文件。测试数据流程如附图4所示。

脚本生成模块

脚本生成模块根据初始测试数据文件生成初始测试脚本。初始测试脚本是用于自动化测试的程序，程序结构相对固定，该程序可以读入测试数据，驱动测试用例的执行，完成测试过程，并且可以验证该测试用例是否正确运行。如果测试用例需要检查更多的验证点，可以对脚本进行修改，得到测试脚本，不需检查更多验证点时，初始测试脚本即是测试脚本。测试脚本流程如附图5所示。

数据生成模块

数据生成模块用于快捷构建不同测试用例之间的业务逻辑关系。该模块通过编写一个业务描述文件，描述用例执行的逻辑顺序，就可以自动对初始测试数据文件进行修改，生成测试数据文件，满足对描述文件中业务逻辑的测试。

集成测试模块

集成测试模块将测试脚本部署在服务端的表示层，进行集成测试。测试过程中，用例将生成数据按业务逻辑输出到相应的数据文件，以便相关用例使用该用例的运行结果，测试结束后，输出测试结果报表。

本发明的具体实施流程图如附图6所示，包括如下步骤：

步骤1、手工进行测试用例的测试；

步骤2、Web数据采集模块自动记录并保存浏览器提交的数据信息；

步骤3、对步骤2保存的数据文件进行修改，加入action信息，得到初始测试数据文件；

步骤4、脚本生成模块根据步骤3得到的初始测试数据文件，自动生成初始测试脚本；

步骤5、初始测试脚本可以根据需要进行修改，以便更多验证点检查，经修改后的文件为测试脚本，不需要对脚本修改时初始测试脚本即为测试脚本；

步骤6、根据业务逻辑关系编写业务描述文件；

步骤7、数据生成模块根据步骤6的业务描述文件生成测试数据文件，满足复杂业务逻辑的批量自动化测试；

步骤8、部署步骤5得到的测试脚本，测试脚本运行时调用步骤7得到的测试数据文件，实现自动化白盒测试；

步骤9、输出测试结果报表。

其中步骤4、5与步骤6、7为并列的两个分支。

下面以具体的实施方案对本发明做进一步的说明。

本实施方案将以电信管理系统为背景，测试三个用例，生成自动化脚本和数据文件。其中，第一个测试用例用以阐述单独用例的测试，第二个和第三个用例用以补充说明多个用例根据业务逻辑进行测试。三个用例如下：

以最高权限管理员root身份创建OP(运营商管理员)；

以OP(运营商管理员)身份创建CP(内容提供商管理员)；

以OP(运营商管理员)身份修改CP(内容提供商管理员)的基本信息。

设创建的OP命名为op-test-${runID}，创建的CP命名为cp-test-${runID}。runID为唯一标识符，每次运行改变数值，不需修改数据文件便可多次回归测试。

测试第一个用例root创建运营商管理员，测试人员使用浏览器与服务器交互，通过数据采集模块将浏览器提交的数据信息自动化保存为本地XML文件，即web请求信息数据文件，本领域的普通技术人员可以根据原理，调用浏览器提供的API保存请求信息，编写出数据采集模块。生成的web请求信息数据文件如下：

<group>

<attr name＝″password″>password</attr>

<attr name＝″repass″>password</attr>

<attrname＝″language″>en_US</attr>

</object>

</group>

将该文件进行修改，根据struts配置文件信息加入actions信息，生成初始测试数据文件：

<group>

<attr name＝″password″>password</attr>

<attr name＝″repass″>password</attr>

<attrname＝″emailAddress″>op@test.com</attr>

</object>

</group>

<attr name＝″CONTEXT_PATH1″>/ConfigMng</attr>

<attr name＝″CONFIG_PATH1″>/WEB-INF/configMng/</attr>

<attr name＝″RequestPath1″>/initAdminOprate.do</attr>

<attr name＝″Object11″>adminType</attr>

<attr name＝″Forward1″>success</attr>

<attr name＝″ForwardPath1″>/adminList.do</attr>

<attr name＝″RequestPath2″>/adminList.do</attr>

<attr name＝″Forward2″>success</attr>

<attr name＝″ForwardPath2″>/adminMng/adminList.jsp</attr>

<attr name＝″RequestPath3″>/createAdmin.do</attr>

<attr name＝″Forward3″>success</attr>

<attr

name＝″ForwardPath3″>/adminMng/adminCreate.jsp</attr>

<attr name＝″TCRunId_Field1″>loginName</attr>

<attr name＝″RequestPath4″>/createAdminSave.do</attr>

<attr name＝″Object41″>adminInfo</attr>

<attr name＝″Forward4″>success</attr>

<attr name＝″ForwardPath4″>/success.jsp</attr>

</object>

</common>

</list>

脚本生成模块根据初始测试数据文件生成初始测试脚本，初始测试脚本是该用例的测试程序，可从数据文件中读入数据并驱动被测试软件执行相应业务。不同用例的测试程序结构一致，可根据测试数据自动生成，本领域的普通技术人员可以容易地编写脚本生成模块，生成测试脚本。

这样自动生成了初始测试数据文件和初始测试脚本，可以将其部署到服务端的表示层，运行该测试用例脚本，对用例(创建管理员)进行自动化回归测试。当其它测试用例需要用到特定管理员时，也可以运行该测试脚本生成的管理员数据。

下面进行多个用例自动化测试。首先，同样的方法生成另外两个用例(以运营商管理员身份创建内容提供商管理员；以运营商管理员身份修改内容提供商管理员的基本信息)的测试脚本和测试数据。这样得到三个用例的测试脚本和数据，假设三个用例的测试数据文件名分别为createOP、createCPSP、OPModifyCPSP。

自动化测试脚本会频繁地回归测试，测试OPModifyCPSP用例时，在不修改测试数据的情况下，每次都进行相同内容的测试，用相同的运营商管理员为内容提供商管理员修改信息，测试意义不大，这样会降低测试的质量和灵活性。如果想每次进行不同内容的测试，就需要在测试该用例之前创建新的运营商管理员和内容提供商管理员，并手工修改OPModifyCPSP用例的测试数据，这是很麻烦的事情，降低自动化测试的效率和意义。比较好的解决方法是用自动化脚本创建不同的运营商管理员和内容提供商管理员，然后用刚创建的运营商管理员为内容提供商管理员修改信息。当一个项目有数百个以上的测试用例时，用例之间的业务逻辑关系就难以管理，数据生成模块解决这一问题。

通过编写业务描述文件，描述三个用例的逻辑关系，

<attr name＝″CaseFlow″>createOP</attr>

<attr name＝″CaseFlow″>createCPSP</attr>

<attr name＝″CaseFlow″>OPModifyCPSP</attr>

</object>

</list>

该描述文件指明所要测试的用例是OPModifyCPSP(list name指明)，业务流程是第一步createOP，第二步createCPSP，第三步OPModifyCPSP。数据生成模块根据该描述文件，批量修改初始测试数据文件，得到测试数据文件。修改后的createOP和createCPSP测试数据文件指定将生成的OP和CP数据输出到OPModifyCPSP数据文件中，这样就使得OPModifyCPSP用例获得所需要数据。如需测试更多的用例，只要在描述文件中增加新的业务逻辑关系的描述即可，本领域的普通技术人员可以根据原理编写数据生成模块，生成测试数据文件。

将测试脚本部署在服务端，便可以进行自动化白盒测试，测试结束后输出结果报表，结果报表包括明确的统计数据(包括测试用例数据和通过率)，当有失败用例时，还提供测试的跟踪信息及测试用例失败的原因分析。

Claims

1.一种面向Web应用的自动化白盒测试方法，其特征在于包括如下步骤：

(1)手工进行测试用例的测试；

(2)通过Web数据采集模块自动记录并保存浏览器提交的数据信息；

(4)通过脚本生成模块根据步骤(3)得到的初始测试数据文件，生成测试脚本；

(5)根据业务逻辑关系编写业务描述文件；

2.根据权利要求1所述的面向Web应用的自动化白盒测试方法，其特征在于所述步骤(4)具体包括脚本生成模块根据初始测试数据文件自动生成初始测试脚本，并可根据更多验证点检查需要进行修改，生成测试脚本，不需要对脚本修改时初始测试脚本即为测试脚本。

3.根据权利要求1或2所述的面向Web应用的自动化白盒测试方法，其特征在于所述步骤(7)还包括测试结束后输出测试结果报表。