Robot Framework自動化測試框架核心指南-如何做好自動化測試平臺框架的設計

張永清發表於2020-09-06

自動化測試如果需要能高效快速的支撐軟體專案的測試，專案的快速迭代以及上線，除了以上我們介紹的需要許多的Lib來支援以及需要高效的去編寫自動化測試案例外，還需要一個好的自動化測試框架平臺來支撐我們的自動化測試案例的執行以及分析，自動化測試平臺一般需要解決測試案例執行任務的建立，任務的管理，任務的排程，測試案例的解析，測試案例分別根據不同的測試型別分發給不同的測試工具或者測試Lib庫進行執行，並且需要對執行的資料進行分析，得出質量資料，然後才好給出對應的測試報告分析資料給測試經理，專案經理來輔助持續的改善專案版本的質量，下圖是一個自動化測試平臺框架的架構設計圖。

本文作者：張永清，轉載請註明出處：https://www.cnblogs.com/laoqing/p/13622088.html 節選自《Robot Framework 自動化測試框架核心指南》

框架圖中的自動化測試平臺框架主要包含了4個部分，自動化測試案例編寫的IDE工具，自動化測試案例的執行，測試任務的管理和監控，測試案例執行後的資料分析。

一個通用的自動化測試案例編寫的IDE工具一般需要包含的功能如下圖所示。

本文作者：張永清，轉載請註明出處：https://www.cnblogs.com/laoqing/p/13622088.html 節選自《Robot Framework 自動化測試框架核心指南》

友好的使用者案例編寫介面，通常一般可以表格或者表單的形式，比如RobotFramework，就是典型的表格介面，也可以用Eclipse的外掛式開發實現這一需求。

在平臺中，一個自動化測試案例的執行一般包括如下圖中的基本步驟，最核心的就是將解析的案例資料分發出去給不同的Lib庫去執行。

本文作者：張永清，轉載請註明出處：https://www.cnblogs.com/laoqing/p/13622088.html 節選自《Robot Framework 自動化測試框架核心指南》

在做資料分析時，可以借用很多現在主流的大資料元件，如下圖所示，資料分析通常包括實時資料分析和離線資料分析，分析中我們還會用到很多訊息佇列中介軟體，比如kafka，資料明細可以採用elasticsearch來進行儲存，這和elasticsearch本身的特點有關係，可以支援大資料的儲存以及方便以後我們來做全文檢索。

平臺框架圖中包含的元件如下表所示。

IDE	RIDE,eclipse外掛，idea外掛
測試案例版本伺服器	svn，git等版本控制伺服器
自動化測試案例資料	自動測試案例檔案
案例解析器	負責自動化測試案例檔案資料的讀取和解析，翻譯成自動化測試工具或者自動化測試Lib庫可以執行的命令
資源監控和資源管理	負責各個執行器，案例解析器以及自動化工具伺服器的資源監控和資源管理
任務排程器	排程自動化測試執行任務在多個節點上的執行
自動化工作管理員	接受自動化任務的提交，自動化任務的管理（任務啟用，任務停用，任務新增，修改，刪除等）
告警	任務執行異常，超時等，自動產生告警
簡訊平臺	告警簡訊傳送，簡訊接收
郵件伺服器	接收生成的測試報告或者告警簡訊，然後郵件傳送給對應的相關人員
Kafka	執行日誌資料的快取儲存
Elasticsearch	測試案例執行的日誌明細資料儲存
Kibana	是一個開源的分析和視覺化平臺，旨在與 Elasticsearch 進行結合。Kibana 提供了搜尋、檢視和與儲存在 Elasticsearch 索引中的資料進行互動的功能。開發者或運維人員可以輕鬆地執行高階資料分析，並在各種圖表、表格和地圖中視覺化資料。
離線分析	負責對日誌定時做離線分析處理，比如通過hive等大資料方式進行資料歸類分析
實時分析	將日誌資料，通過大資料實時資料流的分析，提取案例執行過程的相關日誌資料做實時的分析和統計,常用的實時流分析工具有spark，storm，flink等。

下圖是自動化平臺框架設計的一個分層結構圖。

我們對常見的自動化測試架構思想做了一個如下的對比，如下表所示。

資料驅動測試	資料驅動測試的的思想是將我們的自動化測試指令碼和測試資料放在共同的測試架構中，思想是提供可重用的測試邏輯，這樣來做的目的是減少測試維護的工作量以及便於改善測試案例的覆蓋率，測試案例需要輸入的測試資料和測試完成後的測試結果資料都會被儲存同一個資料庫或者資料來源中，並且將測試的資料和測試邏輯分開，這樣測試資料放生了變化時，不會影響到我們的測試邏輯。並且使得同一套測試邏輯可以針對多種資料來進行測試，儘量來提高測試邏輯的使用效率和複用效率。
模組驅動測試	模組驅動測試的思想是使用獨立的指令碼或者程式碼來對應每一個待測試的模組單元和功能，模組驅動測試引入的是程式語言中的物件導向程式設計中的抽象和模組獨立封裝的思想，即將測試程式碼和每一個測試模組進行解耦，這樣可以減低自動化測試指令碼或者自動化測試程式碼的維護成本，同時也增強了可擴充套件性，測試的執行者不需要知道單元模組的內部實現，只需要呼叫單元模組的對外提供的抽象介面方法即可，單元模組的功能需求發生變化時，只需要修改該單元模組的內部實現，對外的提供的抽象介面方法依然可以做到不發生變化。
關鍵字驅動測試	RobotFramework就是一種典型的關鍵字驅動測試的框架模式，關鍵字驅動測試通常也被認為是表格驅動測試，通過在表格中呼叫關鍵字來實現自動化測試，這種設計思想一般會將自動化測試拆分為設計和實現兩個不同的階段，RedWoodHQ自動化測試工具框架也是這種思想來實現，設計時需要儘量考慮關鍵字的通俗易懂以及通用性，也就是可以在不同的測試案例或者場景中可以高效的複用。關鍵字驅動測試的優點就在於自動化測試案例的編寫者不需要對指令碼語言有非常深入的瞭解就可以完成自動化測試案例的編寫。
混合自動化測試	混合自動化測試是上面幾種自動化測試思想的綜合使用，關鍵字驅動測試和模組驅動測試這兩種在很多情況下就可以完美的結合起來使用，比如我們可以使用RobotFramework提供的自定義使用者關鍵字來對單元模組業務進行封裝，封裝完成後，再提供一個新的使用者自定義關鍵字出來，新的使用者自定義關鍵字就可以認為是一個抽象的介面。
基於模型測試	基於模型測試的思想一般用的較少，一般只能適合於特定的也是基於這種模型設計思想的系統，通常的情況下，這一測試模型是全部或者部分從待測試的軟體系統的功能模型中提取出來的。在測試模型中描述了待測試系統的抽象行為，因此從測試模型中也可以派生出功能測試案例。
行為驅動開發	行為驅動開發是一種敏捷開發的思想，Behavior Driven Development使用簡單的，特定於領域的指令碼語言(DSL)將結構化自然語言語句轉換為通俗易懂的可執行測試，行為驅動開發的根基是一種“通用語言”，該語言通俗易懂，這種通用語言同時被客戶和開發者用來定義系統的行為，Cucumber 就是一種行為驅動開發的自動化測試工具。