Robot Framework在軟件接口自動化測試中的研究與應用

趙明明，周靜，補沖

（1 咪咕互動娛樂有限公司，南京 210041；2 咪咕音樂有限公司，成都 610000）

在早期的軟件開發(fā)過程中，測試常常由開發(fā)人員自行完成，大家對測試的關注度和重要性認識都不夠全面。直到1972年，美國北卡羅來納大學召開了首屆軟件測試技術會議之后，軟件測試才作為軟件工程中的一個重要分支開始逐步發(fā)展。1983年，Bill Hetzel在其著作中對軟件測試做了定義：“測試是以評價一個程序或者系統(tǒng)屬性為目標的任何一種活動”。隨著軟件系統(tǒng)越來越復雜，軟件工程師們普遍意識到，必須要借助工具才能對系統(tǒng)進行快速而充分的測試，同時，伴隨著國外很多機構和學者投入大量的研究工作，測試工具開始逐漸受到人們的重視。

軟件自動化測試的主要原理是針對測試人員對于手工測試所進行的設計，通過一定的技術方法進行自動化測試程序編寫以及運行來達到模擬普通測試人員對軟件系統(tǒng)的操作過程，并且對結果進行檢。常見的自動化測試方法包括腳本錄制回放、數(shù)據(jù)驅動、關鍵字驅動。

1 自動化測試工具分類

常見的自動化測試工具包括QTP、RFT、Selenium、Watir、Phoenix Framework、Robot Framework（ 以下簡稱RF）等。自動化測試工具從功能實現(xiàn)上可以分為兩類：一類是提供了可重用的基礎自動化測試能力，如Selenium、Watir等，它們可以進行基礎的自動化測試，比如打開一個程序，模擬鼠標點擊被測對象，最后驗證被測對象的屬性以判斷程序的正確性。另外一類是提供了自動化測試執(zhí)行和管理的能力，如Phoenix Framework、Robot Framework等，它們本身不具備基礎的自動化測試能力，只是用于組織、管理和執(zhí)行那些獨立的自動化測試用例，測試完成后統(tǒng)計測試結果，這類工具往往可以集成多個提供基礎自動化測試能力的工具，以滿足不同類型的自動化需求，使用較靈活，可擴展性也更強。

Robot Framework最初是由Nokia Networks公司開發(fā)的一個開源自動化測試框架，框架基于Python語言實現(xiàn)，包含豐富的測試工具及測試庫，同時具有很強的擴展性。RF框架通過集成不同的測試工具，可以進行各種自動化測試，如Web自動化測試、Http接口自動化測試、移動App的自動化測試等。

2 軟件接口自動化測試的重要性

分層的自動化測試倡導在產品的不同階段（層次）都需要開展自動化測試，并且不同階段的投入比重有所不同。如Google的產品，70%的自動化投入為單元測試，20%為接口測試，10%為UI層的自動化測試。因為越往上層，開展自動化測試的成本越高，相反，越是底層的自動化，收益卻越高。

不同階段的測試關注點不同，UI層關注的是頁面展示邏輯及頁面前端與服務端的集成驗證，而服務層的接口測試更關注系統(tǒng)整體業(yè)務邏輯實現(xiàn)的驗證，相對于UI層自動化，服務層的接口測試自動化更加穩(wěn)定，測試用例也更容易維護。因此，項目在開展自動化測試過程中，接口自動化測試投入更多的人力，是重要而明智的。

3 RF在軟件接口自動化測試中的應用

3.1 自動化工程結構及測試詞庫的封裝

RIDE是Robot Framework提供的自動化腳本管理工具，通過RIDE可以創(chuàng)建或導入自動化工程、創(chuàng)建資源文件、創(chuàng)建測試套、編輯調試自動化腳本、查看腳本執(zhí)行日志等。如圖1左側展示的AutoTestProject是我們某個項目的自動化工程，工程根目錄下的TestCases、Keywords和Resources目錄分別用于存放測試套、測試詞庫資源文件、變量類資源文件。按照被測系統(tǒng)的特性，測試人員可以在TestCases目錄下新建多個子目錄，分別存放不同特性對應的測試套。

根據(jù)不同的自動化需求，測試人員在Keywords目錄下分別創(chuàng)建資源文件，用于保存不同類型的上層關鍵字，這類資源文件我們稱為詞庫，如Http請求詞庫、Redis操作詞庫、Kafka操作詞庫、數(shù)據(jù)庫操作詞庫等，如圖1所示。每個詞庫分別引用相關的開源擴展庫或自定義庫，獨立管理和維護。詞庫中的關鍵字由多個內置庫或擴展庫或自定義庫中的底層關鍵字組合而成，如圖1右側展示的是數(shù)據(jù)庫操作詞庫中數(shù)據(jù)庫校驗關鍵字的構成，這類滿足RF語法由底層關鍵字組合而成的關鍵字我們稱為上層關鍵字。在項目自動化實施過程中，底層自定義關鍵字的開發(fā)和上層關鍵字的封裝，都由具備一定代碼基礎的測試開發(fā)人員完成，普通的測試人員只需要了解上層關鍵字的用法，即可完成自動化腳本的寫作。

