没回复你，我仅仅看到虫师的回复很神奇。

这是是引用虫师文章的话。

作者吐槽的是将测试用例数据存库、存 Excel 文件，仅赞同这点。

为啥 testerhome 戾气这么重。。。骂战这么多。。。

不用管别人怎么说，工具能出来就有用武之地，虽不能各种场景覆盖但是对于一些特定环境下，还是不错的选择，如果后期你的工具玩的足够熟，你待遇不会一些写代码的低，玩代码只是说让你在测试这块增加一种手段。

还在用 Robotframework 写接口测试用例的小白瑟瑟发抖。。。。究竟 RF 写到什么程度就算 “毕业” 了呢？

额 ，这位兄弟，我觉得你的观点有些偏颇，需不需要数据库数据量不是唯一决定性的因素，还需要结合项目业务，比如我 当前负责的自动化测试项目（覆盖业务主流程），不是数据生产，很大程度是数据消费者（并且各个阶段数据关联性较强，甚至需要在测试过程中对数据库数据进行更新的操作，才能够让自动化用例重复运行）。

在哪里听说的？选择性内容过滤？断章取义很开心？

我也第一次听说产品经理要用测试编写的测试框架写用例。

如果为了降低门槛而使用 yml、excel 等等方式去让每个人都可以做自动化，那还要自动化干嘛呢？不用源代码的工程化维护都是耍流氓

yaml 是不是更好的选择，既可以有利于维护和解读，也不用读表格

我不跟你们扯可维护性、灵活性、扩展性，拿一个自动化的技术实现话题你跟讨论 组织愿景 ， 来！ 你告诉我最广大测试同学的愿景是什么？ 还是你们公司、你们团队的愿景？

始终觉得读表格是一种完全没必要的行为。数据量小的时候不需要单独的表格来存储，数据量大的时候会给维护带来极大的困难。
任何表格都是这样，不存在特例。

个人感觉真正的功夫在于对于参数选取的优化上，减少重复、冗余、无效的参数数据量，让参数数据集变的清晰、明确、有条理。感觉这才是更重要的工作。

我帖子的标题 “读表格” 来做参数化简直的毒瘤...

主要怼的是：

1、用表格存参数化测试数据。

2、用表格存元素定位。

从我来没没说过 读数据库是更好的方案 ，哪里让你产生了理解偏差？ 至于我推荐方式在我的文章和这个帖子里都有介绍。

读表格的者 观点不就是配置简单，不用写代码， 灵活性不也应该考虑一下。难道你们实现的 读表格 只适合一种业务，一个功能？那就不要拿出秀了，别人又不能用。

感觉这就像一个 cms 系统，明明有新增功能了，为啥还要开发一个导入功能。明明有 page list 了，为啥还要导出功能一样。

操作系统 + office 系列，软件生态必须品哦。至于 test data 是否有必要用 excel，还是 json，yaml，能让团队快速用起来，搞好测试就行。

内核够硬，搞得漂亮些与否，看你老板和你自己。灯黑了，只要达到效果，差不多就好。

恩，这个话题从灵活性一出来就已经结束了，底层向上而较的灵活已经是生怼了。

了解下这个？
https://testerhome.com/opensource_projects/masteryi-ui-test

同意你的观点，感觉楼主已经陷入了跟陈皓几年前舌战群喷一样的偏执——只从技术应该如何发展本身的角度考虑问题，而不跟你扯任何组织愿景与现实，比如他认为测试做不好的开发都应该滚出码农界（非原话，大致这意思吧），所以只能说理论上支持一下，实践的时候导向一下，强求和扣帽子就非常不智了。

灵活性？任何代码开发的再一定程度上具有 GUI 的工具，都是用代码开发出来的，还能比原生代码灵活？
UI 自动化不只是考虑易维护了，现在都开始考虑灵活性了？
何况 Excel 的话也可以让用户自定义一些关键字，怎么不灵活了？
工具是列出一系列的规定，就和协议类似，遵守即可快速使用，这个已经不只是 Excel 的范畴了，你已经开始否认所有的 GUI 工具了，难道单元测试框架，能比直接撸代码灵活？单测框架也是代码开发出来的，也会有一些限制，例如注解，装饰器，某些函数的开头，这不会影响灵活么？

你的标题是 读表格 在我看来 读表格是读数据库的过渡期 这么说你明白我的意思了吗？

哈哈，现在人家自己搞了网站自己玩自己的

我觉得框架如果只支持读取固定数据格式的话，局限性还是挺大的，即支持读取固定数据格式同时也支持自定义构造数据的框架我觉的还是挺好用的。

