使用机器人框架ATDD

我想听听其他人使用Robot Framework进行自动验收测试的经验.

它的主要优点和缺点是什么,以及与其他框架(主要是Fitnesse和Selenium)的任何比较？

将要测试的代码是实时遗留代码,主要是在C++中.

在我写这篇文章的时候,我已经在三个不同的公司使用过Robot Framework,大约六年,并且所有公司都以这种或那种方式取得了成功.

我的经历

公司1

我使用Robot的第一个地方是一个基于Java的Web应用程序,用于顶级互联网旅游公司.我们在Jython中使用了Robot,它允许我们用Java创建关键字并直接对被测系统起作用.我们使用Selenium来驱动Web浏览器,我们的大多数测试都在Firefox上.虽然测试工作在QA组织中取得了很大的成功,但开发组织却没有接受它 - 他们更喜欢使用JUnit而不是Robot.

公司2

我觉得我的第二家公司是一个无条件的成功.我们以多种方式使用机器人.主要用途是驱动Internet Explorer以接受和回归测试非常成功的商业.NET Web应用程序.

我们还通过将Selenium与Appium结合使用它来测试iPad应用程序.我们使用Robot来测试向应用程序提供数据的RESTful服务.我们编写了专门的关键词让我们进行图像分析,并且我们还使用机器人测试在每次训练之前快速分析我们的训练设备.我们有关键字让我们在测试之前为数据库创建快照,并在测试之后恢复数据库.

我们也开始使用Robot来帮助进行手动测试.我们在Robot中放置了手动测试用例,让我们可以利用Robot的报告和标记功能.当这些测试运行时,它们会提示用户执行手动步骤,这些步骤被证明比我们让测试人员从测试用例管理工具或Word文档中读取手动步骤时更有效.

公司3

第三家公司是一家大型公司(收入10亿美元),拥有相当大的IT员工.他们有测试人员提供非常低的技术技能(我记得有一个谁不知道什么是命令行了).我们有一个团队致力于编写一组核心关键词,并为其他团队提供培训和指导.我认为使用Robot对于从最不熟练的测试人员中获得一些帮助是有帮助的,尽管即使使用高级别的关键字也是与他们的斗争.

公司4

最近,我搬到了一家非常小的公司,只有少数开发人员,没有专门的测试人员.我们接受了使用Robot Framework 的页面对象,现在我们拥有一套非常稳定的易读性高级验收测试套件.在这家公司使用机器人取得了无可比拟的成功.

优势

Robot的最大优势在于其灵活性.我们使用Robot来支持手动测试,SOAP和REST服务的测试,基于Web的UI测试,数据库测试,图像测试以及移动应用程序的测试.因为Robot很容易扩展其他库,所以如果你愿意卷起袖子并写一些关键词,几乎没有什么是你无法测试的.根据您的设置,您可以通过Robot远程API以Python,Java,.NET或任何语言编写关键字.

因为Robot测试用例和关键字是用纯文本编写的,所以您不会被锁定使用专有工具来创建或查看测试.用户可以选择他们选择的工具--Visual Studio,Eclipse,Emacs,Notepad等.还有一个特定于机器人的IDE(RIDE),但我不推荐它.此外,由于文件是纯文本,它们与其他软件工具很好地集成 - 它们很容易混合和合并,搜索等.

弱点

机器人可以轻松编写低质量的测试.虽然有记录关键字和测试用例的工具,并且对关键字,测试用例和变量使用人类可读的名称,但没有好的方法来强制执行最佳实践.编写大量测试和关键字需要遵守纪律.俗话说,机器人为你提供了足够的绳索.

另一个缺点是机器人的进展速度相当缓慢.从好的方面来说,Robot非常强大并且相对没有bug,因此不需要频繁的补丁.然而,有些功能请求在其问题跟踪器中徘徊多年,没有任何移动,这可能令人沮丧.

摘要

在所有公司中,我们都很高兴能够利用Robot语法提供的灵活性来创建数据驱动的测试,BDD风格的测试以及简单的程序测试.在所有情况下,因为测试是纯文本文件,所以使用我们的SCM工具(Mercurial,Subversion和Git)可以轻松管理测试资产

对我来说,Robot已被证明易于使用,非常容易扩展,并且可用于广泛的测试任务,从Python功能的单元测试,到Web服务测试,基于浏览器和平板电脑的UI测试,测试图像,测试数据库,甚至提高手动测试的效率.

我们已经在我的工作地点使用机器人框架已经有一年多的时间了,并取得了一定的成功.像海报一样,我们也做C++工作.我们花了一些时间来评估Robot对抗Fitnesse/Slim,当时两种解决方案都很好,但决定因素是(截至2009年):

机器人及其报告如何扩展到大型项目更加清晰

如何版本控制Fitnesse工件并不明显

从技术角度来看,我们一直在使用SWIG来桥接Robot和C++.我们将测试夹具包装在SWIG中并将其与测试中的生产代码链接 - 为我们提供一个可以由Robot导入的python模块.

我们几乎完全使用.txt格式的机器人输入 - 我们发现这个版本控制得更好,更容易阅读,我们只是没有使用HTML的高级功能(这是我们开始的地方).另外,我们也使用"BDD Style" Robot语法.我们使用GoogleMock和一些包装器来帮助我们设置在每个机器人测试的拆解期间检查的期望.

至于组织测试,我们已经采用了以下方法(灵感来自Dale Emery的方法):

主要功能层次结构由文件夹结构表示.

机器人测试文件名中描述了特征尺寸的东西.

机器人测试用例名称使用该功能的每个部分的描述.

作为测试用例中的步骤给出了一个例子.

示例文本使用Robot"keywords"分解为步骤.

测试夹具驱动生产代码.

例如,手机可能有这样的东西:

//  PhoneProject/MakingCalls/DialAPhoneNumber.txt

*** Test Case ***
A user can dial a US number with an area code, up to 10 digits
   Given a phone without any numbers dialed
   Expect the attempted phone number to be 123-456-7890
   When a user enters the numbers 1234567890


// A separate MakingCallsKeywords.txt or something similar
*** Keyword ***
Given a phone without any numbers dialed                CreateNewDialer
Expect the attempted phone number to be ${phoneNumber}  ExpectDialedNumber  ${phoneNumber}
When a user enters the numbers ${numbersEntered}        DialNumbers ${numbersEntered}

// MakingCallsFixture.cpp  (which gets wrapped by SWIG)

std::wstring MakingCallsFixture::DialNumbers(const std::wstring& numbersEntered)
{
   ... Drive production code ...
}

// CreateNewDialer, ExpectDialedNumber also go here

然后我们将其与覆盖角落条件的单元测试配对(例如,确保不超过10位数) - 或者这可能是另一个验收测试(可执行规范),具体取决于谁正在阅读测试以及他们对测试的熟悉程度.域.

我们创建这些规范的草稿,并在开始工作之前与领域专家和团队一起审核.这有助于尽早消除一些误解.