月份归档 » 2014 / 12

  Hudson持续集成插件开发环境搭建 这边文章是我2年前发表在百度文库的,最近又帮别人搭建来着。做了些小调整,希望能有用。 一年前自己从无到有的开始接触Hudson,开始接触持续集成。当时我花了两个星期来研究hudson(由于以下问题现在已经改名叫jenkins)并写出了第一个插件,切成功运行,再后来持续研究将编译,环境同步,自动化任务运行等几个内部系统也都通过开发插件的方式集成到一起,做起了公司持续集成的第一个简单版本。再后来交给其他同事继续开发维护。如今同事离职,这事又落到我头上。今天本人又开始搭建hudson插件的开发环境。有些心得,希望纪录下来,希望也能帮我需要的人。   我没有直接安装mavn,eclipse等开发工具,而是先搭建起一个简单的hudson系统。在你开始之前请先确保你 能连上互联网下载东西。 第一步安装java jdk,至于版本的话推荐1.6以上吧。安装好jdk设置环境变量,确保你在cmd中输入java -version有提示你jdk的版本信息等,也就是说确保java jdk能用。如果你连这个都搞不定那就不用继续了。   第二步安装tomcat,这个很简单下载一下,地址自己百度一下。我是在windows上做的所以直接下载了tomcat的可安装版本。安装后自己启动即可。如果启动不了,你可以卸载了,重新已管理员权限再安装即可启动。启动后,在浏览器输入:http://localhost:8080,如果正确打开页面则正常。   第三步安装hudson,其实hudson不需要安装就是一个war包,从网站上下载了,然后放到tomcat下面的webapps文件夹下即可。再次在浏览器输入http://localhost:8080/{你放到webapps下面的war包的名称},即可看到hudson的页面。例如我放到webapps文件下的的war包名称是jenkins,我在浏览器里输入的就是http://localhost:8080/jenkins   第四步安装maven,下载maven后解压缩放到你Apache Software Foundation目录下,这个不是绝对的只是我习惯这么放。然后添加环境变量M2_HOME,然后在path中添加%M2_HOME%\bin即可。在cmd窗口中输入mvn -version 如果提示你了版本信息什么的就算对了。   第五步打开cmd 输入mvn -hpi:create(mvn -U org.jenkins-ci.tools:maven-hpi-plugin:create)然后回车,如果最后没有提示build success。那么你需要做两件事,第一件事就是在你的用户目录下找到.m2这个文件夹。在settings文件中添加 <settings> <pluginGroups> <pluginGroup>org.jenkins-ci.tools</pluginGroup> </pluginGroups>   <profiles> <!– Give access to Jenkins plugins –> <profile> <id>jenkins</id> <activation> <activeByDefault>true</activeByDefault><!– change this to false, if you don’t like to have it on per default –> </activation> <repositories> <repository> <id>repo.jenkins-ci.org</id> <url>http://repo.jenkins-ci.org/public/</url> </repository> </repositories> <pluginRepositories> <pluginRepository> <id>repo.jenkins-ci.org</id> <url>http://repo.jenkins-ci.org/public/</url> </pluginRepository> </pluginRepositories> </profile> </profiles> <mirrors> <mirror> <id>repo.jenkins-ci.org</id> <url>http://repo.jenkins-ci.org/public/</url> <mirrorOf>m.g.o-public</mirrorOf> </mirror> </mirrors> </settings> 如果你的.m2文件夹下没有setting.xml文件那就自己建一个,然后输入上述信息,并保存。 第二件事找到 $M2_HOME/conf/settings.xml file文件将上面的settings内容替换掉然后保存。   再次在cmd中运行mvn -hpi:create,这次会下载很多东西,、 等下载完输入你要创建的插件的项目名称也就是你要在eclips中编辑的项目。最后会提示你build success。 恭喜你你的第一个hudson插件完成了。当然这个插件什么都没有,如果你想开发的话,还需要完成最后一步。   最后一步:在cmd中切换到你刚才创建的插件目录中,运行$ mvn package。 如果是初次运行这句话,那也会下载好多东西。耐心等待吧。 完成后运行 mvn -DdownloadSources=true -DdownloadJavadocs=true -DoutputDirectory=target/eclipse-classes eclipse:eclipse 完成以上几步后,再打开eclips,选在import,再打开的窗口中选择导入一个已经存在的项目。 跟着向导将你刚才创建的插件项目的目录选中,点击完成就可以了。 到这就恭喜你完成了你的第一个hudosn插件的创建以及插件开发环境的搭建。  

接口用例开发   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(); } }   } …..