啄木鸟软件测试培训网：
本文来自：
软件测试网采编
0. 不讨论什么
我们不讨论那种简单的自动化脚本，用来帮助QA对某个，或某几个testcase进行
；这样的脚本往往用来代替手工执行testcase里的某些步骤，比如一个在
里产生数据的
脚本。又比如根据testcase录制了10个
脚本，通过replay这些脚本就能完成这个testcase的测试。这种自动化脚本几乎没有任何弊端，它短小和贴近testcase，没有多大的开发开销，它几乎总是能带来测试效率的提高，如果有可能，完全应该去做。
我们也不讨论
。性能测试几乎总是要自动化的，但它和
有太多的不一样。
当然，也不要包括
(white-box)，虽然它的概念可以在功能测试中借鉴，也就是功能单元测试。
自动化测试
框架，都指针对功能的自动化测试框架。
如果让我来定义自动化测试框架，那么它的核心应该是这样一个东西：它提供一套API，这套API对产品的操作做一个包装并提供一个的精简的集合。通过这套操作集合，几乎所有（当然不可能100%)的testcase对产品的操作步骤都可以对应到对这套API的调用。也就是框架提供了一个 ‘产品’ 和 ‘测试脚本’ 的中间层，。一个好的测试框架，可以让自动化脚本看起来象人类语言描述的testcase一样清晰。
假设我们已经有了这样一个测试框架，我们来看它能带来那些好处
1) 首先得益的是smoke
, smoke test总是和DailyBuild联系起来。有严重问题的build当天早上就能发现，不会release给QA。
2) 如果大部分的功能测试都可以被自动化。那么regression test就可以自动化起来。regression test其实是非常非常枯燥但有不得不做的。也许一整天的测试，只是验证了“新的build通过了所有的这些testcase”。如果以bug的数量来衡量QA的
的话，那么就更令人伤心了。
3) 新功能的测试被翻译为自动化脚本，并加入regression test suite中。庞大的regression test会给QA巨大的信心。
3. 自动化永远不能代替手工测试
一定要认识到： 自动化永远不能代替手工测试。
1) 有些验证根本没法通过程序来验证，或验证起来非常困难，比如程序启动的速度。
2) 在新feature的测试阶段，testcase只能发现30%的defect。但自动化脚本只能基于testcase，所以对新feature的测试，我觉得应该禁止自动化测试。
4. 你需要自动化测试框架吗？
我认为，只要是做产品，都需要这样一个测试框架。测试框架连同它的测试脚本和产品一样都有一个一个的release。好的测试框架会一直伴随产品，为它保驾护航。
有很多搞自动化测试最后失败的公司，这里的失败是指最后放弃了自动化测试。我看到的原因一般是
1) 测试员抱怨框架太难用，在上面开发自动化脚本很耗时
2) 产品变化太大(GUI衰退，学术名字*_~)，要花很多精力和时间来改写测试框架
3) 产品变化太大，很多辛苦开发的自动化脚本在下一个release的产品中不能跑起来
6. 避免失败
那就是高质量的自动化测试框架。
好的框架必须是易于使用的。
好的框架，作为中间层，会尽量减少产品UI的变化对测试脚本的影响。有一句话说在自动化框架的设计中：即使点击一个button都需要写一个函数来包装。这种极端的指导思想来源于下面的考虑：也许这个button会再下一个版本会改成一个link。
好的框架，自身抵抗变化的能力也很强，这要求框架本身是一个设计优良的软件。
7. 如何才能获得高质量的自动化测试框架
如果我们准备开发一个自动化测试框架，我认为需要注意
1） 选择一位精通程序设计和
的开发人员。
一种误解是自动化测试开发只需要普通的测试人员参与就可以了。我不是否定测试人员的能力，而是测试框架开发完完全全是软件的开发。甚至更高一级，相对于软件库的开发，比如它对接口设计和易用性上的要求就相当高。
然后这位开发人员还必须是本软件测试方面的专家，也就是领域专家。有很多软件失败于需求分析，你当然不希望这种事再这里重演。
2） 合适的开发工具
现在商业和开源的开发工具都为数不少。不过我认为在选择的时候要注意两点1）用record&replay来鼓吹易用性的软件。他们也许是好软件，但不是开发测试框架的好软件。框架开发要求工具有强大的功能和灵活性。2）最好选用使用通用语言来开发的软件。通用语言一般都有各种各样的库。我就为用robot的scrīpt来访问mysql的问题相当恼火。
8. 开发自动化测试框架的一些建议
下面是我在开发框架核心API部分中的一些经验
1) 尽量把让测试脚本访问你的API而不是直接操控UI元素。
这即使不是绝对的，也要尽力避免。把变化留给框架。因为我们注意到，产品UI的变化频率和程度都超过功能的变化。UI变化，功能测试的逻辑不会变化，而功能测试在所有的测试中一般是占主要的部分。
2) 针对不同类型的测试，提供多套API
前面说过最好把测试脚本和UI操作完全隔离开来，但考虑到测试的多样性，这往往导致存在多套不同层次的API。
比如一个添加用户的
页面。针对这个页面的基本功能需要提供一个方法: addUser(name, pswd)。大多数testcase都会调用这个方法作为一个其中的步骤。
假如输入的name具有非法字符检查功能,系统会用javascrīpt及时检查用户输入并在某个页面某个位置把错误信息显示出来。要测试这个功能，上面的方法就不够了。这个时候就需要针对这个页面封装一个页面模型(page model),通过这个页面模型可以访问页面的元素比如
getNameInputBox
getErrorMessage
显然这是两套不同的API，应该分别属于不同的集合。而且最好两套API不要有依赖。
3) 保持框架和测试逻辑分离
API不要包含任何测试逻辑的代码。API是精简，正交的。不要试图提供一些和测试逻辑相关的功能来使得某几个测试脚本更好开发，它反而真正伤害了API。
比如我曾经把验证from里各项数据的方法加到了API里。其实我应该做的是把form里的数据收集出来，以Map的形式返回给调用者。
4) 最好边开发框架，边开发一个精简的regression test suite。
这样能让你早发现框架存在的问题
5) 在release你的API之前，一定要给QA 小规模试用
API发布后就不能更改，所以发布API要谨慎小心。
8. 提外话：关键字驱动的自动化测试
套用一句话是：
Make everything as simple as possible, but not simpler. -- Albert Einstein
我曾经开发过一个测试框架，试图提供一种能力把测试逻辑用xml的tag表达出来。我做了大量的工作来把测试中的action用tag封装起来，在给team member使用后发现，它并不那么受欢迎。原因是
1）熟悉tag是一个负担，特别是tag多了以后，
2）tag的表达能力有限，有些情况不能满足需要，如果要满足需要，tag变得非常复杂。甚至需要引入条件判断的tag。后来我想，如果要使用一个&if& tag，为什么不直接使用编程语言呢？
所以，我认为一门高效易学的脚本语言来写测试脚本是在灵活性和易用性之间的最佳平衡点,python, ruby都是上上之选。关键字驱动？太过了，且不说实现它需要而外的投入，学习这些越来越多的关键字会让QA失去对他最后的耐性。
数据驱动是一个非常棒的测试方法。但要在数据里加上 关键字或者流程控制。。。过犹不及也。
我的淘宝课：
/item.htm?spm=.0.QQT3Ey&id=&buyerDetail=true
顾翔凡言：
科学研究再如何努力也就最多了解到万分之一的宇宙本质。
啄木鸟软件测试培训中心，主打五门课：
，你也想成为软件测试工程师吗～软件测试基础教程
，软件测试工程师必须掌握的技能～软件测试设计方法实战。
，让你的程序跑得更快～软件性能测试
，让你找出更多的
～探索式软件测试
，让用户迷上你的产品～用户体验式测试
本文来自微信公众账号提交，由微讯啦收录，转载请注明出处。
微信扫码 分享文章966,690 十月 独立访问用户
语言 & 开发
架构 & 设计
文化 & 方法
您目前处于：
自动化测试框架Cucumber和RobotFramework的实战对比
自动化测试框架Cucumber和RobotFramework的实战对比
刘冉 崔力强
支持表格参数14
支持多种格式的Report：html、junit etc.
支持多种语言
支持四种状态的测试步骤15：Passed、Failed、Skipped、Pending
支持使用变形器消除重复16
一个商用的在线Cucumber系统：Cucumber Pro17
使用关键字的机制，更容易上手
提供了RIDE，对于不熟悉编码的人来说比较友好
能够精细的控制关键字的scope19
Log和Report非常好20
使用变量文件的机制来描述不同的环境21
丰富的关键字库22
内置变量23
缺乏类似RIDE对纯测试人员友好的专用工具
不支持类似于Cucumber中的表格参数14
使用Jython版本测试运行启动慢
Jenkins支持
高效-Jetbrains系列的IDE
高效-RIDE和Jetbrains系列的IDE
三、测试工具选择的一般性原则
在上述的实战案例中，针对项目的具体情况我们对Cucumber和RobotFramework这两种工具进行了取舍。本节就来总结一下这些取舍的考虑因素。
首先来看一下自动化验收测试的层次：
然后对每层进行分析：
最下面是被测系统，需要明确它的形态，比如是Web系统、REST系统或者特定协议系统。
中间是测试库。比如Selenium、SSH、Scapy等，有了它们用例才能和被测系统进行交互，所以需要根据被测系统的形态来选择相应地测试库。该层的选择需要考虑几个因素：
测试库的易用程度。
测试库是否有良好的商业或者开源社区的支持。
团队成员是否熟悉测试库使用的编程语言。
最上层则是测试框架，也就是Cucumber和RobotFramework这一层。其作用包括用例管理、测试数据管理、测试运行、测试报告等。该层的选择需要考虑几个因素：
这一层会通过函数调用的方式和测试库打交道，因此测试框架必须支持测试库所使用的编程语言。
是否提供易用的测试用例开发环境，比如是否有如RIDE这样的专用工具，或者Intellij的IDE的插件。
引入某个测试框架之后对现有工作模式的影响程度，比如让不懂编程的测试人员写代码。
以上这些点是从RobotFramework和Cucumber的对比中总结出来的，但如果你想要选择这两者之外的其他框架，同样可以考虑上述这些原则。
我们在银行、保险、社交、电信、物流、互联网等项目上实施过自动化功能以及验收测试。对于Cucumber和RobotFramework到底属于ATDD还是BDD，这里不做过多的讨论，因为当前在业界对于ATDD和BDD怎么区分还有一些争议，而对于我们来讲，它们只不过是两个名词而已。对于这两个工具本身来讲，只需要清楚它们各自的特点，根据项目本身的情况和需求选择就可以了，简单地说就是：知行合一。
刘冉，现任ThoughtWorks高级软件质量咨询师, 超过10年软件开发和测试工作工作经验。最熟悉的领域是嵌入式系统开发、Linux系统开发、各种脚本、各种测试工具、各种自动化测试系统开发、以及Agile中的QA。其中对于服务器性能测试，Web功能测试，以及测试分层一体化解决方案有较深的理解。现在关注于全方位自动化QA的工作，以及对于Agile流程中怎么实现统一的流程、故事、功能、测试和文档管理，以及质量控制度量。
崔力强，现任ThoughtWorks公司高级咨询师。具有多年Java与Ruby的开发经验，最近两年的主要工作是在客户现场指导客户团队的开发与改进。在遗留代码重构、领域驱动设计、自动化测试的引入与推进方面有着丰富的经验。
感谢对本文的策划，对本文的审校。
给InfoQ中文站投稿或者参与内容翻译工作，请邮件至。也欢迎大家通过新浪微博（）或者腾讯微博（）关注我们，并与我们的编辑和其他读者朋友交流。
Author Contacted
相关厂商内容
相关赞助商
告诉我们您的想法
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
Re: hmm...
Yanqing Yang
Re: hmm...
Re: hmm...
Re: hmm...
&不支持类似于Cucumber中的表格参数&？？？
Shen Jacky
Re: &不支持类似于Cucumber中的表格参数&？？？
Re: &不支持类似于Cucumber中的表格参数&？？？
Miku Ariman
Re: &不支持类似于Cucumber中的表格参数&？？？
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
赞助商链接
InfoQ每周精要
通过个性化定制的新闻邮件、RSS Feeds和InfoQ业界邮件通知，保持您对感兴趣的社区内容的时刻关注。
架构 & 设计
文化 & 方法
<及所有内容，版权所有 &#169;
C4Media Inc.
服务器由 提供, 我们最信赖的ISP伙伴。
北京创新网媒广告有限公司
京ICP备号-7
注意：如果要修改您的邮箱，我们将会发送确认邮件到您原来的邮箱。
使用现有的公司名称
修改公司名称为：
公司性质：
使用现有的公司性质
修改公司性质为:
使用现有的公司规模
修改公司规模为：
使用现在的国家
使用现在的省份
Subscribe to our newsletter?
Subscribe to our industry email notices?
我们发现您在使用ad blocker。
我们理解您使用ad blocker的初衷，但为了保证InfoQ能够继续以免费方式为您服务，我们需要您的支持。InfoQ绝不会在未经您许可的情况下将您的数据提供给第三方。我们仅将其用于向读者发送相关广告内容。请您将InfoQ添加至白名单，感谢您的理解与支持。类似于IBM的STAF
更新，最近研究了Thoughtworks的新框架Gauge，感觉比Robot更加有发展前途，不说他们维护的很勤快，架构也比Robot合理的多，所以实现多进程分发机制很容易。而且用TCP hook的方式加入插件机制也很好，这个目前只是beta，我已经喜欢到把我整个架构都推倒了迁移到Gauge上。看了下Python语言的实现也弄懂了如何和Gauge服务器通信，以后自己扩展也无比方便了。=======================Selenium怎么都不算自动化测试框架啊。Robot Framework可以算一个，提供了强大的关键字驱动和BDD，关键是我已经用Python上瘾了无法自拔了，再也不想用回Java。而且我自己写测试库，灵活性很高，关键那个报告太漂亮。唯一的缺点这货是单进程的，不过可以自己调用Robot的API实现多进程，也不是什么困难的事。还有一个Fitnesse应该也不错，不过我没用过，只是看别人用过一下。
如果是Linux系统，推荐：&a href=&///?target=http%3A//autotest.kernel.org& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&autotest.kernel.org&/span&&span class=&invisible&&&/span&&i class=&icon-external&&&/i&&/a&，有Web的，也有命令行的。
如果是Linux系统，推荐：，有Web的，也有命令行的。
已有帐号？
无法登录？
社交帐号登录
懒惰驱动测试开发