postman使用——在公司的项目落地回顾总结
背景
使用postman做接口自动化以及有差不多一年了，迭代更新了也差不多一年了，本篇文章主要介绍与总结：
- 为什么使用postman做自动化
- 如何使用postman做接口自动化
- 实际落地的方案实施
- postman优势与限制
为什么使用postman做接口自动化
有以下几个角度来考虑，这里面其实涉及到一个自动化产品选型。
公司层面：
去年的时候，公司的各个产品线是割裂开来，各个子产品都有各个子产品的产品线，测试团队，研发团队。因此一开始在自动化脚本选型阶段并没做到统一规划，导致了有的团队使用postman，有的团队使用python。
现实层面：
虽然有实际的问题，但从现实层面来说，去年公司公司降本提效，人员收缩，再投入一部人去直接开启自动化脚本的实施，其实也比较耗费人力，也会导致迭代需求的测试不充分，质量无法保障。考虑到现状后，也比较倾向于能够有快速收效的自动化实现
产品层面：
公司的子产品较多，各个子产品的测试方式以及架构还不太一样，有的倾向于用户，比较上层，有的则是比较底层，针对的是各数据源链路的测试，比如MySQL-MySQL、MySQL-Oracle等等，因此考虑到这一层，有的子产品是比较适合使用python来实现，有的用postman来实现。而我负责的产品刚好是比较倾向于上层，使用postman更加快速且省事
postman是一款相对很成熟的接口测试工具，应该是每个程序员或相关人员都有接触过，使用成本低。
一、易用性
界面友好
Postman 拥有直观、简洁的用户界面，无需复杂的配置即可快速上手。无论是新手还是有经验的测试人员，都能轻松地在 Postman 中进行操作。对于创建和管理接口请求，它提供了可视化的操作环境，例如通过简单的表单填写就能完成一个接口请求的参数配置，包括请求方法（GET、POST 等）、URL、请求头和请求体等。
脚本编写便捷
Postman 支持在请求中编写测试脚本。它使用 JavaScript 作为脚本语言，这是一种广泛使用且容易学习的编程语言。在 Pre - request Script（请求前脚本）和 Tests（测试脚本）标签页中，可以方便地编写代码来实现请求前的参数预处理和请求后的结果验证等操作。例如，可以在测试脚本中编写断言来验证接口返回的状态码是否为 200，或者验证返回数据中的某个字段是否符合预期。
二、功能丰富
请求类型全面支持
能够处理各种类型的 HTTP 请求，包括常见的 GET、POST、PUT、DELETE 等，还支持一些不太常见的请求方法，如 PATCH、OPTIONS 等。无论是简单的查询接口还是复杂的资源更新接口，Postman 都能很好地满足测试需求。对于 POST 请求，它可以方便地设置不同类型的请求体格式，如 JSON、表单数据、XML 等。
环境变量和全局变量管理
Postman 允许用户定义环境变量和全局变量。这对于处理不同环境（如开发环境、测试环境、生产环境）下的接口测试非常有用。通过设置变量，可以轻松地切换接口的基础 URL 等参数，而无需在每个请求中手动修改。例如，可以定义一个环境变量{{base_url}}，在不同的环境配置文件中设置不同的值，这样在请求的 URL 中只需要引用这个变量，就可以在不同环境下进行测试。
集合和文件夹管理
可以将相关的接口请求组织成集合（Collections），并在集合内使用文件夹进一步分类。这种组织方式有助于对大规模的接口进行有条理的管理。例如，可以将与用户管理相关的接口放在一个集合中的 “用户管理” 文件夹下，将与订单管理相关的接口放在另一个文件夹下，方便查找和执行相关的测试。
数据驱动测试
支持数据驱动的测试方法。可以通过导入 CSV 或 JSON 格式的数据文件，对接口进行批量测试。例如，有一个注册接口，需要测试不同的用户名和密码组合是否能成功注册，可以将这些用户名和密码数据整理到 CSV 文件中，然后在 Postman 中配置数据驱动测试，让 Postman 自动使用这些数据逐一执行注册接口的测试。
三、集成能力
与 CI/CD 工具集成
Postman 可以与常见的持续集成 / 持续部署（CI/CD）工具（如 Jenkins、Travis CI 等）集成。这使得可以将接口自动化测试纳入到软件开发的整个流程中，实现每次代码提交后自动执行接口测试，及时发现接口相关的问题。例如，在 Jenkins 中配置一个任务，当代码仓库有新的提交时，自动触发 Postman 的测试集合运行，并将测试结果反馈给开发团队。
与其他工具协作
能够与其他开发和测试工具进行协作。例如，可以将 Postman 中的接口测试用例导出为多种格式（如 Newman、HAR 等），以便在其他工具中使用。同时，也可以从 Swagger 等 API 文档工具中导入接口定义，快速生成接口测试用例，提高测试用例的创建效率。
综上，使用postman来进行公司产品的自动化测试落地。
如何使用postman做接口自动化
这部分内容网上有很多参考资料，这里不做详细介绍。
简而言之，使用postman做接口自动化的关键就是处理好前后的传参
可参考之前的文章：Postman接口测试实战
实际落地的方案实施
1.项目上的压力
2.运维的压力
3.人员的压力
可执行脚本供项目上使用，快速验收
在实现自动化的过程中，一般需要研发、运维、测试三方人员来实施整体的落地方案。
目的
- 减轻项目上验收压力（主要）
- 快速回归验收（次要）
这两项在自动化测试脚本未出来之前，占据了研发、运维、测试的很多时间，因此急需解决。
落地方案
-
编写脚本，做好核心代码与配置文件的分离，以为后边修改配置文件的参数就可在不同的环境下使用。如：
只要修改了配置文件的信息，就可以通过命令行直接执行 -
接入postman兼容的测试报告newman
-
在不同环境下，使用PyInstaller将执行引擎打包成可执行脚本，然后就可在不同的环境下使用，例如windows环境，Linux-arm、Linux-x86环境等环境使用，如下图：
当运维在项目上部署好服务之后，就可以直接拉脚本代码执行在不同的环境中执行，实现快速验收项目功能。
直接可使用以下命令进行执行：
windows示例
newman-win.exe -c TEST.postman_collection.json -e TEST.postman_environment.json
linux x86示例
chmod +x ./newman-linux && ./newman-linux -c TEST.postman_collection.json -e TEST.postman_environment.json
linux arm示例
chmod +x ./newman-linux-arm && ./newman-linux-arm -c TEST.postman_collection.json -e TEST.postman_environment.json
然后会自动生成一个测试报告，通过查看测试报告，就可以知道对应的接口信息了。
失败的话，也可以通过测试报告，查看报错的信息，快速定位解决问题。
以前项目没部署一次或升级一次都需要对应产品线的测试人员去进行验收，现在直接可以拉脚本使用，无门槛、傻瓜式验收，直接将效率提升80%，以前需要3人天，现在只需要半小时即可验收完4个子产品。
postman优势与限制
优势就不多言了，上面为什么选择postman原因之一就是postman本身的产品优势。这里可聊聊它的限制。
一、脚本编写的局限性
- 编程语言的限制
Postman 主要使用 JavaScript 进行脚本编写。虽然 JavaScript 是一种广泛应用的编程语言，但对于一些特定的测试场景，如果需要使用其他编程语言特有的功能或库，Postman 就无法满足。例如，若需要使用 Python 中的某些数据处理库，如我们在业务上需要使用到starrocks进行建表与关联，在 Postman 环境下是无法实现的。因此， 这里我们又使用python来进行操作，分成了两个脚本。 - 复杂逻辑处理能力相对较弱
当面对极其复杂的业务逻辑测试时，Postman 的脚本编写能力可能显得捉襟见肘。例如，在涉及多层嵌套循环、复杂的条件判断和大量数据运算的场景下，在 Postman 中编写和维护这样的测试脚本会变得非常困难。与专业的集成开发环境（IDE）相比，Postman 缺乏一些有助于代码调试和优化的高级功能。
二、测试数据管理的局限性
- 大规模数据处理不便
对于大规模的测试数据管理，Postman 存在一定的局限性。当测试数据量达到一定规模，例如需要处理数千条甚至更多的测试数据时，在 Postman 中导入、管理和操作这些数据会变得低效。例如，在使用 CSV 或 JSON 文件进行数据驱动测试时，如果数据文件过大，可能会导致加载缓慢，并且在数据操作过程中容易出现性能问题。这也是为什么在问答系统里面，我们觉得要把自动化的实现移动到python上面去 - 数据安全性问题
Postman 本身对于测试数据的安全性保障有限。如果涉及到敏感数据（如用户的登录密码、支付信息等）的接口测试，在 Postman 中存储和使用这些数据存在一定风险。虽然可以采取一些措施（如环境变量加密等），但这些方法的安全性相较于专业的数据安全管理工具还是较为薄弱的。