抱歉！ 1 和 2 没看太懂，如果有例子就更好，相信也有和我一样没看懂得。

3、我没有反对平台化，如果在平台上依然 填表格 ，我反对！也不否认协作，每个公司开发比测试多多了，他们怎么协作的？

4、UI 自动化是从功能测试用例里面提炼而来的，如果你们的功能需要用户输入大量的数据，那么是否做到了满足功能的基础，体验最好？ 所以，我说 UI 自动化所用的数据量不大，就更谈不上要用数据库维护参数化数据？ 如果是维护用例本事，那确实很大，所有用例都是数据。

5、重复的 find_elemnt_xxx 当然可以通过良好代码设计和封装消除掉，灵活性 也绝对比 填表格 高！

Excel 可以看做一个简易的数据库，我倒是觉得不是 Excel 做不到 而是写代码的人没有做到
1、我看你的举例，无非是几个输入点击等等，每一个流程可以看做是一个 case，最后有一个 sheet 去汇总要执行的 case 就好了，步骤是有相同特征的，即使某些操作使用同一种特征处理无法满足时，也可以定义一些关键字处理

2、当单个用例写完 ，有一个 task 的 sheet 去引用每一个 case，就做到了你说的一行显示一个 case，也能做到看 Excel 的行数就能知道有多少用例

3、我也并不是说 Excel 很好，平台化在现在看来是一个很好的方案，当团队越来越大，协作的需求也就越来越显得重要

4、你说的是面向新手，不再教导新手基于 Excel 怎样怎样，Excel 在我看来可以用于新手的一个过渡，由 Excel 转向数据库也是一个很好的过渡过程，你又说 Excel 维护大数据不好，又说 ui 数据没多大，用不上数据库，不知道怎样的数据量才能恰好属于你说的适中呢

5、并不是照顾不会写代码的测试人员，而是重复的例如 findelement 这种频率高，没什么营养的代码不用在写了，工具，提升效率罢了。

1. 标题里一眼看到的形容词就是 “蠢、坏、毒瘤 ” ， 这是讨论的正确姿势吗？ 你试下用 “我觉得你的做法太笨了” 开头来给别人的方案提意见，看下会不会引发骂战。
   如果是讨论《“读表格” 来做参数化的自动化方式好不好》，那我觉得肯定意见是百花齐放，这里那么多实践过的同行都可以参与讨论，说不定收集全各种意见论坛里组织开发个大家都满意的工具出来，为行业造福。
   至于是不是大 V ，您可是写个专栏，出过书，办过培训班的大神，包括我在内的很多人都是看您的系列教程开始学习自动化，在这方面您对自己的影响力不会不知道吧？

2. 至于我 “和稀泥” 的行为： 我的观点一直是： 每种工具都有适用范围，至少我碰到挺多同行都是偏好参数化数据驱动来组织测试用例的方式。存在即合理，您一上来就把这一类工具全部打上 “蠢、坏、毒瘤” 的标签，对这类工具的开发维护者来说都是不公平的。

3. 包容是我提的，因为我觉得您缺少包容心。 工具的好坏不是黑白，是没办法客观分清的。

4. 读题能力： 不是我读题能力不行，是您标题起得太有技巧性了。

1. 我的话题偏了吗？ 那请你用客观的描述把标题带回正轨。

你说的是静态统计么？在不运行的测试的情况下，看 excel 的行数就知道有几行用例？

excel 依然做不到！

1、如果是用例 excel 做参数化，那它只能记录一种类型的数据，我在 #18 楼有举例，不同的功能用到的数据不一样，很难放到一个文件中，如果几十个数据文件都打开计算一遍也叫方便的话，我无话可说。

2、如果是用 excel 存测试用例，接口测试除外，UI 自动化，每个用例步骤不一样，怎么把用例写到一行，如果不是一行，那依然不能按照所占用的行数进行统计。

如果的是动态统计的话，利用单元测试框架跑一遍就是知道了，成功、失败、错误数一目了然。 如果和 jenkins 集成也可以看到历史的执行情况（领导想看的？）。

另外，我也并不是特别鼓励 json，yaml，UI 自动化本来用的数据就很少，单元测试框架的参数化就够了。

欢迎，你开源出来你们的方案。

其实每一种方式都有他得缺陷，我在等大神的评论，学习中。

1, 是引发讨论，又不是没有任何论点、论据的乱骂，大 V 这个就比较搞笑了，我总共就在这里发了三个帖子，也没有微博，你给我加的大 V ？ 另外，别上升到身份绑架，如果换个测试同学过来发这个帖子是不是就不掉份，是这个意思么？

