序言：也許到現在大家對所謂的「自動化測試框架」仍然覺得是一種神秘的東西，仍然覺得其與各位很遠；其實不然，「自動化測試框架」從理念來說，並不複雜，但其之所以神秘，是因為其運用起來很是複雜，每個公司，每個部門其產品線，其運作流程都是不同的，所以就導致了在想運用「自動化測試框架」去完成自動化測試時產生了很多不定因素，導致了很多自動化測試專案的失敗，讓人對「自動化測試框架」開始敬而遠之。
而自動化測試發展也有一段時間了，為什麼到現在雖見其火熱，但難見其規模，關鍵是大家對其的定位，很多公司以及很多人都知道做好自動化測試不簡簡單單的靠乙個工具，而更需要乙個框架，但其總是對「自動化測試框架」缺乏清晰的定位，很容易將其定位成了乙個固定的框架，其實個人理解不然，自動化測試框架不是乙個模式，而是一系列思想的集合，是將各種自動化測試框架思想集合應用去搭建成的乙個分層組織。
一、簡述自動化測試框架
也許很多人印象裡的自動化測試框架就是乙個能夠進行自動化測試的程式似的。其實這不全面，真正的自動化測試框架可以不是乙個程式，它僅僅是一種思想和方法的集合，說白了，就是乙個架構，大家應該都知道作業系統其實也是乙個架構吧，你可以把其理解成乙個基礎的自動化測試框架為乙個簡單的作業系統，它定義了幾層架構，定義了各層互相通訊的方式。通過這個架構我們才能在上面進行拓展我們的測試物件（核心體）、測試庫（鏈結庫）、測試用例集（各個windows程序）、測試用例（執行緒），而其之間的通過引數的傳遞進行通訊（即相當於系統中的訊息傳遞）。
二、自動化測試框架思想
接觸過自動化測試的，一定不會對以下幾種「自動化測試框架思想」陌生吧。
很多人都將以上定義為「框架」，而我卻覺得它們都只是代表了一種自動化測試的思想，不能以純粹的框架定義。
首先，我們來看看自動化測試的乙個發展，就能更加明白這些思想的真諦了。
a）第一代自動化測試，即自動化測試思想剛開始誕生時，依靠的是傳統的「錄製-回放」技術，這種技術與現在的工具的「錄製-回放」思想不一樣，其其實就是乙個「模擬」的過程，即模擬你對pc的操作而形成的，其基於你對鍵盤的輸入與對滑鼠的操作，原理與按鍵精靈等類似，這種機制對環境的依賴性太強，對變化性太過於敏感，因此不可能發展成一種規模。
b）第二代自動化測試，即指令碼化的自動化測試，利用指令碼進行結構化的自動化測試，此可以應用於cli與api的自動化測試，在其就開始整合了模組化與庫思想。
c）第三代自動化測試，開始產生了各種自動化測試思想，包括資料驅動與關鍵字驅動思想，其伴隨著物件化思想的產生，而且也造就了現在一系列的自動化測試軟體，其實其中都整合了這些思想，從這時候開始，自動化就開始實現了一定的規模，開始運用在各個行業，並且發展趨勢越來越快。
現在將一一根據自己的個人理解來介紹這些「自動化測試框架思想」：
1、所謂模組化思想，就是將乙個測試用例中的幾個不同的測試點拆分並且將其單個點的測試步驟進行了封裝，形成了乙個模組。
例如：乙個測試用例要對乙個登入程式進行測試，其中包括：使用者名稱輸入、密碼輸入、以及確定登入；
那麼就可以將使用者名稱輸入、密碼輸入、確定登入、取消登入四個操作分別封裝在四個不同的模組中。測試時，只需呼叫其模組即可。這樣的話，當乙個模組有變化，你只需單獨維護那個模組即可，也可以根據模組的不同組合成不同的測試用例。
2、所謂測試庫思想，就是模組化思想的昇華，其為應用程式的測試創造了庫檔案（可以是apis、dlls等），這些庫檔案為一系列函式的集合。其與模組化思想不同的是，其拓展了介面思想，即可以通過介面去傳遞引數，而不是乙個封死的模組，可以說是乙個多了乙個「門」的互動型模組。
例如：還是以上那個測試用例，只是將使用者名稱輸入、密碼輸入、確定登入、取消登入封裝成乙個庫，這個庫含有乙個函式login，這個函式login接收兩個引數「使用者名稱、密碼」，對輸入不同的使用者名稱和密碼可以進行不同的測試用例。也可以另外乙個函式cancle。
3、所謂資料驅動思想，眾說紛紜，很多人都覺僅僅依靠用excle表進行不同資料的讀取僅是乙個高階的引數化，其實怎麼理解並不重要，關鍵是其思想能夠好的應用到你的框架中。而我的理解就是變數不變，資料驅動結果，不同的資料導致了不同的結果的產生。而對於資料的匯入，可以通過很多方式，例如：excle表、xml（用在web中）、資料庫（db）、csv檔案、txt等都可以。
4、所謂關鍵字思想，這個思想，我曾經一直思考，它與物件導向的關係，與互動模組化思想的區別。後來個人理解，其實關鍵字驅動就是一種物件導向的思想，例如：qtp、rft中，物件可以為乙個資料或者乙個關鍵字，對物件的抓取，可以將其測試物件封裝為乙個關鍵字（即可以將gui元素封裝成了乙個個關鍵字），這樣可以對其關鍵物件進行各種操作了，不同的物件可以驅動不同的測試流向與結果。
簡單的應用的方式可以用乙個excel表，裡面包括「物件型別」「物件名稱」「物件操作名稱」「判斷方式」「預期結果」。這樣的話，可以通過匯入不同的物件型別和名稱、不同的物件操作來構建成了乙個測試用例表了。
以上只是對這些思想的個人理解，做好自動化測試，不是說你掌握了乙個框架，而是要掌握其自動化的思想，然後根據這些思想，結合你不同的測試環境和流程來構建你自己的自動化測試框架。
三、構建自動化測試框架的策略
1、永遠記住，你的「自動化測試框架」是給測試人員用的，如果你真的想把自動化測試做成乙個規模，那麼你需要將測試工程師當做你的使用者，你不能指望他們有耐心的去編寫測試指令碼或者指望他們能夠像你一樣對這些思想有良好的掌握。你要將他們當成什麼都不懂的使用者，因此你的框架必須是「一切簡單化」的化身，簡單的操作、簡單的維護、簡單的拓展。
2、做乙個自動化測試框架主要是從分層上去考慮，而不是簡簡單單的應用一種思想，它是各種思想的集合體。
例如，做gui自動化測試，簡單的一般就將其分為三層，其框架如下圖所示：
而其中，可以貫穿著自動化測試的各種思想，例如：物件層中有關鍵字的思想、可以將物件庫標示在excel表中進行管理，或者應用動態搜尋的方式傳遞物件識別引數。tasks層中可以封裝各種方法，形成乙個大型的方法庫，而每個方法中可以應用上資料驅動的思想。
3、真正的自動化測試框架是與流程上結合的，而不簡簡單單的靠技術實現，技術其實不是很複雜，關鍵就在於對其架構和流程的深刻把握，而這需要很長的一段時間，所以不要指望一口氣能吃成胖子，只能一步一步按需求來，需求指導思想的應用。
四、自動化測試框架的發展趨勢
個人認為，自動化測試從初始誕生到至今，已經經過了一段漫長的日子，而其仍處於上公升期，特別是現在軟體大**、敏捷模式、雲端的開始熱門，測試難度和質量保證的難度開始越來越大，自動化測試的比重也會越來越大，而單存的自動化測試是無法實現規模化的，因此，自動化測試框架熱門化的趨勢化的必然的，那是，在各種框架思想的集合中，各種框架將散發出各自的璀璨，來幫助我們快速的完成各種測試。
以上僅僅是至今，個人對「自動化測試框架」的理解，也許在以後的日子，因為認識的加深而會有不同的火花蹦出，但至少覺得現在的框架對自己的專案能夠進行應用，也許某一天，需求飽和時，那麼，新一輪的遠征探索就又要開始……
希望，我們大家在自動化測試的征程上能越走越遠，也希望自動化測試能真正成為測試流程中「不可缺少」的一部分。共勉之。
自動化測試 web自動化測試
自動化 由機器裝置代替人為完成制定目標的過程 優點 提高工作效率 減少勞動力 產品規格同一標準 批量生產 自動化測試 讓程式代替人為去驗證程式功能的過程，即在預設條件下執行程式系統 流程確定 搭建自動化框架 編寫測試用例，將其轉化為soupui 介面 自動化測試指令碼 執行自動化測試指令碼 輸出執行...
測試自動化 自動化測試的定義
相關術語 automated testing test tool,automated testing test suite,automated testing test script等.具體參見 http en.wikipedia.org wiki test automation 推薦書籍 1 軟體...
測試自動化
自動化測試有兩種含義 開發過程的自動化單元測試和功能驗證階段的自動化黑盒測試。這兩者融合到daily build中，是daily build的最重要核心。daily build和自動化單元測試另文詳述，此處主要說說自動化功能測試。自動化測試的投入產出比以及實際應用效果其實不高 自動化測試作為提高測試...