建立測試自動化框架以指導測試人員建立和設計測試用例。在本文中，咱們重點介紹了最經常使用的框架。瞭解每種框架的優缺點，以幫助您的團隊更好地肯定最適合您的測試的框架。
什麼是測試自動化框架?
自動化測試框架就是用於測試自動化的框架。具體來講，它提供了自動化測試用例編寫、自動化測試用例執行、自動化測試報告生成等基礎功能。咱們只須要基於這個框架，完成和業務高度相關的測試用例設計和實現便可。另外，框架會爲咱們處理好複雜度與擴展性的問題，咱們無需爲此操心。
測試自動化框架是在建立和設計測試用例時使用的一組最佳實踐或準則。測試準則集能夠包括編碼標準，對象存儲庫，測試數據處理方法，有關外部存儲訪問的信息等。
這些準則並不是強制，可是在自動化腳本過程當中，它們提升了測試的效率併產生了有益的結果。
使用測試自動化框架的好處
根據需求使用適配的自動化測試框架有助於加快測試過程，並消除人爲錯誤。它還使測試維護更加容易，加快測試進度，節省成本、時間和精力。此外，框架QA團隊可以充分開發、執行和報告測試過程，同時還使代碼可在多種狀況下重用。
5種最流行的自動化測試框架類型
團隊根據團隊規模、經驗水平、用戶需求等因素來選擇測試框架。如下是五種最流行的框架及其優缺點:
這是最基本的框架類型。它一般被稱爲「記錄和回放(record and playback)」框架。
在這個過程當中，測試代碼的建立和執行是按線性或順序編寫的——測試人員手動記錄每個步驟，並自動回放記錄的腳本。這些步驟包括導航、用戶輸入和檢查點。它最適合小型應用程序或團隊。在此過程當中，測試代碼的建立和執行以線性或順序方式編寫-測試人員手動記錄每一個步驟並自動播放記錄的腳本。這些步驟包括導航，用戶輸入和檢查點。最適合小型應用程序或小團隊。
優勢：線性框架最大的好處是生成測試用例的速度快，直接錄製；無須代碼基礎，無須手動編寫測試代碼，所以門檻較低、易於上手。
缺點：然而線性框架的不足之處也很明顯：錄製的腳本是固定的(hardcode)，不可重用。這意味着，當應用發生微小變化時，上一次錄製的腳本可能就沒法使用了，須要從新錄製(rework)，從而產生大量的後期維護成本。
顧名思義，此框架容許將被測應用程序劃分爲單獨的模塊，單元或部分。每一個模塊都會爲它們建立獨立的測試腳本。所以，每一個模塊及其測試腳本的組合能夠構建表明各類測試案例的更大的測試。
優勢：該框架在建立模塊時使用抽象。所以，應用程序更改將隻影響與它們相關聯的測試腳本所涉及的模塊，而不影響其餘部分。高度的模塊化，這使得維護更加容易且具備成本效益 建立測試用例所需的精力最少，由於能夠重複使用不一樣模塊的測試腳本。
缺點：若是沒有語言開發基礎，則創建框架可能會很困難。因爲將數據硬編碼到測試腳本中，所以沒法重複使用數據集——由於測試是單獨執行的。
該庫體系結構框架創建在模塊化框架的基礎上，但具備其餘好處。這樣作的好處是，它不只能夠將被測應用程序劃分爲測試腳本，還能夠將測試腳本中的類似任務劃分爲通用功能。
而後建立一個庫，該庫構成了AUT的經常使用功能，能夠在須要時由測試腳本調用。
優勢：高度的模塊化，這使得測試維護簡單且預算友好。它具備高度的可重用性，由於它的公共函數庫能夠被幾個測試腳本使用。
缺點：框架中引入的庫使其更加複雜。測試數據也被硬編碼到測試腳本中。所以，數據中的更改必須適用於測試腳本。測試腳本的開發須要更多的時間和技術。
在數據驅動框架中，測試數據和測試腳本是分離的。在許多測試場景中，須要使用不一樣的測試數據屢次測試同一功能或特性。若是測試數據是hardcode進測試腳本的，那麼每更換一次測試數據都須要修改測試腳本。這是很大的工做量。此時，可使用數據驅動框架。具體來講，測試腳本是固定的，而測試數據能夠從外部的數據文件，以Excel、CSV、SQL等形式做爲參數傳入測試腳本。這樣，咱們只須要維護一份腳本和一份數據文件便可。
優勢：整體來講，這種框架最大的好處就是易於維護。測試腳本中的任何更改都不會影響測試數據。所以，能夠避免對數據進行硬編碼。可使用多組數據進行測試。能夠經過更改外部數據庫中的測試數據來測試各類測試方案，從而減小所需的測試腳本數量。
缺點：準備和計劃框架的通用測試腳本，識別與格式化測試數據須要花費時間。框架設計的使用須要經驗豐富的測試人員，由於它的複雜性，須要具有多種編程語言知識。
該框架是數據驅動框架的擴展。測試數據和測試腳本也被分離，不一樣的是，該框架要更進一步地將測試腳本中的通用功能剝離出來，造成關鍵詞(keyword)。測試腳本本質上就是對一系列通用的或者自定義的關鍵詞的調用。這樣作的好處是關鍵詞能夠在多個測試中複用，而且測試腳本更加易於維護。不過，實現這樣一個框架並不是易事。
優勢：與數據驅動不一樣，運行此框架不須要腳本知識。能夠獨立於被測應用程序構建測試腳本。一個關鍵字能夠在多個測試腳本中使用。所以該代碼是可重用的。
缺點：設計框架和維護關鍵字對自動化的專業知識要求比較高。實現該框架的成本相對較高，並且設置起來也比較耗時和複雜。
綜上所述，實現用於自動化測試的框架須要選擇一種靈活的工具。該工具應支持普遍的應用程序，並知足測試要求。另外，應該有正確的策略來定義應該自動化哪些部分。
須要指出的是，業界已經有了實現上述各類測試自動化框架的工具。一般來講，咱們並不須要從新發明一個新的框架，而是基於已有的框架去進行優化升級，使之適合本身的項目需求，來完成自動化測試工做。那麼，面對一個新的自動化測試框架，如何着手工做呢？咱們應該聚焦在如下四個問題上。
不一樣的框架，生成測試用例的方法不同。對於線性框架來講，無須編寫腳本，只須要點擊預設的按鈕就可以生成測試用例；
好比Katalon，直接錄製生成測試用例。對於多數框架來講，生成測試用例須要編程。固然，不一樣框架使用的編程語言、編程風格有差別。
對於Selenium框架來講，使用的是通用編程語言Java和Python，可能更多的是對Selenium進行二次封裝，以便更好更快的生成用例；
對於Robot Framework來講，使用的是其專用的Robot Framework編程語言
。
通常來講，使用框架編程的過程不少時候就是調用庫接口的過程。所以做爲前提，在編寫用例以前，咱們須要熟悉框架提供的庫的種類和功能，以及這些庫所提供的API的使用方法。
當測試用例完成以後，咱們須要運行測試用例。自動化測試是經過GUI圖形界面來觸發，仍是經過CLI命令觸發，這因框架而異。
固然，僅僅知道如何觸發測試是不夠的。咱們一般有更多的需求。例如，如何選擇性地執行知足特定條件的測試用例子集？如何設置全局的執行參數(超時時間、日誌路徑、報告形式等)？如何動態地給測試用例集傳入參數？
通常來講，一個完整的框架須要提供足夠多的控制選項，從而讓咱們根據需求定製執行測試的方式。
以Robot Framework爲例，其執行用例的命令具備30多個不一樣的選項。這提供了足夠的自由度和一些很是棒的功能。例如其dryrun選項，可讓咱們在不實際執行用例的狀況下，快速檢查出測試用例中參數不匹配、語法不正確、關鍵詞找不到、庫導入失敗等錯誤，很是實用。
測試執行結束以後，咱們須要關注測試結果。不一樣的框架會以不一樣形式提供測試結果。例如，測試結果既能以控制檯日誌的形式體現、也可以以圖表和報告的形式體現，並以郵件發送或者展現在網站上。
根據測試結果，咱們能夠很容易地瞭解測試的執行狀況，包括測試的成功/失敗狀況、測試的總體/局部用時等。當測試失敗時，咱們尤爲須要關注測試失敗的具體狀況。
一般，咱們關心失敗是因爲咱們使用框架的方法不當形成的，仍是因爲被測軟件的質量問題。這一點，只能經過檢查和分析測試結果獲得。
通常來講，框架只是提供了最基本的功能。不少時候，框架並不能直接知足自動化測試的需求。
這時咱們能夠尋求第三方的、與框架自己兼容的庫或者插件。若是第三方工具不能知足咱們的需求，咱們就須要開發本身的庫和工具。例如，對於HTTP、SSH等公有協議，咱們很容易在網絡上找到某個框架的第三方庫；而對於只用於公司產品的私有協議，咱們一般沒法找到第三方庫，只能本身開發。本身開發時，須要注意的是要聽從框架的規範，使得開發出的庫可以與框架無縫兼容。
說在最後，選擇了一個框架，在享受其好處時，也不得不承受其不足。若是咱們的關鍵需求受制於框架，而且框架也不容易擴展，那麼咱們就可能須要開發本身的框架。這是一件投入較大的事情。在大多數狀況下，仍是建議重用和有限擴展已有的框架。畢竟，不要從新發明輪子——
Don't reinvent the wheel !
-
-
-
-
-
-
-
-
-
微信羣：
軟件自動化測試交流羣已建立，公號回覆入羣便可獲取入羣二維碼。
本文分享自微信公衆號 - 軟測小生（ruancexiaosheng）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。web