软件测试 —— Postman（2）

GET
- - URL结构
  - - 协议与主机名
    - 路径
    - 查询字符串（Query String）
  - 总结
urlcode和urldecode
Params 参数
Authorization
- - 基本结构
  - 常见的认证方案
  - - 1. Basic 认证
    - 2. Bearer Token (OAuth 2.0)
    - 3. API 密钥
    - 4. 其他认证方案
  - 使用场景
  - 示例 - 在Postman中添加Authorization头
Headers 请求头
- - 1. 通用头 (General Headers)
  - 2. 请求头 (Request Headers)
  - 示例 - 在Postman中添加Headers
Body 请求体
- - 请求体 (Request Body)
  - - 1. **application/json**
    - 2. **application/x-www-form-urlencoded**
    - 3. **multipart/form-data**
    - 4. **text/xml 或 application/xml**
    - 5. **raw**
  - 响应体 (Response Body)
  - 在Postman中设置请求体

我们之前已经把postman下好，并且简单的使用了一下postman的功能，我们接下来就要对postman的一些其他功能进行探索，如果没看过上一篇的可以点击这里：

https://blog.csdn.net/qq_67693066/article/details/145240384

GET

我们之前已经会简单的发送一个get请求获取信息了，接下来我想要测试一下这个百度的搜索功能是不是准确有用的：

我们来看看我们在百度搜索老番茄，上面的url是什么样的：
在这里插入图片描述
然后把这个url复制到我们的postman里：

然后我们的postman自动会把参数给提取出来，我们看到在这个url请求中有这么多的参数，我们来分析一下：

这个URL是百度搜索引擎（Baidu）的一个搜索结果页面的链接，它包含了多个查询参数用于定制和跟踪用户的搜索行为。下面是对该URL及其各个部分的详细分析：

URL结构

https://www.baidu.com/s?ie=utf-8&f=8&rsv_bp=1&tn=baidu&wd=%E8%80%81%E7%95%AA%E8%8C%84&oq=%25E7%258E%258B%25E7%2580%259A%25E5%2593%25B2&rsv_pq=c1e86d7e000fef12&rsv_t=16d0woFpOK5YzfU54LMwvuDPncgZQZfOPBgPgh%2BTzN4qeL20hDD%2BA0kGlVE&rqlang=cn&rsv_enter=1&rsv_dl=tb&rsv_sug3=8&rsv_sug1=4&rsv_sug7=100&rsv_sug2=0&rsv_btype=t&inputT=2345&rsv_sug4=3250&rsv_sug=1

协议与主机名

https://：表示使用HTTPS协议，确保数据传输的安全性。
www.baidu.com：百度的主域名。

路径

/s：这是百度搜索服务的路径，意味着这是一个搜索结果页面。

查询字符串（Query String）

查询字符串由一系列键值对组成，每个键值对之间用&分隔，整个查询字符串以?开始。以下是具体参数解析：

ie=utf-8：指定输入编码为UTF-8，保证中文字符能够正确显示。
f=8：可能是某种内部标识符或功能标记，具体含义未知。
rsv_bp=1：可能是指是否启用了某些特殊功能或设置，例如浏览器兼容模式等。
tn=baidu：通常表示搜索模板名称，这里是标准的百度搜索。
wd=%E8%80%81%E7%95%AA%E8%8C%84：这是搜索关键词，经过URL编码后的“老番茄”。wd是“word”的缩写，代表用户输入的搜索词。
oq=%25E7%258E%258B%25E7%2580%259A%25E5%2593%25B2：上一次的搜索查询，同样经过了URL编码，解码后为“王瓜娃”，这可能是之前的搜索历史。
rsv_pq=c1e86d7e000fef12：一个随机生成的查询ID，用于唯一标识此次搜索请求。
rsv_t=16d0woFpOK5YzfU54LMwvuDPncgZQZfOPBgPgh%2BTzN4qeL20hDD%2BA0kGlVE：另一个随机生成的令牌，可能用于追踪或安全校验。
rqlang=cn：指明语言环境为中国大陆地区使用的简体中文。
rsv_enter=1：可能表示用户是如何进入搜索页面的，比如通过点击某个链接进入。
rsv_dl=tb：可能指代了来源类型，如从贴吧（Tieba）或者其他特定渠道来的流量。
rsv_sug3=8、rsv_sug1=4、rsv_sug7=100、rsv_sug2=0：这些参数看起来像是与搜索建议相关的统计信息或者配置项。
rsv_btype=t：可能是用来区分不同类型的搜索结果展示形式。
inputT=2345：输入时间，即用户花费了多少毫秒来完成这次搜索。
rsv_sug4=3250：更多关于搜索建议的信息，具体意义不明确。
rsv_sug=1：似乎也是与搜索建议有关的一个标志位。

总结

这个URL是一个典型的百度搜索结果页面链接，其中包含了大量用于优化用户体验、统计分析以及广告投放等方面的查询参数。虽然有些参数的具体作用并不公开透明，但它们共同构成了一个完整的搜索请求，帮助百度更好地理解用户的意图，并提供相关性强的结果。对于普通用户来说，最重要的部分是wd参数所对应的搜索关键词，即“老番茄”，其余参数主要用于内部处理和跟踪。

