CN103049369A - 一种自动化测试方法及系统 - Google Patents

Abstract

本发明公开了一种自动化测试系统及方法。所述方法包括：产生一测试请求；运行测试脚本，对所述被测界面进行测试；以及获得测试结果；其中，所述测试脚本是根据一界面模型编写的脚本，所述界面模型包括子模块和/或控件的集合。

Description

一种自动化测试方法及系统

技术领域

本申请涉及自动化测试领域，特别是涉及一种自动化测试方法及系统。

背景技术

UI(user interface；用户界面)自动化测试，是由机器模拟用户UI操作，进行自动化测试。主要测试类型有Web UI自动化测试和本地应用程序UI自动化测试。

UI自动化测试多采用id、class等特定属性来定位元素，然而在实际应用中，往往有很多需要自动化测试的控件并没有可用的属性。对于那些没有属性的元素，多采用xpath绝对路径的方式，灵活度不够。JQuery框架可用于处理页面，因为它的快速和简洁，受到越来越多的开发者的青睐。开发用灵活的写法构建出来的页面，往往给使用传统定位方式的测试人员带来困扰。

将元素的查找方式，抽象到界面模型中去，是规避界面元素变化对自动化测试影响的有效手段。传统的界面模型一般以代码的方式展现，并直接供测试脚本调用。但是在企业级应用的时候，会遇到麻烦：如模型代码不够直观不易上手；分享不容易，一个项目中写好的模型不方便其它项目使用，把模型代码拷贝过来用又会遇到更新同步的问题。

另外，在现有技术中，还有如下几种测试框架，但是都有各种缺陷：

Watir封装了IE的COM对象，定位方式丰富，支持id，name，index和xpath，但是不支持Selector(选择器)的方式来定位控件。

Selenium直接引用CSS Selector的js文件，来查找页面上元素，由于它直接用js来驱动查找和操作，Selenium不支持本地应用程序的自动化测试。

AutoIt是本地应用程序自动化的解决方案，他采用自己定义的语法来定位界面上的元素，如″[NAME:textBoxFolder]″，″[CLASS:Button；TEXT:Finish；INSTANCE:2]″等。

发明内容

本申请提供一种自动化测试方法及系统，用以解决现有技术中自动化测试存在的模型代码在企业级应用中不够直观不易上手、分享不容易等问题。

本申请一方面提供一种自动化测试方法，应用于被测界面，所述方法包括：产生一测试请求；运行测试脚本，对所述被测界面进行测试；以及获得测试结果；其中，所述测试脚本是根据一界面模型编写的脚本，所述界面模型包括子模块和/或控件的集合。

优选地，所述子模块嵌套下级子模块和/或所述控件。

优选地，多个所述子模块设置为子模块集合。

优选地，当所述被测界面为Web界面时，所述界面模型为Web界面模型；当所述被测界面为本地应用程序时，所述界面模型为本地应用程序界面模型。

优选地，所述控件的属性包括所述控件的名称、元素类型、元素查找方式及是否为集合；所述子模块的属性包括所述子模块的名称、元素查找方式及是否为集合。

优选地，所述控件的元素查找方式和所述子模块的元素查找方式用来查找和定位所述控件对应的元素在所述被测界面中的位置。

优选地，所述控件的元素查找方式和所述子模块元素查找方式为selector。

优选地，所述测试脚本具体为根据所述控件的名称、所述控件的元素类型、所述控件的元素查找方式、所述控件是否为集合和所述子模块的名称、所述子模块的元素查找方式、所述子模块是否为集合编写的。

优选地，在所述运行所述测试脚本进行测试前，还下载最新的界面模型，并生成界面模型类文件，将所述类文件加载到所述测试脚本中。

本申请另一方面提供了一种自动化测试系统，应用于一被测界面，所述系统包括测试请求产生模块，用于产生一测试请求；脚本运行模块，用于运行测试脚本，以对所述被测界面进行测试；以及结果获得模块，用于获得测试结果；其中，所述测试脚本是根据一界面模型编写的脚本，所述界面模型包括子模块和/或控件的集合。

本申请有益效果如下：

本申请一实施例采用包括有子模块和/或控件的集合的界面模型，并将该界面模型应用到自动化测试中，使得在企业级应用中，共享界面模型变得容易，测试脚本维护成本降低。并且统一了所有UI界面自动化测试的统一，统一了建立界面模型的方式，统一了测试脚本的写法，也有效降低了学习成本。

