Robot Framework官方教程（一）入门
Robot Framework官方教程（二）测试数据语法
Robot Framework官方教程（三）创建测试用例
Robot Framework官方教程（四）创建测试套件
Robot Framework官方教程（五）使用测试库
Robot Framework官方教程（六）变量
Robot Framework官方教程（七）创建用户关键字
Robot Framework官方教程（八） 资源和变量文件
Robot Framework官方教程（九） 执行测试用例
Robot Framework官方教程（十）扩展RobotFramework框架
本节介绍整个测试用例语法。使用测试用例文件和测试套件目录将测试用例组织到测试套件中将在下一节中讨论。
2.2.1测试用例语法
基本语法
测试用例由关键字在测试用例表中构建。关键字可以从测试库或资源文件导入，也可以在测试用例文件本身的关键字表中创建。
测试用例表中的第一列包含测试用例名称。测试用例从包含此列的内容的行开始，并继续到下一个测试用例名称或表的末尾。
第二列通常具有关键字名称。此规则的一个例外是从关键字返回的值设置变量，当第二列或后面的几列包含变量名称，且关键字名称位于它们之后时。在任何一种情况下，关键字名称后面的列都包含指定关键字的参数。
| Test Case | Action | Argument | Argument |
|---|---|---|---|
| Valid Login | Open Login Page | ||
| Input Name | demo | ||
| Input Password | mode | ||
| Submit Credentials | |||
| Welcome Page Should Be Open | |||
| Setting Variables | Do Something | first argument | second argument |
| ${value} = | Get Some Value | ||
| Should Be Equal | ${value} | Expected value |
“测试用例”中的设置
测试用例也可以有自己的设置。设置名称始终位于第二列中，其值在后续列中。关键字通常也是在第二列。设置名称周围有方括号，以区别于关键字。可用设置如下所示，本节稍后将对其进行说明。
-
[Documentation]
用于指定测试用例文档。
-
[Tags]
用于标记测试用例。
-
[Setup]，[Teardown]
指定测试设置和拆卸。也有同义词 [Precondition]和[Postcondition]。
-
[Template]
指定要使用的模板关键字。测试本身将仅包含用作该关键字的参数的数据。
-
[Timeout]
| Test Case | Action | Argument | Argument |
|---|---|---|---|
| Test With Settings | [Documentation] | Another dummy test | |
| [Tags] | dummy | owner-johndoe | |
| Log | Hello, world! |
设置表中的测试用例相关设置
设置表具有以下与测试用例相关的设置。这些设置主要是前面列出的测试用例特定设置的默认值。
-
Force Tags, Default Tags
标签的强制值和默认值。
-
Test Setup, Test Teardown
测试设置和拆卸的默认值。同时也有同义词 Test Precondition和Test Postcondition。
-
Test Template
要使用的默认模板关键字。
-
Test Timeout
2.2.2使用参数
前面的示例已经演示了使用不同参数的关键字，本节将更全面地讨论这一重要功能。如何实际实现具有不同参数的用户关键字和库关键字将在单独的部分中讨论。
关键字可以接受零个或多个参数，而某些参数可能具有默认值。关键字接受的参数取决于其实现，通常搜索此信息的最佳位置是关键字的文档。在本节的示例中，预计文档将使用libdoc工具生成 ，但是有关通用文档工具（如javadoc）生成的文档的相同信息 。
必需的参数
大多数关键字都必须始终给出一定数量的参数。在关键字文档中，这通过指定以逗号（如第一，第二，第三）分隔的参数名称来表示。在这种情况下，参数名称实际上并不重要，除了它们应该解释参数的作用，但重要的是具有与文档中指定的完全相同数量的参数。使用太少或太多的参数将导致错误。
下面的测试使用的属于OperatingSystem库的关键字Create Directory和Copy File。它们的参数被指定为 path和（source,destination ），这意味着它们分别采用一个和两个参数。最后一个关键字，来自BuiltIn的No Operation， 不带任何参数。
| Test Case | Action | Argument | Argument |
|---|---|---|---|
| Example | Create Directory | ${TEMPDIR}/stuff | |
| Copy File | ${CURDIR}/file.txt | ${TEMPDIR}/stuff | |
| No Operation |
默认值
参数通常具有默认值，可以给出或不给出。在文档中，默认值通常与参数名称分隔，其名称与name = default value相同。所有参数都可能具有默认值，但在具有默认值的参数之后不能存在任何位置参数。
下面的示例说明了使用默认值，该示例使用 具有参数path，content =，encoding = UTF-8的Create File关键字。试图在没有任何参数或超过三个参数的情况下使用它是行不通的。
| Test Case | Action | Argument | Argument | Argument |
|---|---|---|---|---|
| Example | Create File | ${TEMPDIR}/empty.txt | ||
| Create File | ${TEMPDIR}/utf-8.txt | Hello world | ||
| Create File | ${TEMPDIR}/iso-8859-1.txt | Hello world | ISO-8859-1 |
可变数量的参数
也可以创建接受任意数量参数的关键字。这些参数可以与必填参数和带有默认值的参数组合，但所谓的varargs只能放在参数列表的最后一个。在文档中，它们通常在参数名称之前有一个星号，如* varargs。
以下示例中使用的Remove Files和Join Paths关键字分别包含参数*paths和base，*parts。前者可以与任意数量的参数一起使用，但后者至少需要一个参数。
| Test Case | Action | Argument | Argument | Argument |
|---|---|---|---|---|
| Example | Remove Files | ${TEMPDIR}/f1.txt | ${TEMPDIR}/f2.txt | ${TEMPDIR}/f3.txt |
| @{paths} = | Join Paths | ${TEMPDIR} | f1.txt | |
| ... | f2.txt | f3.txt | f4.txt |
命名参数
当关键字接受具有默认值的多个参数时，不能使用位置参数仅覆盖最后一个参数。例如，如果在下面的测试中使用具有参数arg1 = a，arg2 = b，arg3 = c的关键字，则其参数 arg1和arg2都将空字符串作为值而不是其默认值。
| Test Case | Action | Argument | Argument | Argument |
|---|---|---|---|---|
| Positional Arguments | [Documentation] | 1st and 2nd | argument get | empty strings |
| Example Keyword | value |
为了只给出一些期望默认值更容易的参数，在Robot Framework 2.5中添加了新的命名参数语法。使用此语法，需要覆盖其默认值的参数将在格式为argname = value的必填参数之后立即给出。可以简单地省略使用默认值的参数。以下示例测试说明了这在实践中如何工作，该测试使用与上述示例相同的关键字。在此示例中，未指定的参数将获取其默认值。
| Test Case | Action | Argument | Argument | Argument |
|---|---|---|---|---|
| Named Arguments | [Documentation] | Not specified | arguments get | default values |
| Example Keyword | arg3=value | |||
| Example Keyword | arg2=xxx | arg3=yyy |
当没有参数遗留时，命名参数语法自然可以与接受默认值的参数一起使用。这可以使参数含义比仅显示值时更清晰。但是，以这种方式命名必填参数是不可能的。此外，不能先给出第一个命名参数，然后是varargs。
命名参数功能的最大限制是它目前仅适用于用户关键字和使用Python实现的库关键字，它们使用静态库API或混合库API。
注意
当命名参数语法与用户关键字一起使用时，参数名称不带
${}装饰。例如，带参数${arg1} = default，${arg2} = second的用户关键字， 必须这样使用：arg2 = override。
仅当等号前面的参数部分与具有默认值的参数名称匹配时，才使用命名参数语法。此匹配从给定参数列表的末尾开始，并在没有匹配时停止。在偶然匹配的极少数情况下，可以使用\ 来转义此语法，如nomatch\=here。
注意
命名参数语法既是大小写也是空格敏感的。前者意味着如果你有一个参数 arg，你必须这样使用：
arg=<value>，并且Arg=<value>或ARG=<value>不起作用。后者意味着在=号之前不允许使用空格 ，并且在它之后的空格被视为默认值本身的一部分。
以下示例演示了在不同方案中使用命名参数，包括在测试库导入中。
| Setting | Value | Value | Value |
|---|---|---|---|
| Library | Telnet | prompt=$ |
| Test Case | Action | Argument | Argument | Argument |
|---|---|---|---|---|
| Example | Open connection | 10.0.0.42 | port=${25} | |
| List files | options=-lh | |||
| List files | path=/tmp | options=-l |
| Keyword | Action | Argument | Argument | Argument |
|---|---|---|---|---|
| List files | [Arguments] | ${path}=. | ${options}= | |
| Execute command | ls ${options} ${path} |
2.2.3测试用例名称和文档
测试用例名称直接来自Test Case表：它正是输入测试用例列的内容。一个测试套件中的测试用例应具有唯一的名称。与此相关，您还可以使用测试中的自动化变量 ${TEST_NAME}来引用测试名称。无论何时执行测试，它都可用，包括所有用户关键字，以及测试设置和测试拆解。
[Documentation]可以为测试用例设置文档。该文本显示在命令行输出中，以及生成的测试日志和测试报告。
如果文档很长，它可以拆分成几个 与空格一起连接的单元格。可以使用简单的 HTML格式，并且可以使用变量使文档动态化。从Robot Framework 2.7开始，如果文档分为多行，则使用换行符连接多行 。如果行已经以换行符结尾或者以转义的反斜杠结束，则不会添加换行符。
| Test Case | Action | Argument | Argument |
|---|---|---|---|
| Simple | [Documentation] | Simple documentation | |
| No Operation | |||
| Splitting | [Documentation] | This documentation is a bit longer and | it has been split into several columns. |
| No Operation | |||
| Many lines | [Documentation] | Here we have | |
| ... | an automatic newline | ||
| No Operation | |||
| Formatting | [Documentation] | *This is bold*, _this italic_ and |
here is a link: http://robotframework.org |
| No Operation | |||
| Variables | [Documentation] | Executed at ${HOST} by ${USER} |
|
| No Operation |
测试用例具有清晰且具有描述性的名称非常重要，在这种情况下，它们通常不需要任何文档。如果测试用例的逻辑需要记录，那么通常表明测试用例中的关键字需要更好的名称并且要加强它们，而不是添加额外的文档。最后，通常使用标签更好地指定元数据，例如上面最后一个示例中的环境和用户信息。
2.2.4标记测试用例
在Robot Framework中使用标签是一种简单但功能强大的机制，用于对测试用例进行分类。标签是自由文本，它们至少可用于以下目的：
- 标签显示在测试报告，日志中，当然还包括测试数据中，因此它们为测试用例提供元数据。
- 测试用例的统计信息（总计，通过，失败是根据标签自动收集的）。
- 使用标记，您可以包含或排除要执行的测试用例。
- 使用标记，您可以指定哪些测试用例被认为是关键的。
在本节中，仅解释了如何为测试用例设置标记，下面列出了不同的方法。这些方法当然可以一起使用。
-
在设置表中强制标记
Force Tags具有此设置的测试用例文件中的所有测试用例始终都会获得指定的标记。如果在测试套件初始化文件中使用它，则子测试套件中的所有测试用例都会获得这些标记。
-
设置表中的默认标签
Default Tags没有自己[Tags]设置的测试用例会获得这些标记。从Robot Framework版本2.5开始，测试套件初始化文件中不再支持默认标记。
-
测试用例表中的
[Tags]测试用例总是获得这些标签。此外，它不会获取使用默认标记指定的可能标记，因此可以使用空值覆盖默认标记。从Robot Framework 2.5.6开始，也可以使用值NONE 来覆盖默认标记。
-
--settag命令行选项除了他们在别处获得的标签之外，所有执行的测试用例都使用此选项设置标签。
-
设置标签
Set Tags和删除标签Remove Tags keywords关键字这些BuiltIn关键字可用于在测试执行期间修改标记。
标签是自由文本，但它们已标准化，框架会将它们转换为小写并删除所有空格。如果测试用例多次获得相同的标签，则删除除第一个之外的其他地方的标签。可以使用变量创建标记，当然这些变量必须已经存在。
| Setting | Value | Value | Value |
|---|---|---|---|
| Force Tags | req-42 | ||
| Default Tags | owner-john | smoke |
| Variable | Value | Value | Value |
|---|---|---|---|
| ${HOST} | 10.0.1.42 |
| Test Case | Action | Argument | Argument |
|---|---|---|---|
| No own tags | [Documentation] | This test has tags | owner-john, smoke, req-42 |
| No Operation | |||
| With own tags | [Documentation] | This test has tags | not_ready, owner-mrx, req-42 |
| [Tags] | owner-mrx | not_ready | |
| No Operation | |||
| Own tags with variables | [Documentation] | This test has tags | host-10.0.1.42, req-42 |
| [Tags] | host-${HOST} | ||
| No Operation | |||
| Empty own tags | [Documentation] | This test has tags | req-42 |
| [Tags] | |||
| No Operation | |||
| Set Tags and Remove Tags Keywords | [Documentation] | This test has tags | mytag, owner-john |
| Set Tags | mytag | ||
| Remove Tags | smoke | req-* |
2.2.5 setup和teardown
Robot Framework具有与许多其他测试自动化框架类似的测试设置和测试拆卸功能。简而言之，测试设置是在测试用例之前执行的，并且在测试用例之后执行测试拆卸。在Robot Framework中，设置和拆卸只是可能带有参数的普通关键字。
设置和拆卸只能是一个关键字。如果他们需要处理多个单独的任务，则可以为此目的创建更高级别的用户关键字。另一种解决方案是使用Robot Framework 2.5中添加的BuiltIn关键字 Run Keywords来执行多个关键字。
测试拆卸在两个方面是特殊的。首先，它也在测试用例失败时执行，因此它可以用于不管测试用例状态的情况下进行的清理活动。从Robot Framework 2.5开始，即使其中一个关键字失败，也会执行拆卸中的所有关键字。
在测试用例文件中为测试用例指定设置或拆卸的最简单方法是使用“设置”表中的“ 测试设置”和“ 测试拆卸”设置。个别测试用例也可以有自己的设置或拆卸。它们使用测试用例表中的[Setup]或[Teardown]设置进行定义， 并且会覆盖设置表的Test Setup和 Test Teardown设置。在[Setup]或[Teardown]设置后没有关键字 意味着没有设置或拆卸。从Robot Framework 2.5.6开始，也可以使用值NONE来指示测试没有设置/拆卸。
| Setting | Value | Value | Value |
|---|---|---|---|
| Test Setup | Open Application | App A | |
| Test Teardown | Close Application |
| Test Case | Action | Argument | Argument |
|---|---|---|---|
| Default values | [Documentation] | Setup and teardown | from setting table |
| Do Something | |||
| Overridden setup | [Documentation] | Own setup, teardown | from setting table |
| [Setup] | Open Application | App B | |
| Do Something | |||
| No teardown | [Documentation] | Default setup, no | teardown at all |
| Do Something | |||
| [Teardown] | |||
| No teardown 2 | [Documentation] | Using special NONE, | works with 2.5.6 |
| Do Something | |||
| [Teardown] | NONE | ||
| Using variables | [Documentation] | Setup and teardown | given as variables |
| [Setup] | ${SETUP} |
||
| Do Something | |||
| [Teardown] | ${TEARDOWN} |
通常在创建类似用例的测试用例时，术语前置条件 和后置条件优于术语设置和拆卸。Robot Framework也支持这个术语，因此前提条件是设置的同义词，后置条件是拆卸的同义词。
| Test Setup | Test Precondition |
|---|---|
| Test Teardown | Test Postcondition |
| [Setup] | [Precondition] |
| [Teardown] | [Postcondition] |
作为设置或拆卸执行的关键字的名称可以是变量。通过从命令行提供关键字名称作为变量，这有助于在不同环境中进行不同的设置或拆卸。
注意
测试套件可以自行设置和拆卸。套件设置在该测试套件中的任何测试用例或子测试套件之前执行，同样在它们之后执行套件拆卸。
2.2.6测试模板
测试模板将正常的关键字驱动的测试用例转换为 数据驱动的测试。正常测试用例的主体是由关键字及其可能的参数构成的，而带有模板的测试用例仅定义了template关键字的参数。以下示例测试用例在功能上完全相同。
| Test Case | Action | Argument | Argument |
|---|---|---|---|
| Normal test case | Example keyword | first argument | second argument |
| Templated test case | [Template] | Example keyword | |
| first argument | second argument |
如上例所示，可以使用[Template]为单个测试用例指定模板。另一种方法是使用 Setting表中的Test Template设置，在这种情况下，该模板将应用于该测试用例文件中的所有测试用例。[Template] 会覆盖设置表中的Test Template设置，当[Template] 设置为一个空值，表示该用用例没有模板，即使设置表中设置了。从Robot Framework 2.5.6开始，也可以使用值NONE来指示测试没有模板。
如果模板化测试用例的主体中有多个数据行，如下例所示，则模板将应用于所有行。这意味着多次执行相同的关键字，每次执行一次数据。模板化测试也很特殊，因此即使出现故障也会执行所有轮次。在正常测试中也可以使用这种continue-on-failure模式，但是通过模板化测试，模式会自动启动。
| Test Case | Action | Argument | Argument |
|---|---|---|---|
| Templated test case | [Template] | Example keyword | |
| first round 1 | first round 2 | ||
| second round 1 | second round 2 | ||
| third round 1 | third round 2 |
如果模板与for循环一起使用，则模板将应用于循环内的所有步骤。在这种情况下，continue-on-failure模式也在使用，这意味着即使存在故障，所有步骤也将使用所有循环元素执行。
| Test Case | Action | Argument | Argument | Argument |
|---|---|---|---|---|
| Template and for | [Template] | Example keyword | ||
| :FOR | ${item} | IN | @{ITEMS} | |
| ${item} | 2nd arg | |||
| :FOR | ${index} | IN RANGE | 42 | |
| 1st arg | ${index} |
测试模板的主要用途是减少数据驱动测试的重复。不是在文件中对所有测试重复相同的关键字，而是可以在设置表中仅使用它一次。下一节将更详细地说明此用法。
注意
测试模板是Robot Framework 2.5中的一项新功能。
注意
目前不能使用变量指定模板关键字。在将来的版本中可能会取消此限制。
2.2.7不同的测试用例风格
可以通过几种不同的方式编写测试用例。描述某种工作流程的测试用例可以用关键字驱动或行为驱动的方式编写。数据驱动的样式可用于使用不同的输入数据测试相同的工作流程。
关键字驱动的风格
工作流测试（例如前面描述的有效登录测试） 是根据几个关键字及其可能的参数构建的。它们的正常结构是首先将系统置于初始状态（有效登录示例中的打开登录页面），然后对系统执行某些操作（输入名称，输入密码，提交凭证），最后验证系统按预期运行（欢迎页面应该打开）。
数据驱动的风格
编写测试用例的另一种方式是数据驱动方法，其中测试用例仅使用一个更高级别的关键字，通常创建为 用户关键字，隐藏实际的测试工作流程。当需要使用不同的输入和/或输出数据测试相同的场景时，这些测试非常有用。每次测试都可以重复相同的关键字，但测试模板功能允许指定关键字只使用一次。
| Setting | Value | Value | Value |
|---|---|---|---|
| Test Template | Login with invalid credentials should fail |
| Test Case | User Name | Password | |
|---|---|---|---|
| Invalid User Name | invalid | ${VALID PASSWORD} | |
| Invalid Password | ${VALID USER} | invalid | |
| Invalid User Name And Password | invalid | whatever | |
| Empty User Name | ${EMPTY} | ${VALID PASSWORD} | |
| Empty Password | ${VALID USER} | ${EMPTY} | |
| Empty User Name And Password | ${EMPTY} | ${EMPTY} |
上面的示例有六个单独的测试，每一个都是无效的用户/密码组合，下面的示例说明了如何只对一个测试进行所有组合。使用测试模板时，即使出现故障，也会执行测试中的所有轮次，因此这两种样式之间没有真正的功能差异。在上面的示例中，单独的组合被命名为更容易看到他们测试的内容，但是大量的这些测试可能会弄乱统计数据。使用哪种风格取决于具体场景和个人偏好。
| Test Case | User Name | Password | |
|---|---|---|---|
| Invalid Password | [Template] | Login with invalid credentials should fail | |
| invalid | ${VALID PASSWORD} | ||
| ${VALID USER} | invalid | ||
| invalid | whatever | ||
| ${EMPTY} | ${VALID PASSWORD} | ||
| ${VALID USER} | ${EMPTY} | ||
| ${EMPTY} | ${EMPTY} |
提示
在上述两个示例中，列标题已更改为与数据匹配。这是可能的，因为在第一行中忽略除第一个之外的其他单元。
行为驱动的风格
也可以将测试用例编写为非技术项目利益相关者必须理解的要求。这些可执行要求通常称为验收测试驱动开发 （ATDD）的基石。
编写这些需求/测试的一种方法是由行为驱动开发（BDD）推广的Given-When-Then风格。在以这种方式编写测试用例时，初始状态通常用一个以单词Given开头的关键字表示，操作用以When开头的关键字，并用以Then开头的关键字来描述期望 。如果某个步骤有多个操作，则可以使用以And开头的关键字。
| Test Case | Step |
|---|---|
| Valid Login | Given login page is open |
| When valid username and password are inserted | |
| and credentials are submitted | |
| Then welcome page should be open |
忽略Given/When/Then/AND前缀
如果找不到与全名匹配的关键字，则在搜索匹配关键字时删除Given，When，Then和And前缀。这适用于用户关键字和库关键字。例如，在以上示例中打开给定登录页面可以实现为具有或不具有单词Given的用户关键字。忽略前缀还允许使用具有不同前缀的相同关键字。例如 Welcome page should be open也可以用作And welcome page should be open。
将数据嵌入关键字
在编写具体示例时，能够将实际数据传递给关键字实现是很有用的。用户关键字通过允许将参数嵌入关键字名称来支持此功能。
