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

Bug回歸的重要性

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

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

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

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

關閉Bug有哪些注意事項

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

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

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

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

下面我們看兩個Bug回歸的經(jīng)典案例：

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

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

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

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

如何提高回歸測試的效率

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

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

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