接口测试 关于 Postman+Newman+Jenkins 做接口自动化测试 有大佬项目这样的吗？
最近在做这块的调研，考虑团队人员技术能力啥的，不准备直接用代码去实现自动化测试，希望能够借助自动化测试平台。
Postman+Newman+Jenkins 这个自动化测接口，因为现在调试接口都是 postman 在调试，技术学习成本比较低，后期项目交接什么的维护成本也低。
不知道有没有大佬在用？项目接口大概 200 个左右，不知道这样算不算多。
要是大佬有其他比较好的开源平台推荐 也可以介绍下。
用 postman 这个做，难度不高，不过考虑后期对这些导出的 json 的维护管理，比较麻烦。
接口自动化测试 这个不是项目必须，只是一个优化工作效率的产出物。
那么问题来了，接口需要依赖 cookie 怎么办？怎么做断言？
之前这样做过，接口功能测试的时候用的 postman，顺理成章的功能测完做自动化也直接用了 postman+newman
用了几天发现这个做自动化不是很方便，接口有变动的话修改起来麻烦，最后老老实实用 unittest+requests 了
你可以先试试，做个比较呀，这种经验有点价值
楼主我想回答：1，postman 我是玩转了一年才 90% 熟悉它（实话说，postman 能和数据库关联校验数据、能用 test 断言获参动态，能用 pre 脚本生成测试数据，能做安全校验，用它做接口可以满足，whynot?）。2，Newman 的命令并不难，且可以在 Jenkins 上使用。3，Jenkins 我不熟悉（因为之前是找运维帮我搭建的，我负责脚本 OK，运维负责给我服务器和 Jenkins 跑起来）。3，postman 很明显的缺点是不能做并发，但是做加压 no problem。4，postman 对于脚本的维护性是根据你对 postman 的熟悉度和 JS 的熟练度来决定的（当然无法和 Python 比，因为一些公共库和资源很难做到完美，但是局部环境和全局环境可满足你的公共资源）。5，建议你在接口稳定后才考虑 Jenkins 的自动化，毕竟维护一个多变的接口，任何一个脚本语言都是很费事的。6，接口自动化的设计好与坏，取决于你对于接口所对应的业务逻辑设计，也就是场景设计。
我属于菜得一比的那种，所以这是我使用的感觉和认为。你可以想象一个一年都在啃 postman 官方文档的人是多么地无聊，但是 postman 不像很多人认为的简单接口工具，它用处很大，尤其是对于 json 格式的接口数据
Test44
回复
谢谢回帖哦，postman 也是用了很久了，现在接口已经基本稳定 只是优化项目做 异常接口的检测，对自动化测试要求不是很高。
而且 准备这部分工作是交给测试去进行完善的。postman 这边就是第一个考虑的了。
楼主可以试试 HttpRunner 框架，也是在社区开源的，同时提供 postman2case 可以方便的把你原有 postman 的接口导入为对应用例格式，因为是基于 python 开发的，语法上会更加灵活好用吧。
推荐 HttpRunner！
先了解下 postman 的限制吧。 200 个接口，每个接口的测试用例基本数平均在 7~8 个。 免费版注定行不通
没什么问题，Postman 本身的脚本功能也足够强大，方便扩展。而且提供了各种主流语言的接口代码转换，后续再换也没太大难度。Postman 按 Collection 管理用例，规划好不会存在太多导出 json 的。而且 newman 也支持使用在线文件执行，json 文件完全可以弄个 web 端维护。收费版主要是它 cloud 端的监控、在线文档、API 调用等的额度限制，你目前的需求不需要用收费版功能。
cookie
回复
这个搞不定还能叫接口工具吗... 取 cookie 存到变量中就好啊。断言？你能想到的接口断言方式估计都支持... 除了 Postman 自带的断言方法，也支持 chai、jsonSchema 这些第三方库
用 jmter 也可以。或者直接用 pytho 写吧