软考和你的工作任务会有什么冲突吗？ 难道你现在工作时间不用做其他任务专心备考？

另外还想吐槽一下楼主，标点符号可以规范一点吗？读起来挺难受的

证 是没人看， 貌似可以 评职 减税；是国企，没证 很尴尬的

缓缓打出一个？你负责啥，你做了啥，你想做啥，怎么做？

软考还没有你在平台化建设过程中积累的有用，谁还看那个。。。

通用场景下，excel 可以满足 80% 常规的接口自动化测试需要，上手也简单，文档多，而且写批量用例复制粘贴然后简单改改，比较省力，初始的用例产出速度比较快。

当然对应的，excel 格式灵活度相对比较低，维护也麻烦一些（比如开发接口换个字段名，开发改一行，excel 得改 n 行），剩余 20% 的场景就不大能胜任了。不过也问题不大，这 20% 变成直接写代码就好了。

远古时期的自动化测试是 UI 层的 QTP 工具，参数化的时候就是 Excel 表格形式，可能从那个时候代代传下来的把。

说你的地址 我去找你，居然怀疑我；

维护简单用例可以使用 excel，但是复杂的，再用 excel 就很不好看了，难维护

我的疑问在于现在测试行业哪还有那么多小白，不是新时代的文盲，都被淘汰了么？这么做意义何在啊，你说外包还要小白？醒醒吧

因为 EXCEL 用例处理的方法最简单。另外。。。。。网上很多例子都是 EXCEL 数据哈哈，抄起来方便

我个人的一个理解吧，就是如果直接用 Python 写用例的话，你后续维护的成本会增加，每次用例修改等操作都需要懂 python 的人来维护。但是用 excel 的情况下，随便一个小白按照你的格式写用例就好了，不需要懂 python 代码等东西易于维护。

……不知道你到底懂不懂，在这鬼扯~

我尽量推荐团队的人用 yaml、xml 之类的，以便平台可移植

python 现有的 写的脚本，暂时貌似不是框架，因为你使用的 基本都是 在 request /urllib 基础上，也就是脚手架而已； 至于怎么进行驱动使用，看你则么安排 脚本数据/exec 了/DB/模版 都是可以的； 这种方式 也就是 规范了数据入口而已， 对 也就这么多；

这个暂时不用担心，你开源了 ，没有进行商用，你的目的是 提供给他人的学习使用的； 你不需要 承担任何法律承担，你只是开放，提供其他人学习，没有进行商业途径； 至于 其他人说的。著作权/署名权/发表权 乱七八糟的，判断是否侵犯 主要开你 做了什么动作，开放提供学习，是追责不到你的的 ；

在 excel 里的数据完全可以不需要自己去写,让别人去写

不管好用不好用，逼格是这样提升的

你说的那种是最 “LOW” 的，其次读 execl、数据库，逼格逐渐提升

就算没有著作权，你也没有权利这么做，虽然情理上你没啥毛病，但是法理上你是违规的。

我问个问题，很多年前，我自己写了一个平台，辅助工作用的（没有领导强制要求，基本业务时间和没工作的时候完成的），然后被公司拿去申请著作权了，后来我把这个平台修改了下代码和页面样式，然后开源了，请问这个违法吗？

大会的很多方案都是有落地效果的，一方面我不觉得他们在吹牛逼，另外一方面我也不觉得 mtsc 能代表顶级。外行看热闹，内行看门道，看完了觉得自己工作中还有很多可以改进的思路，弱水三千只取一瓢

证书下载到电脑 然后 adb push 应该可以

“一是学不到东西，二是创造的价值不再增长”
就是你在这家公司的价值趋向于平稳了，没有什么进步了，就可以考虑了～最近看到的

我觉得参加大会不是说去想着直接能够看完就能照搬别人大厂的成果。更多去了解现在业界的测试都在做什么。自己的方向对不对。当然还有去学习人家的思路，有哪些内容可以去做跟落地的

《测试框架》很重要，而并非是不重要。
但是，用牛逼的测试框架，并不是你牛逼了；相反，把一个测试框架用牛逼了，真的让测试贴近业务场景，测的有深度，测的有效率，这才是真牛逼。

狭义的测试框架，例如 pytest，或者 testng，是在方便你组织测试逻辑的，其中包含了 tag 过滤，teardown，重试等能力。
而广义的测试框架，可能会捆绑周边的一些常用模块，例如报告，日志，收发协议库（http/rpc），模型代码生成（swagger）等。

一个半小时左右的分享，你想每个背景每个细节都讲的很清楚很详细吗？ 这不可能的。
我听过不少的分享，主要看思路，看看别人大厂是遇到什么问题，解决的思路和效果等；至于落地，没有大厂那样的人力资源，只能找其他简单的方法替代和在自己的工作中落地。
如果你连概念都没弄清楚，建议还是先去查查资料，补补课再详细去听吧，效果会好一点。