更进一步，本申请一实施例采用了Selector的元素查找方式，使得界面模型的应用更加灵活，将Selector从原来只支持html应用扩展到由抽象来实现Selector的语法，不同场景(本地应用或浏览器应用，如firefox)只需要简单实现接口就能实现对Selector的支持。

附图说明

图1为本申请一实施例中自动化测试方法的流程图；

图2-7为本申请各实施例中被测界面的布局图；

图8为本申请一实施例中建立界面模型的方法流程图；

图9为本申请一实施例中界面模型的类图；

图10为本申请一实施例中自动化测试系统的功能框图。

具体实施方式

本申请一实施例提供了一种自动化测试方法，请参见图1，其为该自动化测试方法的流程图，该方法包括：

步骤101：产生一测试请求；

步骤102：运行测试脚本，对所述被测界面进行测试，所述测试脚本是根据一界面模型编写的脚本，所述界面模型包括子模块和/或控件的集合；

步骤103：获得测试结果。

在本实施例中，自动化测试方法可在本地执行，也可远程执行，当在本地执行时，测试人员点击运行按钮，产生测试请求，同时测试脚本被运行，运行完成之后，就可以直接看到结果。当为远程执行时，定时器在时间到时，发送一个运行脚本的请求，然后就定时的在自动化执行机器上自动化执行，并给出执行结果。

在步骤102中所运行的测试脚本是根据一界面模型编写的，界面模型包括两种组织方式：一种是控件，另一种是子模块。控件是最小操作单位，下面不能再有子结点，用来定义被测界面上具体要操作的元素；子模块用来对控件进行分类，是一个区块，下面可以有多个子结点。子模块下面可以有一个或多个控件和子模块。

在被测界面上经常会有很多结构类似的布局，例如图2中，页面20上包括“今日关注上升”列表201和“一周关注热门”列表202，这两个列表的结构都一致，都是由多条记录组成，所以在本实施例中，引入集合的概念，将页面上一些相同结构的当作一个数组处理，避免了对每个需要操作的控件进行重复定位。下面具体介绍控件的集合和子模块的集合。

控件的集合，如图2所示，列表201中的5条记录结构都一致，都是同一列表中的link控件，假设现在需要在5个记录中选择一个，现有技术的方式是需要对所有的记录进行定义，而且在事前不知道要选哪个记录的前提下，需要全部定义一次。在本实施例中，将这5个link控件认为是一个数组集合，只要定义一次，就可以找到数组中的任何一个。

子模块的集合和控件的集合类似，只不过子模块的集合是一个区块的集合，后者是一个控件的集合，如图2所示，列表201和列表202结构一致，所以将“关注”信息定义为数组，数组包含了“今日关注列表”201和“一周关注热门”列表202，这样就可以通过这个数组找到任何一条在这个数组里的记录。

控件的属性包括名称(例如英文名、中文名)、元素类型、元素查找方式以及是否为集合，英文名是写测试脚本过程中要用到的名称，中文名是为了方便使用，可以不包括；不同的元素类型会有不同的操作方法，例如：textfield的控件会有set方法，而button类型的控件有click方法，元素查找方式是查找、定位控件的查找器，例如可以使用id，name等查找方式，在本实施例及以下实施例中均采用Selector，支持JQuery语法。集合的概念已经在前面描述清楚，在此不再详述。

子模块的属性包括名称(例如英文名、中文名)、元素查找方式及是否是集合，英文名是写测试脚本过程中要用到的名称，中文名是为了方便使用，可以不包括；元素查找方式是查找、定位控件的查找器，用于查找和定位控件所对应的元素在被测界面中的位置，例如可以使用id，name等查找方式，在本实施例及以下实施例中均采用Selector，支持JQuery语法。集合的概念已经在前面描述清楚，在此不再详述。

以上介绍了界面模型的组织方式，界面模型是根据该被测界面建立的，当被测界面为Web界面时，界面模型为Web界面模型；当被测界面为本地应用程序时，所述界面模型为本地应用程序界面模型，以下举例说明如何根据被测界面建立界面模型及相应的脚本编写。

实施例1：

例如，被测界面为Web界面。首先生成一个还没有添加任何控件或子模块的当前界面，然后在当前界面下直接放控件，这个控件在脚本里用的最多，跟其他控件没关系，这种界面模型使用方便，调用方式简单直观。如图3所示的搜索页面30，关于搜索框301和搜索按钮302的建模方式如下：

