怎样才能设计出好的Robot Framework测试用例(How to write good test cases using Robot Framework)

How to write good test cases using Robot Framework

如何用RF来编制好的测试用例

Table of contents:

目录：

• Introduction
• 介绍
• Naming
• 命名
  • Test suite names
  • 测试套件命名
  • Test case names
  • 测试用例命名
  • Keyword names
  • 关键字命名
  • Naming setup and teardown
  • 命名setup和teardown
• Documentation
• 文档
  • Test suite documentation
  • 测试套件文档
  • Test case documentation
  • 测试用例文档
  • User keyword documentation
  • 用户关键字文档
• Test suite structure
• 测试套件结构
• Test case structure
• 测试用例结构
  • Workflow tests
  • 工作流测试
  • Data-driven tests
  • 数据驱动测试
• User keywords
• 用户关键字
• Variables
• 变量
  • Variable naming
  • 变量命名
  • Passing and returning values
  • 传递及返回参数值
• Avoid sleeping
• 避免使用Sleep关键字

Introduction

介绍

• These are high-level guidelines for writing good test cases using Robot Framework.
• 这是一篇使用RF框架编制好的测试用例的高级指南。
  • How to actually interact with the system under test is out of the scope of this document.
  • 至于如何实际与系统交互则超出了本文的范围。
• Most important guideline is keeping test cases as easy to understand as possible for people familiar with the domain.
• 最重要的一个指导方针就是保证测试用例尽可能让熟悉相关领域的人更容易理解。
  • This typically also eases maintenance.
  • 这样也更容易维护。
• For more information about this subject, you may want to take a look at these great resources:
• 关于这个主题的更多信息，你可能想要看看下面的优秀资源：
  • Robot Framework Dos and Don'ts slides that are based on this how-to.
  • Writing Maintainable Automated Acceptance Tests article by Dale Emery.
  • How to Structure a Scalable And Maintainable Acceptance Test Suite blog post by Andreas Ebbert-Karroum.

Naming

命名

Test suite names

测试套件命名

• Suite names should be as descriptive as possible.
• 套件名称应尽可能的描述清楚。
• Names are created automatically from file or directory names:
• 套件名称会从文件名称或目录名称自动创建。
  • Extensions are stripped.。
  • 文件的后缀名被去掉
  • Underscores are converted to spaces.
  • 下划线会被转换成空格。
  • If name is all lower case, words are capitalized.
  • 如果套件名称都是小写字母，单词的首字母会变为大写。
• Names can be relatively long, but overly long names are not convenient for the file system.
• 套件名称相对可以长一些，但过长的话在文件系统中不方便。
• The name of the top level suite can be overridden from the command line using the --name option if needed.
• 如果有需要，最顶层套件名称可以通过命令行使用—name选项进行覆写。

Examples:

示例：

• login_tests.robot -> Login Tests
• 文件系统中看到是login_tests.robot,在RIDE中看到的是Login Tests
• IP_v4_and_v6 -> IP v4 and v6
• 文件系统中看到的是IP_v4_and_v6，RIDE中看到的是IP v4 and v6

Test case names

测试用例命名

• Test names should be descriptive like the suite names.
• 测试用例的命名应该描述的和测试套件命名相似。
• If a suite contains many similar tests and is well named, test names can be shorter.
• 如果一个测试套件包含许多类似的测试用例且已经很好的命名了，那么测试用例的命名可以简洁一些。
• Name is exactly the same as you specified in the test case file without any conversion.
• 测试用例名称在测试文件中和你指定的一模一样，不会有任何转换。

For example, ifwe have tests related to invalid login in a file invalid_login.robot, these would be OK test case names:

比如，如果我们有一个和非法登录的文件invalid_login.robot，下面的命名都是可以的：

*** Test Cases***

Empty Password

Empty Username

Empty UsernameAnd Password

Invalid Username

Invalid Password

Invalid UsernameAnd Password

These names would be somewhat long:

这些命名就有些长了：

*** Test Cases***

Login With EmptyPassword Should Fail

Login With EmptyUsername Should Fail

Login With EmptyUsername And Password Should Fail

Login WithInvalid Username Should Fail

Login WithInvalid Password Should Fail

Login WithInvalid Username And Invalid Password Should Fail

Keyword names

关键字命名

