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

沉默術士發表於2017-07-03

原文網址 : https://flycode.co/archives/140619

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

　　一、概念

　　這裡我畫了一張示意圖：

　　之所以稱之為“生態系統”，是因為建成之後需要的人為干涉很少，其餘的時間都是系統內部迴圈運作。作為自動化測試人員的你只需要提交程式碼，之後便可以在AutomationDashboard上看到執行的結果了，其餘的事情都由系統內部消化。當然，結果的分析還是需要人來完成，機器還沒有聰明到可以靈活分析出各種各樣讓case fail掉的原因。

　　我們可以把整個系統看作一個黑盒子，那麼上面的圖可以變成：

　　實際上這裡畫的人不僅限於自動化測試人員，也可以是：

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

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

　　（3）開發人員，他們也許會想通過quick regression（提交的產品程式碼被部署到測試環境之後執行的測試）知道自己剛提交的程式碼有沒有破壞系統的基本功能；

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

　　二、實現

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

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

　　1、SCM（Source Code Management）。我選的是git，可以是git伺服器（公司自己搭建了一個git server），也可以是一個bare repo（http://www.saintsjd.com/2011/01/what-is-a-bare-git-repository/）。

　　2、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.152、10.107.122.153、10.107.122.154）都在判斷範圍之內（判斷其是否有“Node”標籤，有則執行project）。

　　另外，列出的所有node我都為其加了一個“Node”標籤。

　　這樣，當我trigger “StartClassicROLATServiceOnAllNodes”之後，就會在master、10.107.122.152、10.107.122.153、10.107.122.154這4個node上同時執行“StartClassicROLATServiceOnASingleNode”。

　3、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在每次部署之後都自動重新載入，所以這個按鈕其實沒什麼用了。