回歸測試對保證軟件質量具有重要意義。要實現有效的回歸測試，必須解決回歸測試中的兩個主要問題：
(1)測試用例的優化選擇;
(2)覆蓋率分析。前者決定了回歸測試的效率，好的測試用例的選擇可以用少量的測試用例準確地覆蓋新版本中盡可能多的改動。后者是度量測試的重要指標，通過達到良好的測試覆蓋率，保證了回歸測試的質量。
本文正是通過討論如何優化選擇測試用例，用最小的代價達到最大的覆蓋率，從而找到回歸測試的有效解決方案。
存在的問題
測試用例的優化選擇
對測試用例的選擇，測試人員通常有兩種作法。一種是，把相關的或是所有的模塊的測試用例都選出來執行一遍;另一種是，僅針對被 Fixed 的 APAR/Defect 進行檢驗，測試用例很少或是開發新的針對這個 Fixed 的測試用例。這兩種方法都存在不足。第一種方法在測試時間有限的情況下，去執行所有的測試用例，會測試到很多無需再測試的測試用例，從而導致測試資源的浪費;第二種是很難確保 APAR/Defect 改動后，被測系統沒有受到關聯影響，很難保證測試質量。
由于 Bug Fix 或者功能更新后，在新版本發布之前，我們要確保所作改動不會對已有的功能模塊產生負面的影響。用所有的測試用例作回歸測試， 存在著人力與時間成本過高的問題;依靠人的經驗去挑選回歸測試用例，存在著挑選不準確或對程序改動測試覆蓋不全的問題。
圖 1. 測試用例優化選擇問題
回歸測試覆蓋率分析
測試用例優化選擇可以有效地解決現有測試用例的覆蓋問題，但在實際測試過程中，我們仍然發現存在著覆蓋不全的問題。即新版本中的某些實現并不能被現有的測試用例所覆蓋。這樣，測試人員需要開發新的測試用例對新的功能進行測試覆蓋。然后對于測試人員來說這并不實際，他們很難依靠測試經驗將代碼中沒有被測試的地方找出來。那么如何更好的得到測試過程中的測試覆蓋率，及測試結束后整個軟件的測試覆蓋率呢，從而使得測試人員可以針對未被測試到的地方設計新的測試用例。這里我們特別針對在版本更新過程中，那些發生了更新卻沒有被覆蓋到的地方。
解決問題
原理
圖 2. 測試用例優化選擇原理
圖 3. 測試用例優化選擇舉例
如上圖所示，所有的測試用例都會有一個函數調用的路徑。我們把這些調用路徑一一記下來。對于新版本所作的改動，所有與之相關的上層調用的測試用例都能夠準確地選出來，這樣我們就能用這些準確的測試用例來覆蓋這次改動所產生的影響。毫不相關的測試用例則不會被選出來。從而用較小的成本完成這次改動所需要的回歸測試，既省時省力又保證較高的測試質量。
圖 4. 覆蓋率分析舉例
如上圖所示，在版本更新過程中受到影響的測試用例為 Test Case1， Test Case2， Test Case3 覆蓋了 12 個 Node，在版本更新過程中的更新點是 4，其中被覆蓋到的為 3，還有 1 個更新點沒有被覆蓋到，現有測試用例集合的更新覆蓋能力為 75% 。這樣，我們知道上一個版本的測試用例設計不夠充分尚有程序模塊沒有被任何已有的測試用例所覆蓋。由于代碼的更新最有可能引起程序的缺陷甚至系統崩潰，所以需要添加新的測試用例以保證對更新的覆蓋，以降低程序運行的風險。
對于軟件的節點覆蓋率，我們細化到函數粒度。我們是通過軟件部署的 Binary 代碼分析得知的函數情況。不需要借助源代碼，因此對于軟件進行測試覆蓋率分析來說要求低，用較小的成本完成此次的測試用例覆蓋反饋與分析。既省時省力又保證較高的測試質量。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
