回歸測試漫談

　　眾所周知軟件測試這個職業有一個為從業者不悅的一個特點就是有時特別煩瑣,要經常做重復性的東西,相信同行或多或少都會有這個感慨,而罪魁禍首就是回歸測試.如果每次測試的功能點都是新的,每次執行的測試用例都是未曾執行過的話,我相信同行都不會覺得厭煩反而很有興致想看下新的功能是怎樣的,執行起用例來也特認真.我也是如此,如果做久了一個項目特別是總是推遲發布的話每天就祈禱著當前項目快點了結.一接到新項目就有如獲新生的感覺...確實回歸測試次數多了,測試員不由變得煩躁起來,特別如果是回歸測試策略又不妥當的話簡直令人發瘋....

　　我深受其害.進新公司近半年來還沒有完全是自己負責的項目,除了花了一定的時間做自動化方面的東西外,其它的時間就是執行測試用例了,當然也就有大量的回歸測試了.更郁悶的是沒有相應的回歸測試策略,而且不少測試用例已經不再適用了,數量又多(以前新功能測試的用例),我逐漸變得厭煩,然后是麻木,最后幾近崩潰.一個汗啊...痛苦泥潭中的只好搜索相關資料并結合自己的實踐,總結下如何更有效地做回歸測試,讓回歸測試做得更有意義.

　　所謂回歸測試就是當軟件發生改變時,重新測試已經通過測試的測試區域,以驗證修改的正確性及其影響.其實我們做測試的大部分工作也是在做回歸測試,嚴格按照定義的話一旦軟件作了修改就必須進行回歸測試.我想對修改過后的軟件要進行回歸測試應該就是無可厚非的,無論是教科書上的介紹還是前人的經驗總結都知道回歸測試的必要性與重要性.那非要做回歸測試,那樣怎樣才能做得更為有效有意義呢?顯然這都需要從測試用例著手.

　　首先我們必須有個管理良好的測試用例庫,這個用例庫中的所有用例必須是有效的,有達到足夠的覆蓋率,并且是容易查找組織的.這需要有良好的測試管理工具, 并有相應的資源(時間與人力)去維護這個測試用例庫,務必使其中沒有過時,冗余的測試用例,并達到一定的覆蓋率.如何管理組織好測試用例已是一個很值得深入研究的課題,在此不再闡述(我也沒有很好的見解..)總之,要做好回歸測試,組織管理良好的測試用例庫是前提.

　　有了測試用例庫,那我做回歸測試時就執行所有有效的測試用例?這個沒有絕對的答案,在很多的時候如果你有足夠的資源用全部測試用例來做回歸測試是最佳選擇. 但現實中呢?有足夠資源這個理想狀態比較少,并且有些時候也沒有必要這樣做.如果只是修改了某個警告對話框中的單詞就要執行完所有測試例以確保其修改正確性及其影響?或許你會說只有瘋子才會那么做,但事實上有時候我們正是那個瘋子.基本上很多時候連開發自己都不敢肯定會不會影響到其它部分,所以我們就不得不擴大測試范圍.那應該如何選擇回歸測試使用呢?前人已經總結了很多,主要是如下4種.

　　1>選擇全部測試用例

　　選擇測試用例庫中的所有測試用例作為回歸測試用例,這是一個較為保險的方法.在理想的狀態下(有足夠的資源,測試人員不知疲憊),這種方法絕對是首選.但理想與現實的差距是慘不忍賭的,測試資源缺乏是行內常情,特別是由于進度而導致測試時間極為苛刻,而且測試人員會因多次執行相同用例而產生厭煩,這對測試質量影響是非常大的.所以,無論從現實資源考慮還是從成本上考慮都不可能每次回歸測試包都是選擇所以測試用例.

　　2>基于風險選擇測試用例

　　這是基于一定的風險標準從測試用例庫中選擇部分測試用例形成測試包.按測試優先級來來選擇最重要的、關鍵的和可疑的測試，而跳過那些非關鍵的、優先級別低的或者高穩定的測試用例.這樣測試任務會大為減輕但效果并不差,因為由此沒有被發現的缺陷是較少并嚴重性較低的.

　　3>基于操作剖面選擇測試用例

　　這種方法適用于測試用例是基于軟件操作剖面開發的，測試用例的分布情況反映了系統的實際使用情況?；貧w測試時可以優先選擇那些針對最重要或最頻繁使用功能的測試用例，釋放和緩解最高級別的風險，有助于盡早發現那些對可靠性有最大影響的故障。

　　4>再測試修改部分

　　這種是基于開發對修改的影響區域有較大把握時所采取的一個策略.通過相依性分析識別軟件的修改情況并分析修改的影響，將回歸測試局限于被改變的模塊和它的接口上,此時只選擇相應的測試用例來做回歸測試.此策略風險最大,但成本也是最能低的,通常用于做小回歸測試.

原文轉自：http://www.uml.org.cn/Test/200902266.asp