酷播亮新聞
文章摘要： 就可以得出線上程式碼的真實覆蓋率由此我們得到了一個完整的自動化測試線上程式碼覆蓋率的框架
作者簡介
姜睿東，2009年加入攜程，從事無線研發，現在大住宿事業群擔任酒店無線研發工作。
清理專案中的無用程式碼是日常開發中非常重要的一環，定期清理廢程式碼既可以保持程式碼的簡潔，也可以讓程式碼邏輯變得更清晰，不給後人留坑。
比較傳統的尋找無用程式碼的做法，一般是查詢沒有引用的方法或類，這個可以很容易的通過指令碼來實現，甚至有的IDE自身就能提供這個功能，再進一步的話也可以在網上找到一些開源演算法的指令碼，來查詢重複或相似的程式碼。
隨著攜程酒店業務的快速發展，線上版本的迭代頻率越來越快，程式碼量開始急劇膨脹，以上這些方法已經不夠用了。如何及時清理無用的程式碼，變得越來越困難。
大量的無用程式碼不是靠檢查一下無引用就能發現的，因為我們有著數量龐大的服務端及客戶端實驗，以及頻繁上線下線的業務，靠人肉很難發現哪些是無用程式碼，而app又對size有著極為苛刻的要求。所以 怎麼高效率的尋找無用的或利用率極低的程式碼 ，成為研究方向。
首先想到的是檢查線上程式碼的覆蓋率，沒有覆蓋到的部分，就是所謂的無用程式碼。
那麼，怎麼來檢查線上程式碼的覆蓋率呢？網上一般會採用「插樁」的方式，思路就是在程式碼的每一個函式中植入埋點程式碼，然後在後臺利用一套演算法來計算程式碼的覆蓋率，用這種方式得出的結果相對比較精準。但是我們對程式碼有些潔癖，並不想對程式碼有任何的破壞，而且這種方式在後臺的計算也是相對比較繁瑣的。
我們想到的辦法是 利用Xcode自帶的Code Coverage來檢查程式碼的覆蓋率 。Xcode的這個自帶的工具非常的好用，不但可以方便的視覺化的看到程式碼覆蓋率，還可以看到程式碼被執行的頻率，如下圖所示：
通過這個報表，我們可以很清楚的看到程式碼被執行的情況，這樣就可以針對那些沒有被執行到的程式碼進行具體原因的分析。
但是Code Coverage只能在單元測試的case中才能使用，而單元測試一般用的都是mock資料，酒店業務極其複雜，各種真實資料不太容易造出來，很難真實反映線上程式碼的執行情況，並不能直接為我們所用。
於是我們把目光投向了我們的自動化測試平臺，我們的自動化測試平臺有一個流量回放的功能，可以回放線上的真實資料，平時用來自動迴歸服務端case，存有千萬條資料，足以覆蓋絕大部分線上的case。
我們設計的大概的流程圖是這個樣子的：
從圖中可以看到，我們的UI測試用例往測試平臺發出的是一個空的request，然後由測試平臺隨機從日誌資料庫中抽取相應用例的response返回給客戶端，如此迴圈足夠多的次數基本上可以覆蓋到這個用例的全部case。
這樣我們就有了一個理論上可行的應用框架 ，不過還需要解決一個問題，那就是我們的一個頁面上往往有數十個小服務，而且互相之間都有資料依賴，自動化測試平臺只能接受單個服務的請求，且無法對應這個服務相關的其他小服務的資料，沒有了聯動性，就給我們的單元測試帶來了麻煩， 沒有辦法完整的測試一個頁面。
對此我們又對 UI測試和自動化測試平臺雙雙進行了改造 ，首先在自動化測試服務的api前面，仿造生產環境一樣搭建一個Gateway，由這個Gateway來負責json和pb之間協議的轉換，如下圖所示：
這樣的話，我們的單元測試無需在原來業務程式碼裡做太多修改，只需要把原來指向生產Gateway的地址指向自動化測試平臺Gateway就可以了，只要幾行程式碼就可以實現一個列表頁的測試。
由此我們得到了一個完整的自動化測試線上程式碼覆蓋率的框架，通過不定期的跑自動化UI Case，就可以得出線上程式碼的真實覆蓋率。
【推薦閱讀】