1. 關(guān)于代碼覆蓋率

　　衡量代碼覆蓋率有很多種層次，比如行覆蓋率，函數(shù)/方法覆蓋率，類覆蓋率，分支覆蓋率等等。代碼覆蓋率也是衡量測試質(zhì)量的一個重要標準，對于黑盒測試來說，假如你不確定自己的測試用例是否真正跑過了系統(tǒng)里面的每一行代碼，在測試的完整性上總要打些折扣。

　　因此，業(yè)界幾乎對各種編程語言都有自己的一套代碼覆蓋率解決方案。世界上最美的語言PHP當然也不例外。PHPUnit和Spike PHPCoverage提供了一套基于xdebug的代碼覆蓋率測試方案。在本文中，我將針對自己碰到的特定業(yè)務(wù)場景，講述一下自己進行PHP代碼函數(shù)覆蓋率測試的解決方案。

 

　　假設(shè)我們在線開發(fā)了一個網(wǎng)站，交給業(yè)務(wù)測試的同事去進行功能測試。那他們是怎么測試的呢?通常情況下，無非是開發(fā)人員把網(wǎng)站部署好了，然后測試人員把網(wǎng)上所有功能都試用一遍，包括一些異常使用情況。對于業(yè)務(wù)測試來說，只要我把所有的功能點都測了，把所有異常使用情況也測到了，那就完成了。

　　但是對于開發(fā)來說，我比較好奇的是，你是否把我寫的所有代碼都跑到了?會不會存在一些代碼，只有在很特殊的情況下才能觸發(fā)，而你從來沒有測到過這些情況?這時，可能就需要代碼覆蓋率來出馬了。

　　其實我首先想到了xdebug來測試覆蓋率，只需要兩三個函數(shù)即可，如下： xdebug_start_code_coverage(); //開始收集代碼行覆蓋情況 xdebug_get_code_coverage(); //獲取截至目前所跑過的代碼文件名和行號 xdebug_stop_code_coverage(); //停止收集代碼行覆蓋情況

　　xdebug提供的接口可以用于測試行覆蓋率，這是否能滿足要求呢?其實，行覆蓋率顆粒度有點細，實際項目中，開發(fā)人員可能會對代碼進行微調(diào)。比如，這次測試，你跑過了A.php文件的第10行，但是我有一天對A.php進行了微調(diào)，在A.php第9行和第10行之間又加了兩行代碼。

　　于是，原來的第10行變?yōu)榱说?2行，而xdebug的行覆蓋信息只記錄了行號……這樣之前的數(shù)據(jù)豈不是不準確了么。。?？紤]再三，我覺得函數(shù)覆蓋是個不錯的顆粒度。在相對成熟的項目中，很少有大規(guī)模函數(shù)變動的情況。不過問題是，xdebug并沒有提供函數(shù)覆蓋的接口。

　　于是，我們現(xiàn)在碰到的場景是：

　　【1】希望測到某次測試中所覆蓋的所有函數(shù)列表，知道這個項目總共有多少個函數(shù)，計算一下覆蓋率是否足夠高。

　　【2】測試完成之后，要生成一份覆蓋率報告，將代碼的覆蓋情況可視化。

　　【3】完整測試的流程如下：

3. 函數(shù)覆蓋率解決方案

其中插樁的意思是在測試執(zhí)行之前的一些準備工作。

（1）原理

　　xdebug天生提供了對行覆蓋率的支持，大家要自己計算出函數(shù)覆蓋率。函數(shù)覆蓋率需要兩點數(shù)據(jù)，一個是哪些函數(shù)被執(zhí)行，一個是文件中總共有多少個函數(shù)。

　　文件中總共的函數(shù)量，由于我們不可能把所有函數(shù)都執(zhí)行一遍，因此這部分只能通過代碼靜態(tài)掃描來實現(xiàn)。假如是在C++或者Java中，可能就需要詞法分析工具了，然而在最美的語言PHP面前，我們完全不需要那么復(fù)雜。

　　從PHP4.3開始，PHP Zend Engine中內(nèi)置了tokenizer功能，幫助開發(fā)者做源碼詞法分析。我們只需要找到PHP中定義函數(shù)時所對應(yīng)的詞法規(guī)律，就可以輕松得到指定PHP文件中的全部函數(shù)了。

　　tokenizer定義的接口也十分簡單： array token_get_all (string $source)

　　該函數(shù)進行文件解析，將php源代碼拆成由token組成的數(shù)組。 string token_name (int $token)

　　將整數(shù)形式的token轉(zhuǎn)變?yōu)樽址问?。類似于C語言中的strerror函數(shù)。有了tokenizer，自己再根據(jù)php函數(shù)定義的規(guī)律和格式設(shè)計一個有限狀態(tài)機，即可完成全量函數(shù)的解析。這部分代碼，本人寫了個比較簡陋的，把它單獨拿出來，僅供大家參考：PHPFunctionParser

