迴歸測試包的選擇
在軟件生命週期中，即使一個得到良好維護的測試用例庫也可能變得相當大，這使每次迴歸測試都重新運行完整的測試包變得不切實際。一個完全的迴歸測試包括每個基線測試用例，時間和成本約束可能阻礙運行這樣一個測試，有時測試組不得不選擇一個縮減的迴歸測試包來完成迴歸測試。
迴歸測試的價值在於它是一個能夠檢測到迴歸錯誤的受控實驗。當測試組選擇縮減的迴歸測試時，有可能刪除了將揭示迴歸錯誤的測試用例，消除了發現迴歸錯誤的機會。然而，如果採用了代碼相依性分析等安全的縮減技術，就可以決定哪些測試用例可以被刪除而不會讓迴歸測試的意圖遭到破壞。
選擇迴歸測試策略應該兼顧效率和有效性兩個方面。常用的選擇迴歸測試的方式包括：
(1)、再測試全部用例
選擇基線測試用例庫中的全部測試用例組成迴歸測試包，這是一種比較安全的方法，再測試全部用例具有最低的遺漏迴歸錯誤的風險，但測試成本最高。全部再測試幾乎可以應用到任何情況下，基本上不需要進行分析和重新開發，但是，隨着開發工作的進展，測試用例不斷增多，重複原先所有的測試將帶來很大的工作量，往往超出了我們的預算和進度。
(2)、基於風險選擇測試
可以基於一定的風險標準來從基線測試用例庫中選擇迴歸測試包。首先運行最重要的、關鍵的和可疑的測試，而跳過那些非關鍵的、優先級別低的或者高穩定的測試用例，這些用例即便可能測試到缺陷，這些缺陷的嚴重性也僅有三級或四級。一般而言，測試從主要特徵到次要特徵。
(3)、基於操作剖面選擇測試
如果基線測試用例庫的測試用例是基於軟件操作剖面開發的，測試用例的分佈情況反映了系統的實際使用情況。迴歸測試所使用的測試用例個數可以由測試預算確定，迴歸測試可以優先選擇那些針對最重要或最頻繁使用功能的測試用例，釋放和緩解最高級別的風險，有助於儘早發現那些對可靠性有最大影響的故障。這種方法可以在一個給定的預算下最有效的提高系統可靠性，但實施起來有一定的難度。
(4)、再測試修改的部分
當測試者對修改的局部化有足夠的信心時，可以通過相依性分析識別軟件的修改情況並分析修改的影響，將回歸測試侷限於被改變的模塊和它的接口上。通常，一個迴歸錯誤一定涉及一個新的、修改的或刪除的代碼段。在允許的條件下，迴歸測試儘可能覆蓋受到影響的部分。
再測試全部用例的策略是最安全的策略，但已經運行過許多次的迴歸測試不太可能揭示新的錯誤，而且很多時候，由於時間、人員、設備和經費的原因，不允許選擇再測試全部用例的迴歸測試策略，此時，可以選擇適當的策略進行縮減的迴歸測試。
還有就是我現在常採用的方式，把產生BUG的用力再執行一次，經過幾個項目的總結，我發現這不失爲一個好辦法。
