分类归档 » GAT框架

GAT框架介绍

目 录 1.1项目背景 1.2框架适用范围 1.3使用要求 2.1 GAT介绍 2.2 框架特点 2.3框架整体组成 GAT2.0使用指南 1背景 1.1项目背景 开发GAT(General Automation Testing)的最初目的是公司同时需要做Web前端自动化,以及服务端的接口自动化。可能很多人觉得服务端接口测试和Web前端测试的方式差别的太大,所以应该各自写框架做测试。这种想法是很自然的想法,如果按照这种方法做了,写自动化测试用例的人就要分成两类,如果想互相备份那么就会形成相应的成本。基于我多年的Web开发,接口开发经验,以及4年多Web,接口自动化测试经验,决定将接口测试框架与Web前端自动化框架集成,统一接口用例开发,以及Web前端开发的方式,运行的方式等。降低测试人员开发自动化用例的门槛。 1.2框架适用范围 1)         服务端接口 l   基于Rest协议的接口(移动端调用的接口基本都是此类接口) l   Web Service类接口 2)         Web UI 自动化 l   框架基于Web Driver封装 3)         Android l   To Do 1.3使用要求 1)         支持的语言:Java 2)         必备软件:Eclipse,JDK 7.0+   2 GAT框架 2.1 GAT介绍 GAT框架目前支持两种类型的自动化测试,接口自动化,以及Web UI自动化测试。未来计划添加对Android Native App的自动化支持。使用框架的用例最终以Testng 的TestMethod来展现,因此支持与jenkins的无缝集成。 2.2 框架特点 1)         接口自动化 l   提供多种接口测试方式。即单一接口测试,多接口业务流程测试。目前多见的为单一接口的测试。 l   根据用户需求不同,不同的接口测试方式,用例开发难易度不同。 l   用例开发门槛低,用户只需要将接口用例数据填入格式化文件即可自动通过工具生成用例。 l   对于高级需求,框架提供自定义配置包括数据构造,精确匹配测试结果等。 l   框架对于不同域名下的相同接口支持自定义配置,只需要简单修改测试平台配置即可轻松将用例应用在不同平台上。 l   框架对于不同协议接口的支持,近乎无缝连接。 l   框架支持可配置 2)    Web UI自动化 l   用例开发实现页面元素,测试用例数据,测试用例分离,实现了参数化与数据驱动 l   用例开发模式一致,语句编写一致,降低维护成本 l   更高粒度上的关键字实现 l   关键字模型化,模型数据驱动化,通过数字驱动化的关键字的组合可以拥有千变万化的用例,但是需要维护的代码降低到了最少、 2.3框架整体组成 图1  