• Keyword names should be descriptive and clear.
• 关键字命名应该描述清晰。
• Should explain what the keyword does, not how it does its task(s).
• 应该说明关键字是做什么的，而不是解释关键字如何做任务。
• Very different abstraction levels (e.g. Input Text or Administrator logs into system).
• 关键字应该有不同的抽象级别（比如：Input Text和Administrator logs into system）
• There is no clear guideline on whether a keyword should be fully title cased or have only the first letter be capitalized.
• 没有明确的指南规范关键字标题是所有单词首字母大写还是首单词首字母大写
  • Title casing is often used when the keyword name is short (e.g. Input Text).
  • 所有单词首字母大写经常用在关键字比较短的情况下，（比如：Input Text）
  • Capitalizing just the first letter typically works better with keywords that are like sentences (e.g. Administrator logs into system). These type of keywords are often higher level.
  • 如果关键字命名就像一个句子，通常将首单词首字母大写更好，（比如，Administrator logs into system）。这些类型的关键字往往具有更高抽象级别。

Good:

好的关键字命名方式:

*** Keywords ***

Login With ValidCredentials

Bad:

不好的关键字命名方式

*** Keywords ***

Input ValidUsername And Valid Password And Click Login Button

Naming setup and teardown

命名setup和teardown

• Try to use name that describes what is done.
• 试着使用描述做什么的命名。
  • Possibly use an existing keyword.
  • 可能使用现有的关键字。
• More abstract names are acceptable if a setup or teardown contains unrelated steps.
• 如果setup或teardown包含一些不相关的步骤，可以接受一些更加抽象的命名。
  • Listing steps in name is duplication and a maintenance problem (e.g. Login to system, add user, activate alarms and check balance).
  • 逐个列出的关键字命名方式是会重复并带来维护方面的问题。（比如， Login to system, add user, activate alarms and check balance）
  • Often better to use something generic (e.g. Initialize system).
  • 通常最好使用通用的东西（比如，Initialize system）
• BuiltIn keyword Run Keywords can work well if keywords implementing lower level steps already exist.
• 如果关键字已经在低级别步骤中存在，使用内置的关键字Run Keywords可以工作的更好。
  • Not reusable so best used when the setup or teardown scenario is needed only once.
  • 最好的使用情况是当setup和teardown只需要使用一次的情景，这不会重复。
• Everyone working with these tests should always understand what a setup or teardown does.
• 所有参与测试工作人员务必理解setup和teardown都做了些什么。

Good:

好的命名方式：

*** Settings ***

Suite Setup    Initialize System

Good (if only used once):

好的命名方式（如果只使用一次）：

*** Settings ***

Suite Setup    Run Keywords

...             Login To System    AND

...             Add User           AND

...             Activate Alarms    AND

...             Check Balance

Bad:

不好的命名方式：

*** Settings ***

Suite Setup    Login To System, Add User, Activate Alarms And Check Balance

Documentation

文档

Test suite documentation

测试套件文档

• Often a good idea to add overall documentation to test case files.
• 通常好的做法是将所有文档都加入到测试用例文件中。
• Should contain background information, why tests are created, notes about execution environment, etc.
• 应该包含一些背景信息，为什么创建测试，注意一些关于执行环境的内容。
• Do not just repeat test suite name.
• 不要重复测试套件的名称
  • Better to have no documentation if it is not really needed.
  • 如果不是真的需要，最好不要有文档。
• Do not include too much details about test cases.
• 不要包含太多关于测试用例的详细信息。
  • Tests should be clear enough to understand alone.
  • 测试用例本身应该清晰以致能够理解。
  • Duplicate information is waste and maintenance problem.
  • 重复信息是浪费并造成一些维护问题。
• Documentation can contain links to more information.
• 文档可以包含更多信息的链接。
• Consider using test suite metadata if you need to document information represented as name-value pairs (e.g. Version: 1.0 or OS: Linux).
• 如果需要以键值对的文档信息，可以考虑使用测试套件的元数据设置metadata。（例如：版本：1.0或系统：Linux）。
• Documentation and metadata of the top level suite can be set from the command line using --doc and --metadataoptions, respectively.
• 最顶层的测试套件的文档和元数据可以通过命令行使用—doc和—metadataoptions命令设置。

Good:

好的文档：

*** Settings ***

Documentation    Tests to verify that account withdrawalssucceed and

...              fail correctly depending fromusers account balance

...              and account type dependent rules.

...              Seehttp://internal.example.com/docs/abs.pdf

Metadata        Version    0.1

Bad (especiallyif suite is named well like account_withdrawal.robot):

不好的文档（特别当套件命名像account_withdrawal.robot）:

*** Settings ***

