內建 Jenkins 和 TestNG 實作自助式自動化測試平台

在軟體業十分成熟的今天，靈活（Agile）開發在業界日益流行，而面臨的挑戰也日益增多，不斷變化的使用者需求、縮短的開發周期、頻繁的部署上線、複雜的産品架構和團隊組織，如何繼續保證軟體的品質是一個不能回避的課題。

許多企業級規模的項目常常按照功能子產品将龐大的團隊分為多個獨立的 Scrum 團隊。在這種情況下，每個 Scrum 團隊各自負責其所屬功能子產品的開發和測試。在 Scrum 團隊中各種角色在不同的時間點有針對性不同的測試需求。其次，Build 部署以及測試頻率大幅增加。測試類型和階段也更加細化。

而現有的自動化測試，常常由獨立的自動化測試團隊來執行和維護。其他的 Scrum 團隊成員除非十分了解自動化測試包的細節，否則無法按照自身多類型的測試需求來執行自動化腳本。并且有些項目自動化測試包涵蓋了成百上千的測試用例，僅僅因為需要驗證某個子產品或某幾個功能點是否成功而執行整個測試包不僅費時且沒有必要。

本文針對以上涉及的問題，提出以下的解決方案：利用 Jenkins 和 TestNG 搭建“自助式”自動化測試平台，充分利用了 Jenkins 成熟的平台及其插件, 以及 TestNG 對選擇測試用例的内在支援。

該平台具有以下優點：

基于成熟的測試工具。Jenkins 是目前業内最流行的快速持續內建工具之一, 其穩定的性能和豐富的擴充性, 使得很多的團隊都優先選擇它作為項目的主要支援工具。TestNG 作為一款強大的 Java 測試架構，其在 Junit，NUnit 的基礎上做了廣泛的增強，從單元測試、功能測試到內建測試，都能提供良好的支援。這兩個工具一方面功能穩定，有大量的實際使用案例和文檔支援，另一方面由于其屬于主流工具，很多團隊已經有過相應的經驗，可以大大縮短學習曲線和成本。

靈活地定制自動化測試。團隊成員通過登陸平台 Web 界面，按照需求任意選擇部署在平台上的自動化測試包，目标測試環境，測試集和測試用例。送出定制化的自動化執行請求，執行結束系統自動發郵件通知。不同人員的請求可以實作并行執行。

所有的自動化執行曆史記錄都可以儲存在平台上。可以通過 Web 的方式随時查閱。

Jenkins 支援豐富的插件，使用者可以按照需求進行選擇安裝和配置，以實作生成執行狀态表格，自動部署/更新自動化測試包等進階功能。

本文将使用一個簡化後的“自助式”自動化測試應用場景以介紹本方案的核心設計思想。首先列舉出該平台需要滿足的各項需求：

使用者權限管理，使用者可以使用自己的帳号進行登陸通路，送出請求。

使用者根據自身的具體需求，靈活的選擇已經部署在平台上的自動化測試包，并且可以對測試環境，測試集和測試用例進行定制化選擇。

多使用者并發請求的執行，彼此之間互相獨立，互不幹擾

請求執行完畢後的 email 通知

執行狀态和曆史紀錄的查詢

使用者體驗良好的 Web 頁面通路模式

針對以上的需求，我們可以用圖 1 來簡要說明該方案的主要功能元件以及彼此之間的聯系。

Web 前端：Jenkins 平台自身提供一套統一标準的 web 界面，使用者可以根據需求通過其完成各種系統配置，任務送出，查詢等工作。

使用者登入與權限控制：Jenkins 平台預設支援若幹種使用者驗證機制，比如 LDAP, Jenkins own database, servlet container authenticate 等等，也可以通過其它插件實作更加複雜的驗證。本文将采用最簡單的 Jenkins own database 來管理帳戶的權限。

任務請求定制化子產品：一般來說，Jenkins 大部分情況下隻需要完成預定義執行内容的任務。是以在參數定制化請求方面隻具備最基本的支援。為了滿足更好的“自助式”的使用者體驗和需求，實作預定義任務對不同使用者需求的靈活響應，我們在還需要借助一款 Jenkins 插件“Extended Choice Parameter plugin”的輔助。利用該插件，使用者可以在送出請求時在頁面上輸入多選式參數，這些動态輸入将以環境變量的形式傳遞給執行子產品影響最終請求的行為。

