談自動化測試框架思想與構建

序言：也許到如今你們對所謂的「自動化測試框架」仍然以爲是一種神祕的東西，仍然以爲其與各位很遠；其實否則，「自動化測試框架」從理念來講，並不複雜，但其之因此神祕，是由於其運用起來非常複雜，每一個公司，每一個部門其產品線，其運做流程都是不一樣的，因此就致使了在想運用「自動化測試框架」去完成自動化測試時產生了不少不定因素，致使了不少自動化測試項目的失敗，讓人對「自動化測試框架」開始敬而遠之。

而自動化測試發展也有一段時間了，爲何到如今雖見其火熱，但難見其規模，關鍵是你們對其的定位，不少公司以及不少人都知道作好自動化測試不簡簡單單的靠一個工具，而更須要一個框架，但其老是對「自動化測試框架」缺少清晰的定位，很容易將其定位成了一個固定的框架，其實我的理解否則，自動化測試框架不是一個模式，而是一系列思想的集合，是將各類自動化測試框架思想集合應用去搭建成的一個分層組織。

1、簡述自動化測試框架

也許不少人印象裏的自動化測試框架就是一個可以進行自動化測試的程序似的。其實這不全面，真正的自動化測試框架能夠不是一個程序，它僅僅是一種思想和方法的集合，說白了，就是一個架構，你們應該都知道操做系統其實也是一個架構吧，你能夠把其理解成一個基礎的自動化測試框架爲一個簡單的操做系統，它定義了幾層架構，定義了各層互相通訊的方式。經過這個架構咱們才能在上面進行拓展咱們的測試對象（核心體）、測試庫（連接庫）、測試用例集（各個windows進程）、測試用例（線程），而其之間的經過參數的傳遞進行通訊（即至關於系統中的消息傳遞）。

2、自動化測試框架思想

接觸過自動化測試的，必定不會對如下幾種「自動化測試框架思想」陌生吧。

• 模塊化思想
• 庫思想
• 數據驅動思想
• 關鍵字驅動思想

不少人都將以上定義爲「框架」，而我卻以爲它們都只是表明了一種自動化測試的思想，不能以純粹的框架定義。

首先，咱們來看看自動化測試的一個發展，就能更加明白這些思想的真諦了。

a）第一代自動化測試，即自動化測試思想剛開始誕生時，依靠的是傳統的「錄製-回放」技術，這種技術與如今的工具的「錄製-回放」思想不同，其其實就是一個「模擬」的過程，即模擬你對PC的操做而造成的，其基於你對鍵盤的輸入與對鼠標的操做，原理與按鍵精靈等相似，這種機制對環境的依賴性太強，對變化性太過於敏感，所以不可能發展成一種規模。

b）第二代自動化測試，即腳本化的自動化測試，利用腳本進行結構化的自動化測試，此能夠應用於CLI與API的自動化測試，在其就開始集成了模塊化與庫思想。

c）第三代自動化測試，開始產生了各類自動化測試思想，包括數據驅動與關鍵字驅動思想，其伴隨着對象化思想的產生，並且也造就瞭如今一系列的自動化測試軟件，其實其中都集成了這些思想，從這時候開始，自動化就開始實現了必定的規模，開始運用在各個行業，而且發展趨勢愈來愈快。

如今將一一根據本身的我的理解來介紹這些「自動化測試框架思想」：

一、所謂模塊化思想，就是將一個測試用例中的幾個不一樣的測試點拆分而且將其單個點的測試步驟進行了封裝，造成了一個模塊。

例如：一個測試用例要對一個登陸程序進行測試，其中包括：用戶名輸入、密碼輸入、以及肯定登陸；

那麼就能夠將用戶名輸入、密碼輸入、肯定登陸、取消登陸四個操做分別封裝在四個不一樣的模塊中。測試時，只需調用其模塊便可。這樣的話，當一個模塊有變化，你只需單獨維護那個模塊便可，也能夠根據模塊的不一樣組合成不一樣的測試用例。

二、所謂測試庫思想，就是模塊化思想的昇華，其爲應用程序的測試創造了庫文件（能夠是APIs、DLLs等），這些庫文件爲一系列函數的集合。其與模塊化思想不一樣的是，其拓展了接口思想，便可以經過接口去傳遞參數，而不是一個封死的模塊，能夠說是一個多了一個「門」的交互型模塊。

