隨著軟件規模的不斷擴大，回歸測試在測試中占據越來越大的比例。讓人痛心的是，一個很小的改動，也許是幾行代碼，也許只是1，2個小時的開發工時，為了線上質量的穩定，我們需要完成整整一套相關產品回歸測試和冒煙測試的工作，這讓測試的工時大大高于開發的公時，有些時候甚至是開發工時的好多倍的時間，于是在項目kickoff上常見的一幕是項目經理非常疑惑的看著測試：“需要這么長時間的測試嗎？一個小的改動需要這么長的時間嗎？可以不做全面回歸嗎？”然后測試很無奈的回答：“需要，真的需要，不做回歸有風險。”于是，能否合理的判斷回歸范圍變成了考核測試人員的一個很大的標準。但是如何合理的確認回歸的范圍，如何在對質量提供保證的同時提高測試的效率。在這里提供一個利用函數覆蓋來確認回歸測試用例的科學方法。
　　現階段市場上能提供函數覆蓋的工具已經很多了。比較普遍的針對java語言的有clover，針對C++語言的有gcov，這些工具都提供統計了函數覆蓋的覆蓋率的功能，也是說在你執行任何一個testcase之后，工具會告訴你這個testcase 覆蓋了系統中的哪些函數。對于shell或者php的簡單腳本我們找不到合適的工具，簡單的方法是每掃描到個函數在函數中加入一句“打印函數名稱”的代碼。這個是簡單的代碼插入的原理了。
　　如何用函數覆蓋來確定回歸測試的范圍呢？好無疑問，在第一輪測試的時候，函數覆蓋工具是無法確認測試范圍的。只能在函數覆蓋未有完全覆蓋的時候提供測試用例不足或者有冗余代碼的信息，但是通過第一輪的測試我們很容易得出下面的一張對應關系圖：其中覆蓋的部分我們寫1，不覆蓋的部分我們寫0.
　　測試用例與函數覆蓋關系圖
　　測試用例1 測試用例2 測試用例3 測試用例4 測試用例……
　　函數1 1 0 1 0 0函數2 0 1 0 1 0函數3 1 1 0 0 0函數4 0 0 1 0 1函數…… …… …… …… …… ……
　　在上張表格完成之后，在第二輪測試之前，我們需要用svn diff來確認開發代碼這一輪和上一輪的改動在哪些函數上。將改動函數的整行從測試用例與函數覆蓋關系圖提取出來，形成測試用例與函數覆蓋關系圖的一個子集，再將這個子集的表格按列取或，終結果為1的測試用例是需要回歸的測試用例，為0的測試用例是不需要回歸的測試用例。比如svn diff的結果是函數1和函數3發生了變化，那么按照上圖的關系。我們終的結果如下表所示：
　　需要回歸測試用例計算圖
　　改動的函數 測試用例1 測試用例2 測試用例3 測試用例4 測試用例……
　　函數1 1 0 1 0 0函數3 1 1 0 0 0或的結果 1 1 1 0 0
　　通過這個計算的邏輯我們可以看到，通常改動涉及的函數越少，需要回歸的測試用例越少，這和傳統的思維邏輯也很接近，但是如果這個函數是main函數或者在流程圖中是必經之路，那么意味著所有的testcase的允許都必須經過這些關鍵函數，這些函數的任意改動都必須經過所有testcase回歸，這會變成回歸測試中頭痛的地方吧。
　　現階段測試人員對測試覆蓋率的重視還不是很強，主要在于覆蓋率本身而言對測試來說沒有提供多大的便利。但是隨著對測試覆蓋率的加工統計，如果能在測試效率上證明對大量的測試是能夠節省工時提高效率的時候，相信是覆蓋率工具真正被使用起來的時候。