一個用於網站自動化測試的生態系統實現

這是我在從事網站自動化測試的工做當中構建出的一個「生態系統」。「生態系統」這個概念是我從公司的前輩身上學到的，他一直以來都認爲自動化測試人員不該僅僅侷限於編寫測試代碼，還應該讓整個自動化測試的過程（測試代碼的持續集成、分發、執行等）都自動化，造成一個「系統」，這個系統的自動化程度越高，自動化測試人員就越省力。

1、概念

這裏我畫了一張示意圖：

之因此稱之爲「生態系統」，是由於建成以後須要的人爲干涉不多，其他的時間都是系統內部循環運做。做爲自動化測試人員的你只須要提交代碼，以後即可以在AutomationDashboard上看到運行的結果了，其他的事情都由系統內部消化。固然，結果的分析仍是須要人來完成，機器尚未聰明到能夠靈活分析出各類各樣讓case fail掉的緣由。

咱們能夠把整個系統看做一個黑盒子，那麼上面的圖能夠變成：

實際上這裏畫的人不只限於自動化測試人員，也能夠是：

（1）產品的管理者，好比產品經理須要從自動化迴歸測試知道此次release有無推遲風險；

（2）團隊的管理者，好比開發經理、QA經理須要從自動化的daily/weekly regression知道最近的代碼質量如何；

（3）開發人員，他們也許會想經過quick regression（提交的產品代碼被部署到測試環境以後運行的測試）知道本身剛提交的代碼有沒有破壞系統的基本功能；

（4）其餘幫忙作自動化測試的開發人員、剛剛開始學習編寫自動化測試代碼的手動測試人員，他們沒必要關心生態系統的內部實現。

2、實現

說完概念，接下來該說說具體實現了。我這裏講的是我認爲最適合我所測試的產品的實現，工具不止一種，方式不止一種。Jenkins能夠用TeamCity或其它CI替換，git也能夠是svn或tfs，AutomationDahsboard能夠用.NET、SpringMVC、ROR等等實現，運行測試的slave能夠是Windows/Linux/Mac（土豪！），總之選擇一種最適合你所測試的產品的實現。還有一點就是自動化測試代碼是用關鍵字驅動思想實現的，這是另一個話題了，有時間另外寫篇文。

好，進入正題。依次說說系統的每一個重要組成部分吧：

一、SCM（Source Code Management）。我選的是git，能夠是git服務器（公司本身搭建了一個git server），也能夠是一個bare repo（http://www.saintsjd.com/2011/01/what-is-a-bare-git-repository/） 。

二、CI（continuous integration）。我選的是部署方便、插件豐富的Jenkins。

它的職責是：

（1）從git上取出代碼，build（.NET對應msbuild，若是是ruby則不用build了，直接部署便可）；

（2）把build好的*.dll部署（這裏便是拷貝）到全部的slave上；

（3）啓動或中止全部slave上的AutomationService（後面還會講到AutomationService），從而控制測試的執行。

我在Jenkins的這些個job配置起來仍是比較繁瑣的，要細講又能夠另外寫一篇文了。這裏就特別提到兩個很實用的插件吧：

（1）Parameterized Trigger Plugin（https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Trigger+Plugin）：能夠在一個build step中觸發其它project的build。

它最有用的就是這個「Block until the triggered projects finish their builds」選項，勾上的話Jenkins就能在全部trigger的project完成build以後（而非僅僅trigger其它project的build，不等它們完成就繼續下一個build step）再繼續下一個build step，作到真正的依次執行每一個build step。

（2）NodeLabel Parameter Plugin（https://wiki.jenkins-ci.org/display/JENKINS/NodeLabel+Parameter+Plugin）：在全部「Possible nodes」標有指定標籤（「Label」）的Jenkins節點（就是Jenkins master或Jenkins slave）上觸發指定project（被觸發的project是參數化的）。

好比我有一個project叫「StartClassicROLATServiceOnAllNodes」，它有一個build step是這樣設定的：

再來看看「StartClassicROLATServiceOnASingleNode」這個project的設定：

這個project有一個Node類型的參數，參數名「NodeX」與以前Label Factory中的「NodeX」對應，「Possible nodes」選的是「ALL」，那麼列出的全部node（master、10.107.122.15二、10.107.122.15三、10.107.122.154）都在判斷範圍以內（判斷其是否有「Node」標籤，有則執行project）。

另外，列出的全部node我都爲其加了一個「Node」標籤。

這樣，當我trigger 「StartClassicROLATServiceOnAllNodes」以後，就會在master、10.107.122.15二、10.107.122.15三、10.107.122.154這4個node上同時執行「StartClassicROLATServiceOnASingleNode」。

三、AutomationDashboard，這裏姑且譯做「自動化測試控制面板」吧。實際上它應該和Jenkins一塊兒並稱控制面板，不過由於Jenkins有API能夠調用，因此想作的畫二者也是能夠統一成一個web界面的。這個dashboard徹底是用.NET+IIS+SQLServer一點點從數據庫設計構建、數據訪問層、業務層、表現層作起來的，要細講……額……又會是另一篇文了（Oh man, not again!）。反正我以爲，雖然我是作自動化測試工做的，但不該該把本身侷限於測試。爲了更好地進行自動化測試，開發網站、安裝配置虛擬機以及其它要用到的工具，都應該抽時間去學習、掌握。

好，來講說這個dashboard。這裏只講兩個主要組成部分，一個網站（如下簡稱dashboard）、一個Windows Service（如下簡稱ATService）和一個console application（如下稱ConsoleRunner）：

（1）dashboard，它的主要功能：

a、展現測試的運行情況：有多少正在運行/執行完畢，分別在哪臺slave上執行等等。

