[翻译]Robot Framework Quick Start Guide [进行中]
原文：https://github.com/robotframework/QuickStartGuide/blob/master/QuickStart.rst
Robot Framework Quick Start Guide
Copyright © Nokia Networks. Licensed under the Creative Commons Attribution 3.0 Unported license.
目录:
引言
关于此指南
Robot Framework快速入门指南介绍了Robot Framework中最重要的功能。你可以简单地浏览此指南及其中的示例，你也可以把此指南当作一份可执行的demo来使用。这里介绍的所有功能均会在Robot Framework User Guide中以更加详细的方式介绍。
Robot Framework概览
Robot Framework是一个用于验收测试及验收测试驱动开发(ATDD)的通用开源自动化测试框架。它设计了一套易用的表格化测试数据语法并使用关键字驱动型测试方法。此测试框架的测试能力是可以通过test librarires来扩展的，这些library可以通过Python或者Java实现，同时用户可以从使用相同语法的已有keyword中创建新的高级关键字(keyword)，已有的关键字用于创建测试用例。
Robot Framework独立于操作系统及应用程序。框架核心是用Python实现的，它可以运行在Jython (JVM)和IronPython (.NET)上。此框架拥有一个完整的围绕自身建立的生态系统，生态系统由各类通用测试库和工具组成，这些库和工具均是独立的项目，互不干扰。
查找更多有关Robot Framework及其生态系统的信息，参阅http://robotframework.org。在那里你可以找到大量的文档，演示项目，罗列出的可用测试库和其它工具，等等。
演示程序
此演示程序是一个经典的登录测试的变体：被测程序是一个基于命令行的Python认证服务器。这个认证服务器允许用户完成下列三件事情：
- 使用一个合法的密码创建一个用户。
- 使用合法的用户名及其密码登录。
- 修改一个已有用户的密码。
应用程序本身在sut/login.py文件中，它可以通过命令: python sut/login.py执行。使用一个不存在的用户名或者非法密码登录均会生成相同的错误信息（拒绝访问）：
> python sut/login.py login nobody P4ssw0rd Access Denied
使用合法密码创建一个用户并登录成功：
> python sut/login.py create fred P4ssw0rd SUCCESS > python sut/login.py login fred P4ssw0rd Logged In
应用程序中的用户密码需满足两个要求：长度必须是7到12个字符；必须包含小写字母，大写字母和数字，但是不可以包含特殊字符。使用非法的密码创建用户时会失败：
> python sut/login.py create fred short Creating user failed: Password must be 7-12 characters long > python sut/login.py create fred invalid Creating user failed: Password must be a combination of lowercase and uppercase letters and numbers
使用非法的用户名及密码登录并修改用户密码会导致生成和用非法信息登录时一样的错误信息。修改密码时应用程序会验证新密码的合法性，如果新密码非法，程序会产生一条错误信息：
> python sut/login.py change-password fred wrong NewP4ss Changing password failed: Access Denied > python sut/login.py change-password fred P4ssw0rd short Changing password failed: Password must be 7-12 characters long > python sut/login.py change-password fred P4ssw0rd NewP4ss SUCCESS
这个认证服务器应用程序使用一个简单的数据库文件追踪用户状态。该数据库文件位于与操作系统无关的一个临时目录内。
执行此指南
这些指导解释了如何运行此指南中的示例测试。如果你对此并不感兴趣，你可以直接查看在线版本的测试结果
安装
推荐使用Python的pip工具安装Robot Framework。一旦你拥有Python的必备运行环境及pip工具，你可以简单地运行下列命令：
pip install robotframework
查阅Robot Framework installation instructions以获取其它安装方法及通用化的详细安装说明。
此演示测试程序使用reStructuredText标记语言编写，并按Robot Framework的测试数据组织方式组织成代码块。执行测试要求安装额外的docutils模块：
pip install docutils
注意：Robot Framework 3.0是第一个支持Python 3的版本。查找之前提到的installation instructions以获取有关Python 2对比Python 3的信息。
执行
安装完成后，你仍需获取演示测试程序。你可以很容易地下载到一个特定的发布版本(release)或者抓取最新版本(latest content)并解压下载后的程序代码，当然你也可以把程序从项目代码仓库中克隆至本地。
安装完成测试程序及Robot Framework本身后，你可以在命令行使用robot命令运行此演示测试程序：
robot QuickStart.rst
如果你使用Robot Framework 2.9或者更早期的版本，则需使用pybot命令执行：
pybot QuickStart.rst
你也可以利用多个命令行参数定制一次测试的执行：
robot --log custom_log.html --name Custom_Name QuickStart.rst
欲查看完整的可用命令行参数列表，运行命令： robot --help.
查看测试结果
Running the demo generates the following three result files. These files are linked to pre-executed files available online, but executing the demo creates them locally.
运行此演示测试程序后会产生三个测试结果文件。这些文件已经存储于线上，是之前测试产生的结果，但是执行此演示程序本身会在本地创建测试结果文件。
- report.html
- 高级别的测试报告。
- log.html
- 细节化的测试执行日志。
- output.xml
- 机器可读的XML格式的测试结果。
测试用例
Workflow tests
Robot Framework test cases are created using a simple tabular syntax. For example, the following table has two tests:
- User can create an account and log in
- User cannot log in with bad password
*** Test Cases ***
User can create an account and log in
Create Valid User fred P4ssw0rd
Attempt to Login with Credentials fred P4ssw0rd
Status Should Be Logged In
User cannot log in with bad password
Create Valid User betty P4ssw0rd
Attempt to Login with Credentials betty wrong
Status Should Be Access Denied
Notice that these tests read like manual tests written in English rather than like automated test cases. Robot Framework uses the keyword-driven approach that supports writing tests that capture the essence of the actions and expectations in natural language.
Test cases are constructed from keywords and their possible arguments. The syntax requires that keywords and arguments, as well as settings and their values, are separated by at least two spaces or by a tab character. It is generally recommended to use four spaces to make the separator more explicit, and in some cases aligning arguments or other values may make the data easier to understand. For more details about the syntax see Robot Framework User Guide.
Higher-level tests
Test cases can also be created using only high-level keywords that take no positional arguments. This style allows using totally free text which is suitable for communication even with non-technical customers or other project stakeholders. This is especially important when using the acceptance test-driven development (ATDD) approach or any of its variants and created tests act also as requirements.
Robot Framework does not enforce any particular style for writing test cases. One common style is the given-when-then format popularized by behavior-driven development (BDD):
*** Test Cases ***
User can change password
Given a user has a valid account
When she changes her password
Then she can log in with the new password
And she cannot use the old password anymore
Data-driven tests
Quite often several test cases are otherwise similar but they have slightly different input or output data. In these situations data-driven tests allows varying the test data without duplicating the workflow. With Robot Framework the [Template] setting turns a test case into a data-driven test where the template keyword is executed using the data defined in the test case body:
*** Test Cases ***
Invalid password
[Template] Creating user with invalid password should fail
abCD5 ${PWD INVALID LENGTH}
abCD567890123 ${PWD INVALID LENGTH}
123DEFG ${PWD INVALID CONTENT}
abcd56789 ${PWD INVALID CONTENT}
AbCdEfGh ${PWD INVALID CONTENT}
abCD56+ ${PWD INVALID CONTENT}
In addition to using the [Template] setting with individual tests, it would be possible to use the Test Template setting once in the settings table like setups and teardowns defined later in this guide. In our case that would ease creating separate named tests for invalid length password cases and for other invalid cases. However, that would require moving those tests to a separate file, because otherwise the template would also be applied to other tests in this file.
Notice also that the error messages in the above example are specified using variables.
Keywords
Test cases are created from keywords that can come from two sources. Library keywords come from imported test libraries, and so called user keywords can be created using the same tabular syntax that is used for creating test cases.
Library keywords
All lowest level keywords are defined in test libraries which are implemented using standard programming languages, typically Python or Java. Robot Framework comes with a handful of test libraries that can be divided to standard libraries, external libraries and custom libraries. Standard libraries are distributed with the core framework and included generic libraries such as OperatingSystem, Screenshot and BuiltIn, which is special because its keywords are available automatically. External libraries, such as Selenium2Library for web testing, must be installed separately. If available test libraries are not enough, it is easy to create custom test libraries.
To be able to use keywords provided by a test library, the keywords must be imported using the Library setting. Tests in this guide need keywords from the standard OperatingSystem library (e.g. Remove File) and from a custom made LoginLibrary (e.g. Attempt to login with credentials). Both of these libraries are imported in the settings table below:
*** Settings ***
Library OperatingSystem
Library lib/LoginLibrary.py
User keywords
One of the most powerful features of Robot Framework is the ability to easily create new, higher-level keywords from other keywords. The syntax for creating these so called user-defined keywords, or user keywords for short, is similar to the syntax that is used for creating test cases. All the higher-level keywords needed in previous test cases are created in this keyword table:
*** Keywords ***
Clear login database
Remove file ${DATABASE FILE}
Create valid user
[Arguments] ${username} ${password}
Create user ${username} ${password}
Status should be SUCCESS
Creating user with invalid password should fail
[Arguments] ${password} ${error}
Create user example ${password}
Status should be Creating user failed: ${error}
Login
[Arguments] ${username} ${password}
Attempt to login with credentials ${username} ${password}
Status should be Logged In
# Keywords below used by higher level tests. Notice how given/when/then/and
# prefixes can be dropped. And this is a comment.
A user has a valid account
Create valid user ${USERNAME} ${PASSWORD}
She changes her password
Change password ${USERNAME} ${PASSWORD} ${NEW PASSWORD}
Status should be SUCCESS
She can log in with the new password
Login ${USERNAME} ${NEW PASSWORD}
She cannot use the old password anymore
Attempt to login with credentials ${USERNAME} ${PASSWORD}
Status should be Access Denied
User-defined keywords can include actions defined by other user-defined or library keywords. As you can see from this example, user-defined keywords can take parameters. They can also return values and even contain FOR loops. For now, the important thing to know is that user-defined keywords enable test creators to create reusable steps for common action sequences. User-defined keywords can also help the test author keep the tests as readable as possible and use appropriate abstraction levels in different situations.
Variables
Defining variables
Variables are an integral part of the Robot Framework. Usually any data used in tests that is subject to change is best defined as variables. Syntax for variable definition is quite simple, as seen in this variable table:
*** Variables ***
${USERNAME} janedoe
${PASSWORD} J4n3D0e
${NEW PASSWORD} e0D3n4J
${DATABASE FILE} ${TEMPDIR}${/}robotframework-quickstart-db.txt
${PWD INVALID LENGTH} Password must be 7-12 characters long
${PWD INVALID CONTENT} Password must be a combination of lowercase and uppercase letters and numbers
Variables can also be given from the command line which is useful if the tests need to be executed in different environments. For example this demo can be executed like:
robot --variable USERNAME:johndoe --variable PASSWORD:J0hnD0e QuickStart.rst
In addition to user defined variables, there are some built-in variables that are always available. These variables include ${TEMPDIR} and ${/} which are used in the above example.
Using variables
Variables can be used in most places in the test data. They are most commonly used as arguments to keywords like the following test case demonstrates. Return values from keywords can also be assigned to variables and used later. For example, the following Database Should Contain user keyword sets database content to ${database} variable and then verifies the content using BuiltIn keyword Should Contain. Both library and user keywords can return values.
*** Test Cases ***
User status is stored in database
[Tags] variables database
Create Valid User ${USERNAME} ${PASSWORD}
Database Should Contain ${USERNAME} ${PASSWORD} Inactive
Login ${USERNAME} ${PASSWORD}
Database Should Contain ${USERNAME} ${PASSWORD} Active
*** Keywords ***
Database Should Contain
[Arguments] ${username} ${password} ${status}
${database} = Get File ${DATABASE FILE}
Should Contain ${database} ${username}\t${password}\t${status}\n
Organizing test cases
Test suites
Collections of test cases are called test suites in Robot Framework. Every input file which contains test cases forms a test suite. When executing this guide, you see test suite QuickStart in the console output. This name is derived from the file name and it is also visible in reports and logs.
It is possible to organize test cases hierarchically by placing test case files into directories and these directories into other directories. All these directories automatically create higher level test suites that get their names from directory names. Since test suites are just files and directories, they are trivially placed into any version control system.
Setups and teardowns
If you want certain keywords to be executed before or after each test, use the Test Setup and Test Teardown settings in the settings table. Similarly you can use the Suite Setup and Suite Teardown settings to specify keywords to be executed before and/or after an entire test suite.
Individual tests can also have a custom setup or teardown by using [Setup] and [Teardown] in the test case table. This works the same way as [Template] was used earlier with data-driven tests.
In this demo we want to make sure the database is cleared before execution starts and that every test also clears it afterwards:
*** Settings ***
Suite Setup Clear Login Database
Test Teardown Clear Login Database
Using tags
Robot Framework allows setting tags for test cases to give them free metadata. Tags can be set for all test cases in a file with Force Tags and Default Tags settings like in the table below. It is also possible to define tags for a single test case using [Tags] settings like in earlier User status is stored in database test.
*** Settings ***
Force Tags quickstart
Default Tags example smoke
When you look at a report after test execution, you can see that tests have specified tags associated with them and there are also statistics generated based on tags. Tags can also be used for many other purposes, one of the most important being the possibility to select what tests to execute. You can try, for example, the following commands:
robot --include smoke QuickStart.rst robot --exclude database QuickStart.rst
Creating test libraries
Robot Framework offers a simple API for creating test libraries using either Python or Java, and the remote library interface also allows using other programming languages. Robot Framework User Guide contains a detailed description about the library API.
As an example, we can take a look at the LoginLibrary test library used in this demo. The library is located at lib/LoginLibrary.py, and its source code is also copied below. Looking at the code you can see, for example, how the keyword Create User is mapped to actual implementation of the method create_user.
import os.path
import subprocess
import sys
class LoginLibrary(object):
def __init__(self):
self._sut_path = os.path.join(os.path.dirname(__file__),
'..', 'sut', 'login.py')
self._status = ''
def create_user(self, username, password):
self._run_command('create', username, password)
def change_password(self, username, old_pwd, new_pwd):
self._run_command('change-password', username, old_pwd, new_pwd)
def attempt_to_login_with_credentials(self, username, password):
self._run_command('login', username, password)
def status_should_be(self, expected_status):
if expected_status != self._status:
raise AssertionError("Expected status to be '%s' but was '%s'."
% (expected_status, self._status))
def _run_command(self, command, *args):
command = [sys.executable, self._sut_path, command] + list(args)
process = subprocess.Popen(command, stdout=subprocess.PIPE,
stderr=subprocess.STDOUT)
self._status = process.communicate()[0].strip()
