本身動手寫Web自動化測試框架（6）：自動化測試框架的規劃

　從這篇開始，咱們正式進入自動化測試框架的編寫中。

　　首先咱們先進行需求分析：咱們到底要什麼樣的自動化測試框架？

　　正如第一篇《本身動手寫Web自動化測試框架（1）：概述》 中提到的，咱們要作的是一個簡單的自動化測試框架，沒有Ajax，沒有框架，沒有Windows對話框，咱們捨棄這些較爲複雜的功能，目的就在於，咱們想要把注意力集中在自動化測試框架的架構上，之後咱們能夠慢慢加入這些功能，可是第一次，咱們不要。

　　這裏規劃一下，咱們想要的自動化測試框架是什麼樣子的，那麼要從咱們的自動化測試提及了。自動化測試代碼通常是在何時寫的呢？在微軟裏，自動化測試代碼應該和被測試的網站的代碼同步開發，由於有了Spec（Specification），咱們就能夠根據Spec來測試用例，而後把咱們認爲重要的，必須常常重複的用例自動化起來。

　　可是問題在於，咱們在沒有網站的狀況下，如何進行自動化測試的開發呢？咱們面臨的困難主要有如下的方面：

　　* 沒有網站，就沒有網頁元素的ID之類的標識，沒有辦法按照上面的辦法獲取咱們想要的網頁元素。

　　* 網站建設初期，頁面元素不穩定，一個小小的ID的變動就可使咱們的自動化代碼變的無用。

　　* 即便是頁面元素不變，一個小小的業務邏輯的改變，也可能會很大的影響到咱們的自動化測試代碼。

　　咱們的自動化測試框架，必定要能夠比較好的解決上面的問題。

　　我想不少的讀者已經明白了，咱們要作的就是把網頁的元素和網站的業務邏輯分開，這樣就能夠比較好的解決這些問題。

　　咱們最終的目標是在一個類裏面去定義整個網站的架構，好比這個網頁上有一個文本框，有幾個按鈕。就像下面的這段代碼:

 

public class Baidu {   WebBrowser wb = new WebBrowser("www.baidu.com");   private Button submit;   private TextBox keyword;   public Button Submit   {     get{       if (submit == null)       {         submit = new Button(wb, "sb");       }       return submit;     }   }     public TextBox Keyword   {     get     {       if (keyword == null)       {         keyword = new TextBox(wb, "kw");       }       return keyword;     }   } }

 

　　上面的代碼，咱們定義了兩個屬性，一個是Button Submit，另外一個是Textbox Keyword。這兩個屬性定義了百度首頁的兩個最重要的元素，咱們也能夠定義更多的好比登陸的HyperLink或者其餘的一些元素，可是咱們如今以這個爲例子來定義。

 

這裏的代碼定義並非最簡單的，讀者徹底能夠經過本身的努力對測試框架進行修改，把這個代碼作到更簡單，不過咱們這裏以這個代碼爲例，來說述自動化測試框架的架構等比較高層的東西。咱們能夠之後來細化這裏。

　　通過以上的定義，咱們的業務邏輯代碼就能夠被簡略到以下的語句：

 

Baidu b = new Baidu(); b.Keyword.Text = "生生不息"; b.Submit.Click();

 

　　這裏我想很簡單，就是咱們打開一個百度的實例，而後輸入生生不息，而後點搜索按鈕。咱們之後還能夠更多的建模，把驗證也放在裏面。

　　怎麼樣？若是咱們的的自動化測試框架能夠達到這樣的效果，咱們就能夠很好的解決上面提出的問題，當Web的開發尚未徹底成型的時候，咱們能夠定義頁面的元素，空着ID不填，而後把業務邏輯作好，一旦Web開發完成，咱們只須要填補上網頁元素的定義，自動化測試代碼就能夠完成。

　　是否是已經摩拳擦掌了？咱們從下一節開始，自動動手來作出這樣一個自動化的測試框架來。