我最开始也想做个接口测试平台，功能一大堆，结果用不起来，后面闲着就做了很多 devops 的工具放在平台上，比如批量推送，根据 jira 自动推送，自动搭建环境等等都是些小玩意，结果用的人很多，再后来改进了下原来的接口测试功能，把它变成了个执行 shell 命令的东西，就变得很火热了，因为测试经常要使用 curl 来调接口，这个平台能保存命令就比 xshell 方便。总结下来我觉着只有解决了别人的需求，工具才能得到推广。

是的呢，我现在也在思考后续的方向，感觉还是需要去一线多了解，多接触才能看到对方的痛点是什么，然后针对性的解决，我们现在基本属于闭门造车，是我的失职，需要反思。同时感谢你的回复，谢谢！

看 LZ 写这么多我也说下感受吧，其实我转行过来没多久，之前想着做开发无奈准备不足，再加上生活压力先入了测试的坑。虽然没做多久，但是通过这一年多来的工作也对测试岗位有不少感触。现身处某公司，规模较大 IT 部门管理混乱，每个部门都有自己测试的管理方式，这让我在一家公司就感受到了不同测试管理的差异。第一，附和 LZ 的关于测试平台这块先说，LZ 其实不止你，我目前所处的测试团队也做了相关的测试平台，从 19 年初就已经在投入使用，然而如楼主一样，团队内没有人愿意使用，尽管你吹的天花乱转也很少有成员愿意去学习，到了第二季度的时候，部门老大坐不住了，招了几个测试开发造出来的东西没人用多尴尬，于是强行推行让每个成员编写脚本使用，并纳入到绩效考核中去，于是组里每个人不得不为了绩效去使用这个平台，但是每个人也是为了迎合一下只是写几个脚本跑起来交个差就行，对外宣称自动化平台多牛逼...说下来是不是和 LZ 情况差不多？这种情况我们不得不去深度思考一下这背后的问题。

原来孤单的不是我一个

接上面，我们深入下以下问题：测试平台有必要吗？这些很难去回答，但我们可以从以下角色去研究下；

1. 测试人员，平台上线后最终交付给的是负责业务线的测试人员，这些同事每天忙于业务的梳理，需求的跟进测试，在没有测试平台前，有很多工具供他们选择，接口 JMETER，POSTMAN 等等，这些都是主流开源的工具也都是官方开发的，做的相对完善也容易上手，对一般工作需求 来讲还是可以满足的；现在做一个测试平台来替换这些工具，换谁谁都不愿意，所以他们觉得你这个东西不好用且没必要，哪天跳槽了对自己也没啥积累。
2. 测试经理，测试平台推进的人，身处管理职位，不得不考虑如何建立高效的测试流程。因此凡是市面上正在推行的技术方案都会尽力在公司内部推行。但是不乏有不少管理人员水平低，没有分析去盲目推行技术的。
3. 测试开发，总算不再点点点了，听上去也和开发平齐，相信没有代码搞不定的自动化，你们天天点点点有啥意思？点也点不出 bug 来，感觉用我们新开发出来的平台吧。

最开始我也遇到过这种困扰，做出来的东西没人用，用着用着就放弃了。后面发现确实是自己没做到痛点，配置复杂，使用繁琐。

然后我就先做一堆 “一键” 就能用的小工具，有不爽的就盯着改，最终整合到一起，大家用的相当开心。

再说个在群里发生的小故事吧，有小伙儿伴在群里说要找人一起做测试平台，一是练练技术，二是找工作也能撑下台面。于是大家开始讨论，A 说我们差个技术架构，找个做架构的来指导下我们；B 说我会写 Python，前端不太好再招个前端帮我们写写页面吧。C 说我们还差个产品，没有需求我们做的也是瞎做。恩，这就是来自一个真实的测试群里的对话。这也让我发现一个问题，想要做好测试平台远没有想象中的那么简单，就像做一个产品一样需要测试开发产品。测试平台开发好了，大家说难用那说明需求没想好，测试平台有 BUG，因为没有人测试啊。。

