面向服務器集群的自動化測試監控平臺的研究和實現

汪 旺，夏 鳳，陳 哲，黃志球

(1.南京航空航天大學計算機科學與技術學院，江蘇 南京 210016;2.阿里巴巴(中國)網絡技術有限公司，浙江 杭州 310099)

0 引言

隨著測試流程的不斷規范以及軟件測試技術［1］的進一步細化，軟件測試自動化［2，18，20］已經日益成為一種不可忽視的技術。能否借助該技術以及如何借助它規范測試流程，提高特定測試活動的效率，是一個需要研究的重要問題。

軟件自動化測試使用機器自動進行測試執行［3］和測試結果判斷，其特點是在測試中部分使用了程序或是機器的能力，目的在于減少資源消耗、擴大測試范圍和充分利用機器與程序的能力。軟件自動化測試技術的出現顯著提高了測試工作［4］的效率。

目前，軟件測試自動化［5］的研究領域主要集中在軟件測試流程的自動化管理［6］以及動態測試［7］的自動化(如單元測試、功能測試以及性能測試方面)。與手工測試相比，測試自動化的優勢明顯。首先，自動化測試可以提高測試效率，測試人員更加專注于新的測試模塊的建立和開發，從而提高測試覆蓋率;其次，自動化測試更便于測試資產的數字化管理，在整個測試生命周期內可以復用測試資產，這個特點在功能測試和回歸測試中尤其具有意義;此外，測試流程自動化管理可以使機構的測試活動開展更加過程化。

但是在服務器集群的環境下，自動化測試［8］相對脆弱，維護比較困難。以阿里巴巴旗下網站的開發測試平臺為例，目前的自動化測試環境管理存在諸多問題，嚴重制約了自動化測試效率的提升。因此，如何有效地對自動化測試進行監控管理，是一個重要而未被很好解決的問題。研究面向自動化測試的服務器管理監控平臺能夠加強對大規模集群測試服務器的統一管理和監控，提高發現測試服務器問題的及時性和處理效率，增加出現問題后的自我恢復能力，從而釋放了大量的人力資源，大幅提升了工作效率。

本文基于控制系統理論［19，21］，結合軟件自動化測試的需求背景和Web開發框架［9］的原理及相關技術，介紹阿里巴巴中文站的自動化研發協作平臺，在分析總結現有工作的基礎上，給出面向服務器集群的自動化測試監控平臺的模塊設計和實現，最后指出該平臺目前存在的問題，并對以后的研究工作進行展望。

1 阿里巴巴自動化研發協作平臺及測試環境

AONE是阿里巴巴自動化研發協作平臺，系統地管理整個研發過程中的各項活動。在該平臺上，項目經理創建項目并分配資源，開發人員提交代碼、編譯審計及打包，完成后公司內部即時聊天工具阿里旺旺會發消息提醒測試人員接手測試，測試后進行發布。倚天測試環境平臺是測試服務器管理與申請平臺，通過它可以申請需要的測試服務器。而通過守護神平臺則可以執行自動化腳本并生成測試質量報告。

AONE上應用編譯通過后會生成一個新的RPM(Red Hat Package Manager)包，是Red Hat的軟件包管理。RPM包里面包含可執行的二進制程序，該程序和Windows的軟件包中的.exe文件類似，是可執行的。包中還包括程序運行時所需要的文件，并放到FTP(File Transfer Protocol)服務器上，根據AONE發出的消息，這個消息包括應用名稱、發布需求的ID、生成的RPM包地址等，會在倚天測試環境平臺上申請測試服務器，搭建和部署相應的測試環境，搭建完成后，就可以在守護神平臺上請求執行自動化腳本，直至完成。

運行自動化腳本［10］之前首先要部署好服務器，即在測試機上搭建測試環境。服務器部署方法經歷從手動部署到一鍵部署腳本，再到watchdog監控程序的過程。

手動部署要求用戶手動輸入一系列的命令。首先要獲取應用RPM包的FTP地址，然后申請一套測試服務器，并登錄測試服務器，獲取RPM包和最新的配置文件antx.properties，該配置文件存儲了測試服務器所需的配置項，將配置項注入RPM包，最后執行啟動操作。這種方法比較耗時費力，效率低下。

一鍵部署腳本可以在Linux測試服務器下自動獲取應用的分支或RPM包，獲取最新的antx.properties(也可以選擇不更新)，可以一鍵自動化部署和重啟。但也存在一些缺點，比如不支持中文提示，不檢查應用名正確性，也不能夠正確處理某些異常情況。

