回歸測試是一種系統範圍的測試，旨在確保系統某個部分的微小變化不會破壞系統中其他地方的現有功能。這很重要，因為沒有回歸測試，很有可能將預期的修復程序引入到一個系統中，這個系統會產生比他們解決的問題更多的問題。

讓我們看一個虛構的例子，說明在不使用回歸測試時會發生什麽。

什麽可能出錯？

有一天，Acme Widgets應收賬款部門的經理發現了公司財務系統中的一個錯誤。事實證明，負責報告逾期發票的模塊未列出所有逾期發票。編寫了一張Jira票據，描述了該錯誤以及有關如何復制問題的說明。該錯誤已分配給進行修復的開發人員。

開發人員遵循公司政策和單位測試新代碼。單元測試證明該修復工作符合預期的效果。

一旦開發人員在Jira中報告錯誤被修復，QA就會查看通過單元測試，以確保開發人員遵循公司的代碼覆蓋策略。此外，QA測試人員還運行了安裝新代碼的測試系統，以確保修復按預期工作。測試代碼按預期在測試系統上運行。

修復程序已發布到生產中。到現在為止還挺好。

一周過去了。然後，當會計部門試圖運行公司的月末損益表時，會發生奇怪的行為。每當系統嘗試發出老化報告時，系統就會超時。（年齡報告根據年齡 - 當前，逾期30天，逾期60天，逾期90天，超過90天）對發票金額進行分類和匯總。）

混亂在Acme Widgets爆發。如果沒有月末的損益表，該公司不知道它是賺錢還是賠錢。會計部門很不高興。該系統在上個月運作良好。現在它已經壞了。會計經理與軟件開發經理聯系以報告問題並盡快尋求補救措施。

軟件開發經理通過Jira查找在運行月末損益表之前指示任何代碼更改的票證。解決過期發票問題的Jira機票瞪著他。軟件開發經理致電Tech Lead，他們一起討論代碼和單元測試。一切看起來都很好，似乎。然後他們打電話給質量保證經理，讓他們對這個問題有另一種看法。從表面上看，QA經理似乎也很好。

然後QA經理有預感。她看了一下單元測試，並註意到測試是針對一個小型測試數據庫運行的，該測試數據庫包含了今年第一季度發票的數據。該數據足以復制錯誤，因此可以修復錯誤並成功進行單元測試。但是，代碼從未使用生產數據進行過測試。

技術負責人聯系了進行修復的開發人員。他們一起審視修復，發現當應用於小數據集時，更改看起來是良性的。技術主管針對生產數據集的副本運行代碼。事實證明，封裝在函數getPastDueInvoices（dueDate）中的新代碼需要5秒鐘才能對生產數據執行。

在進行單元測試時，代碼修復需要1.5秒才能運行。因此，它似乎很好，但在生產中，它不是。會計系統配置為對發票模塊的調用超時時間為2秒。回歸測試確保系統的一部分中的新代碼不會在整個系統中引起不必要的副作用。

事實證明，開發人員確實通過單元測試重新測試了代碼修復。QA進行了高級別檢查，但未進行回歸測試。修復工作在單元測試下達到預期，但在生產中運行時它破壞了系統。如果將修復程序合並到使用生產中運行的數據副本的系統範圍的回歸測試中，則在發布到生產之前發現該問題的可能性非常大。因此，回歸測試的價值和重要性。

回歸測試不僅僅是重新測試

回歸測試很有價值。可悲的是，有時一家公司會認為它正在進行回歸測試，而實際上它正在進行重新測試。重新測試是為了確保特定的代碼更改按預期工作。回歸測試旨在確保一旦引入變更，整個系統就能達到預期效果。因此，設計和實施回歸測試比重新測試具有更廣泛的活動範圍。

如果對軟件測試、接口測試、自動化測試、性能測試、LR腳本開發、面試經驗交流。感興趣可以175317069，群內會有不定期的發放免費的資料鏈接，這些資料都是從各個技術網站搜集、整理出來的，如果你有好的學習資料可以私聊發我，我會註明出處之後分享給大家。

通常，重新測試快速發生，在創建時間代碼或非常接近代碼。當有更多時間可用於滿足執行測試所需的更長時間跨度時，回歸測試在SDLC中進一步發生。是的，一些重新測試可能非常復雜且耗時，但遠不及執行全面回歸測試所需的時間長度。請記住，充分的回歸測試意味著必須對系統的所有方面進行測試，同樣重要的是，進行監控。在沒有適當的系統範圍監控的情況下執行回歸測試會將測試工作轉變為猜謎遊戲。正如我們在開放場景中所展示的那樣，系統的某個部分可能會發生錯誤，但這可能是由另一部分的行為引起的。

將回歸測試納入叠代模型

回歸測試的情況很好。但是，在敏捷下實施一個可能很難。Agile和DevOps的目標是在短暫，快速的發布周期內盡快將工作軟件交到用戶手中。然而，回歸測試需要時間，可能比單次叠代所允許的時間更長。那要做什麽？

一種解決方案是在叠代之間錯開回歸測試。每次叠代都會發布代碼版本。但是，在叠代過程中創建的代碼的回歸測試在叠代開始的一半開始，並繼續進行下一次叠代。在叠代中途開始回歸測試允許測試從業者在叠代期間新代碼“穩定”時發現問題。然後，可以在以下叠代中實現和吸收修復。

將回歸測試僅限於叠代中正在開發的當前版本的代碼會產生創建瀑布動態的風險。在執行修復之前，開發團隊可能會陷入停滯狀態，等待回歸測試完成。然後，一旦問題被開發人員發現並解決，回歸測試人員需要等到新代碼可用後才能采取進一步行動。顯然，這種“切換和等待”模式與敏捷的軟件開發方法是對立的。對叠代進行錯綜復雜的回歸測試可以為測試人員提供執行所需測試範圍所需的時間，同時允許開發人員在此期間創建新代碼。

把它放在一起

代碼在初始發布時很難完美。現代軟件開發已經開始接受發布軟件更多的是讓它隨著時間的推移而變得更好，而不是從一開始就讓它變得更好。

這並不是說公司只是將代碼推出門，並將發布的質量留給機會。恰恰相反。具有前瞻性思維的公司竭力做到這一點，以便在軟件開發生命周期的所有階段進行測試。此外，具有前瞻性思維的公司也明白，隨著系統變得越來越大，軟件創建的速度越來越快，副作用的出現機會也越來越多。因此，在整個軟件開發生命周期中采用全面測試的公司特別強調回歸測試。回歸測試是風險緩解的第一道也是最好的防線，並確保組成軟件部分的代碼確實能夠使整個系統更好。

這就是為什麽mabl可以幫助團隊為他們的應用程序創建自動化測試，並自動化回歸測試。使用機器智能，mabl分析測試輸出以監控整體健康狀況下降，視覺變化和性能下降。

什麽是回歸測試及其重要性？