月份归档 » 2015 / 06

        测试所扮演的角色或者说测试的工作方式,受到很多因素的影响。例如测试资源的充足程度,开发的模式,开发的资源充足程度等。一般常见的测试工作方式有两种,一种是固定的测试人员,固定的产品,固定的开发人员,不断的迭代一个产品或者产品的衍生版本。还有一种方式就是什么都不固定,测试,开发都是一种服务,根据服务空闲时间,随时被调用。          上面已经提到了测试工作方式的两种方式,接下来说说这两种方式的好处及不足。暂且把第一种方式叫做独占模式,第二种叫服务模式。           对于独占模式好处有以下几个:          1   产品固定,测试人员有时间从需求阶段就介入整个产品的生产过程,对产品的背景,演变过程了如指掌。对于产品的理解程度,决定着测试的效率,发现问题的层次。对于开发人员来说,由于长时间开发一款产品,对于产品的代码架构理解更深刻,代码熟悉程度更高,也就意味着代码bug率会更低,及时有问题,bug修复的速度也会是非常快的。        2 从人员主动性的角度来说,由于只做一个项目责任很明确,做的版本越多,这种责任性越强,到最后基本是以一种这是我的项目的思维来做测试或者开发,做事的效率,质量都会有很大程度的提升。另外一个项目从开始到最后上线,这个过程是一个很有节奏的过程,有快有慢,做事张弛有度,会有一定的舒缓作用。        3 由于长时间做同一个产品,无论是开发还是测试都会从技术改进,流程改进的角度去做一些工具,平台等。        4   能够有效的降低管理成本,独占模式中人员的责任心,积极性都相对来说有很大提高,自我管理会在工作过程中占据主导作用。        5   从项目的角度来说,独占模式下项目的周期可以在需要的时候,通过项目成员的努力大大缩短。       接下来再来说说独占模式的问题:        在于对于开发人员来说,长时间做一个项目会有技术疲劳,对于喜欢挑战的人来说可能是比较痛苦的,同样对于测试人员来说,长时间做一个项目也会测试疲劳。尤其是测试人员,测试疲劳可能会导致一部分问题的漏测。        服务模式来说,它的好处主要是资源利用率比较高,对于项目发展不是特别明确,但是项目又比较多的组织来说更加的节省成本。服务模式带来的好处更多的体现在资源效率上,这里说的资源效率的提高主要是指可以更好的利用开发测试人员的时间,保证项目不会因为暂时的资源缺失,导致项目进度停滞。但是从项目,人员的角度来说又会带来一些问题:     1   首先是管理成本,需要一个人来分配调度资源的使用。怎么样能够更加公平,有效的调度资源这对资源的管理人员来说是个挑战。如果不能够做到公平,服务模式的运转会受到很大影响。    2   对项目来说,开发,测试人员的变换,意味着开发效率,开发质量,测试效率的降低。    3   由于是服务性质的,高效,快速的完成项目意味着很快需要投入到另外一个项目,因此在评估项目周期的时候,会不自觉地延长。即使项目进度会比预期的好,很多情况下也不会出现提前完成这种事。所以对于项目来说,很难说服务模式是提高了效率。   4    做项目的过程中,大家应该都会遇到已经上线了的项目,出现突发情况的。出现了问题,服务模式下是不会有人主动站出来说我来搞定。这时候就需要负责资源调度的人来,紧急调度资源处理这些问题。前面提到的公平这件事,在这个时候就会体现出很大的作用,如果你之前在调度资源的时候不够公平,那么之后需要紧急处理问题的时候,再想调度资源可能就比较困难了。    5   服务模式下,大家在工作过程中大部分都会有一种很机械的感觉,对于一些有想法,想要学习更多东西的人来说,时间长了就不太能接受这种工作方式,如果团队不能够给出合理的解决方式可能会导致团队的不稳定。      以上两种模式各有优缺点,所适应的组织特点也不同。对于资源充足的公司来说,一般都会使用独占模式工作,这也是为什么大公司无论测试还是开发,还是其他角色,技术深度,广度都很不错的原因。对于服务模式来说更适合需要节省成本的公司。使用服务模式,那就需要一个优秀的资源管理者,能够平衡服务型团队的优势以及它天然的缺点。以上观点有不足之处,欢迎指正。

