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

Bug回歸的重要性

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

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

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

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

關(guān)閉Bug有哪些注意事項

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

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

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

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

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

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

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

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

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

如何提高回歸測試的效率

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

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

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