既不想写也不懂技术，那就只能一键傻瓜式操作，目前能符合你要求的就只有流量回放平台了

其实都是比较常见的问题，提几个建议：

1、不知道你们开展自动化的出发点是啥，重点想要自动化的用例或者场景是啥，预期成果是啥？从十几人的测试团队规模来说，自研一个接口自动化平台并不是一个性价比比较高的方式，根据自己的需求情况，调研后引入开源的进行二次开发适配，性价比更高。

2、任何新技术从零到一的推行，总会有阵痛，总会有比较难适应的同事。这点建议先和老板沟通清楚，从老板角度是期望通过人员能力提升解决，还是降低平台使用门槛解决，这是两条截然不同的路。

3、如果是要降低平台使用门槛，建议界面设计上尽量对齐 postman 这个大家已经养成习惯的工具，让大家平滑过渡，可以帮你省下很多推广成本。也推荐看看纯 UI 操作的 ms 或者 yapi 的测试模块设计。甚至直接用 postman 做接口自动化测试也是一条可选的路。

为什么要去迎合那些已经放弃躺平的？

感谢老哥
目前公司自动化主要是有两个目的：
1.优先做回归测试：因人力缺失，测试只去验证本次版本修改的问题，不会去验证之前版本已经上的功能，老板的意思目前是先做接口自动化，由我负责搭建起框架和编写接口自动化用例，之后逐步去增加接口自动化用例，以后每次版本上线前就运行我的项目，确保之前的功能正常。老板心里有底，另外补个题外话，公司产品是自研软件，俗称乙方，老板最忌讳的东西就是之前版本已经修复的问题这次版本又出现，所以就是想用自动化去避免这个问题。

2.帮助测试做测试验证，减少重复性操作以及提高测试准确性

目前公司搭建起来的框架其实就是参考开源项目做的二次开发，框架就是用 python+pytest+selenium+yaml+allure，目前基本上是可以实现 Web 端测试以及接口测试

目前和老板讨论后续框架的维护，我这边其实想的是做框架开发的攻坚工作，比如说加什么新模块等等，而不是想话时间去帮测试同事写自动化用例（因为后期推广可能要对接十几个项目）我自己去理解业务也需要花时间，可能后续我就没时间去做攻坚工作，另外组内 10 个测试几乎都没用过 python，学习成本高，老板担心他们不想用我这平台，我目前想到的方法：
1.针对想学习 python 的同事，那我这边把框架搭好以及提供写案例的流程化格式给他们，让他们自己去写；遇到问题我这边自己去排查。
2.针对不想学以及不想写的同事，我这边就搭建好关键字以及搭好页面可视化，写代码的工作还是我来，他们就只负责使用就好，但这样不知道性价比高不高
3.跟老板谈谈，把写自动化作为一项 kpi，kpi 驱动测试同事自己去写
个人愚见

从情感上来说，我这个过来人给你几点建议吧。
1、首先是要完全获得领导的认同，最起码是你的直接上级的认同，阐明这件事情是可行的，且能够给他带来好处。
2、在这为数不多的测试团队里面找到一两个能够和你合拍的同事，让他们能和你一起着手去做这件事，不然负面情绪会淹没你，而你没有任何的帮手。
3、积极、主动。还是积极、主动。这件事情的成败很大程度在你自己的推动，很大一部分时间内，都是你自己在闷头做。你有好的解决方案，一定要积极、主动的去提出来和落实。正常的领导不会拒绝一个主动性拉满的员工，他知道这件事情你做了不仅是为了团队，更加是为了自己，所以不会马虎。
4、可用性和交互非常重要。千万不要相信领导说的什么能用就行，可用性和交互不重要。你这个平台能不能推广出去很大程度就是同事喜不喜欢用，如果交互上难用，下场就是没人用，然后草草了事。

个人见解：
1.是否一开始就搭建平台是否有错？是否其实采用工具均可实现了，是否有调研?
2.自动化平台使用门槛是否过高？是的话，得降低门槛，毕竟开发出来的是要给人用，才有意义，这就是降低使用难度，通过培训可以使用，这就要需要你在进行开发，通过控件或者等其他方式实现；
3.需要有领导介入，因为可以说大家都忙于业务了，基本没有所谓的时间来介入自动化，你多增加一项，是否变成加班了？所以需要领导介入，制定标准，以及涉及到绩效；
4.推动本身就是困难，你自己写没事，工作量变多了，也没事，只要让你的上级知道是做什么的？另外你要到业务一线，争取用你搭建的平台给他们带来的好处，是否有挺高效率或者多发现问题，能有统一见解，才能推动；测试开发是服务于测试，项目，并不是说我开发就可以了，如果说我不测试，不到一线业务，不了解项目痛点，只开发，后面就是 PPT 工具了~

如何更好地让不想用以及手指无力的死党好友去使用脑瓜崩辅助神器

想问下，你有和一线测试的同学沟通过，了解过他们的具体水平情况，以及日常工作中对接口自动化要能达到的能力要求么？

框架基本完成，但还没能落地之前，先集中精力做落地的事情，甚至包括自己加入到业务团队里，和大家一起做测试并在过程中用自己的框架写接口自动化，让框架产生成果先（脚本你写还是团队写都行，得先有人写出来才能有用）。