HttpClient使用详解 Http协议的重要性相信不用我多说了,HttpClient相比传统JDK自带的URLConnection,增加了易用性和灵活性(具体区别,日后我们再讨论),它不仅是客户端发送Http请求变得容易,而且也方便了开发人员测试接口(基于Http协议的),即提高了开发的效率,也方便提高代码的健壮性。因此熟练掌握HttpClient是很重要的必修内容,掌握HttpClient后,相信对于Http协议的了解会更加深入。 一、简介 HttpClient是Apache Jakarta Common下的子项目,用来提供高效的、最新的、功能丰富的支持HTTP协议的客户端编程工具包,并且它支持HTTP协议最新的版本和建议。HttpClient已经应用在很多的项目中,比如Apache Jakarta上很著名的另外两个开源项目Cactus和HTMLUnit都使用了HttpClient。 下载地址: http://hc.apache.org/downloads.cgi 二、特性 1. 基于标准、纯净的java语言。实现了Http1.0和Http1.1 2. 以可扩展的面向对象的结构实现了Http全部的方法(GET, POST, PUT, DELETE, HEAD, OPTIONS, and TRACE)。 3. 支持HTTPS协议。 4. 通过Http代理建立透明的连接。 5. 利用CONNECT方法通过Http代理建立隧道的https连接。 6. Basic, Digest, NTLMv1, NTLMv2, NTLM2 Session, SNPNEGO/Kerberos认证方案。 7. 插件式的自定义认证方案。 8. 便携可靠的套接字工厂使它更容易的使用第三方解决方案。 9. 连接管理器支持多线程应用。支持设置最大连接数,同时支持设置每个主机的最大连接数,发现并关闭过期的连接。 10. 自动处理Set-Cookie中的Cookie。 11. 插件式的自定义Cookie策略。 12. Request的输出流可以避免流中内容直接缓冲到socket服务器。 13. Response的输入流可以有效的从socket服务器直接读取相应内容。 14. 在http1.0和http1.1中利用KeepAlive保持持久连接。 15. 直接获取服务器发送的response code和 headers。 16. 设置连接超时的能力。 17. 实验性的支持http1.1 response caching。 18. 源代码基于Apache License 可免费获取。 三、使用方法 使用HttpClient发送请求、接收响应很简单,一般需要如下几步即可。 1. 创建HttpClient对象。 2. 创建请求方法的实例,并指定请求URL。如果需要发送GET请求,创建HttpGet对象;如果需要发送POST请求,创建HttpPost对象。 3. 如果需要发送请求参数,可调用HttpGet、HttpPost共同的setParams(HetpParams params)方法来添加请求参数;对于HttpPost对象而言,也可调用setEntity(HttpEntity entity)方法来设置请求参数。 4. 调用HttpClient对象的execute(HttpUriRequest request)发送请求,该方法返回一个HttpResponse。 5. 调用HttpResponse的getAllHeaders()、getHeaders(String name)等方法可获取服务器的响应头;调用HttpResponse的getEntity()方法可获取HttpEntity对象,该对象包装了服务器的响应内容。程序可通过该对象获取服务器的响应内容。 6. 释放连接。无论执行方法是否成功,都必须释放连接 四、实例 [java] view plaincopy package com.test;      import java.io.File;   import java.io.FileInputStream;   import java.io.IOException;   import java.io.UnsupportedEncodingException;   import java.security.KeyManagementException;   import java.security.KeyStore;   import java.security.KeyStoreException;   import java.security.NoSuchAlgorithmException;   import java.security.cert.CertificateException;   import java.util.ArrayList;   import java.util.List;      import javax.net.ssl.SSLContext;      import org.apache.http.HttpEntity;   import org.apache.http.NameValuePair;   import org.apache.http.ParseException;   import org.apache.http.client.ClientProtocolException;   import org.apache.http.client.entity.UrlEncodedFormEntity;   import org.apache.http.client.methods.CloseableHttpResponse;   import org.apache.http.client.methods.HttpGet;   import org.apache.http.client.methods.HttpPost;   import org.apache.http.conn.ssl.SSLConnectionSocketFactory;   import org.apache.http.conn.ssl.SSLContexts;   import org.apache.http.conn.ssl.TrustSelfSignedStrategy;   import org.apache.http.entity.ContentType;   import org.apache.http.entity.mime.MultipartEntityBuilder;   import org.apache.http.entity.mime.content.FileBody;   import org.apache.http.entity.mime.content.StringBody;   import org.apache.http.impl.client.CloseableHttpClient;   import org.apache.http.impl.client.HttpClients;   import org.apache.http.message.BasicNameValuePair;   import org.apache.http.util.EntityUtils;   import org.junit.Test;      public class HttpClientTest {          @Test       public void jUnitTest() {   …..

