Postman接口测试入门教程：请求发送与响应解读实战指南

为什么选择Postman作为接口测试入门工具

Postman作为接口测试领域的经典工具，尽管存在不少槽点——不支持中文、必须注册登录才能使用全部功能、官网在国外访问困难——但它依然是入门接口测试的最佳选择之一。它的UI简洁优雅，功能完备，甚至成为众多国产接口测试工具的"参考对象"。更重要的是，掌握Postman的使用逻辑，能为后续学习自动化测试打下坚实基础。

本文将系统梳理Postman的核心界面布局、请求发送机制以及响应解读方法，帮助零基础用户快速建立接口测试的完整认知框架。

Postman的优劣势分析

不可忽视的劣势

• 不支持中文界面，对英语基础薄弱的用户不太友好
• 必须注册登录才能解锁全部功能，而官网在国外，网络通信不稳定
• 持续集成能力不成熟，提供的CLI工具（Newman）在实际项目中表现一般

Newman是Postman官方提供的命令行运行工具，允许将Postman集合（Collection）导出为JSON文件后在CI/CD流水线中执行，理论上可以集成到Jenkins、GitHub Actions、GitLab CI等平台。然而在实际项目中，Newman的局限性较为明显：测试报告格式单一、动态参数处理能力弱、与代码仓库的版本管理集成不够优雅。这也是为什么成熟的自动化测试团队更倾向于使用pytest+requests或RestAssured等代码化框架——它们天然融入开发工作流，可维护性更强。

不过这些劣势不必过于担心。Postman更多是一个学习和入门的跳板，当你的测试能力成长到一定阶段，自然会过渡到更专业的工具和框架。

值得肯定的优势

• UI简洁好看，操作直观，不像JMeter那样让新手无从下手
• 功能完善，对接口功能测试而言完全够用
• 支持导出多语言自动化代码，包括Python、Java、C#、PHP等，方便后续迁移到自动化测试

发送请求：接口测试的起点与重点

发送请求是使用Postman最核心的操作，也是整个接口测试中占比约70%的工作量。理解了如何构造和发送请求，后面的一切都会顺理成章。

在深入操作之前，有必要了解一点背景知识：现代接口测试的主要对象是基于HTTP协议的RESTful API。REST（Representational State Transfer）是一种架构风格，由Roy Fielding在2000年的博士论文中提出，它将网络资源抽象为URI（统一资源标识符），并通过HTTP方法对资源进行操作。理解这一背景，有助于理解为什么GET对应"获取"、POST对应"创建"、PUT对应"更新"、DELETE对应"删除"——这套语义化约定正是RESTful设计的核心思想，也是Postman界面设计的底层逻辑。

Postman的界面可以清晰地分为上下两部分：上半部分是请求区域（红色区域），下半部分是响应区域（绿色区域）。我们的绝大部分工作都集中在上半部分——构造并发送请求；下半部分则是接口返回的结果，属于"听天由命"的部分。

必填项：每个请求都不可缺少的要素

1. 请求方法（Method）

请求方法是HTTP协议的语义化表达，用一个单词说明这个请求要做什么。常见的HTTP请求方法包括：

• GET：获取资源、下载数据
• POST：提交数据、上传文件
• DELETE：删除资源
• PUT：更新资源

说个细节，Postman不仅支持预设的方法，还允许你输入自定义方法名。这说明HTTP方法的数量理论上是无限的，甚至可以自己创造。但在实际的接口测试工作中，掌握常用的几种就足够了。

2. 请求地址（URL）

即接口的访问地址，是必填项。如果不填，点击Send按钮时会直接报错提示"不能为空"。URL决定了你的请求参数发往哪里，不同的接口自然有不同的地址。

当方法和URL都填写完毕后，就可以点击Send按钮发送请求了。即使返回的是405等错误状态码，也说明请求已经成功发出。

选填项：根据接口文档按需配置

1. 查询参数（Params）

附加在URL中的参数，以?key=value的形式拼接在地址后面。例如输入Name=北凡，URL会自动变成http://example.com?Name=北凡。这种参数传递方式直观且常用，常见于GET请求的过滤、分页、搜索等场景。

2. 鉴权配置（Authorization）

大多数接口不会允许任何人随意访问，需要验证用户身份。Postman提供了多种鉴权方式的下拉选择，包括：

• Basic Auth：账号密码认证，将凭据Base64编码后放入请求头，是最简单的HTTP认证方式
• Bearer Token：令牌认证，客户端持有服务端颁发的令牌，每次请求时携带以证明身份
• JWT（JSON Web Token）：目前最流行的无状态认证方案之一，由Header、Payload、Signature三部分组成，用Base64编码后以点号分隔拼接。Header声明算法类型，Payload携带用户信息和过期时间，Signature用密钥对前两部分签名以防篡改。与传统Session不同，JWT无需服务端存储状态，天然适合分布式系统和微服务架构
• API Key：密钥认证，通常由平台颁发固定密钥，适合服务间调用场景

需要注意的是，并非所有接口都需要鉴权。比如登录接口本身就不需要——你总不能要求用户在登录之前就证明自己是谁。

3. 请求头（Headers）

用来附加修饰性信息，比如User-Agent标识请求来源，Accept-Encoding说明是否支持压缩，Connection指定是否保持持久连接等。请求头在接口测试中起到的是辅助和修饰作用。

4. 请求体（Body）

这是传递正式参数的地方，也是请求中最重要的内容载体。Postman的Body支持多种格式，理解它们背后的Content-Type声明有助于避免常见错误：

• form-data：对应multipart/form-data，支持文件上传的多部分格式
• x-www-form-urlencoded：对应application/x-www-form-urlencoded，传统HTML表单的默认格式，以键值对编码传输
• raw JSON：对应application/json，现代API的主流格式，结构清晰、易于解析

Content-Type是HTTP请求头中的MIME类型声明，告知服务器如何解析请求体。Postman在切换Body格式时会自动同步Content-Type，正是因为服务端依赖这个字段来选择解析器——格式与声明不匹配会直接导致422或400错误。这也正体现了"头"与"体"的紧密关联。

5. 脚本（Scripts）

Postman支持JavaScript脚本，分为两个执行时机：

• Pre-request（请求前）：配置请求、加载数据、数据加密等准备工作
• Post-response（响应后）：提取变量、断言验证等

这也是面试中常被问到的问题——"你用Postman如何进行断言？"答案就是通过Post-response脚本编写断言代码。

6. 设置（Settings）

包括HTTP版本号、SSL证书校验、重定向跟随等配置，绝大部分情况下保持默认即可。

解读响应：看懂接口返回的每一条信息

请求发出后，我们需要能够看懂响应内容，这是手动接口测试的基本功。

HTTP状态码：一眼判断请求结果

状态码是响应中最先应该关注的信息，通过数字语义化地表示响应结果。HTTP状态码遵循RFC 7231规范，按首位数字分为5个大类：1xx表示信息性响应，2xx表示成功，3xx表示重定向，4xx表示客户端错误，5xx表示服务器错误。这套分类体系的设计哲学是"责任归属