Robot Framework 怎样写好Test Case

1.介绍

  • 这是一个关于如何用Robot Framework写好Test Case的高层次的指导准则

怎样实际的与系统进行交互不在此文档范围内

  • 最重要的准则是使测试用例尽可能的让熟悉此领域的人觉得简单易懂

显然这也会减轻维护成本

  • 如何需要更多关于此方面的信息，你可以看看以下强大的资源：
  1. Robot Framework Dos and Don'ts
  2. Writing Maintainable Automated Acceptance Tests : Dale Emery编写
  3. How to Structure a Scalable And Maintainable Acceptance Test Suite:由Andreas Ebbert-Karroum写的博客

2.命名

2.1.测试套件的名字

  • 测试套件的名字应该尽可能具有描述性
  • 名称由文件或目录名自动创建的
  1. 去掉后缀
  2. 下划线换成空格
  3. 如果名字全部小写，单词首字母换成大写
  • 名字可能适当加长，但是过长的名字对文件系统来说不方便
  • 可以使用--name选项通过命令行覆盖顶层套件的名称

举例：

  • login_tests.robot -> Login Tests
  • IP_v4_and_v6 -> IP v4 and v6

 2.2.测试用例的名字

  • 测试用例的名字应该像测试套件一样，具有描述性
  • 如果一个测试套件下包含了许多类似的测试用例，而这个测试套件已经很好的命名，那测试用例的名字可以短一点
  • 测试用例的名称应该与试用例文档中指定的完全相同，不需要进行任何转换

举例：

如果在文件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

2.3.关键字的名称

  • 关键字的名称应该具有描述性，而且清晰
  • 应该解释这个关键字是做什么的，而不是怎么做的
  • 彼此之间差异很大，是抽象级别的（譬如：Input Text或者Administrator logs into system）
  • 对于一个关键字是否应该全部首字母大写或只有第一个字母大写，没有明确的准则
  1. 全部首字母大写往往用于关键字比较短的时候（例如：Input Text）
  2. 仅仅第一个字母大写则更适用于类似句子一样的关键字（例如：Administrator logs into system）.这类关键字往往是更高层次的（higher level）

Good:

*** Keywords ***
Login With Valid Credentials

Bad:

*** Keywords ***
Input Valid Username And Valid Password And Click Login Button

2.4.setup and teardown的命名

  • 试着去描述做了什么
  1. 尽可能用已经存在的关键字来命名
  • 如果setup或teardown包含几个互不相关的步骤，则可以接受更抽象的名称
  1. 依次列出测试步骤的名字显得重复，而且维护起来不方便（例如：Login to system,add user,activate alarms and check balance）
  2. 用一些通用的表达会更好（例如：Initialize System）
  • 如果实现较低级别步骤的关键字已经存在，那么内置关键字Run Keywords就很好用
  1. 当setup或teardown的场景只需要用一次时，不需要具备可重用性，用Run Keywords就好了。
  • 参与测试的每个人都应该知道每个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

3.文档

3.1.测试套件的文档

  • 给测试用例添加一个总的文档是个不错的主意
  • 应该包含背景信息：为什么创建这个测试，注明执行的环境等等
  • 不要仅仅只是简单的重复测试套件的名字
  1. 如果不是真的需要，最好不要写文档
  • 不要包含太多关于测试用例的细节
  1. 测试应该足够清晰，独立开也可以理解
  2. 重复的信息纯属浪费，也会造成维护上的困难
  • 文档可以提供一些链接，以提供更多的信息
  • 如果需要记录以name-value对表示的信息，请考虑使用测试套件元数据(例如： Version:  1.0  or  OS:  Linux)
  • 顶级套件的文档和元数据可以分别使用 --doc 和 --metadata 选项通过命令行进行设置

Good:

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


Bad (特别是当测试套件的名字已经命名为 account_withdrawal.robot了):

*** Settings ***
Documentation        Tests Account Withdrawal.

3.2.测试用例的文档

  • 测试用例一般不需要文档
  1. 其父节点测试套件的名字和可能有的文档，再加上测试用例自己的名字应该已经提供了足够的背景信息
  2. 测试用例的结构应该清晰到不需要文档和其他的备注说明
  • 标签通常比文档更灵活，而且可以提供更多的功能(统计，包括/排除 等等)
  • 有时测试文档是有用的，此时还是鼓励用的

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

3.3.用户关键字文档

  • 如果关键字相对简短是不需要文档的
  1. 好的关键字，好的参数命名，加上清晰的结构足矣
  • 关键字文档一个重要的用途是：文档化参数和返回值
  • 通过Libdoc和其他编辑器例如RIDE生成的资源文件文档，可以在关键字完成界面和其他地方显示

4.测试套件的结构

  • 一个测试套件内的测试用例相互之间应该具有关联性
  1. 常用的setup和/或teardown通常是一个很好的指示物
  • 一个测试套件内不应该包含太多的测试用例（最多10个），除非他们是数据驱动测试
  • 测试套件之间应该相互独立。初始化的工作通过setup和teardown来完成
  • 有时候测试套件之间的依赖性无法避免
  1. 例如：单独初始化所有的测试套件需要花费太长的时间
  2. 测试套件之间不会有长链条的依赖
  3. 考虑使用内置的变量 ${PREV TEST STATUS} 来验证前一个测试套件的状态

