github地址：https://github.com/robotframework/HowToWriteGoodTestCases/blob/master/HowToWriteGoodTestCases.rst，這個文檔是官方描述如何寫好用例的，主要內容包括：命名規範、文檔使用、用例結構組織等。
1.命名
1.1 測試用例集命名
- 通常一個robot文件爲一個測試用例集，如：
test_login.robot，那麼它的測試用例集名稱就是Test Login. - 所以，測試用例集的命名符合以下3個規則：
1.會去掉擴展名
robot. 2.會把下劃線轉換爲空格. 3.會將每個單詞的首字母大寫.
- 測試用例集的命名長度是沒有限制的，但是測試用例集是以文件形式存在於操作系統的文件系統中，當測試用例集的命名超過操作系統支持的最大長度或字符不滿足操作系統要求，是會出現問題的。
1.2 測試用例命名
- 測試用例命名時，需要結合測試用例集的命名，使測試用例集名稱+測試用例名稱能夠充分描述一個用例的功能。
- 因此，在命名時，需要注意，名稱不要冗餘，見示例圖：
1.3 關鍵字命名
- 關鍵字命名應該是清晰的描述性語言，用於解釋關鍵字的作用，而不是怎樣用。
- 示例見圖片：
1.4 setup and teardown命名
- 採用已有的關鍵字進行命名操作
- 當有多個步驟，用AND連接
- 當這個用例集的setup和teardown只需要運行一次時，需要加上關鍵字
Run Keywords
2.文檔
2.1 測試集文檔
- 對測試集添加文檔說明，有助於明確測試用例集的功能及背景信息
- 測試集的文檔信息中，應該包括：創建原因、執行環境信息等，爲了能更好的瞭解背景信息，也可以添加鏈接
- 當不需要測試集的文檔描述時，可以不必添加
- 測試集的描述應該簡潔清晰，不需要添加詳細的測試用例信息
2.2 測試用例文檔
- 測試用例通常不需要文檔說明
- 測試用例的功能由用例名稱和用例集的描述進行體現，因此用例名稱需要簡潔貼切
- 如果需要對用例進行描述，可以添加
[Tags]對用例進行一個簡要說明 - 最後，測試用例文檔描述並非不可用哦，需要用
Documentation才能清楚描述的話，還是可以採用的
2.3 關鍵字文檔
- 關鍵字通常不需要進行文檔描述
- 使用簡潔明確的關鍵字信息就可以了
3.測試集結構
- 一個測試集中的測試用例應該有相關性，比如：能夠用同一組setup/teardown
- 除數據驅動類的用例外，一個測試集中的用例最好不要超過10個
- 測試集中的用例應該保持獨立性，用例之間不要關聯，如：用例2需要用到用例1成功才能執行，不能存在這類關聯性
- 但有時，用例之間的關聯性是不能避免的，這時應該如何處理呢？
1.情況1：當用例2需要用到用例1的結果，但如果將用例1放入setup的執行步驟中，會導致所有用例的初始化時間過長，可以考慮關聯；
2.但是不要使用例關聯的鏈過長，如：用例4關聯用例3、用例3關聯用例2、用例2關聯用例1，這類過長的關聯鏈很容易出現問題，在規劃用例時，需要採用一些手段進行用例的合理規劃；
3.當用例關聯時，需要用到上一個用例的結果，可以採用內置關鍵字
${PREV TEST STATUS}進行驗證。
4.測試用例結構
- 測試用例應該簡潔明瞭，易於理解和閱讀
- 一個測試用例應該驗證一個功能點或一個測試點
- 設置合適的用例級別，如用於：冒煙測試或全量測試
- 用例通常分爲2種類型：工作流程用例和數據驅動用例
4.1 流程用例
- 流程用例通常包含以下幾個要素：前置條件、執行步驟、斷言驗證、環境恢復
- 用例是由關鍵字進行描述的，關鍵字清晰明確，不需要文檔或註釋去描述用例實現的功能是什麼
- 不同的用例應該有不同的測試級別，一個用例只能有一個測試級別，通常E2E（指一個完整功能點）的用例擁有較高級別
- 測試用例的風格： 1.更多的低級別的詳細信息的技術測試和集成測試； 2.將“可執行規範”作爲需求文檔； 3.使用領域特定語言； 4.用例易於理解，客戶或產品經理等都能看懂用例描述的功能。
- 測試用例中沒有複雜的邏輯，如：條件判斷和循環、變量的賦值使用合理、用例看起來不應該像腳本。
- 每個用例的步驟不要超過10個，最好少於10個；
- 工作流測試的用例示例，如圖：
4.2 數據驅動用例
- 每個用例中，都有一個高級別的關鍵字： 1.不同的參數需要創建不同的用例； 2.一個測試用例中，可以採用多組參數來運行同一個關鍵字多次，去驗證多個相關的變化。
- 如果關鍵字是以用戶關鍵字實現的，那它通常在工作流用例中有一個相似的流程：除非在其他地方需要，否則最好將它與使用它的測試創建在同一個文件中。
- 數據驅動用例推薦使用測試模板，這樣可以減少關鍵字重複，更易於在同一用例中使用多組變量數據；
- 由於使用的參數通常不止一個，建議在用例的標頭對使用的參數進行命名，這樣更易於閱讀，如圖所示：
- 如果一個用例需要使用大量的測試數據，建議將數據保存在一個外部文件中，讀取後進行參數化操作
- 數據驅動示例如圖：
5.用戶關鍵字
- 關鍵字應該易於理解，不需要文檔或註釋去描述用例實現的功能是什麼
- 關鍵字具備不同的抽象級別
- 關鍵字中允許有程序邏輯，如：循環和判斷
- 但是複雜的邏輯最好放在Library中，通過關鍵字去調用，不要在用戶關鍵字中去實現複雜邏輯
6.變量
- 變量用於封裝過長或者過於複雜的值
- 在命令行中進行參數傳遞時，可以採用
--variable選項 - 在關鍵字之間傳遞信息
6.1 變量命名規則
- 短小清晰
- 在變量表中可以使用文檔或註釋對變量進行說明
- 變量的使用說明： 1.以小寫的單詞作爲局部變量的命名； 2.以大寫的單詞作爲全局變量的命名； 3.單詞之間可以使用空格或下劃線進行分割；
- 建立在變量列表中，設置動態的變量，如：列表、字典格式的變量
- 設置動態變量通常使用內置關鍵字： Set Suite Variable
- 定義變量時，同時需要進行初始化操作
6.2 傳遞和返回值
- 常見方法是，將關鍵字返回的值傳遞給變量，再將變量以參數形式傳遞給其他關鍵字： 1.傳遞過程應該明確且易於遵循； 2.創建獨立的關鍵字，使關鍵字易於複用； 3.在測試用例級別上使用領域性語言，使用例看起來不像程序；
- 爲了避免用例像程序語言風格，以及破壞關鍵字的複用性，可以將需要傳遞值的功能寫入Library或者使用內置關鍵字 Set Test Variable進行存儲。
7.避免使用sleeping
- 使用sleeping，極易造成同步測試的不穩定；
- 通常，安全邊界會導致過長的睡眠時間；
- 因此，我們可以使用內置關鍵字代替sleep：Wait Until Keyword Succeeds
- 但是有時，對於邏輯功能實現，使用sleep也是一個有效的解決方案，所以要善於使用，但是不要用於調用頻繁的用戶關鍵字中。
總結
- 通過閱讀How to write good test cases，瞭解了使用RobotFramework編寫用例的規則
- 遵循規則編寫用例，才能寫出更易於閱讀、理解和穩定的用例
作者：今天我叫陳開心 鏈接：https://www.jianshu.com/p/20e7a539ba32