回歸測試（Regression testing） 指在發生修改之後重新測試先前的測試以保證修改的正確性。理論上，軟體產生新版本，都需要進行回歸測試，驗證以前發現和修復的錯誤是否在新軟體版本上再次出現。
相信無論從底層的編程人員和測試人員，還是到頂層的項目管理者，都經歷過客戶的需求變更對項目帶來的巨大影響。特別是在項目前期進展並不順利的情況，突如其來的變更會使得程式設計師變得消極，焦慮，對自己的代碼毫無信心， 系統偶爾出現奇怪行為就胡亂猜測，改了不該改的地方導致更多奇怪現象出現。而對於項目管理者則會發現每多一次的變更都讓自己越來越感覺到項目質量不可控。
但實際上每次的變更都會做相應的回歸測試，但為什麼還會使項目組的成員產生如此不安的情緒呢。其實原因很簡單，」我怎麼知道改了這塊會不會影響到其它功能，理論上應該不會，但我不敢保證」，」時間太緊了，大體測試了一下，功能基本沒什麼問題，但細節上不確定」上面這兩種回答無疑是最常見的。那麼如何解決上面這兩個問題我認為最好的途徑是正確的做好回歸測試，上面兩種狀況雖然做了回歸測試，但顯然方法是錯誤的。
首先，要對回歸測試進行的時機的誤區進行糾正。回歸測試並不是只在需求變更時進行，回歸測試可以發生在軟體生命周期的任意一個部分，從單元測試（ut），功能測試（ft），集成測試（it），甚至到發布測試。事實上漸進和快速迭代開發中更加頻繁的回歸測試可以更有效的提高代碼質量，使得回歸周期更短。因此對於程式設計師的建議是測試代碼先行於功能代碼，在程序debug階段能夠做到反覆回歸測試，維護測試用例庫，那麼到了測試階段並會事倍功半。
其次，如何有效地進行回歸測試，必須解決回歸測試中的兩個主要問題，一是測試用例的優化選擇，二是覆蓋率分析。對於第二點來說，當產品的開發周期並不是達到三五年的長度時，如果使用正確的測試用例，基本可以達到理想的覆蓋率，而沒有必要拿出成本來做這一項。所以在這裡談一下如果選擇測試用例。要保證正確的測試用例，前提是有項目中有一個隨時維護的測試用例庫。對於測試用例庫的維護來說， 要及時刪除過時的測試用例，改進不受控制的測試用例，刪除冗餘的測試用例，增添新的測試用例。如果及時對測試用例庫進行維護，那麼當有新的需求變更時，我們要做的就是相關人員開一個審記會議，增加現有的測試用例來覆蓋這些需求變更。當代碼修改完畢時，只要能保證所有的測試用例能夠全部正確，那麼就可以保證這一次的變更不會引起新的BUG。這樣即使需求、接口一改再改， 但是有密集的回歸測試用例作保證，可以讓程式設計師毫無顧忌的快速的去調整程序。高效高質的需求對應也會提高客戶的滿意度。
最後，回歸測試是一件辛苦而且乏味的工作，但對於在軟體生命同期來說又是必不可少的，因此對於回歸測試來說自動化測試是必要的。 測試的自動化的程度越高，回歸的周期就越短，效果越明顯，軟體的質量也越高，測試是否自動化也是開發是否敏捷的一個主要標誌。
軟體測試免費視頻觀看連結：https://ke.qq.com/course/159919#tuin=ba4122
松勤網:www.songqinnet.com
微信公眾號：松勤軟體學院
軟體測試交流QQ群：642067188
軟體自動化測試交流QQ群：398140461
軟體性能測試交流QQ群：348074292
打開微信掃一掃 關注松勤軟體學院