最近在思考一个问题,当前 postman 和 jmeter 的功能很强大,也能实现复杂场景的接口测试,pm 也可以使用 newman 执行测试用例集,那为什么还要撸代码搭框架写接口自动化,它们的本质区别在哪?撸代码的核心优势在哪?
emmmmm .... 怎么说呢, 因为是存在很多复杂场景的接口测试的, 它不是能用简单的方式解决的。 也许你面对的场景就是发一个请求然后验证返回的 response 就行了。 但是很多人面对的场景比这个复杂多了。 比如我们这里的接口会调用 k8s 去动态的起一个 job 或者 service。 这个光验证返回的 json 是不行的, 我们需要调用 client 去访问 k8s 查询这个 job 或者 service 是不是正常的运行了。 同理还有各种其他的中间件需要查询验证。 所以 postman 怎么能搞这个呢?
而且你的业务应该没有接触到复杂的场景,如果遇到其他协议要用到第三方模块,工具玩的再转也没什么卵用
(比如我之前公司做远程课堂的(类似视频会议),要用到 sipp 工具来注册和发视频流和音频流(sip 协议),中间还要和和三四个服务器各种交互)我不知道工具怎么搞定
秀啊?
你是不是在群里也问了 宏哥不是给你解释了么
postman 那么强大,那为什么还要用 jmeter 啊?
jmeter 那么强大,那为什么还要用 postman 啊?
工具选择又不是 0 和 1 的问题,只能按你觉得好的来选吗?
选适合自己的就好
虽然容易让人挑选时眼花缭乱,学习时力有不逮
但不得不说竞争是进步的原动力
就像 c c++ c# java python
我就举一个场景:一个 get 请求,参数为 3 个,每个参数都有两种入参选择,你用什么 pm、Jemeter 还是 python 中 3 个 for 循环方便?
况且 postman 能进行压测吗?Jmeter 进行压测,你电脑性能足够吗?能开多少线程?工具只是能进行对应的操作,有时你需要进行一些灵活的操作时,你是先要有一个足以行动的思维,接下来才是如何实现。一味强调使用工具,哪天公司工具换了,你思路也要换吗?
Postman 批量执行多接口任务时有很大的局限性,每次批量执行时只能选择一个 csv 参数化文件,不能选择多个 csv 参数化文件,放在一个 Excel 文件不同 sheet 页里又只能识别第一个 sheet 页,你是怎么用 postman 批量执行多接口多参数话用例的?
有 Python 的存在,为什么还要用 Postman 和 JMeter 写接口自动化???
emmmmm .... 怎么说呢, 因为是存在很多复杂场景的接口测试的, 它不是能用简单的方式解决的。 也许你面对的场景就是发一个请求然后验证返回的 response 就行了。 但是很多人面对的场景比这个复杂多了。 比如我们这里的接口会调用 k8s 去动态的起一个 job 或者 service。 这个光验证返回的 json 是不行的, 我们需要调用 client 去访问 k8s 查询这个 job 或者 service 是不是正常的运行了。 同理还有各种其他的中间件需要查询验证。 所以 postman 怎么能搞这个呢?
业务需求产生技术需求
1、用手去点一堆按钮然后编辑一堆配置文件,我不觉得这是简单的方法(明明几行代码能搞定的)
2、性能测试的话,python 用协程去并发也不差的,至于测试报表和上面的统计项自己实现也不难,而且这个不像工具上面有时会造成一个假的压力值
3、好多测试工具编写的年代比较早,那个时候的普遍认知是测试不需要编码能力,导致工具都是面向 “点点点和配置文件”
而且你的业务应该没有接触到复杂的场景,如果遇到其他协议要用到第三方模块,工具玩的再转也没什么卵用
(比如我之前公司做远程课堂的(类似视频会议),要用到 sipp 工具来注册和发视频流和音频流(sip 协议),中间还要和和三四个服务器各种交互)我不知道工具怎么搞定
有些时候你需要将你写的接口自动化,ui 自动化应用部署到生产;生产环境只能内网访问,并且处于 k8s 集群中,此时你就能体会到自己写应用的好处了。工具虽然强大,但是在部分场景还是不太适合的。
用过 postman+json 数据做成自动化测试,但是很不方便去维护、postman 用来团队协作时,还需要重新配置一遍参数(导入导出)。python 可以做的事情就多了。设置成框架,分层形式让专人负责单一模块,更愉快的协作了。出参入参各种花样解析校验,编程是最简便的方法了。