临时有感，草草记录下，个人观点，欢迎讨论。
更新：
并不是说接口自动化必须按顺序经历这几个阶段，仅是依据个人经历，总结出的几个阶段。
阶段 1. 基本实现
利用公开的、成熟的本地工具完成接口自动化，比如 jmeter，postman 等
能够基本实现接口自动化，解决从 0 到 1 的问题。
阶段 2. 按需定制、自行研发
基于 testNG、pytest、RF 等测试框架，根据自身需求定制接口测试框架。
为什么要定制？业务形态的不同导致了接口测试的需求也各不相同，常常会遇到现成的工具不能很好地满足测试需求，所以，自行开发框架，想要啥有啥，不受束缚。 另外，自行定制的框架能够更好地融合到公司的研发流程中去，发挥更多的作用。
阶段 3. 低门槛化，全员普及
假设我们已经完成了阶段 2，有了一个满足自身需求的接口测试框架，但是这个时候发现，测试团队里有编程基础的人少，没几个人能写自动化用例。
怎么办？ 团队能力建设不可能在短时间内就能完成，这就需要把编写自动化用例的门槛进一步的降低，简化用例编写过程，最大程度降低使用门槛，让测试全员参与，普及接口自动化。
阶段 4. 平台化
平台化其实阶段 3 的进一步升级，而且平台的特性：能交互，能共享，能统计分析，不仅能服务于测试团队，也能向整个研发团队推广，会有更多的玩法。
阶段 5. 智能化
测试离不开的两个关键词，质量和效率。
做自动化是为了保障质量，但效率怎么保障？即使通过各种方法降低门槛、简化流程，自动化用例的编写和维护仍会占据测试同学较大的一块时间。
能不能智能地自动生成用例？
这个应该是很多公司在努力的方向，可能也是接口自动化测试最终的目标。
没有经历 1、3 阶段，直接 2、4，正在向 5 努力。低门槛并不容易，即使我把框架接口封装得再简单，实际使用过程中还是需要这种知识来解决各种难题，所以目前我得框架只有我一个人会用
涤
回复
“目前我得框架只有我一个人会用”
--从结果看，这个是一个不理想的情况，虽然导致这个结果的原因，有客观因素（团队成员能力不齐），但还是得打破这种局面，加强培训， 提升能力同时降低门槛，两端对齐后推广普及。 做出来的东西如果没能推出去，那并不能算一个好的结果。
有个疑问，关于阶段 4 平台化，直接上一个开源的平台怎么样呢？或者说想问下自研平台对比 metersphere，品质上有高很多吗
这 5 个阶段感觉有点把平台弄得太末尾了，实际上开始引入时就需要进行弄成平台还是框架形式的选型了。加上现在也有不少开源平台可用，其实平台可以直接作为第一阶段直接用。
另外，你这个只是接口测试工具的发展阶段，接口测试虽然依赖工具但不只是工具吧，还包括测试设计、测试范围等，个人觉得有点不那么严谨？
要想降本增效，降低使用门槛，对测试小白友好，只对 jmeter 包个 WEB 没用的，不如直接原生的 jmeter ， 要降低门槛 ，就得可以录制，加拖拉方式设置断言，以及参数提取，然后通过可视化拖拉方式编排接口业务场景。如下图这种
还有可能,https://testerhome.com/topics/30495 测试架构师如何解读测试平台的各种争议 我这里写的，对小白友好，
陈恒捷
回复
如果能一步直接到平台，当然是更好的，但是在 5 年前，能把平台做起来的还只有少数几个头部公司。
可能是我写的不明确， 时间范围不是指现在，是我个人经历的几个历史阶段，内容不全，只提了接口测试的工具。
墨妖
回复
“自研平台对比 metersphere，品质上有高很多吗？”
并不能保证，评估一下，如果开源项目能够满足你团队目前以及可预测到的未来的需求，那就选择开源项目，有新需求也可进行二次开发。
自研平台的优势是可定制，但时间成本、人力成本都比较高。
举个买西装的例子，如果能在店里买到你满意的成品西装，那你就没必要花大价钱去做高定了。
没有经历 1,2,3 直接到 4 了
我想定制一套，怎么样方便呢？
Alex
回复
不是很清楚你的需求，
如果图 “方便” 的话，找到一个大致符合你需求的开源项目，做一点点二次开发，是最方便的。
从 0 开始做，可能会走弯路，结果比较不可控。