看来大家都差不多，目前我的还只是自动化框架，利用 jenkins 构成 ci(编译打包，接口自动化测试)。但整个 CI 流程推不动。。好累。

每次分支上线开发都不跑，其实就是一键操作而已。。等个 10 来分钟就收到报告了。后来测试组内推广，提测时跑 CI，跑下静态分析 (静态分析没集成到 CI)。

但有一个业务组，就很充分利用，有时还提需求给我，现在 jenkins 上各种类型 job 很多，也算是价值提现吧

有一种情况就特别心累的，CI 每天会定时构建 (master 分支)， 当有用例失败时，就各种蛋疼，为什么 master 分支出问题 (说明没推广好)，要么服务有问题，要么用例有问题，然后各种问人，查看合并 master 的代码，然后用例维护。。真的累。。

之前还想，jenkins 的 job 越来越多，是不是开发个测试平台代替 jenkins 触发，感觉高上大，看到各位的现状，看来是没这个必要了

很难叫醒一个装睡的人，不排除部分人不想去学习去接触新事物，但往往大部分情况下是做的东西达不到使用者预期。
以前有团队推广 UI 和接口自动化测试平台，自己也是没有很好地应用起来，主要原因并不是不好用，而是投入成本和产出不成正比。
现在轮到自己去推广自动化测试平台，也是谨而慎之，因为自己知道还不能达到很好的效果，不能给效率和质量带来帮助。更多时候会从一些小需求出发，比如做一些数据处理、tts 等辅助工具，大家的反响更好。

让所有的测试变成测试开发，测试开发为自己服务。两者合一的产出大家都看得见。测开的产出，自己能感受到。
老哥，看你其他帖子的回复，我也觉的以后还有测试岗位趋势也正如你所说的那样，测试开发不分家。我若是管理我也会往这块儿去做，目前我还是觉的测试平台对于大多数公司是非必要的，测试深入技术去保证质量这是最应该去做到的，但是现在人员水平参差不齐，能力强的同学需要突出自己于是有了测试开发岗位，所以初期阶段测试开发经验的不足加上管理水平差，才会导致了开发平台没有人的囧事！

兄弟，没人会装睡，希望你借前车之鉴做好，测试行业需要正确的方向推动。

我也觉得小工具好，这是实在，并能够解决当前他们遇到问题，效率的地方 ，用得顺手的话，还会告诉其他人有这个东西，自己推广都不用

你的问题不在做不做平台上，而是没有人帮你推动，在保证 CI 没问题的情况下，如果是用例或者代码出了问题，就让相关负责业务的人员自己去排查，想进一步完善流程，自己去带一个产线，和业务人员一样去使用，这样才能避免闭门造车~

推不动。。与研发 leader 会议也开过几次，说好的这样这样，但一到落地，就打回原形。 ，目前只能推动测试组内了。哎

那就很难办，开发发布分支你可以做个钩子回调自动去跑用例，完了测试同事看到问题再让开发改

目前依赖测试组内同学，提测时，去跑下，有问题反馈

我说说我用的接口自动化平台。
1.先是创建项目，再创建模块，然后创建 case 时要去选择项目，再选择模块。。。。。啊啊啊啊啊，差评啊，这个项目和模块多的时候，一个个选择贼烦！！
2.创建 case 时，一个个输入框里填写 post/get，url，header，params（这个有时候还 n 个 key 和 value 的框），慢死了，根本没有直接 coding 的时候爽，这样东西都是在一块的啊。后续维护的时候也是，需要一个个点开进去修改。唉贼烦
终上：于我而言，不愿意去用这样的自动化平台的直接愿意，就是编写 case 和维护的时候，太麻烦，一条 case，要在十几个输入框里加东西，至少要花 3 分钟，还容易出错，写代码的花，可以直接复制粘贴，20s 左右。鬼才愿意用尼。
理想的愿意用的自动化平台，是类似于 swagger 这种的。当然 swagger 只适合单个接口调用，不是个接口自动化平台。

基于接口自动化测试平台，做一个造数据的工具，这样用的人就多了。
测试过程中总要造数据吧，造数据一般就是调接口，插数据库，这样你的接口自动化测试平台的基础能力就用上了

