关键词驱动 to be or not to be?
作者：lifr
首先我抛砖引玉，表明我的观点：我不赞成 关键词驱动 的测试。
套用一句话是：Make everything as simple as
possible, but not simpler. -- Albert
Einstein
我曾经开发过一个测试框架，试图提供一种能力把测试逻辑用xml的tag表达出来。我做了大量的工作来把测试中的action用tag封装起来，在给team
member使用后发现，它并不那么受欢迎。原因是
1）熟悉tag是一个负担，特别是tag多了以后，
2）tag的表达能力有限，有些情况不能满足需要。如果要满足需要，甚至需要引入条件判断的tag。后来我想，如果要使用一个<if>
tag，为什么不直接使用编程语言呢？
更有甚者，我曾经看到过一个测试框架，它把最简单的用户动作封装为xml
tag。开发框架的初衷是 XML描述testcase 提供灵活性。但结果是，往往一个简单的testcase，就导致长长的xml文件。维护xml文件成了问题。
我认为最佳选择是
脚本语言的framework + script.
一门高效易学的脚本语言 ＋ 设计精良的Framework
来写测试脚本是在灵活性和易用性之间的最佳平衡点。脚本语言里面的python,
ruby都是上上之选。好的framework提供的API能让script的开发象写关键词一样简单。关键是，同时它还提供了程序设计语言无限的灵活性。
最后还有一点，自动化测试框架用户是谁？是QA
Engineer，是专业人士。即使是只做manual testing的 QA Engineer都乐意学习一门脚本语言，因为这对他们自己的提高也有好处。
所以，数据驱动是一个非常棒的测试方法。但要在数据里加上
关键字或者流程控制。。。过犹不及也，且不说实现它需要额外的投入，学习这些越来越多的关键字会让QA失去对他最后的耐性。
1、SQL 查找存在某内容的存储过程都有哪些
2、ST.时间
3、设计模式(Python)-观察者模式
4、1.13.3
5、Linux基本常识