5.测试用例的结构

  • 测试用例应该简单易懂
  • 一个测试用例应该只测试一件事情
  1. 这个事情可大可小，小的可以是某个单一功能的一部分，大的可以是端到端的测试
  • 选择合适的抽象级别
  1. 使用一致的抽象级别(遵循一个抽象原则)
  2. 在测试用例级别不要包含非必要的细节
  • 两种测试用例
  1. Workflow tests          工作流测试
  2. Data-driven tests      数据驱动测试

5.1.工作流测试

  • 工作流测试一般包含这些阶段：
  1. 前置条件 Precondition (可选的，一般是在setup里面)
  2. 动作 Action (对被测系统做一些事情)
  3. 验证 Verification (验证结果，必须要做的)
  4. 清理现场 Cleanup (可选的，总是在teardown里面以保障其一定会被执行)
  • 关键字描述一个测试是做什么的：
  1. 使用清晰的关键字命名以及合适的抽象级别
  2. 应该包含足够的信息以便于手动运行
  3. 应该不需要任何的文档和备注就可以解释清楚这个测试是做什么的
  • 不同的工作流测试可以使用不同的抽象级别
  1. 对详细功能的测试需要具体一些
  2. 端到端的测试则可以用高一些的抽象级别
  3. 一个工作流内应该只用一种抽象级别
  • 风格差异化
  1. 更低级别的细节测试和集成测试使用技术性更强的测试
  2. “可执行规范”作为需求
  3. Use domain language
  4. 每个人都应该能够理解，包括用户 和/或 产品经理
  • 在测试用例级别没有复杂的逻辑
  1. 没有循环，if/else语句
  2. 谨慎使用变量赋值
  3. 测试用例不应该看起来像脚本
  • 一个工作流最多10个步骤，最好更少

举例： 使用 "normal" 关键字驱动

*** Test Cases ***
Valid Login
　　Open Browser To Login Page
　　Input Username　　 demo
　　Input Password 　　 mode
　　Submit Credentials
　　Welcome Page Should Be Open


举例： using higher level "gherkin" style:

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


See the web demo project for executable versions of the above examples.

5.1.数据驱动测试

  • 每个数据驱动测试用一个high-level的关键字
  1. 不同的参数创建不同的数据驱动测试
  2. 一个数据驱动测试可以多次运行相同的关键字来验证多个相关的变体
  • 如果关键字是作为用户关键字来实现的，那么它通常包含一个类似workflow tests的工作流
  1. 除非在其他地方需要，否则在使用它的测试中创建它是一个好主意
  • 建议使用测试模板功能
  1. 不需要多次重复一个关键字
  2. 在一个测试中更容易测试多个变体
  • 可能的情况下，推荐使用列标题
  • 如果需要大量的测试，请考虑用外部文件来生成测试数据

举例：

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

6.用户关键字

  • 应该简单易懂
  1. 和workflow test遵循同样的规则
  • 不同的抽象level
  • 可以包含一些编程的逻辑（如loop，if/else）
  1. 特别是针对一些低级别的关键字
  2. 复杂的逻辑放在libraries里，而不是用户关键字里

7.变量Variables

  • 封装长的和/或复杂的值
  • 使用--variable选项从命令行传递信息
  • 在关键字之间传递信息

8.变量命名

  • 命名要清晰但不要太长
  • 可以在变量的表格中写备注添加更具体的信息
  • 大小写一致
  1. 小写的局部变量只能在一定范围内可用
  2. 大写字母可以在其他地方使用(全局、套件或测试用例级别)
  3. 空格和下划线都可以用作单词分隔符
  • 建议在变量表中还列出动态设置的变量
  1. 通常通过内置的关键字Set Suite Variable来设置动态变量
  2. 初始值应该解释实际值是在哪里设置的以及如何设置的

举例：

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

9.传递，返回值

  • 常用的方法是从关键字返回值，将它们赋值给变量，然后将它们作为参数传递给其他关键字
  1. 清晰且易于遵循的方法
  2. 允许创建独立的关键字，更利于重用
  3. 看起来像编程，因此在测试用例级别上这样做不太好
  • 替代方法是在library中存储信息或使用内置的Set Test Variable关键字
  1. 可以在测试用例级别避免编程的风格
  2. 这种方法相比而言更难以遵循，而且让重用关键字变得更困难

Good:


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


Not so good:


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

10.避免使用sleeping

  • sleep是一种非常脆弱的同步测试方法
  • 为了安全通常会导致sleep时间过长
  • 不用sleep，而是用关键字来验证一系列的动作是否发生了
  1. 此类关键字命名时一般以wait...开头
  2. 应该给一个最大的等待时间
  3. 可能会将其他的关键字包装在内置关键字Wait Until Keyword Scuceeds中
  • 有时候sleeping是最简单的解决方案
  1. 需要时刻谨慎使用
  2. 避免在那些经常被测试用例或其他关键字调用的用户关键字中使用sleep
  • 在debug过程中要停止执行时sleep显得很有用
    1. Dialog library总是很好用
【推广】 免费学中医，健康全家人
原文地址：https://www.cnblogs.com/kill0001000/p/7928897.html