【发布时间】:2011-02-20 17:47:26
【问题描述】:
我想听听其他人使用 Robot Framework 进行自动化验收测试的经验。
它的主要优点和缺点是什么以及与其他框架(主要是 Fitnesse 和 Selenium)的比较?
将要测试的代码是实时的遗留代码,主要是 C++。
【问题讨论】:
-
你最后做了什么?
标签: c++ selenium tdd robotframework
我想听听其他人使用 Robot Framework 进行自动化验收测试的经验。
它的主要优点和缺点是什么以及与其他框架(主要是 Fitnesse 和 Selenium)的比较?
将要测试的代码是实时的遗留代码,主要是 C++。
【问题讨论】:
标签: c++ selenium tdd robotframework
在撰写本文时,我已在三家不同的公司使用 Robot Framework,时间跨度约为六年,并且都以某种方式取得了成功。
我第一次使用 Robot 是为一家顶级互联网旅游公司开发的基于 Java 的 Web 应用程序。我们将 Robot 与 Jython 一起使用,这让我们可以在 Java 中创建关键字并直接与被测系统进行操作。我们使用 Selenium 来驱动 Web 浏览器,我们的大部分测试都是在 Firefox 上进行的。虽然 QA 组织的测试工作在很大程度上取得了成功,但开发组织未能接受它——他们更喜欢使用 JUnit 而不是 Robot。
我觉得我的第二家公司非常成功。我们以多种方式使用机器人。主要用途是驱动 Internet Explorer 对非常成功的商业 .NET Web 应用程序进行验收和回归测试。
我们还通过将 Selenium 与 Appium 结合使用它来测试 iPad 应用程序。我们使用 Robot 来测试为应用程序提供数据的 RESTful 服务。我们编写了专门的关键字来进行图像分析,并且我们还使用机器人测试在每次训练之前对我们的训练设备进行快速分析。我们有关键字可以让我们在测试前对数据库进行快照,并在测试后恢复数据库。
我们还开始使用机器人来帮助进行手动测试。我们在 Robot 中放置了手动测试用例,这让我们可以利用 Robot 的报告和标记功能。当这些测试运行时,它们会提示用户执行手动步骤,这被证明比让测试人员从测试用例管理工具或 Word 文档中读取手动步骤时效率更高。
第三家公司是一家大型公司(收入为 10 亿美元),拥有相当多的 IT 员工。他们的测试人员非常低技术技能(我记得有一个不知道命令行是什么的人)。我们有一个团队专门编写一组核心关键词,并为其他团队提供培训和指导。我认为 Robot 的使用有助于从最不熟练的测试人员那里获得一些使用,尽管即使使用高级关键字也很难与他们斗争。
最近,我搬到了一家很小的公司,只有少数开发人员,没有专门的测试人员。我们将page objects 与Robot Framework 结合使用,现在我们拥有一套非常稳定且易于阅读的高级验收测试。在这家公司使用 Robot 取得了巨大的成功。
Robot 最大的优势在于它的灵活性。我们使用 Robot 来支持手动测试、SOAP 和 REST 服务的测试、基于 Web 的 UI 测试、数据库测试、图像测试以及移动应用程序的测试。因为 Robot 很容易通过额外的库进行扩展,所以如果你愿意卷起袖子写一些关键字,几乎没有什么是你不能测试的。根据您的设置,您可以通过机器人远程 API 用 Python、Java、.NET 或几乎任何语言编写关键字。
由于 Robot 测试用例和关键字是用纯文本编写的,因此您不必拘泥于使用专有工具来创建或查看测试。用户可以选择他们选择的工具——Visual Studio、Eclipse、Emacs、记事本等。还有一个机器人特定的 IDE (RIDE),尽管我不推荐它。此外,由于文件是纯文本,它们与其他软件工具很好地集成在一起——它们很容易区分和合并、搜索等。
Robot 可以轻松编写低质量的测试。虽然有记录关键字和测试用例的工具,并为关键字、测试用例和变量使用人类可读的名称,但没有很好的方法来实施最佳实践。编写大量测试和关键字需要纪律。俗话说,机器人给了你很多绳子可以用来吊死自己。
另一个弱点是机器人的进展速度相当缓慢。从好的方面来说,Robot 很健壮并且相对没有错误,因此不需要频繁的补丁。但是,有些功能请求在他们的问题跟踪器中停滞了多年,没有任何动作,这可能会令人沮丧。
在所有公司中,我们都乐于利用 Robot 语法提供的灵活性来创建数据驱动测试、BDD 样式测试以及简单的过程测试。在所有情况下,由于测试是纯文本文件,因此使用我们的 SCM 工具(Mercurial、Subversion 和 Git)可以轻松管理测试资产
对我而言,Robot 已被证明易于使用、极易扩展,并且可用于各种测试任务,从 Python 函数的单元测试到 Web 服务、基于浏览器和平板电脑 UI 的测试测试,图像测试,数据库测试,甚至提高手动测试的效率。
【讨论】:
一年多来,我们一直在我的工作地点使用 Robot Framework,并取得了一定的成功。像海报一样,我们也做 C++ 工作。我们花了一些时间来评估 Robot 和 Fitnesse/Slim,当时两种解决方案都很好,但决定因素是(截至 2009 年):
从技术角度来看,我们一直在使用SWIG 在 Robot 和 C++ 之间架起桥梁。我们在 SWIG 中包装了我们的测试装置,并将其与测试中的生产代码链接——为我们提供了一个可以由 Robot 导入的 python 模块。
我们几乎只对机器人输入使用 .txt 格式 - 我们发现这个版本控制得更好,更容易阅读,而且我们根本没有使用 HTML 的高级功能(这是我们开始的地方)。此外,我们还使用"BDD Style" Robot 语法。我们使用带有一些包装器的 GoogleMock 来帮助我们设置期望值,这些期望值会在每个机器人测试的拆卸过程中进行检查。
就组织测试而言,我们选择了以下方法(灵感来自Dale Emery's approach given here):
例如,一部手机可能有这样的东西:
// 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 位数字)配对 - 或者这可能是另一个验收测试(可执行规范),具体取决于谁在阅读测试及其熟悉领域。
我们会草拟这些规范,并在开始工作之前与领域专家和团队进行审核。这有助于在早期消除一些误解。
【讨论】:
我在以下场景中使用了 Robot 框架。
对于服务测试,我发现Robot 框架有点难以用于我正在进行的那种测试自动化。
我们的应用服务层完全用 C/C++ 编写。我个人在一台 Windows 笔记本电脑上工作,我们的应用程序驻留在 Linux 服务器上。
我发现*Fitnesse 框架** 更有用且更易于实现自动化。 Fitnesse 具有以下提到的额外功能,可以轻松编写测试用例。我在 Robot 中找不到类似的功能。
决策表 - 您可以使用 Microsoft .xls 格式编写测试用例。数据网格中的每一行将代表一个测试用例。每行将有一组输入和输出。输出将在标题中以问号开头。
查询表 - 测试的输出将是您想要验证的数据列表。
Fitnesse 还允许轻松与 C 等其他语言集成(使用 Slim 服务)。这不需要任何集成编码。 Fitnesse 测试用例直接执行测试夹具、getter 和 setter。
我的经验总结:
我找到了一个易于使用的 UI 自动化工具。
我发现它有点难以用于服务自动化。
【讨论】: