本文大纲截图:
接口:系统与系统之间,组件与组件之间,数据传递交互的通道。
按协议划分:http、tcp、Ip、websocket
按语言划分:C++、Java、PHP ......
按范围划分:
系统之间:多个内部系统之间,内部系统与外部系统之间
程序之间:方法与方法之间,函数与函数之间,模块与模块之间
在众多类型接口中,HTTP协议接口是应用最为广泛的一种接口类型。
HTTP: HyperText Transfer Protocol
,超文本传输协议,是一个基于请求与响应模式的、应用层的协议,也是互联网上应用最为广泛的一种网络协议。
支持客服端/服务器模式
简单快速: 客户向服务器请求服务时,只需传送请求方法和路径。
灵活: HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type
加以标记。
无连接: 每次请求一次,释放一次连接,每次连接只能处理一个请求。优点节省传输时间,实现简单。这种无连接为短连接。对应是长链接(一个连接可以多次请求,长连接专门解决效率问题,但容易造成占用资源不释放的问题),HTTP协议头部中字段Connection:keep-alive
表示支持长链接。
无状态: HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。为了解决HTTP协议无状态,Cookie
和Session
两种用于保持HTTP连接状态的技术就应运而生。(Cookie
客户端保持状态:Cookie
是由服务器发给客户端并以文本文件的方式存放在客户端的特殊信息,然后客户端每次向服务器发送请求的时候都会带上这些特殊的信息;这些信息存放于HTTP响应头(Response Header
)。如:网站登录界面中的“请记住我”的选项就是Cookie
技术的应用。)(Session
服务器来保持状态:Session
指的是服务器端为客户端所开辟用于保存保持状态信息的存储空间;Session
被创建后,调用Session
相关的方法往Session
中增加内容,这些内容只会保存在服务器中,发到客户端的只有Session id
;当客户端再次发送请求时,会将这个Session id
带上,服务器接收到请求后会依据Session id
找到相应的Session
,用来保持用户状态。)
3.3.1 基本介绍
URL概念:Uniform Resource Locator,统一资源定位符,是因特网的万维网服务程序上用于指定信息位置的表示方法。
URL作用:在网络环境中,唯一的定义一个数据资源。
3.3.2 语法格式
说明:[]
为可选项,可填写也可省略。
protocol
协议:常用的协议是http,规定数据传输的方式。
hostname
主机地址:为域名或IP地址,在网络环境中找到主机。http协议中用://
与协议隔开。
port
端口:(常省略)在网络上,标识一个进程(应用程序);端口(0-65535),http默认端口号80,https默认端口号443。用:
与域名隔开。
path
路径:网络资源在服务器中的指定路径,标识网络资源(文件、图片、音视频、变量...)。用/
与端口隔开。
parameter
参数:向服务器传入参数,用于指定特殊参数的可选项。用/
与路径隔开,多个参数用;
隔开。
query
查询字符串:需要从服务器那里查询内容,传递给资源路径对应的数据。用?
与资源路径隔开;多个查询参数内容间用&
连接多个KV对(键值对)。
fragment
片段:网页中可能会分为不同的片段,fragment用于定位到达指定位置。用#
与查询参数隔开。
3.4.1 HTTP请求的作用
客户端(app、浏览器),发送请求给服务器时,使用的协议——http请求协议;
规定发送给服务器的数据传输的语法格式。
3.4.2 HTTP请求的整体格式
请求行: http请求第一行。格式:请求方法(空格)URL(空格)协议版本
请求头: 语法格式:k:v
User-Agent
:描述 请求发送端 的浏览器类型。
Content-Type
:描述 请求体 的数据类型。(application/json
:JSON数据格式;application/x-www-form-urlencoded
:form表单数据。)
空行: 代表http请求头结束。
请求体: 请求发送时携带的数据。数据类型Content-Type
的值!(post
和put
有请求体;get
和 delete
没有请求体。)
3.5.1 HTTP响应的作用
服务端,针对客户端发送的http请求,回发响应数据。——http应答!
规定 回发给客户端的数据组织格式。
3.5.2 HTTP响应的整体格式
响应行(状态行):协议版本(空格)状态码(空格)状态描述
协议版本:如:HTTP/1.1
响应状态码:1xx
:代表指示信息。表示请求已经被接收,等待继续处理;2xx
:代表请求成功被处理、接收。常见:200、201
;3xx
:重定向,待访问的资源,需求重新指定路径访问;4xx
:代表客户端错误。常见:404、403
;5xx
:服务器遇到错误而不能完成该请求。常见:502、504
。
状态描述:一般与状态码 唯一对应。如200——ok
,404——file not found
响应头: 语法格式:k:v
Content-Type
:描述 响应体中数据类型
Content-Length
:响应体的大小。可以不写,浏览器会自动求取。一旦写,必须准确!
空行: 代表响应头结束
响应体: 绝大多数不为空(请求成功:回发数据,失败:回发错误信息;数据类型受Content-Type值
影响;回发给客户端的消息内容,常见的有html网页、xml、json、text/html
)
3.6.1 传统风格接口
特点:
1)请求方法,只使用get和post即可。
2)URL不唯一。同一个操作可以对应不同的URL。
3)状态码的使用较单一。200最常见。
举例:
3.6.2 RESTful风格接口
定义:
REST:即 Representational State Transfer 的缩写。词组的翻译是“表现层状态转化”。如果一个架构符合 REST 原则,就称它为RESTful架构。是一种软件架构风格、设计风格,而不是标准,只是提供了一组设计原则和约束条件。
特点:
1)每一个URL代表一种资源
2)客户端和服务器之间,传递这种资源的某种表现层
3)客户端通过四个HTTP动词(get、post、put、delete),对服务器端资源进行操作,实现“表现层状态转化”;
4)接口之间传递的数据最常用格式为JSON。
举例:
接口测试:接口测试就是对系统或组建件之间的接口进行测试。校验传递的数据正确性和逻辑依赖关系的正确性!接口测试主要针对的测试目标——服务器。
接口自动化测试:借助工具、代码,模拟客户端发送请求给服务器,借助断言自动判断 预期结果和实际结果 是否一致!
符合质量控制前移的理念
可以发现一些页面操作发现不了的问题
接口测试低成本高效益
接口测试是从用户的角度对系统进行检测
1.3.1 怎么测?
模拟客户端,向服务器发送请求。
1.3.2 用什么测?
工具:fiddler、postman、jmeter
代码:python + UnitTest框架 + Requests框架
1.3.3 测什么?
测试服务器针对客户端请求,回发的响应数据是否与预期结果一致!
——人眼对比、断言
1.3.4 接口测试实现方式
工具:JMeter、Postman、fiddler
代码:python + Requests + UnitTest
1)分析需求,产生需求文档(产品经理)
2)产生接口文档,解析接口文档(研发人员)
3)根据研发的接口文档,产生接口测试用例,并送审(测试人员)
4)执行接口测试用例(测试人员)
5)提交并跟踪缺陷(测试人员)
6)生成接口测试报告(测试人员)
7)接口自动化持续集成(可选)(测试人员)
3.1.1 概念
接口文档: 又称为API文档,一般是由开发人员编写,描述接口信息的文档。开发团队按接口文档进行开发工作,并要一直维护遵守。
3.1.2 作用
1)能够让前端开发与后台开发人员更好的配合,提高工作效率。(有一个统一参考的文件)
2)项目迭代或者项目人员更迭时,方便后期人员查看和维护
3)方便测试人员进行接口测试
3.1.3 接口文档呈现形式
Word文档形式:
Excel表格形式:
本文大纲截图:
接口:系统与系统之间,组件与组件之间,数据传递交互的通道。
按协议划分:http、tcp、Ip、websocket
按语言划分:C++、Java、PHP ......
按范围划分:
系统之间:多个内部系统之间,内部系统与外部系统之间
程序之间:方法与方法之间,函数与函数之间,模块与模块之间
在众多类型接口中,HTTP协议接口是应用最为广泛的一种接口类型。
HTTP: HyperText Transfer Protocol
,超文本传输协议,是一个基于请求与响应模式的、应用层的协议,也是互联网上应用最为广泛的一种网络协议。
支持客服端/服务器模式
简单快速: 客户向服务器请求服务时,只需传送请求方法和路径。
灵活: HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type
加以标记。
无连接: 每次请求一次,释放一次连接,每次连接只能处理一个请求。优点节省传输时间,实现简单。这种无连接为短连接。对应是长链接(一个连接可以多次请求,长连接专门解决效率问题,但容易造成占用资源不释放的问题),HTTP协议头部中字段Connection:keep-alive
表示支持长链接。
无状态: HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。为了解决HTTP协议无状态,Cookie
和Session
两种用于保持HTTP连接状态的技术就应运而生。(Cookie
客户端保持状态:Cookie
是由服务器发给客户端并以文本文件的方式存放在客户端的特殊信息,然后客户端每次向服务器发送请求的时候都会带上这些特殊的信息;这些信息存放于HTTP响应头(Response Header
)。如:网站登录界面中的“请记住我”的选项就是Cookie
技术的应用。)(Session
服务器来保持状态:Session
指的是服务器端为客户端所开辟用于保存保持状态信息的存储空间;Session
被创建后,调用Session
相关的方法往Session
中增加内容,这些内容只会保存在服务器中,发到客户端的只有Session id
;当客户端再次发送请求时,会将这个Session id
带上,服务器接收到请求后会依据Session id
找到相应的Session
,用来保持用户状态。)
3.3.1 基本介绍
URL概念:Uniform Resource Locator,统一资源定位符,是因特网的万维网服务程序上用于指定信息位置的表示方法。
URL作用:在网络环境中,唯一的定义一个数据资源。
3.3.2 语法格式
说明:[]
为可选项,可填写也可省略。
protocol
协议:常用的协议是http,规定数据传输的方式。
hostname
主机地址:为域名或IP地址,在网络环境中找到主机。http协议中用://
与协议隔开。
port
端口:(常省略)在网络上,标识一个进程(应用程序);端口(0-65535),http默认端口号80,https默认端口号443。用:
与域名隔开。
path
路径:网络资源在服务器中的指定路径,标识网络资源(文件、图片、音视频、变量...)。用/
与端口隔开。
parameter
参数:向服务器传入参数,用于指定特殊参数的可选项。用/
与路径隔开,多个参数用;
隔开。
query
查询字符串:需要从服务器那里查询内容,传递给资源路径对应的数据。用?
与资源路径隔开;多个查询参数内容间用&
连接多个KV对(键值对)。
fragment
片段:网页中可能会分为不同的片段,fragment用于定位到达指定位置。用#
与查询参数隔开。
3.4.1 HTTP请求的作用
客户端(app、浏览器),发送请求给服务器时,使用的协议——http请求协议;
规定发送给服务器的数据传输的语法格式。
3.4.2 HTTP请求的整体格式
请求行: http请求第一行。格式:请求方法(空格)URL(空格)协议版本
请求头: 语法格式:k:v
User-Agent
:描述 请求发送端 的浏览器类型。
Content-Type
:描述 请求体 的数据类型。(application/json
:JSON数据格式;application/x-www-form-urlencoded
:form表单数据。)
空行: 代表http请求头结束。
请求体: 请求发送时携带的数据。数据类型Content-Type
的值!(post
和put
有请求体;get
和 delete
没有请求体。)
3.5.1 HTTP响应的作用
服务端,针对客户端发送的http请求,回发响应数据。——http应答!
规定 回发给客户端的数据组织格式。
3.5.2 HTTP响应的整体格式
响应行(状态行):协议版本(空格)状态码(空格)状态描述
协议版本:如:HTTP/1.1
响应状态码:1xx
:代表指示信息。表示请求已经被接收,等待继续处理;2xx
:代表请求成功被处理、接收。常见:200、201
;3xx
:重定向,待访问的资源,需求重新指定路径访问;4xx
:代表客户端错误。常见:404、403
;5xx
:服务器遇到错误而不能完成该请求。常见:502、504
。
状态描述:一般与状态码 唯一对应。如200——ok
,404——file not found
响应头: 语法格式:k:v
Content-Type
:描述 响应体中数据类型
Content-Length
:响应体的大小。可以不写,浏览器会自动求取。一旦写,必须准确!
空行: 代表响应头结束
响应体: 绝大多数不为空(请求成功:回发数据,失败:回发错误信息;数据类型受Content-Type值
影响;回发给客户端的消息内容,常见的有html网页、xml、json、text/html
)
3.6.1 传统风格接口
特点:
1)请求方法,只使用get和post即可。
2)URL不唯一。同一个操作可以对应不同的URL。
3)状态码的使用较单一。200最常见。
举例:
3.6.2 RESTful风格接口
定义:
REST:即 Representational State Transfer 的缩写。词组的翻译是“表现层状态转化”。如果一个架构符合 REST 原则,就称它为RESTful架构。是一种软件架构风格、设计风格,而不是标准,只是提供了一组设计原则和约束条件。
特点:
1)每一个URL代表一种资源
2)客户端和服务器之间,传递这种资源的某种表现层
3)客户端通过四个HTTP动词(get、post、put、delete),对服务器端资源进行操作,实现“表现层状态转化”;
4)接口之间传递的数据最常用格式为JSON。
举例:
接口测试:接口测试就是对系统或组建件之间的接口进行测试。校验传递的数据正确性和逻辑依赖关系的正确性!接口测试主要针对的测试目标——服务器。
接口自动化测试:借助工具、代码,模拟客户端发送请求给服务器,借助断言自动判断 预期结果和实际结果 是否一致!
符合质量控制前移的理念
可以发现一些页面操作发现不了的问题
接口测试低成本高效益
接口测试是从用户的角度对系统进行检测
1.3.1 怎么测?
模拟客户端,向服务器发送请求。
1.3.2 用什么测?
工具:fiddler、postman、jmeter
代码:python + UnitTest框架 + Requests框架
1.3.3 测什么?
测试服务器针对客户端请求,回发的响应数据是否与预期结果一致!
——人眼对比、断言
1.3.4 接口测试实现方式
工具:JMeter、Postman、fiddler
代码:python + Requests + UnitTest
1)分析需求,产生需求文档(产品经理)
2)产生接口文档,解析接口文档(研发人员)
3)根据研发的接口文档,产生接口测试用例,并送审(测试人员)
4)执行接口测试用例(测试人员)
5)提交并跟踪缺陷(测试人员)
6)生成接口测试报告(测试人员)
7)接口自动化持续集成(可选)(测试人员)
3.1.1 概念
接口文档: 又称为API文档,一般是由开发人员编写,描述接口信息的文档。开发团队按接口文档进行开发工作,并要一直维护遵守。
3.1.2 作用
1)能够让前端开发与后台开发人员更好的配合,提高工作效率。(有一个统一参考的文件)
2)项目迭代或者项目人员更迭时,方便后期人员查看和维护
3)方便测试人员进行接口测试
3.1.3 接口文档呈现形式
Word文档形式:
Excel表格形式:
PDF文档形式:
本质: 从接口文档中,找出http请求所需要的数据信息。如:请求方法、URL、请求头、请求体、响应状态码、描述、错误码。
以登录为例:
请求方法:POST
URL:http://localhostt/api/sys/login
请求头:Content-Type:application/json
请求体:{"mobile":"13600000000","password":"123456"}
响应状态码:200
错误码:10000
:操作成功;20001
:用户或密码错误;99999
:抱歉,系统繁忙,请稍后重试!
1)防止测试点漏测,条理清晰。
2)方便分配工作,评估工作量和时间
功能测试
单接口功能: 手工测试中的单个业务模块,一般对应一个接口。如:登录业务——登录接口、加入购物车业务——加入购物车接口、订单业务——订单接口、支付业务——支付接口。借助工具、代码。绕开前端界面,组织接口所需要的的数据,展开接口测试。
业务场景功能: 按照用户实际使用场景,梳理 接口业务场景。组织业务场景时,一般只需做正向测试
即可(与手工一致)。一般建议用最少的 用例 覆盖最多的业务场景。如:登录-搜索商品-加入购物车-下单-支付-评价。
性能测试
响应时长、吞吐量、并发数、服务器资源使用率
安全测试
业务安全: 敏感数据是否加密、SQL注入,如' or 1=1#等
攻击安全: 由专业安全测试工程师完成。
4.3.1 与手工设计相同之处
手工测试 对应的功能测试点,与接口测试对应的功能 完全一致。
举例:
4.3.2 与手工设计不同之处
1)手工测试 测写入到输入框中的数据是否正确。接口测试 测参数对应的参数值是否正确;
2)接口测试,不单单针对 参数值进行,还可以针对 参数本身 进行测试
4.3.3 接口测试用例设计基本思路
数值
正向数值(即 正确的)
反向数值:如:空值、等价类、边界值、错误值等待
参数
正向参数
必选参数:所有的必选(必填)都包含
组合参数:所有的必选+任意一个或多个可选参数
全部参数:所有的必选+所有的可选参数
反向参数
多参:多出一个或多个必选参数(可以任意指定)
少参:缺少一个或多个必选参数
无参:没有必选参数
错误参数:参数名输入错误
4.4.1 手工测试用例文档8
大要素
编号、用例名称(标题)、模块、优先级、预置条件、测试数据、操作步骤、预期结果
4.4.2 接口测试用例文档10
要素
编号、用例名称(标题)、模块、优先级、预置条件、请求方法、URL、请求头、请求体(请求数据)、预期结果
4.4.3 单接口测试用例示例
以 登录接口 为例:
登录模块接口测试点:
4.5.1 说明
用户怎么用,怎样设计业务
用最少的测试用例,尽量覆盖最多的接口
4.5.2 业务场景测试用例示例
以 员工管理 业务场景为例:
分析测试点:业务场景(登录-添加员工-查询员工-修改员工-再次查询-删除员工-查询员工列表)
添加员工:
查询员工:修改员工、删除员工、查询员工列表——都类似(略)
PDF文档形式:
本质: 从接口文档中,找出http请求所需要的数据信息。如:请求方法、URL、请求头、请求体、响应状态码、描述、错误码。
以登录为例:
请求方法:POST
URL:http://localhostt/api/sys/login
请求头:Content-Type:application/json
请求体:{"mobile":"13600000000","password":"123456"}
响应状态码:200
错误码:10000
:操作成功;20001
:用户或密码错误;99999
:抱歉,系统繁忙,请稍后重试!
1)防止测试点漏测,条理清晰。
2)方便分配工作,评估工作量和时间
功能测试
单接口功能: 手工测试中的单个业务模块,一般对应一个接口。如:登录业务——登录接口、加入购物车业务——加入购物车接口、订单业务——订单接口、支付业务——支付接口。借助工具、代码。绕开前端界面,组织接口所需要的的数据,展开接口测试。
业务场景功能: 按照用户实际使用场景,梳理 接口业务场景。组织业务场景时,一般只需做正向测试
即可(与手工一致)。一般建议用最少的 用例 覆盖最多的业务场景。如:登录-搜索商品-加入购物车-下单-支付-评价。
性能测试
响应时长、吞吐量、并发数、服务器资源使用率
安全测试
业务安全: 敏感数据是否加密、SQL注入,如' or 1=1#等
攻击安全: 由专业安全测试工程师完成。
4.3.1 与手工设计相同之处
手工测试 对应的功能测试点,与接口测试对应的功能 完全一致。
举例:
4.3.2 与手工设计不同之处
1)手工测试 测写入到输入框中的数据是否正确。接口测试 测参数对应的参数值是否正确;
2)接口测试,不单单针对 参数值进行,还可以针对 参数本身 进行测试
4.3.3 接口测试用例设计基本思路
数值
正向数值(即 正确的)
反向数值:如:空值、等价类、边界值、错误值等待
参数
正向参数
必选参数:所有的必选(必填)都包含
组合参数:所有的必选+任意一个或多个可选参数
全部参数:所有的必选+所有的可选参数
反向参数
多参:多出一个或多个必选参数(可以任意指定)
少参:缺少一个或多个必选参数
无参:没有必选参数
错误参数:参数名输入错误
4.4.1 手工测试用例文档8
大要素
编号、用例名称(标题)、模块、优先级、预置条件、测试数据、操作步骤、预期结果
4.4.2 接口测试用例文档10
要素
编号、用例名称(标题)、模块、优先级、预置条件、请求方法、URL、请求头、请求体(请求数据)、预期结果
4.4.3 单接口测试用例示例
以 登录接口 为例:
登录模块接口测试点:
4.5.1 说明
用户怎么用,怎样设计业务
用最少的测试用例,尽量覆盖最多的接口
4.5.2 业务场景测试用例示例
以 员工管理 业务场景为例:
分析测试点:业务场景(登录-添加员工-查询员工-修改员工-再次查询-删除员工-查询员工列表)
添加员工:
查询员工:修改员工、删除员工、查询员工列表——都类似(略)
最后感谢每一个认真阅读我文章的人,看着粉丝一路的上涨和关注,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走
我们学习软件测试必然是为了找到高薪的工作,下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料,并且有阿里大佬给出了权威的解答,刷完这一套面试资料相信大家都能找到满意的工作。
上面是我整理的配套资源,这些资源对于软件测试的的朋友来说应该是最全面最完整的备战仓库,为了更好地整理每个模块,我也参考了很多网上的优质博文和项目,力求不漏掉每一个知识点,很多朋友靠着这些内容进行复习,拿到了BATJ等大厂的offer,这个仓库也已经帮助了很多的软件测试的学习者,希望也能帮助到你。