唯品會 iOS 程式碼覆蓋率的應用實踐
背 景
唯品會特賣會App承載著前端選購、下單、支付等核心業務，業務邏輯異常複雜，以iOS端為例，程式碼行數已達50萬。2018年初，我們啟動了研發流程的優化，大版本迭代週期由3周縮減至2周，伴隨而來的是測試獨佔時長的壓縮。如何在更短的測試時間內保證App程式碼質量是對測試團隊一次挑戰。長期以來，黑盒測試依賴於測試人員的能力和業務熟悉度，測試質量的高低沒有客觀資料可衡量。推進精準測試是我們的必經之路，而程式碼覆蓋率是必須要跨過的檻，有見及此，特賣會App團隊著手研究iOS及Android程式碼覆蓋率的應用落地。本文重點講解iOS程式碼覆蓋率的應用實踐。
調研中發現，iOS程式碼覆蓋率如要大規模應用到功能/迴歸測試，需解決如下三個痛點：
-
蘋果開發工具Xcode僅支援單元測試的程式碼覆蓋率，而且只能在本地連線除錯。而實際的測試裝置多達20+，把裝置連線電腦再收集覆蓋率是不可行的，我們必須做到收集自動化，而且對使用者無感知。
-
App的功能分支測試周期大約有4天，此期間可能存在多次的開發程式碼提交、缺陷修復，以哪一個版本作為覆蓋率統計是值得思考的。我們嘗試約定在某個穩定版本做全面的功能測試，但效果並不好，因為前期已測過的功能沒必要重測一遍，時間也不允許。因此，我們需要支援行覆蓋率的多版本合併。
-
鑑於app的執行模式僅支援離線插樁，我們需要處理大量手機使用者，不同時間節點的覆蓋率資料。
技術選型
首先，程式碼覆蓋率要考慮插樁，插樁方式有3種：1）原始碼插樁；2）中間程式碼插樁；3）可執行檔案的二進位制插樁。iOS使用clang作為前端編譯器，負責生成AST語法樹，並將程式碼編譯成LLVM bitcode；而LLVM作為後端編譯器負責生成平臺相關的機器語言。其編譯插樁過程屬於中間程式碼插樁，簡化的過程可參考圖1。LLVM脫胎於GCC，也可使用gcda/gcno記錄程式碼覆蓋率。其中：
-
gcno是notes file，插樁編譯後生成；
-
gcda是data file，與gcno對應，由程式執行時記錄；
LCOV作為GCC Code Coverage的開源前端工具，支援行/函式/分支覆蓋的報告輸出。因此，我們使用LCOV作為iOS程式碼覆蓋率生成工具。
圖1: 插樁編譯原理
iOS覆蓋率 工具整體框架如下：
圖2: 系統架構
-
前端UI 接入公司的覆蓋率平臺，支援覆蓋率的收集、生成報告、郵件通知；
-
排程層 負責分發訊息至具體執行的機器 Analyser ， Analyser 由 jenkins 封裝 , 節點的機器必須為 Mac 系統，物理機或虛擬機器均可；
-
分析器 支援覆蓋率檔案的合併、差異以及報告的輸出。另外分析器負責接收終端上報覆蓋率資料；
-
檔案系統 管理覆蓋率檔案的中間資料以及版本構建資訊 。
實現原理
我們設計出一整套解決方案，請看圖3
圖3：iOS程式碼覆蓋率實現時序圖
具體處理時序如下：
1) Xcode打包伺服器在CI中自動插樁，並根據commit id，上傳與之對應的標籤檔案gcno；
2) 使用者通過OTA方式安裝app，在測試過程中只需把app置於後臺，覆蓋率資料即可從快取刷入硬碟，並通過http介面上傳至檔案伺服器；
3) 覆蓋率平臺可通手工觸發方式，收集指定分支、commit id的覆蓋率檔案info；
4) 待預處理完畢後，覆蓋率平臺可生成合並的或差異的覆蓋率報告；
接下來我們從如下三方面剖析技術實現：
-
Xcode插樁
-
Pod上傳伺服器
-
覆蓋率檔案的合併/差異處理
(一) Xcode插樁
在BuildSettings分別設定Instrument Program Flow、Generate Legacy Test Coverage File為True，即可開啟插樁。
圖4: Xcode 插樁設定
(二) Pod上傳伺服器
通過Pod的外掛方式，我們使用C++混編，呼叫外部的__gcov_flush方法把覆蓋率gcda從記憶體刷到硬碟。為了方便交叉編譯，GCC設計了兩個與生成路徑相關的變數GCOV_PREFIX，GCOV_PREFIX_STRIP，如下圖。
圖5: Pod的外掛實現
在生成GCDA後就要考慮上傳到檔案伺服器了，我們採用AFNETWORKING庫，把多個GCDA檔案整合在一個介面上傳，檔案大小約7M Bytes
(三) 覆蓋率檔案預處理，支援差異/多版本合併
我們使用開源LCOV來處理檔案，gcda+gcno+原始碼可生成中間檔案info，info檔案包含了最終呈現報告的所有資訊，包括原始碼路徑、函式名、函式執行次數、函式總數、函式在原始檔的位置、行號、行執行次數、行總數。為支援行差異覆蓋率，我們自定義了新欄位CA/CF/CH，請見圖6。
圖6: 中間檔案info資料結構
對於兩個不同版本的合併，使用平移。原則是把舊版本程式碼裡的未變更的行覆蓋平移到新版本。請見圖7。
圖7: 新舊版本git diff對比
具體流程如下，舊程式碼的覆蓋率與git diff 比較，先判斷是否塊內程式碼，如不是塊內程式碼則平移行號至新版本；若是塊內程式碼，則再判斷是否為已刪除的行號，若是，則跳過不做平移；若不是已刪除的行，則平移行號，請見圖8。或許讀者有疑問，兩個版本的上下文都變了，平移行覆蓋率後的可信度高麼？筆者想強調的是，覆蓋率報告好比一份健康檢查報告，只關心異常點，沒有覆蓋的行就是異常點。在使用平移演算法後那些依然沒有覆蓋的行就是沒經探索的荒地，將是重點關注的物件。
圖8: 兩個版本的行覆蓋率合併流程
我們再擴充套件至n個版本的合併，可沿用以上的平移演算法，只需把最後一個版本作為平移的基準版本即可，可參考下圖。
圖9: 多版本的行覆蓋率合併流程
至此，iOS覆蓋率整套實現方案描述完畢。
實踐效果
iOS覆蓋率工具已接入至覆蓋率平臺，可通過伺服器管理指定待收集的系統平臺，分支；平臺支援多分支同時收集。功能測試分支的覆蓋率收集時間可控制在20分鐘內。覆蓋率收集完成後，平臺可設定行差異覆蓋率的對比基線，可設定一個分支內合併的多個版本，效果請見圖10、11、12。
圖10: 移動測試列表伺服器管理
圖11: 生成覆蓋率報告頁面
圖12: iOS覆蓋率報告的目錄結構
最後，我們看看該工具的應用情況，特賣會App當前每兩週發一個版本，在功能測試階段，各條業務線(包括特賣/基礎/使用者/創新)已開始使用iOS覆蓋率檢測工具，從使用的經驗看，功能測試階段的程式碼行差異覆蓋率達到90%，未覆蓋的行主要包括三項，風險可控：
-
異常捕捉
-
非空指標的保護
-
冗餘預留程式碼
精準測試方法總結
結合iOS覆蓋率工具，我們總結出目前適合特賣會app的精準測試策略，請見圖13。在測試分析階段，我們注重需求差異，技術差異的分析，結合用例地圖得出測試策略，並指導我們進行冒煙/功能測試，每個測試階段的Code Review著重點有所不同，在冒煙測試階段，CR著重檢查開關、介面名、介面引數、model欄位；在功能測試階段，CR重點關注介面異常/跳轉、行為;迴歸階段則優先檢查Bug Fix的程式碼改動。測試階段均通過行差異覆蓋率檢查測試遺漏，並反饋更新測試策略。
圖13: 特賣會App精準測試策略
下一步計劃
目前使用的人工分析+工具輔助的方式進行精準測試，在這條探索的道路上我們還有很長的路要走。人工分析受制於技術，需求背景，能力和經驗，我們很難保證質量。如何把已有的覆蓋率資料轉化為事前分析的參考，並結合整理的用例-模組（檔案、函式、分支）對映庫實行自助分析、測試用例集推薦，將是我們下一步研究的重點。
推薦閱讀
容器環境應用一鍵拉起實踐
“唯技術”一檔專為唯品技術人發聲的公眾號
歡迎投稿！！
只要是 技術相關的文章 儘管砸過來！
