背景
隨着業務的迅速發展，業務代碼邏輯的複雜度增加。QA測試的質量對於產品上線後的穩定性更加重要。一般QA測試的工作流程分爲兩大項：自動化測試和人工測試。這兩種測試後都需要得到代碼覆蓋率。自動化測試的覆蓋率，在雙端都有比較成熟的方案。
本文着重介紹人工測試過程中，怎麼得到對應的代碼覆蓋率。涉及到的技術主要是代碼染色。以下會先介紹整體的工作流程，再對涉及到的技術一一闡述。
染色流程
流程圖中涉及到了雙端的關鍵節點以及技術點。我們重點介紹編譯階段。
- 編譯階段：生成染色包 (對IR文件插樁)
需要在編譯中增加編譯選項，編譯後會爲每個可執行文件生成對應的 .gcno文件。
- 運行階段：生成二進制覆蓋率文件。
在測試代碼中調用覆蓋率分發函數，會生成對應的 .gcda文件。
- 解析階段：將二進制覆蓋率文件可視化。
編譯階段
在上文可以看出，編譯階段最核心的操作是對IR文件進行插樁。
什麼是IR文件？插樁邏輯是什麼？我們往下看。
語言處理系統
一個完整的語言處理系統中，從源程序到可執行的機器代碼，如下圖所示，歷經幾個重要模塊。而我們上文提到的IR文件，是編譯器模塊中的產物，插樁處理也是在這個模塊中進行。這裏重點討論下編譯器。
編譯器
說起編譯器，我們瞭解到的傳統編譯器架構分爲前端、優化器和後端。
傳統編譯器的劣勢是：前端和後端沒有完全分離，耦合在了一起，因而如果要支持一門新的語言或硬件平臺，需要做大量的工作。一種更加靈活，適應性更好的編譯器套件應運而生——LLVM.
LLVM
官網：http://www.aosabook.org/en/llvm.html
LLVM是一個開源的，模塊化和可重用的編譯器和工具鏈技術的集合，或者說是一個編譯器套件。
可以使用LLVM來編譯Kotlin，Ruby，Python，Haskell，Java，D，PHP，Pure，Lua和許多其他語言。
LLVM核心庫還提供一個優化器，對流行的CPU做代碼生成支持。
LLVM同時支持AOT預先編譯和JIT即時編譯。
2012年，LLVM獲得美國計算機協會ACM的軟件系統大獎，和UNIX，WWW，TCP/IP，Tex，JAVA等齊名。
LLVM和傳統編譯器最大的不同點在於，前端輸入的任何語言，在經過編譯器前端處理後，生成的中間碼都是IR格式的。接下來看下LLVM架構下的巨大優勢，iOS&MacOS平臺的編譯器。
iOS&MacOS平臺編譯器
iOS、MacOS平臺開發用的IDE:Xcode。在 Xcode 5版本前使用的是GCC編譯器，在 Xcode 5中將GCC徹底拋棄，替換爲LLVM 。LLVM包含了編譯器前端、優化器和編譯器後端三大模塊。
其中Swift除了在編譯器前端和Objective-C稍有不同，其他模塊都是相同的。
如下圖所示，能看出LLVM的優勢，對於一門新的編程語言，只需要提供對應的編譯前端，生成IR。就可以完成整個新語言的處理。
聊過了IR文件在整個語言處理過程中的位置，下面我們看下IR文件生成邏輯以及插樁相關的邏輯。這不得不提到Clang。
Clang
Clang是LLVM的子項目，是C、C++和Objective-C的編譯器。Clang在整個Objective-C編譯過程中扮演了編譯器前端的角色，同時也參與到了Swift編譯過程中的Objective-C API映射階段。
Clang的特點是編譯速度快，模塊化，代碼簡單易懂，診斷信息可讀性強，佔用內存小以及容易擴展和重用等。
Clang的主要功能是輸出代碼對應的抽象語法樹（AST），針對用戶發生的編譯錯誤準確地給出建議，並將代碼編譯成LLVM IR。
以Xcode爲例，Clang編譯Objective-C代碼的速度是Xcode 5版本前使用的GCC的3倍，其生成的AST所耗用掉的內存僅僅是GCC的五分之一左右。
關於iOS項目可以使用對應的命令獲取，本文不作詳細介紹。
關於編譯器前端的主要工作項，感興趣的讀者閱讀《編譯原理》——龍書。
介紹完了IR的“生成器”。接下來我們詳細介紹IR文件。
LLVM IR
LLVM Intermediate Representation。LLVM的中間代碼，是編譯器前端的輸出，和編譯器後端的輸入。是連接編譯器前端與LLVM後端的一個橋樑。
通常常見的文件格式爲ll 和bt 。做過iOS開發的讀者應該瞭解bitcode。bt就是編譯器開啓bitcode後的一種中間代碼格式。
IR提供了獨立於任何特定機器架構的源語，因此它是LLVM優化和進行代碼生成的關鍵，也是LLVM有別於其他編譯器的最大特點。LLVM的核心功能都是圍繞IR建立的。
通常中間代碼的表示形式分爲：語法樹（syntax tree）、三地址指令序列。爲了更好的瞭解IR文件。這裏介紹下三地址指令。
三地址指令
也可以稱爲三地址代碼。之所以被稱爲三地址指令，是源於它的指令形式：x = y op z ，其中op是一個二目運算符，y和z是運算分量的地址，x是運算結果的存放地址。三地址指令最多隻執行一個運算，通常是計算，比較或者分支跳轉運算。
三地址代碼拆分了多運算符算術表達式以及控制流語句的嵌套結構，所以適用於目標代碼的生成和優化。
//像 x+y*z 這樣的源代碼被翻譯成三地址指令序列：
t1=y*z
t2=x+t1
//源碼：do i = i + 1; while(a[i] < 10); 被翻譯成如下的三地址指令
i = i + 1
t1 = a[i]
if t1 < 10 goto 6
其中t1，t2是編譯器產生的臨時名字。
但是程序運行過程中，每個模塊並不是完全獨立的。存在着模塊間的跳轉。這些被翻譯出的三地址指令，又被組合成另一種便於理解的形式——BB塊。
基本塊
基本塊(Basic Block)是滿足下列條件的最大的 連續三地址指令序列 ：
- 控制流只能從基本塊中的第一個指令進入該塊。
- 除了基本塊的最後一個指令，控制流在離開基本塊之前不會停機或者跳轉。
- 只要基本塊中的第一個指令被執行，那麼基本塊中的所有指令都會得到執行
其中中間代碼指令序列生成BB塊的算法如下：
- 確定中間代碼序列中哪些指令是首指令
- 中間代碼的第一個三地址指令是一個首指令。
- 任意一個條件或無條件轉移指令之後的目標指令是一個首指令。
- 緊跟在一個條件或無條件轉移指令之後的指令是一個首指令。
- 每個首指令對應的基本塊包括了從它自己開始，直到下一個首指令（不含）或者中間代碼的結尾指令之間的所有指令。
舉例：
i = 1 //第一個三地址指令，所以作爲首指令
j = 1 //第11行，跳轉語句的目標指令。所以作爲首指令
t1 = 10*i
t2 = t1+j
t3 = 8*t2
t4 = t3-88
a[t4] = 0.0
j = j+1
if j<=10 goto (3) //本身作爲跳轉指令，所以是首指令
i = i+1
if i<=10 goto (2) //本身作爲跳轉指令，所以是首指令
i = 1
t5 = i – 1 //第17行，跳轉語句的目標指令。所以是首指令
t6 = 88*t5
a[t6] = 1.0
i = i+1
if i<=10 goto (13)//本身作爲跳轉指令，所以是首指令
//把一個10x10的矩陣設置成單位矩陣中的中間代碼
for(i=1;i<=10;i++){
for(j=1;j<=10;j++){
a[i,j] = 0.0;
}
}
for(i=1;i<=10;i++){
a[i,j] = 1.0;
}
對應被劃分的BB塊：
在瞭解了BB塊之後。我們距離怎麼對IR文件進行插樁的真相已經越來越近了，下面我們來看下最後一個最重要的環節。
流圖
當將一箇中間代碼程序劃分成爲基本塊之後，我們用一個流圖來表示它們之間的控制流。流圖(flow graph)的結點就是這些基本塊。流圖就是通常的圖，它可以用任何適合表示圖的數據結構來表示。
從基本塊B到基本塊C之間有一條邊當且僅當基本塊C的第一個指令緊跟在B的最後一個指令之後執行。存在這樣一條邊的原因有兩種：
- 有一個從B的結尾跳轉到C的開頭的條件或無條件 跳轉語句 。
- 按照原來的三地址語句序列中的順序，C緊跟在B之後，且B的結尾不存在無條件跳轉語句。
我們說B是C的前驅(predecessor), 而C是B的一個後繼(successor)。
通常會增加兩個分部稱爲 入口（entry） 和 出口（exit） 的結點。它們不和任何可執行的中間指令對應。從入口到流圖的第一個可執行結點有一條邊（edges）。從任何包含了可能是程序的最後執行指令的基本塊到出口有一條邊。如果程序的最後指令不是一個無條件轉移指令，那麼包含了程序的最後一條指令的基本塊是出口結點的一個前驅。但任何包含了跳轉到程序之外的跳轉指令的基本塊也是出口結點的前驅。
其中B0-B7是BB塊。E0-E7是邊（edges）
插樁邏輯
覆蓋率計數指令的插入會進行兩次循環，外層循環遍歷編譯單元中的函數，內層循環遍歷函數的基本塊。函數遍歷用來向gcno文件中寫入函數位置信息。
一個函數中基本塊的插樁方法如下：
- 統計所有BB的後繼數n，創建和後繼數大小相同的數組ctr[n]。
- 以後繼數編號爲序號將執行次數依次記錄在 ctr[i] 位置，對於多後繼情況根據條件判斷插入。
根據生成流圖的規則，可以很容易得到樁點位置，[]處就是插入的樁點序號。
關於工程配置可以參考GCOV的官網：
https://gcc.gnu.org/onlinedocs/gcc/Gcov.html
下面簡單介紹下gcov，gcno，gcda這三個gcc家族的關鍵成員。
GCOV
GCOV是一個GNU的本地覆蓋測試工具, 伴隨GCC發佈，配合GCC共同實現對C或者C++文件的語句覆蓋和分支覆蓋測試。是一個命令行方式的控制檯程序。需要工具鏈的支持。
GCNO
利用Clang分別生成源文件的AST和IR文件，對比發現，AST中不存在計數指令，而IR中存在用來記錄執行次數的代碼。
覆蓋率映射關係生成源碼是LLVM的一個Pass，用來向IR中插入計數代碼並生成.gcno文件（關聯計數指令和源文件）。
上圖右側。即爲gcno的可視化格式。
本質上gcno是二進制內容。需要藉助gcov工具(gcov -dump xxx.gcno)將文件轉換爲這種可視的格式。
其中每個字段的含義
- 函數所在文件的絕對路徑（如上圖紅框所示）。
- Block ：0-7 代表BB文件的編號。
- Counter爲插樁後生成的存儲執行次數的字段。
- Source Edges是前繼。
- Destination是後繼。
- Lines是指令在代碼文件中行數。
GCDA
gcda是由加了-fprofile-arcs編譯參數的編譯後的文件運行所產生的，它包含了弧跳變的次數和其他的概要信息。
藉助gcov工具可以查看gcda文件的大致內容：
gcda文件已經是一個包括了函數執行情況的文件。剩餘的工作就是將執行情況更加可視化，和源碼進行匹配。
瞭解了三個gc的重要成員。藉助一些前端工具，我們就可以得到一份詳細的覆蓋率報告了。關於前端工具，大家可以自行搜索。
最後附上覆蓋率的一個報告片段
技術擴展
瞭解上述基礎知識後，我們更加容易理解LLVM中的架構及各個模塊的功能。我們可以在插樁過程中，修改原有的插樁邏輯。我們可以編寫XCode編譯器插件。總之，藉助LLVM的源碼及我們瞭解到的知識。在一個語言的任意處理階段，我們都可以對其進行定製，甚至我們可以創造一個自己的專屬語言。
源碼參考：
https://github.com/llvm-mirror/llvm/blob/release_70/lib/Transforms/Instrumentation/GCOVProfiling.cpp
https://llvm.org/doxygen/group__LLVMCCoreValueBasicBlock.html#ga444a4024b92a990e9ab311c336e74633
https://gcc.gnu.org/onlinedocs/gcc/Gcov.html
本文轉載自公衆號高德技術（ID：amap_tech）。
原文鏈接：