任務送出與執行子產品：Jenkins 支援穩定的任務管理機制，管理者可以通過配置使同一個任務支援并發響應多個請求，彼此之間獨立且互不幹擾。

任務狀态與曆史紀錄查詢：對于任務請求的狀态資訊跟蹤，Jenkins 預設隻支援控制台輸出的監控，而且每一次請求記錄，Jenkins 隻提供一個數字 ID 和時間戳進行辨別。對于一個多使用者的自助式平台這是遠遠不夠的。我們利用插件“HTML Publisher Plugin”，儲存請求生成的 html 格式的運作報告。這樣可以在頁面上對任意曆史請求的執行紀錄和報告進行查詢和檢索；同時利用“EnvInject Plugin”，“Build User Vars Plugin”和“Build Name Setter Plugin”為每一次請求動态生成包含使用者姓名等多方面資訊的 ID 以區分，大大友善資訊的管理和測試結果資料的追溯。

Email 提醒：Jenkins 預設隻支援最基本的 email 通知機制。我們使用插件“Email-ext plugin”進行擴充，以支援更加強大的通知機制，靈活定制 email 标題和内容, 添加附件，定制收件人名單等。

TestNG 自動化測試架構：TestNG 是一款強大的自動化測試架構，适用于 Unit 測試，功能測試，內建測試等多類型的自動化測試。其擁有一整套成熟的 API 和 Annotation, 支援資料驅動，測試周期和依賴控制，多線程執行等一系列特性。本方案采用 TestNG 還因為其具有對測試腳本集進行靈活選擇的特性。TestNG 利用 xml 檔案來組織測試腳本集，在運作的時候，我們可以通過參數指定需要運作的腳本，把 Jenkins 任務與建立在這一架構之上的自動化測試包進行連接配接，就可以輕松實作使用者在頁面上選擇測試集。

本章介紹該平台具體的實作和配置流程，主要包含以下步驟：

安裝 Jenkins 及必要的第三方插件

建立新使用者及配置權限

為自動化測試建立和配置新任務

配置使用者輸入定制化選項

配置執行報告儲存

配置 email 提醒

Jenkins 及相關插件的安裝 (本文以 jenkins-ver.1.524 為例)

Jenkins 是一款成熟強大的開源軟體，對大部分主流的作業系統平台（Linux，Windows, Mac OS）都提供支援，在其官方網站上可以直接下載下傳到最新的安裝包和每一個平台的安裝流程文檔。

安裝完畢之後，我們可以以背景服務的形式将其啟動，這個時候我們就可以用浏覽器通過 http://localhost:8080 通路其預設首頁面進行平台定制化配置。

初始安裝後的 Jenkins 并沒有預設管理者帳戶，第一次打開首頁面就可以直接對其進行系統配置，在頁面的左端可以通過點選“Manage Jenkins”打開 Jenkins 系統管理界面。

我們可以通過“Manage Plugins”來安裝第三方插件。其中本方案建議安裝的六個插件分别是“Extended Choice Parameter plugin”，“EnvInject Plugin”，“Build User Vars Plugin”，“Build Name Setter Plugin”，“HTML Publisher Plugin”和“Email-ext plugin”。

安裝插件的方法十分簡單，在“Manage Plugins”頁面的“Available”頁籤中，勾選所需要的目标插件，點選頁面下方的相應安裝按鈕即可。

建立使用者和配置權限

前面我們提到 Jenkins 在初次安裝時預設并沒有使用者驗證的環節，所有打開首頁面的使用者都具有系統管理者權限。對于一個要在正式項目中被整個團隊所公用的測試平台，我們需要嚴格的建立使用者驗證和權限配置。

首先在“Manage Jenkins ->Configure Global Security”頁面中勾選“Enable security”。頁面重新整理之後在“Security Realm”項選擇“Jenkins' own user database”,“Authorization”項選擇“Matrix-based security”，同時暫時賦給 Anonymous“Overall Admin”權限. 每一個項目也可以根據自身的需要選擇其它的認證方式。

儲存設定之後，回到 Jenkins 首頁面，此時我們點選右上角 sign up 連結可以進入建立使用者頁面，輸入建立使用者的基本資訊。通過這種方式可以為需要使用該平台的所有成員建立屬于他們自己的專用賬号。

建立賬号完畢之後，用專門為管理者建立的賬号重新登陸，再次進入“Manage Jenkins ->Configure Global Security”，為我們剛才建立的團隊成員賬号設定權限，同時禁用 Anonymous 的所有權限，具體方式如圖 7 所示，儲存之後即可生效。