英文名           中文名      Selector            子模块    集合

txt_search_box  搜索框  input[name＝q][id＝title]  否       否

btn_search      搜索按钮  button[type＝submit]     否       否

脚本调用：

page.txt_search_box.set“automan”    #搜索框输入automan

page.btn_search.click                 #搜索

实施例2：

当元素出现的个数或内容可变，界面上出现多于三个类似的控件时用控件的集合，即在当前界面下直接放控件的集合，这种界面模型调用方式灵活，支持不定数目的控件。如图4所示的界面40，“今日关注热门”列表401下面有5个类似的控件，所以将其作为一个数组集合来处理，具体建模方式如下：

英文名            中文名      Selector    子模块    集合

lnk_today_hots    热门链接    div.hot a    否        是

脚本调用：

page.lnk_today_hots[0].text＝＞“连衣裙”         #取热门中排名第一的内容

page.lnk_today_hots[“女包”].click                       #点女包这个链接

page.lnk_today_hots[“章鱼”].exist？＝＞false    #这个热门列表里没有章鱼

对于图2中的列表201和列表202可作同样的处理。

实施例3：

当界面上要测的点很多，控件过多，所以要对控件进行分类，而且界面太大，查找速度慢，通过子模块作为变量保存(即做缓冲)的方式来提升速度，这种界面模型分类清晰，可解决控件杂乱等问题。如图5所示的搜索界面50，界面50上还有其他很多控件，不是本实施例要说明的，所以在此省去。如图5所示，自助服务页501里面有6个控件，所以将这6个控件分类为一个子模块，然后将控件放在子模块下面，具体的建模方式如下：

脚本调用：

page.self_service.lnk_forgot_password.click  #点找回登录密码

page.self_service.lnk_refund_list.click      #点退款申诉凭证

用作缓冲时，假设page.self_service由于页面非常大，需要加载很长时间。以下的方式通过临时变量来节省时间：

self_service＝page.self_service

self_service.lnk_forgot_password.click    #点找回登录密码

self_service.lnk_refund_list.click        #点退款申诉凭证

由此可以看出，合适的层次划分可以增加代码的易读性。

实施例4：

本实施例为在当前界面下放子模块，子模块下放控件的集合，该应用场景与实施例2中当前界面下直接放控件的集合类似，只是多了一个子模块的封装，子模块可以使界面有明显的区域划分，分子模块会更加清晰；而且将种类繁多的控件进行归类。详细建模方式请参见实施例2和3，在此不再赘述。

实施例5：

在本实施例中，当前界面下放子模块的集合，子模块下放控件，这种界面模型比较灵活，调用方式统一，脚本易读和不容易写错。如图6所示，在界面60上包括区块601、区块602、区块603、区块604和区块605，每个区块都有固定的格式，但是区块的个数和内容是可变的，或者区块的个数和内容不变，但是个数大于三个也可用本实施例的建模方式，在本实施例中，以区块个数和内容是可变的为例。

如图6所示，区块601、区块602、区块603、区块604和区块605中的每个区块都包括宝贝的链接，和我联系的链接以及价格，所以可以建模如下：

脚本调用：

page.auction_records[“豆浆机”].price.text＝＞255.00    #取第一条内容包含“豆浆机”的宝贝的价格

page.auction_records[“张三”].lnk_contact_me.click      #和张三联系

page.auction_records[0].lnk_auction_link_click           #点第一条宝贝链接

实施例6：

在本实施例中，当前界面下放子模块的集合，子模块下放控件的集合，适用于每个区块都有固定的格式，但区块的个数和区块内容是可变的，同时区块里面的控件个数和内容也是可变的以及更多维度的变化的界面。如图7所示的界面70，例如一级类目区块701里面的手机点进去会出现二级类目区块702，当点选区块702中的诺基亚时会出来价格区块703，具体建模方式如下：

英文名              中文名   Selector                  子模块    集合

category_areas      类目块   ol#J_OlCascadingList＞li    是       是

category_records    类目项   ＞ul＞li                    否       是

脚本调用：

page.category_areas[0].category_records[″手机″].click      #点一级类目中的手机

page.category_areas[1].category_records[″Nokia/诺基亚″].click      #点二级类目中诺基亚

