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總是很好用