軟體測試每週一問：隨著系統的逐步成熟，每個版本包含的新特性越來越少，但是新功能對原系統的影響有多大是我們在測試時需要重點考慮的問題。此時，就勢必要進行回歸測試。而且系統越成熟，回歸測試的比重也會越大。這將會對測試工作帶來不小的挑戰。
在實際工作中，經常是一方面求全，希望覆蓋面盡量廣，避免漏測。另一方面求產出，大量的回歸測試用例，可能只發現很少的問題，投入與產出不太匹配，會影響測試人員的士氣，甚至測試管理者也會對這種投入產出有所質疑。並且，設計大量的自動化測試指令碼，會占用大量的時間。
引子就說這麼多，看看大家對這一普遍問題有什麼看法和建議。
會員賣燒烤的魚的精彩回答：
所謂回歸測試，即就是在軟體生命週期中，只要軟體發生了改變，就可能給該軟體產產生問題；所以，每當軟體發生變化時，
我們就必須重新測試現有的功能，以便確定修改是否達到了預期的目的，檢查修改是否破壞原有的正常功能。
其實僅單純從英文單詞regress很好理解:return to a worse or less developed state.即是退化，衰退的意思，
檢查軟體從正常的穩定狀態退化或是衰退到不正常工作的不穩定狀態。
注意：回歸測試不僅僅是針對在系統測試階段，而是在軟體生命週期中^_^
如果以上的定義均明確後，有效的回歸測試應從這幾方面：
其實最有效的回歸測試方法建立在開發測試庫的基礎上；開發在建立測試庫，每次生成程式的新版本時都可以執行這些用例。
只有有效的從源頭避免風險才能有效的進行回歸測試(目前國內的公司，能從事此級別的，太少）
1 強調單元測試時加強回歸測試，引入**評審，引入自動測試;
2 整合和系統級的測試時，加強測試用例評審，回歸測試用例的選擇；
具體的選擇可以參考以下幾點：
1 開發設計測試用例時制定優先順序，如高，中，低，方便以後自動化或是策略選擇；
2 配置管理時，引入測試用例基線管理，有效管理測試用例；
3 定期維護測試用例增，刪，保持最新狀態；
回歸測試時需考慮效率和覆蓋度有效配合，通常的策略有以下幾種：
基於風險選擇測試：
哪些功能是軟體的特色？
哪些功能是使用者最常用的？
哪些功能出錯將導致使用者不滿？
哪些程式是最複雜、最容易出錯的？
哪些程式最容易擴散錯誤？
哪些程式是開發者最沒有信心的？
備註：只有有效的避免最大的風險，使用者反感的問題，回歸測試可以說達到了70%任務!
基於regress衰退概念的測試：
開發人員修改的區域性程式時，可能已經處理了症狀，所以主要測試其被改變的模組和它的介面上；
但是也可能存在未觸及到根本原因，所以需要測試周邊程式及相互依賴性的部分；
錯誤本身可能得到了修復，但修復也可能造成其他錯誤，所以有必要為每個修復的錯誤，設計回歸測試。
基於全面測試策略：
如果時間充足，資源齊全，可以進行全面測試,最低的遺漏回歸錯誤的風險，但測試成本最高，非上策!
其它的回歸測試：
1 基於gui方式的自動化回歸測試技術
2 基於ad hoc 回歸測試：增加隨機測試，避免回歸測試肓點
備註：ad hoc testing可參考:賣燒烤的魚的測試部落格：
3 基於交叉測試：多人互動的回歸測試，尤其在核心的功能點，互動性比較的
軟體測試每週一問：當前問題討論：做好軟體測試計畫和測試用例的工作的關鍵是什麼？
測試設計008 如何有效評估測試用例的質量？
測試用例質量的評估，可以考慮下面3個方面的因素 第一，根據測試用例的形式評估其質量，主要包括 1 測試用例與需求規格說明中需求條目的可追溯性，例如 我們要求每個需求條目至少有1個測試用例與之對應。目的是為了評估測試的需求覆蓋率，以及分析需求發生變更的時候，對測試修改工作的影響程度 2 測試用例有無明...
如何更高效的進行回歸測試？
1 回歸測試基本策略及其評價 基於以上基本原則的闡述，回歸測試的基本策略目前有如下幾種，現一一進行闡述。1.1 回歸測試方式 gtrt 全面用例回歸測試選擇基線測試用例庫中的全部測試用例組成回歸測試包，這是一種比較安全的方法，再測試全部用例具有最低的遺漏回歸錯誤的風險，但測試成本最高。全部再測試幾乎...
原創 如何有效的考核測試人員
原創 如何有效的考核測試人員 當前國內很多公司對測試存在普通的認識不足，經常聽到許多公司拿bug的數量來考核測試人員的唯一方法，哪麼我要說 測試人員的考核不是僅僅看bug的！如何有效的考核測試人員？好的考核能激勵測試人員，提高工作效率 相反 不公正 的考核，則會降低工作效率,引起測試人員的不滿！本文...