对比接口测试工具在自动化测试优缺点：Jmeter、Python、Postman

一、JMeter

总结：适合对代码不敏感的使用人员，不会代码也可以完成接口自动化，设计框架。适合紧急迭代的项目。

JMeter接口测试的优势

小巧轻量级，并且开源免费，社区接受度高，比较容易入门
支持多协议，并提供了比较高级的扩展能力，允许自己定义和扩展新的协议支持，比如扩展支持阿里提供的Dubbo协议的JMeter插件等
学习者不需要会代码，不需要编程，熟悉http请求，熟悉业务流程，就可以根据页面中input对象来编写测试用例；
Jmeter 自带 20 种控制器、40+ 种函数、20+ 种配置元件，可以满足 99% 的项目接口自动化需求；
可以集成不同的应用，数据库，redis，mock，dubbo、jar 包二次开发等都不在话下；
可以根据喜好（项目特性）自由组合（适合项目的）测试框架；
实在满足不了的，可以用 beanshell 编程，可以写出比较灵活的测试脚本；
因为 Jmeter 自带组件、函数，所以编写接口性能脚本特别高效、快捷。
JMeter社区比较完善，提供了比较丰富的协议支持。比如除了支持常见的HTTP协议之外，还可以直接通过JDBC Sampler连接数据库，把期望的测试结果存入数据库中，直接对测试结果进行验证。在编写测试脚本过程中，可以将不同的协议调用使用同一个脚本进行组合调用，写出比较复杂的测试用例。
JMeter提供了html测试报告和Jenkins集成的能力，比较方便地实现一些基础的持续测试。
不依赖于界面，如果服务正常启动，传递参数明确就可以添加测试用例，执行测试
测试脚本维护方便，可以将测试脚本复制，并且可以将某一部分单独保存。
可以跳过页面限制，向后台程序添加非法数据，这样可以测试后台程序的健壮性。
利用badboy录制测试脚本，可以快速的形成测试脚本
Jmeter断言可以验证代码中是否有需要得到的值
使用参数化以及Jmeter提供的函数功能，可以快速完成测试数据的添加修改等

JMeter接口测试的不足

脚本的灵活性。虽然JMeter提供了一定的BeanShell编程能力和自定义协议的扩展能力，可以让脚本开发人员有一定的灵活性，受制于JMeter本身的限制，与开发人员直接使用语言进行接口测试相比，灵活性还是相对不足。
报告的能力。JMeter提供了HTML报告，但是JMeter本身的测试报告主要用于性能测试，反映的更多是性能测试层面的结果。而且配置过程比较复杂，在团队成员分享报告等方面比较麻烦。
持续集成。利用第三方的Jenkins插件、Ant和Maven等，能与JMeter进行一些基本的持续测试集成，但是对于完全自动化所需的测试环境的管理等功能支持不足，配置过程略嫌麻烦。
测试脚本和测试结果的管理：脚本和结果基本都是本地管理，无法做到在线管理。
不支持前端测试，使用Jmeter无法验证JS程序，也无法验证页面，所以需要手工去验证。
Jmeter的断言功能不是很强大
就算是jmeter脚本顺利执行，依旧无法确定程序是否正确执行，有时候需要进入程序查看，或者查看Jmeter的响应数据。
Jmeter脚本的维护需要保存为本地文件，而每个脚本文件只能保存一个测试用例，不利于脚本的维护。
调试不方便，不容易从结果提示错误中快速定位到错误点具体位置，例如一次测试几百个接口，如果有几个接口出现了问题，还得一个一个去翻查找
在接口自动化测试中，较难给测试接口快速提供可测试环境，或者说较难提供自己想要的测试环境
使用过程中单位不规范（有时候单位秒、分）