b、經過call Jenkins的API來trigger Jenkins的job，間接控制測試的執行。

c、展現測試的結果：發生錯誤的是哪一個case、出錯時間、錯誤信息、代碼回溯（stack trace）、甚至能夠包含一張出錯時的截圖。

主要界面以下：

a、Summary，顧名思義是彙總信息，case有多少pass多少fail、case按分類每一類有多少等等。（其實這裏我少作了一張很重要的圖，就是coverage餅狀圖）

b、Queue，測試隊列，包含當前正在運行的、運行完的、等待運行的test fixture或test case（依據測試工具的不一樣，NUnit、JUnit、RSpec等，fixture的叫法可能不一樣，總之就是包含多個test case的集合）。能夠啓動、中止、終止（終止以後能夠清空）測試執行或清空當前隊列。

c、TestCase，生態系統中的全部測試用例會展現在這裏，能夠看到它們最後一次執行的時間和狀態（pass/fail），點擊某條case能夠跳轉到該條case的全部test result。能夠按狀態（pass/fail/other）篩選用例，能夠勾選部分用例從新執行、或從新執行全部fail的case。「Reload Test Cases」主要是考慮到*.dll文件中的test case可能會在某次部署以後發生變化，須要從新加載。不事後來我修改了Jenkins裏的job在每次部署以後都自動從新加載，因此這個按鈕其實沒什麼用了。

d、TestSuite，包含多個fixture的集合是一個suite。勾選多個suite點擊「Run Suite」便可把這些suite中包含的fixture添加到Queue。

這裏的suite是對NUnit中的Category的一個補充，點擊「New Suite」你能夠任意選擇fixture來組成本身想要的suite：

e、TestResult，展現全部test case的運行結果，能夠按test case id進行篩選，點擊TC#這一列的id就只顯示這條case的結果。

點右邊的藍色「i」圖標能夠跳到這條結果的詳細頁面，截圖功能暫未啓用，根據RunnerMessage和RunnerStackTrace能夠知道報錯的代碼位置，進而嘗試重現問題。

（2）ATService。這個Windows Service（slave都是Windows，稍後會講）被安裝到了每一個slave上，用以向dashboard詢問「如今有沒有分配給個人test fixture/case？」，若是有且當前slave空閒的話就抓過來運行，運行完畢彙報結果。

還記得Queue（隊列）吧？不管你在TestCase仍是TestSuite頁面挑選了test case/suite想要運行，都只是把它們添加到隊列當中（準確地說就是往Queue這張數據庫表中INSERT記錄），而不會給它們分配slave。只有當Jenkins啓動了slave上的ATService以後，ATService纔會去Queue表中本身抓取（就是打上標記說這條fixture/case已經有主了，其它slave就不會再去抓）尚未運行過且沒有分配有slave的test fixture/case。

（3）ConsoleRunner，最開始的那個圖中沒有畫出來。這個console程序主要供Jenkins調用。Jenkins不是可讓job定時運行麼？正好，定時調用這個console application，傳幾個參數，就能夠在指定時間往Queue裏填充fixture/case，而後再啓動ATService開始執行測試。這樣就能實現quick/daily/weekly/full regression的無人值守運行了。

四、Slave

我選擇在Windows上運行測試：

（1）公司IT通常只提供Windows操做系統的虛擬機

（2）產品在Windows上的用戶佔絕大多數（其實這個有點廢話，桌面操做系統Windows依然是世界王者。誠然，我本身業餘時用Linux作開發，Mac在國內外也是至關流行的，但GoogleAnalytics顯示的統計結果就是大部分訪問都來自Windows。什麼，你說iOS/Android？額……移動端如今仍然是產品的短板……）

若是選擇Linux的話要注意下selenium webdriver的native event設定（http://code.google.com/p/selenium/wiki/AdvancedUserInteractions#Native_events_versus_synthetic_events）。

關於瀏覽器，Firefox、Chrome、IE皆可，webdriver的瀏覽器兼容性已經很不錯了。瀏覽器兼容性是個有點頭疼的問題，想支持不少瀏覽器的話有時會增長不少開發、測試成本，我通常在Firefox上跑就足夠了。什麼？數字？馬桶？企鵝？您想多了，selenium官方不支持。

你能找到多少臺slave來執行測試？多多益善哦！找不到那麼多實體機就本身配虛擬機吧，分佈式運行能夠給你的自動化測試生態系統裝上火箭！在更短的時間內運行完更多測試，從而更快地從測試中得到反饋！

嗯，差很少就這麼多了。還有不少細節就留在以後的文中再說了。自我感受這個生態系統仍是有不少能夠完善、增長的功能，並且這個實現方式、運做機制可能也並不是適用於你所測試的產品，不過如今對於我測的產品來講是夠用的了。

無論怎樣實現，我想表達的核心觀點是：

作自動化測試不要侷限於自動化測試代碼的編寫，咱們要自動化的不只僅是manual test case，還應包括整個automation test的process！測試代碼持續集成、部署（分發）、執行、結果展現，自動化的環節越多、越完全，爲你節約的時間就越多，你能夠用這些節約的時間作更有意義的事情。人類發明計算機，用代碼編寫程序，其實就是一種自動化的過程。之前要靠手工勞動完成的如今都交給電腦作了——服務器不正是勤勤懇懇地重複執行着咱們寫好的程序麼？構建自動化測試生態系統是一樣的道理，由於機器能比人更可靠地完成重複勞動。

若是你還在手動拷貝*.dll，還須要打開NUnit手動執行測試，還在1臺機器上運行測試，那麼，如今就是該提升生產力的時候了！