詳解迴歸測試

測試工作中，新人對於測試流程、測試方法都有可以直接拿來用的教材，但是對於迴歸測試中的bug處理的細節，往往需要我們更多的經歷才能更好的完成自己的工作，下面我們來談一談迴歸測試bug的處理中需要關注的點：

一、什麼是迴歸測試？

迴歸測試是指在發生修改之後重新測試先前的測試以保證修改的正確性。理論上，對軟體的任何新版本，都需要進行迴歸測試，驗證以前發現和修復的錯誤是否在新軟體版本上再現，並確認曾經透過的功能不會出現問題。

二、迴歸測試做多少次？

很多資料都有具體指定迴歸的次數，在我看來，迴歸測試不能確卻的給出一個專案具體做多少輪迴歸測試，因為，版本不可控的因素太多了，需求的更改、人員的流動，開發的編碼甚至還有很多其它市場因素都會造成版本的變動與推遲，只要有新版本勢必就會做迴歸測試，因此在一開始規定迴歸測試的次數這是不可取的。

一般只要出新版本就會有迴歸測試，極少的情況在沒有新版本的情況下，為了快速檢驗版本質量，也會根據補丁進行迴歸測試（不推薦）。

三、迴歸測試做什麼？

很多人在做迴歸測試的時候，都是原原本本的按bug步驟進行驗證。事實上，這樣做的迴歸測試是遠遠不夠的。做迴歸時，不光要驗證bug中的內容 ，還要對bug中所有相關業務都要做基本的驗證，另外，bug中如果只提到一個導致bug的入口（舉例：修改專案中某個人的資訊，一定會存在新建與修改並存的地方，也會在其它地方可進行修改），那麼在驗證的時候也應該將所有入口都驗證到，這在要求測試人員對測試業務非常熟悉的同時，還要求懂點程式碼，會根據開發的修改方案在程式碼上與業務上都進行迴歸。事實上，當每輪的bug都有根據業務的擴充套件與涉及來進行了驗證的話，在迴歸測試裡可以將冒煙完成大部分（具體依bug的數量與模組決定 ）。

四、迴歸測試何時結束？

迴歸測試的結束應該從以下兩方面闡述：

1）一個bug的關閉

當驗證bug可以正常關閉時，應該在關閉bug的時候備註以下幾點：

迴歸版本：驗證的版本號

迴歸步驟：迴歸bug的步驟

迴歸結論：是否迴歸透過。如果透過就可以直接關閉，如果驗證過程中還有其它問題，就要進行二次迴歸，就需要在迴歸結論裡進行闡述還存在的問題現象及場景，並再次啟用指派給開發。

2）一輪迴歸的結束

新版本出來後，會存在一些無法重現、評審透過此版本先不解決的、出版本之際由於時間安排推遲到下一個版本的bug，針對這些特殊情況的bug進行特殊處理後，所有bug都進行了迴歸 ，那麼一輪的迴歸測試就算結束了

五、迴歸測試裡我們還可以做什麼？

在做迴歸時，有些bug會轉為需求，也會因為一些bug在業務上有大小的變動，一輪迴歸下來，除了將bug都進行迴歸外，還會根據bug的性質對用例進行相對的增加與修改，相對應的應該根據實際情況對用例進行新增與修改。同樣的，一輪測試下來，做測試總結的時候，也會得出在業務上的薄弱點，這個時候也應該對用例庫進行整理，對不受控與存在冗餘、或是由於新增導致變動的用例都相應的進行修改。

迴歸測試雖然做的事情比較單一，但是實際過程中，只要好好把握這個過程，不僅可以對業務的熟悉有大的提升，還可以藉此整理用例庫從而更好的透過用例測出高質量的bug，對於想透過bug來找點測試思路甚至作為熟悉業務也不失為一種好方式