robotframework 脚本编写规范

2024-03-26 16:56:16

测试集、脚本

  测试脚本的名字不要超过20个字符，文件类型应该为txt
  名字必需易读且有意义（看名知意）
  记住测试集的名字是自动根据文件、目录的名字创建的。后缀名会被截去，下划线会转换为空格，如果名字全部
  为小写，每个单词的首字母会大写。例如login_tests.html->Login Tests,DHCP_and_DNS->DHCP and DNS
  文档应该根据脚本和预先条件进行更新
  为Suite Setup,Suite Teardown, Test Setup 和 Test Teardown设置合适的关键字
  除非是数据驱动的脚本，否则不要在一个测试集中包含太多的测试（最大50）
  

测试用例、测试

   测试用例的名字应该小于40个字符，文件类型应该为txt
   测试用例的名字采用驼峰模式（每个词首字母大写，其它字母小写）
   名字必需易读且有意义（根据名字可以知道测试用例是做什么的）
   文档应该根据测试的步骤，注释，条件信息进行更新
   为每一个case给定合适的tags
   测试之间应该是独立的
   在依赖的测试之间，应该给予详细的注释，并通过${PREV TEST STATUS}变量验证前面测试的状态
   应该避免使用硬编码的对象名字
   应该经常封装高级别关键字来代替重复的步骤
   高级别的关键字应该用于浏览（不关心底层的详细信息）
   局域变量应该以t字母开，作为零时变量
   

资源

  将所有资源放入同一个文件夹
  资源文件的名字需小于20个字符，文件类型为html格式
  所有的字符均为小写
  根据资源的母的更新文档
  所有包含的东西应该维持在一个资源文件中
  对于应用程序的数据应该单独放入一个资源文件
  将所有GUI对象页面向导或者模块向导放入独立的资源文件
  对高级别关键字按功能逻辑，模块，常用的类别进行分组
  

高级别关键字、用户关键字、方法

  方法名字需小于35个字符
  名字必需易读且有意义（根据名字可以知道方法是做什么的）
  使用驼峰命名
  前缀很有用，例如 is 是为了问一个什么问题，get 获取一个值，set 赋一个值
  为了增加可读性，可以有空格
  文档应该包含清晰的描述：用途，变量，返回的值
  避免硬编码对象名字
  参数应该以p开头，返回值应该以r开头，局域变量应该以t开头
  不要添加重复的方法
  能够包含一些程序逻辑（for循环，if/else)
  复杂的逻辑应该放入类库中而不是关键字
  很重要的变量需要在其后面添加注释
  

变量

  变量名不要超过20个字符
  变量名应该是有意义的词
  以驼峰命名
  参数应该以p开头，返回值应该以r开头，局域变量应该以t开头，GUI变量应该以o开头
  常量应该全部大写。例如：APP_URL,DB_SERVER,其它一些类型变量应该是混合类型（小写加大写）
  脚本和全局变量应该放在脚本最前面
  方法、测试用例级别的变量应该定义在方法的最前面
  可以使用空格，但要限制为最少个

    --------------------------------------------------------------------------------------  

 

测试套件(Test suite)的命名

  • 套件的名称应该尽可能地描述这个套件的用途。
  • 名称可以相对长一些，但是如果超过40个字那也太长了一些。
  • 套件名称是直接从文件/目录的名字转换来的。 
    • 文件的后缀名被去掉了
    • 下划线会被转换成空格
    • 如果你的用到的单词都是小写的，那么开头字母会被转换成大写的

比如

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

 

关键词(Keyword)命名

  • 同样的，关键词的名称也应该是清晰具体的。
  • 应该可以表达这个关键词干了什么，而不是它如何去做。
  • 关键词应该是非常不同的抽象层次（比如，「输入字符」或者「用户登录到系统」）。
  • 没有明确的规定

Good:

*** Keywords ***
Login With Valid Credentials

 

Bad:

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

 

Setup和Teardown的命名

  • 试着用名称来描述这个步骤完成了什么。 
    • 或许你可以用一个已经存在的关键词

  • 如果Setup或者Teadown包含了不相关的步骤，那么可以接受更抽象一点的名称。

    • 在名称中列举步骤是一个重复化和维护的问题（比如：登入系统，添加用户，激活警报和检查平衡）。
    • 或许需要用到一些通用一些的名称比如「初始化系统」

  • 如果关键字需要执行的低级步骤已经存在，BuiltIn 关键字中的Run Keywords可以帮你很好的执行它

    • Setup和Teardown脚本只需要运行一次的时候，这样不会出现重复
  • 让每个用到这几个测试用例的人都需要明白这几个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

 

文档

测试套件(Test suite)的文档

  • 通常把文档添加到包含测试用例的最底层套件中是一个不错的想法。 
    • 高层的套件不需要那么频繁地文档化。
  • 文档应该包含必要的背景信息，比如为什么要创建这些测试用例，测试环境中需要注意的点等等。
  • 文档内容不要只是简单地重复套件的名称。 
    • 如果不是真的有文档还不如不添加文档。
  • 文档的内容不要包含关于测试用例的太详细的信息。 
    • 测试用例本身就应该足够清楚易懂了。
    • 重复的信息是一种浪费，而且也不容易维护。
  • 文档中可以添加一些详细内容的链接。
  • 如果你需要在文档中添加一些比如（版本：1.0 或者 OS：Linux）这样的「名称-值」组的话，可以考虑使用测试套件 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.
  • 1
  • 2
  • 1
  • 2

测试用例(Test case)的文档

  • 测试用例通常来说不需要文档。 
    • 套件名称和文档以及用例的名称已经提供了足够的背景信息。
    • 测试用例的结构应该是不需要文档或者其他注释都足够清楚了的。
  • Tag 通常比文档更灵活，还能提供更多的功能（比如：统计，包含/排除等）。
  • 当测试用例的文档是有用的时候，没有必要去害怕它。

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

