经历过 excel，yaml，代码和平台化来搞自动化，还是写代码的好啊

那就写呗。自己作为用户，换个做自动化的方式不是应该很容易么？

扪胸自问，大部分人做平台是不是因为这个最简单

个人意见：写工具/平台的人应该有 2 个底线：1，不强迫（包括政治手段）别人使用；2，不强迫别人接坑。花若盛开,蝴蝶自来。

领导要强推怎么办

我们领导也是逼着使用公司的测试平台，每周还统计项目接口覆盖要达到 90%，没达到要逼着你整改，关键是特别难用啊

有一说一，自动化测试平台开发还是比较简单的，很多人拿来练手，具体的落地效果只有自己知道了

是的，直接 java 写 HTTP 请求，然后断言，数据库/缓存处理什么的最爽了，非要搞成有 UI 界面的平台化，其实效率低很多

平台应该具备的最基本能力之一：在既定兼容范围内的框架下，手写的脚本，可以随意接入平台管理，这样就可以统一方便地场景组合、管理数据、调度任务，等等等等~~~
那种单纯做成在线写脚本的测试平台，想想就垃圾~

自动化测试平台最大的受益者是开发者

一样的，你平台支持调度执行你做的脚本就行。本质上平台只是为了方便数据统计和过往回归结果统计。

不用就行了，强迫用会越来越不爽的。

我就没强迫用平台，但是强迫了各个项目的报告和构建要由平台管理。

至于你实现自动化的方式就不管了，怎么顺手怎么来，当然代码规范和结构是有要求的。

难道不应该是 Python 吗

踏实做个点工不好吗？很多人已经脱离了测试的本质！

角度不同 屁股不同 测试总监需要可视化的数据指标好些 ppt 所以肯定会强推平台化 可视化 汇总月测试数据指标. 开发平台的人肯定希望组员都用平台 好让他自己有优化的方向慢慢迭代 从而个人升值 换工作也好找. 然后其他人员都是测试总监和平台开发者的踏脚石, 被剥夺了写代码的权利 个人发展方向受限 彻底成为点工和傻瓜测试操作人员 如果跳槽能力不升反降 更不要说有些平台还贼鸡儿难用 有些东西大家都心知肚明的 就看你的屁股是哪边的了 测试总监?平台开发者?组内其他人员?

把你实际使用中不好用的点都罗列一番，然后把你用脚本写的好处都罗列一番（特别是效率上和效果上，平台写一个用例的时间脚本可以写好几个，或者有些挺需要自动化的用例平台上没法做），做个比较给领导和平台开发同学看。名义上可以说是这个平台在你所在业务的落地成果汇报。

如果领导有最终为业务服务的想法，应该是愿意听取你的意见的不直接强推的。平台开发同学如果不是自嗨型，也应该很愿意接受你的意见，去兼容脚本或者优化平台上的功能。

不过有一个点要留意，一般领导最担心的是每个人都这么单干团队就没法管了，百花齐放然后人一走变成烂摊子没人接。所以还是得取得一些平衡，比如把脚本和平台结合起来，数据上报平台，脚本编写也有一些基本框架规范限制。这块其实一般能做平台的测开同学也能做脚本框架，可以一起沟通达成共识。

其实楼主应该只是不想用平台给平台开发者做踏脚石 如果平台好用的话 我比较倾向用平台的 自动化代码本质也是体力劳动 而且比平台还繁琐的多 写的一点也不爽 还是平台傻瓜式操作爽 效率高 说白了 其实这个还是和个人利益有关 平台大家都用 起码平台开发者已经受益了 有人的地方就有江湖

做平台的人一般都不喜欢强推，会做强推的基本都是领导，目的是快速把平台用起来，出成绩。

至于 “花若盛开,蝴蝶自来” ，也要看公司。主动性强的自然会自来，主动性弱的有时候强推一下打开局面，可能更有效。

可能观念不同吧。我的基本观念是大家都是同一个团队的战友，应该能合作获得共赢。多一个敌人不如多一个朋友。

如果能共赢，做平台开发者的踏脚石也没问题，本身平台也是自己的踏脚石呀，以后出来了说自己业务实践中自动化测试做的怎么怎么牛逼，也是对自己有好处的。

有些人不满足现在公司给的薪资,只把现在的公司当做跳板 团队人多起来后这种人不会少 人家不会让着你的 个人发展利益至上 当踏脚石 不存在的 . 有些时候团队人是管不了的 每个人都有自己的想法

我理解你的意思，确实是会有这样的人，做完平台后只简单落地一个项目，写几个简单的用例，就拿着这个平台出去跳槽。

但领导也不傻，大家也不傻。这种情况下做出来的平台，谁敢用。。。既然领导都想强推了，说明还是想做长期的（领导自然得去想怎么让平台能长期发展）。既然做长期，那还是有机会达成共赢的。

而且我觉得，就算沟通到最后发现真的是这种残酷的现实，没法往下走，但也不代表这个沟通就是不必要的吧。个人不喜欢猜测别人的想法，更不喜欢基于自己的这些猜测去限制自己的行动。别人想啥你控制不了，但你做啥是你能控制的，是否要主动去沟通也是你可以控制的。主动然后碰壁总比窝在自己的世界里要好吧，而且就我自己个人经验，主动去沟通了，结果总会比完全不沟通要好，甚至很多时候会发现结果比自己想象要好得多。

当初做接口测试平台的初衷就是把当前代码实现的测试用例都搬到平台上，能达到这个目标即可

一些定时任务等围绕测试展开的功能平台化后也非常舒服

其实我是很赞成平台集中管理的 脚本说实在的 太零散了 可视化基本为 0 怎么平衡平台开发者和组员内共同成长 这个就是测试总监头疼的事情了

其实平台无罪，人有罪而已！
当然这样说有点过了。
不满足现状，搞个平台，想去跳槽，没毛病。
不满足易用性差的平台，不想用，没毛病。
站在不同角度，感受是完全不一样的。

静下心来好好，你到底怎么想的。不想难为自己就撤，不想难为别人就用。

终于有人说实话了

适当的推广我认为是可以并且鼓励的，毕竟再好的平台，别人需要学习成本和改变习惯，一般都不太愿意去接受。如果设计得好，学习成本低，也更有可能被接纳。所以另一个原罪就是写工具的人是菜逼，要写好一个工具，你需要做好产品，开发，测试三个角色，然而很多人呢，表结构都设计得一言难尽，更别提什么交互。而且放眼望去，十有八九都是做 http 的自动化，当然 http 应用广泛是其一，涉及到点 rpc 什么的基本就傻眼，能力只到那个层次又要强行装逼，最后就是写出来一堆垃圾。然后 ppt 上写出来的效果拳打 ali 脚踢 tx，无他，唯 B 尔。当然就算到这种程度，作为一个自扫门前雪的人，我是不会去吐槽的，毕竟人家锻炼下也没问题，但是过了底线：1 强推，2 让人接坑，那就 sb 无疑。

平台是用来整合资源，提高效率的，如果达不到这个目的，不如不做——或者换一个角度，从大局观出发，满足大部分人的需求，提高了大部分人的效率，那就是有价值的。否则自己玩自己的，就是一地鸡毛

想问下，你们都是达到什么测试规模才会有领导去强推测试平台？10 人以内的 QA 团队，功能也是不少的，引入开源的测试平台不能满足现状吗？

请教下，所谓的调度是什么一个功能，一般涉及哪些技术才能达到

绝大部分平台列出来所谓没有平台的痛点都是伪痛点，或者自己也没解决的痛点

比如你的平台用例就是一个 python 脚本，一个 js 脚本，一个 go 脚本。https://testerhome.com/topics/27297

还要支持三种语言，太花哨了吧，你这平台最终能落地么？

已经落地投入使用了 hhh 本质上是 worker 实现了解析脚本的功能，跟系统是分离的，系统只是管理和调度任务而已。每个人都可以根据自己的项目去定制开发自己的 worker。

平台应该要满足多层需求的。有写代码人的需求，有直接用的需求

我跟作者观点相同，这个问题我也跟我的老板讨论过，老板的视角就是，你会写当然觉得写代码容易，别人不懂代码的话，第一步都迈不出去，平台化的话，可以让外包来写自动化用例，虽然老板也知道非常难写，但是起码对外包来讲 能够完成自动化用例

你自己会写代码当然觉得容易，别人也写代码觉得容易，但是你们俩都写代码，一人一个风格，将来你们不在这干了，谁来维护你们留下的烂摊子？考虑过么？

恩，写代码一定是烂摊子？同一个团队不能统一规范？

林子大了，啥鸟都有！做的跟用的都想着想那。
@Lihuazhang
建议把帖子关了，不要在这样问题上讨论个没完。

我也做了个类似的，不仅给测试团队用，开发团队也能用，定时调度脚本、查看结果报告等等。挺实用的

观点还是没转换过来，还是认为测试没有 code 能力，这是不对的

说出了心声，好多地方就不得把测试弱智化，又不是纯业务人员，是有技术发展的需求的，不能完全忽略个人成长，关健是有的地方测试 coding 让人感觉不可思议一样

完全赞同，测试平台存在不是给不懂测试的人员做自动化用的 反而是自己公司的规模化达到某个程度后 应该开发平台来管理

赞同，就是有些人非把 IDE 的一些文件加入到 git，例如 jetbrains 家族的.idea 文件夹加入到 git 仓库，那里面的配置就可能与自己的不同了，改自己的环境吧，每次提交之前得恢复原样，要是直接提交吧，别人也有意见，把这些加到 git 的是真烦

。。。实话实说，很多平台使用的复杂程度已经超过直接用 PYTHON 了，之前各种美其名曰降低技术门槛和用工成本的不知道哪里来的自信

github 上拉了很多平台，自己也设计过平台，有一说一，真的没有纯撸代码来的舒服，平台操作实在是繁琐，一个用例填一堆东西，点来点去，这个时间都已经代码写了好几个了。更重要的时，再好的平台，也没有代码来的灵活。

所以，有什么好用的开源接口自动化框架或者平台吗？
请各位大佬推荐下