⑴ RobotFramework 自動化框架環境搭建及使用
一、為什麼要做自動化？
前提：主流程穩定，周期長，腳本可重復利用。
1.節省人力資源
2.提高效率
3.面試需要
二、什麼是RobotFramework：
基於Python的關鍵字驅動的自動化框架。
1. 基於Python：就是由python語言開發的這個框架。
2.關鍵字驅動：關鍵字驅動測試又稱為表格驅動測試，是自動化測試的一種方法，是數據測試的一種改進方法。關鍵字驅動主要包括測試步驟、測試步驟中的對象，測試對象執行的動作，測試對象需要的數據
3.自動化框架？：是應用於自動化測試，框架提供可重用的基礎自動化測試平台，提供自動化測試執行和管理功能的組織架構。
三、pip的常用方法：
pip 是 Python 包管理工具，該工具提供了對Python 包的查找、下載、安裝、卸載的功能。
以下在win10_x64 cmd中操作：
安裝：pip install 包名
eg：pip install robotframework
安裝指定版本：pip install 包名==版本號
eg：pip install robotframework==1.7.4.1
升級指定包：pip install --upgrade 包名
eg：pip install --upgrade robotframework
卸載：pip uninstall 包名
eg：pip uninstall robotframework
搜索安裝包：pip search 包名
eg：pip search robotframework
查看當前電腦上已經安裝的包：pip list
查看當前電腦上可以升級的包：pip list -o
四、rf的安裝：
安裝RF自動化框架：pip install robotframework
安裝RF自動化框架IDE：pip install robotframework-ride
安裝wxpython（ride依賴wxpython）：pip install wxpython
ps ：實際上新版本pip在安裝ride時會自動安裝所需依賴，也就是wxpython
版本信息：Win10 x64 + Python 3.7.7 + rf 3.1.2 + ride 1.7.4.1 + wxpython 4.0.7.post2
ps ：ride 1.x版本不支持Python 3.8及以上，ride 2.x（開發中）支持Python 3.8
rf日誌中文亂碼解決方法：修改文件 python安裝目錄下 Libsite-packagesrobotidecontrib estrunner estrunnerplugin.py 第 565 行，將 SYSTEM 改成 OUTPUT ，重啟ride工具。
五、元素定位：
id ：以網路搜索輸入框為例
在RF中寫法： id=kw
name ：以網路搜索輸入框為例
在RF中寫法： name=wd
xpath ：Xml Path Language
1. 絕對路徑：從html根部逐級（從上至下）查找
/html/body/p[1]/p[1]/p[3]/p/p/form/span[1]/input
在RF中寫法：xpath=/html/body/p[1]/p[1]/p[3]/p/p/form/span[1]/input
2.相對路徑：根據節點的上下文進行查找
eg：//p/form/span/input 這里是在html中找一個p，p裡麵包含一個form，form包含一個span，span包含一個input，找有這樣一個四層的關系的input標簽，要注意如果html中有多個符合這種層級關系的input，會默認選第一個，也就是說這種方式未必是完全准確的。
3. xpath相對定位我們還可以根據元素的屬性來查找：
eg：//p/form/span[1]/input[@type] 這里是找符合這樣一個層級關系並且有'type'這個屬性的input標簽
在RF中寫法：xpath=//p/form/span[1]/input[@type]
eg：//p/form/span[1]/input[@type='submit'] 這里是找符合這樣一個層級關系並且'type'這個屬性的值為'submit'的input標簽
在RF中寫法：xpath=//p/form/span[1]/input[@type='submit']
eg：//p/form/span[1]/input[contains(@type,'sub')] 這里是找符合這樣一個層級關系並且'type'這個屬性的值包含'sub'的input標簽
在RF中寫法：xpath=//p/form/span[1]/input[contains(@type,'sub')]
以上是根據屬性，如果是下面這樣的a標簽，我們還可以根據鏈接文字來進行定位
點我
eg：//a[contains(text(),'點我')] 這樣就是找所有a標簽並且文字為'點我'的元素了
在RF中寫法：xpath=//a[contains(text(),'點我')]
小技巧：
在 Chrome-F12-Console 中根據Xpath尋找元素：使用 $x ("")，引號中填寫xpath路徑，如$x("/html/body/p[1]/p[1]/p[3]/p/p/form/span[1]/input")
css：
id： 以網路搜索輸入框為例
在RF中寫法： css=#kw
class： 以網路搜索輸入框為例
在RF中寫法： css=.s_ipt
css根據屬性定位 ：
[id='kw'] 表示查找id值為'kw'的元素
[name^='w'] 表示查找name值為'k'開頭的元素
[class$='ipt'] 表示查找class值為'ipt'結尾的元素
[autocomplete*='f'] 表示查找autocomplete值中包含'f'的元素
[id='kw'] [name^='w'] 表示查找id值為'kw'並且name值為'k'開頭的元素
在RF中寫法：css=[id='kw'] [name^='w']、css=[class$='ipt']、
css=[maxlength=饗']、css=[autocomplete='off']
ps：id和class也是屬性，只是在css中針對id和class多了一種簡單的寫法，如上面的
css=#kw、css=.s_ipt
css根據標簽定位：
input
表示查找當前頁面所有input標簽
在RF中寫法：css=input
a,input
表示查找當前頁面所有a標簽和input標簽
在RF中寫法：css=a,input
span input
表示查找span標簽下的所有input標簽，哪怕是span下下級的input
在RF中寫法：css=span input
span>input
表示查找父元素為span標簽的所有input標簽，注意和span input的區別
在RF中寫法：css=span>input
span+input
表示查找緊挨在span元素後的第一個input元素
在RF中寫法：css=span+input
span~input
表示查找緊挨在span元素後的所有input元素
在RF中寫法：css=span~input
ps ：其實大家都知道，因為頁面上只依靠標簽定位的話重復的可能性太大了，所有我們可以採用 標簽 + 屬性 的方式來進行定位
例如 span>input[id='kw'][name^='w'] 意思是查找所有父標簽為span的input標簽，並且該標簽中有屬性id的值為kw且屬性name的值為w開頭
在RF中寫法：css=span>input[id='kw'][name^='w']
小技巧：
在 Chrome-F12-Console 中根據css尋找單個元素：
使用 $ ("")，引號中填寫css選擇器，如$("span>input[id='kw'][name^='w']")
在 Chrome-F12-Console 中根據css尋找多個元素：
使用 $ ("")，引號中填寫css選擇器，如$("span>input[id='kw'][name^='w']")
⑵ 如何用 Robot Framework 來編寫優秀的測試用例
我們使用符合RobotFramework規范的一種表格語法來編寫測試用例。用例一般會是下面這個樣子這樣的表格存儲到一個文件中，就是一組測試用例。RF支持多種格式，如HTML，TSV,純文本等。它們長相大同小異，其實描述的都是一種內容。為了方便，推薦使用RIDE這個用例的編輯工具來編寫測試用例，這些文本在RIDE環境下被打開長得是一個樣子的。
⑶ robot framework 怎麼調試腳本
需要的 我們使用符合Robot Framework規范的一種表格語法來編寫測試用例。用例一般會是下面這個樣子 這樣的表格存儲到一個文件中，就是一組測試用例。RF支持多種格式，如HTML，TSV,純文本等。它們長相大同小異，其實描述的都是一種內容。
⑷ 如何用 Robotframework 來編寫優秀的測試用例
命名測試套件的命名套件的名稱應該盡可能地描述這個套件的用途。名稱可以相對長一些，但是如果超過40個字那也太長了一些。記住Robotframework的套件名稱是直接從文件/目錄的名字轉換來的。文件的後綴名被去掉了而且下劃線會被轉換成空格，如果你的用到的單詞都是小寫的，那麼開頭字母會被轉換成大寫的。比如login_test.txt會被轉換成LoginTests,DHCP_and_DNS會被轉換成DHCPandDNS。測試用例的命名測試用例的名字應該與套件的名字描述相似。如果一個套件里包含了好多個相似的測試用例，而且測試套件本身已經很好地命名了，那麼用例的名稱可以簡短一些。在測試用例文件中的名稱應該恰好表達了你需要做什麼。關鍵詞命名同樣的，關鍵詞的名稱也應該是清晰具體的。應該可以表達這個關鍵詞幹了什麼，而不是它如何去做。關鍵詞應該是非常不同的抽象層次（比如，「輸入字元」或者「用戶登錄到系統」）。生成和分解的命名試著用名稱來描述這個步驟完成了什麼。或許你可以用一個已經存在的關鍵詞如果生成或者分解包含了不相關的步驟，那麼可以接受更抽象一點的名稱。在名稱中列舉步驟是一個重復化和維護的問題（比如：登入系統，添加用戶，激活警報和檢查平衡）。或許需要用到一些通用一些的名稱比如「初始化系統」每個用到這幾個測試用例的人都需要明白這幾個生成或者分解動作是干什麼的。文檔測試套件的文檔通常把文檔添加到包含測試用例的最底層套件中是一個不錯的想法。高層的套件不需要那麼頻繁地文檔化。文檔應該包含必要的背景信息，比如為什麼要創建這些測試用例，測試環境中需要注意的點等等。文檔內容不要只是簡單地重復套件的名稱。如果不是真的有文檔還不如不添加文檔。文檔的內容不要包含關於測試用例的太詳細的信息。測試用例本身就應該足夠清楚易懂了。重復的信息是一種浪費，而且也不容易維護。文檔中可以添加一些詳細內容的鏈接。如果你需要在文檔中添加一些比如（版本：1.0或者OS：Linux）這樣的「名稱-值」組的話，可以考慮使用測試套件metadata測試用例的文檔測試用例通常來說不需要文檔。套件名稱和文檔以及用例的名稱已經提供了足夠的背景信息。測試用例的結構應該是不需要文檔或者其他注釋都足夠清楚了的。Tag通常比文檔更靈活，還能提供的功能。當測試用例的文檔是有用的時候，也不要擔心而不去添加喲。用戶自定義關鍵詞文檔如果這個關鍵詞非常簡單明了的話，不需要文檔。好的名稱和明確的結構就足以說明一切了。用戶自定義關鍵詞文檔的一個重要的用途是用來記錄參數和返回值的信息。在RIDE(比如在關鍵詞補全的地方)以及在資源文件中顯示的文檔是由libdoc.py生成的。測試套件的結構在套件中的用例應該是互相相關的。如果測試用例擁有同樣的生成或者分解部分，那麼他們應該是屬於一個套件的。除非是數據驅動的，在一個套件中不要放10個以上的測試用例。測試用例應該是獨立的。用生成和分解來初始化他們。有時候如果測試用例之間無法避免地相關聯比如說，它可能是因為把所有的用例獨立出來要化太多的時間在初始化上。相關聯的測試用例就那麼幾個（最多4到5個）下一個用例是用來驗證上一個用例的結果的。（用${PREVTESTSTATUS}這個變數）測試用例的結構測試用例應該是易懂的。一個測試用例只測試一件事情。當然，事情本身可大可小。選擇一個合適的抽象層面。一致地使用抽象水平（單一水平的抽象原則）只包含與測試相關的信息。用例可以分為兩種工作流程的測試用例數據驅動的測試用例工作流程的測試用例通常來說有以下這些部分：前置條件（可選，通常在生成部分）動作（對被測系統執行一些動作）驗證（必須有一個驗證的部分！）清理（可選，通常在分解部分，以保證用例已經執行完畢）關鍵詞是用來描述這個用例做了什麼。用清晰的關鍵詞名稱和合適的抽象層次。應該包含足夠的信息使得手動執行可以啟動。應該從來不需要文檔或者溝通來告訴你這個用例在做什麼。不同的用例可以有不同的抽象層次。詳細的功能測試是更精確的。端到端的測試可以是一個很高的抽象層次。一個測試用例應該只使用一種抽象層次。不同的風格對於底層的詳細測試和集成測試用例來講應該是更關注技術細節。「可執行定義」來扮演需求。使用領域中的語言（術語？）。所有人（包括顧客和產品負責人）都應該可以看明白。不復雜的邏輯不用for循環或者if/else判斷結構。小心給變數賦值。測試用例不應該看起來像腳本一樣難讀。最多10步，越少越好。數據驅動的測試用例每個測試用例有一個高層次的關鍵詞。不同的參數創建不同的測試。關鍵詞通常包含了與同一個用例文件中工作流程測試用例中描述的流程類似的流程。推薦使用測試模板功能。不需要多次地去重復關鍵詞。在一個用例里去測試更容易去測試多種變化。如果可能，推薦在列頭部命名。如果真的需要很多測試用例，考慮把他們做成依賴於外部的模型。用戶定義關鍵詞應該容易讓人理解和工作流程測試用例一樣的標准。不同的抽象層次。可以包含一些編程邏輯（for循環，if判斷這些）特別對於底層的的關鍵詞。復雜的邏輯應該放在庫里而不是用戶定義的關鍵詞里。變數封裝常的或者復雜的值。從命令行傳遞信息。在關鍵詞之間傳遞信息。變數的命名清楚，但是不要太長。可以在變數表格里用注釋來說明。對每個使用場景保持一致：小寫的本地變數只在當前的用例或者關鍵詞中可用。全局變數或者套件，用例級別的變數需要大寫。空格或者下劃線都可以用來分割變數中的詞。推薦在變數表格中也把設置成動態的變數也列出來。用SetGlobal/Suite/Testvariable關鍵詞來命名變數。變數的初始值應該可以解釋真實的值應該是什麼。傳遞和返回值通常的方式是通過關鍵詞來返回值，把他們賦給變數，然後傳遞給其他關鍵詞的參數。清楚易懂地遵循這個方法。看起來像是編程。備選方案是使用SetTestVariable關鍵詞不需要在測試用例層面上有什麼編程風格。要遵循起來比較復雜，很難重用關鍵詞。避免以下這種測試用例層級。避免使用sleepingSleeping是非常脆弱的。平均來說，安全的邊界值會使得Sleeping很長時間。用包含了一定的動作觸發的關鍵詞來替代Sleeping等待需要有一個超時的值。關鍵詞可以用WaitUntil…來開頭可能的話用內置的關鍵詞WaitUntilKeywordSucceeds來包裝其他關鍵詞。有時候Sleeping是一種最簡單的解決方式請總是小心使用，不要在經常用到的自定義關鍵詞或者其他關鍵詞中用Sleeping。在Debugging的時候Sleeping用來暫停測試執行還是很有用的。雖然DialogsLibrary通常更適合用來干這個。
⑸ 如何使用RobotFramework編寫好的測試用例
命名
測試套件的命名
套件的名稱應該盡可能地描述這個套件的用途。
名稱可以相對長一些，但是如果超過40個字那也太長了一些。
記住 Robotframework 的套件名稱是直接從文件/目錄的名字轉換來的。文件的後綴名被去掉了而且下劃線會被轉換成空格，如果你的用到的單詞都是小寫的，那麼開頭字母會被轉換成大寫的。比如 login_test.txt 會被轉換成 Login Tests, DHCP_and_DNS 會被轉換成 DHCP and DNS。
測試用例的命名
測試用例的名字應該與套件的名字描述相似。
如果一個套件里包含了好多個相似的測試用例，而且測試套件本身已經很好地命名了，那麼用例的名稱可以簡短一些。
在測試用例文件中的名稱應該恰好表達了你需要做什麼。
關鍵詞命名
同樣的，關鍵詞的名稱也應該是清晰具體的。
應該可以表達這個關鍵詞幹了什麼，而不是它如何去做。
關鍵詞應該是非常不同的抽象層次（比如，「輸入字元」或者「用戶登錄到系統」）。
生成和分解的命名
試著用名稱來描述這個步驟完成了什麼。
或許你可以用一個已經存在的關鍵詞
如果生成或者分解包含了不相關的步驟，那麼可以接受更抽象一點的名稱。
在名稱中列舉步驟是一個重復化和維護的問題（比如：登入系統，添加用戶，激活警報和檢查平衡）。
或許需要用到一些通用一些的名稱比如「初始化系統」
每個用到這幾個測試用例的人都需要明白這幾個生成或者分解動作是干什麼的。
文檔
測試套件的文檔
通常把文檔添加到包含測試用例的最底層套件中是一個不錯的想法。
高層的套件不需要那麼頻繁地文檔化。
文檔應該包含必要的背景信息，比如為什麼要創建這些測試用例，測試環境中需要注意的點等等。
文檔內容不要只是簡單地重復套件的名稱。
如果不是真的有文檔還不如不添加文檔。
文檔的內容不要包含關於測試用例的太詳細的信息。
測試用例本身就應該足夠清楚易懂了。
重復的信息是一種浪費，而且也不容易維護。
文檔中可以添加一些詳細內容的鏈接。
如果你需要在文檔中添加一些比如（版本：1.0 或者 OS：Linux）這樣的「名稱-值」組的話，可以考慮使用測試套件 metadata
測試用例的文檔
測試用例通常來說不需要文檔。
套件名稱和文檔以及用例的名稱已經提供了足夠的背景信息。
測試用例的結構應該是不需要文檔或者其他注釋都足夠清楚了的。
Tag 通常比文檔更靈活，還能提供更多的功能。
當測試用例的文檔是有用的時候，也不要擔心而不去添加喲。
用戶自定義關鍵詞文檔
如果這個關鍵詞非常簡單明了的話，不需要文檔。
好的名稱和明確的結構就足以說明一切了。
用戶自定義關鍵詞文檔的一個重要的用途是用來記錄參數和返回值的信息。
在 RIDE(比如在關鍵詞補全的地方)以及在資源文件中顯示的文檔是由 libdoc.py 生成的。
測試套件的結構
在套件中的用例應該是互相相關的。
如果測試用例擁有同樣的生成或者分解部分，那麼他們應該是屬於一個套件的。
除非是數據驅動的，在一個套件中不要放10個以上的測試用例。
測試用例應該是獨立的。
用生成和分解來初始化他們。
有時候如果測試用例之間無法避免地相關聯
比如說，它可能是因為把所有的用例獨立出來要化太多的時間在初始化上。
相關聯的測試用例就那麼幾個（最多4到5個）
下一個用例是用來驗證上一個用例的結果的。（用${PREV TEST STATUS} 這個變數）
測試用例的結構
測試用例應該是易懂的。
一個測試用例只測試一件事情。
當然，事情本身可大可小。
選擇一個合適的抽象層面。
一致地使用抽象水平（單一水平的抽象原則）
只包含與測試相關的信息。
用例可以分為兩種
工作流程的測試用例
數據驅動的測試用例
工作流程的測試用例
通常來說有以下這些部分：
前置條件（可選，通常在生成部分）
動作 （對被測系統執行一些動作）
驗證 （必須有一個驗證的部分！）
清理 （可選，通常在分解部分，以保證用例已經執行完畢）
關鍵詞是用來描述這個用例做了什麼。
用清晰的關鍵詞名稱和合適的抽象層次。
應該包含足夠的信息使得手動執行可以啟動。
應該從來不需要文檔或者溝通來告訴你這個用例在做什麼。
不同的用例可以有不同的抽象層次。
詳細的功能測試是更精確的。
端到端的測試可以是一個很高的抽象層次。
一個測試用例應該只使用一種抽象層次。
不同的風格
對於底層的詳細測試和集成測試用例來講應該是更關注技術細節。
「可執行定義」來扮演需求。
使用領域中的語言（術語？）。
所有人（包括顧客和產品負責人）都應該可以看明白。
不復雜的邏輯
不用 for 循環或者 if/else 判斷結構。
小心給變數賦值。
測試用例不應該看起來像腳本一樣難讀。
最多10步，越少越好。
數據驅動的測試用例
每個測試用例有一個高層次的關鍵詞。
不同的參數創建不同的測試。
關鍵詞通常包含了與同一個用例文件中工作流程測試用例中描述的流程類似的流程。
推薦使用測試模板功能。
不需要多次地去重復關鍵詞。
在一個用例里去測試更容易去測試多種變化。
如果可能，推薦在列頭部命名。
如果真的需要很多測試用例，考慮把他們做成依賴於外部的模型。
用戶定義關鍵詞
應該容易讓人理解
和工作流程測試用例一樣的標准。
不同的抽象層次。
可以包含一些編程邏輯（for 循環，if 判斷這些）
特別對於底層的的關鍵詞。
復雜的邏輯應該放在庫里而不是用戶定義的關鍵詞里。
變數
封裝常的或者復雜的值。
從命令行傳遞信息。
在關鍵詞之間傳遞信息。
變數的命名
清楚，但是不要太長。
可以在變數表格里用注釋來說明。
對每個使用場景保持一致：
小寫的本地變數只在當前的用例或者關鍵詞中可用。
全局變數或者套件，用例級別的變數需要大寫。
空格或者下劃線都可以用來分割變數中的詞。
推薦在變數表格中也把設置成動態的變數也列出來。
用Set Global/Suite/Test variable關鍵詞來命名變數。
變數的初始值應該可以解釋真實的值應該是什麼。
傳遞和返回值
通常的方式是通過關鍵詞來返回值，把他們賦給變數，然後傳遞給其他關鍵詞的參數。
清楚易懂地遵循這個方法。
看起來像是編程。
備選方案是使用Set Test Variable關鍵詞
不需要在測試用例層面上有什麼編程風格。
要遵循起來比較復雜，很難重用關鍵詞。
避免以下這種測試用例層級。
避免使用sleeping
Sleeping 是非常脆弱的。
平均來說，安全的邊界值會使得 Sleeping 很長時間。
用包含了一定的動作觸發的關鍵詞來替代 Sleeping
等待需要有一個超時的值。
關鍵詞可以用 Wait Until… 來開頭
可能的話用內置的關鍵詞 Wait Until Keyword Succeeds來包裝其他關鍵詞。
有時候 Sleeping 是一種最簡單的解決方式
請總是小心使用，不要在經常用到的自定義關鍵詞或者其他關鍵詞中用 Sleeping。
在 Debugging 的時候 Sleeping 用來暫停測試執行還是很有用的。
雖然 DialogsLibrary 通常更適合用來干這個。
⑹ robot framework用自己寫腳本么
需要的
我們使用符合Robot Framework規范的一種表格語法來編寫測試用例。用例一般會是下面這個樣子
這樣的表格存儲到一個文件中，就是一組測試用例。RF支持多種格式，如HTML，TSV,純文本等。它們長相大同小異，其實描述的都是一種內容。為了方便，推薦使用RIDE這個用例的編輯工具來編寫測試用例，這些文本在RIDE環境下被打開長得是一個樣子的。
測試用例與文件的關系
一個文件被稱作一個測試套件(Test suit)，期間可以包含多個測試用例。上圖就是一個測試套件，裡麵包含2個測試用例，My Test 和AnotherTest。
Test suit也能嵌套，比如同一個目錄下的多個Test suit組成一個更高層的Test Suit，這些更高層的Test suit可以組成，這種嵌套的層數可以無限多。這種嵌套的用例組織形式在實際應用中很常見。
測試用例文件的內部結構
一個Test Suit文件包含四段內容他們分別是：Setting，Variable，Testcase，Keyword
Setting部分主要的作用是：
引用測試類庫文件(test Library)，引用資源文件(resource files)，引用變數文件(variable files)。
為測試套件或者測試用例定義元數據(metadata)
Variable部分的主要作用是：
定義測試用例中要使用的變數。
TestCase部分的主要作用是：
使用測試關鍵字來完成測試用例
Keword部分的主要作用是：
把現有關鍵字進行組合，生成更高一級的新關鍵字。
對測試用例文本解析的規則
如同各種編程語言一樣，RF需要對它規定的這種表格語言進行解析，並用內部引擎把這些腳本語言解釋成執行測試用例的具體操作。在解析過程中我們需要如下幾點：
忽略字元：根據格式不同，忽略不符合格式的字元，規則很多，但是可以使用RIDE來規避，使用RIDE我們就可以不考慮這些。
轉義符：RF使用 \ 作為轉義符。舉個例子：\${notvar} 代表字元串 ${notvar} 而不是一個變數
空格：RF會自動截斷頭尾的空格
多行用例
如果參數太多，需要換行，則需要在下一行的關鍵字處使用英文的省略號(...)表示參數屬於同一個關鍵字。
Test Case
Action
Argument
Argument
Argument
Example [Documentation] Documentation for this test case.
... This can get quite long...
[Tags] t-1 t-2 t-3
... t-4 t-5
Do X one two three
... four five six
${var} = Get X 1 2
... 3 4 5
...
從上表中我們可以看到：[Tags]有5個參數，而Do X有6個參數。
⑺ 如何用 Robotframework 來編寫優秀的測試用例
最重要的一條原則就是保證測試用例對於不熟悉這個領域的人來講越簡單越好。
關於這個主題的更多信息，你可以查看以下這些優秀的資源：
Writing Maintainable Automated Acceptance Tests 作者：Dale H. Emery
How to Structure a Scalable And Maintainable Acceptance Test Suite 作者：Andreas Ebbert-Karroum
命名
測試套件的命名
套件的名稱應該盡可能地描述這個套件的用途。
名稱可以相對長一些，但是如果超過40個字那也太長了一些。
記住 Robotframework 的套件名稱是直接從文件/目錄的名字轉換來的。文件的後綴名被去掉了而且下劃線會被轉換成空格，如果你的用到的單詞都是小寫的，那麼開頭字母會被轉換成大寫的。比如 login_test.txt 會被轉換成 Login Tests, DHCP_and_DNS 會被轉換成 DHCP and DNS。
測試用例的命名
測試用例的名字應該與套件的名字描述相似。
如果一個套件里包含了好多個相似的測試用例，而且測試套件本身已經很好地命名了，那麼用例的名稱可以簡短一些。
在測試用例文件中的名稱應該恰好表達了你需要做什麼。
關鍵詞命名
同樣的，關鍵詞的名稱也應該是清晰具體的。
應該可以表達這個關鍵詞幹了什麼，而不是它如何去做。
關鍵詞應該是非常不同的抽象層次（比如，「輸入字元」或者「用戶登錄到系統」）。
生成和分解的命名
試著用名稱來描述這個步驟完成了什麼。
或許你可以用一個已經存在的關鍵詞
如果生成或者分解包含了不相關的步驟，那麼可以接受更抽象一點的名稱。
在名稱中列舉步驟是一個重復化和維護的問題（比如：登入系統，添加用戶，激活警報和檢查平衡）。
或許需要用到一些通用一些的名稱比如「初始化系統」
每個用到這幾個測試用例的人都需要明白這幾個生成或者分解動作是干什麼的。
文檔
測試套件的文檔
通常把文檔添加到包含測試用例的最底層套件中是一個不錯的想法。
高層的套件不需要那麼頻繁地文檔化。
文檔應該包含必要的背景信息，比如為什麼要創建這些測試用例，測試環境中需要注意的點等等。
文檔內容不要只是簡單地重復套件的名稱。
如果不是真的有文檔還不如不添加文檔。
文檔的內容不要包含關於測試用例的太詳細的信息。
測試用例本身就應該足夠清楚易懂了。
重復的信息是一種浪費，而且也不容易維護。
文檔中可以添加一些詳細內容的鏈接。
如果你需要在文檔中添加一些比如（版本：1.0 或者 OS：Linux）這樣的「名稱-值」組的話，可以考慮使用測試套件 metadata
測試用例的文檔
測試用例通常來說不需要文檔。
套件名稱和文檔以及用例的名稱已經提供了足夠的背景信息。
測試用例的結構應該是不需要文檔或者其他注釋都足夠清楚了的。
Tag 通常比文檔更靈活，還能提供更多的功能。
當測試用例的文檔是有用的時候，也不要擔心而不去添加喲。
用戶自定義關鍵詞文檔
如果這個關鍵詞非常簡單明了的話，不需要文檔。
好的名稱和明確的結構就足以說明一切了。
用戶自定義關鍵詞文檔的一個重要的用途是用來記錄參數和返回值的信息。
在 RIDE(比如在關鍵詞補全的地方)以及在資源文件中顯示的文檔是由 libdoc.py 生成的。
測試套件的結構
在套件中的用例應該是互相相關的。
如果測試用例擁有同樣的生成或者分解部分，那麼他們應該是屬於一個套件的。
除非是數據驅動的，在一個套件中不要放10個以上的測試用例。
測試用例應該是獨立的。
用生成和分解來初始化他們。
有時候如果測試用例之間無法避免地相關聯
比如說，它可能是因為把所有的用例獨立出來要化太多的時間在初始化上。
相關聯的測試用例就那麼幾個（最多4到5個）
下一個用例是用來驗證上一個用例的結果的。（用${PREV TEST STATUS} 這個變數）
測試用例的結構
測試用例應該是易懂的。
一個測試用例只測試一件事情。
當然，事情本身可大可小。
選擇一個合適的抽象層面。
一致地使用抽象水平（單一水平的抽象原則）
只包含與測試相關的信息。
用例可以分為兩種
工作流程的測試用例
數據驅動的測試用例
工作流程的測試用例
通常來說有以下這些部分：
前置條件（可選，通常在生成部分）
動作 （對被測系統執行一些動作）
驗證 （必須有一個驗證的部分！）
清理 （可選，通常在分解部分，以保證用例已經執行完畢）
關鍵詞是用來描述這個用例做了什麼。
用清晰的關鍵詞名稱和合適的抽象層次。
應該包含足夠的信息使得手動執行可以啟動。
應該從來不需要文檔或者溝通來告訴你這個用例在做什麼。
不同的用例可以有不同的抽象層次。
詳細的功能測試是更精確的。
端到端的測試可以是一個很高的抽象層次。
一個測試用例應該只使用一種抽象層次。
不同的風格
對於底層的詳細測試和集成測試用例來講應該是更關注技術細節。
「可執行定義」來扮演需求。
使用領域中的語言（術語？）。
所有人（包括顧客和產品負責人）都應該可以看明白。
不復雜的邏輯
不用 for 循環或者 if/else 判斷結構。
小心給變數賦值。
測試用例不應該看起來像腳本一樣難讀。
最多10步，越少越好。
數據驅動的測試用例
每個測試用例有一個高層次的關鍵詞。
不同的參數創建不同的測試。
關鍵詞通常包含了與同一個用例文件中工作流程測試用例中描述的流程類似的流程。
推薦使用測試模板功能。
不需要多次地去重復關鍵詞。
在一個用例里去測試更容易去測試多種變化。
如果可能，推薦在列頭部命名。
如果真的需要很多測試用例，考慮把他們做成依賴於外部的模型。
用戶定義關鍵詞
應該容易讓人理解
和工作流程測試用例一樣的標准。
不同的抽象層次。
可以包含一些編程邏輯（for 循環，if 判斷這些）
特別對於底層的的關鍵詞。
復雜的邏輯應該放在庫里而不是用戶定義的關鍵詞里。
變數
封裝常的或者復雜的值。
從命令行傳遞信息。
在關鍵詞之間傳遞信息。
變數的命名
清楚，但是不要太長。
可以在變數表格里用注釋來說明。
對每個使用場景保持一致：
小寫的本地變數只在當前的用例或者關鍵詞中可用。
全局變數或者套件，用例級別的變數需要大寫。
空格或者下劃線都可以用來分割變數中的詞。
推薦在變數表格中也把設置成動態的變數也列出來。
用Set Global/Suite/Test variable關鍵詞來命名變數。
變數的初始值應該可以解釋真實的值應該是什麼。
傳遞和返回值
通常的方式是通過關鍵詞來返回值，把他們賦給變數，然後傳遞給其他關鍵詞的參數。
清楚易懂地遵循這個方法。
看起來像是編程。
備選方案是使用Set Test Variable關鍵詞
不需要在測試用例層面上有什麼編程風格。
要遵循起來比較復雜，很難重用關鍵詞。
避免以下這種測試用例層級。
避免使用sleeping
Sleeping 是非常脆弱的。
平均來說，安全的邊界值會使得 Sleeping 很長時間。
用包含了一定的動作觸發的關鍵詞來替代 Sleeping
等待需要有一個超時的值。
關鍵詞可以用 Wait Until… 來開頭
可能的話用內置的關鍵詞Wait Until Keyword Succeeds來包裝其他關鍵詞。
有時候 Sleeping 是一種最簡單的解決方式
請總是小心使用，不要在經常用到的自定義關鍵詞或者其他關鍵詞中用 Sleeping。
在 Debugging 的時候 Sleeping 用來暫停測試執行還是很有用的。
雖然 DialogsLibrary 通常更適合用來干這個。