軟體測試學習教程—迴歸測試

迴歸測試整理總結

　　目錄

　　一、迴歸測試的定義.-2-

　二、迴歸測試的目的.-2-

　　三、百度百科中對迴歸的說明.-2-

　　1.維護測試用例庫.-2-

　　2.選擇迴歸策略.-3-

　　四、ISTQB解釋.-4-

　　3.迴歸測試的範圍.-4-

　　五、在缺陷跟蹤中的位置

軟體迴歸測試

一、迴歸測試的定義

 

迴歸測試 regression  testing系統或部件選擇的重新測試，用以驗證修改未引起不希望的有害效果，或證明修改後的系統或系統部件仍滿足規定的需求。——《GB/T 11457-2006 資訊科技 軟體工程術語》 2.1329

軟體修改後，重新測試以前測試過的程式，確保更改沒有給軟體其他未更改部分帶來新的缺陷。軟體修改後或使用環境變更後要執行迴歸測試。                           ——《軟體測試基礎教程（ISTQB指定教材）》

 

二、迴歸測試的目的

 

測試軟體變更後，變更部分的正確性和對變更需求的符合性；測試軟體變更後，軟體原有的、正確的功能、效能和其他規定的要求的不損害性。——《GB/T 15532-2008 計算機軟體測試規範》

 

 

三、百度百科中對迴歸的說明

 

迴歸測試是指修改了舊程式碼後，重新進行測試以確認修改沒有引入新的錯誤或導致其他程式碼產生錯誤。迴歸測試作為軟體生命週期的一個組成部分，在整個軟體測試過程中佔有很大的工作量比重，軟體開發的各個階段都會進行多次迴歸測試。在漸進和快速迭代開發中，新版本的連續釋出使迴歸測試進行的更加頻繁，而在極端程式設計方法中，更是要求每天都進行若干次迴歸測試。因此，透過選擇正確的迴歸測試策略來改進迴歸測試的效率和有效性是非常有意義的。自動迴歸測試將大幅降低系統測試、維護升級等階段的成本。

 

1.   維護測試用例庫

 

對於一個軟體開發專案來說，專案的測試組在實施測試的過程中會將所開發的測試用例儲存到“測試用例庫”中，並對其進行維護和管理。當得到一個軟體的基線版本時，用於基線版本測試的所有測試用例就形成了基線測試用例庫。在需要進行迴歸測試的時候，就可以根據所選擇的迴歸測試策略，從基線測試用例庫中提取合適的測試用例組成迴歸測試包，透過執行迴歸測試包來實現迴歸測試。儲存在基線測試用例庫中的測試用例可能是自動測試指令碼，也有可能是測試用例的手工實現過程。

 

測試用例庫的維護。為了最大限度地滿足客戶的需要和適應應用的要求，軟體在其生命週期中會頻繁地被修改和不斷推出新的版本，修改後的或者新版本的軟體會新增一些新的功能或者在軟體功能上產生某些變化。隨著軟體的改變，軟體的功能和應用介面以及軟體的實現發生了演變，測試用例庫中的一些測試用例可能會失去針對性和有效性，而另一些測試用例可能會變得過時，還有一些測試用例將完全不能執行。為了保證測試用例庫中測試用例的有效性，必須對測試用例庫進行維護。同時，被修改的或新增添的軟體功能，僅僅靠重新執行以前的測試用例並不足以揭示其中的問題，有必要追加新的測試用例來測試這些新的功能或特徵。因此，測試用例庫的維護工作還應包括開發新測試用例，這些新的測試用例用來測試軟體的新特徵或者覆蓋現有測試用例無法覆蓋的軟體功能或特徵。

 

2.    選擇迴歸策略

 

在軟體生命週期中，即使一個得到良好維護的測試用例庫也可能變得相當大，這使每次迴歸測試都重新執行完整的測試包變得不切實際。一個完全的迴歸測試包括每個基線測試用例，時間和成本約束可能阻礙執行這樣一個測試，有時測試組不得不選擇一個縮減的迴歸測試包來完成迴歸測試。

 

迴歸測試的價值在於它是一個能夠檢測到迴歸錯誤的受控實驗。當測試組選擇縮減的迴歸測試時，有可能刪除了將揭示迴歸錯誤的測試用例，消除了發現迴歸錯誤的機會。然而，如果採用了程式碼相依性分析等安全的縮減技術，就可以決定哪些測試用例可以被刪除而不會讓迴歸測試的意圖遭到破壞。

 

選擇迴歸測試策略應該兼顧效率和有效性兩個方面。常用的選擇迴歸測試的方式包括：

 

(1) 、再測試全部用例

 

選擇基線測試用例庫中的全部測試用例組成迴歸測試包，這是一種比較安全的方法，再測試全部用例具有最低的遺漏迴歸錯誤的風險，但測試成本最高。全部再測試幾乎可以應用到任何情況下，基本上不需要進行分析和重新開發，但是，隨著開發工作的進展，測試用例不斷增多，重複原先所有的測試將帶來很大的工作量，往往超出了我們的預算和進度。

 

(2) 、基於風險選擇測試

 