watchdog監控程序是一款自動化測試服務器管理程序，通過HTTP請求來完成各種功能，但是目前這僅僅是一個維持基本功能的版本，有許多可以優化的地方。它還沒有可視化的UI界面，如更新RPM包地址需要SQL語句來完成，除此之外，添加測試環境或更改配置都需要修改代碼，重新打包來完成，不夠方便。

目前阿里巴巴三大測試的公共環境維護狀況如下:

1)RPM包地址由watchdog監控程序更新;

2)自動化環境由watchdog監控程序根據AONE發布情況部署;

3)公共環境由one-click.sh(一鍵部署腳本)定時更新，依賴watchdog監控程序數據庫;

4)性能環境手動管理，不定期更新;

5)機器由dragoon監控，它是阿里巴巴自主研發的高性能、大并發的通用監控系統，主要是系統監控，包括各種操作系統，如 Linux、Solaris、Aix、Windows。它由運維中心進行運營管理，只能監控環境的性能指標和系統關鍵信息。

分析目前的測試環境，發現存在性能測試環境不能實現自動更新，主干RPM包管理機制不夠透明等問題。今后AONE實施自主發布，自動化環境需要實現大規模測試服務器群的部署，watchdog監控程序在測試機上搭建測試環境已經不能滿足需求，因此亟待對已有的服務器部署功能進行擴展，引入面向服務器集群的自動化測試監控平臺，對自動化環境、公共環境、性能環境進行統一的管理和監控，并實現一定的環境自我恢復能力。

2 面向服務器集群的自動化測試監控平臺設計與實現

2.1 系統整體設計

面向服務器集群的自動化測試［11］監控平臺主要有2方面的功能，即部署測試環境和監控測試服務器。開發人員提交測試后，測試人員需要在大規模測試服務器群上安裝開發提供的RPM包，即部署測試環境，然后才能驗證所提交代碼的正確性。用戶在自己的計算機上通過瀏覽器訪問該測試監控平臺，進行申請測試服務器和部署環境等一系列操作。平臺服務器收到命令后會在相應的測試服務器上部署環境，并返回部署狀態等監控信息，從而使用戶通過瀏覽器就可以監控和查看測試服務器的狀態，系統功能如圖1所示。

圖1 系統功能示意圖

AONE上應用編譯通過后會生成一個新的RPM包并放到FTP服務器上，然后AONE會觸發部署操作。部署控制模塊在相應的測試服務器傳送和安裝Agent軟件。Agent的信號處理器收到部署環境的信號，就會調用one-click.sh腳本進行環境部署。該腳本在每個執行模塊運行到最后(成功或失敗)時，返回部署狀態和相關消息。部署狀態(成功、失敗或超時)會通過Agent的狀態提取器存儲在緩存中。環境監控模塊則會獲取該狀態，傳達給告警中心。如果部署失敗，監控模塊會告訴部署控制模塊進行重置。其中部署控制模塊是通過部署分發模塊來分配部署工作，該模塊包括一個應用部署信息查詢列表，會周期性進行刷新。

部署測試環境時，首先會有調度中心按序對每一個環境生成部署線程，其次通過部署計劃表查詢依賴順序，監聽前置依賴的就緒狀態，然后線程會給Agent下達部署命令，Agent會及時將部署狀態和消息反饋到調度中心，從而更新部署計劃列表中的環境部署狀態。環境部署模塊設計包括分發環境部署計劃、生成臨時部署計劃、應用依賴關系管理、部署計劃列表和配置部署計劃設置。

環境監控模塊有查看環境監控信息、配置環境監控設置、環境監控調度和環境監控查詢遠程服務4個部分。

2.2 難點和解決方案

2.2.1 環境監控調度

環境監控調度是環境監控模塊在獲取部署狀態后傳達給告警中心，如果部署失敗，監控模塊會告訴部署控制模塊進行重置的過程。

在環境監控調度中，新建或修改環境的健康度檢查配置并確認保存時，監聽服務立即被觸發。觸發監聽服務的過程如圖2所示。

圖2 激發監聽服務的過程圖

圖2中部署狀態是指環境部署計劃中的部署狀態正處于大于等于“安裝進行中”，小于“啟動失敗”、“啟動成功”或“啟動超時”的中間狀態。

