html5开发wap网站陶艺品网站模板

当前位置： 首页 > news >正文

html5开发wap网站,陶艺品网站模板,淡蓝黑色大气企业网站模板,网站分站系《API Testing and Development with Postman》最新第二版封面 文章目录 第十五章 API 接口性能测试1 性能负载的类型2 Postman 负载配置3 Postman 性能测试实战3.1 Fixed 型负载下的性能测试3.2 基于数据驱动的 Postman 接口性能测试 4 性能测试的注意事项 写在前面 终于来到了… 《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 修改接口。 首先从浏览器登录 user1user1/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 容器配置等等尽可能降低性能测试的噪音认真考虑 初始数据 对性能测试的影响尽量保持一致一致的性能测试数据清理流程建议不要总是自动删除数据而是根据实际情况决定是否有必要保留既有数据也可能会有助于后续调试系统的冷启动问题初始阶段可能性能尚不稳定推荐制定一套明确的操作步骤文档各性能指标的确认需要多方参与综合考虑避免纸上谈兵闭门造车。