如何做好回歸測試

　　在總結回歸測試的方法時發現，不管國內國外，這都是個頭疼的話題。做是要做，也能做，但是從效率角度說可是千差萬別。給我足夠多的人或是時間，總是可以保證回歸測試進行的徹底，可是那并不是做事情的方法和解決問題的手段。我覺得google的James Whittaker說的好“事實上，有些測試組堅持要保持一個規模相對比較大的團隊主要是因為他們的假設前提就是有些事情做錯了。這也意味著編碼和測試之間的工作失衡。添加更多的測試人員并不能解決任何問題。”“In fact, teams that insist on having a large testing presence are generally assumed to be doing something wrong. Having too large a test team is a very strong sign that the code/test mix is out of balance. Adding more testers is not going to solve anything.”當然，google把quality交給developer去own才能將測試人員的工作真正做到是質量環節的最后確保。而不是去檢查developer犯的錯誤。

　　從執行方法的角度看，回歸測試大多要通過兩種方式去執行：一類借助于工具完成的自動化測試，一類是手動完成。從回歸測試的計劃和策略上講，一般有以下兩種方法：

　　一、基于風險的

　　這是一個比較簡單和常用的方法，顧名思義，就是在分析出改動所帶來的風險以后，在易出錯的地方進行回歸測試以保證原有的功能沒有被新的變化影響。這么看，對于新的改動的分析風險能力很重要。如何準確的獲得風險列表呢?

　　· 大家最頭疼的地方，也許就是風險所在

　　這可以從以往和dev以及product owner等人的會議及email的討論中獲得。

　　· 新功能的測試計劃

　　在編寫測試用例和寫測試計劃的時候，因為比較系統和全面的了解新功能，所以可以同時把可能有的風險列出來，以供日后的回歸測試來進行雙重保證。

　　· 商業價值

　　說白了，就是最賺錢的地方，客戶最在意的地方。因為這些地方的一點點小錯誤都可能引來客戶的抱怨和不滿，所以這些地方就尤其重要。相反，商業價值比較小的地方，有點錯誤也無傷大雅。那么，測試重點就該有所先后。

　　· 權重計算

　　影響產品質量的權重參數很多，我們可以估計和預測的有以下方面：

　　1. 項目架構，包括功能之間的依賴關系、功能的復雜度以及需求變更等

　　2. 大小，多少人開發多少人測試

　　3. 開發人員的能力，這個常常被忽略的因素往往起到很大的作用。我們可以從開發人員的薄弱環節，或是某個能力稍差的開發人員做的模塊下手，找到bug是在情理之中的。

　　二、矩陣法

　　這種方法雖然麻煩，但是卻最高效，也是目前看來最佳的辦法。但是這個方法的執行需要QA manager有很強的執行能力以及一個溝通比較通暢的團隊。以下為這種方法執行的具體步驟：

　　· 首先，創建一個影響回歸的功能\特性矩陣(regression impact matrix)

　　列出所有的特征和功能，例如

原文轉自：http://www.uml.org.cn/Test/20113113.asp