可以基於一定的風險標準來從基線測試用例庫中選擇迴歸測試包。首先執行最重要的、關鍵的和可疑的測試，而跳過那些非關鍵的、優先順序別低的或者高穩定的測試用例，這些用例即便可能測試到缺陷，這些缺陷的嚴重性也僅有三級或四級。一般而言，測試從主要特徵到次要特徵。

 

(3) 、基於操作剖面選擇測試

 

如果基線測試用例庫的測試用例是基於軟體操作剖面開發的，測試用例的分佈情況反映了系統的實際使用情況。迴歸測試所使用的測試用例個數可以由測試預算確定，迴歸測試可以優先選擇那些針對最重要或最頻繁使用功能的測試用例，釋放和緩解最高階別的風險，有助於儘早發現那些對可靠性有最大影響的故障。這種方法可以在一個給定的預算下最有效的提高系統可靠性，但實施起來有一定的難度。

 

 (4) 、再測試修改的部分

 

當測試者對修改的區域性化有足夠的信心時，可以透過相依性分析識別軟體的修改情況並分析修改的影響，將回歸測試侷限於被改變的模組和它的介面上。通常，一個迴歸錯誤一定涉及一個新的、修改的或刪除的程式碼段。在允許的條件下，迴歸測試儘可能覆蓋受到影響的部分。

 

再測試全部用例的策略是最安全的策略，但已經執行過許多次的迴歸測試不太可能揭示新的錯誤，而且很多時候，由於時間、人員、裝置和經費的原因，不允許選擇再測試全部用例的迴歸測試策略，此時，可以選擇適當的策略進行縮減的迴歸測試。

 

 

 

四、  ISTQB解釋

—— 摘抄自《軟體測試基礎教程》第2版 3.7.4 與變更有關的測試和迴歸測試

 

當已有的系統發生變化、缺陷被修正或者增加了新功能時，變化的部分必須進行再測試（retest）。另外，還存在變化導致副作用的風險。為了解決這些問題，需要重新執行已有的測試用例。這些測試稱為迴歸測試。

 

迴歸測試是在程式被修改後重新進行測試的過程，以保證這個修改沒有引入或暴露故障。這樣的故障經常是因為程式修改而引起計劃外的副作用造成的。這就意味著迴歸測試可以在所有的測試基本執行，並應用到功能測試、非功能測試和結構測試（structural testing）中。迴歸測試中使用的測試用例會多次執行，因而必須很好地進行文件化，並使之具有可重用性。因此它們通常是測試自動化（test automation）的物件。

 

3.       迴歸測試的範圍

在進行迴歸測試的時候，必須決定迴歸測試的範圍。下面是對可能的範圍的一些建議：（1）重新執行所有發現故障的測試，而新的軟體版本已經修正了這些故障（缺陷再測試、確認測試）。（2）測試所有修改或修正過的程式部分（功能改變的測試）。（3）測試所有新整合的程式（新功能測試）。（4）測試整個系統（完全迴歸測試）。

 

方法（1）中只進行了很少的再測試，而方法（2）和方法（3）中只對修改的部分進行再測試，這樣的測試是不夠的，因為在軟體系統中原生程式碼的修改可能導致系統其他部分（不確定距離）的副作用。如果測試只覆蓋變化或新的程式碼部分，那麼測試就忽略了修改部分對沒有修改部分的影響。軟體的麻煩是他的複雜性，在合理的成本下，只能粗略的估計這樣的影響可能在哪些地方發生。對於沒有充足文件或需求遺漏的系統進行修改就顯得尤其困難，不幸的是，這種情況在已有的系統中經常發生。除了對修正的缺陷和功能發生變化的部分進行再測試，還應該重新執行已有的所有測試用例。只有這樣，現在的測試才和對原程式版本的測試一樣安全。如果變化的系統環境對系統的所有部分都有影響的話，還應該執行完全迴歸測試。

 

實際中，完全迴歸測試通常是非常耗時間，成本很高。因而需要尋找一些標準以幫助選擇可以忽略哪些舊的測試用例，而不會丟失太多的資訊。在測試過程中，這樣通常意味著風險和成本的平衡。決定這種平衡的最好辦法就是對變更進行影響分析，儘量決定副作用可能在哪兒發生。下面的策略經常會用以判斷：☆ 只重複測試計劃中的高優先順序的測試。☆ 在功能測試中，忽略特定的變化（特別的例子）。☆ 只針對特定配置進行測試（例如：只對英文產品版本進行測試，只對作業系統的一個版本測試）。☆ 只針對特定子系統或測試級別進行測試。

 

這些列出的標準通常主要針對系統測試。在更低的測試級別，迴歸測試標準可以同樣基於設計或架構文件（例如，類層次）或白盒資訊。更多資訊可見[Kung 95]、[Rothermel 94]、[Winter 98]和[Binder 99]。這些文件中作者不僅描述了在物件導向程式中迴歸測試面臨的特殊問題，還詳細的描述了迴歸測試的通用準則。

 

五、        在缺陷跟蹤中的位置

當缺陷修復後，在對新版本的“迴歸測試”中，驗證缺陷是否修復成功，如果缺陷修復成功，將缺陷狀態置為“關閉 Closed”，否則置為“重新開啟 Reopen”。