九、RobotFramework--执行测试用例

声明：本文搬运自官方操作文档，仅用作学习，有错误的地方欢迎指正。
官方文档链接：RobotFramework--执行测试用例

3 执行测试用例

3.1 基本使用

Robot Framework测试用例从命令行执行，最终结果默认情况下是 XML 格式的输出文件以及HTML报告和日志。执行后，输出文件可以与rebot工具进行组合，否则将进行后处理。

3.1.1 开始测试执行

概要

pybot|jybot|ipybot [options] data_sources 
python|jython|ipy -m robot.run [options] data_sources 
python|jython|ipy path/to/robot/run.py [options] data_sources 
java -jar robotframework.jar [options] data_sources

测试执行通常开始使用pybot,jybot或ipybot。这些脚本是相同的，但第一个执行测试使用Python，第二个使用Jython，最后一个使用IronPython。或者，也可以使用robot.run，无论是作为模块或脚本解释器，或使用独立的JAR分布。

无论执行方法如何，要执行的测试数据的路径都要在命令后作为参数给出。此外，不同的命令行选项可用于以某种方式更改测试执行或生成输出。

指定要执行的测试数据

Robot Framework测试用例在文件和目录中创建，它们通过将有关文件或目录的路径交给所选的运行脚本来执行。路径可以是绝对的，或者执行测试的相对路径。给定的文件或目录会创建顶级测试套件并以文件或目录的名称作为顶级测试套的名称，除非使用--name选项指定名称。下面的例子说明了不同的执行方式。请注意，在这些以及本节中的其他示例中仅使用pybot脚本，但可以类似地使用其他执行方法。

pybot test_cases.html pybot path/to/my_tests/ pybot c:\robot\tests.txt

也可以同时传入多个测试用例文件或目录路径，用空格隔开。Robot Framework会自动创建顶级测试套件，指定的文件和目录将成为其子测试套件。创建的测试套件的名称来自子套件名称，通过（&）和空格连接。例如，下面第一个例子中的顶级套件的名称是My Tests & Your Tests。这些自动创建的名称通常相当长和复杂。因此，在大多数情况下，最好使用*--name*选项来覆盖它，如下第二个例子：

pybot my_tests.html your_tests.html pybot --name Example path/to/tests/pattern_*.html

3.1.2 命令行

Robot Framework提供了许多命令行选项，可用于控制测试用例的执行方式和生成什么输出。本节解释了选项语法，以及实际存在哪些选项。如何使用它们在本章的其他地方讨论。

使用选项

使用选项时，必须在流道脚本和数据源之间始终给出这些选项。例如：

pybot -L debug my_tests.txt pybot --include smoke --variable HOST:10.0.0.42 path/to/tests/

短和长格式

选项总是有一个长名，如*--name*，最常需要的选项也有一个简短的名称，如*-N*。除此之外，只要长期选项是独一无二的就可以缩短。例如，--logle DEBUG有效，而-lo log.html无效，因为前者只匹配--loglevel，但后者匹配几个选项。手动执行测试用例时，短期和缩短的选项是实用的，但在start-up脚本中建议使用长选项，因为它们更容易理解。

长选项格式不区分大小写，便于以易于阅读的格式编写选项名称。例如--SuiteStatLevel相当于--suitestatlevel，但更易读。

设置选项值

大多数选项都需要一个值，该值在选项名称后给出。短选项和长选项都接受与具有空格的选项名称分离的值，像--include tag或``-i tag。例如长选项分隔符可以是等值符号，如--include=tag，然而对于短选项分隔符可以省略，如-itag。

有些选项可以指定几次。例如设置两个变量--variable VAR1:value --variable VAR2:another。如果只使用一个值的选项多次使用，则最后给出的值是有效的。

选项值作为单个选项

许多选项携带参数视为简单的模式。这意味着*和？可以用作特殊字符，以便前者匹配任何字符串（甚至是空字符串），后者匹配任何单个字符。例如--include prefix-*匹配所有以prefix-开头的标签，--include a???匹配四个字符长且以a开头的任何标签

3.1.3 测试结果

命令行输出

测试执行中最明显的输出是命令行中显示的输出。所有已执行的测试套件和测试用例及其状态均实时显示在那里。下面的示例显示了执行仅具有两个测试用例的简单测试套件的输出：

============================================================================== 
Example test suite 
============================================================================== 
First test :: Possible test documentation                             | PASS | 
------------------------------------------------------------------------------ 
Second test                                                           | FAIL | 
Error message is displayed here 
============================================================================== 
Example test suite                                                    | FAIL | 
2 critical tests, 1 passed, 1 failed 2 tests total, 1 passed, 1 failed 
============================================================================== 
Output:  /path/to/output.xml 
Report:  /path/to/report.html 
Log:     /path/to/log.html

从Robot Framework 2.7 开始，每当测试用例中的顶级关键字结束时，控制台上也会显示通知。如果关键字通过，则使用绿点：如果失败，则使用红色 F。这些标记写在行的末尾，当测试结束时，它们被测试状态覆盖。如果控制台输出重定向到文件，则将禁用编写标记。

生成输出文件

命令行输出非常有限，通常需要单独的输出文件来审查测试结果。如上所示，默认生成三个输出文件。第一个是XML格式，包含有关测试执行的所有信息。第二个是更高级别的报告，第三个是更详细的日志文件。这些文件和其他输出文件在不同的输出文件部分详细讨论。

返回码

运行脚本使用返回码将总体测试执行状态传达给运行它们的系统。当执行成功启动且没有关键测试失败时，返回码为零。所有返回码见下表。

image.png

执行后应始终轻松提供返回码，从而便于自动确定整体执行状态。例如，在 bash shell中，返回码是特殊变量$?，在 Windows 中，返回码为变量%ERRORLEVEL%。如果使用一些外部工具运行测试，请咨询其文档以了解如何获取返回码。

从Robot Framework 2.5.7 开始，即使使用--NoStatusRC命令行选项存在严重故障，返回码也可以设置为 0。例如在持续集成服务器中，在确定测试执行的整体状态之前需要处理结果。

注意
同样的返回码也用于rebot。

执行期间的错误和警告