2，你是没试图说服我，以上来就 和稀泥 , 你跑到一个讨论帖下面 和稀泥 合适么？ 没有人能说服我，你确定？ 我只是要求说服我的时候给 点实列 和依据，这过分么？

3、包容 是你先跑到我的贴在下面说的。

4、你以为看到我标题的同学是过来看我们两个吵架么？当然是想了解一下 “读表格” 做参数化咋不好了？ 都没有读题的能力。通过留言，也可以看出有同学是想看有价值的讨论的。

5、 是你用 和稀泥 、 包容 的观点把话题带偏了。

说的很好，我也很赞同。exlce 自动化绝对是坑爹的一个想法。

1. 用 “蠢、坏、毒瘤 ” 来作为标题党引发论战，作为大 V 的你不觉得掉份吗？
2. 我从来没试图说服你，原因上面说了： 你在标题里用到 “蠢、坏、毒瘤 ”，已经是强烈情绪主观的表述，没有人能说服得了你。
3. 既然你都叫我不要参与讨论你公开场所发的帖子， 那也就没必要和你讨论包容了。
4. 最后纠正你一个逻辑错误： 这个帖子有一千多浏览，不代表 “至少这些人在用 excel 做自动化的时候会考虑一下我的观点和多一点思考” 。
   

首先，我的 厌恶 并不是主观，通过我的经验总结出来，蠢、坏、毒瘤 只是为引起关注。

我用文章 阐述了不认为使用 excel 不好的原因，我一开始都欢迎 用 excel 做的牛 B 人过来怼我（说服我）。

说服我要拿例子吧！ 也好让各位测试同学 观摩、学习、评价吧！ 空怼 和 YY 需求 还不让反驳了。

不要总结 土壤 、包容 ，你这么包容，就不要参与这个贴子的讨论了，还试图自己的主观看法说服我？

这个帖子现在有 一千多浏览了，至少这些人在用 excel 做自动化的时候会考虑一下我的观点和多一点思考。

这种问题没有继续讨论下去的必要了。
当你对某样事务的厌恶已达到了蠢、坏、毒瘤的程度，辩论已经不能说服你。

其实人生来就是不同的，三观、信仰、习惯、思维。。。 正是因为有不同的思维，不同的尝试、试错、改进，我们现在才有现在越来越多美好的选择。

前几天有个关于 “土壤” 的帖子也引起很多人讨论。 其实我觉得国内的测试行业的土壤，需要的是更多的包容。

你可以引申一句：等大家都牛逼了，再来一刀，都换成 yaml 或者 json
反正我以前的做法很简单：web E2E 的自动化用 txt、csv、excel 这种所见即所得的管理模式，接口全用 json

我说的是

用什么管理就不是重点，如何让整个团队甚至其他干系人都看得懂、看的轻松

并非是说让他们来写 case，以前我们做的自动化测试脚本，需要提交同行评审，大家都要看
吐槽归吐槽，情绪不要太重~

这回复说的挺有道理的。
其实可能框架作者不是不想做到纯点点点不用写代码，就可以自动化，只是实现代价过大，做不到罢了。目前的框架，包括 RF 等等都是妥协的成果吧。。。
不过这不是喷读表格的理由啊。。。KAGGLE 也都是读表格。CSV+XML/YAML，包括提交结果很多 CSV 的。PANDAS 可以直接处理二维数据，非常简单。。。

为什么不想这个去吧业务封装下，总是想着怎么把自动化操作去封装呢？
有这个时间为什么不去深入了解业务，抽象化脚本业务代码，封装关键业务代码呢？
天天整那些不用写代码就能自动化的事有什么用？

QTP 为什么被淘汰，除了价格贵，笨重不灵活也有这个原因。

真的做自动化没有比直接写代码来的更加灵活和舒畅了。

现在是深刻的认识到土壤两个字的意思了

第一次听说，产品经理要用公司做的测试框架写测试用例， 还有业务用户和内部客户。

麻烦实现 excel 写测试用例测同学就不要往测试社区发了，多去一下产品经理社区。因为用户是产品经理！

在开发的世界，有人写框架，有人用框架实现业务，你见过有人把框架封装的不用开发写代码，大批开发的还用的屁颠屁颠的么？关键是很难做到灵活，可维护、可扩展

为什么在自动化的世界就要照顾那些不懂代码又想做自动化的同学？ 测试圈的人比较怪，就是在做框架之前就要考虑怎么不让测试写代码， 这都给大批后来者测试一个错觉，就是写代码的框架不是好框架，用 excel 的框架才是。结果呢？

最后，用代码定位一下元素，再实现一下操作，谁不会？ 用表格就不用写定位了，就不用指定动作了？

