3>基于操作剖面選擇測試用例
這種方法適用于測試用例是基于軟件操作剖面開發的，測試用例的分布情況反映了系統的實際使用情況�；貧w測試時可以優先選擇那些針對最重要或最頻繁使用功能的測試用例，釋放和緩解最高級別的風險，有助于盡早發現那些對可靠性有最大影響的故障。
4>再測試修改部分
這種是基于開發對修改的影響區域有較大把握時所采取的一個策略。通過相依性分析識別軟件的修改情況并分析修改的影響，將回歸測試局限于被改變的模塊和它的接口上，此時只選擇相應的測試用例來做回歸測試。此策略風險最大，但成本也是最能低的，通常用于做小回歸測試。
以上四種回歸測試策略各有優缺點，實際應用中應根據項目的資源，進度及項目開發的模式等實際情況來選擇最優策略。1>一般情況在在一個非用于基線的 build中作了小修改，建議采用策略4，只測試修改部分，因為現在的開發流程中build更新較快特別是極限編程中，要進行完全的回歸測試是比較不現實的，即使有自動化工具的輔助亦未必能實現。2>在一個milestone中，一個作為基線的build中則可采用策略2或3，基于一定的風險選擇測試，這是一個較為折中的辦法，但如果資源允許的話建議進行全回歸測試。3>較重要的mileStone或是最終版本，最好選擇全回歸測試。因為如果一般來說此時軟件改動會較大，選擇全部測試較為保險。當然這還是要依據當時的實際出發。
但無論采取何種策略，回歸測試還是讓人棄之不做卻又不得不做的一種測試，因為它重復多并且經常工作量大但經常發現的缺陷相對工作量來說太少。但是誰都不敢承擔不做回歸測試帶來的后果，真是食之無味，棄之不能。所以在做回歸測試時我們必須采取一些較為有效的方法來保證做好回歸測試。例如安排新的測試者完成手工回歸測試，讓更有經驗的測試者開發新的測試用例，編寫和調試自動測試腳本，做一些探索性的或ad hoc測試�；蚴遣扇≥喠鲌绦胁煌K，盡量避免一人一直測試某一模塊，不論從測試感受還是測試效果來看，這都是一個不好的方法。但我覺得最重要的就是基于實際可行的話引進自動化測試，因為機器不會累，可以日夜跑。
回歸測試這個令人頭痛的問題需要根據項目跟測試資源等實際情況來采取更有效的策略來解決。其中需要注意的是必須重視回歸測試，在測試計劃中有很好的進度安排及選擇相應的回歸，重視測試用例的維護，借助于自動化工具。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
