集成 Jenkins 和 TestNG 實現自助式自動化測試平臺

背景介紹

在軟件業十分紅熟的今天，敏捷（Agile）開發在業界日益流行，而面臨的挑戰也日益增多，不斷變化的用戶需求、縮短的開發週期、頻繁的部署上線、複雜的產品架構和團隊組織，如何繼續保證軟件的質量是一個不能迴避的課題。

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

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

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

該平臺具備如下優勢：

• 基於成熟的測試工具。Jenkins 是目前業內最流行的快速持續集成工具之一, 其穩定的性能和豐富的擴展性, 使得不少的團隊都優先選擇它做爲項目的主要支持工具。TestNG 做爲一款強大的 Java 測試框架，其在 Junit，NUnit 的基礎上作了普遍的加強，從單元測試、功能測試到集成測試，都能提供良好的支持。這兩個工具一方面功能穩定，有大量的實際使用案例和文檔支持，另外一方面因爲其屬於主流工具，不少團隊已經有過相應的經驗，能夠大大縮短學習曲線和成本。

• 靈活地定製自動化測試。團隊成員經過登錄平臺 Web 界面，按照需求任意選擇部署在平臺上的自動化測試包，目標測試環境，測試集和測試用例。提交定製化的自動化執行請求，執行結束系統自動發郵件通知。不一樣人員的請求能夠實現並行執行。

• 全部的自動化執行歷史記錄均可以保存在平臺上。能夠經過 Web 的方式隨時查閱。

• Jenkins 支持豐富的插件，用戶能夠按照需求進行選擇安裝和配置，以實現生成執行狀態表格，自動部署/更新自動化測試包等高級功能。

---

方案設計概述

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

• 用戶權限管理，用戶可使用本身的賬號進行登錄訪問，提交請求。

• 用戶根據自身的具體需求，靈活的選擇已經部署在平臺上的自動化測試包，而且能夠對測試環境，測試集和測試用例進行定製化選擇。

• 多用戶併發請求的執行，彼此之間相互獨立，互不干擾

• 請求執行完畢後的 email 通知

• 執行狀態和歷史紀錄的查詢

• 用戶體驗良好的 Web 頁面訪問模式

針對以上的需求，咱們能夠用圖 1 來簡要說明該方案的主要功能組件以及彼此之間的聯繫。

圖 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 任務與創建在這一框架之上的自動化測試包進行鏈接，就能夠輕鬆實現用戶在頁面上選擇測試集。

平臺的實現與配置

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

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

2. 創建新用戶及配置權限

3. 爲自動化測試創建和配置新任務

1. 配置用戶輸入定製化選項

2. 配置執行報告保存

3. 配置 email 提醒

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

Jenkins 是一款成熟強大的開源軟件，對大部分主流的操做系統平臺（Linux，Windows, Mac OS）都提供支持，在其官方網站上能夠直接下載到最新的安裝包和每個平臺的安裝流程文檔。

安裝完畢以後，咱們能夠之後臺服務的形式將其啓動，這個時候咱們就能夠用瀏覽器經過 http://localhost:8080 訪問其默認主頁面進行平臺定製化配置。

圖 2.Jenkins 主頁面

初始安裝後的 Jenkins 並無默認管理員賬戶，第一次打開主頁面就能夠直接對其進行系統配置，在頁面的左端能夠經過點擊「Manage Jenkins」打開 Jenkins 系統管理界面。

圖 3.Jenkins 管理界面

咱們能夠經過「Manage Plugins」來安裝第三方插件。其中本方案建議安裝的六個插件分別是「Extended Choice Parameter plugin」，「EnvInject Plugin」，「Build User Vars Plugin」，「Build Name Setter Plugin」，「HTML Publisher Plugin」和「Email-ext plugin」。

圖 4.Jenkins 插件管理

安裝插件的方法十分簡單，在「Manage Plugins」頁面的「Available」選項卡中，勾選所須要的目標插件，點擊頁面下方的相應安裝按鈕便可。

