迴歸測試最佳實踐--迴歸測試用例的優化選擇與覆蓋率分析

From:http://www.ibm.com/developerworks/cn/java/j-lo-regtest/

迴歸測試對保證軟件質量具備重要意義。要實現有效的迴歸測試，必須解決迴歸測試中的兩個主要問題：（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 代碼分析得知的函數狀況。不須要藉助源代碼，所以對於軟件進行測試覆蓋率分析來講要求低，用較小的成本完成這次的測試用例覆蓋反饋與分析。既省時省力又保證較高的測試質量。

解決方案

基於對問題 1) 和問題 2) 的原理分析，咱們設計並實施了迴歸測試的解決方案，以下圖所示。它包含了 3 個主要步驟。一是測試用例的錄入；二是對新舊兩個版本的變動分析；3、經過測試用例優化選擇和覆蓋率分析，獲得相應的測試用例優化選擇報告，和覆蓋率分析報告。

圖 5. 迴歸測試解決方案

步驟一， Trace Test Case 負責錄製測試用例，並將捕獲到的測試用例的 Runtime Trace 存放到數據庫中；

測試用例在後臺運行中的 Runtime Trace 是動態分析 (Dynamic Analysis) 中的重要信息。這些實際的運行信息爲測試用例的優化選擇和覆蓋率分析創造了條件。下面是測試用例跟蹤的框架圖：

圖 6. 測試用例跟蹤的框架圖

從上圖咱們能夠看出，測試人員觸發 Trigger 以後，會啓動 Agent Controller 。 Agent Controller 一直對 JVM 中的 JVMTI 進行監聽，以獲取部署在 JVM 上的被測應用程序。這些 Agent Controller 還負責將收集到的數據傳輸給 Data Collector 。又 Data Collector 將這些 Runtime Trace 寫入以下表所示的數據庫表中。

注意：函數的 Signature 信息做爲函數的參數標識也須要記錄下來。以區別同名不一樣參數的函數。

步驟二， Change Analysis 用於將新舊兩個版本做比較，獲得 Change Report，即程序變動報告，能夠精確到 Method 粒度。通常來講代碼變動有 4 種級別，分別爲包級別 (Package)，類級別 (Class)，函數級別 (Method) 及語句級別 (Statement) 。

對於包級別和類級別來講，比較的力度過粗，會影響到迴歸測試優化的質量。而函數級別和語句級別都能起到很好的迴歸測試的做用。其中語句級別由於粒度最細，等到的分析結果也最精確，迴歸測試質量最高。但與函數級別的變動分析相比，迴歸測試的質量相差頗有限，但形成了過多的執行時間代價，影響了迴歸分析的效率。所以咱們採用函數級別的變動分析做爲迴歸測試的變動粒度。

肯定比較粒度以後，能夠選擇分析比較的方法。最簡單的經常使用比較方法就是文本比較。包括源代碼和可執行文件 (binary code) 的文本比較。根據 Java 語言面向對象的特色，還能夠採用基於面向對象分析的比較方法。後者獲得的分析粒度更細，可是所花的代價也越高。

步驟三， 在經過測試用例錄製獲得測試用例具體的 Runtime Trace 信息，以及經過 Change 分析獲得新舊兩個版本的變動信息以後，咱們能夠對測試用例優化問題及覆蓋率分析問題進行求解。

Test Case Prioritization 中，經過測試用例與運行的 Runtime Trace 進行匹配獲得相關的測試用例。並利用測試用例優化排序算法對相關的測試用例進行排序，獲得優化結果。如今的優化排序算法有多種，這裏不對優化排序算法進行討論。

Coverage Analysis 中，經過對已被相關測試用例覆蓋的 Method 數量，及未被測試用例覆蓋到的 Method 數量的分析，能夠獲得基於代碼更新的覆蓋率報告。測試人員獲得這份報告以後，能夠找到未被覆蓋到的 Method，並對其進行鍼對性的開發新的測試用例。以完成對新功能的覆蓋。

咱們能夠看到步驟一，二共同服務於測試用例優化選擇和覆蓋率分析兩個模塊。有了測試用例的 Runtime Trace 和 Change Report. 咱們能夠將 Change 結果與 Runtime Trace 進行匹配，找出能覆蓋程序更改的測試用例。一樣，對於沒有被測試用例覆蓋到的 Change 部分。因爲沒有相關測試用例被找出，咱們現有的測試用例是不足的，須要針對未被覆蓋到的 Change 部分開發新的測試用例。

