如何使用Postman进行接口测试和接口测试用例设计思路

如果你是大一学生，我会这样跟你讲：API 接口，就是前端向后端“要数据或让它干活”的固定方式上课的时候开发过html网页吧，但是老师只讲过这个网页的前端css设计，就是样式啊，里面的超链接，标题之类的。你用 Tomcat 这类服务器在本地运行这个网站时，会用到 localhost:8080 这样的地址 —— 但这只是本地服务器的 “门牌号”，不是接口。如果想让网页显示天气数据，你需要在这个地址后加个具体的 “功能入口”，比如 localhost:8080/getWeather，这个带功能的地址才是真正的 API 接口，只不过你当时没给它对接数据，所以网页只有空壳样式。

如果你是大二大三学生，已经参与开发过一些小项目，不论是课程，比赛还是实习实训，你大概率一定听说过一个词：前后端分离架构。那么这个前端就是我们大一时候所接触过的网页，他也可以是微信小程序，手机应用，你可以看到的这个元素设计显示，大部分都是属于前端；那么后端就是我们具体处理数据的地方，从数据输入，上传，存储，处理，传递回去，这些对具体数据的处理，命令功能的实现，就是后端干的活。每当有一个需要传来，前端就向后端定义具体的接口请求命令和传递数据，这些接口所需要进行的操作和处理数据的业务逻辑都是已经定义好的，后端处理之后传递数据和消息回这个接口（当然数据库里面的内容也会随之改变），这个消息也是我们后面讲的code码和message，前端接受数据并显示。

我感觉可能讲的还是可能没法听懂，我找ai总结了一下，可以这样理解：

API 接口是前端和后端之间约定好的通信规则。
前端不直接操作数据库，也不关心数据怎么处理，只需要按接口规则发请求；
后端收到请求后，完成业务逻辑处理，并把结果通过接口返回给前端。
接口的本质不是页面，而是“数据和功能的入口”

2.为什么要进行接口测试

前面已经讲了，前端发送数据，后端处理返回处理后的结果；或者前端发送请求，后端返回请求的内容数据。接口测试，就是要验证后端是否按照要求正确处理和返回了数据。

在我们进行小项目的开发时，只有一俩个网站，可能觉得这个并不重要，因为本来要处理的数据就不多，后端写一个console.log或者前端直接就显示了，有错直接就改。

但是当我们开发稍微大一点的项目，有很多个模块，前端后端都是分开做的，这时候可不能要是求前端处理数据的时候说，你console.log一下看一下数据处理对不对，返回数据啥样式的，然后写前端代码吧，前端和后端的工作几乎是完全分离的。前端开发看的就是后端输出的这个接口文档，定义了具体传入数据的格式和返回数据的格式，还有不同的请求方式，那么这个时候，对接口功能的验证就非常重要，接口测试就是干这个用的。

二、Postman的安装和基础使用

1.Postman安装

随便找的一个安装教程，很多入门的很友好的安装教程，参考别人的吧这个我不赘述了https://blog.csdn.net/2302_77758423/article/details/140495062?ops_request_misc=elastic_search_misc&request_id=2a069d65d8ad912d960d897811dd85c3&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~top_positive~default-1-140495062-null-null.142^v102^pc_search_result_base3&utm_term=postman%E5%AE%89%E8%A3%85&spm=1018.2226.3001.4187

2.如何使用

开门见山，不介绍具体元素，直接实例演示，你可以先从2.1体验一下，然后体会到了就直接开始2.3的实际测试。然后下面是我们postman的初始页面

2.1 一个普通网站的获取数据(get)

第一步只是让你进行体验，尝试成功一次，所以很简单只是请求而已。

输入网址：https://randomuser.me/api/，选择方法get，点击发送
查看下面的返回信息，这是一个返回随机用户信息的网址，如果有内容的话，恭喜你的第一次Postman访问接口成功！
你还可以get其他网址，https://baidu.com 啊之类的你想get的网址都可以尝试

2.2 自己后端springboot启用的端口（get,post)

当我们自己在进行后端开发的时候，有时候一次定义了多个接口，并且我们想在开发前端之前就验证他的功能正确，那么这种情况我推荐先建一个collection对你的接口进行保存，然后具体请求这里只讲俩种get和post

感觉讲的很罗嗦啊，不好意思我们直接上示例吧，get请求就是，在params中填入请求参数

post请求，一般最多使用的是formdata表单格式，和json格式，对应请求头方式
Content-Type：application/x-www-form-urlencoded 或 multipart/form-data
Content-Type：application/json

2.3 进行一个网站的多模块的http接口测试

在对一个网站进行接口测试的使用，从接口文档的描述进行接口请求的创建，唯一可能遇到的新内容就是可能需要用到环境变量，还有cookie了，cookie我现在也不是特别明白

2.3.1环境变量说明

2.3.2接口文档和对应接口示例

