我想听听其他人使用 Robot Framework 进行自动化验收测试的经验。
它的主要优点和缺点是什么,以及与其他框架(主要是 Fitnesse 和 Selenium)的比较?
将要测试的代码是实时的遗留代码,主要是 C++。
我想听听其他人使用 Robot Framework 进行自动化验收测试的经验。
它的主要优点和缺点是什么,以及与其他框架(主要是 Fitnesse 和 Selenium)的比较?
将要测试的代码是实时的遗留代码,主要是 C++。
在我写这篇文章的时候,我已经在三个不同的公司使用了机器人框架,时间跨度大约六年,并且都以一种或另一种方式取得了成功。
我第一次使用 Robot 是为一家顶级互联网旅游公司开发的基于 Java 的 Web 应用程序。我们将 Robot 与 Jython 一起使用,这让我们可以在 Java 中创建关键字并直接与被测系统进行操作。我们使用 Selenium 来驱动 Web 浏览器,我们的大部分测试都是在 Firefox 上进行的。虽然 QA 组织的测试工作在很大程度上取得了成功,但开发组织未能接受它——他们更喜欢使用 JUnit 而不是 Robot。
我觉得我的第二家公司取得了空前的成功。我们以多种方式使用机器人。主要用途是驱动 Internet Explorer 对非常成功的商业 .NET Web 应用程序进行验收和回归测试。
我们还通过将 Selenium 与Appium结合使用它来测试 iPad 应用程序。我们使用 Robot 来测试为应用程序提供数据的 RESTful 服务。我们编写了专门的关键字来进行图像分析,并且我们还使用机器人测试在每次训练之前对我们的训练设备进行快速分析。我们有关键字可以让我们在测试前对数据库进行快照,并在测试后恢复数据库。
我们还开始使用 Robot 来帮助进行手动测试。我们在 Robot 中放置了手动测试用例,这让我们可以利用 Robot 的报告和标记功能。当这些测试运行时,它们会提示用户执行手动步骤,这被证明比让测试人员从测试用例管理工具或 Word 文档中读取手动步骤更有效。
第三家公司是一家大型公司(收入 10 亿美元),拥有相当多的 IT 员工。他们有技术技能非常低的测试人员(我记得有一个不知道命令行是什么的人)。我们有一个团队专门编写一组核心关键词,并为其他团队提供培训和指导。我认为 Robot 的使用有助于从最不熟练的测试人员中获得一些使用,尽管即使使用高级关键字,与他们的斗争也是如此。
最近,我搬到了一家很小的公司,只有少数开发人员,没有专门的测试人员。我们支持在 Robot Framework 中使用页面对象,现在我们拥有一套非常稳定且易于阅读的高级验收测试。在这家公司使用机器人取得了绝对的成功。
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 风格”机器人语法。我们使用带有一些包装器的 GoogleMock 来帮助我们设置期望值,这些期望值会在每个机器人测试的拆解过程中进行检查。
就组织测试而言,我们采用了以下方法(灵感来自Dale Emery 在此处给出的方法):
例如,一部手机可能有这样的东西:
// 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 自动化工具。
我发现它有点难以用于服务自动化。