我基于 requests 写了个接口自动化框架，我引用了 requests，我不能叫框架，对不起。

家里马桶堵了好多次，58 上叫了好多次师傅，门被锁了很多次，叫了很多次业务。 发现都是分分钟赚上百块钱的业务。所以最近在考虑要潜心研究如何开锁和如何通马桶。 是个不错的兼职。

你说的这个
基于xxx框架（比如robotframework），使用PO模式写了些关键字和用例，就是关键字分层+配置模块+工具类模块
我觉得可以称之为脚手架，基于这个脚手架可以根据规范，快速上手写自动化

借此机会 吐槽一下 文思海辉 ，昨天 给我电话 说 招聘一个 自动化产品助理 ，最高给 20K（还是要有多年自动化经验的人），哈哈 人才；

简单说一下 ，
自动化基本操作 联调；参数化；检查点；报告；
再说 实际一点的 ，一个 web restful 框架就是，对 request 做解析，对 respose 做封装，和 route，

那么 到测试这块， 现有的 urllib 已经发展 3 个版本，request 库是现在用的最多的；

response 是开发已经封装好的 返回参数， 测试可以做 或者测试开发 可以做的 就是对 request 进行上下文的 操作，user 检查 auth 检查 route 检查； 貌似就这么多了

框架，需要抽取共性问题，具有一定的规范条件，而且要与业务有明显的边界区分；如书架，书架每层可以放各类的书，也可以规定书架放什么样类型的书。测试框架也一样，我们常见的 appium，selenium，u2，atx 等，个人认为只能称之为应用或者是工具（书架里面的书）。能称得上框架的比如 junit，testng，springboot/spring cloud。

很多人没有框架的概念，只是被误导了，毕竟网上一搜都是写的框架。
https://www.cnblogs.com/fnng/p/11607309.html

我觉得看中学习能力和解决问题的能力会更重要，拘泥于对方搭建的是否是框架又有什么意义呢？

能把框架整合好，变成适合自己公司业务的人，他招过来不香吗？如果一直纠结在搞一个全新的框架上，市面上 99.9% 的人都会被淘汰，更何况，很多时候，就算有人有类似的经历，通常也只是负责某一部分的内容，这个时候楼主是不是又会觉得这个人负责的部分没什么技术含量呢？

说句不好听的 有几个人能自己从零搞个框架出来，还不是站在别人的肩膀上。

这其实很简单理解，楼主 你写过什么框架么（不是攻击 就是询问）； 现在很少人自己独立写一个 restful 的框架 提供给其他人员使用， 一方面 市场已经健全，另一方面 也是代码掌握不够好； 经常会听到，很多人 说 市面上已经有很多轮子了，造轮子干嘛呢， 我 就只有笑笑， 市面很多框架 是好用，可再好用的 框架 还是没有自己写的 容易拓展，落地； 第三方的框架，是要学习成本的；

所以看你怎么理解呢，现在流行 拿来主义 ， 我不批评也不赞成；

基于开源的框架开发，封装成为自己场景适用的框架有什么问题吗？难道你以为搞出一个框架是造一个新轮子吗？也太看得起自己了。

从来不敢把自己写的 demo 称之为框架 哈哈哈哈

感觉被别人引用了，就可以叫框架
不一定非得啥都自己写

为什么金融类的行业不要碰，我还是小白，大佬能给详细说下吗

建议更多的关注在事情本身，还不是一些叫法上。楼主这样的心态其实不太合适做面试官

我也一直对所谓的 “测试框架” 有点不理解。为什么一定要把它理解为高大上的东西。而且对于像 pytest、unittest 这种框架也存在很多迷惑，这些测试框架的作用是什么？无非是生成一个测试报告，统计下测试数据、然后批量执行测试用例而已。为什么要搞的那么复杂？

基于 xx 框架搭建了适用于公司项目的 xx 框架~

所谓框架是可以在短时间内学习复刻并应用到实际项目中的脚手架，关键是解决现有问题的思路，后续可扩展性的考虑。不管用什么方法只要实用就可以，楼主不妨针对人家这个设计，问下你们现在测试的困难点，看是否可以因 “框” 而生，私以为解决问题的思路比所谓的工具使用，代码技术更重要。

张嘴闭嘴就说自己开发了个框架，实际 “框架” 95% 以上代码都是用了开源产品或开源库，实际连基础算法都不会写，设计模式都没听过的大有人在，对这种人最好的检验方法就是让其写代码

作为混迹游戏公司多年的人表示，现在政策越收越紧，如果不是头部公司或近期有精品游戏的企业不要碰，尤其是游戏研发类公司。永航除了炫舞还有别的吗？

airtest+poco 吧……现在游戏业比较好的解决方案了

如果是我，我肯定就选联通了，无他，求稳

毕业 3 年，30W 我才 3 千一个月

应该是 PC 的自动化 用 airtest 的