　　求函數(shù)覆蓋率的另外一個難點在于獲取被執(zhí)行的函數(shù)列表。這地方讓我們走了一些彎路。一開始一個最簡單的辦法，我們既然通過xdebug拿到被執(zhí)的行，可以通過行號來反推此行屬于哪一個函數(shù)。然而每一次的請求獲取的行號信息量是非常大的，假如一個求情執(zhí)行了1000行，那就要進行1000次判斷，效率上會比較差。調(diào)研了一番之后，發(fā)現(xiàn)xdebug提供了function trace的功能，可以把一次請求中的函數(shù)調(diào)用關(guān)系獲取到，只不過拿到了函數(shù)名字，卻沒辦法得到它所在的文件。

　　于是，再次調(diào)研一番，發(fā)現(xiàn)了Reflection，給定方法名和類名，可以反推出來它在哪個文件中定義。于是我們使用function trace把函數(shù)調(diào)用關(guān)系暫存在一個臨時文件中，然后通過文件解析，拿到執(zhí)行的函數(shù)名(假如是類方法，則是“類名::函數(shù)名”的形式)，再通過reflection機制反推出定義這個函數(shù)的文件即可。再次體會到了世界上最美語言的強大之處。

（2）插樁

　　為了降低使用門檻，我們盡可能少地改變PHP源代碼為好。xdebug收集信息的原理是分別調(diào)用xdebug_start_code_coverage和xdebug_stop_code_coverage來控制覆蓋率信息收集的開始和結(jié)束，因此不可避免地要改變源代碼。

　　此處我們的解決辦法是，將xdebug_stop_code_coverage通過register_shutdown_function注冊為php程序結(jié)束前必須要跑的一段程序(類似C語言的atexit函數(shù))，將其封裝到一個文件中，然后在源代碼第一行require這個文件即可。假如你的PHP框架是CodeIgniter這種所有請求都有一個統(tǒng)一入口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(); //備注：上面省略號表示非關(guān)鍵代碼，這里就不展示了

（3）信息存儲

　　我們的函數(shù)覆蓋率測試有了思路，使用xdebug的function trace獲取一次請求中所有函數(shù)的調(diào)用關(guān)系，得到執(zhí)行過的所有函數(shù)，輸出到文件中，通過文件解析和reflection獲得被執(zhí)行的函數(shù)名和該函數(shù)所在文件。將這些信息存入數(shù)據(jù)庫或文件即可。

　　之前試用Spike的時候，我們發(fā)現(xiàn)這些信息以xml格式存入文件，數(shù)據(jù)冗余度很高，導(dǎo)致幾個測試下來，文件已經(jīng)非常大了。這顯然不是我們想看到的。因此在數(shù)據(jù)存儲的時候，我們直接將數(shù)據(jù)做json格式的序列化，字符串形式存在文件中，大大減少了文件大小。與此同時，我們再通過請求來源的IP和日期作為分隔，分別存儲不同的文件。這樣，來自每個機器每天的請求數(shù)據(jù)都能一目了然，向著“精準”的方向又邁進了一步，可以對測試人員的每個請求做精確的監(jiān)控。下圖是我們在業(yè)務(wù)實踐中搜集的部分數(shù)據(jù)文件截圖：

4. 報告生成

這樣，來自任何一個IP的每一次Web請求，它所覆蓋的行和函數(shù)信息，都會被記錄到文件中。對于一般的項目測試中，也就只有幾個測試人員在使用，所以不需要考慮一些性能問題。

　　上面講了生成覆蓋率數(shù)據(jù)的原理，不過我們至此獲得的只是一份份的數(shù)據(jù)文件，如何匯總成一份完整的報告呢?這就需要我們自己來寫一段腳本解析剛才生成的數(shù)據(jù)文件了。我們的做法是借鑒了開源工具spike phpcoverage的模版，并加入自己的代碼邏輯，特別是加入了該工具所不具有的函數(shù)覆蓋率統(tǒng)計數(shù)據(jù)。我們自己測試的web頁面生成的報告如下：

　　圖中可以看到每個文件的行覆蓋率，函數(shù)覆蓋率，還有總的覆蓋率統(tǒng)計數(shù)據(jù)。假如需要更精確的數(shù)據(jù)，可以點進文件連接，查看到底覆蓋的是哪些代碼行(藍色為覆蓋，紅色為未覆蓋)：

 

　　業(yè)務(wù)測試中做Web測試時，對代碼的覆蓋率是衡量測試質(zhì)量的重要指標。我們希望通過此方法做到盡量地“精準”，測試執(zhí)行完后可以精確看到哪一行代碼被執(zhí)行過，哪一行沒被執(zhí)行過。分析沒被執(zhí)行過的原因，從而改進測試用例。使用工具的流程也很簡單，插樁=>測試=>搜集數(shù)據(jù)=>出報告。并且此解決方案最大化地減少了對業(yè)務(wù)代碼的影響，只需要改一行代碼即可。即便中間出現(xiàn)了問題，也可以快速將代碼恢復(fù)為原來的樣子。讓測試放心，讓開發(fā)也放心。

　　不過，最后還需要強調(diào)的一點是，并不是說覆蓋了所有的代碼，就證明測試已經(jīng)完整了。只不過沒被覆蓋的話，一定是不完整的。所以這個方案最大的意義在于能夠發(fā)現(xiàn)測試中一些遺漏的代碼，找到一部分問題。其實，它也可以幫助新來的員工理解整個項目代碼結(jié)構(gòu)，我們可以清晰的知道，自己的每一次瀏覽器請求，到底在運行服務(wù)器上的哪些代碼。