(4). 如果必要,生成新的測試用例集T1,用于測試T0無法充分測試的軟件部分。
(5). 用T1執行修改后的軟件。
第(2)和第(3)步測試驗證修改是否破壞了現有的功能,第(4)和第(5)步測試驗證 修改工作本身。
三、 回歸測試實踐
在實際工作中,回歸測試需要反復進行,當測試者一次又一次地完成相同的測試時,這些回歸測試將變得非常令人厭煩,而在大多數回歸測試需要手工完成的時候尤其如此,因此,需要通過自動測試來實現重復的和一致的回歸測試。通過測試自動化可以提高回歸測試效率。為了支持多種回歸測試策略,自動測試工具應該是通用的和靈活的,以便滿足達到不同回歸測試目標的要求。
在測試軟件時,應用多種測試技術是常見的。當測試一個修改了的軟件時,測試者也可能希望采用多于一種回歸測試策略來增加對修改軟件的信心。不同的測試者可能會依據自己的經驗和判斷選擇不同的回歸測試技術和策略。
回歸測試并不減少對系統新功能和特征的測試需求,回歸測試包應包括新功能和特征的測試。如果回歸測試包不能達到所需的覆蓋要求,必須補充新的測試用例使覆蓋率達到規定的要求。
回歸測試是重復性較多的活動,容易使測試者感到疲勞和厭倦,降低測試效率,在實際工作中可以采用一些策略減輕這些問題。例如,安排新的測試者完成手工回歸測試,分配更有經驗的測試者開發新的測試用例,編寫和調試自動測試腳本,做一些探索性的或ad hoc測試。還可以在不影響測試目標的情況下,鼓勵測試者創造性地執行測試用例,變化的輸入、按鍵和配置能夠有助于激勵測試者又能揭示新的錯誤。
在組織回歸測試時需要注意兩點,首先是各測試階段發生的修改一定要在本測試階段內完成回歸,以免將錯誤遺留到下一測試階段。其次,回歸測試期間應對該軟件版本凍結,將回歸測試發現的問題集中修改,集中回歸。
在實際工作中,可以將回歸測試與兼容性測試結合起來進行。在新的配置條件下運行舊的測試可以發現兼容性問題,而同時也可以揭示編碼在回歸方面的錯誤。
原文轉自:http://www.uml.org.cn/Test/20101283.asp