这里的第一篇博文用于简单的介绍一个平日工作中用得很爽的插件–Postman 在chrome应用商店里面可以搜索到,火狐我没有搜到,不知道有没有,还是说是另一个名字。 应用商店地址:https://chrome.google.com/webstore/search/postman?t=http://webstore.google.com 插件的操作很简单,下面是一些简单的实例。 1.安装 在谷歌应用商城搜索postman,如下图1-1所示: 1-1 Chrome应用商城截图 其中蓝色的是网页版,黑色的是桌面版,推荐下载桌面版,原因为可以使用账号同步,这个功能非常爽,之后会介绍到。 2.主界面,如下图2-1所示: 2-1主界面 左边是浏览历史(History)与收藏夹(Collection)、新建文件夹按钮与导入按钮。右边为请求地址、请求方式、请求参数与结果的展示界面。 3.请求结果,如下图3-1所示: 3.1请求结果示例图 在填写好地址与请求方式后,点击send就可以发送请求,下方即展示返回的结果,并且可以根据不同的数据(json、xml)进行格式化展示。 4.添加参数,如下图4-1所示: 4-1添加参数示例图 当选择请求方式为POST的时候,下方会出现填写参数的地方,参数可选择是文件还是值。 5.添加到收藏,如下图5-1所示:  