為自動化測試建立和配置新任務。當以上工作都準備完畢之後，就可以開始在 Jenkins 平台上為自動化測試建立新的任務。首先在主界面的左上方點選“New Job”, 選擇“Build a free-style software project”類型，并且提供一個合适的任務名如“ProjectA RESTAPI automation”。

點選 OK 之後就可以開始對 Job 内容進行定義和配置。傳統的 Jenkins 平台應用主要集中在持續內建（CI）領域，是以在配置頁面提供了大量的關于源代碼擷取，Build 建立等傳統配置選項。而本文從全新的角度利用 Jenkins 平台的特性搭建自助式平台，基于篇幅所限，這裡隻介紹和本方案相關的主要配置項。

首先，為了讓自動化任務在送出請求的時候都能夠接收不同使用者的選擇，我們需要勾選“This build is parameterized”。在接下來的“Add Parameter”下拉菜單中，Jenkins 提供多種類型的使用者輸入，在這裡我們選擇“Extended Choice Parameter”(這是由上文中提到的插件“Extended Choice Parameter plugin”新增出的支援類型)，同時 Jenkins 每一個 Job 支援多個使用者輸入選項，并且彼此之間可以屬于不同類型，管理者可以根據項目需要進行靈活搭配。

在這裡為了簡單起見，本文建立了兩個參數化輸入選項以說明問題。其中第一個為單選項，提供使用者對目标測試環境的選擇，另一個為多選項，提供對具體測試用例的選擇。每一個輸入項在配置時需要提供唯一辨別的名字, 不僅會顯示在輸入頁面上，同時使用者送出請求時真實的輸入将會以同樣命名的環境變量的形式傳遞給具體的執行腳本。其次對于備選項清單的配置，系統提供兩種方式。第一種是直接在“Value”項中提供所有備選項的清單，并以逗号隔開（如圖 10 中對環境選項 ENVIRONMENT 的配置），另一種是當備選清單比較長的時候我們可以以檔案的形式來提供（如圖 11 中對測試用例 SELECTED_TESTCASE 選項的配置）。備選清單檔案的内容格式如清單 1 所示：

1

2

<code>TestCase = Testcase1,Testcase2,\</code>

<code>Testcase3</code>

備選選項清單以檔案形式提供的好處之一是我們可以自己設計腳本來自動生成和更新這個清單，這樣當自動化測試包有更新的時候我們并不需要每次都手動更新這些配置檔案。同時檔案的更新可以即時生效，這一點十分重要。

本例所示參數化配置之後，使用者在送出請求時，系統将會顯示如下頁面以提示使用者進行選擇，使用者可以根據需要自由的選擇測試的目标環境和測試用例集合。

其次，如果該 Job 需要支援多人送出請求的并行執行（前提是 Job 執行的内容本身不會因為并行執行産生問題，比如每個請求都需要獨占某個僅有的目标資源等），我們可以勾選“Execute concurrent builds if necessary”，同時我們需要考慮 Jenkins 所在伺服器本身的配置和負荷能力。

同時，每一個來自不同使用者的請求在系統中都會産生唯一的 ID 和時間戳以标示，但是這些資訊并不足以讓我們了解該請求的具體内容和發起人，可讀性是很差的。為了更友善閱讀和管理過往的記錄，在此可以為每一個請求動态生成包含多種可識别資訊的名字。我們利用“EnvInject Plugin”，“Build User Vars Plugin”和“Build Name Setter Plugin”三個插件以實作為不同請求定制如圖 14 所示的名字。(Jenkins 自身提供部分系統環境變量如 BUILD_NUMBER, 之前為選擇目标測試環境而配置的使用者輸入提供了環境變量 ENVIRONMENT，“Build User Vars Plugin”插件為我們提供了請求發起人的使用者名資訊 BUILD_USER)

通過以上的配置，不同使用者請求的曆史記錄将更加易于查詢和管理，如圖 15 所示

緊接着就是通過配置“Build Step”來定義每次請求具體的執行内容，Jenkins 提供 Windows batch, shell, Ant, Maven 四種方式調用外部的指令和腳本

我們将在 build step 的指令中調用基于 TestNG 架構的自動化測試包。TestNG 是利用一種特殊格式的 XML 檔案來定義測試用例集合的，稱之為測試套件檔案。假定我們項目的自動化測試包有一個包含三個 test 的測試套件 projectARestAPISuite.xml，如清單 2 所示，它所包含 test 的名字（test name 屬性）分别為 Testcase1,Testcase2,Testcase3。

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

