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

[ 本帖最后由 lifr 于 2007-7-28 10:38 编辑 ]

lantianwei

无意看到本文，很感兴趣就来看看。
本人有和LZ不同的意见，我觉得KEYWORD还是有他的优点的，比如数据驱动是对函数级的操作，而数据驱动则是对单个动作的操作，可见灵活性增加了，复用性提高了，开发测试的时间减少了（在关键字驱动的后期）等，当然它也有缺点，比如前期的开发工作量大，技术难度高等。但我想它的优点不管怎样还是胜过缺点的，在国内大部分企业无法实施关键字驱动，不是技术问题，而是环境的问题，国内测试行业没有一个非常规范的标准，实施起来烦琐，有可能将导致成本的提高而非降低。
以上是本人的漏见，如有不足，还请高手指正！