其实本人知识广度也不是很够，真正开发和使用的框架其实并没有多少（但是也因为大部分的框架大同小异），在团队开发自动化测试框架选型的时候，本能的避开了使用数据驱动，这里说的数据驱动，实现起来大部分是在 excel 写用例和写数据，约定书写格式。
当时的想法是，python 的语法已经够简单了，有时候看一些 excel 写用例的，觉得写在 excel 里边，有时候还需要一些特定写法和格式来复用参数和逻辑，直接写在 python 脚本里它不香么
可能会有说到学习成本低，但是用 excel 实际上更加多了一层学习成本。
可能是我实践的范围太窄，看不到这种类型在后期的好处么？
不管好用不好用，逼格是这样提升的
你说的那种是最 “LOW” 的，其次读 execl、数据库，逼格逐渐提升
在 excel 里的数据完全可以不需要自己去写,让别人去写
python 现有的 写的脚本，暂时貌似不是框架，因为你使用的 基本都是 在 request /urllib 基础上，也就是脚手架而已； 至于怎么进行驱动使用，看你则么安排 脚本数据/exec 了/DB/模版 都是可以的； 这种方式 也就是 规范了数据入口而已， 对 也就这么多；
我尽量推荐团队的人用 yaml、xml 之类的，以便平台可移植
我个人的一个理解吧，就是如果直接用 Python 写用例的话，你后续维护的成本会增加，每次用例修改等操作都需要懂 python 的人来维护。但是用 excel 的情况下，随便一个小白按照你的格式写用例就好了，不需要懂 python 代码等东西易于维护。
因为 EXCEL 用例处理的方法最简单。另外。。。。。网上很多例子都是 EXCEL 数据哈哈，抄起来方便
我的疑问在于现在测试行业哪还有那么多小白，不是新时代的文盲，都被淘汰了么？这么做意义何在啊，你说外包还要小白？醒醒吧
维护简单用例可以使用 excel，但是复杂的，再用 excel 就很不好看了，难维护
远古时期的自动化测试是 UI 层的 QTP 工具，参数化的时候就是 Excel 表格形式，可能从那个时候代代传下来的把。
通用场景下，excel 可以满足 80% 常规的接口自动化测试需要，上手也简单，文档多，而且写批量用例复制粘贴然后简单改改，比较省力，初始的用例产出速度比较快。
当然对应的，excel 格式灵活度相对比较低，维护也麻烦一些（比如开发接口换个字段名，开发改一行，excel 得改 n 行），剩余 20% 的场景就不大能胜任了。不过也问题不大，这 20% 变成直接写代码就好了。
如果驱动数据多到写 py 都很烦都时候，是不是想想冗余数据太多了？利用 “外部” 数据源，个人感觉是一件吃力不讨好的事情，先不说整体执行时间加长 (就算预读，预读时间一样会加长)，最不理解的是，为啥不用 All-pairs 清洗下驱动数据，从而加快执行效率呢？