• 软件测试技术
  • 软件测试博客
  • 软件测试视频
  • 开源软件测试技术
  • 软件测试论坛
  • 软件测试沙龙
  • 软件测试资料下载
  • 软件测试杂志
  • 软件测试人才招聘
    暂时没有公告

字号: | 推荐给好友 上一篇 | 下一篇

关键词驱动 to be or not to be?

发布: 2009-5-24 18:54 | 作者: LIFR | 来源: 测试时代采编 | 查看: 33次 | 进入软件测试论坛讨论

领测软件测试网 套用一句话是: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失去对他最后的耐性。

延伸阅读

文章来源于领测软件测试网 https://www.ltesting.net/

TAG: 驱动 关键词 not


关于领测软件测试网 | 领测软件测试网合作伙伴 | 广告服务 | 投稿指南 | 联系我们 | 网站地图 | 友情链接
版权所有(C) 2003-2010 TestAge(领测软件测试网)|领测国际科技(北京)有限公司|软件测试工程师培训网 All Rights Reserved
北京市海淀区中关村南大街9号北京理工科技大厦1402室 京ICP备10010545号-5
技术支持和业务联系:info@testage.com.cn 电话:010-51297073

软件测试 | 领测国际ISTQBISTQB官网TMMiTMMi认证国际软件测试工程师认证领测软件测试网