用户自定义关键词(User keyword)文档

  • 如果这个关键词非常简单明了的话，不需要文档。 
    • 好的名称和明确的结构就足以说明一切了。
  • 用户自定义关键词文档的一个重要的用途是用来记录参数和返回值的信息。
  • 在 RIDE(比如在关键词补全的地方)以及在资源文件中显示的文档是由 libdoc.py 生成的。

测试套件(Test suite)的结构

  • 在套件中的用例应该是互相相关的。 
    • 如果测试用例拥有同样的Setup或者Teardown部分，那么他们应该是属于一个套件的。
  • 除非是数据驱动（data-driven tests）的，在一个套件中不要放10个以上的测试用例。
  • 测试用例应该是独立的。用Setup和Teardown来初始化他们。
  • 有时候测试用例之间无法避免地相关联 
    • 比如说，它可能是因为把所有的用例独立出来要化太多的时间在初始化上。
    • 相关联的测试用例就那么几个（最多4到5个）
    • 下一个用例是用来验证上一个用例的结果的。（用${PREV TEST STATUS} 这个变量）

测试用例(Test case)的结构

  • 测试用例应该是易懂的。
  • 一个测试用例只测试一件事情。 
    • 当然，事情本身可大可小。
  • 选择一个合适的抽象层面。 
    • 一致地使用抽象水平（单一水平的抽象原则）
    • 只包含与测试相关的信息。
  • 用例可以分为两种 
    • 工作流程的测试用例
    • 数据驱动的测试用例

工作流程的测试用例

  • 通常来说有以下这些部分： 
    • 前置条件（可选，通常在Setup部分）
    • 动作 （对被测系统执行一些动作）
    • 验证 （必须有一个验证的部分！）
    • 清理 （可选，通常在Teardown部分，以保证用例已经执行完毕）
  • 关键词是用来描述这个用例做了什么。 
    • 用清晰的关键词名称和合适的抽象层次。
    • 应该包含足够的信息使得手动执行可以启动。
    • 应该从来不需要文档或者沟通来告诉你这个用例在做什么。
  • 不同的用例可以有不同的抽象层次。 
    • 详细的功能测试是更精确的。
    • 端到端的测试可以是一个很高的抽象层次。
    • 一个测试用例应该只使用一种抽象层次。
  • 不同的风格 
    • 对于底层的详细测试和集成测试用例来讲应该是更关注技术细节。
    • 「可执行规范」作为要求。
    • 使用领域中的语言（术语？）。
    • 所有人（包括顾客和产品负责人）都应该可以看明白。
  • 测试用例级别没有复杂的逻辑 
    • 不用 for 循环或者 if/else 判断结构。
    • 小心给变量赋值。
    • 测试用例不应该看起来像脚本一样难读。
  • 最多10步，越少越好。

使用“正常”关键字驱动的风格:

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

 

上面的例子你可以参考web demo project

数据驱动的测试用例

  • 每个测试用例有一个高层次的关键词。 
    • 不同的参数创建不同的测试。
    • 一个测试可以运行相同的关键字多次来验证多种关联的变化
  • 如果关键字是由用户关键字来实现的，那他通常包含类似工作流 的工作流测试 
    • 如果还需要用到其他地方，用一个测试文件创建它比较好
  • 推荐使用测试模板功能。 
    • 不需要多次地去重复关键词。
    • 在一个用例里去测试更容易去测试多种变化。
    • 如果可能，推荐在列头部命名。
  • 如果需要一个非常大的数据的测试，可以考虑用一个外部模块来生成他们

Example:

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

以上例子同样可以在web demo project 中获取到

用户定义关键词(User keywords)

  • 应该容易让人理解 
    • 和工作流程测试用例一样的标准。
  • 不同的抽象层次。
  • 可以包含一些编程逻辑（for 循环，if 判断这些） 
    • 特别对于底层的的关键词。
    • 复杂的逻辑应该放在库里而不是用户定义的关键词里。

变量(Variables)

  • 封装常的或者复杂的值。
  • 可以通过命令行使用 –variable参数传递信息。
  • 在关键词之间传递信息。

变量的命名

  • 清楚，但是不要太长。
  • 可以在变量表格里用注释来说明。
  • 对每个使用场景保持一致： 
    • 小写的本地变量只在当前的用例或者关键词中可用。
    • 全局变量或者套件，用例级别的变量需要大写。
    • 空格或者下划线都可以用来分割变量中的词。
  • 推荐在变量表格中也把设置成动态的变量也列出来。 
    • 用Set Global/Suite/Test variable关键词来命名变量。
    • 变量的初始值应该可以解释真实的值应该是什么。

Example:

*** 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关键词 
    • 不需要在测试用例层面上有什么编程风格。
    • 要遵循起来比较复杂，很难重用关键词。

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

 

避免使用sleeping

  • Sleeping 是非常脆弱的。
  • 平均来说，安全的边界值会使得 Sleeping 很长时间。
  • 用包含了一定的动作触发的关键词来替代 Sleeping 
    等待需要有一个超时的值。 
    • 关键词可以用 Wait … 来开头
    • 可能的话用内置的关键词 Wait Until Keyword Succeeds Succeeds来包装其他关键词。
  • 有时候 Sleeping 是一种最简单的解决方式 
    • 请总是小心使用
    • 不要在经常用到的自定义关键词或者其他关键词中用 Sleeping。
  • 在 Debugging 的时候 Sleeping 用来暂停测试执行还是很有用的。 
上一篇：robotframework中的用evaluate关键字进行运算（随机数+转换+运算）


下一篇：robotframework ride 版本兼容问题