接口自动化不是单纯 postman 的东西加上断言就完事的，前面的造数据啥的也有不少要注意的地方，听你说团队都没这方面经验，这个还是需要你加入他们，根据他们实际业务去找到最佳解决方案的。不要刚完成个第一版，想着后续堆功能啥的，作为一个小团队的测开，应该是最熟悉业务的专家型人才，而不是埋头搞平台的纯开发。

具体怎么落地，可以参照前面 5 楼说的。

首先，你要让他们体会到写这个是帮助自己，而不是负担。

没人会拒绝能涨工资的技术提升，不知道你有没有和他们谈过，这种编码平台还是挺好的，总比傻瓜式堆用例的平台好。现在出去面试哪个不需要自动化，有人会抵制这个吗？

我觉得，做了自动化，想要推广，就要让团队的人信任自动化结果，的确可以带来效益，减少很多手工回归；
不信任你的自动化结果，任凭你怎么推广，我自岿然不动；

作为一个小团队的测开，应该是最熟悉业务的专家型人才，而不是埋头搞平台的纯开发

无比赞同，可惜有很多公司和很多人没搞懂。

"目前可支持 API 和 UI 自动化测试，但需要通过编码去实现自动化"
为什么你的平台要编码，我觉得是你的平台设计有问题，可以看看小弟用户体验的贴

这种平台最终都是无意义的, 100% 会失败!

多谢老哥
目前平台已经搭起来，老板的意见是先拿一个项目入手，来做试点。目前我和该项目的一线业务同事对接，由他们提供接口测试验证逻辑以及重点测试案例回归集，我这边已经写完并调试成功接口以及自动化用例集，并让业务测试同事自己去使用和体验，该同事目前有学习 python 的想法，后续的话应该由他自己主动去写接口验证逻辑。

现在的问题是平台后续的维护工作，如果后续要推广的话老板说平台想要好用且可视化，能同时兼顾会写代码以及不会写代码的同事，目前可支持会写代码的同事需求，针对不会写代码的同事我目前就想到搭 web 应用给他们去做自动化，自己拿开源平台去做二次开发，这只是我的一个想法，不知道有没有其他好的想法

能同时兼顾会写代码以及不会写代码的同事

让不会写代码的同事用，基本上就只能是通过 web 界面了。但这样就变成你要维护两种不同的写法（代码的、界面的），工作量 x2 了。

一般来说，如果本身需求就包含要兼顾不会写代码的同事，可能一开始就统一用界面方式写会好一些，要不以后两种写法共存，学习成本 x2。别的平台基本都是前后端一体的，你想继续使用你的后端，只用别人的前端，可能改造成本也会比较高。

我理解你只是写了 1 个自动化的框架,同时兼容了 api ui,并没有做到平台化
我们现在的平台,用例通过前端页面维护,之后可以直接生成对应的自动化脚本,也就是用来你说的关键字驱动技术

首先，你这套东西叫平台不合适，你这叫一个自动化框架；
然后这个框架明显不适合你们团队，建议先找个开源平台或者工具去推广，做大部分场景的自动化落地，满足不了的再由你的脚本代码去实现；

前面光说问题漏了建议了。

我的建议是，既然平台已经花了不少精力做出来了，不妨先做一阵子实际推广，也借机了解下大家实际上对于写 python 代码的意愿如何，实在不愿意写代码的比例有多少。比例不高的话，暂时没太大必要再专门搞一套界面了，对提高大家技术水平也有好处。

如果比例实在高，那建议还是换开源的界面化写用例平台吧，比如 meterphere ，到时候辛苦一点，人工把用例全部迁移上去，后面就可以长期用了。

看了楼上大家的回答，据我们曾经的失败与稍有成功的经历，建议如下：
1、与现在的领导（主管）达成一致，有目标及具体计划，并得到支持，如：个别对技术有兴趣的同事，争取一点资源跟你一起做架构的开发（需要你的指导），后面维护的事，他可以帮你，也为这道框架持续下去打下基础
2、根据团队的情况，采用低代码开发测试用例的框架，并把用例转化的工作纳入同事们的 KPI（需领导支持）。前提：你这边作指导，如：带头写一个小模块的用例脚本，并运转起来，让同事们看到效果（好处）
3、主动积极推广：建议主动领某项目的小业务进行功能测试，需与业务同事打成一片，更深入了解他们，为自己的推广及自动化优化工作作好铺垫。（这一点对你来说很重要，也只有这样你才不会偏离方向，技术永远为业务服务才有价值，也为自己争取更多的可能）

让同事们看到效果（好处）,例如通过自动化发现一些业务测试难于发现的问题，并让大家有成长，没有人愿意拒绝成长的，:)

从贴子来看，只是集成开源的，做了一个框架，都不能称为平台。做平台是要降本提效，只是为了平台而平台，开始领导会支持你，后面没产生价值，第一个要干掉的就是你！ 建议不从 0 开始，要么用成熟稳定的，开不开源都 OK ， 关键是要经常更新，一个搞一个平台，工作量摆在那里，没法做好的 .itest work 我们这平台，接口测试都搞了两年多，且是专职开发团队维护。