新建用戶和配置權限

前面咱們提到 Jenkins 在初次安裝時默認並無用戶驗證的環節，全部打開主頁面的用戶都具備系統管理員權限。對於一個要在正式項目中被整個團隊所公用的測試平臺，咱們須要嚴格的創建用戶驗證和權限配置。

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

圖 5. 安全管理

保存設置以後，回到 Jenkins 主頁面，此時咱們點擊右上角 sign up 連接能夠進入建立用戶頁面，輸入新建用戶的基本信息。經過這種方式能夠爲須要使用該平臺的全部成員建立屬於他們本身的專用帳號。

圖 6. 賬號建立

新建帳號完畢以後，用專門爲管理員建立的帳號從新登錄，再次進入「Manage Jenkins ->Configure Global Security」，爲咱們剛纔建立的團隊成員帳號設置權限，同時禁用 Anonymous 的全部權限，具體方式如圖 7 所示，保存以後便可生效。

圖 7. 權限配置

爲自動化測試創建和配置新任務。當以上工做都準備完畢以後，就能夠開始在 Jenkins 平臺上爲自動化測試建立新的任務。首先在主界面的左上方點擊「New Job」, 選擇「Build a free-style software project」類型，而且提供一個合適的任務名如「ProjectA RESTAPI automation」。

圖 8. 新 Job 建立

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

首先，爲了讓自動化任務在提交請求的時候都可以接收不一樣用戶的選擇，咱們須要勾選「This build is parameterized」。在接下來的「Add Parameter」下拉菜單中，Jenkins 提供多種類型的用戶輸入，在這裏咱們選擇「Extended Choice Parameter」(這是由上文中提到的插件「Extended Choice Parameter plugin」新增出的支持類型)，同時 Jenkins 每個 Job 支持多個用戶輸入選項，而且彼此之間能夠屬於不一樣類型，管理員能夠根據項目須要進行靈活搭配。

圖 9. 參數化配置

在這裏爲了簡單起見，本文新建了兩個參數化輸入選項以說明問題。其中第一個爲單選項，提供用戶對目標測試環境的選擇，另外一個爲多選項，提供對具體測試用例的選擇。每個輸入項在配置時須要提供惟一標識的名字, 不只會顯示在輸入頁面上，同時用戶提交請求時真實的輸入將會以一樣命名的環境變量的形式傳遞給具體的執行腳本。其次對於備選項列表的配置，系統提供兩種方式。第一種是直接在「Value」項中提供全部備選項的列表，並以逗號隔開（如圖 10 中對環境選項 ENVIRONMENT 的配置），另外一種是當備選列表比較長的時候咱們能夠以文件的形式來提供（如圖 11 中對測試用例 SELECTED_TESTCASE 選項的配置）。備選列表文件的內容格式如清單 1 所示：

清單 1. SELECTED_TESTCASE 選項的備選列表文件內容

TestCase = Testcase1,Testcase2,\
Testcase3

備選選項列表以文件形式提供的好處之一是咱們能夠本身設計腳原本自動生成和更新這個列表，這樣當自動化測試包有更新的時候咱們並不須要每次都手動更新這些配置文件。同時文件的更新能夠即時生效，這一點十分重要。

圖 10. 單選項配置

圖 11. 多選項配置

本例所示參數化配置以後，用戶在提交請求時，系統將會顯示以下頁面以提示用戶進行選擇，用戶能夠根據須要自由的選擇測試的目標環境和測試用例集合。

圖 12. 參數化界面

其次，若是該 Job 須要支持多人提交請求的並行執行（前提是 Job 執行的內容自己不會由於並行執行產生問題，好比每一個請求都須要獨佔某個僅有的目標資源等），咱們能夠勾選「Execute concurrent builds if necessary」，同時咱們須要考慮 Jenkins 所在服務器自己的配置和負荷能力。

圖 13. 並行配置