而覆蓋率做爲軟件測試的一項重要指標，能夠根據已經獲得覆蓋和未被覆蓋的 method 進行求解，即已獲得覆蓋的 change method 數與總的 change method 之比。

結果

基於以上的迴歸測試解決方案，咱們對一個有着 30 個測試用例的程序進行迴歸測試，獲得以下測試用例優化選擇分析報表：

Change Analysis Report

表 1 優化選擇測試用例: 3 (of Total 30)

分析報告顯示此次代碼變動共有 12 個函數發生了更改。在 30 個測試用例中有 3 個測試用例與這些更改相關，它們覆蓋了此次代碼更改 12 箇中的 10 個。而其它 27 的測試用例則與這 12 個代碼改動絕不相關。

表 2 迴歸測試結果分析

從表中咱們能夠看到，通過測試用例優化選擇以後，咱們選出了 3 個和函數變動相關的測試用例，達到了 83.3% 的覆蓋率。同時因爲 27 個與函數變動無關的測試用例不須要重測，使得 90% 的迴歸測試資源獲得了節省。

圖 7. 覆蓋率分析

從上圖，咱們能夠清楚地看到基於每一個函數改動的相關測試用例的數目，以及測試覆蓋率。好比 ManageCommodityAction 這個 Class 裏面，存在了 2 個 Change Method, 只有 1 個 changed method 被現有的 1 個 Test Case 所覆蓋，測試覆蓋率爲 50% 。

上面分析報告中總共有 12 個函數發生改動，基中還有 2 個沒有被任何測試用例覆蓋到。那麼未被覆蓋的 Change Method 就須要測試人員對之進行分析而且添加新的測試用例以提升咱們的測試覆蓋率 , 保證測試質量。

回頁首

總結

迴歸測試用例的優化選擇，以最少的測試用例，準確地覆蓋所做改動，極大地提升了咱們迴歸測試的測試效率與測試質量。

自動測試過程當中的覆蓋率反饋分析，以最小的測試代價，最精確的分析，來得到當前的測試完成狀況，爲測試人員提升了良好的分析報告，以便測試人員改進和新增新的測試用例。大大提升了迴歸測試的測試效率與質量。

免責說明

本文不帶有任何明示或暗含的保證。文章提供的建議或最佳實踐只做爲通常的經驗分享，做者不保證這些建議或最佳實踐在任何狀況下都有效。本文中任何帶有主觀性的陳述都只表明本文做者我的的觀點，不表明 IBM 公司的官方立場。相關細節，請直接諮詢做者。

參考資料

學習

• 「Rational Edge: 加快回歸測試的步伐：累積測試分析和目標測試入門」 （developerWorks，2006 年 10 月）：本文來自於 Rational Edge：一般所說的「累積測試分析（Cumulative Test Analysis）」技術向軟件測試團隊提供了對自動化測試更合理的方法，特別是在迴歸測試集的領域內。理解 CTA 如何提升您的測試效率。
• 「基於 RFT 和 STAF 進行的無需人工干預的跨平臺自動化迴歸測試」（developerWorks，2008 年 8 月）：本文隨着迴歸測試的自動化程度不一樣，而結合 Rational Functional Tester (RFT) 進行無需人工干預的跨平臺併發自動化迴歸測試。
• 瀏覽 技術書店獲取關於這些主題和其餘技術主題的書籍。
• developerWorks Java 技術專區：查找數百篇有關 Java 編程各方面的文章。

討論

• 參與 developerWorks blogs 並加入 developerWorks 社區。

做者簡介

鄧俊寧，軟件工程師，IBM CDL TAAS (Test as a Service) Competency Center 部門。從 2000 年開始從事 IT 軟件開發設計工做，在 Java 和 Web 開發方面有豐富的經驗。如今 IBM 軟件開發中心從事軟件測試工做，是 TAAS 自動化測試工做組的核心成員之一。

黃勝，研究員，IBM CRL Service Building Technology(SBT) 部門。如今 IBM CRL SBT 測試小組從事研究工做，是測試小組核心成員之一。迴歸測試解決方案的主要設計人員和開發團隊 Leader。

陳暘，IBM 中國研究院實習生。迴歸測試解決方案開發團隊的主要成員之一。