意思是说我们只要保证最重要的参数wd在，就可以完成一次搜索，我们可以把postman里面的请求改改：
在这里插入图片描述
postman返回了请求，我们也可以把这串url粘贴到我们的浏览器中：
这里使用了https来传输，其他的都是一模一样的。我们想测试一下返回的页面和postman返回的页面是不是一样的，我们可以看百度返回的页面和postman返回的页面是不是包含同样的元素，比如在百度页面的右侧，有一个“逆风笑”的词条：
在这里插入图片描述我们也可以在postman中搜索一下：
说明postman返回的页面应该是正确的，可能是返回了css样式表，导致返回的结果很长。

在这里插入图片描述

urlcode和urldecode

我们看一下wd的关键字那里：wd=%E8%80%81%E7%95%AA%E8%8C%84

我们在百度页面是可以看到汉字的，但是汉字是没有办法传输的，而且直接的明文传输也不安全，所以汉字等特殊字符在传输时要进行urlcode编码：

我们可以网上搜个工具，进行urlcode编码：

在这里插入图片描述那么有urlcode编码，也有urldcode解码：

Params 参数

我们接下来了解一些postman面板上的一些功能参数，首先我们看到Params：
在这里插入图片描述这个主要是在执行get时，查询操作的时候，后面带的一些参数，如果我们还要加的话我们还可以添加：
到时候执行get的时候，这些参数都会一并写到我们的url中。

Authorization

在这里插入图片描述

Authorization 是HTTP请求头中的一个关键字段，用于向服务器提供认证信息。它允许客户端证明自己的身份，从而访问受保护的资源或执行需要授权的操作。Authorization 头通常用于实现各种认证机制，如Basic认证、Bearer Token（OAuth 2.0）、API密钥等。

基本结构

在HTTP请求中，Authorization 头的一般格式如下：

Authorization: <认证方案> <认证参数>

认证方案：指定使用的认证类型，例如 Basic、Bearer 等。
认证参数：根据所选认证方案提供的具体凭证信息。

常见的认证方案

1. Basic 认证

这是最简单的认证方式之一，适用于HTTP协议。它将用户名和密码组合成一个字符串，然后使用Base64编码后作为认证参数发送给服务器。

格式：

 Authorization: Basic <base64-encoded(username:password)>

示例：
如果用户名是 user，密码是 pass，那么经过Base64编码后的值为 dXNlcjpwYXNz，因此请求头会是：
```
Authorization: Basic dXNlcjpwYXNz
```

注意事项：由于Basic认证仅对凭证进行了简单的编码而非加密，所以必须通过HTTPS来确保传输的安全性。

2. Bearer Token (OAuth 2.0)

Bearer Token是最常用的现代认证方式之一，尤其是在基于OAuth 2.0的系统中。客户端从授权服务器获取令牌，并在每个请求中包含该令牌以证明其身份。

格式：
```
Authorization: Bearer <access_token>
```

示例：

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

优点：相比于Basic认证，Bearer Token提供了更高的安全性，因为它可以包含额外的元数据（如过期时间），并且可以在每次请求时验证令牌的有效性和权限范围。

3. API 密钥

某些服务可能要求使用API密钥进行认证，这通常是通过在请求头中传递一个唯一的密钥字符串来完成的。

格式：
```
Authorization: ApiKey <your_api_key>
```

示例：

Authorization: ApiKey 12345abcde67890fghij

注意：API密钥应该保密处理，并且建议定期更新以增强安全性。

4. 其他认证方案

还有许多其他的认证方法，比如Hawk、AWS Signature Version 4等，它们各自有特定的应用场景和安全特性。

使用场景

保护敏感数据：当API涉及个人隐私或商业机密时，必须确保只有经过授权的用户才能访问。
限制资源访问：对于有限制的API端点，可以通过认证来控制谁能够调用以及他们能做什么操作。
追踪和审计：通过认证信息，可以记录下哪些用户在何时进行了哪些请求，便于后续分析和问题排查。

示例 - 在Postman中添加Authorization头

假设你正在使用Postman测试一个需要Bearer Token认证的API：

打开Postman并选择你要编辑的请求。
切换到“Headers”标签页。
添加一个新的键值对，其中键为 Authorization。
对于Bearer Token认证，值应设置为 Bearer <your_access_token>，例如：
```
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
```
发送请求，服务器将检查提供的令牌是否有效，并根据结果决定是否授予访问权限。

总之，Authorization 请求头是确保API安全性和可控性的关键工具，正确配置它可以大大提升系统的整体安全性。

Headers 请求头

在这里插入图片描述这里隐藏9个选项，我们可以打开看看：

HTTP headers（HTTP头）是HTTP请求和响应的一部分，用于在客户端和服务器之间传递元数据。这些头部信息提供了关于请求或响应的额外上下文，帮助双方更好地理解和处理传输的数据。HTTP头可以分为几类：通用头、请求头、响应头和实体头。下面是关于HTTP头的详细介绍：

1. 通用头 (General Headers)

