一、 概述

在軟體生命週期中的任何一個階段，只要軟體發生了改變，就可能給該軟體帶來問題。軟體的改變可能是源於發現了錯誤並做了修改，也有可能是因為在整合或維護階段加入了新的模組。當軟體中所含錯誤被發現時，如果錯誤跟蹤與管理系統不夠完善，就可能會遺漏對這些錯誤的修改；而開發者對錯誤理解的不夠透徹，也可能導致所做的修改只修正了錯誤的外在表現，而沒有修復錯誤本身，從而造成修改失敗；修改還有可能產生副作用從而導致軟體未被修改的部分產生新的問題，使本來工作正常的功能產生錯誤。同樣，在有新程式碼加入軟體的時候，除了新加入的程式碼中有可能含有錯誤外，新程式碼還有可能對原有的程式碼帶來影響。因此，每當軟體發生變化時，我們就必須重新測試現有的功能，以便確定修改是否達到了預期的目的，檢查修改是否損害了原有的正常功能。同時，還需要補充新的測試用例來測試新的或被修改了的功能。為了驗證修改的正確性及其影響就需要進行迴歸測試。

迴歸測試在軟體生命週期中扮演著重要的角色，因忽視迴歸測試而造成嚴重後果的例子不計其數，導致阿里亞娜5型火箭發射失敗的軟體缺陷就是由於複用的程式碼沒有經過充分的迴歸測試造成的。

迴歸測試作為軟體生命週期的一個組成部分，在整個軟體測試過程中佔有很大的工作量比重，軟體開發的各個階段都會進行多次迴歸測試。在漸進和快速迭代開發中，新版本的連續釋出使迴歸測試進行的更加頻繁，而在極端程式設計方法中，更是要求每天都進行若干次迴歸測試。因此，通過選擇正確的迴歸測試策略來改進迴歸測試的效率和有效性是非常有意義的。

二、 迴歸測試策略

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

迴歸測試需要時間、經費和人力來計劃、實施和管理。為了在給定的預算和進度下，儘可能有效率和有效力地進行迴歸測試，需要對測試用例庫進行維護並依據一定的策略選擇相應的迴歸測試包。

1、測試用例庫的維護

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

測試用例的維護是一個不間斷的過程，通常可以將軟體開發的基線作為基準，維護的主要內容包括下述幾個方面。

(1)、刪除過時的測試用例

因為需求的改變等原因可能會使一個基線測試用例不再適合被測試系統，這些測試用例就會過時。例如，某個變數的界限發生了改變，原來針對邊界值的測試就無法完成對新邊界測試。所以，在軟體的每次修改後都應進行相應的過時測試用例的刪除。

(2)、改進不受控制的測試用例

隨著軟體專案的進展，測試用例庫中的用例會不斷增加，其中會出現一些對輸入或執行狀態十分敏感的測試用例。這些測試不容易重複且結果難以控制，會影響迴歸測試的效率，需要進行改進，使其達到可重複和可控制的要求。

(3)、刪除冗餘的測試用例

如果存在兩個或者更多個測試用例針對一組相同的輸入和輸出進行測試，那麼這些測試用例是冗餘的。冗餘測試用例的存在降低了迴歸測試的效率。所以需要定期的整理測試用例庫，並將冗餘的用例刪除掉。

(4)、增添新的測試用例

如果某個程式段、構件或關鍵的介面在現有的測試中沒有被測試，那麼應該開發新測試用例重新對其進行測試。並將新開發的測試用例合併到基線測試包中。

通過對測試用例庫的維護不僅改善了測試用例的可用性，而且也提高了測試庫的可信性，同時還可以將一個基線測試用例庫的效率和效用保持在一個較高的級別上。

2、迴歸測試包的選擇

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

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

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

(1)、再測試全部用例

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

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

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

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

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

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

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

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

3、迴歸測試的基本過程

有了測試用例庫的維護方法和迴歸測試包的選擇策略，迴歸測試可遵循下述基本過程進行:

(1). 識別出軟體中被修改的部分；

(2). 從原基線測試用例庫T中，排除所有不再適用的測試用例，確定那些對新的軟體版本依然有效的測試用例，其結果是建立一個新的基線測試用例庫T0。

(3). 依據一定的策略從T0中選擇測試用例測試被修改的軟體。

(4). 如果必要，生成新的測試用例集T1，用於測試T0無法充分測試的軟體部分。

(5). 用T1執行修改後的軟體。

第(2)和第(3)步測試驗證修改是否破壞了現有的功能，第(4)和第(5)步測試驗證 修改工作本身。

三、 迴歸測試實踐

在實際工作中，迴歸測試需要反覆進行，當測試者一次又一次地完成相同的測試時，這些迴歸測試將變得非常令人厭煩，而在大多數迴歸測試需要手工完成的時候尤其如此，因此，需要通過自動測試來實現重複的和一致的迴歸測試。通過測試自動化可以提高迴歸測試效率。為了支援多種迴歸測試策略，自動測試工具應該是通用的和靈活的，以便滿足達到不同迴歸測試目標的要求。

在測試軟體時，應用多種測試技術是常見的。當測試一個修改了的軟體時，測試者也可能希望採用多於一種迴歸測試策略來增加對修改軟體的信心。不同的測試者可能會依據自己的經驗和判斷選擇不同的迴歸測試技術和策略。

迴歸測試並不減少對系統新功能和特徵的測試需求，迴歸測試包應包括新功能和特徵的測試。如果迴歸測試包不能達到所需的覆蓋要求，必須補充新的測試用例使覆蓋率達到規定的要求。

迴歸測試是重複性較多的活動，容易使測試者感到疲勞和厭倦，降低測試效率，在實際工作中可以採用一些策略減輕這些問題。例如，安排新的測試者完成手工迴歸測試，分配更有經驗的測試者開發新的測試用例，編寫和除錯自動測試指令碼，做一些探索性的或ad hoc測試。還可以在不影響測試目標的情況下，鼓勵測試者創造性地執行測試用例，變化的輸入、按鍵和配置能夠有助於激勵測試者又能揭示新的錯誤。

在組織迴歸測試時需要注意兩點，首先是各測試階段發生的修改一定要在本測試階段內完成迴歸，以免將錯誤遺留到下一測試階段。其次，迴歸測試期間應對該軟體版本凍結，將回歸測試發現的問題集中修改，集中迴歸。

在實際工作中，可以將回歸測試與相容性測試結合起來進行。在新的配置條件下執行舊的測試可以發現相容性問題，而同時也可以揭示編碼在迴歸方面的錯誤。

參考文獻：

[1] Glenford J.Myers，計算機軟體測試技巧，清華大學出版社，1985。

[2] Robert V. Binder，面向物件系統的測試，人民郵電出版社，2001。

[3] Rex Black， 測試流程管理，北京大學出版社，2001。

來源：賽寶軟體評測中心 作者：資訊產業部電子第五研究所 李丹 劉傑