同样待在测试开发团队 3 年，这些和业务脱节导致做出来的平台不大受欢迎的事情也遇到过。

我们是通过定期轮岗业务解决的。每过半年左右，和业务同学一起去参与实际业务项目的测试。一方面是拉近和业务团队的关系，另一方面也能熟悉业务，同时自己去亲身感受团队的痛点，挖掘有价值的提升点。

另外，根据痛点做出来的工具，也会先找和这个痛点有关的个项目试点，确认有效并修正一些小问题后再考虑推广。而且推广的时候也要考虑被推广团队是否合适，不强推。团队大了需求自然有差异，如果发现别的团队用不起来，先了解确认是不是不适合他们业务。

PS：
我们接口测试目前也没做成平台，而是以框架形式提供。因为整体团队都有一定的编码基础，也希望通过写脚本更熟悉 java 语言，便于去熟悉开发写出来的程序。
而基于流程自动化用例做得造数据就做成了平台。只需要增加一些接口定义的信息，就能变成造数据平台的界面。平台化更方便研发、产品使用，学习成本低且无需搭建环境。

是的，每个团队的情况都不一样，就算一个测试部门，小的测试业务团队的情况也各有差别，有得用平台做得有声有色，有的框架用得溜溜的，有些怎么做都做不起自动化。所以很多情况下，自动化还是小团队自治这样子得。所以现在真的很想申请去业务团队亲子体验下。。。

按着我的经验，平台这个东西，对外（默认）暴露的内容越简单越好，理解成本最低，使用成本也最低
而在做平台的时候往往觉得配置越多越牛逼，越强大，但这样做完了往往反人类，再加上业务里本身有些名词理解上就有歧义，最终导致没人用
可以想一下，如果百度、谷歌在搜索框下面加一堆选项，你都选了才能搜东西，那能叫好用么

平台只是辅助嘛，没必要纠结。任何东西别人适合，自己这里不一定适合。不过近几年业界应该会对测试人员提出更高的要求了。。。应了那句，天下苦秦久矣，自己不争气，逼得外部力量介入了。

你们缺合格的产品经理和运营吧，不好用肯定大家都不用了

如果你领导推跟监控，你负责培训，执行，收集，反馈，那这个一定会成功~

自研是信仰，不要轻易尝试。

其实只要保证就算只有自己一个人用平台也用的开心，保证使用平台的测试效率比自己写代码还要高，就不亏。

不过能做好的太少了，不建议走这条信仰之路。

首先要确认创建自动化平台的目的是什么？面向哪些群体？可以解决哪些问题？
目前我的理解目的有两点：一个是系统性回归验证；二是提高测试效率
面向群体：可以面向测试、开发、产品：可用于测试验证、开发调试、产品验收等
解决问题：保证系统性稳定，发现因回归策略不严谨导致的问题；提供测试效率、间接提高开发提测质量（降低开发调试门槛）、提高产品的实际验收率（降低产品验收门槛）

系统性回归测试大多是政治任务，暂且不谈，说一下效率问题：
自动化平台将接口页面化，面向不同的用户，参数的默认值一般是没有的，参数多达 10 多个 20 个的时候，因为要多次使用，用起来就会很麻烦。
场景一：如果是一般性接口（不涉及接口签名和加密）暂无代码基础的人，测试人员在 postman 上大多都会整理好的接口，并保存有一套测试数据，每次请求只要改一下关心的参数即可，每次不用逐一填写。

场景二：如果是涉及到签名和加密的，因为每次签名数据不一致，这时候用 postman 就没有那么便捷，暂无代码基础的人这时就会使用自动化平台完成测试，但是每次（至少是首次）打开页面都要逐一填写参数，使用起来不够便捷，也不利于开发调试、产品验收；而有代码能力的人一般都会自己开发，自己维护一套测试数据，使用时也是只修改关心参数即可。

总的来说，如果用户使用自动化平台，效率没有明显提高或没有为使用者提供便利，一般使用率都不高。

