模板
教程
環境
性能
功能
管理
淘寶網 持續集成的 嘗試
全網回歸
全網回歸 是淘寶網主站 持續集成的 組成部分，
要解決的問題
1. 應用多，
2. 有依賴，各應用之間有依賴，開發應用者不完全清楚。
3. 同一個測試環境，解決問題容易，排查問題難。
目標
1. 對業務線的回歸; on time
2. 公司級別的回歸， 安全，運維團隊 升級 打補丁之后， 可以直接選擇需要回歸的業務線以及 用例優先級; on demand
3. API 的精確回歸， 當某一API 發生 變化時， 能夠精確的定位被影響的全網 其他API ，并且進行回歸，給出結果，通知相應的人; on event (we are here)
目前情況
2011年
1. 平均每天2.1個bug;共發現208個bug;幫助降低線上BUG遺漏率 45.31%(208/459);
2. 腳本平均運行時間： WebUI：1.38分鐘API：1.2秒
3. 腳本數量：19263個(WebUI-1613，API-17650) ———-> 54120個(WebUI-6492，API-47628)
4. 腳本成功率： WebUI平均95%(最高97%，最低92%);API平均97%(最高98%，最低95%)
5. 投入成本： 平均每條線維護腳本0.955個，耗時10分鐘(6條線); 平均每人維護腳本0.035個，耗時3.75秒(200人計)
6. 成本降低： 平均每天在跑用例 50k，每個用例人工執行 算5min; 則需要 520個工作日的時間(每天8小時不間斷工作)，相當于 520個人 一天8小時 不間斷的工作量
關鍵技術
1. 機器管理
目的
確保測試機器高可用度
降低測試機器搭建的成本
分析
現狀：從春節后的2月份開始，automan(淘寶自動化框架)升級了5次，但每一次升級都不完整，總會有一些機器升級不成功?；貧w機器已達到了70+臺，排查起來費時費力;
Agent也有同樣的問題，但相比而言要少些;目前，全面升級一次的時間挺長，約2小時;
辦法：測試平臺提供統一的客戶端軟件批量升級的辦法，升級后能驗證是否成功，并反饋到kelude(淘寶測試系統)上的機器管理系統中，負責人可以立即看到所有機器的升級情況，進而快速發現問題、解決問題;
另外，機器管理還需要收集各回歸機器的關鍵軟件信息，如：版本、配置等，方便負責人快速發現環境差異;
對回歸機器的全面驗證，例如：benchmark
現狀：在kelude(淘寶測試系統)系統中登記的機器共有100+，但這里面的機器有些不能訪問，或者性能低下;例如，2012-03-14對全網回歸的99臺機器進行驗證，結果發現：有39臺沒有執行腳本，有40臺機器正常執行(<20S)，有15臺機器執行時間超過20S;
辦法：建立一套驗證腳本和驗證機制：每天定時 或 按需(例如加機器，或升級)運行這一套腳本，對所有的回歸機器進行全面的自動驗證，從中確定有問題的，運行緩慢的機器，或優化，或淘汰等;
驗證腳本可以根據需要 添加進來，例如：對性能的驗證，對瀏覽器訪問的驗證，對automan(淘寶自動化框架)版本的驗證等;
機器標準化
機器標準化：賬號、軟件、配置等，并提供標準化的虛擬機鏡像，方便快速創建新的回歸機器;后期會嘗試 KVM 的接入
技術
機器唯一性標識
每個KeludeAgent接入到Kelude系統時，會由系統分配一個獨一無二的UUID,用來在Kelude系統內標識該KeludeAgent。
機器信息&軟件配置獲取
(windows)KeludeAgent定期讀取(1h)注冊表獲取機器信息，瀏覽器信息，通過 HTTP API 推送到kelude平臺
(linux) 暫未支持
軟件升級
KeludeAgent開放 Deploy RPC service 接口，Kelude Web 將升級的命令通過 RPC調用傳遞給KeludeAgent執行。
(windows)KeludeAgent 執行 Kelude Web 傳遞的命令進行升級。由于在某些時候可能需要升級KeludeAgent本身，因此KeludeAgent在執行升級命令時，會將升級過程單獨啟動一個獨立的進程來執行。即使KeludeAgent被關閉，也不會影響升級過程。
可用性檢測
任意程序可以通過訪問KeludeAgent暴露的 RPC 接口來確定其是否可用.
可用性檢測告警
在機器信息收集的基礎上，定義了一些觸發條件。當機器的信息滿足這些條件時，Kelude系統就發出旺旺消息通知對應的機器管理人員。
目前定義的規則主要包括
機器可用狀態變化
機器 C 盤空間降低到500M以下(windows)
2. 任務調度
按機器池并行調度
現狀：2月份，各回歸機器的利用率差別很大，從30%-90%不等，回歸機器沒有被充分利用起來，導致部分產品回歸時間長;
辦法：首先按產品線建立機器池，各產品線回歸 從機器池中獲取可用機器，以10個-30個TC為一組 進行并行調度;
期望的效果是，均衡機器的利用率，縮短整體回歸時間;
按任務優先級調度
現狀：WebUI回歸2小時完成率大約在74%，通過分析發現，70%運行超時的腳本(約300個)都被安排在了02:00之內運行，這就導致了運行快的腳本被排擠到了2H以外;
辦法：增加調度優先級，例如：運行快的腳本被優先執行，重要的用例優先執行等;
機器節點動態伸縮
探測回歸機器是否可用，并能夠動態的增加或減少回歸機器。不會因為其中的少量機器不可用，而引起回歸超時、或失敗的問題;
l
3. 如何確立全網的API依賴關系(系統內，系統外)
Depend系統的API接口采用基于REST風格的接口規范。所有的調用請求都需要走http的方式調用統一的URL(暫定http://XXXXX:8080/depend/rest.do )來實現。
Depend實現原理關鍵技術點：在被測試應用所有類中插入jvm指令，以取回方法調用鏈、當前請求URL、tair服務的名字空間等信息，存入數據庫即完成了依賴關系的收集，具體技術要點如下：
