读后笔记 -- Python 全栈测试开发 Chapter8：接口测试

合集 - Python 全栈测试开发(10)

1.读后笔记 -- Python 全栈测试开发 Chapter1 Python 实战实例2022-01-112.读后笔记 -- Python 全栈测试开发 Chapter2 自动化测试基础2022-07-033.读后笔记 -- Python 全栈测试开发 Chapter3：Selenium2022-02-144.读后笔记 -- Python 全栈测试开发 Chapter4：自动化测试框架：unittest2022-10-015.读后笔记 -- Python 全栈测试开发 Chapter7：移动自动化测试框架2022-10-17

6.读后笔记 -- Python 全栈测试开发 Chapter8：接口测试2022-11-05

7.读后笔记 -- Python 全栈测试开发 Chapter9：Postman + Newman 实现接口自动化2022-11-208.读后笔记 -- Python 全栈测试开发 Chapter10：接口的设计与开发2022-11-229.读后笔记 -- Python 全栈测试开发 Chapter11：Python + Requests 实现接口测试2022-12-0910.读后笔记 -- Python 全栈测试开发 Chapter12：pytest框架 + Allure 报告生成2023-02-04

收起

目录

• 8.1 接口测试
• 8.2 报文分析
• 8.2.4 cookie、token 和 session

返回目录

8.1 接口测试

1. 市场分布

• UI（web、app）自动化：10%
• 接口自动化：20%
• 单元测试：70% -- 测开

2. 接口类型：

1）结构划分：模块间（系统间）的接口称为内部接口；系统与第三方（如支付宝、微信、身份验证等。）接口称为外部接口。

     较常用的第三方接口：聚合API（https://www.juhe.cn/apiservice），通联API（金融相关，https://apidoc.datayes.com/app/overview）

2）接口类型划分：

接口类型	协议	数据格式	测试工具
http 接口	HTTP 协议（应用层）	application/json，text/html，text/xml....	fiddler、postman、jmeter、lr、 框架（RF、python+request、java+httpclient）
webservices 接口	SOAP 协议（应用层基于 http 协议封装）	请求和响应的数据格式都是 XML 格式	SoapUI、jmeter
socket 接口	socket 基于 tcp/udp 传输层抽象出的一层， 大多在 c/s 架构。建立连接后，可实现客户端 和服务器的双向数据通讯		socketTest、jmeter

3. 实际工作中接口的管理：

• office 文档管理；
• 共享、会话等功能的管理工具：postman、eolinker、apizza、easy_api、jira、confluence等

4. 接口模拟发送请求：

     fiddler：实现抓包、分析数据（篡改数据）、模拟请求发送、模拟弱网

　　fiddler \ Composer：可以模拟请求发送。

5. 测试方法：参数的组合、极值、是否必填

---

8.2 报文分析

1. 一个请求包含：：请求行 + 请求头 + 请求体

1）请求行： 请求方法 + 请求地址 + 请求协议版本

　　请求方法： GET、POST、PUT、DELETE、TRACE、OPTIONS、HEAD 等

• GET：从服务器获取资源。1）数据直接暴露在地址栏，不适合私密数据传输；2）最多识别 1024 个字符，不适合大数据传输；
• POST：提交表单数据资源。
• PUT：数据存储在服务器
• DELETE：删除服务器资源
• TRACE：回显信息，主要用于测试或debug
• OPTIONS：获取服务器针对某些特定的资源所支持的 HTTP 请求方法
• HEAD：获取头信息

  GET v.s. POST：

• （1）GET 参数在 URL 中（导致：a. 长度限制， b. 相对安全性）；POST 参数在 body 中；
• （2）GET 请求只提交一次数据；POST 提交 2 次数据（先发送 head 数据 -> 服务器回应 100 -> 再发送 body 数据）

  POST v.s. PUT：

• POST 对数据的增加；PUT：对数据的修改

2）请求头：键值对组成

