关键词驱动 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失去对他最后的耐性。