迴歸測試最佳實踐

迴歸測試最佳實踐

http://www.sina.com.cn   2009年09月01日 10:35   IT168.com
<!-- 正文內容 begin --><!-- google_ad_section_start -->
<!-- 正文內部文字導航 : begin --><!-- 正文內部文字導航 : end --><!-- 內容模塊:單圖 begin --><!-- 內容模塊:單圖 end --><!-- 內容模塊:段落 begin --><!-- <div class="moduleParagraph"> --><!-- publish_helper name='原始正文' p_id='2' t_id='1' d_id='3400104' f_id='2' -->文本Tag: 迴歸測試

  【IT168 技術文檔】本文介紹一個有效的解決方案,可以提高迴歸測試的效率與質量。它解決了迴歸測試中的兩個主要問題:如何優化迴歸測試用例以及分析覆蓋率。

  迴歸測試對保證軟件質量具有重要意義。要實現有效的迴歸測試,必須解決迴歸測試中的兩個主要問題:

  (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 個主要步驟。一是測試用例的錄入;二是對新舊兩個版本的變更分析;三、通過測試用例優化選擇和覆蓋率分析,得到相應的測試用例優化選擇報告,和覆蓋率分析報告。

  圖 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

  總函數 變更函數 覆蓋數 未覆蓋 覆蓋率 108 12 10 2 83.3%

  表 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 就需要測試人員對之進行分析並且添加新的測試用例以提高我們的測試覆蓋率 , 保證測試質量。

  總結

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

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