这些头字段可以在任何类型的HTTP消息中出现，并且既适用于请求也适用于响应。

Cache-Control：指定缓存机制的行为规则，例如是否允许缓存、最大有效期等。
Connection：控制连接的状态，如keep-alive保持持久连接，close关闭连接。
Date：生成消息的时间戳。
Pragma：与缓存相关的指令，主要用于向后兼容HTTP/1.0。
Trailer：指示在消息体之后跟随哪些扩展头。
Transfer-Encoding：指定传输过程中使用的编码方式，如chunked。
Upgrade：建议使用更高级别的协议进行通信。
Via：记录消息经过的中间节点，常用于代理服务器。
Warning：提供有关可能影响消息内容的警告信息。

2. 请求头 (Request Headers)

请求头由客户端发送给服务器，包含有关请求来源、用户偏好、内容类型等信息。

Accept：告知服务器客户端可以接受的内容类型（如 text/html, application/json 等）。
Accept-Charset：表示客户端支持的字符集。
Accept-Encoding：列出客户端支持的内容编码方式（如 gzip, deflate 等），用于压缩传输内容。
Accept-Language：显示客户端首选的语言（如 en-US, zh-CN 等）。
Authorization：携带认证信息，例如使用Basic Auth或Bearer Token进行身份验证。
Cookie：包含之前由服务器设置的cookie，用以维持会话状态或其他持久化信息。
Content-Length：指示请求体中的字节数量。
Content-Type：当请求体中包含数据时，指明这些数据的MIME类型（如 application/x-www-form-urlencoded, multipart/form-data, application/json 等）。
Host：指定请求的目标主机名和端口号。
Referer：显示从哪个页面链接到当前请求资源，有助于分析流量来源。
User-Agent：描述发起请求的浏览器或其他客户端应用程序的信息。
Origin：用于CORS（跨域资源共享）检查，指明请求的来源域名。

示例 - 在Postman中添加Headers

假设你正在使用Postman测试一个API，并需要添加自定义的请求头：

打开Postman并选择你要编辑的请求。
切换到“Headers”标签页。
使用表格形式添加键值对，其中键为头部名称，值为对应的值。

在这里插入图片描述这里注意这里只是演示，get是没有Content-Type，只有post才有。

Body 请求体

在这里插入图片描述

HTTP 请求和响应中的 Body（主体）部分用于携带实际的数据内容。它通常出现在 POST、PUT、PATCH 和 DELETE 等方法中，因为这些方法可能需要向服务器发送数据以创建或更新资源。对于 GET 请求来说，通常不包含请求体，因为数据是通过 URL 的查询字符串传递的。

请求体 (Request Body)

请求体包含了客户端想要发送给服务器的数据。根据不同的应用场景，可以使用多种格式来表示这些数据。以下是几种常见的请求体格式及其用途：

1. application/json

JSON（JavaScript Object Notation）是一种轻量级的数据交换格式，易于阅读和编写，并且易于机器解析和生成。它是现代Web API中最常用的格式之一。

示例：

{
  "username": "john_doe",
  "email": "john@example.com",
  "password": "securepassword123"
}

2. application/x-www-form-urlencoded

这种格式主要用于HTML表单提交。数据被序列化为键值对，并且每个键值对之间用&分隔，键和值之间用=连接。所有字符都会经过URL编码。

示例：

username=john_doe&email=john%40example.com&password=securepassword123

3. multipart/form-data

当上传文件时，或者当表单中有文件输入字段时，应该使用multipart/form-data。它允许在一个请求中同时发送文本和二进制数据。

示例（简化版）：

--boundary
Content-Disposition: form-data; name="username"

john_doe
--boundary
Content-Disposition: form-data; name="avatar"; filename="profile.jpg"
Content-Type: image/jpeg

[binary data]
--boundary--

4. text/xml 或 application/xml

XML（可扩展标记语言）也是一种常用的数据交换格式，特别是在SOAP Web服务中。

示例：

<user>
  <username>john_doe</username>
  <email>john@example.com</email>
  <password>securepassword123</password>
</user>

5. raw

有时你可能需要直接发送原始文本或自定义格式的数据，这时可以选择“raw”选项并指定适当的MIME类型。

示例（假设发送的是纯文本）：
```
Hello World!
```

响应体 (Response Body)

响应体则是服务器返回给客户端的数据。它同样可以根据API的设计采用不同的格式，最常见的是JSON和XML。此外，对于下载文件等操作，响应体可能会包含二进制数据。

JSON 响应体示例：

{
  "id": 123,
  "username": "john_doe",
  "email": "john@example.com"
}

XML 响应体示例：

<user>
  <id>123</id>
  <username>john_doe</username>
  <email>john@example.com</email>
</user>

在Postman中设置请求体

假设你正在使用Postman测试一个API，并需要发送带有请求体的POST请求：

打开Postman并选择你要编辑的请求。
在请求构造器中选择合适的HTTP方法（例如POST）。
切换到“Body”标签页。
根据你的需求选择合适的数据格式（如raw + JSON, form-data, x-www-form-urlencoded等）。
输入或构建你要发送的数据。
发送请求，并查看服务器返回的响应体。

在这里插入图片描述