3.2 數(shù)據(jù)驅動的自動化腳本實現(xiàn)

圖1 自動化工程結構及測試詞庫關鍵字的構成

開展接口自動化測試的過程中，一個接口往往定義一個測試套（由一組自動化腳本構成），測試套下包含該接口所有的自動化腳本。由于接口的測試報文結構基本是固定的，不同的腳本往往只是修改報文中某個或某幾個參數(shù)的值，如果在每個腳本中都帶上測試報文，就會造成數(shù)據(jù)冗余、維護成本高的問題，尤其在報文結構復雜，腳本數(shù)量多的情況下格外突出。為此，我們的自動化腳本在實現(xiàn)上使用數(shù)據(jù)驅動的模式，將腳本與測試報文分離。首先，在測試套同級目錄下保存一個.conf后綴的文本文件，文件中保存一條完整的測試報文，自動化腳本先從該文件中讀取報文，再根據(jù)需要修改報文中某個或某幾個字段的值，然后將請求發(fā)送給被測系統(tǒng)并進行結果校驗。圖2左側展示的是一個腳本示例，其中${Req_Data_File}變量指向了.conf后綴的文件，我們建議將其定義為測試套變量，變量值使用RF的內置變量，例如${CURDIR}${/}訂單查詢接口.conf，可以自動適配Windows和Linux操作系統(tǒng)。

3.3 接口參數(shù)校驗場景的自動化腳本實現(xiàn)

接口測試存在很多參數(shù)校驗的場景，例如字段為空、字段超長、字段取值錯誤等，這類腳本往往占據(jù)全部自動化腳本的50%以上。而參數(shù)校驗類的測試用例或自動化腳本步驟基本一致，唯一的區(qū)別就是響應結果中錯誤碼和錯誤提示的差異，鑒于此，我們對參數(shù)校驗類的測試用例和自動化腳本的寫作方法進行了優(yōu)化。

測試用例的設計階段，針對某個接口各種參數(shù)校驗的場景，整合為一個測試用例。針對該測試用例，在測試套同級目錄下新增.error后綴的文本文件。有多少個參數(shù)校驗場景，該文件就包含多少行，每行的第一列表示要校驗的場景，如appId為空、appId取值錯誤、報文缺少appId等，如涉及多個參數(shù)的校驗，使用英文逗號隔開，校驗參數(shù)使用JsonPath語法描述，例如$.appId：100001，$.userId：20001，從第二列開始表示該場景下要校驗的內容，例如錯誤碼、錯誤提示等，多列之間使用tab鍵分隔。

自動化腳本寫作階段，首先從.conf后綴的文件中獲取一條測試報文，然后循環(huán)從.error文件中獲取要校驗的場景，解析后替換到報文中，并發(fā)送請求到被測系統(tǒng)，最后進行錯誤碼、錯誤提示等的校驗。經過關鍵字封裝，最終的自動化腳本僅包含圖2右側展示的兩個步驟。從項目實施經驗看，經過以上優(yōu)化，接口自動化腳本的數(shù)量可以減少50%以上，不僅提升了腳本寫作效率，也降低了測試人員后期維護自動化腳本的工作量。

3.4 自動化腳本與測試環(huán)境的解耦

產品迭代開發(fā)過程中，可能會有多套被測環(huán)境，如果自動化腳本不進行相關約束，那么切換被測環(huán)境必然會導致大量的腳本執(zhí)行失敗，此時又需要投入測試人力修改腳本，這個問題經常會影響到項目自動化測試開展的及時性。為此，我們采用以下方法，解決了切換被測環(huán)境引起的腳本修改問題。

在項目自動化腳本寫作過程中，和被測環(huán)境相關的信息，必須全部定義為變量，存放在資源文件中，自動化腳本引用資源文件中定義的變量，不能直接使用被測環(huán)境的信息。如針對服務端URL地址，我們會定義變量 ${G_URL}=http：//10.138.10.10：8080， 自 動 化腳本發(fā)送請求關鍵字的參數(shù)必須使用${G_URL}變量，不能寫死http：//10.138.10.10：8080。由于可能存在多套被測環(huán)境，因此，我們在Resources目錄下新建多個資源文件，如Test_Env_Alpha.robot、Test_Env_Beta.robot、Test_Env_Gamma.robot，分別代表不同的測試環(huán)境，如圖1所示，這些文件中存放自動化腳本中引用的與被測環(huán)境相關的變量，其中變量名完全一致，區(qū)別在于變量值不同。最后我們新增資源文件Test_Env_Cur.robot，該文件引用當前生效的被測環(huán)境資源文件，如Test_Env_Alpha.robot，所有的測試套都引用Test_Env_Cur.robot，經過以上處理，如果需要切換測試環(huán)境，僅需要修改Test_Env_Cur.robot文件中引用的資源文件名即可，自動化腳本不需要做任何修改，實現(xiàn)了自動化腳本與測試環(huán)境的解耦。

