欢迎大家来到IT世界,在知识的湖畔探索吧!
上一集中,通过postman已经对基本的get请求和application/x-www-form-urlencoded格式的接口进行了请求,不过整个操作更像是在抄写两个请求的内容,以后扩展到更多的接口进行请求的话,我们首先就得清楚接口HTTP协议报文的前世今生,透彻理解请求时应该注意的各个环节。
HTTP协议报文
之前说到,当我们完成一个请求的时候,相当于向服务器发送了一个快递,同时也希望得到服务器的回赠,为了更好地得到自己想要的结果,我们必须了解清楚HTTP协议报文的格式,也就是快递打包的基本规则。
1报文基本格式
对于一个报文来说,好比一个快递包裹,其主要构成部分分成三个部分:
- 报文起始行(start line):描述请求或响应报文的基本信息。(相当于物流信息)
- 报文头(headers ):涵盖HTTP报文相关的内容信息(相当于快递单)。
- 报文实体(entity):实际传输的数据(相当于快递包裹)。
而报文又分为从客户端发往服务端的请求报文(request)和从服务端发往客户端的响应报文(response)。
2请求报文Request
欢迎大家来到IT世界,在知识的湖畔探索吧!
如上图所示,请求报文是客户端发送给服务端的报文,主体分成3大部分以及请求头与请求体之间的空行:
请求行:其中包含HTTP请求方法,URL与HTTP协议版本(物流信息)。
请求头:与请求报文相关的内容信息(寄件快递单)。
请求体:请求报文实际传输的数据(寄件包裹内容)。
其中请求行中的HTTP方法与URL是需要深入理解的信息:
2.1HTTP请求方法
HTTP协议规范中规定了如下几种HTTP方法,分别代表不同的语义,进行接口测试时,大多数情况下只需要获取请求方法的类型进行填写即可。
|
GET |
请求指定的页面信息,并返回实体主体。 |
|
HEAD |
类似于 GET 请求,只不过返回的响应中没有具体的内容,用于获取报头。 |
|
POST |
向指定资源提交数据进行处理请求(例如提交表单或者上传文件)。数据被包含在请求体中。POST 请求可能会导致新的资源的建立和/或已有资源的修改。 |
|
PUT |
从客户端向服务器传送的数据取代指定的文档的内容。 |
|
DELETE |
请求服务器删除指定的资源。 |
|
CONNECT |
HTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器。 |
|
OPTIONS |
返回服务器针对特定资源所支持的HTTP请求方法,也可以利用向web服务器发送‘*’的请求来测试服务器的功能性,允许客户端查看服务器的性能。 |
|
TRACE |
回显服务器收到的请求,主要用于测试或诊断。 |
|
PATCH |
是对 PUT 方法的补充,用来对已知资源进行局部更新 。 |
2.2 URL(统一资源定位符)
要发送请求,则必须要知道服务端请求的资源地址,也就是知道服务端的收件人信息,URL就是请求资源的定位标识,能够唯一地找到一个接口或者其它互联网资源。
一个URL地址由如下几个部分构成:
- 协议名称:标识本次请求所使用的协议,在HTTP协议中,即为HTTP或HTTPS。
- 主机地址(有时包括端口)
- 资源路径:指定资源在主机上的存放位置
- 参数:从?开始,以键=值&键=值得格式呈现的提交参数内容
2.3请求头
请求头中包含许多与HTTP请求报文相关的信息,大部分的头信息是在请求和响应报文中通用的,比较常见的请求头信息及含义如下:
|
头部字段名 |
说明 |
|
Host |
指定访问服务的主机信息 |
|
User-Agent |
HTTP客户端程序的信息(客户端浏览器类型版本等) |
|
Accept |
用户代理可处理的媒体类型(指定客户端可接收的服务端返回格式) |
|
Referer |
对请求中URI的原始获取方(请求的来源地址) |
|
Accept-Encoding |
优先的编码集 |
|
Cache-Control |
控制缓存的行为类型 |
|
Content-Type |
实体主体的格式类型(例如application/x-www-form-urlencoded、application/json等) |
|
Content-Length |
实体主体的大小(单位:字节) |
|
Cookie |
在请求过程中携带发往服务器的Cookie字段 |
大部分的请求头在测试过程中不需要额外关注,请求发包工具比如Postman是可以自动处理添加相关头域的,只有在测试post、put等携带请求体的头域时,需要特别关注Content-Type头域字段,使用匹配对应类型的格式来编辑请求体。
2.4请求体
请求体是客户端工具发起请求时,实际发送的数据,也就是寄送的包裹,根据实际需求填写即可,不过要特别注意请求体的格式需要和请求头中的Content-Type相匹配,匹配格式如下:
- application/x-www-form-urlencoded:以url编码格式即 键=值&键=值格式填写的请求体。
- application/json:以json格式即{“键”:值,”键”:值}格式填写的请求体。
- text/xml:以xml格式即<元素 属性=”属性值”>内容</元素>格式体现的请求体。
- multipart/form-data:通常用于包含文件类型以及纯文本类型等混合类型的请求体。
3响应(返回)报文Response
如上图所示,响应报文(又称返回报文),是由服务端发送给客户端的HTTP报文,其主体分成3大部分以及响应头与响应体之间的空行:
响应行:又称为状态行,其中包含HTTP协议版本,状态码及其状态描述。(物流信息状态)
响应头:与响应报文相关的内容信息(回件快递单)。
响应体:响应报文实际传输的数据(回件包裹内容)。
3.1HTTP状态码
响应行中的状态码及其状态描述表示了本次请求的结果,类似于物流信息成功或者物流出现了问题。常见状态码如下:
1XX:信息状态码
|
状态码 |
含义 |
描述 |
|
100 |
继续 |
初始的请求已经接受,请客户端继续发送剩余部分 |
|
101 |
切换协议 |
请求这要求服务器切换协议,服务器已确定切换 |
2XX:成功状态码
|
状态码 |
含义 |
描述 |
|
200 |
成功 |
服务器已成功处理了请求 |
|
201 |
已创建 |
请求成功并且服务器创建了新的资源 |
|
202 |
已接受 |
服务器已接受请求,但尚未处理 |
3XX:重定向状态码
|
状态码 |
含义 |
描述 |
|
300 |
多种选择 |
针对请求,服务器可执行多种操作 |
|
301 |
永久移动 |
请求的页面已永久跳转到新的url |
|
302 |
临时移动 |
服务器目前从不同位置的网页响应请求,但请求仍继续使用原有位置来进行以后的请求 |
|
307 |
临时重定向 |
服务器目前从不同位置的网页响应请求,但请求者应继续使用原有位置来进行以后的请求 |
4XX:客户端错误状态码
|
状态码 |
含义 |
描述 |
|
400 |
错误请求 |
服务器不理解请求的语法 |
|
401 |
未授权 |
请求要求用户的身份演验证 |
|
403 |
禁止 |
服务器拒绝请求 |
|
404 |
未找到 |
服务器找不到请求的页面,(地址填错,或者文件不存在了) |
|
405 |
方法禁用 |
禁用请求中指定的方法 |
|
406 |
不接受 |
无法使用请求的内容特性响应请求的页面 |
5XX:服务端错误状态码
|
状态码 |
含义 |
描述 |
|
500 |
服务器错误 |
服务器内部错误,无法完成请求(后台报错) |
|
501 |
尚未实施 |
服务器不具备完成请求的功能 |
|
502 |
错误网关 |
服务器作为网关或代理出现错误(下游服务宕机) |
|
503 |
服务不可用 |
服务器目前无法使用 |
|
504 |
网关超时 |
网关或代理服务器,未及时获取请求 |
3.2响应头
响应头中包含与HTTP请求报文相关的信息,类比于收到快递的快递单,大部分的头信息是在请求和响应报文中通用的,比较常见的响应头信息及含义如下:
|
头部字段名 |
说明 |
|
Date |
创建报文的日期时间 |
|
Connection |
连接的管理,常见为keep-alive保持长连接 |
|
Cache-Control |
控制缓存的行为类型 |
|
Expires |
缓存内容的过期时间 |
|
Server |
HTTP服务器的安装信息 |
|
Last-Modified |
资源的最后修改日期时间 |
|
Content-Type |
实体主体的格式类型(例如application/x-www-form-urlencoded、application/json等) |
|
Content-Length |
实体主体的大小(单位:字节) |
|
Set-Cookie |
服务端返回的cookie字段 |
通常响应头中的内容不需做特别关注,就像收到快递之后,不回去查看快递单的内容一样。
3.3响应体
响应体是服务端发送回客户端的实际数据,就像收到的快递物品才是我们最关心的东西,它也是接口测试验证时的重点。
总结:
- HTTP协议报文就像快递,包括报文行(物流信息)、报文头(快递单)、报文实体(快递内容)
- HTTP协议报文分为请求报文和响应(返回)报文
- HTTP协议报文中需要重点关注的包括:
- 请求报文中的HTTP方法、URL地址、请求头和请求体
- 返回报文中重点关注返回体,留意返回状态码即可。
了解完HTTP协议报文,大家也就打好了进行接口测试的理论基础,不论使用Postman/Jmeter或者自由编程实现接口测试都会更加得心应手,足以触类旁通举一反三。之后的内容中,我们继续学习Postman完成测试的进阶用法。
最后,关于软件测试学习,offer选择等等,都可以通过后台私信交流。需要学习资料或者帮忙修改简历也可以私信!!也可百度搜索“特斯汀软件测试腾讯课堂”或关注公众号“特斯汀软件测试”,里面涵盖很多精彩免费视频或干货知识
免责声明:本站所有文章内容,图片,视频等均是来源于用户投稿和互联网及文摘转载整编而成,不代表本站观点,不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益,请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权,请联系删除,如若转载,请注明出处:https://itzsg.com/97349.html