引言 HTTP是一个属于应用层的面向对象的协议,由于其简捷、快速的方式,适用于分布式超媒体信息系统。它于1990年提出,经过几年的使用与发展,得到不断地完善和扩展。目前在WWW中使用的是HTTP/1.0的第六版,HTTP/1.1的规范化工作正在进行之中,而且HTTP-NG(Next Generation of HTTP)的建议已经提出。 HTTP协议的主要特点可概括如下: 1.支持客户/服务器模式。 2.简单快速:客户向服务器请求服务时,只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单,使得HTTP服务器的程序规模小,因而通信速度很快。 3.灵活:HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。 4.无连接:无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求,并收到客户的应答后,即断开连接。采用这种方式可以节省传输时间。 5.无状态:HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息,则它必须重传,这样可能导致每次连接传送的数据量增大。另一方面,在服务器不需要先前信息时它的应答就较快。   一、HTTP协议详解之URL篇     http(超文本传输协议)是一个基于请求与响应模式的、无状态的、应用层的协议,常基于TCP的连接方式,HTTP1.1版本中给出一种持续连接的机制,绝大多数的Web开发,都是构建在HTTP协议之上的Web应用。 HTTP URL (URL是一种特殊类型的URI,包含了用于查找某个资源的足够的信息)的格式如下: http://host[“:”port][abs_path] http表示要通过HTTP协议来定位网络资源;host表示合法的Internet主机域名或者IP地址;port指定一个端口号,为空则使用缺省端口80;abs_path指定请求资源的URI;如果URL中没有给出abs_path,那么当它作为请求URI时,必须以“/”的形式给出,通常这个工作浏览器自动帮我们完成。 eg: 1、输入:www.guet.edu.cn 浏览器自动转换成:http://www.guet.edu.cn/ 2、http:192.168.0.116:8080/index.jsp    二、HTTP协议详解之请求篇     http请求由三部分组成,分别是:请求行、消息报头、请求正文 1、请求行以一个方法符号开头,以空格分开,后面跟着请求的URI和协议的版本,格式如下:Method Request-URI HTTP-Version CRLF 其中 Method表示请求方法;Request-URI是一个统一资源标识符;HTTP-Version表示请求的HTTP协议版本;CRLF表示回车和换行(除了作为结尾的CRLF外,不允许出现单独的CR或LF字符)。 请求方法(所有方法全为大写)有多种,各个方法的解释如下: GET     请求获取Request-URI所标识的资源 POST    在Request-URI所标识的资源后附加新的数据 HEAD    请求获取由Request-URI所标识的资源的响应消息报头 PUT     请求服务器存储一个资源,并用Request-URI作为其标识 DELETE  请求服务器删除Request-URI所标识的资源 TRACE   请求服务器回送收到的请求信息,主要用于测试或诊断 CONNECT 保留将来使用 OPTIONS 请求查询服务器的性能,或者查询与资源相关的选项和需求 应用举例: GET方法:在浏览器的地址栏中输入网址的方式访问网页时,浏览器采用GET方法向服务器获取资源,eg:GET /form.html HTTP/1.1 (CRLF) POST方法要求被请求服务器接受附在请求后面的数据,常用于提交表单。 eg:POST /reg.jsp HTTP/ (CRLF) Accept:image/gif,image/x-xbit,… (CRLF) … HOST:www.guet.edu.cn (CRLF) Content-Length:22 (CRLF) Connection:Keep-Alive (CRLF) Cache-Control:no-cache (CRLF) (CRLF)         //该CRLF表示消息报头已经结束,在此之前为消息报头 user=jeffrey&pwd=1234  //此行以下为提交的数据 HEAD方法与GET方法几乎是一样的,对于HEAD请求的回应部分来说,它的HTTP头部中包含的信息与通过GET请求所得到的信息是相同的。利用这个方法,不必传输整个资源内容,就可以得到Request-URI所标识的资源的信息。该方法常用于测试超链接的有效性,是否可以访问,以及最近是否更新。 2、请求报头后述 3、请求正文(略)    三、HTTP协议详解之响应篇     在接收和解释请求消息后,服务器返回一个HTTP响应消息。 HTTP响应也是由三个部分组成,分别是:状态行、消息报头、响应正文 1、状态行格式如下: HTTP-Version Status-Code Reason-Phrase CRLF 其中,HTTP-Version表示服务器HTTP协议的版本;Status-Code表示服务器发回的响应状态代码;Reason-Phrase表示状态代码的文本描述。 状态代码有三位数字组成,第一个数字定义了响应的类别,且有五种可能取值: 1xx:指示信息–表示请求已接收,继续处理 2xx:成功–表示请求已被成功接收、理解、接受 3xx:重定向–要完成请求必须进行更进一步的操作 4xx:客户端错误–请求有语法错误或请求无法实现 5xx:服务器端错误–服务器未能实现合法的请求 常见状态代码、状态描述、说明: 200 OK      //客户端请求成功 400 Bad Request  //客户端请求有语法错误,不能被服务器所理解 401 Unauthorized //请求未经授权,这个状态代码必须和WWW-Authenticate报头域一起使用 403 Forbidden  //服务器收到请求,但是拒绝提供服务 404 Not Found  //请求资源不存在,eg:输入了错误的URL 500 Internal Server Error //服务器发生不可预期的错误 503 …..

