第1章
测试那点事
单元测试》接口测试》界面测试
接口就是包含特定输入和特定输出的一套逻辑处理单元,用户无须知晓接口的内部实现逻辑,这也可以称为接口的黑河处理逻辑。因为服务对象不同,接口又可分为两种:一种是系统或服务的内部接口,另一种是外部接口。
简单来说,内部接口就是系统内部调用的接口。
第2章
为接口测试储备技术
2.1接口测试都是以网路协议为基础的
接口测试都是在某种网络传输协议之上完成的。
2.1.1 OSI七层模型
OSI(开放式系统互连)七层模型又称OSI七层参考模型,它是ISO(国际标准化组织)在1985年研究制定的网络互联规范。ISO推荐所有公司都使用这一规范来控制网络,这样所有公司就能互连了。顾名思义,OSI七层模型将网络通信从上到下分为7层——应用层、表示层、会话层、传输层、网络层、数据链路层和物理层。其中,应用层、表示层、会话层、传输层是高层,它们定义了程序的功能;而网络层、数据链路层和物理层是低层,它们主要处理网络的端到端数据流。
2.1.2 TCP/IP四层模型
又称为因特网分层模型、因特网参考模型等。
TCP/IP四层模型将网络通信从上到下分为4层,分别是应用层、传输层、网络层、数据链路层。
应用层负责支持用户提供应用服务的通信活动,应用层直接作用于操作系统,负责用户会话管理、数据加密/解密、为应用程序提供数据等。
HTTP是一种无状态、无连接的协议
无状态是指对于事务处理没有记忆能力。
无连接是指在客户端和服务器交互的过程中,一次交互只能处理一个请求。
请求中的消息格式:
HTTP请求由首行、HTTP头(header)和正文(body)3部分组成。
首行指明了HTTP的请求方法,可以是GET、POST、PUT、DELETE、OPTIONS、HEADER等方法。在日常工作中最常用到的是GET和POST方法。
GET方法用于从服务器获取资源,其参数是在URL中发送出去的。测试工程师需要了解GET请求的如下特点。
GET请求可被缓存。
GET请求保留在浏览器的历史记录中。
GET请求可被收藏为书签。
GET请求不应在处理敏感数据时使用。
GET请求有长度限制(现实情况是对URL长度而非参数长度有约束)。
GET请求只应当用于取回数据。
POST方法用于向指定的资源提交数据并请求处理。测试工程师需要了解POST请求的如下特点。
POST请求不会被缓存。
POST请求不会保留在浏览器的历史记录中。
POST请求不能被收藏为书签。
POST请求对数据长度没有要求。
2.2.1 HTTP状态码
在基于HTTP的交互过程中,客户端会发送一个请求到服务器端,服务器端在正确处理完这个请求后,就会返回一个响应。这个响应除包含HTTP的头信息和正文信息之外,还包含一个状态码。这个状态码由3位数字代码组成,用来表示服务器端的响应状态。
1. 20X状态码
在HTTP中,20X状态码表示请求成功。
200状态码最常见,表示服务器端不但正确处理了客户端发来的请求,而且返回了对应的业务逻辑的处理结果。200状态码会随响应头一起返回。
201状态码:表示请求已经实现。
202状态码:表示请求虽然已被接收但尚未处理。
204状态码:表示虽然服务器成功处理了请求,但未返回任何内容。
2. 30X 状态码
在HTTP中,30X状态码表示重定向。如果我们以未登录状态访问异步社区的历史订单功能,那么网站就会将请求重定向到登录页面,并返回302状态码来表示临时移动。
301状态码:表示永久移动,此时用户访问的资源已被永久移动到新的URI(统一资源标识符)。URI是一个字符串,用于标识某互联网资源的名称。
304状态码:表示请求的资源未发生修改。
3. 40X 状态码
在HTTP中,40X状态码表示请求错误,其中的X表示具体的错误类型。
400:一种十分常见的语义错误,400状态码表示当前请求无法被服务器理解,这通常是客户端请求中存在语法错误引起的,并且绝大部分是请求参数有问题导致的。
401:表示此次请求需要登录信息,这也是服务器针对客户端访问权限的常见的鉴定方式和友好的处理方法。
403:表示服务器虽然理解客户端请求但拒绝执行,客户端请求被服务器拒绝的很多情况是客户端没有访问权限导致的。
y404:表示测试服务器无法根据客户端请求找到对应的URI,网站的设计人员通常可以设置自己的404页面,从而向用户呈现更加有好的交互体验。
4. 50X 状态码
在HTTP中,50X状态码表示服务器错误。
500:表示服务器遇到一个不知道该如何解决的问题,导致没有办法处理对应的客户端请求。这种情况通常是服务器内部存在逻辑问题导致的。
503:表示服务器暂时无法对外提供服务,这种情况很多时候是系统维护或服务器负载太高,进而无法处理客户端请求导致的。
2.2.2 HTTP头
1.请求的头信息
Connection:表示是否需要持久连接(HTTP1.1默认会进行持久连接)。keep-alive表示使客户端到服务器的连接持续有效,这样当出现对服务器的后继请求时,便可以避免建立或重新建立连接。
Accept:指定客户端能够接收的内容的类型。
X-Requested-With:指定请求是Ajax请求还是普通请求。
User-Agent:发出请求的用户信息。
Referer:所要访问的网址。
Accept-Encoding:指定浏览器可以支持的Web服务器所返回的内容的压缩编码类型。
Cookie:当发送请求时,客户端会把保存在请求域名下的所欲Cookie一起发送给Web服务器。
2.响应的头信息
Server:Web服务器软件的名称。
Date:原始服务器消息发出的时间。
Content-Type:所返回内容的MIME类型,用于告诉浏览器以什么形式、什么编码读取这个文件。
Content-Length:所返回内容的长度。在一次传输中,Content-Length如果存在有效的话,则必须与消息内容的传输长度完全一致。
Age:从原始服务器到代理缓存形成的估算时间(以秒计,为非负值)。
Via:用于告诉代理客户端响应是从哪里发送的。
Accept-Ranges:用于指明服务器是否支持指定范围内的请求以及支持哪种类型的分段请求。
2.3 Web服务器Tomcat
对于测试工程师而言,既不需要掌握Tomcat的运行原理,也不需要弄清楚Servlet在Tomcat中是如何运行的,他们只需要能够部署和配置Tomcat就可以了。
JAVA_OPTS配置中的参数
参数类型 | 参数 | 说明 |
-(表示标准参数) | -server | JVM(Java虚拟机)以服务器模式启动,这种方式启动慢,但是运行起来效率很高 |
-client | JVM以客户端模式启动,这种模式虽然启动速度快,但是运行起来效率不高,在进行本地调试时适合使用这种模式。 | |
-X(表示非标准参数) | -Xms | 用来设置Java堆的初始值(使用中的最小内存),Java堆是由全部线程共享的一块内存区域,几乎全部对象或实例都会从Java堆中分配内存。 |
-Xmx | 用来设置Java堆的最大值(使用中的最大内存) | |
-XX(表示非平稳参数) | -XX:NewSize | 用来设置内存的新生区域(用于存放新生对象)的大小 |
-XX:MaxNewSize | 用来设置内存的新生区域大小的上限 | |
-XX:PermSize | 用来设置非堆内存的初始大小(堆内存是Java代码可以使用的内存,非堆内存则是JVM留给自己使用的内存) | |
-XX:MaxPermSize | 用来设置非堆内存大小的上限 |
对于标准参数,JVM都支持,并且这些参数都向后兼容;对于非标准参数,JVM默认有可能(但并不保证)实现它们的功能,而且这些参数也不一定向后兼容;对于非平稳参数,不同的JVM处理方式也不一样,使用时必须谨慎,一定要留意开发环境、测试环境、生产环境的Java版本。
第3章
着手准备接口测试
在功能测试过程中,很多时候,我们需要查看客户端和服务器的交互情况,这离不开抓包工具。
3.3接口测试的标准输入
测试工程师,尤其是做了多年业务测试的测试工程师,在开始接触接口测试时,无论研发工程师是否提供了接口文档,下面3种情形在日常工作中都是很常见的。
研发工程师提交测试的项目附带了一个几十页的Word文档,里面是一行行的访问地址和路由,面对这样的Word文档,测试工程师不知道如何开始验证。
研发工程师使用即时通信工具发送了一条长达几页的消息,里面包含各种嵌套的参数,测试工程师不知道这些参数都似乎干什么用的。
研发工程师口头指出需要测试的接口地址,之后什么都没有再多说,面对又长又复杂的接口地址,测试工程师束手无策。
研发工程师在设计和开发接口的过程中,需要不断维护和更新接口文档,接口文档中包含每一个接口的访问方式、访问路由、输入参数及返回参数的含义,此外还包含一个完整的例子。
接口文档既可能以Word文档形式存在,也可能以类似Swagger的工具形式存在。使用Swagger可以从代码中生成以Web服务形式存在的接口文档,这种接口文档能够随着代码的变化而同步进行变化,从而极大降低了研发工程师和测试工程师的沟通成本。
对于每一个参数了解一下3点内容:
参数的含义及来源。我们要搞清楚每一个参数的含义,也就是这个参数对应的实际自然语言的名称。
参数的作用域。参数的作用域涉及的问题包括参数在接口中是用来干什么的,参数在哪一个访问周期中一直存在,参数是否导致业务逻辑分支等。
返回值的含义。对于接口的返回值,我们要理解JSON中每一个键对应的含义,这样当需要与接口产生交互时,就可以快速搞清楚对应参数的含义,从而完成业务逻辑上下文的串联。
总的来说,请求和响应的全部参数对于接口测试而言都是必要的输入项,因此我们有必要花费精力完善并留存它们。
测试的业务逻辑是通过串联多个接口完成的,而多个接口的串联逻辑是由业务逻辑规定的。因此,多个接口之间并非随意组合,而是需要按照业务逻辑并通过数据传递来完成多个接口的串联。
为了使用接口测试完成业务逻辑,我们不仅需要制作整个流程中所有接口的接口信息表,还要弄清楚每一个数据流程,数据流程负责驱动业务流的处理,如此才能开始业务逻辑接口的测试。
3.4接口测试工具 Postman
启动Postman软件,输入被测接口的URL,单击Params按钮,设置请求参数,然后选择请求方法(如GET或POST),最后单击Send按钮,一个简单的请求过程就完成了。发送完请求后,查看接口返回的JSON信息。
3.4.1 使用测试用例集管理被测接口
Postman提供的Collections功能可以理解为测试用例集。
3.4.3 使用全局变量解决上下文依赖问题
第5章
接口测试框架进阶
5.1支持RESTful风格的接口
5.1.1 RESTful是什么
在符合架构原理的前提下,通过理解和评估以网络为基础的应用软件的架构设计,得到一种功能强、性能好且适用于通信的架构。REST指的是一组架构约束条件和设计原则。
我们将符合REST(表述性状态转移)约束的架构称为RESTful架构。RESTful由于是面向资源接口设计的并且操作抽象,因此能简化开发人员的不良设计,同时最大限度地利用HTTP最初的应用协议设计理念。要想理解RESTful,我们就必须掌握资源、表现层和状态转移这3个概念。
1.资源
这里的资源是指网络上的实体或具体信息,如一段文本、一幅图片、一个多媒体或一种可以提供的服务。资源是通过URI进行标识的,要想和资源进行交互,只需要访问对应的URI就可以了。
2.表现层
资源有多种表现形式,具体如何展现是由表现层控制的。例如,数据既可以使用JSON来描述,也可以使用XML来描述。在RESTful服务中,表现层控制者服务器和客户端之间资源的传递形式,比如使用JSON和XML传输文本,而使用JPG、WebP格式传输图片等。当然,通过HTTP传输的数据也可以压缩。
3. 状态转移
当我们通过网络和网页发生交互时,就会产生交互式且流程化的信息传递,而在信息传递过程中,必然会有数据和状态的变化,这就是状态转移。状态转移是在表现层之上完成的。在状态转移过程中,我们会用到HTTP的以下4种基本操作。
GET操作:用来获取资源。
POST操作:用来新建或更新资源。
PUT操作:用来更新资源。
DELETE操作:用来删除资源。
另外,RESTful要求HTTP状态码必须能够传递出服务器的状态信息。例如,常用的HTTP状态码200,表示成功,500表示服务器内部错误。
REST指的是一组架构约束条件和设计原则,其本质是为了让访问者依据URI就可以找到资源,然后通过简单的输入和输出完成与服务的交互。
RESTful风格的接口主要以JSON格式进行数据交换。
5.2.4 WebSocket 一点通
WebSocket是HTML5提供的一种能在单个TCP连接上进行全双工通信的协议。HTTP是一种无状态、无连接、单向的应用协议。HTTP采用了请求/响应模型:通信请求只能由客户端发起,服务器负责对请求做出应答处理。但这会出现一个很严重的问题——HTTP永远无法从服务器发起会话。在这种单向的通信模式下,对于在服务器有状态变化后想要通知客户端的情况,很多Web应用通过大量且频繁地AJAX(异步 JS和XML)请求实现了长轮询,但这种机制效率低下、资源耗费大。
WebSocket就是为了解决这种问题而出现的。WebSocket连接允许在客户端和服务器之间进行全双工通信,以便任何一方都可以通过建立的连接将数据推送到另一端。WebSocket只需要建立一次连接,就可以一直保持连接状态,相对于在轮询方式下不停地建立连接,效率显然得到了极大提高。
WebSocket的优点如下。
建立在TCP之上,服务器端的实现相对比较容易。
与HTTP有着良好的兼容性。默认的端口号也是80 和 443,并且握手阶段采用HTTP,因此握手时不容易屏蔽。
数据格式比较轻量,性能开销小,通信高效。
既可以发送文本,也可以发送二进制数据。
没有同源限制,客户端可以与任意服务器通信。
协议标识符师ws(如果加密,则为wss),服务器网址是URL。
5.2.5 WebSocket数据帧的格式
客户端与服务器端数据的交换离不开数据帧格式的定义。WebSocket客户端与服务器端通信的最小单位是帧,一个或多个帧可以组成一条完整的消息。
发送端:将消息分成多个帧并发送到服务器端。
接收端:接收消息帧并将关联的帧重新组装成完整的消息。
5.3使框架拥有RPC接口测试能力
5.3.1RPC和gRPC
RPC(远程过程调用)实际上提供了可以使应用程序相互通信的一套机制,它是一种通过网络从远程计算机程序请求服务,而不需要我们了解底层网络技术的通信方式,可简单地理解为一个节点请求另一个节点提供的服务。在客户-服务器模式下,客户端调用服务器端的接口就像调用本地函数一样。RPC和HTTP目前是微服务常用的通信方式,但是RPC和HTTP多少还有一些区别,因为它们确实不是同一层次的概念。
RPC的调用协议通常包含序列化方式和传输协议。序列化方式可以是XML、JSON、Protobuf、Hessian等,其中XML、JSON是纯文本方式,Protobuf、Hessian是二进制编码方式。网络底层的传输协议有TCP、HTTP等。
HTTP不仅可以是RPC传输方式的一种,而且可以为微服务提供技术方案,但HTTP并不依托RPC来支持微服务框架。HTTP既可以和RPC一样作为服务间通信的解决方案,也可以作为RPC通信层的传输协议。
目前流行的开源RPC框架比较多,比如阿里巴巴的Dubbo、Google的gRPC、Meta(原Facebook)的Thrift和Twitter的Finagle等。Google发布的开源RPC框架gRPC是基于HTTP2.0的,并且支持众多常见的编程语言。gRPC提供了强大的流式调用功能,目前已成为主流的RPC框架之一。RESTful也是一套通信机制,那么gRPC和RESTful API有何区别呢?gRPC和RESTful API分别提供了一套通信机制用于客户-服务器通信模型,并且它们都使用HTTP作为底层的传输协议。不过,gRPC还是有自身明显特征的,例如gRPC可以通过Protobuf来定义接口,因而拥有更加严格的接口约束条件。通过Protobuf,我们可以将数据序列化为二进制编码,这能大幅度减少需要传输的数据量,从而极大地提高了性能。
第6章
性能测试
6.1.1 性能测试的常用指标
在GB/T 25000.10 的八大质量特性中,性能效率这个独立的质量特性包含了时间特性、资源利用性、容量、性能效率的依从性等质量子特性。
并发用户数:是针对服务器而言的,指的是在同一时刻与服务器进行交互的在线用户数量。在压力测试期间,并发用户数是指同时执行一个或一系列操作的用户数量,或指同时执行某个脚本的用户数量。不同场景下的并发情况是不一样的,在实际的测试工作中,需要根据具体的需求设置并发用户数。
最大并发用户数:用来描述信息系统所能提供提供的最大服务能力。
吞吐量:单位时间内系统所能处理的请求数量。对于交互式系统,单位通常是字节数/秒、页面数/秒或请求数/秒;对于非交互系统,单位通常是笔(交易)/秒。
响应时间:分为用户响应时间和系统响应时间两种。用户响应时间是指用户所能感受到的系统对其操作的响应时间。人的眼睛由于视觉暂停现象只能察觉0.1s以上的视觉变化,用户响应时间只要不超过0.1s就可以了。系统响应时间是指计算机对用户的输入或请求做出应答的时间。压力测试一般站在用户的角度考虑问题,因而衡量的是用户响应时间。
资源利用率:描述信息系统性能状态的一系列数据指标,包括被测服务器的CPU利用率、内存利用率、磁盘I/O速率、网络吞吐量等。
等待时间:信息系统用户在进行业务操作时发出的两个连续请求之间的时间间隔。
6.1.2 性能测试的分类
性能测试用来评估系统的服务能力。
1.负载压力测试:通过不断为系统增加负载,观察系统的性能变化并确定系统在满足一系列性能指标(包含响应时间、CPU利用率、内存使用率、网络吞吐量、磁盘I/O速率等,其中关键性指标是响应时间、CPU利用率和内存使用率)要求的前提下所能承受的最大负载。
2.失效恢复测试:针对提供了系统冗余备份或负载均衡机制的系统,模拟系统局部发生故障后,在系统仍有大量用户持续访问的情况下,对系统服务能力的回复进行测试,主要用来评估系统的健壮性和可恢复性。
3.疲劳测试:在保证总业务量的情况下长时间运行系统的测试,主要用来评估系统长时间无故障稳定运行的能力(测试周期通常是7*24小时、3*24小时或1*24小时)。