【架構研習】欲善其事先利其器-Robot Framework實戰演練之框架的選擇

（原創文章，轉載請註明出處。）

    以前有提到過，本身曾基於公司業務系統從無到有碼過一套測試框架，但因爲開發時的思想同時受限於公司業務及框架的適用性上，致使最終雖然框架可完美支持業務，但在易用性、兼容性及可擴展性方面依然存在必定問題，維護成本較高。後有幸結識RF，甚爲喜歡。

爲何呢?

    這就要從框架自己提及。關於對測試框架的認識，其實可大可小，各人理解不一。好比說如Junit等xxUnit系列，能夠說是單元測試的框架，以白盒的方式調函數，調模塊，加setup、加assert，覆蓋代碼段的功能，能夠在代碼層面作任何測試，但不太會用它作接口的聯調或業務的串聯測試。如TestNG+xxx等，偏向於用例及流程的控制，TestNG自己並不調用業務邏輯。相對全一點的，早期如Rational系列，從CQ到TM再到Rational Robot，覆蓋從需求到測試再到測試管理，但實在是過重。後期如你們最熟知的QC+QTP／LR，全開發流程串聯，功能強大，但一樣的問題，一是略重，二是要用你的業務系統去適應QTP，固然用的好的話能夠直接本身寫測試agent做爲第三方測試工具連QC，但除了調用接口要跟QC完美契合外，Report也用適應QC自己的報表，須要人力成本。再者QC的二次開發難度較大（ps:有須要的能夠找我），需大量時間作研究實踐。

    那咱們來談談RF在框架或平臺各個層級的特色。這裏結合通常開展自動化工做的人和事來講。

1、測試開發階段：

    咱們一點點展開說。測試開發，指的是測試腳本的開發工做。能夠用純語言寫，如Java、Py等，用VB6寫個鏈接程序也能放QC上跑。也能夠用工具，採用半寫半錄的方式，直接用QTP或Rational Robot去跑。但無論用任種方式，咱們都會須要或者說在逐步演進的過程當中都會意識到須要如下幾點內容：1、要有一個便於開發者使用的IDE。RF的IDE，有RIDE或者PyCharm的插件，界面幾戶無異，均比較容易上手。2、須要有核心庫或者公共庫的概念。比如本身寫代碼會寫Lib，用QTP會寫vbs核心庫等。RF中有Library和Resource的概念，既可引用開源庫，也能夠封裝核心的業務動做。通常一個自動化團隊會有1-2名成員去維護核心庫代碼，負責控制代碼的check in。其餘若干人員負責腳本的設計或業務流的串聯。一旦造成，任何接口的變更或更新，只須要更新核心庫的代碼便可，無須逐個更新腳本。3、數據驅動、關鍵字驅動、數據代碼分離。KWD是很早就有的概念，大多數商用工具裏都支持數據的剝離，RF一樣能夠實現。雖然RF一樣支持諸如同一個用例跑一個數據文件，逐一跑文件中包含的三組不一樣的數據，但如何把這樣的模式應用到測試場景中，如何經過好的佈局將關鍵字驅動及數據驅動相結合，並將各個獨立的驗證點加入進去纔是須要不斷思考和優化的地方。4、快速對接待測業務接口或識別界面元素。比如Jmeter內置了http協議，因此你們習慣用它作頁面壓力測試。RF能夠快速pip相關的Library，能夠兼容各種接口，幾乎涵蓋各種協議及先後臺。另外Lib裏還附帶了各種操做，甚至直接調用python語句，很是方便。  5、快速造成業務邏輯測試腳本。當代碼實現了各類接口調用、界面元素調用，並參數化和抽象後，須要思考自動化腳本開發人員如何快速的將之整合造成業務邏輯。RF能夠經過簡單的拖拽造成業務邏輯。但以前說的腳本開發人員不是一我的，而是不少人，因此在應用工具的同時還必須創建規範。設計完善加之管理適當的話，以上提到的腳本設計人員其實不須要過多的接觸代碼，只須要編排關鍵字，而後改改數據就能夠造成可用的業務邏輯了。6、代碼、數據版本管理。因爲RF腳本自己是txt的，因此能夠利用Git或SVN作版本控制。IDE自己也包含相關插件。

2、測試執行（運維）階段：

    測試腳本完成業務串聯並調試經過後，會打上版本標籤，並從開發庫轉移到執行庫，就此正式開始測試執行工做。咱們的討論會就測試執行定義一些分類，以便展開說。

    測試執行就階段分能夠分爲執行階段和分析階段。

    執行階段就是咱們一般說的跑。跑的方式有不少種，能夠分爲半自動化和全自動化。前者是我有一個自動化測試執行團隊，每人負責幾臺測試機，人爲的手動取代碼更新到運行庫，而後根據這次運行要求，是full仍是sanity，框一個範圍，每人分幾臺機器去跑。後者是我有一個自動化測試平臺，在平臺上勾選我要的範圍，平臺自動allocate機器並assign用例，運行過程當中還會作load balance。對於第一種方式，RF的RIDE自己就能夠建多層次的文件夾及測試集，能夠構建出業務模塊，在任何一臺測試機上都可以git到代碼並點選相關模塊去運行。對於第二種方式，剛接觸RF，暫時尚未看到現成的開源代碼，但仍是能夠經過用remoting調用agent的方式並作簡單的控制實現，但這還都是老套路。若是能實現第二種模式，那恭喜你，你基本已經實現了自動化測試從腳本化到框架化再到平臺化的演進了，不考慮實際效能的話，已經能夠說是圓滿了，但若是要走出最後一步產品化，要有不少額外的事要作，這裏暫時就不細說了。腳本觸發的方式也有不少種，能夠分爲手動和自動。利用RF自帶的pybot，能夠經過命令行直接調用項目層級、測試集層級，能夠輕易的植入Jenkins做爲冒煙測試。

    分析階段實際上是最花時間的。爲了提升效率，須要考慮如下幾點。首先須要有詳盡的Log，而且Log level是可調的。RF包含了None、Debug、Trace等多個層級。Trace層級，能夠看到全部變量的值，並追溯到具體的報錯內容，十分詳盡。其次是清晰的測試報告。RF的測試報告也是分層級的，能夠經過一層層點擊定位問題，比較方便。而且能夠經過簡單的設置，保存每次運行的結果，便於往後查驗。但即便如上述種種，跟業務相關的排錯仍是須要有經驗的人去作，快速定位問題。

    因而可知，RF符合快速搭建自動化測試框架（平臺）的基本要求，也便於咱們快速的開展工做。