背景

隨著業務的迅速發展，業務代碼邏輯的復雜度增加。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

總結

以上是生活随笔為你收集整理的11纯代码 oc xcode_iOS代码染色原理及技术实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。