最近几年接口测试被炒得火热了,越来越多的测试同行意识到了接口测试的重要性。主要是平常的功能点点点,大家水平都一样,然而要拿到更高的薪资,对事业更有成就感。更深入的思考页面上看不到的功能,也就是接口测试了。
接口测试主要用于外部系统与系统之间以及内部各个子系统之间的交互点,定义特定的交互点,然后通过这些交互点来,通过一些特殊的规则也就是协议,来进行数据之间的交互。
接口一般分为两种:1.程序内部的接口 2.系统对外的接口
说起接口测试,网上有很多例子,但是当初做为新手的我来说,看了不不知道他们说的什么,觉得接口测试,好高大上。认为学会了接口测试就能屌丝逆袭,走上人生巅峰,迎娶白富美。因此学了点开发知识后,发现接口测试其实都是人们玩的名词罢了。接口测试,真心很简单。它只不过是数据传递是一种表现而已。
哔哩哔哩,免费学习好去处。正好我前几天剪了一个关于接口自动化测试技术的合集。
如果对你有帮助,别忘了回来点个赞同。
什么是接口?
业内常说的接口一般指两种:
1.API:应用程序编程接口,程序间的接口
2.GUI:图形用户界面,人与程序的接口
软件接口测试中的接口特指API接口
接口测试又称API测试
接口实例:系统与系统间的接口调用,作用:实现了两个或多个独立系统或模块间的通信和数据交换能力。
常见的Web接口类型
REST接口——通过HTTP的get和post方式得到数据,返回报文json格式
SOAP接口——通过soap协议得到数据,相比Httpservice能处理更加复杂的数据类型,请求报文和返回报文xml格式
Http接口的组成
eg:http://127.0.0.1:80/user.php?act=register
请求协议:http://
IP:127.0.0.1
端口号:80
接口地址:user.php
接口参数:act
参数值:register
SOAP接口
SOAP实际上就是HTTP+XML
无论哪种语言开发的平台,只要是网页开发都可以通过http协议来进行通信,并且返回的数据想要通用的话,可以使用XML格式来编写
面试题:什么是RESTful?
RESTful是REST的全程。
提供了一组客户端和服务器交互的规则。
当用“GET”方式时,只用来获取数据,成功了返回http状态码200。
当用“POST”方式时,只用来创建数据,成功了返回http状态码201
当用“PUT”方式时,只用来修改更新数据,成功了返回http状态码203
当用“DELETE”方式时,只用来删除数据,成功了返回http状态码204
ps:GET(SELECT):从服务器取出资源(一项或多项)。
POST(CREATE):在服务器新建一个资源。
PUT(UPDATE):在服务器更新资源(客户端提供改变后的完整资源)。
PATCH(UPDATE):在服务器更新资源(客户端提供改变的属性)。
DELETE(DELETE):从服务器删除资源。
为什么要做接口测试?
尽早进行系统集成测试,暴露BUG
解决系统测试复杂度
屏蔽UI层的不稳定性
检查系统安全性,稳定性
接口经过测试稳定了,前端页面随便改,减少BUG的产生
接口测试的原理
原理:模拟客户端向服务器发送请求报文,服务器接受请求报文后对相应的报文做处理并向客户端返回应答,客户端再接受应答的一个过程。
接口测试是黑盒测试。作为黑盒测试,基本的测试思路是通过输入和输出判断被测系统或者对象的逻辑。
接口测试关注点
关注在系统架构的业务逻辑层,不注重UI操作或者用户感观
检查数据的交换,传递和控制管理过程
注重系统间的相互逻辑关系调用
接口测试的范围
按测试类型分:功能、性能、安全性
按数据的输入输出分:
1、进入系统的接口(调用外部系统的参数为本系统使用)
2、数据流出系统接口(验证系统处理后的数据是否正常)
接口测试和UI测试的异同点
UI的操作实际上就是用另一种方式调用接口,那么接口有多少种参数组合就要求UI用例要构造多少种操作进行调用
UI操作所需要的数据可以用接口来生成
接口测试可以保证数据和逻辑的准确性,UI测试需要考虑交互和界面展示的逻辑正确性
UI测试需要重视接口调用不成功或者接口异常情况下UI的呈现方式和用户体验
UI中可能会有一些状态的缓存信息(这样就不需要每次频繁调用接口去获取了),比如鉴权信息等,需要重点关注这些缓存的更新策略
接口测试的三种形式
手动测试:辅助工具、Fiddler、Postman、HttpWath。。。
自动化测试:自己开发的工具、SoapUI、RobotFramework。。。
性能测试:自己开发的工具、Jmeter、LoadRunner。。。
如何开展接口测试
找开发或者开发主管索要接口说明文档(API文档)。作用:是开发测试脚本的依据
熟悉业务,设计测试用例,准备测试数据
根据接口说明文档开发接口测试脚本,执行脚本
API文档
测试文档接口说明,参数,返回值,是否齐全
熟悉业务
设计测试用例,准备测试数据
开发接口测试脚本
执行脚本,调入数据
提交BUG
写报告
一份好的接口说明文档是什么样的?
在项目中,一份完整的接口文档应该包含以下的内容:
接口说明
请求方式(getpost)
请求地址
请求参数、参数类型、请求参数说明
返回参数说明
返回示例
HTTP协议——Http请求
请求:Request,由客户端发送给服务器端
请求分类:GET和POST请求(有什么区别?)
GET请求主要是数据的获取
POST请求主要是数据的提交
HTTP协议——Http响应
响应:Response,由服务器端返回给客户端
响应包含正常的响应和异常的响应。
HTTP协议通过响应的状态码来进行定义:1xx,2xx,3xx(正常),4xx,5xx(异常)
接口功能测试点
接口文档规范性
接口可用性
接口实现功能验证
输入输出参数个数及命名
输入参数的必填项
输入参数的合法性
输出参数内容的正确性
接口传递参数的安全性
——接口可用性
主要测试接口是否可用、接口是否存在、接口的协议类型
测试用例中应包括:
依据接口文档中给定的接口地址和协议方法能够访问到该接口。
使用错误的协议方法无法按照接口地址进行访问。
使用正确的协议方法无法按照错误的接口地址进行访问。
——输入输出参数个数及命名
主要测试接口包含的输入输出参数的个数以及各个参数的命名是否正确。
测试用例中应包括:
依据接口文档检查输入参数的个数以及命名是否和文档一致。
依据接口文档检查输出参数的个数以及命名是否和文档一致(注意检查输出的正常参数和异常参数)。
输入错误的参数名,接口会报错,并有错误信息返回。
——输出参数内容的正确性
主要对输出参数的内容是否和后台真实数据一致进行检查。
测试用例中应包括:
考虑多种输入参数的组合情况,依次测试在这些组合情况下接口返回的数据的各字段内容是否正确,要具体检查每个字段的内容。一般通过与后台数据库数据比较来进行检查。
考虑多种输入参数的组合情况,依次测试在这些组合情况下接口返回的数据中涉及输入参数的项,是否和最初输入的值一致。
——接口实现功能验证
主要对接口操作的具体功能是否正常运转进行检查。
测试用例中应包括:
输入正确的参数,检查接口对应的要实现的后台功能是否正确运转。例如:对一个启动接口发送启动的命令,接口对应的后台系统能够正确启动并返回正确的参数。
输入错误的参数,检查接口对应的要实现的后台功能是否没有运转。
——接口文档规范性
主要对开发提供的接口文档是否规范准确进行检查。
测试用例中应包括:
接口文档中对于输入输出参数都有准确的命名,不存在模糊的情况。
接口文档对于每一个参数都有明确的类型说明,是否可选还是必输,是否有默认值。
接口文档对于每一个输入参数都有明确好基本的录入条件,比如长度最长多少、只能为数字还是字母、不能含有特殊字符等。
针对一个接口如果有多种类型的输出参数组合且参数的命名或者个数有不同,这种情况,要在接口文档中罗列清晰,并明确指出出现这种类型的输出参数的条件。
——接口传递参数的安全性
接口传递参数的加密显示
防止SQL注入攻击
——SQL注入的原理
定义:利用现有应用程序,将(恶意)的SQL命令注入到后台数据库引擎执行的能力。
用于没有对用户的输入数据进行必要的合法性判断,导致了攻击者可用提交一段数据库查询代码,根据程序返回的结果,获得一些他想要得到的数据。
举例:
在用户名输入框中输入:’or 1=1 #,密码随便输入,这时候的合成后的SQL查询语句为:
select * from users where username = '' or 1=1 #' and password = md5('')
等价于:select * from users where username = '' or 1=1
接口测试用例怎么写
三个步骤:
初始化测试数据
调用接口,传入输入数据
对输出断言
内容来源于网络如有侵权请私信删除