• （1）Connection：keep-alive （常连接，client 可继续向服务器发送请求，且保持当前状态）；close 当前会话关闭；
• （2）Content-Length：请求体文本长度，可用于检测是否丢包；
• （3）Cache-Control：缓存控制，含：age，max-age，min-age，单位秒，还可设置访问权限 private；与之对应的是 Expires 缓存到期时间
• （4）Content-Type：文本类型，值语法：type/subtype; params.
•           常用的 4 种类型：
•                   （4.1）text/html：最常用的一种，返回一个 html 页面
•                   （4.2）application/json：接口测试常用，返回 json 数据
•                   （4.3）application/x-www-form-urlencoded：针对需要提交表单所声明的文本类型。值通常是 键值对 形式，key1=value1&key2=value2....
•                   （4.4）application/form-data：通常应用在文件上传下载，数据格式以分割线形式表示。
•                      注意：不同工具在 post 请求时，其参数都以 key=value 形式存在，但是默认值不同。jmeter 默认是 application/x-www-form-urlencoded，fiddler、postman 都表单请求 默认类型 不是
•            常用的文本类型： text/plain、text/html、text/xml、image/png、image/jpg、image/jpeg ...
• （5）Accept：当前客户端允许解析的文本数据类型。 */* 表示允许解析所有类型

3）请求体：请求体的值与请求头之间会空一行；如果是 GET 请求，则是空值

 

Fiddler 的详细使用参照： https://www.cnblogs.com/bruce-he/p/16906966.html

 

---

 

 ***** 下面是测试 不同测试工具的默认类型 *****

Postman 请求：

    

?

1 2 3 4

！！！ Postman 1. Params 中放置的 参数键值对，最终会被放置在 url 中，形成 get 请求方式，即使请求类型选择为 post   2. Post 请求，其参数需要放置在 body 中

Fiddler：

1）直接默认发送请求：

• 在 Composer 请求栏：http://ws.webxml.com.cn/WebServices/MobileCodeWS.asmx/getMobileCodeInfo
• body 中输入：mobileCode=18918457828&userID=
• 请求类型：post

=> 结果：报 500，

（2）Header 中添加 Content-Type 后，请求成功。

• 在 Composer 请求栏：http://ws.webxml.com.cn/WebServices/MobileCodeWS.asmx/getMobileCodeInfo
• body 中输入：mobileCode=18918456666&userID=
• 请求类型：post
• Header 里添加：Content-Type: application/x-www-form-urlencoded

     

2. HTTP 相应：状态行 + 消息报文 + 相应正文

状态行：协议/版本 + 状态码 + 状态（状态码的文本描述）

状态码，主要包含：

• 1xx ： 提示信息，服务器已接受当前请求；代表有 100
• 2xx ：请求被接受；代表有 200
• 3xx ： 重定向，要完成请求必须进行下一步操作；代表有 301， 302， 304
• 4xx ： 客户端错误，请求有语法或无法实现；代表有 403, 404
• 5xx ： 服务器错误；代表有 500

8.2.4 cookie、token 和 session

1. cookie：客户端向服务器发送请求，服务器响应后，客户端进行部分数据（即cookie、缓存）的存储在本地，

    cookie 一般包含：名称、内容、域名、路径、为何发送、创建时间、到期时间。

    cookie 主要有两种cookie：

•   会话 cookie：只作用于当前会话，一旦会话结束，则 cookie 失效或消失
•   持久（本地化） cookie：将 cookie 存储在本地硬盘，同样有对应的生命周期；

2. session：

服务器对客户端的标识。

存储在服务器端，

用户操作完对应的网站后会被销毁，此时 session 会将用户访问的相关信息临时存储在服务器上。

3. token

    目前 web、APP 进行认证的最佳方式。完成 token 身份认证有如下特征：无状态、扩展性高、支持移动平台、跨程序应用、安全等。

    基于 token 认证的过程：

• 用户通过用户名、密码发送请求
• 程序验证
• 程序返回一个签名的 token 给客户端
• 客户端存储 token，并且用于每次发送请求
• 服务端验证 token，并返回数据

具体实现授权的方式有： cookie、session、token 等

cookie v.s. session

• 1）cookie 客户端存储；session 服务器存储
• 2）cookie 只支持字符串存储（如有其他类型，会先转成字符串）；session 可存储任意数据类型
• 3）cookie 可设置长时间保存（如网页几天内不用登录）；session 一般客户端关闭或 session 超时就失效
• 4）cookie 保存的数据容量有限，最大不超过 4K；session 存储数据容量大于 cookie，但一般不会存储过多，否则影响服务器资源

token v.s. session

• 1）session 是有状态化的，会记录并存储会话信息；token 无状态化，不会存储会话信息
• 2）session 依赖 链路层 提高通信安全；token 通过身份认证方式，对请求进行签名从而防止监听或重放攻击等
• 3）session 的认证是通过 sessionID 完成存储，只是相对安全，只要存在 sessionID，就可以获得用户全部权限；token 不同机制认证方式不同，如果是 oAuth token 或类似机制，提供的是 认证和授权两种形式，认证对用户，授权对应用程序，此时 token 是唯一的，不能转移到其他用户或程序

如果系统的用户信息需要与第三方共享，甚至允许第三方调用其 API 接口，就需要考虑 token 方式