如何做好軟件測試中的回歸測試(3)

　　這個列表可以有以下部分組成：

　　1. 影響范圍

　　2. 對影響的描述

　　3. 影響所影響的特定情節

　　4. 代碼變化部分，以及所影響的功能

　　5. 開發人員所推薦的回歸，我想研發過程中，養成dev在改動代碼的時候向測試人員提供回歸測試推薦的習慣實在是必要的。

　　6. 對有依賴關系的特性的影響

　　由于要達成某種改動的目的，也許需要其他特性做相應修改。

　　策略

　　執行回歸測試，分為以下三個主要類型，也相應的分為以下三個階段：

　　第一階段：

　　提供被新功能或有依賴關系的改動直接影響的區域。這些區域至少要完成一組小的覆蓋全部特性的基本功能的測試用例。

　　第二階段：

　　把上個開發階段(previous release)重復發現的問題列出來 – 這些信息可以從上個階段的最終測試報告中找到。(也就是說每個階段的測試報告需要包括重復發現的問題)

　　同時，把客戶關系和敏感的特性列出來 – 例如付費等。

　　第三階段：

　　a. Hot-spot suite 這是基于前兩個階段發現的比較多的問題區域。因為，缺陷往往在比較容易發生缺陷的地方隱藏更多，所以，這樣的地方是要增加人手測試的。

　　b. 額外增加的測試，這些測試往往是由于晚期check-in代碼，或者有依賴關系的特性改動。這個測試范圍的定位需要再次使用”影響測試列表Test Impact Checklist”.

　　c. Sanity Test, 這是在產品發布給客戶之前做的clean-run測試，類似于monkey test.

原文轉自：http://www.kjueaiud.com