Documentation    Tests Account Withdrawal.

Test case documentation

测试用例文档

• Test normally does not need documentation.
• 测试通常不需要文档。
  • Name and possible documentation of the parent suite and test's own name should give enough background information.
  • 父套件的命名和文档以及测试用例本身的命名应该给足够信息。
  • Test case structure should be clear enough without documentation or other comments.
  • 测试用例结构应该清晰到足够不需要文档或其他注释。
• Tags are generally more flexible and provide more functionality (statistics, include/exclude, etc.) than documentation.
• 标签通常比文档更加灵活并且功能更加丰富（statistics，include/exclude等等）。
• Sometimes test documentation is useful. No need to be afraid to use it.
• 有些时候测试文档是非常有用的。灵活使用它。

Good:

好的测试用例文档：

*** 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

Bad:

不好的测试用例文档：

*** Test Cases***

Valid Login

    [Documentation]    Opens a browser to login url, inputs validusername

    ...                and password and checks thatthe welcome page is open.

    ...                This is a smoke test. Createdin iteration 3.

    Open Browser   ${URL}   ${BROWSER}

    Input Text    field1   ${UN11}

    Input Text    field2   ${PW11}

    Click Button    button_12

    Title Should Be    Welcome Page

User keyword documentation

用户关键字文档

• Not needed if keyword is relatively simple.
• 如果关键字很简单就不要文档。
  • Good keyword, argument names and clear structure should be enough.
  • 好的关键字，应该有参数名和清晰的结构。
• Important usage is documenting arguments and return values.
• 重要的使用惯例是记录参数和返回值。
• Shown in resource file documentation generated with Libdoc and editors such as RIDE can show it in keyword completion and elsewhere.
• 在资源文件中，使用Libdoc生成的文档可以在RIDE中通过关键字和其他地方展示。

Test suite structure

测试套件结构

• Tests in a suite should be related to each other.
• 测试套件应该彼此有关联。
  • Common setup and/or teardown is often a good indicator.
  • 公共的setup/teardown设置是一个很好的体现。
• Should not have too many tests (max 10) in one file unless they are data-driven tests.
• 除了数据驱动测试套件，一个测试套件不应该有太多测试用例（不超过10个）。
• Tests should be independent. Initialization using setup/teardown
• 测试套件应该设计成独立的，通过使用setup/teardown进行初始化工作。
• Sometimes dependencies between tests cannot be avoided.
• 有些时候，测试套件间的依赖是不可避免的。
  • For example, it can take too much time to initialize all tests separately.
  • 例如：分别单独初始化所有的测试套件花太多时间。
  • Never have long chains of dependent tests.
  • 不要有太长的测试依赖链。
  • Consider verifying the status of the previous test using the built-in ${PREV TEST STATUS} variable.
  • 考虑使用内置的${PREV TEST STATUS}变量验证前一个测试套件状态。

Test case structure

测试用例结构

• Test case should be easy to understand.
• 测试用例应该很容易被理解。
• One test case should be testing one thing.
• 一个测试用例应该只测试一个事情。
  • Things can be small (part of a single feature) or large (end-to-end).
  • 事情可以很小（单一要素的一部分）或很大（端到端）
• Select suitable abstraction level.
• 选择合适的抽象级别。
  • Use abstraction level consistently (single level of abstraction principle).
  • 使用抽象级别要以致（单一层次的抽象原则）
  • Do not include unnecessary details on the test case level.
  • 在测试用例级别不要包含不必要的详细信息。
• Two kinds of test cases:
• 两种测试用例：
  • Workflow tests
  • 工作流测试
  • Data-driven tests
  • 数据驱动测试

Workflow tests

工作流测试

• Generally have these phases:
• 通常有以下阶段：
  • Precondition (optional, often in setup)
  • 前置条件（可选，通常在setup中设置）
  • Action (do something to the system)
  • 操作（对系统做一些操作）
  • Verification (validate results, mandatory)
  • 验证（验证结果，强制性）
  • Cleanup (optional, always in teardown to make sure it is executed)
  • 清理工作（可选，总是在teardown中设置以保证执行）
• Keywords describe what a test does.
• 关键字描述测试做什么。
  • Use clear keyword names and suitable abstraction level.
  • 使用明确的关键字命名和合适的抽象级别。
  • Should contain enough information to run manually.
  • 应该包含足够的手动操作运行信息。
  • Should never need documentation or commenting to explain what the test does.
  • 不需要文档或注释来解释测试做什么。
