所謂的自動化測試模型，可以理解為自動化測試框架+工具設計的一種思想產物。
先說說庫、框架、工具之間的區別：
庫：英文名Library，由代碼集成的一個產品，供用戶調用。面向對象的庫叫做類庫，面向過程的庫叫做函數庫，webdriver就屬於庫的范疇。
框架：英文名Framework，為解決一個或一類問題而開發的產品，一般只需要使用框架提供的類或函數，即可實現全部功能。前面的博客中提到的unittest框架，
主要用於實現測試用例的組織和執行，以及測試結果的生成，因此通常稱它為單元測試框架。
工具：英文名Tools，相對框架來說更抽象，屏蔽底層代碼，一般提供單獨的操作界面供用戶使用，像QTP、selenium IDE就是自動化測試工具。
自動化測試發展至今，常見的測試模型有以下幾種類型：
一、線性測試
早期的自動化測試，就是通過錄制或者編寫應用程序的操作步驟產生響應的線性腳本，來模擬用戶完整的操作場景。
優點：單個腳本相對完整，且獨立，可拿出來單獨執行；
缺點：開發成本很高，測試用例之間可能存在重復操作，每次都要錄制或編寫重復的操作，比如用戶登錄；
維護成本很高，因為存在重復操作，因此如重復操作發生變更，就需要包含重復操作的用例都需要進行修改；
二、模塊驅動化測試
將重復的操作獨立封裝為公共模塊，用例執行過程中需要用到時調用該公共模塊，最大限度的消除重復操作；
優點：提高開發效率，不用重復編寫相同的腳本；
簡化了維護的復雜性，如果某個地方發生變化，只需要修改變更內容即可；
三、數據驅動測試
即根據數據的改變去驅動自動化測試的執行，最終引起測試結果的改變，簡單來說，數據驅動就是數據的參數化，因為輸入的不同而引起輸出的不同。
數據驅動的方式很多，無論讀取的是定義的數組、字典，或是外部文件（excel、csv、txt、xml等），都可以看做數據驅動，目的都是實現數據與腳本分離。
優點：增強腳本的復用性，比如用戶登錄模塊，使用不同的數據進行登錄，這樣可以很好的適用於相同操作不同數據的情況。
四、關鍵字驅動測試
關鍵字驅動和數據驅動很相似，通過關鍵字的改變引起測試結果的改變，也稱之為表格驅動測試或基於動作字的測試。
關鍵字驅動基本上將測試用例分為4個不同的部分，分別是：
測試步驟（Test Step）、測試步驟中的對象（Test Object）、測試對象執行的動作(Action)、測試對象需要的數據（Test Data）。
目前典型的關鍵字驅動工具以QTP（最新版本叫做UTF）和Robot Framework為主，前者為商業工具，后者開源。
這類工具皆封裝了底層代碼，提供獨立的圖形界面，只需使用工具所提供的關鍵字，以“填表格”的方式來編寫用例即可。
缺點：個人認為，這種傻瓜式的測試模型對個人的技術和經驗提升，沒有太大幫助，我本人還是比較傾向於寫代碼去實現自動化測試，畢竟，“代碼改變世界！”
不過話說回來，無論是工具還是測試模型，都是輔助我們更好的工作，提升效率；這一點，仁者見仁智者見智，觀點不同而已。。。
五、綜合自動化測試
上面的幾種自動化測試模型，有各自的適用場景和優缺點，但實際來說，真實的場景往往比我們預估的更復雜，所以，根據實際情況選擇合適的測試模型，綜合使用不失為一種比較合理的做法。
個人認為，成功的自動化測試模型，通常都融合了“模塊驅動”+“數據驅動/關鍵字驅動”，優點如下：
1、即擁有腳本與測試數據相互分離的優點，又結合了模塊驅動的架構，這樣會使得測試腳本更加簡潔，並減少運行時意外失敗的可能性；
2、該架構可以實現一些純粹的“數據/關鍵字驅動測試”難以實現的自動化測試任務；
3、大大減少了測試用例的維護復雜性，提升了腳本開發效率，測試腳本的可復用性、移植性較強；
關於具體的測試模型使用實例，后續后不斷更新介紹。。。