最近review小组内部同事们写的RF用例，发现不同的同事写的风格不尽相同。因此找了一下官方的文档（https://github.com/robotframework/HowToWriteGoodTestCases/blob/master/HowToWriteGoodTestCases.rst），打算作为小组内同事编写RF用例时的参考，考虑到组内同事成员的英文水平不尽相同，因此翻译了一下。
命名
测试套(Test Suite)命名
• 测试套的名字应尽可能地具有描述性。
• 测试套的名字会自动根据文件或者目录名称创建:
– 去掉文件扩展名。
– 将下划线转换成空格。
– 如果名字全部都是小写，则首字母大写。
• 测试套的名字可以相对较长，但是过长的名字对于文件系统来讲不方便处理。
• 最高层级的测试套名称可以通过命令行参数“--name”来覆盖。
样例:
• login_tests.robot -> Login Tests
• IP_v4_and_v6 -> IP v4 and v6
测试用例(Test Case)命名
• 和测试套一样，测试用例的名字应尽可能地具有描述性。
• 如果一个测试套包含多个类似的测试用例并且命名合理，那么测试用例的名字可以命令相对短些。
• 测试用例名字不会进行任何转换，和文件中编写的保持一致。
举例说明，如果我们有个测试无效登录的文件invalid_login.robot，该文件中包含了多个测试用例，那么以下测试用例的命令是可以的：
*** Test Cases ***
Empty Password
Empty Username
Empty Username And Password
Invalid Username
Invalid Password
Invalid Username And Password
这些测试用例的名称也可以相对长一点：
*** Test Cases ***
Login With Empty Password Should Fail
Login With Empty Username Should Fail
Login With Empty Username And Password Should Fail
Login With Invalid Username Should Fail
Login With Invalid Password Should Fail
Login With Invalid Username And Invalid Password Should Fail
关键字命名
• 关键字的名字应尽可能地清晰，并具有描述性。
• 应该能够解释关键字做什么，而不是关键字怎么做。
• 不同的抽象级别（例如：Input Text 或者 Administrator logs into system）。
• 目前并没有明确要求关键字必须每个单词的首字母大写（title cased），或者只是首字母大写。
– 当关键字名字比较短的时候，一般是每个单词的首字母都大写（例如：Input Text）。
– 当关键字看起来更像一个句子时，一般大写的只有首字母（例如：Administrator logs into system）。这种类型的关键字通常是高级关键字。
好的样例：
*** Keywords ***
Login With Valid Credentials
不好的样例：
*** Keywords ***
Input Valid Username And Valid Password And Click Login Button
Setup和Teardown的命名
• 使用能够解释关键字做什么的命名。
– 尽可能使用已经存在的关键字。
• 如果Setup或者Teardown包含没有关联的步骤，则可以使用更加抽象的命名。
– 罗列步骤会导致冗余，并且会增加维护的难度（例如：Login to system, add user, activate alarms and check balance）。
– 最好用一些更通用的名字（例如：Initialize system）。
• 多个关键字的执行可以使用内置的关键字Run Keywords。
• 自动化测试人员需要留意并理解当前测试套的setup以及teardown的作用。
好的样例：
*** Settings ***
Suite Setup Initialize System
好的样例 (一次执行):
*** Settings ***
Suite Setup Run Keywords
... Login To System AND
... Add User AND
... Activate Alarms AND
... Check Balance
不好的样例:
*** Settings ***
Suite Setup Login To System, Add User, Activate Alarms And Check Balance
文档
测试套（Test Suite）文档
• 通常建议给测试套文件增加一个总体介绍文档。
• 包含背景介绍，用例编写的原因，以及执行环境的建议等。
• 不要只是重复测试套的名字。
– 如果没有必要，也可以不写文档。
• 不要包含太多测试用例的细节。
– 每个测试用例必须足够清晰，便于理解。
– 重复冗余的信息是没有必要的，会增量维护的难度。
• 文档可以包含链接，指向更多的文档。
• 如果想表示name-value形式的信息，可以考虑使用metadata（例如：Version: 1.0 或者 OS: Linux）.
• 最高层级的文档和metadata可以通过命令行参数”--doc”和”--metadata”来分别指定。
好的例子:
*** Settings ***
Documentation Tests to verify that account withdrawals succeed and
... fail correctly depending from users account balance
... and account type dependent rules.
... See http://internal.example.com/docs/abs.pdf
Metadata Version 0.1
不好的例子(比如当测试套的命名已经很清楚的时候：account_withdrawal.robot):
*** Settings ***
Documentation Tests Account Withdrawal.
测试用例（Test Case）文档
• 测试用例一般情况下不需要文档。
– 测试套的名字和文档，加上测试用例的名字应该能够提供足够的信息。
– 测试用例的结构需要足够清晰，不需要文档或者其它注释来解释。
• 使用Tags则更加灵活，和文档相比能提供更多的功能（statistics, include/exclude等）。
• 有必要的话，测试用例的文档也是可以写的，不要过分担心。
好的例子:
*** Test Cases ***
Valid Login
[Tags] Iteration-3 Smoke
Open Login Page
Input Username ${VALID USERNAME}
Input Password ${VALID PASSWORD}
Submit Credentials
Welcome Page Should Be Open
不好的例子:
*** Test Cases ***
Valid Login
[Documentation] Opens a browser to login url, inputs valid username
... and password and checks that the welcome page is open.
... This is a smoke test. Created in iteration 3.
Open Browser ${URL} ${BROWSER}
Input Text field1 ${UN11}
Input Text field2 ${PW11}
Click Button button_12
Title Should Be Welcome Page
用户关键字文档
• 如果关键字比较简单，则不需要文档。
– 好的关键字，必须要有清晰的参数名称，结构也要足够清晰。
• 一般用来解释参数和返回值。
• 可以显示在通过libdoc生成的文件中，也可以在像RIDE这样的编辑器中显示。
测试套（Test Suite）的结构
• 一个测试套的测试用例应该是存在关联的。
– 一般会有共同的setup以及teardown。
• 除非是数据驱动的测试套，否则一个测试套文件中不建议有太多的用例（超过10个）。
• 测试用例应该是独立的，通过setup/teardown来实现初始化。
• 但有时候用例之间的依赖也无法避免。
– 例如，分别初始化所有用例会非常耗时。
– 不要编写一连串相关的测试用例。
– 考虑使用内置的${PREV TEST STATUS}变量来验证先前用例的执行状态。
测试用例的结构
• 测试用例应该易于理解。
• 一个测试用例应该只测试一件事。
– 事情可能很小（单个功能的一部分），也可能很大（端到端）。
• 选择合适的抽象级别。
– 使用一致的抽象级别。
– 不要在测试用例级别包含不必要的细节。
• Two kinds of test cases:测试用例包含两种类型：
– 工作流测试用例。
– 数据驱动测试用例。
工作流（关键字驱动）测试用例
• 一般会有这些步骤：
– 预置条件（可选，通常在Setup中）。
– 具体动作（在系统中完成一些事情）。
– 验证（验证结果，必须要有）。
– 清理（可选，一般在Teardown中以确保会被执行）。
• 关键字描述测试的目的。
– 使用清晰的关键字名称和适当的抽象级别。
– 应该包含足够的信息以便于手工运行。
– 永远不需要文档（documentation）或评论（comment）来解释测试的目的。
• 不同的测试可以具有不同的抽象级别。
– 详细功能的测试用例是更加精确的。
– 端到端的测试用例可以是非常high-level的。
– 一个测试用例应仅使用一个抽象级别。
• 不同的风格：
– 针对更多细节的和集成测试，我们可以编写更具有技术性的测试用例。
– “可执行规范”可以作为技术要求。
– 使用领域内（行业内）的术语。
– 每个人（包括客户和/或PO）都应该能始终理解。
• 在测试用例级别上不要有复杂的逻辑。
– 没有FOR循环或者IF/ELSE结构。
– 谨慎使用变量赋值。
– 测试用例不应该看起像脚本！
– 最多十个步骤，少一点更好。
使用“正常”关键字驱动风格的例子：
*** Test Cases ***
Valid Login
Open Browser To Login Page
Input Username demo
Input Password mode
Submit Credentials
Welcome Page Should Be Open
使用更高级别“gherkin”风格的例子：
*** Test Cases ***
Valid Login
Given browser is opened to login page
When user "demo" logs in with password "mode"
Then welcome page should be open
数据驱动（Data-Driven）测试用例
• 每个测试用例包含一个高级别的关键字。
– 不同的关键字参数可以创建不同的测试用例。
– 一个测试用例可以多次执行同一个关键字，用以验证不同的参数组合。
• 如果关键字被实现成用户关键字，它通常包含和关键字驱动/工作流测试用例一样的流程。
– 除非需要在其它地方使用，否则最好在和使用它的测试用例同样的文件中创建。
• 推荐使用test template功能。
– 不需要重复关键字名称很多次。
– 更容易在同一个测试用例中测试多个变量的组合。
• 尽可能地，并且推荐使用命名列标题。
•如果需要进行大量的测试，则可以考虑通过外部模型来生成。
样例:
*** Settings ***
Test Template Login with invalid credentials should fail
*** Test Cases *** USERNAME PASSWORD
Invalid Username invalid ${VALID PASSWORD}
Invalid Password ${VALID USERNAME} invalid
Invalid Both invalid invalid
Empty Username ${EMPTY} ${VALID PASSWORD}
Empty Password ${VALID USERNAME} ${EMPTY}
Empty Both ${EMPTY} ${EMPTY}
*** Keywords ***
Login with invalid credentials should fail
[Arguments] ${username} ${password}
Input Username ${username}
Input Password ${password}
Submit Credentials
Error Page Should Be Open
用户关键字（User Keywords）
• 应该容易理解。
– 和工作流的用例使用同样的规则。
• 不同的抽象级别。
• Can contain some programming logic (for loops, if/else).可以包含一些编程的逻辑（FOR循环，IF/ELSE等）
– 特别是在较低级别的关键字上。
– 复杂的逻辑可以放在库里面而不是用户关键字里。
变量（Variables）
• 封装长度较长的和/或者复杂的值。
• 可以通过命令行参数—variable来指定变量。
• 在不同关键字间传递信息。
变量（Variable）命名
• 命名需要清晰并且长度适中。
• 可以给变量添加注释。
• 大小写要一致：
– 局部变量仅在特定范围内可见，使用小写。
– 其它非局部变量使用大写（全局变量，测试套变量以及用例变量）
– 空格和下划线都可以用作单词分隔符。
• 推荐在变量列表中也列出动态设置的变量。
– 使用内置关键字Set Suite Variable。
– 初始值应该可以解释实际的值赋值的位置/如何赋值。
样例:
*** Settings ***
Suite Setup Set Active User
*** Variables ***
# Default system address. Override when tested agains other instances.
${SERVER URL} http://sre-12.example.com/
${USER} Actual value set dynamically at suite setup
*** Keywords ***
Set Active User
${USER} = Get Current User ${SERVER URL}
Set Suite Variable ${USER}
传递和返回值
• 通常的方法是从关键字返回值，将其赋值给变量，然后将变量作为参数传递给其他关键字。
– 清晰且易于遵循的方法。
– 允许创建独立的关键字并方便重用。
– 看起来像编程，因此在测试用例级别上使用不太好。
• 另一种方法是存储在一个库里，或者使用内置的Set Test Variable关键字。
– 避免在测试用例级别使用编程的风格。
– 遵循起来可能会更复杂，使关键字的重用变得更加困难。
好的例子:
*** Test Cases ***
Withdraw From Account
Withdraw From Account $50
Withdraw Should Have Succeeded
*** Keywords ***
Withdraw From Account
[Arguments] ${amount}
${STATUS} = Withdraw From User Account ${USER} ${amount}
Set Test Variable ${STATUS}
Withdraw Should Have Succeeded
Should Be Equal ${STATUS} SUCCESS
不推荐的例子:
*** Test Cases ***
Withdraw From Account
${status} = Withdraw From Account $50
Withdraw Should Have Succeeded ${status}
*** Keywords ***
Withdraw From Account
[Arguments] ${amount}
${status} = Withdraw From User Account ${USER} ${amount}
[Return] ${status}
Withdraw Should Have Succeeded
[Arguments] ${status}
Should Be Equal ${status} SUCCESS
避免使用sleeping
• 使用Sleeping来同步测试是非常脆弱的。
• 为了保险起见，通常会使用过长的sleep时间。
• 除了sleep，可以使用触发某些轮询操作的关键字。
– 关键字名字通常以Wait开头。
– 应该有一个最长等待时间。
– 可以将其它关键字包在内置关键字Wait Until Keyword Succeeds中。
• 有时Sleeping是最简单的解决方法。
– 务必小心使用。
– 切勿在测试用例或其他关键字经常使用的用户关键字中使用。
•在调试的时候可能会有用，用来停止执行。
– 标准库Dialogs通常效果更好。