《API Testing and Development with Postman》最新第二版封面
文章目录
- 第十五章 API 接口性能测试
- 1 性能负载的类型
- 2 Postman 负载配置
- 3 Postman 性能测试实战
- 3.1 Fixed 型负载下的性能测试
- 3.2 基于数据驱动的 Postman 接口性能测试
- 4 性能测试的注意事项
写在前面
终于来到了本书最后一章 API 性能测试的学习。这一章也是第二版的新增内容，虽然不能算作最后的彩蛋级福利（毕竟性能测试不是 Postman 的专长），但通过几个简单的设置也能在 Postman 进行最基础的性能测试，还是让我非常惊喜的。平时这些功能几乎都没用过，实际操作一遍发现并没有什么难度，既可以作为拓展知识阅读，也可视为今后工作中性能测试的应急方案。
至此，整本书的要点笔记就全部梳理完了，虽然前面还有三章内容没梳理，但都是一些概念性的知识，没有多少提炼的价值，后续可能会放到同一篇博文中一并介绍。相信有了书中介绍的接口测试知识，大家的 Postman 应该称得上熟练甚至小范围精通了。但这只是一个开端，我学 Postman 也是为后面的 AI 学习打下坚实的基础；后续有 Postman 相关的最新动态我也会陆续更新到本专栏，欢迎大家多提意见，共同进步。感谢关注！
第十五章 API 接口性能测试
本章要点
- 性能负载的不同类型
- 负载配置文件在
Postman中的用法- 性能测试在
Postman中的运行方法- 性能测试注意事项
API 接口通过编程进行交互，从而促成了自动化访问，同时也意味着出现性能问题。本章将基于 Postman 简要介绍接口性能测试。
1 性能负载的类型
性能测试的复杂之处在于，需要全面综合考虑可能导致系统变慢的各种因素。
性能负载主要可分三类：
- 处理负荷（Processing Load）：是指处理单元的负荷，可能发生在计算资源开销极为昂贵的任务中；
- 内存负载（Memory Load）：涉及临时内存（RAM）或存储设备的高内存使用率；
- 连接负载（Connection Load）：涉及服务器可处理的最大同时连接数等。
2 Postman 负载配置
Postman 实现性能测试，主要是通过 Collection Runner 中的 Performance 配置页实现的：
【图 15.1 Postman 实现基本性能测试的配置页面及负载配置选项截图】
目前共支持四类负载配置类型：
| 类型 | 特点 | 适用场景 |
|---|---|---|
| Fixed（固定负载） | 模拟恒定不变的负载，用户数量或请求速率在整个测试期间保持不变 | 适用于评估系统在稳定负载下的表现 |
| Ramp up（逐步增加负载） | 负载从低到高逐步增加，模拟用户或请求逐渐增多的场景 | 适用于测试系统在负载逐步增加时的响应和稳定性 |
| Spike（突发负载） | 短时间内负载急剧增加，模拟突发的高流量场景 | 适用于测试系统在突发高负载下的表现和恢复能力 |
| Peak（峰值负载） | 负载在短时间内达到峰值，模拟系统在高峰期的表现 | 适用于评估系统在最大负载下的性能和稳定性 |
切换每个类型，下方都会显示该类型的可视化配置图，表征虚拟用户数（Virtual Users，即 VUs）随时间的变化趋势：
【图 15.2 Fixed 型负载配置示意图】
【图 15.3 Ramp up 型负载配置示意图】
【图 15.4 Spike 型负载配置示意图】
【图 15.5 Peak 型负载配置示意图】
由于在 Postman 的 Collection Runner 进行性能测试，只能模拟最多 100 个虚拟用户节点发起请求，不仅测试规模有限，性能参数的监控也不够全面，仅供了解即可。
3 Postman 性能测试实战
总思路：以 GitPod 在线演示项目 ToDo List App 为基础，利用 Collection Runner 进行基础的性能测试。
3.1 Fixed 型负载下的性能测试
新建测试集合 Performance Testing，并添加示例请求 Get task list，请求接口 GET {{url}}/tasks。
模拟 10 个虚拟用户节点、1 分钟内的性能测试：
【图 15.6 Fixed 型负载下模拟 10 个虚拟用户 1 分钟内的性能测试配置页截图】
运行结果如下：
【图 15.7 性能测试进行中的实时监控情况截图】
【图 15.8 性能测试完成后的结果展示页截图】
从测试集合的运行统计表中还可以看到更多性能指标：
【图 15.9 从测试集合的运行统计栏中还可以看到更多性能指标数据】
其余负载类型均可如法炮制。
3.2 基于数据驱动的 Postman 接口性能测试
本例演示上传 CSV 数据文件进行 Fixed 型负载性能测试，目标接口为 ToDo List App 项目的 PUT /tasks/1 修改接口。
首先从浏览器登录 user1（user1/12345），并手动添加一则待办事项：
【图 15.10 先从页面登录 user1，并新增一则待办事项】
然后创建一个控制 status 状态的 CSV 文件 status.csv，内容如下（可用 Excel 另存为 csv 格式）：
Status
Draft
In Progress
Complete
同时设置 PUT 请求的请求体为，注意变量名 Status 要与 CSV 文件的字段列名称保持一致：
{"description": "Do Something Great","status": "{{Status}}"
}
上传该 CSV 文件，此时会立即弹出一个临时窗口，选择随机插值后确认：
【图 15.11 上传 CSV 数据文件时，在自动弹出的窗口中设置插值方式为随机插值】
最后检查其他配置，再次运行 Collection Runner：
【图 15.12 再次确认性能测试各项配置】
运行结果如下：
【图 15.13 基于数据驱动的性能测试实时运行界面截图】
【图 15.14 基于数据驱动的性能测试实时 GitPod 后端运行界面截图】
【图 15.15 基于数据驱动的性能测试运行结束后的界面截图】
此外，还可以在某个运行详情页与其他性能测试记录进行对比，并结合统计图中的选筛条件，实现更多性能指标的综合对比：
【图 15.16 不同性能测试的运行指标对比效果图】
4 性能测试的注意事项
何时进行：尽量在开发周期的早期阶段进行。
性能测试中各个基准指标的确定：
- 单一负载：尽量设计得简单可靠；
- 复杂负载：除了考察可以接受的响应速度边界，还应考虑时间随负载的变化趋势。
可重复性的考虑：
性能测试对可重复性的要求相对较低，但这并不意味着可重复性不重要，而是要在有限条件下尽可能确保可重复性：
- 尽可能确保 测试环境的标准化：相同的底层硬件、相同数量的内核环境、内存配置、相同的
Docker容器配置等等，尽可能降低性能测试的噪音； - 认真考虑 初始数据 对性能测试的影响，尽量保持一致；
- 一致的性能测试数据清理流程；
- 建议不要总是自动删除数据，而是根据实际情况决定是否有必要保留（既有数据也可能会有助于后续调试）；
- 系统的冷启动问题：初始阶段可能性能尚不稳定；
- 推荐制定一套明确的操作步骤文档；
- 各性能指标的确认需要多方参与，综合考虑，避免纸上谈兵，闭门造车。