在测试执行过程中可能会出现意想不到的问题，如无法导入库、资源文件或关键字被弃用。根据严重程度，此类问题被归类为错误或警告，并将其写入控制台（使用标准错误流），显示在日志文件中的Test Execution Errors部分，并写入Robot Framework自己的系统日志中。通常，这些错误是由Robot Framework核心生成的，但库可以使用日志级别 WARN来编写警告。下面的示例说明了日志文件中的错误和警告的外观。

20090322 19:58:42.528 ERROR Error in file '/home/robot/tests.html' in table 'Setting' in element on row 2: Resource file 'resource.html' does not exist
20090322 19:58:43.931 WARN Keyword 'SomeLibrary.Example Keyword' is deprecated. Use keyword Other Keyword instead.

3.1.4 转义复杂字符

由于空格用于将选项分隔，因此在选项值中使用是有问题的。某些选项（如--name）会自动将下划线转换为空格，但其它空格必须要转义。此外，许多特殊字符在命令行上使用很复杂。因为用反斜杠或引号来转义复杂的字符并不总是正常运行，Robo tFramework有自己的通用转义机制。另一种可能性是使用参数文件，其中选项可以在纯文本格式中指定。这两种机制在执行测试和处理后输出时都有效，而且一些外部支持工具具有相同或类似的功能。

在Robo tFramework的命令行转义机制中，有问题的字符通过自由选择的文本转义。要使用的命令行选项是--escape（-E），*它采取的格式参数what:with，what是要转义什么字符，with是字符要被转义成什么。可以转义的字符列表如下：

image.png

以下示例使语法更加清晰。在第一个示例中，元数据 X 被赋值为Value with spaces，在第二个示例中，变量${VAR}被分配到"Hello, world!"

--escape space:_ --metadata X:Value_with_spaces -E space:SP -E quot:QU 
-E comma:CO -E exclam:EX -v VAR:QUHelloCOSPworldEXQU

请注意，所有给定的命令行参数（包括测试数据的路径）都转义了。因此，需要谨慎选择转义字符序列。

3.1.5 参数文件