我司今年也搞了一个自动化平台，因政治任务需要对部分接口添加用例，完成用例定时自动执行。因自动化平台对请求参数格式做了规定，然后为了添加用例，我需要另外写了一段代码来获取到自动化平台规定的请求格式，才能添加用例。而费时费力添加的用例也是之前在上线前不会去验证的东西，这里也不是说不该去回归验证这些功能，是考虑到自动化用例维护的投入产出比。

我理解的自动化平台设计原型，尽可能还原 * 原本接口的功能，如果对原接口有做封装，因尽量减少对原接口的影响，同时提供某种便利（比如可以将请求格式定义为 josn、可以隐藏签名和加密、其他参数的整合关联等）。

设计可以分两块：一模块用于用户系统功能性回归，二模块用于测试过程中数据构造。
一、系统性回归测试，由相关测试人员负责添加用例，需要对测试数据做合理的拆分，数据和账号的解耦，保障同一接口的数据可以应对测试环境和生产环境的不同账号
二、测试数据构造，对接口参数设定默认值，尽可能减少不必要参数输入，传入关键/关心的参数（进行覆盖），即可进行请求，一键请求，可以方便测试验证功能、开发进行调试、产品进行验收。根据业务需求针对高频操作的业务场景再做封装（上下依赖接口一起执行）等
同时备以详细的日志，展示请求接口的真实数据和接口返回的原始响应等。

看了楼主说的这些，其实也结合自己前两年的一些工作经验感觉，如果没有部门领导的推崇，推起来确实十分费劲。原先那家公司 大家都忙于需求根本没空去你平台上一条条写，后来到了这家公司，领导的大力支持， 私下里也经常去找大家挨个去问一下 去调研痛点，其实我们在做平台的时候大部分都是自己觉得做得特别方便特别好用，但是我收到的反馈就是各种不明白不会用，包括批量导入的格式这些。其实我觉得我们老大有一句话说的特别好就是我不需要你做出来技术多么顶尖，多么炫酷的平台，只要是能解决大家实际问题的就可以。

像接口测试这种平台，本来做的目的是简化使用，提高效率，但是随着需求的增加，为了适应各种不同情况，往往会越做越复杂，有时候可能为了 10 的特殊情况，增加了 90% 的代码量和配置项，但这些配置项可能很少用到，但是做成了个巨复杂的系统，比起一般测试人员使用 postman 或者 jemeter 要复杂很多，所以人家不愿意用也情有可原。要想做好一个平台，一个优秀产品尤为重要，技术并不是成败的关键

以我的经验一个自动化测试平台的定位很重要，尤其是你需要 “破局” 的时候。首先，不要大而全，找准自己的定位，然后切进去，比如接口自动化平台最大的收益在于回归、监控、巡检，相比传统的 coding，可维护性高、传承性好，劣势也很明显：编写用例、迁移成本高。其次，明确劣势了就要最大可能的消除这种门槛提供一种平滑的过度，要立标杆看价值。

一个平台有多 NB 不是功能有多么厉害多么全，而是说平台本身的包容性、无缝对接的能力能让用户真正的 “爽”。

哎，同感，都是面字工程

个人也比较反感做成平台化的，逼着其他人去学习使用这个平台，说句不正确的话，这个对以后跳槽都没多大帮助，用些开源的还能提升下个人技能；相反做些小工具，解决日常工作中的一些痛点，推行起来就比较容易

平台话推广， 哎 累死人； 我之前也独自搞了两个平台，结果就我一个人使用和维护，后面我自己直接干掉这两个平台； 现在是参与部分项目行测试；和帮忙我们的团队人员，一个一个接口的 过脚本，做数据/断言/入库/报告/集成 哎 我能有什么办法呢； 搞小工具，不知搞什么的 ，你能想到的 貌似市场都有

其实现在开源的接口自动化测试平台都挺好的，不如选一个何时的做下二次开发自己用，从头做新的。。。测试人员本来就不够，做出来也不见的适用，，，开源的毕竟用的人多，基本功能都满足，自己再研究改造下，成本小成效快

这就是内卷啊，不做的话没有升职加薪出去面试没得说，做了的话达不到友好的使用体验，多矛盾。