通过以上各实施例的介绍，本领域技术人员很容易理解具体如何建立界面模型，当然，根据实际需要，可以对上述各个实施例进行组合。

另外，本申请实施例采用Selector来定位元素，使界面模型使用起来更加灵活，而且因为Selector支持JQuery的语法，可以实现Web界面测试和本地应用程序(App)测试。

请继续参考图8，其为本申请一实施例中建立界面模型的方法流程图。该方法包括：

步骤803：选择添加的元素类型；

步骤804：如果是子模块，则进行子模块编辑；

步骤805：如果是控件，则进行控件编辑；

步骤806：判断是否要为子模块添加元素；

步骤807：如果是，则重复步骤803～806；

其中，在步骤804中，对子模块进行编辑，包括编辑子模块的英文名、中文名、元素查找方式及是否是集合，英文名是写测试脚本过程中要用到的名称，中文名是为了方便使用，可以不包括；元素查找方式是查找、定位控件的查找器，用于查找和定位控件所对应的元素在被测界面中的位置，例如可以使用id，name等查找方式，在本实施例及以下实施例中均采用Selector，支持JQuery语法。集合的概念已经在前面描述清楚，在此不再详述。

在步骤805中，对控件进行编辑包括编辑控件的名称(例如英文名、中文名)、元素类型、元素查找方式以及是否为集合，英文名是写测试脚本过程中要用到的名称，中文名是为了方便使用，可以不包括；不同的元素类型会有不同的操作方法，例如：textfield的控件会有set方法，而button类型的控件有click方法，元素查找方式是查找、定位控件的查找器，例如可以使用id，name等查找方式，在本实施例及以下实施例中均采用Selector，支持JQuery语法。集合的概念已经在前面描述清楚，在此不再详述。

步骤804和805并没有先后顺序限制，是根据元素类型来决定的。

在另一实施例中，在步骤803之前或当步骤806判断结果为否之后，还包括步骤802，判断建模是否完成。

在再一实施例中，在步骤802之前还包括步骤801，选择模型的类型，当被测界面为Web界面时，界面模型为Web界面模型，即页面模型；当被测界面为本地应用程序时，所述界面模型为本地应用程序界面模型。

请参考图9，图9为本申请实施例中界面模型的类图，在本实施例中以应用在Web自动化测试中为例，所以即是页面模型的类图。该图只示出了在IE上的实现方法，其他浏览器和本地应用自动化也是类似的实现模式。

如图9所示，类图里的类PageModel，里面包含了页面模型(即子模块)和页面元素(即控件)，类PageModel是所有页面模型中的一个代表，所有实际使用中的页面模型都是一个一个具体的PageModel(页面模型)。如LoginPageModel(登录页面模型)或BuyPageModel(购买页面模型)，这些页面模型未图示。在页面模型中主要关注的是控件的属性和子模块的属性，例如控件的属性中的元素类型，元素类型例如为Link，Button或默认等，在类PageModel实现的时候，表现为具体的一个方法的返回类型，例如在实施例5中的lnk_auction_link，调用这个方法后应该返回一个ALink的对象。

属性中的元素查找方式，以selector为例，是由类Model来实现抽象的规则，需要调用BaseElement里面的Children，ControlName，Id，ControlName等方法，而这些方法的具体实现是跟浏览器相关的，BaseElement只是抽象方法，真正实现的是IEElement，AElement这些子类。AElement是所有IE控件的基类，所有基本类型如TextField，Radio的操作只是对它的一些扩展或重载，特殊类型如AlipayPassword也是一样。所有BaseElement的子类都会存储自己对应的底层实现的对象，来真正地实现操作的自动化，如IE上就会存COM对象，而FireFox上使用Selenium来集成就会存reference Id。

属性中的是否为集合，对应类Model里不同的方法，当为集合时，方法如类Model里的FindElements和FindModels。

属性中的中英文名分别为方法名和中文注释部分。

类HtmlModel继承自Model，除了和Model一样具备解析Selector的能力外，它还定义了页面模型间互相切换的方法，让页面模型的使用更顺畅。页面模型(PageModel)都是HtmlModel的子类，所有子模块和控件的声明都在类PageModel里。

IEModel定义了所有IE的操作，是页面自动测试的入口，通过cast方法获得具体的页面，进而进行一系列的操作。