4   基于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生成。后面我们再介绍使用GatCreator生成WebUI自动化用例时应该注意的点。StepMethod代码:使用过GAT的人都知道,我们自己写的代码都是以StepMethod的形式存在的。WebUI 的StepMethod的代码写法与接口的StepMethod的写法一致,概念,使用方式都是一致的。还记得我在前面的文档里写过,如果你会写多接口组合的用例那么你就会写一般的WebUI自动化用例了,说的就是无论概念还是代码的写法都是一致的。StepMethod代码存放在WUATStepGroup工程下。命名规则,什么的请参考接口的要求即可。

目 录 3.2接口用例场景组件 3.3 多接口用例的开发 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中。 l  准备好数据后,就可以运行你的用例,注意如果只是修改了数据不需要重新执行GatCrteator.java生成用例。 3.3 多接口用例的开发 多接口组合的用例是一种更加普遍的试用场景,尤其是移动端的接口测试。因为移动端业务逻辑都在接口服务端实现,因此需要我们试用多个接口组合来完成一个业务逻辑的测试。接下来的我们来看看怎么样开发多接口组合的用例,在此假定你已经能够开发单一接口的用例,对框架的开发架构都已经熟悉。 1)  和单一接口用例的差别 存储形式:单一接口中,数据,用例都是存放在Excel文件中,一行为一个测试用例。多接口组合的用例,用例和数据分别单独存放在不同的xml文件里。 断言方式:单一接口的断言方式分为固定断言方式和自定义断言方式。固定断言方式包括相等断言和包含断言两种。自定义断言方式主要通过自己编写断言代码来完成。对于多接口组合用例来说断言方式都是自定义的,都需要自己开发代码来完成。 用例的组成:单一接口用例因为只有一个接口,因此只用Excel中的一行就能代表一个用例。对于多接口组合的用例来说,每一个用例都是由多个步骤组合而成,也就是说由多个Step方法组合完成。 2)  和单一接口用例的共同点: 用例数据:用例数据都是存放在xml中,而且存放数据的规则,xml格式,xml中标签的含义都是完全一致的。 用例的生成:都已通过执行GatCreator.java来完成。 3)  多接口用例的组成部分 用例描述文件:用例描述文件是一个以TestCase.xml结尾的xml文件,注意一定要以TestCase.xml结尾,这是多接口组合用例的标示,否则在执行GatCreator.java的时候将不能生成用例。下图就是一个示例性的用例描述文件。 一个用例描述文件,也就是一个TestCase.xml文件可以包含很多个测试用例,不再像单一接口用例限定一个excel sheet只能编写一个接口的用例。接下来我们解释一下用例描述文件中的标签。 l   <AllTestCases></AllTestCases>:每一个用例描述文件有且仅有一个这样的标签,用例相关的信息都要放在这个标签内。 l   <StepParametersFilePath></StepParametersFilePath>:上图中第一个红框内的标签,这个标签中的内容:标示的是组成用例的每一个Step方法使用的数据存放在哪个文件中。这个标签是对用例描述文件中Step方法数据存放文件的全局描述。另外这个标签也可以做为TestCase,Step等标签的属性来为单个TestCase或者单个Step定义自己专属的配置。在Step,TestCase都有这个属性的情况下,框架读取配置的优先级是Step的配置优先于TestCase,TestCase优先于全局配置,对于其他全局配置而言,这个优先级同样适用。对于全局配置标签而言,一个文件只能有一个。 l   <StepAssembly></StepAssembly>:上图红框中的第二个标签。这个标签也是一个全局配置标签。表示在这个用例描述文件里,所有用到的Step方法都在这个包里。这个全局配置也可以作为TestCase,Step的属性。注意这个标签的值最后的小点别忘记了。 l   <StepGroup></StepGroup>:上图红框中第三个标签。这个标签同样是一个全局配置标签。虽然叫StepGroup,其实代表的是在这个用例描述文件中,所有用到的Step方法都在这个类中。这个全局配置也可以作为TestCase,Step的属性。 l   <TestCase></TestCase>:上图红框中第四个标签.这个标签代表了一个用例。ID属性是他的唯一标示,因此不能重复,Name属性同样不能重复。它还有Step子标签,我们前面说过了,一个用例是多个Step组成的,因此一个用例可以有多个Step标签。 l   <Step></Step>:这个标签代表了一个用例的一个步骤。StepName:属性是一个StepMethod的名称,StepParameterID是这个StepMethod用到的数据在全局配置中提到的文件中的ID标示。当然如果你自己为Step设置了StepParametersFilePath这个属性,那么这个ID就是你自己设置的这个文件中的ID了。 l   最后总结一下:多接口用例是由多个自定义的方法组成,这个用例由那些方法组成,以及用到了那些数据这些信息最后会存放在一个用例描述文件中。当你编辑完一个用例描述文件后,你就可以使用GatCreator来生成具体的代码了。 数据文件:也就是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 …..

