1. 關於程式碼覆蓋率
衡量程式碼覆蓋率有很多種層次，比如行覆蓋率，函式/方法覆蓋率，類覆蓋率，分支覆蓋率等等。程式碼覆蓋率也是衡量測試質量的一個重要標準，對於黑盒測試來說，假如你不確定自己的測試用例是否真正跑過了系統裡面的每一行程式碼，在測試的完整性上總要打些折扣。
因此，業界幾乎對各種程式語言都有自己的一套程式碼覆蓋率解決方案。世界上最美的語言PHP當然也不例外。PHPUnit和Spike PHPCoverage提供了一套基於xdebug的程式碼覆蓋率測試方案。在本文中，我將針對自己碰到的特定業務場景，講述一下自己進行PHP程式碼函式覆蓋率測試的解決方案。
假設我們線上開發了一個網站，交給業務測試的同事去進行功能測試。那他們是怎麼測試的呢?通常情況下，無非是開發人員把網站部署好了，然後測試人員把網上所有功能都試用一遍，包括一些異常使用情況。對於業務測試來說，只要我把所有的功能點都測了，把所有異常使用情況也測到了，那就完成了。
但是對於開發來說，我比較好奇的是，你是否把我寫的所有程式碼都跑到了?會不會存在一些程式碼，只有在很特殊的情況下才能觸發，而你從來沒有測到過這些情況?這時，可能就需要程式碼覆蓋率來出馬了。
其實我首先想到了xdebug來測試覆蓋率，只需要兩三個函式即可，如下： xdebug_start_code_coverage(); //開始收集程式碼行覆蓋情況 xdebug_get_code_coverage(); //獲取截至目前所跑過的程式碼檔名和行號 xdebug_stop_code_coverage(); //停止收集程式碼行覆蓋情況
xdebug提供的介面可以用於測試行覆蓋率，這是否能滿足要求呢?其實，行覆蓋率顆粒度有點細，實際專案中，開發人員可能會對程式碼進行微調。比如，這次測試，你跑過了A.php檔案的第10行，但是我有一天對A.php進行了微調，在A.php第9行和第10行之間又加了兩行程式碼。
於是，原來的第10行變為了第12行，而xdebug的行覆蓋資訊只記錄了行號……這樣之前的資料豈不是不準確了麼。。。考慮再三，我覺得函式覆蓋是個不錯的顆粒度。在相對成熟的專案中，很少有大規模函式變動的情況。不過問題是，xdebug並沒有提供函式覆蓋的介面。
於是，我們現在碰到的場景是：
【1】希望測到某次測試中所覆蓋的所有函式列表，知道這個專案總共有多少個函式，計算一下覆蓋率是否足夠高。
【2】測試完成之後，要生成一份覆蓋率報告，將程式碼的覆蓋情況視覺化。
【3】完整測試的流程如下：
3. 函式覆蓋率解決方案
其中插樁的意思是在測試執行之前的一些準備工作。
（1）原理
xdebug天生提供了對行覆蓋率的支援，大家要自己計算出函式覆蓋率。函式覆蓋率需要兩點資料，一個是哪些函式被執行，一個是檔案中總共有多少個函式。
檔案中總共的函式量，由於我們不可能把所有函式都執行一遍，因此這部分只能透過程式碼靜態掃描來實現。假如是在C++或者Java中，可能就需要詞法分析工具了，然而在最美的語言PHP面前，我們完全不需要那麼複雜。
從PHP4.3開始，PHP Zend Engine中內建了tokenizer功能，幫助開發者做原始碼詞法分析。我們只需要找到PHP中定義函式時所對應的詞法規律，就可以輕鬆得到指定PHP檔案中的全部函式了。
tokenizer定義的介面也十分簡單： array token_get_all (string $source)
該函式進行檔案解析，將php原始碼拆成由token組成的陣列。 string token_name (int $token)
將整數形式的token轉變為字串形式。類似於C語言中的strerror函式。有了tokenizer，自己再根據php函式定義的規律和格式設計一個有限狀態機，即可完成全量函式的解析。這部分程式碼，本人寫了個比較簡陋的，把它單獨拿出來，僅供大家參考：PHPFunctionParser
求函式覆蓋率的另外一個難點在於獲取被執行的函式列表。這地方讓我們走了一些彎路。一開始一個最簡單的辦法，我們既然透過xdebug拿到被執的行，可以透過行號來反推此行屬於哪一個函式。然而每一次的請求獲取的行號資訊量是非常大的，假如一個求情執行了1000行，那就要進行1000次判斷，效率上會比較差。調研了一番之後，發現xdebug提供了function trace的功能，可以把一次請求中的函式呼叫關係獲取到，只不過拿到了函式名字，卻沒辦法得到它所在的檔案。
於是，再次調研一番，發現了Reflection，給定方法名和類名，可以反推出來它在哪個檔案中定義。於是我們使用function trace把函式呼叫關係暫存在一個臨時檔案中，然後透過檔案解析，拿到執行的函式名(假如是類方法，則是“類名::函式名”的形式)，再透過reflection機制反推出定義這個函式的檔案即可。再次體會到了世界上最美語言的強大之處。
（2）插樁
為了降低使用門檻，我們儘可能少地改變PHP原始碼為好。xdebug收集資訊的原理是分別呼叫xdebug_start_code_coverage和xdebug_stop_code_coverage來控制覆蓋率資訊收集的開始和結束，因此不可避免地要改變原始碼。
此處我們的解決辦法是，將xdebug_stop_code_coverage透過register_shutdown_function註冊為php程式結束前必須要跑的一段程式(類似C語言的atexit函式)，將其封裝到一個檔案中，然後在原始碼第一行require這個檔案即可。假如你的PHP框架是CodeIgniter這種所有請求都有一個統一入口index.php的框架，那就只需要改變這一個檔案即可，對原始碼只有一行的改動!實際上，目前基本上所有的PHP框架，都是以一個index.php檔案作為所有請求的入口。
我們對原始碼的改動只有入口檔案index.php的第一行加入了一句話： require_once "/file/path/to/phpcoverage.php"; >
而phpcoverage.php核心程式碼邏輯大致如下： < php …… function xdebugPhpcoverageBeforeShutdown(){ …… $lineCovData = xdebug_get_code_coverage(); xdebug_stop_code_coverage(); …… xdebug_stop_trace(); …… } register_shutdown_function(‘xdebugPhpcoverageBeforeShutdown’); …… xdebug_start_trace(……); xdebug_start_code_coverage(); //備註：上面省略號表示非關鍵程式碼，這裡就不展示了
（3）資訊儲存
我們的函式覆蓋率測試有了思路，使用xdebug的function trace獲取一次請求中所有函式的呼叫關係，得到執行過的所有函式，輸出到檔案中，透過檔案解析和reflection獲得被執行的函式名和該函式所在檔案。將這些資訊存入資料庫或檔案即可。
之前試用Spike的時候，我們發現這些資訊以xml格式存入檔案，資料冗餘度很高，導致幾個測試下來，檔案已經非常大了。這顯然不是我們想看到的。因此在資料儲存的時候，我們直接將資料做json格式的序列化，字串形式存在檔案中，大大減少了檔案大小。與此同時，我們再透過請求來源的IP和日期作為分隔，分別儲存不同的檔案。這樣，來自每個機器每天的請求資料都能一目瞭然，向著“精準”的方向又邁進了一步，可以對測試人員的每個請求做精確的監控。下圖是我們在業務實踐中搜集的部分資料檔案截圖：
4. 報告生成
這樣，來自任何一個IP的每一次Web請求，它所覆蓋的行和函式資訊，都會被記錄到檔案中。對於一般的專案測試中，也就只有幾個測試人員在使用，所以不需要考慮一些效能問題。
上面講了生成覆蓋率資料的原理，不過我們至此獲得的只是一份份的資料檔案，如何彙總成一份完整的報告呢?這就需要我們自己來寫一段指令碼解析剛才生成的資料檔案了。我們的做法是借鑑了開源工具spike phpcoverage的模版，並加入自己的程式碼邏輯，特別是加入了該工具所不具有的函式覆蓋率統計資料。我們自己測試的web頁面生成的報告如下：
圖中可以看到每個檔案的行覆蓋率，函式覆蓋率，還有總的覆蓋率統計資料。假如需要更精確的資料，可以點進檔案連線，檢視到底覆蓋的是哪些程式碼行(藍色為覆蓋，紅色為未覆蓋)：
業務測試中做Web測試時，對程式碼的覆蓋率是衡量測試質量的重要指標。我們希望透過此方法做到儘量地“精準”，測試執行完後可以精確看到哪一行程式碼被執行過，哪一行沒被執行過。分析沒被執行過的原因，從而改進測試用例。使用工具的流程也很簡單，插樁=>測試=>蒐集資料=>出報告。並且此解決方案最大化地減少了對業務程式碼的影響，只需要改一行程式碼即可。即便中間出現了問題，也可以快速將程式碼恢復為原來的樣子。讓測試放心，讓開發也放心。
不過，最後還需要強調的一點是，並不是說覆蓋了所有的程式碼，就證明測試已經完整了。只不過沒被覆蓋的話，一定是不完整的。所以這個方案最大的意義在於能夠發現測試中一些遺漏的程式碼，找到一部分問題。其實，它也可以幫助新來的員工理解整個專案程式碼結構，我們可以清晰的知道，自己的每一次瀏覽器請求，到底在執行伺服器上的哪些程式碼。