人家说的不是业务测试，而是产品经理以及产品面向的业务用户甚至是内部客户~

业务同学喜欢用表格？ 业务同学完全不想懂代码？业务同学单纯用表格就能把自动化做好？ 确定不是 YY 出来的需求。我遇到的测试同学从刚工作到做了 N 年的，大家都是有学下一点编程的诉求的，毕竟没人想被行业淘汰。况且，像 python 这样的语言门槛不高，资料有多。

如果你们公司存在这样的业务同学，我想这对公司和团队的发展并不是好的。

估计用 Excel 的数据驱动思维继承的是以前 QTP 的方式，记得最早接触自动化就是 QTP，数据的参数化就是类 Excel 的视图。

因人而异吧，虽然个人不喜欢 Excel 的参数化，但是如果用的人非常的熟悉，能够及时把自动化推广用到项目中，先解决有无的问题，是可以接受的。
但最不能接受的是 UI 自动化数据存到数据库的， 这是要和开发拼 CRUD 的能力嘛？

其实主要思想还是数据与代码分离吧，不过那些鼓吹不用写代码就能做自动化的，真的是又蠢又坏。
顺便来评论区取取经

其实我想说，读取数据文件进行测试是为了方便写测试用例的人和写工具的人分开，毕竟直接在代码里改测试用例风险比较大，开发者自己有时候都可能手贱改残代码，何况是两个人合作开发

为什么说写死呢？不明白你的理解！

业务代码 你会把数据写死？

表格可以让业务同学去维护
yaml 本身也是需要进行解析，和读表格没差别，虽然支持格式比较多。

关键字驱动 db

自动化测试特别是 ui 方面，这玩意，我不知道国内究竟普及到啥程度了，反正我接触的中小企业来说更多的都是叫好不叫座！如果从小项目，用例更多体现在流程而不是覆盖率式的单元测试的话，个人觉得表格应该也有自己的用武之地的，当然如果用例规模很大，表格的一些参数化维护反而容易把数据和业务代码脱离特别厉害！

用代码来做数据驱动更方便，为什么要用 csv，yaml 这种更复杂不直观的方式

只是从具体来做时来分析，csv 的形式只是实现比较简单，但是根据维护成本和用例复杂度来考虑的话，应该还是优先考虑 pageobject 模式吧

csv 的话，像是测试流程时存在复用时应该只是复制黏贴，po 的话直接调用某个类和方法即可，可读性高
另外就是前端 UI 变动时，针对有复用的情况改的地方多些
我没做过这块，上面的只是分析来说会存在的情况，不正确的话还请指正哈

你写的那个平台里边用的是啥数据驱动？

额，菜鸟还是把这几个都实践一下再来跟帖回复吧。我是菜鸟，感觉要学的东西太多太多。

大家收一下， 别太发散了。 楼主喷的不是数据驱动， 而是做的不好的数据驱动和关键字驱动。 这点我也是赞成的。 就像研发有句话叫过度设计， 认为过度设计的东西是不好的。 同样的，自动化测试如果过度设计，把数据驱动进行过度的设计反而是不好的。 其实数据驱动这么小的一个东西没必要单拉出来大书特书，大多数时候就用 java 中 testng 的 dataprovider 这种就够了。 还是把主要的设计精力放在怎么封装业务逻辑，能够更稳定的支撑大规模的自动化 case 上吧。

原来是没有的，是后来更新之后加上了

文章里不是自带链接吗？

1. 点你的头像进去没看到你说的三篇文章，能否给个链接我拜读一下？ 2.对于 Excel，我的替代方案是用数据库保存，做成 web 页面来编写用例。这个方案对我来说很适用，但是对你来说可能很不适用，所以我觉得大家都有自己选择的权力。
2. 两种方案我都没觉得不好，所以 “你觉得不好是你的问题！” 这句话我没法回答你。

不知道大家对 PageModel 类似的模型写 UI 自动化怎么看？

所以，我用三篇文章详细说明了我的观点，那么你是不是给具体的做法，解决了我说的问题，让大学学习借鉴一下，而不是我觉得好就好，你觉得不好是你的问题！

各位看官看到有哪个优秀的开源项目是用 Excel 维护自动化测试用例的？

有哪个优秀的开源项目是用我朝特有的测试平台测试的？

自动化测试不就是一个工具吗，有人爱折腾脚本，每个页面每个原素都在代码里维护；有人喜欢数据（原素属性或者用例步骤）和代码脚本分离，用更贴切测试用例的方式来管理用例。

为什么测试圈里就这么强的鄙视链，我支持的就是最好，不支持的就是异类甚至毒瘤？