觸發以后，監聽器會給Agent發送健康檢查命令。Agent首先解析JSON(JavaScript Object Notation，一種輕量級的數據交換格式)，解析檢查內容，逐個執行檢查內容中的command內容。然后，如果是進程檢查，直接組裝檢查結果，并發送到Redis(一個key-value存儲系統);如果是URL檢查，請求URL并對返回內容進行校驗，將校驗結果發送到Redis;如果是Service檢查，則直接執行檢查命令啟動Service檢查程序，但要將監控系統中心發送過來的JSON參數追加在命令后面，由Service檢查程序組裝檢查結果并發送到Redis。這里假設是Service檢查。

接下來，Agent會周期性地調用Service檢查。對于用戶自定義的Service檢查，只要繼承AbstractServiceHealthChecker類，然后實現setRedisHost和check方法。打包成jar包后連二方庫(即所引用的公司內部其他項目的代碼包)一起上傳到SVN(Subversion，是一個免費的、開放源碼的版本控制系統)。圖3是Service檢查定制框類類圖［7］。

圖3 Service檢查定制框類

Service檢查完，將檢查結果存入Redis。監聽器維護一個定時器，它會啟動一個定時任務用于周期性提取存儲在Redis中的環境檢查結果數據，并將結果存入數據庫，如果部署失敗，會觸發失敗重新部署，環境監控調度如圖4所示。

圖4 環境監控調度總體示意圖

2.2.2 應用搭建算法

應用搭建是指部署一套環境時可能需要搭建幾個應用，而應用之間存在一定的依賴關系，一旦一個應用搭建不成功，就會影響到對它依賴的其他應用。

應用依賴搭建算法描述如圖5所示。

圖5 應用依賴搭建方案

該算法采用的是并行搭建，運用按層級關系搭建應用的思想，避免了絕對的串行搭建會影響環境部署效率的問題。

每個應用搭建完成后發送觸發信息?？偟拇罱〞r間為有向圖中最長路徑上每個應用的搭建時間之和。每一組搭建應用過程采用設定超時時間方式。

應用依賴搭建算法中，會對一個有向無環圖(Directed Acyclic Graph，DAG)進行拓撲排序［8］(Topological Sort)。拓撲排序是將有向無環圖G中所有頂點排成一個線性序列，使得對圖中任意一對頂點u和v，若＜u，v＞∈E(G)，則u在線性序列中出現在v之前。

拓撲排序算法的每一步均是輸出當前無后繼(即出度為0)的結點。對于一個DAG，按此方法輸出的序列是逆拓撲次序。因此設置一個棧(或向量)T來保存輸出的結點序列，即可得到拓撲序列。若T是棧，則每當輸出結點時，只需做入棧操作，排序完成時將棧中結點依次出棧即可得拓撲序列。若T是向量，則將輸出的結點從T［n-1］開始依次從后往前存放，即可保證T中存儲的結點是拓撲序列。

拓撲排序主要代碼如下:

函數topo()調用函數noSuccessors()，如果返回值為-1，表明該有向圖有環，給出錯誤提示;否則，把返回的沒有后繼的結點保存到數組sortedArray中，并調用函數deleteVertex(int delVert)刪去該結點，并刪去從該結點發出的全部有向邊。

重復以上步驟，直到有向圖中不存在沒有后繼的結點為止。最后輸出拓撲序列。

其中，函數 noSuccessors()和函數 deleteVertex(int delVert)代碼如下:

函數noSuccessors()用于返回沒有后繼的結點。對有向圖中的每個結點檢查從該結點出發是否有邊，如果從某結點出發沒有邊，表明該結點沒有后繼，函數返回該結點;如果檢查完有向圖發現圖中每個結點都有邊，表明該有向圖中有環，函數返回-1。

函數deleteVertex(int delVert)用于刪去有向無環圖中沒有后繼的結點，并刪去從該結點發出的全部有向邊。

3 結束語

隨著測試流程的不斷規范以及軟件測試技術的進一步細化，軟件測試自動化［12］日益成為一種不可忽視的技術。但目前自動化測試相對比較脆弱，維護起來比較困難，如何有效地對自動化測試進行監控管理［22-25］，是一個重要問題。

本文結合軟件自動化測試［13］的需求背景，對自動化測試［14］環境的服務器管理監控進行了初步的研究分析。筆者基于Web開發框架，在Eclipse平臺［15］上，開發出了一個面向自動化環境的服務器管理監控平臺。該平臺主要有部署和監控測試環境2大功能，加強了對測試服務器的統一管理和監控。