GAT2.0快速使用说明   提示:本文档目的在于帮助你快速在本地搭建起开发结构,需要详细了解框架使用,请查看GAT2.0说明文档。   1  从github(https://github.com/GeneralAutomationTesting/GAT2.0)上下载GAT2.0,并解压,在解压后的目录会看到以下几个目录或者文件。 2 建立接口测试工作目录,目录名称可以自定义。下图是我建立的工作目录(InterfaceAutomation) 3 将解压目录里的Libs复制到与InterfaceAutomation 同一目录下,已经在使用1.0的人,替换原有Libs即可。替换前,请做备份。如下图   4 在InterfaceAutomation下建立DataFiles目录,用来存放Excel,xml文件。目录结构如下: DataFiles目录的作用,结构与1.0版完全一致。已经在使用1.0版,可以忽略此步骤。如果对于DataFiles目录有不明白的,请参看1.0使用说明文档。   5 在InterfaceAutomation 下新建eclipse java project。Project名称可以随意。推荐使用IATStepGroup   6建好Project后,做以下几件事: 1  将GAT2.0解压目录里的GatCreator.java 复制到IATStepGroup/src下 2  将文件gatConfig.properties,logConfig.properties,build.xml复制到IATStepGroup 下 3  最后将TemplateFiles 也复制到IATStepGroup下   7 完成上述步骤后,请查看gatConfig.properties 文件。 框1:autoprojectfolder的值是我们刚才建立的InterfaceAutomation,如果你的名称不是InterfaceAutomation,请确保此处的值是你自定义的名称 框2:同样确保projectName和你建立的projectname 一致。   8  修改build.xml中 Libs的路径。请将下图中红圈里的值修改为Libs目录的路径   9 完成以上步骤,你就可以开始开发你的用例了。   10 当你在XML或者Excel中添加或者删除了用例,在2.0中已经没有了gatrunner,取代它的就是我们在一开始src中添加的GatCreator.java文件,当你需要重新生成单元测试用例的时候,在eclipse中运行这个文件中的main方法即可。它会帮你在当前Project中生成所有用例。 11 执行用例的时候,你可以选择生成的单个testng 类文件去执行,也可以直接运行build.xml文件执行所有的测试用例,这取决于你的需要。   12 对于已经在使用1.0的使用者来说,只需要按照步骤6之后的步骤使用即可,就可以完成的切换到2.0.当然替换Libs也是必须的。   13 对于想要和jenkins集成的同学,只需要按照1.0版的集成方式去做即可。唯一不同的是,不在需要下载IATTestProject了。  

  大家好,相信大家在看这篇文章之前已经对GAT框架有了一定的了解。最近看到GAT的交流群中经常会有人问如何做接口测试,作为GAT第一批的使用者下面我给大家分享下我是如何做接口测试的以及GAT的实用探索 1.为什么选择GAT框架 我在接触GAT框架前,也开发了过个简单的接口测试工具,但发现因为经验不足想到的东西太少,导致我自己开发的工具在实际运用当中不够灵活。在做接口业务逻辑测试时,多个接口互相传递参数的时候,无法灵活的传递。而GAT框架提供了一个单例模式的参数池,很好的解决了多个接口互相传递参数的问题,使多接口的业务逻辑测试能够有更多的组合。而且有一定开发基础的测试工程师,可以针对自己测试的项目在GAT框架基础上进行二次开发。 2.我们是如何做接口测试的 我们目前的主要工作是针对移动App做服务端接口测试,我们的目标是在前端测试开始之前完成所有的接口测试,并且漏测率不高于10%。为了到达目标,我们制定了一个相应的流程,首先我会要求服务端的开发人员每开发完成一个模块就提交进行测试。在拿到接口文档后,会制定测试计划,以便将每日的工作量细化,以保证测试时间的充足。接着对照着接口文档及需求文档,开始着手编写测试用例。对于接口的测试用例,我们将其分为两类,一类是接口参数测试,另一类是接口业务逻辑测试。接口参数测试顾名思义就是用正向及逆向的参数灌入到接口中检查其返回值是否正确。接口业务逻辑测试是参照需求文档,将多接口互相调用完成整套的业务逻辑,就是相当于是脱离前端测功能。在完成测试用例后我会进入开发阶段,在开发阶段我会在Jenkins上建立相应的任务,并将每日完成测试用例放到Jenkins上做持续集成,如下图。 3.接口参数测试 接口参数测试,就是用边界值和等价类的测试方法,将不同的数据通过接口发送到服务端验证返回值是否正确,以json返回值为例,如下图: 我们的目标是将返回值中所有的参数与预期结果做对比,以保证每个返回参数的值是正确的。 4.接口业务逻辑测试        接口业务逻辑测试,简单来讲就是按照前端的业务逻辑,将多个接口组合成为一个业务场景,测试该场景中是否会出现异常情况。所以测试之前,需要对照着需求文档及接口文档,编写测试用例,这样能够有效的增加测试的覆盖率,避免漏测产生,而且在代码开发完成之后,也方便维护。 5.编写代码的重要原则 在编写代码时候,我们遵循着一个重要的原则,就是所有的通用输入参数,尽量做到动态的自动生成,这样有两个好处,第一,在做接口参数测试时,你只需要填入异常参数,正常参数都是由代码自动生成,可以大大减少用例的开发时间,在做业务逻辑测试时也可以方便的让你想出更多的测试场景。第二,开发完成之后,在jenkins上持续集成时,动态生成输入参数的用例要也要比固定输入参数用例的对接口覆盖率更高。      

接口测试 1         接口的概念从IT的角度出发,主要是子模块或者子系统间交互并相互作用的部分。从形式上来看各种应用程序的API(最著名的Windows 系统的API),硬件的驱动程序,数据库系统的访问接口,再到后来的Webservice接口,http rest接口。虽然接口的形式各有不同,但是从测试角度来说,需要测试的内容大致是相同的,功能,性能,安全。经历有限,本篇文章主要介绍http REST接口从功能角度出发,怎么做测试。   2         我们为什么要做接口测试呢?。 我们现在处于移动互联网时代,接触过移动客户端测试的人都知道,我们的移动端的功能是需要大量的后台服务来支撑。 这里说的移动端包括IOS,Android,WP 原生应用以及混合应用。为什么移动端的应用需要大量的后端服务来支撑呢,最主要是两个原因,我们的手机计算能力有限,另外移动应用必须省电,因此大量的计算,数据存储,业务处理等活动需要放到服务端由大型服务器来完成。在服务器端完成计算后,通过REST接口来获取到想要的计算接口,然后展示。所以说服务端的接口的测试就尤其重要,随时移动互联网的普及,接口测试会越来越重要。 另外一个需要做接口测试的原因是在互联网时代,软件系统的开发不在遵循传统软件的开发模式,我们需要的是快速上线,快速发布。由于测试在整个软件开发流程的最后阶段,能不能快速上线,快速发布,测试能不能在保证一定质量的前提下快速完成就成为了很重要的一环。测试的工作量是固定的,要想保证一定的质量,测试的过程大幅缩短的可能是并不高。但是我们知道在移动端产品中,大部分的业务计算是放在服务端的来做的。因此,我们想到了提前测试,也就是不等到客户端开发完成,提前测试服务端接口,也就是我们说的测试前置。测试前置除了能够节省测试时间之外,还能够节省测试成本,由于接口测试阶段更接近底层,发现底层的问题的直接性更高,难度相对UI测试要低很多。所以节省测试成本,减少测试时间,也是我们做接口测试的一个重要原因。 可能看到这里会有疑问,为什么接口可以被提前测试呢。这是由接口的开发过程,以及接口的使用方式所决定的。先说接口的开发过程,开发人员在开发接口的过程中基本是按照一个依赖树的结构来进行的。接口在使用的过程中其实是有依赖的,接口A可能要依赖接口B的输出参数作为输入参数。那么开发在开发过程中,要想能够调试接口A,那就有可能需要先把B接口开发完。以此类推,开发最先开发出来的接口肯定是最基础,最底层,最没有依赖的接口。再来说使用方式,我们使用接口都是每次调用一个接口,复杂些的情况无非就是输入参数是其他接口的输出参数而已。所以当开发人员开发完成一个接口后,你就可以立即开始测试,而不用等到所有接口都完成才开始测试。基于上述原因,我们基本可以做到完成接口开发的同时,完成接口的测试工作。   3         我们为什么只介绍REST接口测试呢?首先来认识一下什么是REST 接口。REST Web 服务(也称为 RESTful Web API)是一个使用HTTP并遵循REST原则的Web服务。它从以下三个方面资源进行定义:URI,比如:http://example.com/resources/。Web服务接受与返回的互联网媒体类型,比如:JSON,XML ,YAML 等。Web服务在该资源上所支持的一系列请求方法(比如:POST,GET,PUT或DELETE)。通过上面的定义我们就能准确的知道REST接口其实就是一个Web请求,和你访问一个Web页面请求是没有任何区别的。所以大家在认识接口的时候完全可以把REST接口当做是一个Web页面请求。因为REST类型的接口已经越来越成为互联网行业通用的接口表现形式,它在使用过程中不受调用客户端语言的限制,在网络传输过程中不需要传递强类型的对象,仅仅通过网络传递字符串。基于上述特点,REST协议的接口成为了互联网中接口协议最为常用的接口方式。所以我们在这里主要介绍REST协议的接口测试。在此小结中我们已经知道了REST接口的调用本质是一次http请求。所以在我们的测试过程中,还会碰到其他一些基于MVC模式开发的web接口,这些接口可能不太符合REST要求,但是他们的本质是一致的就是http请求,在测试时候我们可以完全忽略这些表面上的东西。   4         我们怎么测试接口?从测试策略上来说我们测试接口是基于业务来测试,和从UI端做功能测试是一样的,都是测试功能业务,只不过我们更进一步使用接口来测试。前面小结也已经提到,接口是对业务处理结果的一种展现。测试实现上来说,REST接口是一个Http请求,所以对接口的测试主要是通过发送http请求,通过对比返回值来测试返回的结果是不是和我们期望的一致。不同的语言用来发送http请求的工具,类库都不太一样。我们这里以java语言为例,可以用来发送http请求的第三方包有httpclient,httpunit等,大家可以自由的选择使用。   5         我们要测试什么呢?从第四小节,我们已经知道了接口测试的基本方式。其实在我们的具体测试过程中又可以将接口的测试分为两种。单一接口的测试;多接口组合测试。 单一接口功能的测试主要测试返回的数据结构是否和接口文档给出的一致,接口的正常功能是否完成,接口的参数检查测试,接口的异常测试。 多接口组合测试,实际上是在测试一个业务流程。在测试过程中依次调用多个接口,这些接口相互依赖。这种依赖表现为接口A的输出是接口B的输入或者接口B需要接口A来修改某个状态。总之这样一个业务流程是不可能由单独的接口来完成。像这种多接口组合类的测试,我们说我们的这个测试场景ok,并不是说这个过程中的所有接口都ok就可以的。这个场景的验证点我们还是需要根据业务场景来确定。 对于中间接口的正确性却并不需要验证,因为在做多接口组合的测试之前,我们应该先保证单一接口的功能是ok的。 在测试接口的时候还是要考虑接口的业务特性,比如接口的某个参数可能有多个类型的值,每个值根据业务含义不同可能接口的返回值也是不一样的,遇到这种情况一定要根据业务设计测试点。 另外我们在对比返回值的时候一定要注意,不能只是简单的对比一下返回值了事。现实过程中有些接口的返回可能会简单到只返回一个code,但是这个接口的功能是不是正确却不一定有保证。所以我们一定要知道我们是在做测试,而不是在对比返回值。这就是接口最基本的测试方式,下面的小节我会写下一个相对完整的测试过程,供大家参考。   6         从项目角度来说,接口测试的第一步是要了解清楚和项目相关的信息。这里所说的项目信息包括以下几个方面: l  接口开发人员是谁 l  接口开始开发时间 l  接口结束开发时间 l  测试环境信息 l  数据库相关信息 l  需求文档,接口API文档 除了要获取信息外,还需要和开发人员,产品达成一些共识。这些共识包括: l  第一次提测接口的时间 l  可测接口的提交频率 l  Bug解决方式等 我们来说说这些信息,对我们来说有什么用处。开发人员,项目开始结束时间这些信息从项目角度来说,是必须的。你需要知道在测试过程中和谁交互沟通,你需要根据项目开始结束时间来安排资源。测试环境,数据库信息这些是我们接口测试的基础。需求文档,API文档这是我们接口测试的依据。第一次提测时间,是我们开始投入资源测试的时间,接口提交频率决定了我们能否在开发完成的同时完成测试。(这里说的同时是指开发在提交最后一批接口时完成了前面所有接口的测试)。开发提交可测接口的频率过低,会导致测试介入过晚。从而不能完成测试。提测频率过高,有可能会影响开发的效率.   7         我们再从测试的角度来说说在测试开始前应该做哪些事情。我们从文章开始就一直说的是接口测试,而且也说明白了接口测试其实是在做业务的测试。所以接口测试要想做好,有一项工作是基础。我们必须设计测试用例。设计测试用例的依据对于接口测试来说,主要是根据需求文档和接口API文档。前面第5小节已经说了,我们在测试接口的主旨,其实还是在测试业务。所以我们需要根据需求文档,API接口文档设计多接口组合的场景用例,单接口功能用例,接口结构检查用例。 设计好了用例,那么我们就可以开始用代码实现用例了。具体怎么实现,本文不会涉及。在这主要说说怎么来检查结果。我们的接口返回值也会有两种。一种是返回值是个常量或者叫固定值。对于这种类型的接口,我们可以采用直接对比字符串的方式来完成结果校验。另外一种接口也是最常见的接口,接口的返回值是根据数据库中的数据来返回,是不固定的。这种接口在测试时,接口的期望值也就不再是固定的而是要根据数据库的数据来动态生成。因此我们在测试过程中就必须要写代码来测试接口。   8         本篇文章到此结束,到这基本上说了接口测试怎么做。可能很多人关心的是,接口的自动化测试。自动化说简单点其实就是已经做过的事不需要重复做,接口测试想要自动化那就需要我们保存好我们的接口测试用例,并保证能在任何情况下重复使用。这是自动化的基础,后续的文章我会来阐述接口自动化应该注意些什么。 转载请注明出处。

GAT源码获取地址:https://github.com/TeamcatCorp/GAT-CODE.git  有问题可以加群,讨论。51302519

接口用例开发   1         基本要求: l  断言方法要添加断言注解@AssertStepMethodDesc l  作为用例中间步骤的方法添加Step注解:@StepsMethodDesc l  作为Setup方法使用的添加注解@SetupStepMethodDesc l  作为Teardown方法使用的添加注解@TearDownMethodDesc l  注解属性不能为空   2   语法要求: l  尽量避免使用硬编码,参数使用尽量参数化 l  避免重复代码,提高代码复用性。原则上同一段代码不得出现两次。此条根据个人能力自行决定。 l  正确使用注解 l  方法,用例名称能够表达方法功能 l  StepMethod方法不应该是static或其他类型方法,只能是一个无返回值的public 方法   3         结果检查要求: l  每个接口返回的Json字符串结构中90%以上的字段必须验证。 l  每个接口的返回结果都必须验证。 l  接口的每个参数必须有一条与之对应的用例。   4     用例设计依据: l  API文档 l  产品需求设计文档,根据产品需求文档设计用例 l  根据已有功能点,设计接口测试用例。   5     用例的执行 l  用例开发完毕后,每天提交到svn,并在jenkins上建立任务定时运行。   6         用例的维护 l  每日运行一次用例,对失败的用例做到当天分析,当天处理,保证用例可用。 l  开发的用例必须保证能够重复运行,拒绝只能执行一次用例。   7     用例Review l  不定时对用例设计,用例实现做评审(本条仅针对服务端测试)   8      测试结果评价: l  功能测试过程中发现的所有服务端bug视为服务端测试的漏测,漏测率目标10%。 漏测率=漏测的bug数/服务端测试bug数。(本条仅针对服务端测试)    

   基于WebDriver的web自动化 GAT框架的功能分为2个部分,一部分就是文档之前的章节一直在说明的的接口自动化用例的开发。另外一部分就是之前有提到过的基于WebDriver的Web UI自动化用例开发。从本节开始我将会来说明怎么用GAT来开发Web UI自动化用例。 4.1  Web UI用例的开发架构      WebUI用例的开发结构和接口自动化用例的开发架构基本一致。具体接口请看下图。 l  与接口用例的共同点:如果大家还记得我们接口用例的开架构的话,可以看出我们的接口用例的所有代码,数据文件都是放在InterfaceAutomation这个文件夹下的。而我们的Web自动化的所有代码,数据文件是放在UIAutomation这个文件夹下的。同时,接口用例和UI自动化用例共同使用Libs文件夹作为第三方公共jar包的存放位置。请注意Libs这个文件夹是公用的,所以需要保持这样的目录结构不变。另外UI用例的开发目录中的文件夹的作用基本和接口用例开发目录中的文件夹作用是一致的。通过文件夹名称相信大家能够明白。当然目录的名字都是可以变化的,具体怎么来设置我会在以后的文章中统一作出说明。   l  与接口用例的不同点:UI自动化用例开发目录下的在DataFiles文件夹中只有Xmls这一个文件夹,接口用例的开发目录中除了Xmls这个文件夹之外,还有Excels这个文件夹。大家看到这不要以为是漏掉了Excel文件夹,是我们的UI自动化用例开发架构中确实没有也不需要有Excel文件夹。 4.2 开始写第一个Web UI自动化用例   1  数据文件       在写之前先来看看Web UI自动化用到的几个数据文件。 l   Paramters.xml,此文件和我们写接口测试用例的时候的用途是一致的,而且文件结构,属性  都是一致的,也就是说是通用。在此不多说。 l   TestCase.xml 此文件也和接口用例中用到的文件一致,文件结构属性都通用,只不过多出来了一个属性请看下图。 l     如上图红框中所示,Web UI 自动化中用的.TestCase.xml文件与接口中TestCase.xml文件唯一的不同是多了<UIElementsFilePaht>元素,这个元素用来表示这个文件中用到的页面元素存放的位置。大家应该知道WebUI自动化由于需要操作页面元素,因此需要再多一个文件来存放这些页面元素属性。这就是关于WebUI自动化中用到的TestCase.xml文件。和接口自动化一样,WebUI的自动化的TestCase.xml文件也必须以TestCase.xml结尾,否则不能够通过GatRunner生成单元测试用例。 l   UIElements.xml:这个文件时WebUI自动化专有的文件。下面我将通过一个示例文件来一一说明这个文件的结构,以及属性。 下面我一步一步来给大家介绍文件的结构以及属性 ²  <AllUIElements>:此元素每一个UIElements.xml文件仅有一个,是所有元素的Root元素。 ²  <UIElement>: 此元素每一个文件可有多个,此元素用来存放要操作的页面元素的识别信息。一个<UIElement>元素仅代表一个要操作的页面元素信息。下面继续介绍此元素的属性。 ü   NodeID:用来表示此元素在文件中的位置,仅仅用来在UIElements.xml文件中查找<UIElement>这个元素使用,并不表示页面元素在网页中的ID. ü   ControlType:要操作的这个元素的类型,这个可能比较不太容易理解。在GAT框架里对最基本的页面元素都做了分类,有TextBox,CheckBox,Button等等。每一种类型都对应了一个类。这个ControlType的值也就是一个类名称。这个值可以是我们框架里定义的最基本的类型,也可以是你自己定义的一个类。最基本类型的值可以自行查看API文档中com.gateside.autotesting.Gat.uia.webautomation.webcontrols 这个 package中的类。所有基本类型都在这个类中。 ü   WindowType:这个属性表示要操作的元素是在主窗口还是子窗口上,因为有可能在自动化过程中打开新的窗口,新打开的窗口称为子窗口。 可用值:MainBrowser,ChildBrowser. 不过在实际使用过程中这个属性很少用,我们提供了其他更好的方法做到这一点,因此建议这  个属性就默认保持“MainBrowser”代表主窗口即可。如果此属性选择了ChildBrowser,需要配合WindowName属性使用。 ü   WindowName:当WindowType选择了ChildBrowser的时候需要填写此属性。此属性代表了浏览器窗口的Title或者ID。 ü   FrameType:表示要操作的元素是否是在Frame或者IFrame中。 可用值:DefaultPage,FramePage. 如果要操作的元素不再任何frame中使用DefaultPage即可。如果元素在frame中使用FramePage。如果此属性使用了FramePage,就必须配合后面的IFrameName,IFrameIndex使用。 ü   IFrameName: 是值IFrame的id,name等属性,在此只需要填写能唯一确定iframe的值即可或者name或者ID.如果要操作的元素在嵌套的iframe中。只需要在此按照iframe嵌套的顺序添加iframe的id或者name,用逗号分隔iframe唯一标示信息即可。在此填写了iframe信息,在操作元素过程中就完全不需要再操心元素在哪个iframe中了。 ü   IFrameIndex:有时候有些iframe没有id,name等属性只能通过index来获取iframe. ü   ID:页面元素的ID ü   Name:页面元素Name ü   Xpath:页面元素的xpath ü   CssSelector:Css样式选择器,可以使用Selenium IDE获得 ü   InnerText:Text属性 ü   LinkText:仅仅针对<a></a>超链接元素 ü   TagName:通过TagName获取元素,返回第一个值 ü   ClassName:通过ClassName定位元素,返回第一个值 ü   PropertyName,PropertyValue:其他元素属性 需要说明的是,以上用于定位元素的属性,仅填写一个能够定位元素的值即可,其余均可留空,不需要都写。   2 代码文件   1)         用例代码:用例代码的表现形式是基于Testng的单元测试代码,一个TestMethod代表了一个用例。当然了这个用例代码是不需要你自己去写的,和接口用例一样,我们可以通过GatRunner根据TestCase.xml生成。后面我们再介绍使用GatRunner生成WebUI自动化用例时应该注意的点。WebUI生成的测试用例工程名字是WUATTestProject。所有的测试用例代码都在这个Project中。 2)         StepMethod代码:使用过GAT的人都知道,我们自己写的代码都是以StepMethod的形式存在的。WebUI 的StepMethod的代码写法与接口的StepMethod的写法一致,概念,使用方式都是一致的。还记得我在前面的文档里写过,如果你会写多接口组合的用例那么你就会写一般的WebUI自动化用例了,说的就是无论概念还是代码的写法都是一致的。StepMethod代码存放在WUATStepGroup工程下。命名规则,什么的请参考接口的要求即可。唯一不同的就是StepMethod方法的参数类型,以及个数不同。具体请看下面一小节 3)      Step代码示例: 下面代码是用来打开百度首页,并输入搜索关键字,然后点击搜索的一个操作模块。我来一句一句的解释一下每一个句话的含义及功能。   publicclass GameHomePageSteps { @WUATStepMethodDesc publicvoid search(WebBrowser browser,WebPage webPage,String parameterID) throws Exception { WebUIStepParameter parameter=(WebUIStepParameter)ParameterHelper.getWebUIStepParameter(parameterID); browser.navigateTo(“http://www.baidu.com”,180); webPage.getWebControll(“Test01”).action(“inputText”).exec(parameter.getValue(“searchkeyword”)); if(parameter.parameters.contains(“click”)) { webPage.getWebControll(“Test02”).action(“click”).exec(); } }   } …..

创建接口自动化任务 1 开打接口自动化专用的Jenkins网站http://172.23.237.169:8080/jenkins/ 2 点击新建,添加任务 l 输入Job名称(红圈位置) l 选择构建一个自由风格的软件项目(小红圈位置) l 最后点击OK 1 配置新任务 1)源码管理配置 l 源码管理方式选择Subversion l 添加IATTestProject源码地址,及本地目录名称(IAT/IATTestProject) l 添加Libs源码地址,及本地目录名称(IAT/Libs) l 添加DataFiles源码地址,及本地目录名称(IAT/DataFiles) l 添加IATStepGroup源码地址,及本地目录名称(IAT/IATStepGroup)   2) 构建配置 l 添加构建IATStepGroup步骤 点击增加构建步骤,选择Invoke Ant步骤,最后点击高级按钮 l 添加执行Testng用例构建步骤 点击增加构建步骤,选择Invoke Ant步骤,最后点击高级按钮 l 在Build File框中填入要执行的ant build 文件名称 3)构建后操作 点击增加构建后操作步骤,选择Publish TesgNG Result l 在TestNG XML report pattern 中输入上图中的字符即可 l 点击保存结束任务创建。 2 执行任务前准备: 1) 使用Gatrunner生IATTestProject 目录结构如下 2) 复制生成的testng.xml,并根据要执行的测试用例创建自己的tesgngxxx.xml文件 3) 复制build.xml文件生成自己的buildxxx.xml.生成自己的buildxxx.xml文件需要修改以下地方。(红圈位置) l 将红圈1中的内容替换为,你刚才创建的jenkins job名称 l 将红圈2中testng.xml替换为你刚才创建的testngxxx.xml l 保存文件,并上传到SVN 4) 修改IATTestProject下的gatConfig.properties 将rootDir的值修改为如上图所示,也就是将值留空   5) 修改IATStepGroup目录中的build文件 复制现有的build文件,并重命名为你自己的build文件,修改文件中一下内容。 l 将红圈1中的内容替换为,你刚才创建的jenkins job名称 l 将红圈2中的内容替换为,你刚才创建的jenkins job名称 l 保存文件,并上传到SVN   3 完成上述操作后,就可以在jenkins上运行创建的任务,并查看结果。 4 查看任务运行结果: 1) 在任务运行完成后,点击要查看的任务构建历史 2) 进入任务执行历史后,点击TestNGResults,即可看到如下图 3) 点击具体用例,还能看到测试用例失败的原因及日志。 4) 如果还想自动把测试用例的执行结果发出来,其实主要想办法把IATTestProject\test-output文件夹下的emailable-report.html的内容作为邮件发出来即可。如果要让jenkins发出来,可能需要你自己写插件才行。  

3.3 多接口用例的开发 多接口组合的用例是一种更加普遍的试用场景,尤其是移动端的接口测试。因为移动端业务逻辑都在接口服务端实现,因此需要我们试用多个接口组合来完成一个业务逻辑的测试。接下来的我们来看看怎么样开发多接口组合的用例,在此假定你已经能够开发单一接口的用例,对框架的开发架构都已经熟悉。 1)和单一接口用例的差别 存储形式:单一接口中,数据,用例都是存放在Excel文件中,一行为一个测试用例。多接口组合的用例,用例和数据分别单独存放在不同的xml文件里。 断言方式:单一接口的断言方式分为固定断言方式和自定义断言方式。固定断言方式包括相等断言和包含断言两种。自定义断言方式主要通过自己编写断言代码来完成。对于多接口组合用例来说断言方式都是自定义的,都需要自己开发代码来完成。 用例的组成:单一接口用例因为只有一个接口,因此只用Excel中的一行就能代表一个用例。对于多接口组合的用例来说,每一个用例都是由多个步骤组合而成,也就是说由多个Step方法组合完成。 2)和单一接口用例的共同点: 用例数据:用例数据都是存放在xml中,而且存放数据的规则,xml格式,xml中标签的含义都是完全一致的。 用例的生成:都已通过执行GatRunner来完成。 3)多接口用例的组成部分 用例描述文件: 用例描述文件是一个以TestCase.xml结尾的xml文件,注意一定要以TestCase.xml结尾,这是多接口组合用例的标示,否则在执行GatRunner的时候将不能生成用例。 下图就是一个示例性的用例描述文件。 一个用例描述文件,也就是一个TestCase.xml文件可以包含很多个测试用例,不再像单一接口用例限定一个excel sheet只能编写一个接口的用例。接下来我们解释一下用例描述文件中的标签。 :每一个用例描述文件有且仅有一个这样的标签,用例相关的信息都要放在这个标签内。 :上图中第一个红框内的标签,这个标签中的内容:标示的是组成用例的每一个Step方法使用的数据存放在哪个文件中。这个标签是对用例描述文件中Step方法数据存放文件的全局描述。另外这个标签也可以做为TestCase,Step等标签的属性来为单个TestCase或者单个Step定义自己专属的配置。在Step,TestCase都有这个属性的情况下,框架读取配置的优先级是Step的配置优先于TestCase,TestCase优先于全局配置,对于其他全局配置而言,这个优先级同样适用。对于全局配置标签而言,一个文件只能有一个。 :上图红框中的第二个标签。这个标签也是一个全局配置标签。表示在这个用例描述文件里,所有用到的Step方法都在这个包里。这个全局配置也可以作为TestCase,Step的属性。注意这个标签的值最后的小点别忘记了。 :上图红框中第三个标签。这个标签同样是一个全局配置标签。虽然叫StepGroup,其实代表的是在这个用例描述文件中,所有用到的Step方法都在这个类中。这个全局配置也可以作为TestCase,Step的属性。 :上图红框中第四个标签.这个标签代表了一个用例。ID属性是他的唯一标示,因此不能重复,Name属性同样不能重复。它还有Step子标签,我们前面说过了,一个用例是多个Step组成的,因此一个用例可以有多个Step标签。 :这个标签代表了一个用例的一个步骤。StepName:属性是一个StepMethod的名称,StepParameterID是这个StepMethod用到的数据在全局配置中提到的文件中的ID标示。当然如果你自己为Step设置了StepParametersFilePath这个属性,那么这个ID就是你自己设置的这个文件中的ID了。 最后总结一下:多接口用例是由多个自定义的方法组成,这个用例由那些方法组成,以及用到了那些数据这些信息最后会存放在一个用例描述文件中。当你编辑完一个用例描述文件后,你就可以使用Gatrunner来生成具体的代码到IATTestProject中了。 数据文件:也就是Parameter.xml文件这个文件要和TestCase.xml文件一样都放在开发架构中的DataFiles\Xmls文件夹下。文件的具体结构和单一接口中的Parameters.xml文件一致。在这里就不多说了。 代码的写法: public class DemoStep { @StepMethodDesc(description=””,owner=”tiande.zhang”) public void Step1(String parameterID) throws              Exception { InterfaceStepParameter parameter=(InterfaceStepParameter)ParameterHelper.getInterfaceStepParameter               (parameterID); WebConversation currentConversation=HttpUnitHelper.createConversation(); WebRequest currentReques t=HttpUnitHelper.createWebRequest(parameter.getValue(“url”),parameter.ge               tValue(“httpmethod”)); HashMap<String, String> urlParameters=parameter.getURLParametersMap(); if(urlParameters.size()!=0) { HttpUnitHelper.setParameters(currentRequest,urlParameters); } WebResponse response=currentConversation.getResponse(currentRequest); System.out.println(response.getText()); StepValuePool.createInstance().getValueDic().put(“doubiToken”,response.getText()); } @StepMethodDesc(description=””,owner=”tiande.zhang”) public void Step2(String parameterID) throws Exception { System.out.println(parameterID+StepValuePool.createInstance().getValueDic().get(“doubiToken”).toString()); } @AssertStepMethodDesc(description=””,owner=”tiande.zhang”) public void Step3(String parameterID,String expectResut,String actualResult) { SimpleLogger.logInfo(this.getClass(),actualResult); } 代码的整体写法和为单一接口写断言方法是一致的,都是写在IATStepGroup中。 Step方法都是无返回值的,而且只接受一个参数那就是parameterID.切记只有一个String型的参数,参数个数类型都不         能随意别更,否则会出错。 所有Step方法,断言方法都要加相应的注解,否则可能服务被调用。切记 总结:以上部分就是在业务无关的情况下,代码部分我们要注意的地方。 4)多接口组合用例用到的类,方法 在我们做多接口组合的用例的时候,搜索的事情都需要我们自己写代码完成。包括发送http请求,设置http请求参数          ,解析对比返回值等等。为了方便大家,框架本身提供了大部分的帮助类来帮助大家完成工作。当然你也可以自己写这           些类来完成工作。 …..

