淺談自動化測試框架設計

筆者結合實際項目經驗以及學習其餘前輩經驗，總結分享一下自動化測試框架設計的思想

• 自動化測試通常有數據驅動和關鍵字驅動兩種模式，這裏將兩種思想結合起來，即有關鍵字驅動也有數據驅動。從架構層面設計，採用開發經常使用MVC框架思想，分爲邏輯控制層（Controller）、持久層（Model）、展現層（View）。以下圖所示，以Java語言爲例，每層應用到的技術：

　　邏輯控制層：Selenium適用於Web自動化，真實模擬用戶操做瀏覽器；HttpClient應用於接口自動化；TestNG是一個目前很流行實用的單元測試框架，有完善的用例管理模塊，配合Maven可以很方便管理依賴第三方插件，事半功倍。若是適用python，也是有相似的開源庫可供選擇，如python+selenium+request+unittest。

　　持久層：這一層注意用例測試數據的管理，不少是適用excel表格的形式去管理測試數據，這裏也不是說很差，畢竟也是通過市場的考驗。例外介紹一個筆者以爲更加優秀的思路，採用MyBatis+MySQL的方式管理數據，可能不少測試人員開發經驗不足，不太熟悉MyBatis框架，這裏有必要能夠學一學。整體的思想就是首先作好測試分析，根據業務設計好測試數據庫表結構，而後將測試數據保存在MySQL數據庫，實現測試數據和指望結果數據的線上管理，這裏只須要在MyBatis框架下面寫好對應的SQL語句便可實現數據驅動的自動化測試。筆者對python的第三方庫不是很熟悉，想必python應該也有相似的管理MySQL的庫。

　　展現層：主要是測試報告的展現，採用ExtentReport框架實現測試報告的展現，該框架的測試報告效果目前來看是比較好的。

• 邏輯業務層的具體實現來看，主要分基礎框架類、封裝工具類、封裝業務類和自動化腳本。如圖所示：

 

　　基礎框架類：這裏能夠直接使用maven引入便可，管理起來很方便。

　　封裝工具類：這個類主要包括鏈接數據庫、讀取配置文件、讀取excel文件等基本工具類，還包括對selenium、HttpClient等框架進行二次封裝的類，可能有人會說，這是多餘的，爲何要作這個封裝，作這個主要是爲了解耦業務類與框架。若是某天發現這個框架有點缺陷，業務類很差使，當咱們更新框架可能會須要大量修改封裝的業務類，維護工做量巨大，若是有這一層，那咱們只須要修改二次封裝類的具體實現就能夠了，對業務類提供的API不變，這樣維護工做量小不少。

　　封裝業務類：這一層採用關鍵字驅動的自動化測試思想，根據被測對象的特性，設計不少個不一樣的業務類，好比登陸操做，若是不少個登陸的入口，就寫一個登陸基類，不一樣入口繼承基類分別實現子類。若是是接口自動化，這個設計起來就比較簡單了，有多少個接口就設計多少個業務類，這些類咱們稱之爲AW（Action Word），是爲了自動化測試腳本測試不一樣場景直接引用方法，組合AW，造成一條條測試用例。這樣，咱們測試人員即便代碼能力通常，也能依葫蘆畫瓢，組合各個AW寫自動化測試用例。若是公司資金人力容許，還能夠針對開發一個桌面工具或者網站，實現表格式開發測試用例，這樣的話，即便不懂代碼的測試人員，也能根據業務邏輯本身在桌面工具或者頁面組合AW，造成測試用例，程序自動組裝TestNG測試用例。筆者用到過的相似這種框架就有Robot Framework，一個很是優秀的開源python自動化測試框架。

　　自動化腳本：直接組合業務類寫好的AW。針對這一層須要測試人員懂一點點Java代碼就能夠勝任這個工做，若是想要小白都能寫，須要針對開發一個桌面工具或者網站，實現表格式開發測試用例，前面已經講到再也不贅述。

• 最後說一說測試執行，目前用的比較多的就是Jenkins，持續集成；將咱們寫好的測試用例使用git倉庫管理，事先在Jenkins建立好任務，發佈新版本以後，直接運行任務，自動部署版本包，下載自動化測試用例並執行，生成報告，這樣的一條流水線，在當今敏捷開發模式下效率是很高的。