• Different tests can have different abstraction levels.
• 不同的测试可以有不同的抽象层次。
  • Tests for a detailed functionality are more precise.
  • 有详细功能的测试更加精确。
  • End-to-end tests can be on very high level.
  • 端到端的测试级别非常高。
  • One test should use only one abstraction level
  • 一个测试应该仅仅只使用一个抽象层次。
• Different styles:
• 不同风格：
  • More technical tests for lower level details and integration tests.
  • 低层次的和集成测试更具有技术性。
  • "Executable specifications" act as requirements.
  • 将“可执行的说明书”作为需求。
  • Use domain language.
  • 使用领域语言
  • Everyone (including customer and/or product owner) should always understand.
  • 所有角色（包括客户/产品拥有者）什么情况下都可以理解。
• No complex logic on the test case level.
• 测试用例层次没有复杂的逻辑。
  • No for loops or if/else constructs.
  • 没有循环或分支设计。
  • Use variable assignments with care.
  • 使用变量赋值需注意。
  • Test cases should not look like scripts!
  • 测试用例不应该看起来像脚本。
• Max 10 steps, preferably less.
• 最大10个步骤，尽量少。

Example using "normal" keyword-driven style:

使用正常关键字驱动的风格示例：

*** Test Cases***

Valid Login

    Open Browser To Login Page

    Input Username    demo

    Input Password    mode

    Submit Credentials

    Welcome Page Should Be Open

Example using higher level "gherkin" style:

使用更高级的“gherkin”风格示例：

*** Test Cases***

Valid Login

    Given browser is opened to login page

    When user "demo" logs in withpassword "mode"

    Then welcome page should be open

See the web demo project forexecutable versions of the above examples.

Data-driven tests

数据驱动测试

• One high-level keyword per test.
• 每个测试应该有一个高级别关键字
  • Different arguments create different tests.
  • 不同的参数创建不同的测试。
  • One test can run the same keyword multiple times to validate multiple related variations
  • 一个测试可以运行多次相关的关键字来验证多个相关的变化。
• If the keyword is implemented as a user keyword, it typically contains a similar workflow as workflow tests.
• 如果关键字是以用户关键字实现的，它包含和工作流测试相似的测试流。
  • Unless needed elsewhere, it is a good idea to create it in the same file as tests using it.
  • 如果在其他地方不需要使用，一个好的方式在同一个测试套件下创建并使用。
• Recommended to use the test template functionality.
• 推荐使用测试模板功能。
  • No need to repeat the keyword multiple times.
  • 不需要重复多次编写关键字。
  • Easier to test multiple variations in one test.
  • 在一个测试中方便适应多种测试变化。
• Possible, and recommended, to name column headings
• 可能的话，推荐给列命标题名。
• If a really big number of tests is needed, consider generating them based on an external model.
• 如果真的有大量的测试需求，可以考虑基于一个外部模型生成他们。

Example:

示例：

*** Settings ***

Test Template        Login with invalid credentials should fail

 

*** Test Cases***    USERNAME             PASSWORD

Invalid Username     invalid             ${VALID PASSWORD}

Invalid Password     ${VALIDUSERNAME}    invalid

Invalid Both         invalid              invalid

Empty Username       ${EMPTY}            ${VALID PASSWORD}

Empty Password       ${VALIDUSERNAME}   ${EMPTY}

Empty Both           ${EMPTY}            ${EMPTY}

 

*** Keywords ***

Login withinvalid credentials should fail

   [Arguments]   ${username}   ${password}

    Input Username   ${username}

    InputPassword   ${password}

    Submit Credentials

    Error Page Should Be Open

The web demo project containsan executable version of this example too.

web demo project 包含可执行版本的这个样例。

User keywords

用户关键字

• Should be easy to understand.
• 应该容易被理解。
  • Same rules as with workflow tests.
  • 和工作流测试有相同的规则。
• Different abstraction levels.
• 不同的抽象层次
• Can contain some programming logic (for loops, if/else).
• 可以包含一些逻辑设计（循环，分支）。
  • Especially on lower level keywords.
  • 尤其是在较低层次的关键字。
  • Complex logic in libraries rather than in user keywords.
  • 复杂逻辑是在测试库中实现，而不是在用户关键字中。

Variables

变量

• Encapsulate long and/or complicated values.
• 封装一些长的和/或复杂的值。
• Pass information from them command line using the --variable option.
• 命令行中使用—variable选项在变量中传递信息。
• Pass information between keywords.
• 关键字之间传递信息。