該平臺在阿里巴巴的實踐證明，它可以提高發現大規模集群測試服務器問題的及時性和處理效率，增加出現問題后的自我恢復能力，大幅提升測試［16］效率，并為進一步設計有效的自動化管理方法提供了基礎。

目前所做的工作中仍存在許多不足之處，在下一步的工作中，將對系統的高級功能，比如環境出錯自動重啟、按部署計劃定時搭建環境、全部重搭自化［17］環境等進行充分的驗證。

［1］Myers G J，Sandler C，Badgett T.The Art of Software Testing［M］.John Wiley＆ Sons，2011.

［2］李鵬，楊永艷.基于業務數據的大型企業SOA測試方法［J］.計算機工程，2012，38(4):60-62.

［3］宋波，張忠能.基于系統功能測試的軟件自動化測試可行性分析［J］.計算機應用與軟件，2006，22(12):31-33.

［4］顏炯，王戟，陳火旺.基于模型的軟件測試綜述［J］.計算機科學，2004，31(2):184-187.

［5］單錦輝，姜瑛，孫萍.軟件測試研究進展［J］.北京大學學報(自然科學版)，2005，41(1):134-145.

［6］楊文，黃文濤.通用自動測試系統的軟件設計與實現［J］.工業控制計算機，2012(1):79-80.

［7］王先平，齊逸.面向服務計算中Web服務動態綁定模型研究［J］.計算機工程與設計，2010(19):4165-4167.

［8］李瑋.軟件自動化測試混合框架的研究與實現［J］.北京交通大學學報，2007(4):27-31.

［9］楊寧，劉丹軍.基于JFinal框架的Java Web應用開發研究［J］.電腦知識與技術，2014(7):74-76.

［10］史永莉，陳元琰，羅曉曙，等.軟件自動化測試方案的效益分析［J］.微計算機信息，2010(6):218-219.

［11］汪邦慧，徐從來.軟件自動化測試框架設計與實踐［J］.衛星電視與寬帶多媒體，2013(11):57-61.

［12］張坤.基于業務流程驅動自動化測試研究與實現［J］.計算機光盤軟件與應用，2013(5):268-269.

［13］馬春燕，朱怡安，陸偉.Web服務自動化測試技術［J］.計算機科學，2012，39(2):162-169.

［14］邢翠芳，杜晶，趙海冰.軟件自動化測試技術研究［J］.電腦知識與技術，2013(12):61-62.

［15］Eckel B.Thinking in Java［M］.3rd Edition.Prentice Hall，2013.

［16］牟永敏，姜宇，張志華.軟件自動化測試中熱點路徑的研究［J］.計算機工程與科學，2011，33(6):79-83.

［17］聶長海.關于軟件測試的幾點思考［J］.計算機科學，2011，38(2):1-3.

［18］Chen Zhe，Gu Yi，Huang Zhiqiu，et al.Model Checking Aircraft Controller Software:A Case Study［DB/OL］.http://onlinelibrary.wiley.com/doi/10.1002/spe.2242/abstract，2013-11-21.

［19］Chen Zhe.Control Systems on Automata and Grammars［J/OL］. http://comjnl.oxfordjournals.org/content/early/2013/10/25/comjnl.bxt125，2013-10-25.

［20］Chen Zhe，Zhang Daqiang，Zhu Rongbo，et al.A review of automated formal verification of Ad Hoc routing protocols for wireless sensor networks［J］.Sensor Letters，2013，11(5):752-764.

［21］Chen Zhe.On the generative power of ω-grammars and ωautomata［J］.Fundamenta Informaticae，2011，111(2):119-145.

［22］Chen Zhe，Gilles Motet.Towards better support for the evolution of safety requirements via the model monitoring approach［C］//Proceedings of the ACM/IEEE 32nd International Conference on Software Engineering(ICSE 2010).2010:219-222.

［23］Chen Zhe，Gilles Motet.Nevertrace claims for model checking［C］//Proceedings of the 17th International SPIN Workshop on Model Checking of Software(SPIN 2010).2010:162-179.

［24］Chen Zhe，Gilles Motet.System safety requirements as control structures［C］//Proceedings of the 33rd Annual IEEE International Computer Software and Applications Conference(COMPSAC 2009).2009:324-331.

［25］Chen Zhe，Gilles Motet.A language-theoretic view on guidelines and consistency rules of UML［C］//Proceedings of the 5th European Conference on Model Driven Architecture-Foundations and Applications(ECMDA-FA 2009).2009:66-81.