圖2 數(shù)據(jù)驅動的自動化腳本實現(xiàn)及接口參數(shù)校驗腳本實現(xiàn)

3.5 測試用例與自動化腳本的互相轉換

很多公司都有自己的測試用例管理系統(tǒng)，支持Excel文檔的導入導出。產品迭代開發(fā)過程中，測試人員往往都是根據(jù)需求先梳理Excel格式的測試用例，然后導入用例管理系統(tǒng)，最后根據(jù)測試用例描述，完成自動化腳本的寫作。

為了提升自動化腳本的寫作效率，我們對RIDE工具做了定制開發(fā)，支持將Excel格式的測試用例與自動化腳本互相轉換。如圖3所示，Tools菜單下新增了Convert Excel To Test Suite功能，單擊后選擇某個測試用例Excel文檔，工具會按照Excel文檔的目錄結構自動生成同樣目錄結構的測試套文件，并將測試用例名稱、編號、測試步驟等信息寫入自動化腳本的Documentation部分，測試人員只需要添加腳本步驟即可完成自動化腳本的寫作，省去了很多從測試用例文檔到測試套的復制粘貼工作。

相反的，只要測試人員按照規(guī)范要求，在自動化腳本的Documentation中寫入用例名稱、編號、測試步驟等信息，右鍵自動化工程的TestCases目錄或其子目錄，然后選擇Convert to Test Case，就可以將選中目錄下的測試套轉換為Excel格式的測試用例文檔，如圖3所示，轉換生成的文檔可直接導入測試用例管理系統(tǒng)。

測試用例轉換為測試套的功能，一定程度上提升了自動化腳本的寫作效率；測試套轉換為測試用例的功能，用于自動化腳本先于測試用例之前完成，可以由自動化腳本轉換生成一份測試用例，方便后續(xù)測試用例的管理和維護。

3.6 自動化腳本規(guī)范問題靜態(tài)檢查

為了提升RF自動化腳本的質量，我們會要求測試人員按照規(guī)范寫作自動化腳本，但是，由于人員能力參差不齊，對規(guī)范的掌握程度也不盡相同，所以測試人員輸出的自動化腳本往往需要經過多次評審和優(yōu)化才能達到要求。為了提早發(fā)現(xiàn)腳本規(guī)范問題、提升腳本評審的效率，我們將一些常見的腳本問題歸類，開發(fā)了相應的規(guī)范檢查工具，用于自動識別腳本中存在的問題。測試人員在提交腳本前，先主動執(zhí)行靜態(tài)檢查，就可以提前識別出一些不符合規(guī)范的問題并加以修改。

圖3 測試用例與自動化腳本的互相轉換

圖4 自動化腳本靜態(tài)檢查工具及報告

檢查規(guī)則分為強制和建議兩種，目前實現(xiàn)的如圖4所示的8條，其中每條檢查規(guī)則都對應一條腳本寫作規(guī)范。如我們的規(guī)范要求自動化腳本不能使用Sleep關鍵字進行強制等待（除非有特殊的業(yè)務要求），規(guī)則2會掃描所有的測試套文件，識別出使用了Sleep關鍵字的腳本步驟；規(guī)范要求自動化腳本必須包含結果校驗，規(guī)則4會掃描所有的測試套文件，識別出缺少結果校驗步驟的自動化腳本。最后，檢查工具會按照規(guī)則輸出問題統(tǒng)計報告，并給出詳細的問題位置及文件路徑。從項目實施經驗看，檢查工具使用前期會發(fā)現(xiàn)很多問題，如圖4是我們一個項目第一次掃描的結果，上千個同類問題，如果依賴人工評審，需要耗費的時間難以估量，隨著腳本的不斷優(yōu)化及測試人員對規(guī)范的掌握，相關問題會越來越少。這些檢查規(guī)則的自動化可以有效牽引測試人員提升自動化腳本的質量，我們也在積極擴展實現(xiàn)其它的檢查規(guī)則，進而不斷提升團隊的測試效率。

4 結束語

Robot Framework是一個開源的自動化測試框架，基于關鍵字驅動，使用靈活，可擴展性良好。經過我們的優(yōu)化，該框架既具備關鍵字驅動的靈活性和可重用性，又具備數(shù)據(jù)驅動框架的低耦合，很大程度的降低了開展自動化測試的成本投入。從真實的項目實施情況看，接口自動化覆蓋率可以達到100%，在小步快跑、快速迭代的大趨勢下，可以有效縮短回歸測試時長，提升自動化測試的價值，本文所闡述的方法很值得在相關軟件測試領域推廣使用。