Robot Framework 怎样写好Test Case

最新推荐文章于 2024-01-25 17:03:12 发布

ailun7429

最新推荐文章于 2024-01-25 17:03:12 发布

阅读量357

点赞数

文章标签：测试操作系统

原文链接：http://www.cnblogs.com/kill0001000/p/7928897.html

版权

1.介绍

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

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

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

显然这也会减轻维护成本

如何需要更多关于此方面的信息，你可以看看以下强大的资源：

Robot Framework Dos and Don'ts
Writing Maintainable Automated Acceptance Tests : Dale Emery编写
How to Structure a Scalable And Maintainable Acceptance Test Suite:由Andreas Ebbert-Karroum写的博客

2.命名

2.1.测试套件的名字

测试套件的名字应该尽可能具有描述性
名称由文件或目录名自动创建的

去掉后缀
下划线换成空格
如果名字全部小写，单词首字母换成大写

名字可能适当加长，但是过长的名字对文件系统来说不方便
可以使用--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）
对于一个关键字是否应该全部首字母大写或只有第一个字母大写，没有明确的准则

全部首字母大写往往用于关键字比较短的时候（例如：Input Text）
仅仅第一个字母大写则更适用于类似句子一样的关键字（例如：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的命名

试着去描述做了什么

尽可能用已经存在的关键字来命名

如果setup或teardown包含几个互不相关的步骤，则可以接受更抽象的名称

依次列出测试步骤的名字显得重复，而且维护起来不方便（例如：Login to system,add user,activate alarms and check balance）
用一些通用的表达会更好（例如：Initialize System）

如果实现较低级别步骤的关键字已经存在，那么内置关键字Run Keywords就很好用

当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.测试套件的文档

给测试用例添加一个总的文档是个不错的主意
应该包含背景信息：为什么创建这个测试，注明执行的环境等等
不要仅仅只是简单的重复测试套件的名字

如果不是真的需要，最好不要写文档

不要包含太多关于测试用例的细节

测试应该足够清晰，独立开也可以理解
重复的信息纯属浪费，也会造成维护上的困难

文档可以提供一些链接，以提供更多的信息
如果需要记录以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.测试用例的文档

测试用例一般不需要文档

其父节点测试套件的名字和可能有的文档，再加上测试用例自己的名字应该已经提供了足够的背景信息
测试用例的结构应该清晰到不需要文档和其他的备注说明

标签通常比文档更灵活，而且可以提供更多的功能(统计，包括/排除等等)
有时测试文档是有用的，此时还是鼓励用的

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.用户关键字文档

如果关键字相对简短是不需要文档的

好的关键字，好的参数命名，加上清晰的结构足矣

关键字文档一个重要的用途是：文档化参数和返回值
通过Libdoc和其他编辑器例如RIDE生成的资源文件文档，可以在关键字完成界面和其他地方显示

4.测试套件的结构

一个测试套件内的测试用例相互之间应该具有关联性

常用的setup和/或teardown通常是一个很好的指示物

一个测试套件内不应该包含太多的测试用例（最多10个），除非他们是数据驱动测试
测试套件之间应该相互独立。初始化的工作通过setup和teardown来完成
有时候测试套件之间的依赖性无法避免

例如：单独初始化所有的测试套件需要花费太长的时间
测试套件之间不会有长链条的依赖
考虑使用内置的变量 ${PREV TEST STATUS} 来验证前一个测试套件的状态

5.测试用例的结构

测试用例应该简单易懂
一个测试用例应该只测试一件事情

这个事情可大可小，小的可以是某个单一功能的一部分，大的可以是端到端的测试

选择合适的抽象级别

使用一致的抽象级别(遵循一个抽象原则)
在测试用例级别不要包含非必要的细节

两种测试用例

Workflow tests 工作流测试
Data-driven tests 数据驱动测试

5.1.工作流测试

工作流测试一般包含这些阶段：

前置条件 Precondition (可选的，一般是在setup里面)
动作 Action (对被测系统做一些事情)
验证 Verification (验证结果，必须要做的)
清理现场 Cleanup (可选的，总是在teardown里面以保障其一定会被执行)

关键字描述一个测试是做什么的：

使用清晰的关键字命名以及合适的抽象级别
应该包含足够的信息以便于手动运行
应该不需要任何的文档和备注就可以解释清楚这个测试是做什么的

不同的工作流测试可以使用不同的抽象级别

对详细功能的测试需要具体一些
端到端的测试则可以用高一些的抽象级别
一个工作流内应该只用一种抽象级别

风格差异化

更低级别的细节测试和集成测试使用技术性更强的测试
“可执行规范”作为需求
Use domain language
每个人都应该能够理解，包括用户和/或产品经理

在测试用例级别没有复杂的逻辑

没有循环，if/else语句
谨慎使用变量赋值
测试用例不应该看起来像脚本

一个工作流最多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的关键字

不同的参数创建不同的数据驱动测试
一个数据驱动测试可以多次运行相同的关键字来验证多个相关的变体

如果关键字是作为用户关键字来实现的，那么它通常包含一个类似workflow tests的工作流

除非在其他地方需要，否则在使用它的测试中创建它是一个好主意

建议使用测试模板功能

不需要多次重复一个关键字
在一个测试中更容易测试多个变体

可能的情况下，推荐使用列标题
如果需要大量的测试，请考虑用外部文件来生成测试数据

举例：

*** 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.用户关键字

应该简单易懂

和workflow test遵循同样的规则

不同的抽象level
可以包含一些编程的逻辑（如loop，if/else）

特别是针对一些低级别的关键字
复杂的逻辑放在libraries里，而不是用户关键字里

7.变量Variables

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

8.变量命名

命名要清晰但不要太长
可以在变量的表格中写备注添加更具体的信息
大小写一致

小写的局部变量只能在一定范围内可用
大写字母可以在其他地方使用(全局、套件或测试用例级别)
空格和下划线都可以用作单词分隔符

建议在变量表中还列出动态设置的变量

通常通过内置的关键字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}

9.传递，返回值

常用的方法是从关键字返回值，将它们赋值给变量，然后将它们作为参数传递给其他关键字

清晰且易于遵循的方法
允许创建独立的关键字，更利于重用
看起来像编程，因此在测试用例级别上这样做不太好

替代方法是在library中存储信息或使用内置的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