例如：仍是以上那個測試用例，只是將用戶名輸入、密碼輸入、肯定登陸、取消登陸封裝成一個庫，這個庫含有一個函數Login，這個函數Login接收兩個參數「用戶名、密碼」，對輸入不一樣的用戶名和密碼能夠進行不一樣的測試用例。也能夠另一個函數Cancle。

三、所謂數據驅動思想，衆說紛紜，不少人都覺僅僅依靠用EXCLE表進行不一樣數據的讀取僅是一個高級的參數化，其實怎麼理解並不重要，關鍵是其思想可以好的應用到你的框架中。而個人理解就是變量不變，數據驅動結果，不一樣的數據致使了不一樣的結果的產生。而對於數據的導入，能夠經過不少方式，例如：EXCLE表、XML（用在WEB中）、數據庫（DB）、CSV文件、TXT等均可以。

四、所謂關鍵字思想，這個思想，我曾經一直思考，它與面向對象的關係，與交互模塊化思想的區別。後來我的理解，其實關鍵字驅動就是一種面向對象的思想，例如：QTP、RFT中，對象能夠爲一個數據或者一個關鍵字，對對象的抓取，能夠將其測試對象封裝爲一個關鍵字（便可以將gui元素封裝成了一個個關鍵字），這樣能夠對其關鍵對象進行各類操做了，不一樣的對象能夠驅動不一樣的測試流向與結果。

簡單的應用的方式能夠用一個EXCEL表，裏面包括「對象類型」「對象名稱」「對象操做名稱」「判斷方式」「預期結果」。這樣的話，能夠經過導入不一樣的對象類型和名稱、不一樣的對象操做來構建成了一個測試用例表了。

以上只是對這些思想的我的理解，作好自動化測試，不是說你掌握了一個框架，而是要掌握其自動化的思想，而後根據這些思想，結合你不一樣的測試環境和流程來構建你本身的自動化測試框架。

3、構建自動化測試框架的策略

一、永遠記住，你的「自動化測試框架」是給測試人員用的，若是你真的想把自動化測試作成一個規模，那麼你須要將測試工程師當作你的用戶，你不能期望他們有耐心的去編寫測試腳本或者期望他們可以像你同樣對這些思想有良好的掌握。你要將他們當成什麼都不懂的用戶，所以你的框架必須是「一切簡單化」的化身，簡單的操做、簡單的維護、簡單的拓展。

二、作一個自動化測試框架主要是從分層上去考慮，而不是簡簡單單的應用一種思想，它是各類思想的集合體。

例如，作GUI自動化測試，簡單的通常就將其分爲三層，其框架以下圖所示：

 

而其中，能夠貫穿着自動化測試的各類思想，例如：對象層中有關鍵字的思想、能夠將對象庫標示在Excel表中進行管理，或者應用動態搜索的方式傳遞對象識別參數。tasks層中能夠封裝各類方法，造成一個大型的方法庫，而每一個方法中能夠應用上數據驅動的思想。

三、真正的自動化測試框架是與流程上結合的，而不簡簡單單的靠技術實現，技術其實不是很複雜，關鍵就在於對其架構和流程的深入把握，而這須要很長的一段時間，因此不要期望一口氣能吃成胖子，只能一步一步按需求來，需求指導思想的應用。

4、自動化測試框架的發展趨勢

我的認爲，自動化測試從初始誕生到至今，已經通過了一段漫長的日子，而其仍處於上升期，特別是如今軟件大爆炸、敏捷模式、雲端的開始熱門，測試難度和質量保證的難度開始愈來愈大，自動化測試的比重也會愈來愈大，而單存的自動化測試是沒法實現規模化的，所以，自動化測試框架熱門化的趨勢化的必然的，那是，在各類框架思想的集合中，各類框架將散發出各自的璀璨，來幫助咱們快速的完成各類測試。

以上僅僅是至今，我的對「自動化測試框架」的理解，也許在之後的日子，由於認識的加深而會有不一樣的火花蹦出，但至少以爲如今的框架對本身的項目可以進行應用，也許某一天，需求飽和時，那麼，新一輪的遠征探索就又要開始……

但願，咱們你們在自動化測試的征程上能越走越遠，也但願自動化測試能真正成爲測試流程中「不可缺乏」的一部分。共勉之。