第一章 接口测试初识
1. 接口测试理论基础
“接口测试”一个让人觉得非常高大上的名词,特别是对于刚入门的测试同学而言。随着测试技术不断的深化,“接口测试”出现在我们视野中的频次越来越高。那么接口测试到底是如何做的?接口测试的优势又体现在哪些方面?
1.1 什么是接口?
接口主要用于外部系统与系统之间以及内部各个子系统之间的交互点,定义特定的交互点,然后通过这些交互点来,通过一些特殊的规则也就是协议,来进行数据之间的交互。
1.2 接口种类
接口一般分为两种:程序内部接口、系统对外接口。
- 系统对外接口:例如最常见的系统对外接口—支付宝支付接口,很多app的支付功能都是调用支付宝的支付接口来进行支付,而该接口是支付宝系统提供给外部系统进行调用的
- 程序内部接口:模块与模块之间的交互,比如淘宝商城要购买商品,下订单前必须要先登录,那么下订单与登录之间就是一个交互,这个交互就是一个接口,让程序内部的其他模块进行调用的
1.3 常用接口分类
- HTTP 接口:通过HTTP协议来进行数据传输的接口
- WebService 接口:通过soap协议进行数据传输的接口
-
webService接口是走soap协议通过http传输,请求报文和返回报文都是xml格式的,我们在测试的时候都用通过工具才能进行调用,测试。
SOAP代表简单对象访问协议(Simple Object Access Protocol)。它是一种基于XML的消息传递协议。虽说名字带了简单,但是协议比较罗嗦,已经远没有后来居上的JSON使用广泛。
-
http api接口是走http协议,通过路径来区分调用的方法,请求报文都是key-value形式的,返回报文一般都是json串,有get和post等方法,这也是最常用的两种请求方式。
json是一种通用的数据类型,所有的语言都认识它。(json的本质是字符串,他与其他语言无关,只是可以经过稍稍加工可以转换成其他语言的数据类型,比如可以转换成Python中的字典,key-value的形式,可以转换成JavaScript中的原生对象,可以转换成java中的类对象等。)
1.4 为什么要做接口测试
-
提高测试效率:可通过自动化手段实现重复验证,也可以在依赖服务没有开发完成时优先测试部分服务
-
接口测试相对容易实现自动化持续集成,且相对UI自动化也比较稳定,可以减少人工回归测试人力成本与时间,缩短测试周期,支持后端快速发版需求。接口持续集成是为什么能低成本高收益的根源。 接口测试作为质量管理的一部分保证系统正确稳定,一个系统服务越接近底层,对系统的影响也就越大,服务端的一个缺陷可能会引起整个客户端的崩溃,损失是不可估量的.
-
方便定位Bug:通过接口的抓包和分析,可以清楚的知道问题是来源于前端还是后台服务
-
提高服务端健壮性:通过接口测试可以测出来开发是否在后端做了校验,帮助提高服务的健壮性
前端随便变,接口测好了,后端不用变,前后端是两拨人开发的。 检查系统的安全性、稳定性,前端传参不可信,比如京东购物,前端价格不可能传入-1元,但是通过接口可以传入-1元。 现在很多系统前后端架构是分离的,从安全层面来说: - 只依赖前端进行限制已经完全不能满足系统的安全要求(绕过前面实在太容易), 需要后端同样进行控制,在这种情况下就需要从接口层面进行验证。 - 前后端传输、日志打印等信息是否加密传输也是需要验证的,特别是涉及到用户的隐私信息,如身份证,银行卡等
1.5 什么是接口测试
系统组件间接口测试。主要是检测外部系统与系统之间,以及内部各个子系统之间的交互点,检查数据的交换,传递,和控制管理过程,以及系统间的相互逻辑依赖关系,适用于为其他系统提供服务的底层框架系统和中心服务系统,主要测试这些系统对外部系统提供的接口,验证其正确性与稳定性 —百度百科
简答的说就是通过URL向服务器或者其他模块等,传输我们想传输的数据,然后看看他们返回的是不是我们预期想要的。
接口测试就是通过测试不同输入条件下,接口返回的结果是否与预期结果一致。
接口测试其实是一个非常简单的过程,将接口的业务逻辑处理看成黑盒测试中的黑盒子,我们只需要考虑各种输入条件下,会产生相应的什么结果。
而我们知道黑盒测试又称功能测试,那么接口测试与功能测试是不是一回事呢?答案是否定的,为什么呢?功能测试还包含了程序的UI层,包含了按钮,UI交互等功能,而接口测试是没有页面操作的,只能通过调用接口来进行测试,只需要给接口传递相应的输入条件,再检查接口输出的结果是否符合预期即可。某种程度讲,接口测试比功能测试还要更简单一些。
那么问题来了,如何调用接口来进行接口测试呢?
1.6 怎样做接口测试?
由于我们项目前后端调用主要是基于http协议的接口,所以测试接口时主要是通过工具或代码模拟http请求的发送与接收。工具有很多如:postman、jmeter、soupUI、java+httpclient、robotframework+httplibrary等。
–也可以用 接口自动化来实现,就是用代码实现,框架和UI自动化差不多,发送请求用断言来判断。
重点还是在于测试用例的设计
1.7 接口测试使用范围
接口测试一般会用于多系统间交互开发,或者拥有多个子系统的应用系统开发的测试。接口测试适用于为其他系统提供服务的底层框架系统和中心服务系统,主要测试这些系统对外部提供的接口,验证其正确性和稳定性。接口测试同样适用于一个上层系统中的服务层接口,越往上层,其测试的难度越大。接口测试在淘宝的应用是一个自下而上的发展过程。
接口测试实施在多系统多平台的构架下,有着极为高效的成本收益比,接口测试天生为高复杂性的平台带来高效的缺陷监测和质量监督能力。平台越复杂,系统越庞大,接口测试的效果越明显。
接口测试的目的是测试接口,尤其是那些与系统相关联的外部接口,测试的重点是要检查数据的交换,传递和控制管理过程,还包括处理的次数。外部接口测试一般是作为系统测试来看待的。
不是所有的团队都可以在一个隔离的测试环境中进行测试工作的,因此使得对外部接口的测试显得困难。我们应该确保较早地与相关的组织协调好并确定进行外部接口测试的方案。有时候相关的组织只是人工的静态的审阅一次数据而并不真正的用这些数据来测试。等等这些都增加了实际测试执行中遇到的风险,但有些时候是可以避免的。
前后端
做接口测试前,需要对两个概念有所了解,前端和后端
\1. 前端:通常为Web前端和app前端,前端的作用是为了展示数据内容,做简单的数据校验,比如我们看到的淘宝商城,那些商品信息,图片展示等等
\2. 后端:进行复杂计算的业务逻辑,功能实现,例如我们购买商品后的价格计算,优惠活动的使用,最终的支付,都是通过后端实现的
而前后端就是通过接口来进行交互的。
接口调用示意图
开始讲解接口测试之前,先看看当你在浏览器中输入地址,并看到Web页面的时候底层发生了什么:
- 浏览器根据输入把请求发送到服务器
- 服务器获取到请求以后生成响应文件,把响应文件发送给浏览器
- 浏览器解析响应,渲染数据生成Web页面的展示效果
接口测试与UI层功能测试优劣势对比
- 接口测试的介入时间更早,越早介入价值越高 (具体原因可以参考我另外一篇文章:[软件测试流程-全程软件测试])
- 接口测试的稳定性更高,变动少。接口测试通过,前端即时出现问题,解决起来也会非常快
- 接口测试发现缺陷后,解决的成本更低。越底层的缺陷,影响的面就越广,一个底层缺陷可能引起N个表面的缺陷,那时候解决起来就会非常麻烦,而且还不一定能找到源头缺陷
- 定位问题更加准确和快速。当我们接口测试通过后,在功能测试中出现问题,我们就可以更快速和准确的定位问题,因为已经排除掉接口层的干扰了。
2. 接口测试流程
接口测试的原理跟功能测试是一样的,那么它的流程跟功能测试流程其实也是基本一致的。
接口测试 不等于 接口测试工具使用
很多人认为会使用接口测试工具就是会接口测试。其实接口测试远远不止是工具的使用,SoapUI也好,Jmeter也好,这些工具都是我们在进行接口测试过程中能够更方便的进行测试,而工具仅仅是工具,真正核心部分还是接口测试用例设计以及测试思维。那么当我们做接口测试时,到底需要做哪些方面的工作呢?
接口测试流程:
- 获取需求文档和接口文档
- 通过对需求文档分析出接口的业务逻辑要求以及业务边界
- 通过对接口文档分析出接口的技术指标(接口地址、请求方式、入参、出参)
- 接口测试用例设计(着重于接口测试数据准备)
- 使用接口测试工具进行接口测试
- 接口缺陷管理与跟踪
- 接口自动化持续集成
2.1 接口测试测试点
目的:测试接口的正确性和稳定性;
原理:模拟客户端向服务器发送请求报文,服务器接收请求报文后对相应的报文做处理并向客户端返回应答,客户端接收应答的过程;
重点:检查数据的交换,传递和控制管理过程,还包括处理的次数;
核心:持续集成是接口测试的核心;
优点:为高复杂性的平台带来高效的缺陷监测和质量监督能力,平台越复杂,系统越庞大,接口测试的效果越明显(提高测试效率,提升用户体验,降低研发成本);
用例设计重点:通常情况下主要测试最外层的两类接口:数据进入系统接口(调用外部系统的参数为本系统使用)和数据流出系统接口(验证系统处理后的数据是否正常)
2.2 接口测试都要掌握哪些知识?
- http协议
- 抓包工具
3. HTTP
3.1 HTTP 简介
https://www.w3school.com.cn/tags/html_ref_httpmethods.asp
HTTP协议是Hyper Text Transfer Protocol(超文本传输协议)的缩写,是用于从万维网(WWW:World Wide Web )服务器传输超文本到本地浏览器的传送协议。。
HTTP是一个基于TCP/IP通信协议来传递数据(HTML 文件, 图片文件, 查询结果等)。
3.2 HTTP 工作原理
HTTP协议工作于客户端-服务端架构上。浏览器作为HTTP客户端通过URL向HTTP服务端即WEB服务器发送所有请求。
Web服务器有:Apache服务器,IIS服务器(Internet Information Services)等。
Web服务器根据接收到的请求后,向客户端发送响应信息。
HTTP默认端口号为80,但是你也可以改为8080或者其他端口。
CGI是common gateway interface的缩写,大家都译作通用网关接口,但很不幸,我们无法见名知意。
我们知道,web服务器所处理的内容都是静态的,要想处理动态内容,需要依赖于web应用程序,如php、jsp、python、perl等。但是web server如何将动态的请求传递给这些应用程序?它所依赖的就是cgi协议。没错,是协议,也就是web server和web应用程序交流时的规范。换句话说,通过cgi协议,再结合已搭建好的web应用程序,就可以让web server也能"处理"动态请求(或者说,当用户访问某个特定资源时,可以触发执行某个web应用程序来实现特定功能),你肯定知道处理两字为什么要加上双引号。
HTTP三点注意事项:
-
HTTP是无连接:无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求,并收到客户的应答后,即断开连接。采用这种方式可以节省传输时间。
-
HTTP是一种无状态的协议,无状态是指Web浏览器与Web服务器之间不需要建立持久的连接,这意味着当一个客户端向服务器端发出请求,然后Web服务器返回响应(Response),连接就被关闭了,在服务器端不保留连接的有关信息。也就是说,HTTP请求只能由客户端发起,而服务器不能主动向客户端发送数据。
-
HTTP是媒体独立的:这意味着,只要客户端和服务器知道如何处理的数据内容,任何类型的数据都可以通过HTTP发送。客户端以及服务器指定使用适合的MIME-type内容类型。
-
HTTP是无状态:HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息,则它必须重传,这样可能导致每次连接传送的数据量增大。另一方面,在服务器不需要先前信息时它的应答就较快。
以下图表展示了HTTP协议通信流程:https://www.runoob.com/http/http-intro.html
CGI(Common Gateway Interface) 是 HTTP 服务器与你的或其它机器上的程序进行“交谈”的一种工具,其程序须运行在网络服务器上。
绝大多数的 CGI 程序被用来解释处理来自表单的输入信息,并在服务器产生相应的处理,或将相应的信息反馈给浏览器。CGI 程序使网页具有交互功能。
浏览器显示的内容都有 HTML、XML、GIF、Flash 等,浏览器是通过 MIME Type 区分它们,决定用什么内容什么形式来显示。
**注释:**MIME Type 是该资源的媒体类型,MIME Type 不是个人指定的,是经过互联网(IETF)组织协商,以 RFC(是一系列以编号排定的文件,几乎所有的互联网标准都有收录在其中) 的形式作为建议的标准发布在网上的,大多数的 Web 服务器和用户代理都会支持这个规范 (顺便说一句,Email 附件的类型也是通过 MIME Type 指定的)。
媒体类型通常通过 HTTP 协议,由 Web 服务器告知浏览器的,更准确地说,是通过 Content-Type 来表示的。例如:Content-Type:text/HTML。
通常只有一些卓哉互联网上获得广泛应用的格式才会获得一个 MIME Type,如果是某个客户端自己定义的格式,一般只能以 application/x- 开头。
3.3 HTTP 请求方法
根据 HTTP 标准,HTTP 请求可以使用多种请求方法。
HTTP1.0 定义了三种请求方法: GET, POST 和 HEAD方法。
HTTP1.1 新增了六种请求方法:OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。
https://www.w3school.com.cn/tags/html_ref_httpmethods.asp
序号 | 方法 | 描述 |
---|---|---|
1 | GET | 请求指定的页面信息,并返回实体主体。 |
2 | HEAD | 类似于 GET 请求,只不过返回的响应中没有具体的内容,用于获取报头 |
3 | POST | 向指定资源提交数据进行处理请求(例如提交表单或者上传文件)。数据被包含在请求体中。POST 请求可能会导致新的资源的建立和/或已有资源的修改。 |
4 | PUT |