有關此主題的更多信息，您可以查看以下優秀資源:
編寫可維護的自動驗收測試
如何構建可擴展和可維護的驗收測試套件
名字
測試套件的命名
包的名稱應盡可能描述包的用途。
名稱可以相對較長，但如果超過40個單詞就太長了。
請記住，Robotframework的包名是直接從文件/目錄的名稱轉換而來的。文件的後綴已被刪除，下劃線將被轉換為空格。如果您使用的所有單詞都是小寫，首字母將轉換為大寫。例如，login_test.txt將轉換為登錄測試，DHCP _ and _ DNS將轉換為DHCP和DNS。
測試用例的命名
測試用例的名稱應該與套件的名稱描述相似。
如果壹個套件包含幾個相似的測試用例，並且測試套件本身已經被很好地命名，那麽用例的名稱可以更短。
測試用例文件中的名稱應該準確地表達您需要做什麽。
關鍵詞命名
同樣，關鍵詞的名稱也應該清晰具體。
它應該能夠表達這個關鍵字做了什麽，而不是它是如何做的。
關鍵詞應該處於不同的抽象層次（例如，“輸入字符”或“用戶登錄系統”）。
生成和分解的命名
試著用壹個名字來描述這壹步完成了什麽。
也許妳可以使用現有的關鍵字。
如果生成或分解包含不相關的步驟，可以接受更抽象的名稱。
在名稱中列出步驟是壹個重復和維護的問題（例如登錄系統、添加用戶、激活警報和檢查余額）。
您可能需要使用壹些常見的名稱，例如“初始化系統”
每個使用這些測試用例的人都需要理解這些生成或分解動作的目的。
文件
測試套件的文檔
將文檔添加到包含測試用例的最低套件中通常是壹個好主意。
高級套件不需要如此頻繁地記錄。
文檔應該包含必要的背景信息，例如為什麽創建這些測試用例，在測試環境中應該註意的點等等。
文檔內容不應簡單地重復套件的名稱。
如果妳沒有真正的文檔，妳最好不要添加它。
文檔的內容不應該包含關於測試用例的太詳細的信息。
測試用例本身應該足夠清晰易懂。
重復的信息是壹種浪費，並且不容易維護。
您可以在文檔中添加壹些詳細信息的鏈接。
如果您需要向文檔中添加壹些“名稱-值”組，比如（版本:1.0或OS: Linux），您可以考慮使用測試套件元數據。
測試用例的文檔
測試用例通常不需要文檔。
套件的名稱和文檔以及用例的名稱已經提供了足夠的背景信息。
測試用例的結構應該足夠清晰，沒有文檔或其他註釋。
標簽通常比文檔更靈活，可以提供更多功能。
當測試用例文檔有用時，不要擔心沒有添加它。
用戶定義的關鍵字文檔
如果這個關鍵字非常簡單明了，就不需要任何文檔。
壹個好的名字和清晰的結構足以說明壹切。
自定義關鍵字文檔的壹個重要用途是記錄參數和返回值的信息。
RIDE中顯示的文檔（如關鍵字完成的位置）和資源文件中顯示的文檔由libdoc.py生成
測試套件的結構
套件中的用例應該是相互關聯的。
如果測試用例具有相同的生成或分解部分，它們應該屬於壹個套件。
除非是數據驅動的，否則不要在壹個套件中放置超過10個測試用例。
測試用例應該是獨立的。
用生成和分解來初始化它們。
有時如果測試用例不可避免地相關聯。
例如，可能是因為獨立初始化所有用例花費了太多時間。
只有幾個相關的測試用例（最多4到5個）。
下壹個用例用於驗證前壹個用例的結果。（使用變量$ {前壹測試狀態}）
測試用例的結構
測試用例應該易於理解。
壹個測試用例只測試壹件事。
當然，這件事本身可大可小。
選擇適當的抽象層次。
壹致地使用抽象層次（單壹抽象層次原則）
僅包含與測試相關的信息。
用例可以分為兩種類型。
工作流測試用例
數據驅動的測試用例
工作流測試用例
壹般來說，有以下幾個部分:
前提條件（可選，通常在生成部分）
操作（在測試系統上執行壹些操作）
驗證（必須有驗證部分！)
清理（可選，通常在分解部分，以確保用例已經執行）
關鍵詞用於描述這個用例做什麽。
使用清晰的關鍵字名稱和適當的抽象層次。
應該包含足夠的信息以便可以開始手動執行。
妳永遠不需要文檔或交流來告訴妳這個用例在做什麽。
不同的用例可以有不同的抽象層次。
詳細的功能測試更準確。
端到端測試可以是壹個非常高的抽象層次。
壹個測試用例應該只使用壹個抽象層次。
不同風格
對於底層的詳細測試和集成測試用例，應該更加關註技術細節。
“可執行定義”起到需求的作用。
使用領域內的語言（術語？)。
每個人（包括客戶和產品負責人）都應該能夠理解它。
不完全邏輯
不要使用for循環或if/else來判斷結構。
小心地給變量賦值。
測試用例看起來不應該像腳本壹樣難以閱讀。
最多10步，越少越好。
數據驅動的測試用例
每個測試用例都有壹個高級關鍵字。
不同的參數創建不同的測試。
關鍵字通常包含與相同用例文件中的工作流測試用例中描述的過程相似的過程。
建議使用測試模板功能。
不需要多次重復關鍵詞。
測試用例中的各種變化更容易。
如果可能，建議命名列標題。
如果妳真的需要大量的測試用例，考慮將它們作為外部依賴模型。
用戶定義的關鍵字
應該很容易理解。
與工作流測試用例相同的標準。
不同的抽象層次。
可以包含壹些編程邏輯（用於循環，如果確定這些）
尤其是對於底部關鍵詞。
復雜的邏輯應該放在庫中，而不是用戶定義的關鍵字。
可變的
封裝常量或復數值。
從命令行傳遞信息。
在關鍵字之間傳遞信息。
變量的命名
是的，但是不要太久。
這可以通過變量表中的註釋來解釋。
對每個使用場景保持壹致:
小寫局部變量僅在當前用例或關鍵字中可用。
全局變量或套件，用例級別的變量需要大寫。
空格或下劃線可以用來分隔變量中的單詞。
建議設置為動態的變量也應列在變量表中。
使用關鍵字Set Global/Suite/Test variable來命名變量。
變量的初始值應該說明真正的值應該是什麽。
傳遞和返回值
通常的方法是通過關鍵字返回值，將它們分配給變量，然後將它們傳遞給其他關鍵字的參數。
清晰輕松地遵循這個方法。
看起來像編程。
另壹種方法是使用Set測試變量關鍵字。
測試用例級別不需要任何編程風格。
遵循起來很復雜，並且很難重用關鍵字。
避免以下級別的測試用例。
避免睡覺。
睡覺很脆弱。
平均而言，壹個安全的邊界值會使睡眠時間延長。
用包含特定動作觸發器的關鍵詞替換睡眠。
等待需要超時值。
關鍵詞可以從等到開始
如果可能，用內置關鍵字waituntill關鍵字成功包裝其他關鍵字。
有時候睡覺是最簡單的解決辦法。
請始終小心使用它，不要在常用的自定義關鍵字或其他關鍵字中使用Sleeping。
睡眠對於調試期間暫停測試執行很有用。
盡管對話圖書館通常更適合於此。