有问题的字符通常可以很容易地使用参数文件处理。这些文件可以包含命令行选项和测试数据路径，每行一个。它们与*--argumentfile*选项（短选项-A）以及可能的其他命令行选项一起使用。参数文件可以包含任何字符而不转义，但行的开头和结尾的空间被忽略。以(#) 开头的空行和行被忽略：

--doc This is an example (where "special characters" are ok!) 
--metadata X:Value with spaces 
--variable VAR:Hello, world! 
# This is a comment 
path/to/my/tests

注意
要在参数文件中使用非 ASCII 字符，必须使用 UTF-8 编码保存。

参数文件的另一个重要用途是按特定顺序指定输入文件或目录。如果字母顺序默认执行顺序不合适，则此非常有用：

--name My Example Tests 
tests/some_tests.html tests/second.html 
tests/more/tests.html tests/more/another.html 
tests/even_more_tests.html

当在命令行上使用参数文件时，其内容被放置在参数文件选项所在的同一位置的原始参数列表中。参数文件可以单独使用，以便它们包含测试数据的所有选项和路径，也可以与其他选项和路径一起使用。可以多次甚至递归地使用--argumentfile选项：

pybot --argumentfile all_arguments.txt 
pybot --name example --argumentfile other_options_and_paths.txt 
pybot --argumentfile default_options.txt --name example my_tests.html 
pybot -A first.txt -A second.txt -A third.txt some_tests.tsv

特殊值STDIN可用于读取标准输入流中的参数而不是文件。在用脚本生成参数时非常有用：

generate_arguments.sh | pybot --argumentfile STDIN 
generate_arguments.sh | pybot --name Example --argumentfile STDIN mytest.txt

从标准输入读取参数是Robo tFramework 2.5.6 的新功能。

3.1.6 获取帮助或版本信息

无论是执行测试用例还是处理后输出时，都有可以获得命令行帮助的选项--help及其短版本- h.这些帮助文本具有简短的一般概述，并简要解释了可用的命令行选项。

所有运行脚本也支持获得版本信息与选项 --version。此信息还包含 Python 或 Jython 版本和平台类型：

$ pybot --version 
Robot Framework 2.7 (Python 2.6.6 on linux2) 
$ jybot --version Robot Framework 2.7 (Jython 2.5.2 on java1.6.0_21) 
C:>rebot --version 
Rebot 2.7 (Python 2.7.1 on win32)

3.1.7 创建start-up脚本

测试用例通常由连续集成系统或其他一些机制自动执行。在这种情况下，需要有一个脚本来开始测试执行，也可能以某种方式用于处理后的输出。在手动运行测试时，类似的脚本也很有用，特别是当需要大量的命令行选项或设置测试环境很复杂时。

在类似 UNIX 环境中，shell脚本为创建自定义启动脚本提供了简单而强大的机制。也可以使用 Windows 批处理文件，但它们更有限且通常也更复杂。一种独立于平台的替代方案是使用 Python 或其他高级编程语言。无论语言如何，建议使用长选项名称，因为它们比短名称更容易理解。

在第一个示例中，相同的 Web 测试使用不同的浏览器执行，随后合并结果。这很容易使用shell脚本，因为实际上你只是一个接一个列出所需的命令：

#!/bin/bash 
pybot --variable BROWSER:Firefox --name Firefox --log none --report none --output out/fx.xml login 
pybot --variable BROWSER:IE --name IE --log none --report none --output out/ie.xml login 
rebot --name Login --outputdir out --output login.xml out/fx.xml out/ie.xml

使用 Windows 批文件执行上述示例也不是很复杂。重要的是，由于pybot和rebot是作为批处理文件实现的，因此在从另一批文件运行它们时必须使用call。否则当第一批文件完成时执行将结束。

@echo off 
call pybot --variable BROWSER:Firefox --name Firefox --log none --report none --output out\fx.xml login 
call pybot --variable BROWSER:IE --name IE --log none --report none --output out\ie.xml login 
call rebot --name Login --outputdir out --output login.xml out\fx.xml out\ie.xml

在下一个示例中，lib目录下的 JAR 文件在开始测试执行之前放入CLASSPATH中。在这些示例中，start-up脚本要求将执行测试数据的路径作为参数提供。也可以自由使用命令行选项，即使脚本中已经设置了某些选项。所有这一切都是相对直截了当的使用 bash：

#!/bin/bash 
cp=. 
for jar in lib/*.jar; do
  cp=$cp:$jar 
done 
export CLASSPATH=\$cp 
jybot --ouputdir /tmp/logs --suitestatlevel 2 \$*

使用 Windows 批次文件实现此操作稍微复杂一些。困难的部分是在 For 循环中设置包含所需 JAR 的变量，因为出于某种原因，如果没有帮助函数，这是不可能的。

@echo off 
set CP=. for %%jar in (lib\*.jar) do (
  call :set_cp %%jar 
) 
set CLASSPATH=%CP% 
jybot --ouputdir c:\temp\logs --suitestatlevel 2 %* 
goto :eof 
:: Helper for setting variables inside a for loop 
:set_cp
  set CP=%CP%;%1 
goto :eof

修改Java startup参数

有时使用 Jython 时需要更改 Java 启动参数。最常见的案例是增加 JVM 最大内存大小，因为当输出非常大时，默认值可能不足以创建报告和日志。配置JVM选项的方法有几种：

1. 直接修改 Jython 启动脚本（jpython shell 脚本或jython .bat批文件）。这是永久生效。
2. 设置JYTHON_OPTS环境变量。这可以在操作系统级别或自定义启动脚本中永久执行。
3. 将所需的Java参数机智-J选项传递给Jython启动脚本，这些脚本将将其转发到Java。使用直接入口点时，这特别容易：

jython -J-Xmx1024m -m robot.run some_tests.txt

3.1.8 问题调试

测试用例可能会失败，因为测试中的系统不能正常工作，在这种情况下，测试发现了错误，或者因为测试本身有bug。失败的错误消息显示在命令行输出和报告文件中，有时仅错误消息就足以定位问题。通常需要日志文件，因为包含了其它信息，会显示到底哪些关键字失败。

当测试程序导致故障时，错误信息和日志应该足以找到原因。即使找不到，测试库也不会提供足够的信息，需要增强。在这种情况下，手动运行测试也可能显示有关此问题的更多信息。

测试用例本身或关键字引起的故障有时很难调试。例如，如果错误信息显示使用关键字的参数数量错误则修复问题显然很容易，但如果关键字丢失或以意外方式失败，则查找原因可能很困难。查找更多信息的第一个地方是日志文件中的执行错误部分。例如，有关测试库导入失败的错误很可能解释为什么测试由于缺少关键字而失败。

如果默认日志文件没有提供足够的信息，则可以执行日志级别较低的测试。例如，使用DEBUG级别记录代码中发生故障的回溯，当问题出在单个关键字中时，此信息是无价的。

如果日志文件仍然没有足够的信息，则查看系统日志提供的信息。也可以在测试用例中添加一些关键字，看看发生了什么，特别是内置关键字Log和Log Variables。如果无效可以发送邮件或其它方式获取帮助。

3.2 测试执行

本节描述了如何执行从解析的测试数据中创建的测试套件结构，如何在失败后继续执行测试用例，以及如何优雅地停止整个测试执行。

3.2.1 执行流程

已执行的套件和测试

测试用例始终在测试套件中执行。测试套是由有测试的测试用例文件直接创建，而从目录创建的套件有具有测试或自己的子套件的子测试套件。默认情况下执行套件中的所有测试都会运行，但使用选项*--test*, *--suite*, *--include* 和 *--exclude*。不包含任何测试的套件被忽略。

执行从顶级测试套件开始。如果套件有测试，它们会逐一执行，如果套件有套件，则会以深度第一顺序递归执行。执行单个测试用例时，它包含的关键字将按顺序运行。通常，如果任何关键字出现故障，当前测试的执行将结束，但也可能在失败后继续执行。以下部分讨论了确切的执行顺序以及设置和拆解如何影响执行。

设置和拆卸

设置和拆卸可以在测试用例和测试套件级别定义。

套件设置

如果测试套件有设置，则将在测试和子套件之前执行。如果套件设置通过，测试将正常进行；失败则所有测试用例的套件及其子套件都标记为失败，而父套件设置的消息设置则失败。子测试套件中的测试和可能的套件设置和拆解不执行。

套件设置通常用于设置测试环境。由于如果套件设置失败，测试不会运行，因此很容易使用套件设置来验证环境是否处于可以执行测试的状态。

套件拆解

如果测试套件有拆解，则在其所有测试用例和子套件之后执行。无论测试状态如何，即使匹配的套件设置失败也会执行套件拆解。如果套件拆解失败，则套件中的所有测试在报告和日志中标记为失败。

套件拆解主要用于执行后清理测试环境。为了确保完成所有这些任务，即使其中一些任务失败，拆解中使用的所有关键字也会执行。

测试设置

测试设置在测试用例的关键字之前执行。如果设置失败则关键字不会执行。测试设置的主要用途是为该特定测试用例设置环境。

测试拆解

测试用例执行后，可能会执行测试拆解。无论测试状态如何，也无论测试设置是否失败，它都会执行。

与套件拆解类似，测试拆解主要用于清理活动。此外，即使他们的一些关键字失败也会被完全执行。

执行命令

测试套件中的测试用例按照测试用例文件中定义的相同顺序执行。更高级别测试套件内的测试套件根据文件或目录名称按不区分大小写字母顺序执行。如果传入多个文件 和/或 目录，则按传入顺序执行。

如果需要在目录内设置测试套件的执行顺序，可以在文件和目录名称中增加前缀（如01和02）。如果这些前缀与具有两个下划线的套件的基本名称分开，则此类前缀不包括在生成的测试套件名称中：

01__my_suite.html -> My Suite 
02__another_suite.html -> Another Suite

如果套件内测试套件的按字母顺序排列有问题，则一个好的解决方法是按照要求的顺序单独提供测试套件。这很容易导致过长的启动命令，但参数文件允许列出文件，即每行一个文件。

也可以使用--runmode选项随机化执行顺序。

3.2.2 失败继续

通常当任何关键字失败时，测试用例都会立即停止。此行为缩短了测试执行时间，并防止如果测试中的系统处于不稳定状态导致后续关键字挂起或其他问题。缺点是通常随后的关键字会提供更多有关系统状态的信息。

在Robot Framework 2.5 之前，处理故障以便测试执行不会立即终止的唯一方法是使用内置关键字Run Keyword And Ignore Error、 Run Keyword 和Expect Error。为此目的使用这些关键字通常会为测试用例增加额外的复杂性，在Robot Framework 2.5 中添加以下功能，以便在失败后继续使用变得更加容易。

关键字中的特殊故障

库关键字使用异常报告失败，并且可以使用特殊例外来告诉核心框架即使失败也可以继续执行。如何创建异常在测试库 API 章节中解释。

当测试结束时，如果有一个或多个连续失败，测试将被标记为失败。如果存在多个故障，则所有故障都将在最终错误消息中列举：

Several failures occurred:
1) First error message.
2) Second error message ...

如果连续失败后发生正常故障，测试执行也会结束。此外这种情况下，所有故障都将列在最终错误消息中。

失败关键字的返回值（可能分配给变量）始终是 Python None。

运行关键字并继续运行失败关键字

内置关键字Run Keyword And Continue On Failure allows将任何故障转换为连续故障。这些故障由框架处理的方式与源自库关键字的连续故障。

拆解时继续自动执行

为了确保所有清理活动都得到处理，在测试和套件拆解中自动打开故障模式。在实践中这意味着在拆解中，所有级别的关键字始终执行。

测试有模板时执行所有顶级关键字

使用测试模板时，所有数据行始终执行以确保测试所有不同的组合。在此使用中，继续使用仅限于顶级关键字，如果存在不连续失败则执行正常结束。

3.2.3 优雅地停止测试执行

有时需要在所有测试完成之前停止测试执行，但要创建日志和报告。下面解释了如何实现此目的的不同方法。在所有这些情况下，剩余的测试用例被标记为失败。

注意
这些功能大多是新的Robot Framework2.5。仅在早期版本中支持失败时退出模式。

按Ctrl-C

当在运行测试的控制台中按下Ctrl-C时，执行将停止。在 Python 上运行测试时执行会立即停止，但Jython下是在当前执行关键字结束之后结束。

如果再次按下Ctrl-C，执行将立即结束，并且不会创建报告和日志。

使用信号

在类似 Unix 的机器上，使用信号 INT和TERM可以终止测试执行。从命令行发送使用kill命令

信号对Jython与按压Ctrl-C效果相同。同样，第二个信号也是强制终止。

使用关键字

执行也可以通过执行的关键字停止执行。为此有一个单独的内置关键字*Fatal Error*，自定义关键字在失败时可以使用。

退出

如果选项--runmode与值ExitOnFailure（忽略大小写）一起使用，则如果关键测试失败且其余测试被标记为失败，则测试执行将立即停止。

处理拆解

默认情况下，即使使用上述方法之一停止测试执行，也执行已启动的测试和套件的拆解。这使得无论执行如何结束，清理活动都得以运行。

从Robot Framework 2.5.2 开始，如果使用*--runmode SkipTeardownOnExit*命令行选项，则在停止执行时跳过拆卸。如果清理需要大量时间可以使用。

3.3 后置输出

在测试执行过程中生成的XML 输出文件可以在测试后由rebot工具进行后期处理，是Robot Framework的一个组件。当在测试执行过程中会自动调用，生成测试报告和日志，也可以在执行后单独使用。

3.3.1 使用rebot工具

概要

rebot|jyrebot|ipyrebot [options] robot_outputs 
python|jython|ipy -m robot.rebot [options] robot_outputs 
python|jython|ipy path/to/robot/rebot.py [options] robot_outputs 
java -jar robotframework.jar rebot [options] robot_outputs

rebot是在Python运行，也可以在Jython和IronPython分别运行jyrebot和ipyrebot。建议在可用时使用rebot，因为它比其它方案快得多。除了使用这些脚本外，还可用于使用rebot.rebot为入口作为模块或脚本使用任何解释器，或使用独立的JAR包。

指定选项和参数

使用rebot的基本语法与开始测试执行时完全相同，并且大多数命令行选项也相同。主要区别在于，rebot的参数是XML 输出文件，而不是测试数据文件或目录。

rebot返回码

rebot的返回代码与运行测试的完全相同。

3.3.2 创建不同的报告和日志

您可以使用rebot创建在测试执行过程中自动创建的相同报告和日志。当然，创建完全相同的文件是不明智的，然而如果有一个报告包括所有测试用例，另一个只有一些测试子集：

rebot output.xml 
rebot path/to/output_file.xml 
rebot --include smoke --name Smoke_Tests c:\results\output.xml

另一种常见用途是，在运行测试时只创建输出文件（生成日志和报告可以禁用选项--log NONE 和 --report NONE），并在以后生成日志和报告。例如，测试可以在不同的环境中执行，将文件输出到汇总的位置，并在那里创建报告和日志。在 Jython 上运行测试生成报告和日志需要大量时间，此方法也可以有效执行。禁用生成日志和报告，并在以后使用rebot生成，可以节省大量时间同时减少内存的使用。

3.3.3 组合输出

rebot最重要的特点是它能够结合来自不同测试执行的输出。例如，此功能允许在不同的环境中运行相同的测试用例，并统一生成报告。组合输出很简单，只需要给出几个输出文件作为参数：

rebot output1.xml output2.xml 
rebot outputs/*.xml

当输出组合在一起时，将创建一个新的顶级测试套件以定义输出文件中的测试套件是其子套件。执行多个测试数据文件或目录时效果相同，在这种情况下，创建顶级测试套件的名称是将子套件名称用（&） 和空格拼接。自动生成名称不大好，建议使用*--name*指定一个有意义的名称：

rebot --name Browser_Compatibility firefox.xml opera.xml safari.xml ie.xml 
rebot --include smoke --name Smoke_Tests c:\results\*.xml

3.4 配置执行

本节讲可用于配置测试执行或后处理输出的不同命令行选项。下一节将讨论与生成输出文件相关的选项。

3.4.1 选择测试用例

Robot Framework提供了几个命令行选项，用于选择执行哪些用例。当使用rebot工具处理后输出时，相同的选项也有效。

通过测试套和测试名称

测试套件和测试用例可以按其名称选择，命令选项*--suite (-s)* 和 *--test (-t)*。这两种选择都可用于多次选择多个测试套件或案例。这些选项的参数是case- and space-insensitive，也可以有匹配多个名称的简单模式。如果同时使用*--suite*和*--test*选项，则只选择匹配套件和匹配名称的测试用例。

--test Example 
--test mytest --test yourtest 
--test example* 
--test mysuite.mytest 
--test *.suite.mytest 
--suite example-?? 
--suite mysuite --test mytest --test your*

注意
使用长名称（例如mysuite.mytest）选择测试用例适用于Robot Framework 2.5.6 及以上版本。

使用*--suite*选项与仅执行适当的测试用例文件或目录大致相同。一个主要的好处是有可能选择基于父套件的套件。其语法是用点分离父子套件名。在这种情况下，可以执行父套件的设置和拆解。

--suite parent.child --suite myhouse.myhousemusic 
--test jack*

在创建测试用例时，使用*--test*选项选择单个测试用例非常实用，但在自动运行测试时非常有限。在这种情况下，*--suite*选项比较好，但按标签名称选择测试用例更为灵活。

通过标签名

可以通过标签名称（--include (-i) 和 --exclude (-e)）选项来包括和排除测试用例。前者只选择具有匹配标记的测试用例，而后者不选择匹配标记的测试用例。如果同时使用两者，则只选择与前一个选项匹配的标记的测试，而非后者。

--include example 
--exclude not_ready 
--include regression --exclude long_lasting

--include和--exclude都可以多次用于匹配多个标签，它们的参数可以是简单模式。这些情况也适用选择测试用例的规则，以便选择具有标记匹配的任何包含模式的测试用例，并且不选择具有标记匹配排除模式的测试。还可以通过将标签用 &或AND（不区分大小写）分开来选择仅具有两个或多个指定标签的测试用例。从Robot Framework 2.1.3 开始，只能使用某个标签进行测试，但无需任何其他测试，可以通过将这些标签用NOT（不区分大小写）分开来选择。如果匹配到多个NOT，则测试用例不选择。

--include req-*
--include regressionANDiter-42 
--include tag1&tag2&tag3&tag4 
--exclude regressionNOTowner-* 
--include tag1NOTtag2NOTtag3&tag4  (includes tests which have `tag1`, but not tests which additionally have `tag2` or both tags `tag3` and `tag4`)

通过标签选择测试用例是一种非常灵活的机制，允许许多有趣的可能性：

• 在其他测试之前要执行的测试的子集可以标记为smoke，并执行--include smoke。
• 未完成的测试可以承诺使用标记not_ready的版本控制，并在测试执行之外执行使用--exclude not_ready。
• 测试可以用iter-，其中指定当前迭代的数量，执行所有测试用例后，单独生成包含特定迭代测试的报告（例如，rebot --include iter-42 output.xml）。

当未匹配到测试

默认情况下，当没有测试匹配选择标准时，测试执行失败，比如报错：

[ ERROR ] Suite 'Example' with includes 'xxx' contains no test cases.

由于没有生成输出，因此，如果执行测试并自动处理结果可能会有问题。幸运的是，在此情况下可以使用命令行选项*--RunEmptySuite*强制执行套件，这样会正常创建输出，但没有执行测试。待执行目录或测试用例文件为空时也可以使用相同的选项来更改行为。

在用rebot处理输出文件时也会出现类似的情况。任何测试都可能与使用的筛选标准相匹配，或者输出文件一开始没有包含任何测试。默认情况下，执行rebot在这些情况下失败，但它有一个--ProcessEmptySuite选项可用于更改行为。实践中此选项与--RunEmptySuite相同。

注意
--RunEmptySuite是在RobotFramework2.6中加入,--ProcessEmptySuite是在2.7.2中加入

3.4.2 设置边界

测试执行的最终结果由关键测试决定。只要有关键测试失败，则整个测试结果状态为失败。但是非关键测试用例失败，总体状态仍为通过。

默认情况下所有测试用例都至关重要，但可以通过--critical (-c) and --noncritical (-n)选项来修改。这些选项指定哪些测试用例根据标签被视为关键，类似于选择测试用例标签中的--include和--exclude。如果仅使用--critical，则具有匹配标记的测试用例为关键。如果仅使用*--noncritical*，则未匹配标记的测试为关键。如果两者同时使用，则仅测试带有关键标记的，但是未使用关键标记也会被视为关键标记。这两种选项都接受简单模式：

--critical regression 
--noncritical not_ready 
--critical iter-* --critical req-* --noncritical req-6??

设置临界性的一般是测试用例尚未准备好或测试功能仍在测试执行中开发中。当然，这些测试完全可以使用--exclude选项在测试执行时排除掉，但将它们作为非关键测试，可让您查看它们何时开始通过。

从Robot Framework 2.1临界度设置开始不会存储。当使用rebot处理后输出时，如果要保持相同的临界性也需要使用--critical和/或--noncritical：

# Use rebot to create new log and report from the output created during execution 
pybot --critical regression --outputdir all my_tests.html 
rebot --name Smoke --include smoke --critical regression --outputdir smoke all/output.xml   

# No need to use --critical/--noncritical when no log or report is created 
jybot --log NONE --report NONE my_tests.html 
rebot --critical feature1 output.xml

3.4.3 设置元数据

设置名称

当Robot Framework解析测试数据时，测试套件名称由文件和目录名称创建。但是，顶层测试套件的名称可以用命令行选项 --name (-N)覆盖。给定名称中的下划线自动转换为空格，名称中的单词大写。

设置文档

除了在测试数据中定义文档外，还可以从命令行中提供顶层套件的文档，并提供选项*--doc* (*-D*)。给定文档中的下划线转换为空格，并且它可以包含简单的HTML 格式。

设置 元数据

free测试套件元数据也可以使用命令行选项--metadata (-M)。参数必须以格式名称：值，其中设置元数据的名称和值是其值。名称和值中的下划线转换为空格，后者可能包含简单的HTML 格式。此选项可用于多次设置多个元数据。

设置标签

命令行选项--settag (-G)可用于为所有已执行的测试用例设置给定标记。此选项可用于多次设置多个标签。

3.4.4 调整库搜索路径

当测试库投入使用时，Robot Framework使用 Python 或 Jython 解释器从系统导入实施库的模块。查找模块的位置称为 PYTHONPATH，在Jython 或使用JAR包运行时，还可以使用 Java CLASSPATH。

调整库搜索路径以便找到库是成功执行测试的一个要求。除了查找测试库外，搜索路径还用于查找命令行设置的监听器。有各种方法来改变PYTHONPATH和CLASSPATH，但无论选择那种方法，建议使用自定义启动脚本。

自动在PYTHONPATH搜索

Python 和 Jython 安装自动将自己的库目录放入 PYTHONPATH中。这意味着使用 Python 自己的系统包的测试库会自动安装到库搜索路径中的位置。Robot Framework还将包含其标准库的目录和从 PYTHONPATH执行测试的目录放入 PYTHONPATH 中。

设置PYTHONPATH

系统中有几种方法可以更改PYTHONPATH，但最常见的方法是在测试执行之前设置使用此名称的环境变量。Jython 实际上通常不使用PYTHONPATH环境变量，但无论解释器是什么Robot Framework都将其中列出的位置添加到库搜索路径中。

设置CLASSPATH

类路径用于Jython或使用独立jar时。

使用 Jython 时，设置CLASSPATH环境变量的方法似于 PYTHONPATH。请注意，即使使用Java执行的库和监听器，也可以使用PYTHONPATH， 未必一定使用CLASSPATH。

在使用独立jar包时，由于java-jar命令不读取 CLASSPATH 环境变量，因此设置上会有点区别。在这种情况下，有两种不同的配置CLASSPATH，如下：

java -cp lib/testlibrary.jar:lib/app.jar:robotframework-2.7.1.jar org.robotframework.RobotFramework example.txt   

java -Xbootclasspath/a:lib/testlibrary.jar:lib/app.jar -jar robotframework-2.7.1.jar example.txt

使用--pythonpath选项

Robot Framework还有命令行选项--pythonpath (-P)添加到 PYTHONPATH 的目录或档案。可以通过用冒号(:)分隔来提供多条路径或多次使用此选项。给定路径也可以是匹配多个路径的glob模式，但通常必须转义。

--pythonpath libs/ 
--pythonpath /opt/testlibs:mylibs.zip:yourlibs 
--pythonpath mylib.jar --pythonpath lib/STAR.jar --escape star:STAR

3.4.5 设置变量

变量可以通过命令行设置，既可以使用单独的--variable (-v) 选项也可以通过变量文件的--variablefile (-V)选项。变量和变量文件在单独的章节中解释，以下示例说明了如何使用这些选项：

--variable name:value 
--variable OS:Linux --variable IP:10.0.0.42 
--variablefile path/to/variables.py 
--variablefile myvars.py:possible:arguments:here 
--variable ENVIRONMENT:Windows --variablefile c:\resources\windows.py

3.4.6 Dry Run

Robot Framework支持所谓的dry run模式，否则测试将正常运行，但来自测试库的关键字根本不执行。dryrun模式可用于验证测试数据：如果dryrun通过，数据应在句法上正确。此模式使用选项*--runmode DryRun*（不区分大小写），并且从Robot Framework 2.5 开始支持该模式。

干运行执行可能由于以下原因而失败：

• 使用找不到的关键字。
• 使用参数数量错误的关键字。
• 使用语法无效的用户关键字。

除这些故障外，还显示正常的执行错误，例如，当无法解决测试库或资源文件导入问题时。

注意
dryrun模式无法验证变量。此限制可能会在以后的版本中取消。

3.4.7 随机执行命令

*--runmode*选项也可用于随机化测试执行顺序。这是使用下面解释的不同值完成的。
random:test
每个测试套件内的测试用例按随机顺序执行。
random:suite
所有测试套件均按随机顺序执行，但套件内的测试用例均按定义顺序运行。
random:all
测试用例和测试套件都是随机执行的。

pybot --runmode random:test my_test.txt

3.4.8 控制控制台输出

控制台宽度

控制台中测试执行输出的宽度可以使用选项--monitorwidth (-W)设置。默认宽度为 78 个字符。

提示
在许多类似UNIX的机器上，你可以使用方便的$COLUMNS变量，如-监视器宽$COLUMNS。

控制台颜色

--monitorcolors (-C)选项用于控制控制台输出中是否使用颜色。使用 Jython 时，颜色应适用于除 Windows 以外的所有其他平台。此选项有以下不区分大小写的值：
auto
当输出被写入控制台时，而不是当它重定向到文件时，颜色就会启用。这是默认值，很少需要更改它。
on
当输出重定向到文件时，也会使用颜色。对视窗没有影响。
off
颜色已禁用。
force
兼容Robot Framework2.5.5及以上。不应使用。

注意
支持 Windows 和auto模式上的颜色是Robot Framework 2.5.6 中的新功能。

3.4.9 设置监听

所谓的侦听器可用于监控测试执行。使用命令行选项--listener一起使用，指定的监听器必须在模块搜索路径中，类似于测试库

3.5 创建输出

执行测试时会创建多个输出文件，并且这些都与测试结果有点关系。本节讨论了创建哪些输出、如何配置创建以及如何微调其内容。

3.5.1 不同的输出文件

本节解释了可以创建哪些不同的输出文件，以及配置创建的路径。输出文件使用命令行选项进行配置，该选项将有关输出文件的路径作为参数进行配置。特殊值NONE（不区分大小写）用于禁用某个输出文件。

输出目录

所有输出文件都可以使用绝对路径设置，这样会被创建到指定位置，但在其他情况下，会被视为相对路径。默认输出目录是执行开始的目录，但可以通过--outputdir(-d)选项进行更改。与此选项设置的路径再次相对于执行目录，但也可以作为绝对路径给出。无论如何获得通往单个输出文件的路径，如果尚未存在，都会自动创建其父目录。

输出文件

所有测试执行结果的输出文件使用的是 XML 格式。日志和报告文件是根据输出文件生成的，输出文件也可以在测试执行后进行组合并进行后处理。

命令行选项--output (-o)决定相对于输出目录创建输出文件的路径。运行测试时，输出文件的默认名称是output.xml

当处理后输出时，除非明确使用--output (-o)选项，否则不会创建新的输出文件。

从Robot Framework 2.6 开始，在运行具有特殊值NONE的测试时，也可以禁用输出文件的创建。除调试文件外的其他输出文件会被禁用。

日志文件

日志文件包含有关 HTML 格式已执行的测试案例的详细信息。会分层显示测试套、测试案例和关键字详细信息。基本每次执行都会生成详细的执行结果。即使日志文件也有统计数据，但是这样能获取更高级的综合报告。

命令行选项--log (-l) 决定日志文件的创建位置。除非使用特殊值NONE，否则始终创建日志文件，默认名称为log.html

image

日志文件头

image

可看到关键字详细信息的日志文件

报告文件

报告文件是 HTML 格式的测试执行结果概述。有基于标签和已执行测试套件的统计数据，以及所有已执行测试案例的列表。生成报告和日志时，报告具有日志文件的链接，便于导航以获取更详细的信息。从报告中很容易看到整体测试执行状态，因为如果所有关键测试都通过其背景色为绿色，否则为亮红色。

命令行选项--report (-r)决定报告文件的创建位置。与日志文件类似，除非使用NONE值，否则始终创建报告且其默认名称为report.html。

image

测试执行成功的报告文件

image

测试执行失败的报告文件

XUnit兼容性结果文件

XUnit 结果文件包含 XUnit 兼容 XML 格式的测试运行摘要。此文件可用作处理 XUnit 数据的工具的输入。例如，Hudson 持集成服务器已内置支持此输出格式，并且可以根据此文件进行配置以生成测试历史记录。

只有明确使用命令行选项--xunitfile (-x)，才会创建 XUnit 输出文件。

调试文件

试用文件是测试执行过程中写入的纯文本文件。所有从测试库收到的信息，以及有关启动和结束测试套件、测试案例和关键字的信息都会写入。调试文件可用于监控测试执行。用起来也很简单，只需使用单独的fileviewer.py工具或UNIX这类系统的tail -f命令。

除非明确使用命令行选项--debugfile (-b)，否则不会创建调试文件。

时间戳输出文件

本节中列出的所有输出文件都可以使用选项--timestampoutputs (-T)生成时间戳。使用此选项时，会在每个文件的扩展名和基本名称之间放置YYMMDD-hhmms格式的时戳。如下面会创建输出文件output-20080604-163225.xml和mylog-20080604-163225.html：

pybot --timestampoutputs --log mylog.html --report NONE tests.html

设置标题

日志和报告的默认标题是通过使用测试日志或测试报告的名称作为级测试套件的名称生成的。自定义标题可以分别使用命令行选项--logtitle 和 --reporttitle。给定标题中的下划线自动转换为空格。

例子：

pybot --logtitle Smoke_Test_Log --reporttitle Smoke_Test_Report --include smoke my_tests/

设置背景色

默认情况下，当所有关键测试通过时，报告背景为绿色，否则是红色。这些颜色可以通过使用命令行选项--reportbackground 进行自定义，该选项以两到三种颜色以冒号分隔为参数：

--reportbackground blue:red --reportbackground green:yellow:red --reportbackground #00E:#E00

如果指定两种颜色，第一种颜色将替换默认的绿色，第二种颜色将代替默认红色。例如，可使用蓝色而不是绿色使色盲者容易区分。

如果指定三种颜色，第一种颜色将在所有测试成功时使用，第二种颜色仅在非关键测试失败时使用，最后一种颜色在发生关键故障时使用。因此，当非关键测试失败时，此功能允许使用单独的背景颜色，例如黄色。

指定的颜色用作body元素background 的CSS 属性值。该值可以原样使用，也可以是 HTML 颜色名称（如red）、十六进制值（如#F00或#FF0000），或 RGB 值（如rgb(255，0，0)）。默认的绿色和红色分别使用#9F6和#F33的十六进制值来指定。

3.5.2 日志级别

可用日志级别

日志文件中的消息可以有不同的日志级别。有些是Robot Framework本身的，但执行的关键字也可以使用不同的级别记录信息。可用日志级别为：
FAIL
当关键字失败时使用。只能由Robot Framework本身使用。
WARN
用于显示警告。它们也显示在控制台和日志文件中的测试执行错误部分，但它们不会影响测试案例状态。
INFO
正常消息的默认级别。默认情况下，此级别以下的消息不显示在日志文件中。
DEBUG
用于调试目的。例如，用于记录库在内部执行的工作。当关键字出现故障时，使用此级别自动记录代码中发生故障的位置的回溯。
TRACE
更详细的调试级别。使用此级别自动记录关键字参数和返回值。

设置日志级别

默认情况下，未记录INFO级别以下的日志消息，但此阈值可以使用命令行选项--loglevel (-L)更改。此选项将任何可用的日志级别作为参数，该级别将成为新的阈值级别。特殊值NONE也可用于完全禁用记录。

从Robot Framework 2.5.2 开始，在使用rebot处理后输出时，也可以使用--loglevel选项。例如，这允许首先使用TRACE级别运行测试，并生成较小的日志文件，以供以后使用INFO级别进行正常查看。默认情况下，执行过程中包含的所有消息也将包含在rebot 中。无法恢复执行过程中忽略的消息。

更改日志级别的另一种可能性是在测试数据中使用内置关键字Set Log Level 。它同样需要参数--loglevel选项，它也返回旧级别以便在以后恢复，例如在测试拆解。

可见的日志级别

从Robot Framework 2.7.2 开始，如果日志文件包含DEBUG或TRACE级别的消息，则右上角显示日志级别下拉框。允许用户从视图中过滤所选级别以下的消息。这在TRACE级别运行测试时非常有用。

image

显示可见日志级别下降的示例日志

下拉框默认情况为日志最低级别以便显示所有消息。默认可见日志级别可以使用--loglevel 选项在由冒号分离的正常日志级别后提供默认值：

--loglevel DEBUG:INFO

在上述示例中，测试使用级别DEBUG运行，但日志文件中的默认可见级别是INFO。

3.5.3 拆分日志

通常日志文件只是一个单一的HTML文件。当他的测试案例数量增加时，文件的大小会变大，以至于将其打开到浏览器中并不方便，甚至是不可能的。从Robot Framework 2.6 开始，可以使用--splitlog选项将部分登录文件拆分为外部文件，这些文件在需要时以透明方式加载到浏览器中。

拆分日志的主要好处是单个日志部件非常小，即使测试数据量非常大，也可以打开和浏览日志文件。小缺点是日志文件的整体大小增加。

从技术上讲，与每个测试案例相关的测试数据将保存到与主日志文件相同的文件夹中的 JavaScript 文件中。这些文件具有log-42.js其中log是主日志文件的基础名称，42是增量索引。

注意
在复制日志文件时，您还需要复制所有log.js*文件，否则某些信息将丢失。

3.5.4 配置统计数据

有几个命令行选项，可用来配置和调整*Statistics by Tag*的内容，按套件统计和按标签表测试详细信息。所有这些选项在执行测试案例和处理后输出时都有效。

配置显示套件数据

执行较深的套件结构时，Statistics by Suite的所有测试套件级别可能会使表有点难以读取。Bt 默认所有套件都显示，但您可以使用命令行选项--suitestatlevel控制此问题，该级别将显示为参数：

--suitestatlevel 3

是否包括标签数据

当使用许多标签时，Statistics by Suite可能会变得相当拥挤。如果发生这种情况，可以使用命令行选项--tagstatinclude 和 --tagstatexclude选择要显示的标记，类似于选择测试案例的--include and --exclude：

--tagstatinclude some-tag --tagstatinclude another-tag 
--tagstatexclude owner-* 
--tagstatinclude prefix-* --tagstatexclude prefix-13

生成联合标签数据

命令行选项--tagstatcombine用来生成聚合标记，这些标记结合了多个标记的统计数据。为此选项提供论据的方法有三种略有不同：
一个标签作为一个简单的模式
匹配给定模式的所有标记组合在一起。
由&或AND分离的两个或多个标签
合并后的统计数据包含包含所有列出标签的测试。标签可以作为简单的模式给出。
由NOT分隔的两个或两个以上标签
合并的统计数据包含具有第一个标签的测试，但不包括任何其他测试。在这种情况下，标签也可能是模式。
以下示例说明了这些用法，下面的图显示了在使用以下选项执行示例测试数据Statistics by Tag表显示生成的统计片段：

--tagstatcombine owner-* 
--tagstatcombine smokeANDmytag 
--tagstatcombine smokeNOTowner-janne*

image

合并标签统计示例

如上所示，默认情况下，添加的合并统计的名称由给定模式生成。在某些情况下名字看起来比较模糊，可以指定带描述性的名称。此名称是在用冒号(:)分隔 后给出的。下面的示例生成组合标记，以便报告和日志中显示的名称为Critical Tests：

--tagstatcombine *NOTnon-critical:Critical_Tests

创建标签名链接

您可以使用命令行选项--tagstatlink将外部链接添加到Statistics by Tag表。此选项的参数格式为 tag:link:name，其中tag是链接的目标标签，link是要创建的链接，name是链接名称。

tag可以是一个单一标签，但更常见的是一个简单的模式，其中匹配任何东西？匹配任何单个字符。当tag为模式时，通配符语法%N可以匹配link和*title与，其中"N"是从 1 开始的匹配索引。

以下示例说明了此选项的使用情况，下图显示了使用以下选项执行示例测试数据时Statistics by Tag表生成的统计片段：

--tagstatlink mytag:http://www.google.com:Google 
--tagstatlink jython-bug-*:http://bugs.jython.org/issue_%1:Jython-bugs 
--tagstatlink owner-*:mailto:%[email protected]?subject=Acceptance_Tests:Send_Mail

image

标签名称链接示例

为标签添加文档

标签可以给一个文档与命令行选项--tagdoc，如果携带参数可以使用tag:doc。标签名中的tag可以声明到文档中，它也可以是一个简单的模式匹配多个标签。doc是指定的文档。文档中的下划线会自动转换为空格，并且它也可以包含HTML 格式。

给定的文档会在Test Details by Tag表中匹配标签，并作为Statistics by Tag表中这些标签的工具提示。如果一个标签获得多个文档，会使用&拼接。

例子：

--tagdoc mytag:My_documentation 
--tagdoc regression:*See*_http://info.html 
--tagdoc owner-*:Original_author

3.5.5 从输出移出关键字

输出文件的大部分内容来自关键字，尤其是其日志信息。创建更高级别的报告时，根本不需要日志文件，还占用空间。如果日志文件包含for循环或多次重复执行关键字的结构，则可能增长更大。

这些情况下，命令行选项--removekeywords可用于处理不必要的关键字。它可以在执行测试和rebot时使用，但前一种情况下关键字不会从输出文件中删除。除非在ALL模式下，否则不会被删除包含警告的关键字。

该选项具有以下操作模式：
ALL
无条件地从所有关键字中删除数据。
PASSED
从已通过且不包含警告的测试案例中删除关键字数据。在大多数情况下，在此之后创建的日志文件包含足够的信息来调查可能的故障。
FOR
从FOR循环中删除所有已通过的迭代。
WUKS
删除内置关键字内除最后一个失败的关键字外的所有关键字Wait Until Keyword Succeeds。

例子：

rebot --removekeywords all output.xml 
pybot --removekeywords passed --removekeywords for tests.txt

注意
在Robot Framework 2.7 中添加了在执行测试时使用--removekeywords以及FOR和WUKS模式的支持。

3.5.6 设置执行的开始和结束时间

使用rebot组合输出时，可以分别使用选项--starttime 和 --endtime设置组合测试套件的开始和结束时间。这很方便，因为默认情况下组合套件没有这些值。指定开始时间和结束时间时，所经过的时间也会根据它们计算。否则，通过将子测试套件的经过时间加在一起来获得所经过的时间。

从Robot Framework 2.5.6 开始，在使用rebot时，还可以使用上述选项为单个套件设置开始和结束时间。使用单个输出的这些选项始终会影响套件的使用时间。

时间必须作为时间戳的格式YYYY-MM-DD hh:mm:ss.mil，其中所有的分隔符都是可选的，从毫秒到小时的部分可以省略。例如，2008-06-11 17：59：20.495相当于20080611-175920.495，200806111175920495也仅相当于20080611。

例子：

rebot --starttime 20080611-17:59:20.495 output1.xml output2.xml 
rebot --starttime 20080611-175920 --endtime 20080611-180242 *.xml 
rebot --starttime 20110302-1317 --endtime 20110302-11418 myoutput.xml

3.5.7 系统日志

Robot Framework有自己的纯文本系统日志，记录的信息有

• 已处理和跳过测试数据文件
• 导入测试库、资源文件和变量文件
• 已执行的测试套件和测试案例
• 创建输出

通常用户永远不需要此信息，但在检测测试库或Robot Framework本身的问题时这些可能很有用。系统日志不是默认创建的，但它可以通过设置环境变量ROBOT_SYSLOG_FILE来启用，以便它包含到所选文件的路径。

系统日志具有与正常日志文件相同的日志级别，但错误级别除外。 使用阈值级别可以使用下面示例中显示的ROBOT_SYSLOG_LEVEL环境变量进行更改。除了控制台和正常日志文件外，系统日志中还记录了可能的意外错误和警告。

#!/bin/bash 
export ROBOT_SYSLOG_FILE=/tmp/syslog.txt 
export ROBOT_SYSLOG_LEVEL=DEBUG 
pybot --name Syslog_example path/to/tests