将机器人框架用于ATDD [英] Using Robot Framework for ATDD
问题描述
我想听听其他人对Robot Framework进行自动验收测试的经验.
它的主要优点和缺点是什么，以及与其他框架(主要是Fitnesse和Selenium)的比较?
将要测试的代码是实时的旧代码，主要是C ++.
在撰写本文时，我已经在三家不同的公司使用了Robot Framework，跨越了大约六年的时间，所有这些都以一种或另一种方式获得了成功./p>
我的经验
公司1
我使用Robot的第一个地方是一家顶级互联网旅游公司的基于Java的Web应用程序.我们将Robot与Jython结合使用，这使我们可以用Java创建关键字并直接与被测系统配合使用.我们使用Selenium来驱动Web浏览器，而我们的大多数测试都在Firefox上进行.尽管质量保证组织的测试工作在很大程度上取得了成功，但是开发组织却没有接受它-他们更喜欢使用JUnit而不是Robot.
公司2
我觉得我的第二家公司取得了无与伦比的成功.我们以多种方式使用了Robot.主要用途是驱动Internet Explorer对高度成功的商业.NET Web应用程序进行接受和回归测试.
我们还通过将Selenium与 Appium 结合使用来测试iPad应用程序.我们使用Robot来测试为应用程序提供数据的RESTful服务.我们编写了专门的关键字来进行图像分析，并且在每次培训之前，我们还使用了机器人测试对我们的培训设备进行了快速分析.我们有关键字，可以让我们在测试前为数据库快照，并在测试后恢复数据库.
我们还开始使用Robot帮助进行手动测试.我们将手动测试用例放到了Robot中，这使我们能够利用Robot的报告和标记功能.当这些测试运行时，它们会提示用户执行手动步骤，事实证明，这些步骤比我们让测试人员从测试用例管理工具或Word文档中读取手动步骤要有效得多.
公司3
第三家公司是一家大型公司(收入10亿美元)，拥有相当多的IT员工.他们的测试人员技术水平很低(我记得一个人不知道命令行是什么).我们有一个团队致力于编写一组核心关键字，并为其他团队提供培训和指导.我认为，使用Robot有助于从技能最差的测试人员那里获得一定的使用机会，尽管即使使用了高级关键字，这对他们来说也是一个挣扎.
公司4
最近，我搬到一家很小的公司，只有几个开发人员，没有专门的测试人员.我们欢迎将页面对象与机器人一起使用框架，现在我们有了一套非常稳定的易读高级验收测试套件.在这家公司使用Robot取得了无与伦比的成功.
优势
机器人的最大优势在于它的灵活性.我们已经使用Robot来支持手动测试，SOAP和REST服务测试，基于Web的UI测试，数据库测试，图像测试以及移动应用程序测试.由于Robot很容易使用附加库进行扩展，因此如果您愿意袖手旁观并编写一些关键字，几乎没有什么可以测试的.根据您的设置，您可以通过Robot远程API用Python，Java，.NET或几乎任何一种语言编写关键字.
由于机器人测试用例和关键字是用纯文本编写的，因此您不必局限于使用专有工具来创建或查看测试.用户可以选择他们所选择的工具-Visual Studio，Eclipse，Emacs，记事本等.还有一个特定于机器人的IDE(RIDE)，尽管我不建议这样做.此外，由于文件是纯文本格式，因此可以与其他软件工具很好地集成在一起-易于区分和合并，搜索等.
弱点
机器人使编写低质量的测试变得容易.虽然提供了记录关键字和测试用例的工具，并为关键字，测试用例和变量使用了易于理解的名称，但是没有实施最佳实践的好方法.编写大量的测试和关键字需要纪律.俗话说，机器人为您提供了很多绳子供您垂吊.
另一个缺点是，Robot的进度相当缓慢.从好的方面来说，Robot功能强大且相对没有漏洞，因此对频繁的补丁程序的需求不大.但是，有些功能请求在其问题跟踪器中持续多年没有移动，这令人沮丧.
摘要
在所有公司中，我们都很高兴能够利用Robot语法提供的灵活性来创建数据驱动的测试，BDD样式的测试以及简单的过程测试.而且在所有情况下，由于测试都是纯文本文件，因此可以使用我们的SCM工具(Mercurial，Subversion和Git)轻松管理测试资产
对我来说，Robot已被证明易于使用，非常易于扩展，并且对于从Python函数的单元测试到Web服务，基于浏览器的和平板电脑UI的测试等广泛的测试任务非常有用.测试，图像测试，数据库测试，甚至提高了手动测试的效率.
I would like to hear other people's experience with Robot Framework for automated acceptance testing.
What are its major strengths and weaknesses as well as any comparison with other frameworks (mainly Fitnesse and Selenium)?
The code that will be tested is real-time, legacy code, mainly in C++.
I have used Robot Framework at three different companies spanning about six years at the time that I write this, and all have been successful in one way or another.
My experiences
Company 1
The first place I used Robot was a Java-based web application for a top-tier Internet travel company. We used Robot with Jython, which let us create keywords in Java and directly act with the system under test. We used Selenium to drive the web browser, with most of our testing being on Firefox. While the testing effort was largely successful with the QA organization, the development organization failed to embrace it -- they preferred to use JUnit rather than Robot.
Company 2
My second company I feel was an unqualified success. We used Robot in a multitude of ways. The primary use was to drive Internet Explorer for acceptance and regression testing of a highly successful commercial .NET web application.
We also used it to test an iPad app by combining Selenium with Appium. We used Robot to test the RESTful services that supplied data to the app. We wrote specialized keywords that let us do image analysis, and we also used Robot tests to do quick analysis of our training equipment before each training session. We had keywords that let us snapshot a database before a test, and to restore the database after a test.
We also started using Robot to help with manual testing. We put manual test cases in Robot, which let us leverage Robot's reporting and tagging features. When these tests would run, they would prompt the user to perform manual steps which was proven to be much more efficient than when we had testers reading manual steps out of a test case management tool or Word document.
Company 3
The third company was a large company ($1B revenue) with a fairly large IT staff. They had testers with very low technical skill (I remember one who had no idea what a command line was). We had one team dedicated to writing a core set of keywords, and to providing training and mentoring to the other teams. I think the use of Robot was instrumental in getting some use out of the least-skilled testers, though even with high level keywords it was a struggle with them.
Company 4
Most recently I moved to a very small company with just a handful of developers and no dedicated testers. We embraced the use of page objects with Robot Framework, and we now have an exceptionally stable suite of easily readable high level acceptance tests. The use of Robot at this company has been an unqualified success.
Strengths
The biggest strength of Robot is its flexibility. We've used Robot to support manual testing, testing of SOAP and REST services, web-based UI testing, database testing, testing of images, and the testing of mobile apps. Because Robot is so easy to extend with additional libraries, there's almost nothing you can't test if you're willing to roll up your sleeves and write some keywords. Depending on your setup, you can write keywords in Python, Java, .NET, or really just about any language through the Robot remote API.
Because Robot test cases and keywords are written in plain text, you're not locked in to using a proprietary tool to create or view tests. Users are able to pick the tool of their choice -- Visual Studio, Eclipse, Emacs, Notepad, etc. There is also a Robot-specific IDE (RIDE), though I don't recommend it. Also, because the files are plain text, they integrate well with other software tools -- they are easy to diff and merge, to search, etc.
Weaknesses
Robot makes it easy to write low-quality tests. While there are facilities to document keywords and test cases, and to use human-readable names for keywords, test cases and variables, there's no good way to enforce best practices. Writing a large body of tests and keywords requires discipline. As the saying goes, Robot gives you plenty of rope to hang yourself with.
Another weakness is that the pace of progress on Robot is fairly slow. On the plus side, Robot is robust and relatively bug free, so there's not a big need for frequent patches. However, there are feature requests that languish in their issue tracker for years with no movement, which can be discouraging.
Summary
In all companies we've enjoyed being able to leverage the flexibility provided by Robot's syntax to create data-driven tests, BDD-style tests, as well as simple procedural tests. And in all cases, because the tests are plain text files, the test assets were easy to manage with our SCM tools (Mercurial, Subversion, and Git)
For me, Robot has proven to be easy to use, extremely easy to extend, and useful for a wide range of testing duties, from unit-testing of Python functions, to testing of web services, browser-based and tablet UI testing, the testing of images, the testing of databases, and even to improve the efficiency of manual testing.
这篇关于将机器人框架用于ATDD的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