3.2接口用例场景组件 在此之前,大家应该都已经开发完成了一个最简单的接口测试用例,但是之前的接口用例的期望结果是固定值,不能动态的去做对比,有很大局限性。下面开始介绍怎样通过场景组件来动态对测试结果做断言。(以下步骤的前提是你已经完成了3.1小结中的简单测试用例。)   1)         单一接口用例的断言组件 l   第一步:在eclipse中导入IATStepGroup,根据你自己的接口功能模块添加新的package包.本例中我添加的package名字:cn.gateside.iat.steps.demo   l   第二步:在新建的package下添加场景组件类。类名称建议以接口的名称+Steps作为你的场景组件类名称。本例中我添加的场景组件类名称为:UserInfoSteps.java   l   第三步:添加好场景组件后,开始添加场景组件方法。在UserInfoSteps.类中添加如下代码: @AssertStepMethodDesc(description=””,owner=””) publicvoid asserUserInfo(String parameterID,String expectResut,String actualResult) throws Exception { InterfaceStepParameter parameter=(InterfaceStepParameter)ParameterHelper.getInterfaceStepParameter(parameterID); JSONObject object=JSONObject.fromObject(actualResult); MysqlDBOperationService service=new MysqlDBOperationService(parameter.ConnectiongString); List<List<String>> resultSet= service.executeQuery(parameter.getValue(“announcerInfoSql”),parameter.getValue(“user”),parameter.getValue(“password”)); assertEquals(object.keys(), resultSet.size()-1,”!!!the announcer number from interface is different from the number from database!!!”); } 以上是一个最常用的断言场景组件的写法。接下来解释上述方法中的每一行。这里说到的每一行是指一行代码,请忽略换行,以及花括号。   H1:是断言方法的注解,包含两个参数description(方法功能描述),owner(方法的开发人员)   H2:场景组件方法定义,需要注意的是断言组件方法会有三个参数,分别表示这个方法中用到的数据的存储ID,期望结果,以及用例的实际结果。   H3:第三行是用来获取方法中用到的数据,根据parameterID从存储数据的xml文件中读取。此行可以照抄,如果没有用到数据可以不写此行。   H4:是将实际结果转换成Json对象,如果实际结果不是json字符串,请用相应的处理格式来处理。   H5,H6:两行是用来从数据库查询出期望的结果和实际结果做对比。对于H5行来说只有一个参数ConnectionString,在此是指JDBC链接字符串。H6行中三个参数,第一个只是要执行的sql语句,后面两个是访问数据库需要的用户名和密码。另外H6返回值是一个二维的list.resultSet.get(0)代表的是查询结果的column name.   H7:对实际结果以及查询到的期望结果做断言。   2)   断言场景组件的使用 完成自己的场景方法后,接下来介绍怎么使用。首先需要知道我们完成的场景方法的全名是什么。 l  场景方法全名:cn.gateside.iat.steps.demo.UserInfoSteps.asserUserInfo,也就是之前提到的pacakge.class.method l  现在来看怎么使用我们的场景方法,先打开你在excel中创建的用例,将AssertType的值改为Custom.然后修改AssertMethod的值为cn.gateside.iat.steps.demo.UserInfoSteps.asserUserInfo:Test01 l  到这一步的时候,很多人可能不明白AssertMethod的值里面【:Test01】的意思,这一段表示这个场景方法用到的数据在xml中的存储ID.这个ID也就是在你开发场景方法的时候的第一个参数parameterID. l  接下来看看,parameterID这个参数指定的数据是存放在哪里,对于Excel形式的用例,parameterID所指定的数据是存放在与Excel同名的xml文件里的。所以在我们示例中开发的场景方法用到的数据必须都放在xml中。 |  在运行你的用例之前,要做的一件事就是修改IATStepGroup项目下的build.xml文件。将下图中红框里的路径修改为你本地的Libs的路径。修改完成后,将IATStepGroup编译打包成jar文件   l  准备好数据后,就可以运行你的用例,注意如果只是修改了数据不需要重新执行GatRuner生成用例。