目 录 3.1接口用例开发 3   开始写用例 3.1接口用例开发 1)         准备工作 l  第一步从github(https://github.com/GeneralAutomationTesting/GAT2.0)上下载GAT2.0。 在获取的GAT2.0包里你会看到两个文件夹。如下图所示:   l  第二步从GAT2.0Demo包里找到IATStepGroup 并导入的eclipse.并确保导入后的项目没有引用错误。导入后的目录与【代码结构图】中的结构相似 2)         开始单接口用例开发 单一接口的用例的数据以及用例描述文件是存储在Excel文件中的。下面就详细解释一下Excel中各个字段的含义以及注意事项。   字段名称 字段说明 可选值/实例 ID 唯一即可 DomainName 接口URL的域名 http://api.demo.com Path 域名后参数前的部分 /service/uerlist ParameterName url的参数,列名以$开头 ExpectResult 接口的期望结果 AssertType 断言方式 Equal:和期望结果相等 Contains:包含期望结果 Custom:需要自定义场景组件 AssertMethod 断言方式为自定义情况下需要提供场景组件方法 packagename.classname.methodname:场景组件的参数ID SetupType Custom SetupContext 需要Setup情况下需要提供场景组件方法 packagename.classname.methodname:场景组件的参数ID TearDownType Custom TearDownContext packagename.classname.methodname:场景组件的参数ID 备注:空值必须以:$NULL代替,不能留空   l   第一步:在InterfaceAutomation->DataFiles->Excels目录下创建一个Excel文件。文件名称代表接口所属的模块,请起一个有意义的名字。 l   第二步:打开新创建的Excel文件,并把一个sheet的名字修改为接口的名字,注意一个sheet只能为一个接口写用例。Sheet名字请不要包含特殊字符等。 l   第三步:复制已经存在的excel文件中的各个列名,到新建的sheet中,并开始填写值。   图12 l   请注意一下几点: n   确保ID唯一,DomainName,Path等字段的值都正确。 n   如果接口没有参数请确保没有以$开头的列。 n   如果不想传某个参数,可以把该参数的值置成$EMP. n   Excel中的一行代表一个用例 n   如果需要添加描述性的列,列名请以#开头即可 n   黄色背景字段为默认字段,名称必须保持与图片中的一致。 n   绿色背景字段为接口参数,每增加一个参数在绿色字段增加一列即可。列名称为$+参数名称.如果没有参数请不要保留任何参数字段。 n   图片中可为空字段,在为空是请以$NULL代替 n   如果字段值为数字,请将单元格格式设置为字符串   l  第四步:完成以上步骤后,保存Excel文件。然后右击GatCreator.java运行。在运行之前请确保已经关闭了Excel文件,否则有可能出错。运行完成后就会生成相应的单元测试用例,如果在Eclipse中看不到,请刷新IATStepGroup项目。 3)         运行用例 到这步的时候你已经成功的完成了第一个用例,接下来是运行你的用例。 l   :在package [com.gateside.autotesting.generation.unittest]中找到excel文件名_sheet名称.java文件然后点击右键,run as Testng就可以

目 录 2.3 用例开发架构 2.4 代码结构 对于Web UI自动化和接口自动化来说,图1 中表示的功能可能会有少许差异,下面我将分别做说明。 1)         公共部分 l   单元测试集生成工具:根据用例描述文件来生成Testng 的TestMethod l   公共类库:包含了访问数据库,XML文件等各种公共类 l   单元测试集:由代码生成工具根据用例描述文件自动生成,一个Testmehod为一个用例。 l   核心框架:包含操作用例描述文件,测试数据文件,以及数据构造,接口调用,结果验证等功能 2)    接口测试部分 l   场景组件:场景组件是由用例开发人员开发的具有特定格式的方法,场景组件方法是定义在用户自定义的一个类中。场景组件作为用例的重要组成部分,在用例执行时由核心框架通过反射的方式逐个执行。分为3种。具体形式看下图。 图2 a)    红圈1代表了第一种场景组件,用来做断言的断言类组件 b)    红圈2 代表了第二种场景组件,用来作为用例其中一个步骤的步骤组件 c)    红圈3 代表了在用例执行前需要执行的组件 l   用例数据:对于接口测试来说,用例测试数据由于接口测试用例类型的不同分别存储在Excel文件和xml文件中。形式如下: a)    存储在excel中的数据 图3 b)    存储在xml中的数据 图 4 以上数据无论是存储在什么文件中,都是一个段格式化的数据,分别对应着框架中的一个类。 l   用例描述文件:用来描述用例使用了哪些数据或者由哪些场景组件组成等信息。对于接口测试来说用例描述文件根绝测试用例类型也分为两种。形式如下: a)    存储在excel中(这种形式的用例,用例描述和用例数据是放在一起的具体形式查看数据小结) b)    存储在xml中,这种类型的用例是由多个测试场景组件组成的,xml文件中保存了测试场景组件的必要信息。形式如下: 图6 3)    Web UI部分 l   场景组件:场景组件是由用例开发人员开发的具有特定格式的方法,场景组件方法是定义在用户自定义的一个类中。场景组件作为用例的重要组成部分,在用例执行时由核心框架通过反射的方式逐个执行。分为3种。具体形式看下图。 图7 a)    红圈1代表了第一种场景组件,用来做断言的断言类组件,断言类组件方法有三个参数本组件用到的数据的ID,以及期望结果,实际结果 b)    红圈2 代表了第二种场景组件,用来作为用例其中一个步骤的步骤组件(仅有一个参数) c)    红圈3 代表了在用例执行前需要执行的组件(仅有一个参数) l   用例数据:对于Web UI自动化测试来说测试用例数据全部存储在xml文件中 形式如下: 图8 以上数据和接口用例数据一样,都是一个段格式化的数据,分别对应着框架中的一个类。   l   用例描述文件:用来描述用例使用了哪些数据或者由哪些场景组件组成等信息。对于Web UI自动化来说用例描述文件只有xml一种,这种类型的用例是由多个测试场景组件组成的,xml文件中保存了测试场景组件的必要信息。形式如下: 图-9 2.3 用例开发架构 开发架构从物理角度看如下图:稍后就图10中的目录用途做详细说明 图10 1)         公共目录 l  Libs:对于接口自动化以及WebUI自动化所使用的所有第三方类库都放在此目录里。 2)         接口相关目录 l  InterfaceAutomation:接口自动化用例,场景组件,测试数据,用例描述文件等均放置在此目录中。总之就是接口自动化相关的文件都在此目录中。 l  DataFiles\Excels: 用于存放单描述接口用例的Excel文件,以及其他参数文件 l  DataFiles\Xmls:用于存放描述多接口用例的Xml文件,一起其他参数文件 l  IATStepGroup:所有测试用例中使用到的场景组件,以及测试用例方法 3)         WebUI相关目录 l   UIAutomation: WebUI自动化用例,场景组件,测试数据,用例描述文件等均放置在此目录中。WebUI自动化相关的文件都在此目录中。 l   DataFiles\Xmls:用于存放描述用例的Xml文件,参数数据文件,页面元素信息文件等。 l   WUATStepGroup:所有测试用例中使用到的场景组件,以及测试用例方法 2.4 代码结构 将IATStepGroup项目导入到,exclipse 后 ,开发架构在Eclipse中的结构如下图,稍后会就下图做相应解释 代码结构图 1)          单元测试用例的生成(GatCreator.java): 看过前面文章的人,可能会问我们把数据写到Excel或者Xml中,用例是怎么开始执行的,其实任何一个程序都会有一个执行入口。在GAT中,用例的执行入口是由Testng的单元测试方法来承担的,GatCreator.java会根据我们之前填写的Excel或者xml文件来生成相应的单元测试方法。 2)          单元测试用例 根据Excel或者xml生成的所有单元测试方法都存放在package [com.gateside.autotesting.generation.unittest]中,这个package下的所有文件包括package本身都是自动生成的。当你想要执行某个用例时到这个package下找到相应的单元测试方法运行即可。   3)         Stepmethod或者叫场景组件方法。 这类方法是由我们自己开发的代码,决定了具体的测试场景以及业务。后面的文章里也会提到。如上图中的package …..

