Robot Framework（九） 执行测试用例——基本用法

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 runner脚本开始测试执行。这些脚本在其他方面是相同的，但第一个使用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提供了许多命令行选项，可用于控制测试用例的执行方式和生成的输出。本节介绍选项语法以及实际存在的选项。它们如何使用将在本章的其他地方讨论。

使用选项

使用选项时，必须始终在runner脚本和数据源之间给出它们。例如：

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

短期和长期期权

选项始终具有长名称，例如--name，并且最常用的选项也具有短名称，例如 -N。除此之外，只要它们是唯一的，就可以缩短长期选项。例如， - lite DEBUG有效，而--log log.html没有，因为前者仅匹配 --loglevel，但后者匹配多个选项。手动执行测试用例时，短期和缩短选项都很实用，但在启动脚本中建议使用长选项，因为它们更容易理解。

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

设置选项值

大多数选项都需要一个值，该值在选项名称后面给出。short和long选项都接受带有空格的选项名称分隔的值，如--include标记 或-i标记。对于长选项，分隔符也可以是等号，例如--include = tag，并且使用短选项可以省略分隔符，如-itag。

某些选项可以多次指定。例如， - variable VAR1：value --variable VAR2：另一个设置两个变量。如果多次使用仅包含一个值的选项，则最后给出的值有效。

选项值为简单模式

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

3.1.3测试结果

命令行输出

测试执行中最明显的输出是命令行中显示的输出。所有执行的测试套件和测试用例以及它们的状态都会实时显示在那里。下面的示例显示了执行只有两个测试用例的简单测试套件的输出：

================================================== ============================
示例测试套件
================================================== ============================
第一次测试::可能的测试文档　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 | 通过|
-------------------------------------------------- ----------------------------
第二次测试　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 | 失败|
此处显示错误消息
================================================== ============================
示例测试套件　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 | 失败|
2个关键测试，1个通过，1个失败
总共2次测试，1次通过，1次失败
================================================== ============================
输出：/path/to/output.xml
报告：/path/to/report.html
日志：/path/to/log.html

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

生成的输出文件

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

退货代码

运行器脚本使用返回代码将整体测试执行状态传达给运行它们的系统。当执行成功启动且没有严重测试失败时，返回码为零。所有可能的返回代码在下表中说明。

可能的返回码

RC	说明
0	所有关键测试都通过了
1-249	返回的关键测试数量失败。
250	250次或更多严重故障。
251	打印帮助或版本信息。
252	无效的测试数据或命令行选项。
253	用户停止测试执行。
255	意外的内部错误。

执行后应始终可以轻松获得返回代码，这样可以轻松自动确定整体执行状态。例如，在bash shell中，返回码是特殊变量$？，在Windows中，它位于％ERRORLEVEL％ 变量中。如果您使用某些外部工具来运行测试，请查阅其文档以获取返回代码。

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

注意

相同的返回码也与rebot一起使用。

执行期间的错误和警告

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

20090322 19：58：42.528	错误	第2行元素中的表''设置'中的文件'/home/robot/tests.html'出错：资源文件'resource.html'不存在
20090322 19：58：43.931	警告	不推荐使用关键字“SomeLibrary.Example Keyword”。请改用关键字“其他关键字”。

3.1.4转义复杂的字符

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

在Robot Framework的命令行转义机制中，有问题的字符将使用自由选择的文本进行转义。要使用的命令行选项是--escape（短版本 -E），它采用以下格式的参数：with，其中要转义的字符的名称是什么， with是要转义它的字符串。可以转义的字符列在下表中：

Available escapes

Character	Name to use	Character	Name to use
&	amp	(	paren1
'	apos	)	paren2
@	at	%	percent
\	blash	|	pipe
:	colon	?	quest
,	comma	"	quot
{	curly1	;	semic
}	curly2	/	slash
$	dollar		space
!	exclam	[	square1
>	gt	]	square2
#	hash	*	star
<	lt

以下示例使语法更清晰。在第一个示例中，元数据X 通过空格获取值Value，而在第二个示例中，变量$ {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

从标准输入读取参数是Robot Framework 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创建启动脚本

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

在类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中。在这些示例中，启动脚本要求将执行的测试数据的路径作为参数提供。即使已在脚本中设置了某些选项，也可以自由使用命令行选项。所有这些都是使用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启动参数

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

1. 直接修改Jython启动脚本（jython shell脚本或 jython.bat批处理文件）。这是一种永久性配置。

2. 设置JYTHON_OPTS环境变量。这可以在操作系统级别中永久执行，也可以在自定义启动脚本中执行。

3. 将所需的Java参数wit -J选项传递给Jython启动脚本，该脚本将它们传递给Java。使用直接入口点时，这一点特别容易：

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

3.1.8调试问题

测试用例可能会失败，因为被测系统无法正常工作，在这种情况下，测试发现了一个错误，或者测试本身是错误的。解释失败的错误消息显示在命令行输出和报告文件中，有时单独的错误消息足以查明问题。但是，更常见的情况是，不需要日志文件，因为它们还有其他日志消息，并且它们显示实际上失败的关键字。

当测试的应用程序导致失败时，错误消息和日志消息应该足以理解导致它的原因。如果不是这种情况，则测试库不能提供足够的信息，需要进行增强。在这种情况下，如果可能，手动运行相同的测试也可能会显示有关该问题的更多信息。

测试用例本身或他们使用的关键字导致的失败有时很难调试。例如，如果错误消息告诉关键字使用错误数量的参数修复问题显然很容易，但如果关键字丢失或以意外方式失败，找到根本原因可能会更难。查找更多信息的第一个位置是日志文件中的执行错误部分。例如，有关失败的测试库导入的错误可能很好地解释了由于缺少关键字而导致测试失败的原因。

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

如果日志文件仍然没有足够的信息，最好启用syslog并查看它提供的信息。还可以在测试用例中添加一些关键字以查看正在进行的操作。特别是BuiltIn关键字 日志和日志变量很有用。如果没有其他工作，总是可以从邮件列表或其他地方搜索帮助。