<code>&lt;</code><code>suite</code> <code>name</code><code>=</code><code>"Project A RestAPI automation suite"</code><code>&gt;</code>

<code> </code><code>&lt;</code><code>test</code> <code>name</code><code>=</code><code>"Testcase1"</code><code>&gt;</code>

<code> </code><code>&lt;</code><code>classes</code><code>&gt;</code>

<code> </code><code>&lt;</code><code>class</code> <code>name</code><code>=</code><code>"tests.Testcase1"</code> <code>/&gt;</code>

<code> </code><code>&lt;/</code><code>classes</code><code>&gt;</code>

<code>&lt;/</code><code>test</code><code>&gt;</code>

<code>&lt;</code><code>test</code> <code>name</code><code>=</code><code>"Testcase2"</code><code>&gt;</code>

<code> </code><code>&lt;</code><code>class</code> <code>name</code><code>=</code><code>"tests.Testcase2"</code> <code>/&gt;</code>

<code>&lt;</code><code>test</code> <code>name</code><code>=</code><code>"Testcase3"</code><code>&gt;</code>

<code> </code><code>&lt;</code><code>class</code> <code>name</code><code>=</code><code>"tests.Testcase3"</code> <code>/&gt;</code>

<code>&lt;/</code><code>suite</code><code>&gt;</code>

那麼就可以用下面的指令集來定義 build step, 在此處巧妙地利用了 TestNG 啟動指令的兩個重要選項：

-testname 接受以逗号隔開的 test name 清單，腳本運作時 suite xml 中隻有-testname 選項清單裡指定了的 test 才會被執行。而上文當中使用者在送出請求時在定制頁面上實際選擇（多選）的測試集合恰恰會以逗号隔開的方式傳遞給 SELECTED_TESTCASE 環境變量，我們正是通過這種方式達到使用者自由選擇 case 執行的目的。

-d 指定 TestNG 預設 report 生成的路徑。因為不同使用者可能存在并行執行的請求，為了防止沖突，每一個請求的 report 會生成在以環境變量 BUILD_ID 命名的目錄下，BUILD_ID 可以唯一标示不同的請求。

而前面的另一個使用者輸入 ENVIRONMENT 也可以以環境變量的形式被自動化腳本所讀取，根據使用者的不同輸入做出不同的響應。

-testname 隻是 TestNG 支援定制化選擇的其中一個選項，除此之外還支援包括-groups，-methods，-testclass 等多種選擇方式，使用者可以根據項目的需要靈活使用，具體方法可以參照 TestNG 的官方幫助文檔。

腳本執行完畢之後，接下來就需要歸檔生成的測試報告。這裡采用了插件“HTML Publisher Plugin”新增的配置選項。首先在“Add post-build action”中選擇“Publish HTML reports”，指定每一個請求所生成的 HTML 報告的路徑和檔案名, 勾選“Keep past HTML reports”, 這樣就可以在曆史記錄的快捷菜單中輕松的查詢過往請求的執行報告了。

最後，因為該平台是提供給整個團隊使用的公共自助式平台，是以每一個請求執行結束後我們都希望請求發起者可以收到執行完成的 email 通知，這裡我們利用“Email-ext plugin”新增的配置選項，在“Add post-build action”中選擇“Editable Email Notification”. 該插件提供豐富的 email 配置，可以利用環境變量定制 email 通知的主題，正文，添加附件等等，在進階選項中可以添加“Trigger”。當然為了郵件可以成功的發出，還需要在“Manage Jenkins -&gt;Configure System”中的“Jenkins Location”中為系統郵件配置一個預設郵箱位址，以及在“E-mail Notification”中配置一個有效的 SMTP server 位址。

按照本文所介紹的内容，我們可以搭建起一個自助式的自動化平台，同時不僅僅局限于自動化測試的需要，項目團隊所開發的其他自動化工具包，部署，監測，生成報告等腳本工具都可以按同樣的方式部署在該平台上，讓所有團隊的成員都能夠自由的共享使用，也更加便于管理和維護。圖 24 用來表示這種全新的團隊協作模式：

本文簡要介紹了如何使用 Jenkins 和 TestNG 搭建一個自助式的自動化測試平台。這個平台可以讓項目團隊成員更加靈活和有效的使用自動化工具包完成各項工作，提高工作效率，降低管理和維護成本。