即時通訊平臺建立後，服務端基於分散式構建，包含NAV/CMP/ACP等26個組服務端件，Android、iOS和網頁版3個客戶端，還有2個開放介面與3個管理介面。訊息傳遞和推送的入口非常多，而且路徑很長。
渠道內部需求較多，多工並行時，測試非常困難。系統涉及子系統較多，比如一個推送場景不僅涉及外聯蘋果、小米和華為，還涉及通訊平臺十幾個元件，以及客戶端各種品牌手機。測試投入大，執行時間長，且測試範圍很難覆蓋全面，對熟練測試人員依賴度高。
基於以上原因，即時通訊平臺對業界自動化測試做了一定研究和實踐，充分考慮產品特性，結合敏捷試點，逐步形成通訊平臺的自動測試框架，目前可替代60%手工測試工作，未來計劃將替代率提高到85%左右。
通訊平臺自動化測試創新點主要體現在以下二個方面：
1、基於即時通訊技術架構進行測試工具設計和開發，深度定製化
 

業界測試工具一般分為三類：流量工具、協議模擬和業務模擬。流量工具的代表有Load Runner和ab，協議模擬有Firefox的Requester和SoapUI，業務模擬有Appium和Selenium。
依據即時通訊平臺的技術視角應用架構圖（上圖），元件可分為通訊元件、管理平臺、開放介面和客戶端四大部分。通訊平臺基於TCP協議，可抽象出Socket工具進行測試；管理平臺提供B/S服務，可以利用Selenium錄製進行自動化測試；開放介面提供RESTful協議，可抽象出HTTP工具進行自動化測試，客戶端主要是UI類相關操作，介面測試存在易碎性較高，可以通過錄制事件進行測試。
Appium和Selenium是業界成熟的測試工具，可以直接引入作用在B/S站點和客戶端上，所以自動化測試的重點在於開放介面和通訊平臺。
開放介面的自動化測試工具（AutoTCP）比較簡單，基於httpclient-4.3編寫一個RestTool工具，封裝一個http請求：
String http(String ip, String token, String method, String action, String input)
將RESTful的請求和響應寫到xml檔案裡：

然後通過一些封裝和抽象，這樣測試人員也可以編寫xml，然後進行批量自動化執行測試了。原來測試人員通過Firefox的Requester外掛，執行一遍測試大概需要兩天的時間，基於封裝的工具類，5分鐘就可以跑完30個介面上百個場景，並給出一個粗略的報告，用來做冒煙和迴歸都非常方便。
通訊平臺的自動化測試（AutoTCP）和介面大致相似，基於CinCommon元件，模擬TCP報文請求和響應：

通訊平臺的封裝可以縮短測試路徑，原來比如群組的變更只修改了CGC元件，可能要搭配起整套環境，利用客戶端經過CMP、UCC、MDBC等一系列元件中轉，報文才會到CGC處理，借用TCP自動化測試工具，可以直接針對CGC修改所涉及的Hanlder進行測試，縮短的測試時間。
2、通過系統執行報文錄製解決測試模擬問題，並提 高測試核對精度
通過第一步我們完成了自動化測試工具AutoHTTP和AutoTCP之後，它可以減少重複，便於迴歸，能模擬多執行緒，增加複用，對傳統純手工的替代率在40%左右。
自動化測試的流程一般有測試分析、測試設計、測試模擬和測試核對四步，其中測試模擬和測試核對是最困難的部分。基於AutoHTTP和AutoTCP，我們需要編寫大量的測試模擬報文。雖然說之前報文是基於XML的，可讀性較好。但是大量的編寫和引數調整，對於測試和開發，還是一個不小的負擔，一個介面往往需要二三十個報文去覆蓋，而且還需要隨著介面的更新進行維護。
業界通用的方法是通過使用者操作來錄製指令碼，比如Selenium提供一個Firefox外掛，啟動外掛後，比如使用者開啟一個網頁，輸入賬號和密碼然後登陸一個頁面。在這過程中，外掛會將使用者的操作轉換成Selenium程式碼，Selenium支援將程式碼匯出成Junit程式碼工程。工程可以載入eclipse，執行一下就相當於執行了使用者手工的操作。
即時通訊平臺我們已接手自己開發，從實踐中來，到實踐中去。基於理論創新的想出以下方法，解決模擬的成本問題：

黑色方框的元件是通訊平臺所有元件，執行在開發/測試/生產各個環境上。執行的過程中，有各式各樣的請求；通訊平臺的基礎依賴元件是CinCommon，在CinCommon裡面會將所有的Request和Response攔截，非同步放入一個請求池Request House中。那麼在自動化測試的過程中，開發和測試人員就無需自己手工編寫所有的報文和維護報文的版本隨產品進行更新了，直接從Request House中獲取一個Request，進行引數的修改，然後再將該請求發回開發/測試環境，獲取Response然後進行驗證。由於Request House錄製了所有的Request和Response，那麼測試有效的Request和Response還可以順便儲存到一個Test House裡面，形成有效的測試案例庫。
通過該方法，部署到ST後，通訊平臺20多個元件上千個介面的報文，不到一週就編寫收集完畢。

由於TCP請求，除了同步之外，還有非同步的響應，所以將所有報文錄製入庫，還可以進行Request和Response的匹配，便於測試核對。基於Request House，測試人員在編寫模擬報文的時候，依據Event和Method，可以查出一個Request，然後對Request的From、To等引數稍加修改，就可以作為新的報文傳送給通訊元件，完成測試模擬請求。

如上圖中，通過id獲取一個系統實際執行的報文，獲取到之後，修改From和To等引數，設定測試的值，然後再向該元件發出請求，獲取響應並進行驗證。短短几行程式碼，就可以完成一些複雜場景的報文模擬、測試和核對工作。而且請求和響應報文均來自實際執行而非手工編寫，降低了人工差錯，提高了測試精度。