同時，每個來自不一樣用戶的請求在系統中都會產生惟一的 ID 和時間戳以標示，可是這些信息並不足以讓咱們瞭解該請求的具體內容和發起人，可讀性是不好的。爲了更方便閱讀和管理過往的記錄，在此能夠爲每個請求動態生成包含多種可識別信息的名字。咱們利用「EnvInject Plugin」，「Build User Vars Plugin」和「Build Name Setter Plugin」三個插件以實現爲不一樣請求定製如圖 14 所示的名字。(Jenkins 自身提供部分系統環境變量如 BUILD_NUMBER, 以前爲選擇目標測試環境而配置的用戶輸入提供了環境變量 ENVIRONMENT，「Build User Vars Plugin」插件爲咱們提供了請求發起人的用戶名信息 BUILD_USER)

圖 14. 請求命名 ID 的配置

經過以上的配置，不一樣用戶請求的歷史記錄將更加易於查詢和管理，如圖 15 所示

圖 15. 歷史記錄

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

圖 16.Build Step

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

清單 2. TestNG 測試套件文件 projectARestAPISuite.xml

<suite name="Project A RestAPI automation suite"> 
 <test name="Testcase1"> 
 <classes> 
 <class name="tests.Testcase1" /> 
 </classes> 
</test> 
<test name="Testcase2"> 
 <classes> 
 <class name="tests.Testcase2" />
 </classes> 
</test> 
<test name="Testcase3"> 
 <classes> 
 <class name="tests.Testcase3" /> 
 </classes> 
</test> 
</suite>

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

-testname 接受以逗號隔開的 test name 列表，腳本運行時 suite xml 中只有-testname 選項列表裏指定了的 test 纔會被執行。而上文當中用戶在提交請求時在定製頁面上實際選擇（多選）的測試集合偏偏會以逗號隔開的方式傳遞給 SELECTED_TESTCASE 環境變量，咱們正是經過這種方式達到用戶自由選擇 case 執行的目的。

-d 指定 TestNG 默認 report 生成的路徑。由於不一樣用戶可能存在並行執行的請求，爲了防止衝突，每個請求的 report 會生成在以環境變量 BUILD_ID 命名的目錄下，BUILD_ID 能夠惟一標示不一樣的請求。

而前面的另外一個用戶輸入 ENVIRONMENT 也能夠以環境變量的形式被自動化腳本所讀取，根據用戶的不一樣輸入作出不一樣的響應。

圖 17.Build 命令

-testname 只是 TestNG 支持定製化選擇的其中一個選項，除此以外還支持包括-groups，-methods，-testclass 等多種選擇方式，用戶能夠根據項目的須要靈活使用，具體方法能夠參照 TestNG 的官方幫助文檔。

腳本執行完畢以後，接下來就須要歸檔生成的測試報告。這裏採用了插件「HTML Publisher Plugin」新增的配置選項。首先在「Add post-build action」中選擇「Publish HTML reports」，指定每個請求所生成的 HTML 報告的路徑和文件名, 勾選「Keep past HTML reports」, 這樣就能夠在歷史記錄的快捷菜單中輕鬆的查詢過往請求的執行報告了。

圖 18. 報告發布

圖 19. 報告路徑和配置

圖 20. 報告查詢

最後，由於該平臺是提供給整個團隊使用的公共自助式平臺，因此每個請求執行結束後咱們都但願請求發起者能夠收到執行完成的 email 通知，這裏咱們利用「Email-ext plugin」新增的配置選項，在「Add post-build action」中選擇「Editable Email Notification」. 該插件提供豐富的 email 配置，能夠利用環境變量定製 email 通知的主題，正文，添加附件等等，在高級選項中能夠添加「Trigger」。固然爲了郵件能夠成功的發出，還須要在「Manage Jenkins ->Configure System」中的「Jenkins Location」中爲系統郵件配置一個默認郵箱地址，以及在「E-mail Notification」中配置一個有效的 SMTP server 地址。

圖 21.Email 通知配置

圖 22. 系統發件人 Email 地址配置

圖 23.SMTP 配置

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

圖 24. 協做模式

結論

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