并行(多线程)技术在软件术语里被定义为软件、操作系统或者程序可以并行地执行另外一段程序中多个部分或者子组件的能力。TestNG允许我们以并行(多线程)的方式来执行测试。这就意味着基于TestNG测试组件的配置,多个线程可以被同时启动然后分别执行各自的测试方法。相对于传统的单线程执行测试的方式,这种多线程方式拥有很大的优势,主要是它可以减少测试运行时间,并且可以验证某段代码在多线程环境中运行的正确性。 目录 并行执行测试的优势 如何并行地执行测试方法 如何并行地执行测试类 如何并行地执行同一测试套件内的各个测试组件 如何配置需要在多线程环境中执行的测试方法 并行执行测试的优势 并行(多线程)执行测试可以给用户带来很多好处,主要包括以下两点: 1)减少了执行时间:并行测试也就意味着多个测试可以在同一时间被同时执行,从而减少了整体测试所花费的时间。 2)允许多个线程并行地测试同一个测试组件:有了这个特性,我们就能够写出相应的测试用例来验证应用程序中包含多线程部分的代码的正确性。 以上特性被广泛地应用在QA领域的自动化功能测试方面。通过简单的配置,QA人员就可以很轻松地使得他们的测试用例在多个浏览器或者操作系统中并行地执行。 TestNG提供了三种不同类型的配置方案来实现并行测试。 如何并行地执行测试方法 TestNG为我们提供了多种方式来实现并行测试,其中一种就是每一个独立的线程分别执行各自的测试方法。这种方式能够显著地减少测试执行时间,这是因为当有越多的测试方法被并行执行时,总体测试消耗时间将会越少。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 package com.howtodoinjava.parallelism; import org.testng.annotations.AfterMethod; import org.testng.annotations.BeforeMethod; import org.testng.annotations.Test; public class ParallelMethodTest {     @BeforeMethod     public void beforeMethod() {         long id = Thread.currentThread().getId();         System.out.println(“Before test-method. Thread id is: ” + id);     }     @Test     public void testMethodsOne() {         long id = Thread.currentThread().getId();         System.out.println(“Simple test-method One. Thread id is: ” + id);     }     @Test     public void testMethodsTwo() {         long id = Thread.currentThread().getId();         System.out.println(“Simple test-method Two. Thread id is: ” + id);     }     @AfterMethod     public void afterMethod() { …..

目 录 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