接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换、传递和控制管理过程,以及系统间的相互逻辑依赖关系等。
接口是一种用来定义程序的协议,是一组规则的集合。它规定了实现本接口的类,或接口必须拥有的一组规则。
1.1.1 为什么需要接口?
接口的意义在于抽象,从而使同类事物在同一高度具有通用及可替代性。
在系统分析和架构中,分清层次和依赖关系,每个层次不是直接向其上层提供服务(即不是直接实例化在上层中),而是通过定义一组接口,仅向上层暴露其接口功能,上层对于下层仅仅是接口依赖,而不依赖具体类。
优点: 系统灵活性增强: 当下层需要改变时,只要接口及接口功能不变,则上层不用做任何修改。甚至可以在不改动上层代码时将下层整个替换掉,就像我们将一个WD的60G硬盘换成一个希捷的160G的硬盘,计算机其他地方不用做任何改动,而是把原硬盘拔下来、新硬盘插上就行了,因为计算机其他部分不依赖具体硬盘,而只依赖一个IDE接口,只要硬盘实现了这个接口,就可以替换上去。 不同部件或层次的开发人员可以并行开工: 就像造硬盘的不用等造CPU的,也不用等造显示器的,只要接口一致,设计合理,完全可以并行进行开发,从而提高效率。
常见的层次:
界面层:
也就是展示层,直接呈现给用户的,可能不同的软件有不同的呈现方式,比如Web,WinForm,甚至移动APP。在这个层次,一般没有必要写太多的接口。
业务逻辑层:
可以根据需要使用接口。如果是直接读写数据库之类的,就直接用调用数据库访问层的接口。如果是与多个第三方接口进行交互,那么就需要接口,不同的渠道各自实现。
数据访问层:
最好使用接口,比如数据库访问。可以根据不同的数据库实现相应的接口,向业务逻辑层提供服务。
1.1.2 软件设计中有关接口的原则
依赖倒置原则:
高层模块不应该依赖底层模块,两者都应该依赖其抽象,抽象不应该依赖细节,细节应该依赖抽象。即要面向接口编程。
接口隔离原则:
客户端不应该依赖它不需要的接口,一个类对另一个类的依赖应该建立在最小的接口上。即设计接口的时候要精简单一。
1.1.3 软件接口的分类:
系统与系统之间的调用,如微信向用户提供统一的对外接口,程序员调用接口完成基于微信的小程序等。
同一系统内部上层服务对下层服务的调用,如一个软件程序一般分为表示层,业务层和数据层,表示层调用业务层的接口来完成自己的工作,而业务层又会调用数据层的接口来实现相应的业务等。
不同接口类型的差异:
参数提交方式不同
请求数据大小不同
安全性
在项目开发中,web项目的前后端分离开发、APP开发,需要由前后端工程师共同定义接口,编写接口文档,之后大家都根据这个接口文档进行开发,到项目结束前都要一直维护。
1.2.1 为什么需要接口文档
项目开发过程中前后端工程师有一个统一的文件进行沟通交流开发。正规的团队合作或者是项目对接,接口文档是非常重要的,一般接口文档都是通过开发人员写的。
项目维护中或者项目人员更迭,方便后期人员查看、维护。
不是随便一个功能就要有个接口,也不是随便一个需求就要加个接口。每新建一个接口,就要有充分的理由和考虑,无意义的接口不仅增加了维护的难度,更重要是对于程序的可控性的大大降低,接口也会十分臃肿。
1.2.2 接口规范
接口包含: 请求(request)、响应(response)、服务器(host)、路径(path)、参数(query)、 状态码(code)、请求类型(method)、请求时间(start)、响应时长(duration)、响应大小(size)、状态(status)。
接口主要可以分为四部分:方法、uri、请求参数、返回参数。
1.2.2.1 方法
新增(post)
修改(put)
删除(delete)
获取(get)
1.2.2.2 uri
统一资源标识符(Uniform Resource Identifier,URI)是一个用于标识某一互联网资源名称的字符串。 该种标识允许用户对任何(包括本地和互联网)的资源通过特定的协议进行交互操作。URI由包括确定语法和相关协议的方案所定义。
统一资源定位符(Uniform Resource Locator,URL),统一资源名称(Uniform Resource Name,URN)是URI的子集。 URL是一种URI,它标识一个互联网资源,并指定对其进行操作或获取该资源的方法。可能通过对主要访问手段的描述(比如采用何种协议 http、ftp…),也可能通过网络“位置”进行标识。。 例如,http://www.wikipedia.org/这个URL,标识一个特定资源(首页)并表示该资源的某种形式(例如以编码字符表示的,首页的HTML代码)是可以通过HTTP协议从www.wikipedia.org这个网络主机获得的。
URI格式:
URL的格式由三部分组成:
第一部分是协议(或称为服务方式,例如http、ftp、mailto、file)。
第二部分是存有该资源的主机IP地址(有时也包括端口号)。
第三部分是主机资源的具体地址。
[协议名]://[用户名]:[密码]@[服务器地址]:[服务器端口号]/[路径]?[查询字符串]#[片段ID] 登录信息(用户名:密码):指定用户名和密码作为从服务器端获取资源时必要的登录信息(身份认证),此项是可选项。 服务器地址:使用绝对 URI 必须指定待访问的服务器地址。地址可以是类似 hackr.jp 这种 DNS 可解析的名称,或是 192.168.1.1 这类 IPv4 地址名,还可以是 [0:0:0:0:0:0:0:1] 这样用方括号括起来的 IPv6 地址名。 服务器端口号:指定服务器连接的网络端口号。此项也是可选项,若用户省略则自动使用默认端口号。 带层次的文件路径:指定服务器上的文件路径来定位特指的资源。这与 UNIX 系统的文件目录结构相似。 查询字符串:针对已指定的文件路径内的资源,可以使用查询字符串传入任意参数。此项可选。 片段标识符:使用片段标识符通常可标记出已获取资源中的子资源(文档内的某个位置)。但在 RFC 中并没有明确规定其使用方法。该项也为可选项。
以/a开头,如果需要登录才能调用的接口(如新增、修改;前台的用户个人信息,资金信息等)后面需要加/u,即:/a/u
中间一般放表名或者能表达这个接口的单词
get方法,如果是后台通过搜索查询列表,那么以/search结尾,如果是前台的查询列表,以/list结尾
注意:uri地址里不允许出现大写字母,如果是两个单词拼接,用/分开。
1.2.2.3 请求参数
请求参数和返回参数都分为五列:字段、说明、类型、备注、是否必填。
字段是类的属性
说明是中文释义
类型是属性类型,只有String、Number、Object、Array四种类型
备注是一些解释,或者可以写一下例子,比如负责json结构的情况,最好写上例子,好让前端能更好理解
是否必填指的是,字段是否必填。
1.2.2.4 返回参数
返回参数结构有几种情况:
1、如果只返回接口调用成功还是失败(如新增、删除、修改等),则只有一个结构体:code和message两个参数。
2、如果要返回某些参数,则有两个结构体:
code/mesage/data
data里写返回的参数,data是object类型
3、如果要返回列表,那么有三个结构体:
code/mesage/data
data是object,里面放置page/size/total/totalPage/list 五个参数,其中list是Arrary类型
list里放object,object里是具体的参数。
1.2.2.5 示例1
请求地址:get /a/student/list
请求参数:
字段 | 说明 | 类型 | 备注 | 是否必填 |
page | 页码 | Number | 默认1 | 否 |
size | 一页展示个数 | Number | 默认10 | 否 |
返回参数:
字段 | 说明 | 类型 | 备注 | 是否必填 |
code | 接口状态码 | Number | 成功(1),失败(0) | 是 |
message | 接口信息 | String | 成功(success),失败(提示信息) | 是 |
data | Object | 是 |
其中data:
字段 | 说明 | 类型 | 备注 | 是否必填 |
page | 是 | |||
size | 是 | |||
totalPage | 总页数 | Number | 是 | |
list | student list | Array | 是 |
其中list:
字段 | 说明 | 类型 | 备注 | 是否必填 |
id | Number | 是 | ||
name | 姓名 | String | 是 | |
gender | 性别 | Number | 男(0),女(1) | 是 |
1.2.2.6 示例2:用户登录注册
1、登录
http请求方式: POST(请使用https协议)
https://localhost:8080/hu/vue/userAction_login.action
登录成功返回JSON数据包:
{ "msg":"登录成功", "result":{ "uname":"你登录的用户名", "pwd":"你登录的密码" }, "code":1 }
如果登录成功code返回1,否则返回0,msg是提示信息。
说明:
2、注册
注册返回JSON数据包:
{ "msg":"用户注册成功", "code":1 }
说明:
接口测试的用例设计与单元测试有相似之处,都需要用到如:边界值法、等价类法等基本测试方法。
设计接口测试用例的出发点是要验证接口实现的功能与性能指标与接口设计文档的一致性
测试接口具有良好的容错机制,能在接收到各种异常输入数据时做到:
返回对错误定位具有良好参考意义的错误码
屏蔽底层错误信息
接口测试用例需要暴露接口代码更多的代码缺陷
注意:一个系统可能有很多的层次结构,也就有了不同层级的许多接口,如果对每个接口分别进行测试,时间和人力消耗较大, 且用例数量大,用例的维护成本很大。分析出系统的关键模块和核心接口,并对其进行完整的测试,能以最小的测试投入, 达到最好的测试效果。
2.1.1 功能
功能是否正常,以及功能是否按照接口文档实现。
2.1.2 业务逻辑
是否依赖业务。
2.1.3 异常
1、参数异常:
关键字参数(语言中的关键字)
参数为空
多、少参数
错误参数
2、数据异常:
关键字数据
数据为空
长度不一致(超出数据库字段长度)
错误数据
2.1.4 安全
cookie
header(特别是移动端使用)
是服务器以HTTP协议传HTML资料到浏览器前所送出的字串,在标头与HTML文件之间尚需空一行分隔。
唯一识别码(客户端常用)
3.1.1 抓取接口的工具
httpwatch(ie、火狐的插件)
缺点只能在ie、火狐用,其他浏览器不支持
看数据比较麻烦
wireshark
功能比较齐全
经过电脑的所有请求都会抓取
看数据比较麻烦
fiddler
轻量级
功能比较齐全
抓包工具
可进行接口测试
使用比较多
3.1.2 测试接口的工具
loadrunner
可进行性能测试,因为在这个软件里所有的性能测试都是基于HTTP请求的。
fiddler
soapui
比较强大的接口测试工具,可以做自动化测试。
Jmeter
可以做性能测试,同loadrunner。
postman
最常用的,以前是集成在谷歌浏览器的。
python自己开发
作者:黑黑白白君
原文链接:https://blog.csdn.net/m0_37621024/article/details/116505090