?一個Bug的生命周期是從創建開始到關閉結束，而Bug能否關閉就取決于回歸測試的結果，測試人員可能很多都對Bug靈敏度有較高要求，但是對于回歸測試的把控或質量掌握的程度卻比較模糊。而關于回歸測試的范圍、回歸測試的開展正是本文討論的重點。

Bug回歸的重要性

回歸測試是軟件測試中不可忽視的一部分，回歸測試是對問題修改后，重新進行測試并確認修改沒有引入新錯誤，或者導致其他程序出現錯誤。

作為軟件生命周期的一部分，回歸測試在整個軟件測試過程中占據著相當大的分量，在敏捷測試的每個階段都要進行多次回歸測試。

開發人員修改的局部問題時，可能已經處理了表面癥狀，所以主要測試其修改的頁面和它的底層邏輯上。

但是也可能存在未觸及到根本原因，所以還需要測試交互模塊。Bug本身可能得到了修復，但修復也可能造成其他錯誤，所以有必要為每個修復的錯誤，設計回歸測試。

關閉Bug有哪些注意事項

最重要的，要看Bug的原因分析和解決方案是否正確，能否對應。

在原因和解決方案都看懂了的情況下開始進行回歸驗證。該問題在發現時是百分百的出現概率，那么按照操作步驟驗證改好之后可以直接關閉。

該問題在發現時是int問題，那么最好要提高操作次數，回歸20次（概率<5%回歸30次，概率>5%回歸20次），再視操作結果關閉Bug。

有些開發解決Bug的習慣比較好，會附上回歸建議，此時再額外按照建議回歸下即可。如果在條件允許的情況下，最好跟開發人員溝通交流，討論Bug的根因、修改方案及修改影響，結合開發人員的開發習慣，再結合測試人員自身的經驗，梳理相關回歸思路。這樣基本就可以將Bug一網打盡。

下面我們看兩個Bug回歸的經典案例：

這個案例中，問題出現的原因是對該線索進行操作，簽約狀態的值傳的不對，沒有定義這個狀態的值，導致線索狀態沒有變化。

我們在回歸時，除了驗證原Bug中操作的場景，還需要驗證其他不同流程，保證線索的狀態都是正確變化的，從而確認沒有引入新的問題。比如：

• 線索由待跟進轉換為跟進中，提交后狀態顯示正確；
• 線索由跟進中轉換為已簽約，提交后狀態顯示正確；
• 線索由已簽約轉換為已失效，提交后狀態顯示正確。

而這個Bug就相對比較簡單，問題原因就是普通線索和商盟線索沒有加商盟標志，導致和普通線索一樣展示在了原來的區域，驗證時除了按照原來步驟操作，還需要查看數據庫中商盟的線索有這個值就代表改好了。

如何提高回歸測試的效率

快速進行回歸測試的最佳方法之一是使回歸測試的簡單場景轉換成自動化用例。我們可以創建一系列回歸測試腳本，并應在每次修改到這部分邏輯時對該腳本進行部分修改和審查，以確保其覆蓋到修改的地方。

然后在手工執行回歸測試時，這部分自動化腳本就可以幫我們測試其他常用的基礎功能，保證修改不會引入嚴重問題，自動化測試腳本應涵蓋所有可能的基礎場景的測試用例。自動化回歸測試將大大降低系統測試階段、維護升級等階段的人力和時間成本。

除了上述的關于回歸測試的采取的必要手段，回歸測試也可以借鑒平常測試的一些方法，比如交換測試，邀請別的小伙伴站在用戶角度對該模塊進行驗證，也可以發現一些測試者自己發現不了的隱蔽問題。?