軟體測試中的Bug迴歸，到底有多重要？

一個Bug的生命週期是從建立開始到關閉結束，而Bug能否關閉就取決於迴歸測試的結果，測試人員可能很多都對Bug靈敏度有較高要求，但是對於迴歸測試的把控或質量掌握的程度卻比較模糊。而關於迴歸測試的範圍、迴歸測試的開展正是本文討論的重點。 加我VX：atstudy-js 回覆“測試”，進入 自動化測試學習交流群~~

Bug迴歸的重要性

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

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

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

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

關閉Bug有哪些注意事項

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

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

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

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

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

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

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

1）線索由待跟進轉換為跟進中，提交後狀態顯示正確；

2）線索由跟進中轉換為已簽約，提交後狀態顯示正確；

3）線索由已簽約轉換為已失效，提交後狀態顯示正確。

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

如何提高迴歸測試的效率

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

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

除了上述的關於迴歸測試的採取的必要手段，迴歸測試也可以借鑑平常測試的一些方法，比如交換測試，邀請別的小夥伴站在使用者角度對該模組進行驗證，也可以發現一些測試者自己發現不了的隱蔽問題。

最後：

可以到我的個人V：atstudy-js，可以免費領取一份10G軟體測試工程師面試寶典文件資料。以及相對應的視訊學習教程免費分享！其中包括了有基礎知識、Linux必備、Mysql資料庫、抓包工具、介面測試工具、測試進階-Python程式設計、Web自動化測試、APP自動化測試、介面自動化測試、測試高階持續整合、測試架構開發測試框架、效能測試等。

這些測試資料，對於做【軟體測試】的朋友來說應該是最全面最完整的備戰倉庫，這個倉庫也陪伴我走過了最艱難的路程，希望也能幫助到你！