回歸測試漫談(2)

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

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

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

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

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

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

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