2.3.3非常重要的，记得保存！还有如何导入导出

衍生：可以建立团队或者邀请别人进入团队一起使用同一个workplace进行编辑，有时候Postman的访问网站超时或者失败可能是使用了vpn，记得关掉就可以访问了。

三、设计接口测试用例的思路和注意事项

1.接口测试用例表头

用例编号/模块/接口名称/优先级/标题/URL/前置条件/请求方式/请求头/请求参数/预期结果/响应预期结/实际结果/是否存在接口依赖/依赖接口1/依赖字段/执行人/执行结果/备注

2.接口测试用例设计

考虑因素：必填字段/格式/缺少token/越权
正向：
必填字段全填入/必填非必填都填入（格式全正确）,对应权限正常访问
逆向：
1. 必填和格式：任意必填字段缺失，任意必填字段格式错误，非必填格式错误（对于必填字段的校验一定要严格，一个都不能允许错误）
2. 业务逻辑（格式正确但是逻辑错误）：唯一性校验（用户名唯一性，邮箱绑定唯一性），数字不可为负数，开始时间不可大于结束时间等，根据功能设计。
3. 权限：缺少token或者copkies，垂直越权（普通用户执行管理员的使用接口），水平越权（用户a可以查看用户b的数据）

四、接口测试中的预期结果：返回值code和message

一般来说常见使用的返回值code正常是200，重定向3xx，客户端请求参数异常的4xx，服务器错误的5xx，其中具体的4xx5xx的部分具体说明如下，如果想了解全部的Http返回值码说明可以去往上搜搜，这里只是部分。

错误码返回逻辑梳理：
400 Bad Request：
缺少必填字段：如果 API 设计中有必填字段，客户端没有提供这些字段，服务器返回 400。
参数格式错误：例如，字段的值类型错误（字符串传数字、日期格式不匹配等）。
无效的请求体：例如，客户端发送了空的 JSON 或不合法的 JSON 格式
404 Not Found：
表示伺服器找不到所請求的資源
409 conflict ：资源冲突（重复数据，唯一性校验，对已经有的资源做出操作）
典型的应用：如果你的应用对某些数据（如用户名、邮箱、ID 等）有唯一性要求，当客户端试图创建一个已经存在的资源时，返回 409 Conflict。
例如，如果你尝试注册一个已经存在的邮箱 user@example.com，服务器可以返回 409，表示该邮箱已经被占用，与当前的数据冲突。
422 Unprocessable Content ：（合法但是业务逻辑不给过）
字段格式正确，但业务规则不通过：例如，提交了一个合法的邮箱地址，但该邮箱已被注册。
业务逻辑校验失败：例如，创建一个新用户时，用户名已经存在，系统不能接受重复的唯一标识符。（有待商榷，更多建议使用特定的409）
提交的表单数据格式正确，但某些字段的值不符合服务器的期望：例如，日期字段不在允许的范围内，或者金额字段为负数
403 Forbidden ：即使提供了有效的 Token，但用户没有足够的权限访问某些资源
401 Unauthorized：未提供有效的 Token 或认证信息
405 Method Not Allowed：
表示客户端使用了错误的 HTTP 方法，通常是当客户端尝试对某个资源使用不支持的请求方法时，返回此状态码，比如有的资源不可以删除，然后对他使用了delete方法
5xx：服务器错误，通常是服务端未能正确处理有效请求的问题。
示例：数据库连接失败、依赖的外部服务宕机等

message对应的就是具体的消息，比如404时，资源未找到，409时可能是“用户名重复，请换一个”
具体我们工作的时候会遇到的情况可能如下：

{
"code": 403,
"msg": "对不起，您没有该接口访问权限，请联系管理员"
}

{
"requestId": "494968e26512990d52b700996d006674",
"code": 404,
"msg": "gRPC GetGroup failed: rpc error: code = Unknown desc = 分组不存在",
"status": "error",
"data": null
}

{
"requestId": "5071337b1e23abe1cb64347286724ad9",
"code": 200,
"msg": "创建成功",
"data": {
"id": 4,
"groupName": "大頭鸭新建分组",
"description": "希望创建成功",
"nodeCount": 0,
"groupType": "default",
"priority": 1,
"loadBalanceStrategy": "round_robin",
"maxConcurrentTasks": 100,
"isActive": true,
"createdAt": "2025-12-11T13:20:35.67365243+08:00",
"updatedAt": "2025-12-11T13:20:35.67365243+08:00"
}
}

当然我们只是测试，这些消息不是我们写的，但是作为我们的预期效果，得确保其具有一定的合格形式，如果发现返回值没有什么code和message，只是单纯返回success,fail这种，就是有很大问题，或者发现明明是请求格式错误或者数据不符合，客户端的问题，应该返回值4xx，但是返回了500，这就是明显的问题需要反馈修改。当然具体还是要沟通，有些可能不用有些需要。