关键词驱动 to be or not to be?
套用一句话是:Make everything as simple as possible, but not simpler. -- Albert Einstein 我曾经 开发 过一个 测试 框架,试图提供一种能力把测试逻辑用xml的tag表达出来。我做了大量的工作来把测试中的action用tag封装起来,在给team member使用后发现
套用一句话是: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失去对他最后的耐性。
原文转自:http://www.ltesting.net