请继续参考图9，图中虚线部分表示引用关系，箭头所指的类为被引用的类；带三角箭头的实线表示继承关系，三角箭头所指的类为父类。带菱形箭头的实线表示组合/包含关系(如PageModel和ALink间的菱形箭头代表PageModel里面包含了ALink这个类)实线旁的数字如果是1和1，则表示是一一对应的关系，如果一边是1，一边是0...*，则表示是一对多的关系。另外，重新建好的页面模型可重复使用，而且公共页面元素，用模型间继承可实现共享。Watir::Link可在被调用的时候初始化，例如当测试代码调用page.lnk_auction_link时，系统根据当前IE实时查找到节点，并将其构造为Watir::Link对象。

请一并参考图1和图9，在运行测试脚本前，还下载最新的界面模型，并生成界面模型类文件，并将类文件加载到脚本中，所以可以简单的更新脚本，工作量小，不容易出错。

本申请一实施例还提供了一种自动化测试系统，接下来请参考图10，图10为自动化测试系统的功能框图。如图10所示，该系统包括：

测试请求产生模块110，用于产生一测试请求；

脚本运行模块120，用于运行测试脚本，以对被测界面进行测试，测试脚本是根据一界面模型编写的脚本，界面模型包括子模块和/或控件的集合；

结果获得模块130，用于获得测试结果。

进一步，自动化测试系统还包括脚本更新模块，用于在运行测试脚本之前，下载最新的界面模型，并生成界面模型类文件，将所述类文件加载到测试脚本中。

界面模型的结构及建立方法以及如何根据界面模型编写测试脚本已经在描述测试方法时描述的非常清楚，所以为了说明书的简洁，在此不再详述。

本申请一实施例采用包括有子模块和/或控件的集合的界面模型，并将该界面模型应用到自动化测试中，使得在企业级应用中，共享界面模型变得容易，测试脚本维护成本降低。并且，统一了所有UI界面自动化测试的统一，统一了建立界面模型的方式，统一了测试脚本的写法，也有效降低了学习成本。

更进一步，本申请一实施例采用了Selector的元素查找方式，使得界面模型的应用更加灵活，将Selector从原来只支持html应用扩展到由抽象来实现Selector的语法，不同场景(本地应用或浏览器应用，如firefox)只需要简单实现接口就能实现对Selector的支持。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (10)

1.一种自动化测试方法，应用于被测界面，其特征在于，所述方法包括：

产生一测试请求；

运行测试脚本，对所述被测界面进行测试，所述测试脚本是根据一界面模型编写的脚本，所述界面模型包括子模块和/或控件的集合；以及

获得测试结果。

2.如权利要求1所述的方法，其特征在于，所述子模块嵌套下级子模块和/或所述控件。

3.如权利要求1所述的方法，其特征在于，多个所述子模块设置为子模块集合。

4.如权利要求1所述的方法，其特征在于，当所述被测界面为Web界面时，所述界面模型为Web界面模型；当所述被测界面为本地应用程序时，所述界面模型为本地应用程序界面模型。

5.如权利要求1所述的方法，其特征在于，所述控件的属性包括所述控件的名称、元素类型、元素查找方式及是否为集合；所述子模块的属性包括所述子模块的名称、元素查找方式及是否为集合。

6.如权利要求5所述的方法，其特征在于，所述控件的元素查找方式和所述子模块的元素查找方式用来查找和定位所述控件对应的元素在所述被测界面中的位置。

7.如权利要求6所述的方法，其特征在于，所述控件的元素查找方式和所述子模块元素查找方式为selector。

8.如权利要求5所述的方法，其特征在于，所述测试脚本具体为根据所述控件的名称、所述控件的元素类型、所述控件的元素查找方式、所述控件是否为集合和所述子模块的名称、所述子模块的元素查找方式、所述子模块是否为集合编写的。

9.如权利要求1所述的方法，其特征在于，在所述运行所述测试脚本进行测试前，还下载最新的界面模型，并生成界面模型类文件，将所述类文件加载到所述测试脚本中。

10.一种自动化测试系统，应用于一被测界面，其特征在于，所述系统包括：

测试请求产生模块，用于产生一测试请求；

脚本运行模块，用于运行测试脚本，以对所述被测界面进行测试，所述测试脚本是根据一界面模型编写的脚本，所述界面模型包括子模块和/或控件的集合；以及

结果获得模块，用于获得测试结果。

Images