我是支持关键字驱动的，而且用例用过 Excel 和 MySQL 管理，没觉得有什么不方便；但是也不妨碍我觉得 page object 的方式也很好，说不定下个项目有机会也尝试一下。

与虫师观点高度契合。

我其实是很鄙视读取数据文件的操作的，因为真get不到它的“方便”之处，做自动化测试写代码就老老实实的写代码，就你测试用的这点数据，真没必要读取文件，数据库就更谈不上了。

关闭是不小心误点，我正在等待大神过来怼我呢！

赞同。

一个 for 循环确实可以搞定测试过程中许多问题。

我没说要读取数据库，UI 自动化的参数化是有多少数据量要存数据库？ 怕不是和性能测试搞混了吧！先初始化几万条测试数据。

无非就是循环读取二维数组简单东西。

我有一个系统。

登录功能：用户名、密码、

注册功能：用户名、密码、重复密码

A 搜索功能：名称

A 添加数据：名称、描述、状态。

B 填写卡号： 银行卡号。

c 填写收件地址：手机号、详细地址、邮编。

.....

有十几个需填写不同数据的 “表单” 不过份吧！

来！来！大家思考一下用，用 excel 能不能存，存了怎么取？ 注意我每个功能用的数据不一样！

别关闭讨论，虫师，当年我还买过你的书，我以前写的接口自动化，就是 excel 维护的，不过所有测试数据全是自动化生成的

注意看我吐槽的点：

1、用表格存参数化测试数据。

2、用表格存元素定位。

我没说用表格写测试用例，用表格写测试用例做的比较好好的是 robot Framework 框架，不过，我依然觉的 robot Framework 现在并没有受到多少公司的欢迎。如果稍微 python 语言用的比较熟悉的同学大多不愿意用它，对比 robot Framework 和直接用 python 实现一个 for 循环就不想用 RF 了，当然，那些新手看到 RF 依然会激动不已，看！不写代码，一样可以做自动化。

lz 可以不止是吐槽，顺便也说一下你推荐的方式吗？

开发会觉得数据驱动测试简直是 xx；其实我也是这么想的

是 cnblogs 的哪位虫师吗？

同样不看好用 Excel 维护用例。

1. 懂代码是我们的本分工作，许多时候用代码编写测试用例是最简单的事情，而不是使用 Excel 维护自动化用例。
2. 用 Excel 维护 100 条测试用例没有什么技术含量。测试周期为一个月的项目产生几千条自动化测试用例是常见的。
3. 用 Excel 维护用例受限于测试框架，也不便于业务流程的梳理。一个自动化测试脚步里面包括了业务相关的知识，可以加注释，能够很快了解业务流、数据流等知识。

因为这样的文章很多，培训很多。
自主学习能力欠佳
还有记住，技术本无罪

CSV 还好吧，DataFrame 支持读写，数据集很多用 CSV 的。。。。

我记得虫师去年还专门怼过 sweetest 这个框架呢。
可惜人家下架了、

这个文风和语气…… 感觉和印象中写自动化系列博客的虫师有点不一样

因为这种解决框架简单，难度成本低。读 excel low，那读 mysql 你觉得 low 不 low？读 redis 读 mongodb 呢？无非就是循环读取二维数组简单东西，是不是 excel 永远不是重点。

最近也是挺烦恼这件事情的，现在的自动化测试项目里面很多环境变量，测试数据是通过配置文件配置的（xml），以至于我的自动化项目现在对接 jenkins 自动打包流程时，时常因为需要改某些测试参数而重新提交一次代码，正在打算把配置数据迁移到云端（apollo)。
当然我还是希望楼主在评论一种方法的好坏之时，除了能够指出不足，也能够分享一下自己的解决方案（比如测试数据的存储，读取）。

之前在一两个小项目里用过一个框架，就是简单用 Excel 维护关键字驱动的测试用例。
我的使用场景： 在客户现场的一台内网服务器， 简单部署了这个框架，在 Excel 里维护了大约一百多条用例。
为啥不用数据库维护？ 因为想做到资源最小化，因为现场的服务器只是一台 win pc，要是只为这个工具安装个数据库就太麻烦了；
用例维护麻烦吗？ 因为是小项目，只有自己在用，不存在多人读写 Excel 的问题； 而且 Excel 里复制用例、批量查找替换等功能其实挺方便。

能大致说下理由吗，我也隐约觉得表格限制很大，正在改用 yaml，就是不知限制到底有多大

现在动不动的框架就是一门开发语言 + 相关单元测试框架 +excel+ 报告输出 + 关键字驱动数据驱动, 简直了