近兩周都在做回歸測試，發現大的工作量是測試環境的恢復和新發現缺陷的定位。測試環境的恢復正在尋求好的解決方案，那么先總結下對于缺陷定位的思考和方法吧。

　　有一種心理暗示，不知大家是否認同。第一次測試一個系統，當發現了問題大多時候會第一感覺會是認為這是個缺陷，即使定位錯誤也許開發人員或其他成員會認為你由于對系統還不太熟悉，作為開脫理由。

　　回歸測試卻不同，至少已經完成了一輪以上的測試，這時候發現新的問題，尤其是與新版本新特性無明顯關聯的問題，一般情況下第一感覺會反思自己是不是哪里設置有誤，這是個Bug嗎？常會有這樣的疑問。還會擔心如果把錯誤的定位反饋給開發人員，會不會對自己產生不好的影響。

　　那么在回歸測試中如何定位缺陷呢？

　　1、在舊的版本上驗證：同樣的數據和環境設置，執行舊版本的系統或軟件，查看結果是否仍然有誤。如果舊版本的結果是正確的，而新版本的結果是錯誤的，已經基本可以說明是新產生的缺陷了。當然還要排除新問題是由于新特性導致原來正確的數據或環境設置在新版本產生異常的情況。

　　2、查看系統日志：如果通過舊版本驗證后還是不能確認，那么接下來查看日志。如果是計算錯誤類型的缺陷，尤其是復雜的計算過程，能否在日志中查到相應的過程及結果數據，只能憑運氣了；诖宋医ㄗh測試人員可以提前提供給開發人員需要哪些關鍵的中間數據結果信息，在測試版本的系統日志中打印出來，方便測試人員查看。

　　3、反推法：適用于某些特性的測試，正確的數據設置產生了錯誤的期望結果，那么反之錯誤的數據設置會產生正確的期望結果。那么這時可以通過嘗試不同的錯誤的基礎數據設置，來尋求得到正確的結果。一旦得到期望的結果，可以通過與原有版本的基礎數據設置來逐一對比，從而查找出是由于哪個錯誤的數據設置產生的問題。

　　4、查看或調試代碼：保險的方法，但是有時常常由于某些原因而無法實現。比如測試客戶方的系統，無法看到代碼，或者測試人員的閱讀代碼能力有限。當然如果是我們實在無法確認的問題，可以交給開發人員來查看或調試代碼。

　　缺陷定位中，有優勢的是對于業務需求和系統架構能夠充分掌握的測試人員，那么我們也可以來請教這樣的人或者自己來努力成為這樣的人。