談自動化測試框架思想與構建
序言：也許到現在大家對所謂的“自動化測試框架”仍然覺得是一種神秘的東西，仍然覺得其與各位很遠；其實不然，“自動化測試框架”從理念來說，并不復雜，但其之所以神秘，是因為其運用起來很是復雜，每個公司，每個部門其產品線，其運作流程都是不同的，所以就導致了在想運用“自動化測試框架”去完成自動化測試時產生了很多不定因素，導致了很多自動化測試項目的失敗，讓人對“自動化測試框架”開始敬而遠之。
而自動化測試發展也有一段時間了，為什么到現在雖見其火熱，但難見其規模，關鍵是大家對其的定位，很多公司以及很多人都知道做好自動化測試不簡簡單單的靠一個工具，而更需要一個框架，但其總是對“自動化測試框架”缺乏清晰的定位，很容易將其定位成了一個固定的框架，其實個人理解不然，自動化測試框架不是一個模式，而是一系列思想的集合，是將各種自動化測試框架思想集合應用去搭建成的一個分層組織。
一、簡述自動化測試框架
也許很多人印象里的自動化測試框架就是一個能夠進行自動化測試的程序似的。其實這不全面，真正的自動化測試框架可以不是一個程序，它僅僅是一種思想和方法的集合，說白了，就是一個架構，大家應該都知道操作系統其實也是一個架構吧，你可以把其理解成一個基礎的自動化測試框架為一個簡單的操作系統，它定義了幾層架構，定義了各層互相通信的方式。通過這個架構我們才能在上面進行拓展我們的測試對象（核心體）、測試庫（鏈接庫）、測試用例集（各個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、真正的自動化測試框架是與流程上結合的，而不簡簡單單的靠技術實現，技術其實不是很復雜，關鍵就在于對其架構和流程的深刻把握，而這需要很長的一段時間，所以不要指望一口氣能吃成胖子，只能一步一步按需求來，需求指導思想的應用。
四、自動化測試框架的發展趨勢
個人認為，自動化測試從初始誕生到至今，已經經過了一段漫長的日子，而其仍處于上升期，特別是現在軟件大爆炸、敏捷模式、云端的開始熱門，測試難度和質量保證的難度開始越來越大，自動化測試的比重也會越來越大，而單存的自動化測試是無法實現規模化的，因此，自動化測試框架熱門化的趨勢化的必然的，那是，在各種框架思想的集合中，各種框架將散發出各自的璀璨，來幫助我們快速的完成各種測試。
以上僅僅是至今，個人對“自動化測試框架”的理解，也許在以后的日子，因為認識的加深而會有不同的火花蹦出，但至少覺得現在的框架對自己的項目能夠進行應用，也許某一天，需求飽和時，那么，新一輪的遠征探索就又要開始……
希望，我們大家在自動化測試的征程上能越走越遠，也希望自動化測試能真正成為測試流程中“不可缺少”的一部分。共勉之。
版權聲明：本文出自 散步的SUN 的51Testing軟件測試博客：http://www.51testing.com/?382641
【編輯推薦】
