測試集、腳本
測試腳本的名字不要超過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:
Bad:
*** Keywords ***
Input Valid Username And Valid Password And Click Login Button
Setup和Teardown的命名
Good:
*** 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):
測試用例(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
等待需要有一個超時的值。
- 有時候 Sleeping 是一種最簡單的解決方式
- 請總是小心使用
- 不要在經常用到的自定義關鍵詞或者其他關鍵詞中用 Sleeping。
- 在 Debugging 的時候 Sleeping 用來暫停測試執行還是很有用的。
