這是我在從事網(wǎng)站
自動化測試的
工作當(dāng)中構(gòu)建出的一個“生態(tài)系統(tǒng)”。“生態(tài)系統(tǒng)”這個概念是我從公司的前輩身上學(xué)到的，他一直以來都認(rèn)為自動化測試人員不應(yīng)僅僅局限于編寫測試代碼，還應(yīng)該讓整個自動化測試的過程（測試代碼的持續(xù)集成、分發(fā)、執(zhí)行等）都自動化，形成一個“系統(tǒng)”，這個系統(tǒng)的自動化程度越高，自動化測試人員就越省力。
一、概念
這里我畫了一張示意圖：
之所以稱之為“生態(tài)系統(tǒng)”，是因為建成之后需要的人為干涉很少，其余的時間都是系統(tǒng)內(nèi)部循環(huán)運作。作為自動化測試人員的你只需要提交代碼，之后便可以在AutomationDashboard上看到運行的結(jié)果了，其余的事情都由系統(tǒng)內(nèi)部消化。當(dāng)然，結(jié)果的分析還是需要人來完成，機(jī)器還沒有聰明到可以靈活分析出各種各樣讓case fail掉的原因。
我們可以把整個系統(tǒng)看作一個黑盒子，那么上面的圖可以變成：
實際上這里畫的人不僅限于自動化測試人員，也可以是：
（1）產(chǎn)品的管理者，比如產(chǎn)品經(jīng)理需要從自動化回歸測試知道這次release有無推遲風(fēng)險；
（2）團(tuán)隊的管理者，比如開發(fā)經(jīng)理、QA經(jīng)理需要從自動化的daily/weekly regression知道最近的代碼質(zhì)量如何；
（3）開發(fā)人員，他們也許會想通過quick regression（提交的產(chǎn)品代碼被部署到測試環(huán)境之后運行的測試）知道自己剛提交的代碼有沒有破壞系統(tǒng)的基本功能；
（4）其他幫忙做自動化測試的開發(fā)人員、剛剛開始
學(xué)習(xí)編寫自動化測試代碼的手動測試人員，他們不必關(guān)心生態(tài)系統(tǒng)的內(nèi)部實現(xiàn)。
二、實現(xiàn)
說完概念，接下來該說說具體實現(xiàn)了。我這里講的是我認(rèn)為最適合我所測試的產(chǎn)品的實現(xiàn)，工具不止一種，方式不止一種。Jenkins可以用TeamCity或其它CI替換，git也可以是svn或tfs，AutomationDahsboard可以用.NET、SpringMVC、ROR等等實現(xiàn)，運行測試的slave可以是Windows/Linux/Mac（土豪！），總之選擇一種最適合你所測試的產(chǎn)品的實現(xiàn)。還有一點就是自動化測試代碼是用關(guān)鍵字驅(qū)動思想實現(xiàn)的，這是另外一個話題了，有時間另外寫篇文。
好，進(jìn)入正題。依次說說系統(tǒng)的每個重要組成部分吧：
1、SCM（Source Code Management）。我選的是git，可以是git服務(wù)器（公司自己搭建了一個git
server），也可以是一個bare repo（http://www.saintsjd.com/2011/01/what-is-a-bare-git-repository/） 。
2、CI（continuous integration）。我選的是部署方便、插件豐富的Jenkins。
它的職責(zé)是：
（1）從git上取出代碼，build（.NET對應(yīng)msbuild，如果是ruby則不用build了，直接部署即可）；
（2）把build好的*.dll部署（這里即是拷貝）到所有的slave上；
（3）啟動或停止所有slave上的AutomationService（后面還會講到AutomationService），從而控制測試的執(zhí)行。我在Jenkins的這些個job配置起來還是比較繁瑣的，要細(xì)講又可以另外寫一篇文了。這里就特別提到兩個很實用的插件吧：
（1）Parameterized Trigger Plugin（https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Trigger+Plugin）：可以在一個build step中觸發(fā)其它project的build。
它最有用的就是這個“Block until the triggered projects finish their builds”選項，勾上的話Jenkins就能在所有trigger的project完成build之后（而非僅僅trigger其它project的build，不等它們完成就繼續(xù)下一個build step）再繼續(xù)下一個build step，做到真正的依次執(zhí)行每個build step。
（2）NodeLabel Parameter Plugin（https://wiki.jenkins-ci.org/display/JENKINS/NodeLabel+Parameter+Plugin）：在所有“Possible nodes”標(biāo)有指定標(biāo)簽（“Label”）的Jenkins節(jié)點（就是Jenkins master或Jenkins slave）上觸發(fā)指定project（被觸發(fā)的project是參數(shù)化的）。
比如我有一個project叫“StartClassicROLATServiceOnAllNodes”，它有一個build step是這樣設(shè)定的：
再來看看“StartClassicROLATServiceOnASingleNode”這個project的設(shè)定：
這個project有一個Node類型的參數(shù)，參數(shù)名“NodeX”與之前Label Factory中的“NodeX”對應(yīng)，“Possible nodes”選的是“ALL”，那么列出的所有node（master、10.107.122.152、10.107.122.153、10.107.122.154）都在判斷范圍之內(nèi)（判斷其是否有“Node”標(biāo)簽，有則執(zhí)行project）。
另外，列出的所有node我都為其加了一個“Node”標(biāo)簽。
這樣，當(dāng)我trigger “StartClassicROLATServiceOnAllNodes”之后，就會在master、10.107.122.152、10.107.122.153、10.107.122.154這4個node上同時執(zhí)行“StartClassicROLATServiceOnASingleNode”。
3、AutomationDashboard，這里姑且譯作“自動化測試控制面板”吧。實際上它應(yīng)該和Jenkins一起并稱控制面板，不過因為Jenkins有API可以調(diào)用，所以想做的畫兩者也是可以統(tǒng)一成一個web界面的。這個dashboard完全是用.NET+IIS+SQLServer一點點從數(shù)據(jù)庫設(shè)計構(gòu)建、數(shù)據(jù)訪問層、業(yè)務(wù)層、表現(xiàn)層做起來的，要細(xì)講……額……又會是另外一篇文了（Oh man, not again!）。反正我覺得，雖然我是做自動化測試工作的，但不應(yīng)該把自己局限于測試。為了更好地進(jìn)行自動化測試，開發(fā)網(wǎng)站、安裝配置虛擬機(jī)以及其它要用到的工具，都應(yīng)該抽時間去學(xué)習(xí)、掌握。
好，來說說這個dashboard。這里只講兩個主要組成部分，一個網(wǎng)站（以下簡稱dashboard）、一個Windows Service（以下簡稱ATService）和一個console application（以下稱ConsoleRunner）：
（1）dashboard，它的主要功能：
a、展示測試的運行狀況：有多少正在運行/執(zhí)行完畢，分別在哪臺slave上執(zhí)行等等。
b、通過call Jenkins的API來trigger Jenkins的job，間接控制測試的執(zhí)行。
c、展示測試的結(jié)果：發(fā)生錯誤的是哪個case、出錯時間、錯誤信息、代碼回溯（stack trace）、甚至可以包含一張出錯時的截圖。
主要界面如下：
a、Summary，顧名思義是匯總信息，case有多少pass多少fail、case按分類每一類有多少等等。（其實這里我少做了一張很重要的圖，就是coverage餅狀圖）
b、Queue，測試隊列，包含當(dāng)前正在運行的、運行完的、等待運行的test fixture或test case（依據(jù)測試工具的不同，NUnit、JUnit、RSpec等，fixture的叫法可能不同，總之就是包含多個test case的集合）。可以啟動、停止、終止（終止之后可以清空）測試執(zhí)行或清空當(dāng)前隊列。
c、TestCase，生態(tài)系統(tǒng)中的所有測試用例會展示在這里，可以看到它們最后一次執(zhí)行的時間和狀態(tài)（pass/fail），點擊某條case可以跳轉(zhuǎn)到該條case的所有test result。可以按狀態(tài)（pass/fail/other）篩選用例，可以勾選部分用例重新執(zhí)行、或重新執(zhí)行所有fail的case。“Reload Test Cases”主要是考慮到*.dll文件中的test case可能會在某次部署之后發(fā)生變化，需要重新加載。不過后來我修改了Jenkins里的job在每次部署之后都自動重新加載，所以這個按鈕其實沒什么用了。
d、TestSuite，包含多個fixture的集合是一個suite。勾選多個suite點擊“Run Suite”即可把這些suite中包含的fixture添加到Queue。
這里的suite是對NUnit中的Category的一個補(bǔ)充，點擊“New Suite”你可以任意選擇fixture來組成自己想要的suite：
e、TestResult，展示所有test case的運行結(jié)果，可以按test case id進(jìn)行篩選，點擊TC#這一列的id就只顯示這條case的結(jié)果。
點右邊的藍(lán)色“i”圖標(biāo)可以跳到這條結(jié)果的詳細(xì)頁面，截圖功能暫未啟用，根據(jù)RunnerMessage和RunnerStackTrace可以知道報錯的代碼位置，進(jìn)而嘗試重現(xiàn)問題。