軟件測試中的回歸測試漫談

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

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

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

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

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

　　1>選擇全部測試用例

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

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

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

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

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

　　4>再測試修改部分

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

　　以上四種回歸測試策略各有優缺點,實際應用中應根據項目的資源,進度及項目開發的模式等實際情況來選擇最優策略.

　　1>一般情況在在一個非用于基線的build中作了小修改,建議采用策略4,只測試修改部分,因為現在的開發流程中build更新較快特別是極限編程中,要進行完全的回歸測試是比較不現實的,即使有自動化工具的輔助亦未必能實現.

　　2>在一個milestone中,一個作為基線的build中則可采用策略2或3,基于一定的風險選擇測試,這是一個較為折中的辦法,但如果資源允許的話建議進行全回歸測試.

　　3>較重要的mileStone或是最終版本,最好選擇全回歸測試.因為如果一般來說此時軟件改動會較大,選擇全部測試較為保險.當然這還是要依據當時的實際出發.

　　但無論采取何種策略,回歸測試還是讓人欲棄之不做卻又不得不做的一種測試,因為它重復多并且經常工作量大但經常發現的缺陷相對工作量來說太少.但是誰都不敢承擔不做回歸測試帶來的后果,真是食之無味,棄之不能.所以在做回歸測試時我們必須采取一些較為有效的方法來保證做好回歸測試.例如安排新的測試者完成手工回歸測試,讓更有經驗的測試者開發新的測試用例，編寫和調試自動測試腳本，做一些探索性的或ad hoc測試?；蚴遣扇≥喠鲌绦胁煌K,盡量避免一人一直測試某一模塊,不論從測試員感受還是測試效果來看,這都是一個不好的方法.但我覺得最重要的就是基于實際可行的話引進自動化測試,因為機器不會累,可以日夜跑.

　　回歸測試這個令人頭痛的問題需要根據項目跟測試資源等實際情況來采取更有效的策略來解決.其中需要注意的是必須重視回歸測試,在測試計劃中有很好的進度安排及選擇相應的回歸策略,重視測試用例的維護,借助于自動化工具. 

原文轉自：http://www.anti-gravitydesign.com