Variable naming

变量命名

• Clear but not too long names.
• 清晰但不要太长的名称。
• Can use comments in variable table to document them more.
• 可以对变量进行注释以记录更多信息。
• Use case consistently:
• 用例一致性：
  • Lower case with local variables only available inside a certain scope.
  • 有明确作用域的内部局部变量命名使用小写。
  • Upper case with others (global, suite or test level).
  • 其他用例命名使用大写（全局，套件和测试用例级别）
  • Both space and underscore can be used as a word separator.
  • 空格和下划线都可以作为单词分隔符。
• Recommended to also list variables that are set dynamically in the variable table.
• 建议在变量表中列出需动态设置的变量。
  • Set typically using BuiltIn keyword Set Suite Variable.
  • 一般使用内置关键字Set Suite Variable设置
  • The initial value should explain where/how the real value is set.
  • 初始值应该说明真实值在哪里设置和怎么设置。

Example:

示例：

*** Settings ***

Suite Setup      Set Active User

 

*** Variables***

# Default systemaddress. Override when tested agains other instances.

${SERVER URL}    http://sre-12.example.com/

${USER}           Actual value set dynamically atsuite setup

 

*** Keywords ***

Set Active User

   ${USER} =    Get Current User   ${SERVER URL}

    Set Suite Variable   ${USER}

Passing and returning values

传参和返回值

• Common approach is to return values from keywords, assign them to variables and then pass them as arguments to other keywords.
• 通常从关键字返回值，再将他们赋值给其他变量，然后将他们作为参数传递给其他关键字。
  • Clear and easy to follow approach.
  • 清晰并容易理解的方法
  • Allows creating independent keywords and facilitates re-use.
  • 允许创建单个关键字并促进复用。
  • Looks like programming and thus not so good on the test case level.
  • 在测试用例级别上看起来像编码是不好的。
• Alternative approach is storing information in a library or using the BuiltIn Set Test Variable keyword.
• 替代的方式是将信息存储在测试库中或使用内置关键字“Set Test Variable”
  • Avoid programming style on the test case level.
  • 避免测试用例的风格像编码。
  • Can be more complex to follow and make reusing keywords harder.
  • 可以更努力的使用更复杂的和复用关键字。

Good:

好的示例：

*** Test Cases***

Withdraw FromAccount

    Withdraw From Account    $50

    Withdraw Should Have Succeeded

 

*** Keywords ***

Withdraw FromAccount

   [Arguments]   ${amount}

   ${STATUS} =    Withdraw From UserAccount   ${USER}   ${amount}

    Set Test Variable   ${STATUS}

 

Withdraw ShouldHave Succeeded

    Should Be Equal   ${STATUS}   SUCCESS

Not so good:

不好的示例：

*** Test Cases***

Withdraw FromAccount

   ${status} =    Withdraw From Account    $50

    Withdraw Should Have Succeeded   ${status}

 

*** Keywords ***

Withdraw FromAccount

   [Arguments]   ${amount}

   ${status} =    Withdraw From UserAccount   ${USER}   ${amount}

   [Return]   ${status}

 

Withdraw ShouldHave Succeeded

   [Arguments]   ${status}

    Should Be Equal    ${status}    SUCCESS

Avoid sleeping

避免使用sleep关键字

• Sleeping is a very fragile way to synchronize tests.
• 同步测试中使用sleep是一个非常脆弱的方式。
• Safety margins cause too long sleeps on average.
• 普通的安全边际会造成太长的等待时间。
• Instead of sleeps, use keyword that polls has a certain action occurred.
• 使用一定的工作触发的关键字代替sleep关键字。
  • Keyword names often starts with Wait ....
  • 关键字经常用Wait开头
  • Should have a maximum time to wait.
  • 应该包含最长的等待时间。
  • Possible to wrap other keywords inside the BuiltIn keyword Wait Until Keyword Succeeds.
  • 尽量使用内置的关键字“Wait Until Keyword Succeeds”封装成其他关键字。
• Sometimes sleeping is the easiest solution.
• 有些时候sleep是最简单的解决方案。
  • Always use with care.
  • 使用时总是要小心
  • Never use in user keywords that are used often by tests or other keywords.
  • 不要在经常使用用户关键字的测试和其他关键字中使用sleep关键字。
• Can be useful in debugging to stop execution.
• 在debugging时暂停执行还是很有用的。
  • Dialogs library often works better.
  • Dialogs library通常效果更好。