在大家的常識中，回歸測試在范圍的選擇上，有如下四種方法：

　　1、測試全部用例——選擇基線測試用例庫中的全部測試用例，這是一種比較安全的方法，再測試全部用例具有低的遺漏回歸錯誤的風險，但測試成本高；

　　2、基于風險選擇測試——可以基于一定的風險標準來從基線測試用例庫中選擇回歸測試；

　　3、基于操作剖面選擇測試——如果基線測試用例庫的測試用例是基于軟件操作剖面開發的，回歸測試可以優先選擇那些針對重要或頻繁使用功能的測試用例，釋放和緩解高級別的風險，有助于盡早發現那些對可靠性有大影響的故障；

　　4、再測試修改的部分——當測試者對修改的局部化有足夠的信心時，可以通過相依性分析識別軟件的修改情況并分析修改的影響，將回歸測試局限于被改變的模塊和它的接口上。

　　我前一段時間在微博里發了一個號稱“回歸測試用例自動生成器”的設計圖（如下），核心思路是通過配置管理工具對版本差異的掃描來獲取改動的文件，通過用代碼掃描工具對改動文件的掃描得到改動的內容，再通過這些改動的內容掃描出關鍵字：

　　SP：cursor、function、procedure……

　　JAVA：method、interface、class、DAO、DTO……

　　后通過這些關鍵字和系統功能點、回歸測試用例庫中的測試用例，這三者的映射關系來精確的找到每次移交之后所要進行的關聯測試。其實后來經過大家的討論，發現這種構思叫“回歸測試范圍界定選擇器”更加合適，用“生成”二字有點歧義。我自己也沒有想清楚到底如何實現，需要關注哪些問題，但是我做這種設想的理由很簡單：

　　1、我厭倦了每次版本后一次移交之后都需要的全面回歸測試，這是一種無恥的浪費；

　　2、我厭倦了這種“瞎蒙”式的回歸測試，不精確，而且所謂的全面回歸也無法避免測試遺漏；

　　3、我不相信在沒有足夠的時間的情況下，所謂的回歸測試剪裁，所謂基于風險的評估是無法保證規避一些重要的測試遺漏的；

　　4、我不相信coder兄弟們告訴我的，他們基于本次版本所有需求所修改的內容，因為他們其中個別人往往會稍帶著做一些自認為“無傷大雅的優化”；

　　5、我憎恨任何一個把前期測試沒有盡力卻在出了測試遺漏的時候把責任推給回歸測試的人，開發人員也好、測試人員也罷；

　　當然，這些只是我個人主觀上的認知傾向，貌似我應該用更有說服力的數據來說明我這么思考和想做這件事情的理由，那么不妨讓我算一筆賬給大家看看：

　　1、前提：自動化開發和維護的成本撇開不算，因為有沒有這個構思，自動化測試開發和維護都必須要做；

　　2、按照目前Selenium/WebDriver的自動化回歸測試腳本的粒度算，假設一個系統平均Web頁面回歸測試用例1000個，其中80%是自動化的，20%是手動的；