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

讓我們看一個虛構(gòu)的例子，說明在不使用回歸測試時會發(fā)生什么。

什么可能出錯？

有一天，Acme Widgets應(yīng)收賬款部門的經(jīng)理發(fā)現(xiàn)了公司財務(wù)系統(tǒng)中的一個錯誤。事實證明，負(fù)責(zé)報告逾期發(fā)票的模塊未列出所有逾期發(fā)票。編寫了一張Jira票據(jù)，描述了該錯誤以及有關(guān)如何復(fù)制問題的說明。該錯誤已分配給進(jìn)行修復(fù)的開發(fā)人員。

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

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

修復(fù)程序已發(fā)布到生產(chǎn)中。到現(xiàn)在為止還挺好。

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

混亂在Acme Widgets爆發(fā)。如果沒有月末的損益表，該公司不知道它是賺錢還是賠錢。會計部門很不高興。該系統(tǒng)在上個月運作良好?，F(xiàn)在它已經(jīng)壞了。會計經(jīng)理與軟件開發(fā)經(jīng)理聯(lián)系以報告問題并盡快尋求補救措施。

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

然后QA經(jīng)理有預(yù)感。她看了一下單元測試，并注意到測試是針對一個小型測試數(shù)據(jù)庫運行的，該測試數(shù)據(jù)庫包含了今年第一季度發(fā)票的數(shù)據(jù)。該數(shù)據(jù)足以復(fù)制錯誤，因此可以修復(fù)錯誤并成功進(jìn)行單元測試。但是，代碼從未使用生產(chǎn)數(shù)據(jù)進(jìn)行過測試。

技術(shù)負(fù)責(zé)人聯(lián)系了進(jìn)行修復(fù)的開發(fā)人員。他們一起審視修復(fù)，發(fā)現(xiàn)當(dāng)應(yīng)用于小數(shù)據(jù)集時，更改看起來是良性的。技術(shù)主管針對生產(chǎn)數(shù)據(jù)集的副本運行代碼。事實證明，封裝在函數(shù)getPastDueInvoices（dueDate）中的新代碼需要5秒鐘才能對生產(chǎn)數(shù)據(jù)執(zhí)行。

在進(jìn)行單元測試時，代碼修復(fù)需要1.5秒才能運行。因此，它似乎很好，但在生產(chǎn)中，它不是。會計系統(tǒng)配置為對發(fā)票模塊的調(diào)用超時時間為2秒?；貧w測試確保系統(tǒng)的一部分中的新代碼不會在整個系統(tǒng)中引起不必要的副作用。

事實證明，開發(fā)人員確實通過單元測試重新測試了代碼修復(fù)。QA進(jìn)行了高級別檢查，但未進(jìn)行回歸測試。修復(fù)工作在單元測試下達(dá)到預(yù)期，但在生產(chǎn)中運行時它破壞了系統(tǒng)。如果將修復(fù)程序合并到使用生產(chǎn)中運行的數(shù)據(jù)副本的系統(tǒng)范圍的回歸測試中，則在發(fā)布到生產(chǎn)之前發(fā)現(xiàn)該問題的可能性非常大。因此，回歸測試的價值和重要性。

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

回歸測試很有價值?？杀氖?，有時一家公司會認(rèn)為它正在進(jìn)行回歸測試，而實際上它正在進(jìn)行重新測試。重新測試是為了確保特定的代碼更改按預(yù)期工作。回歸測試旨在確保一旦引入變更，整個系統(tǒng)就能達(dá)到預(yù)期效果。因此，設(shè)計和實施回歸測試比重新測試具有更廣泛的活動范圍。

如果對軟件測試、接口測試、自動化測試、性能測試、LR腳本開發(fā)、面試經(jīng)驗交流。感興趣可以175317069，群內(nèi)會有不定期的發(fā)放免費的資料鏈接，這些資料都是從各個技術(shù)網(wǎng)站搜集、整理出來的，如果你有好的學(xué)習(xí)資料可以私聊發(fā)我，我會注明出處之后分享給大家。

通常，重新測試快速發(fā)生，在創(chuàng)建時間代碼或非常接近代碼。當(dāng)有更多時間可用于滿足執(zhí)行測試所需的更長時間跨度時，回歸測試在SDLC中進(jìn)一步發(fā)生。是的，一些重新測試可能非常復(fù)雜且耗時，但遠(yuǎn)不及執(zhí)行全面回歸測試所需的時間長度。請記住，充分的回歸測試意味著必須對系統(tǒng)的所有方面進(jìn)行測試，同樣重要的是，進(jìn)行監(jiān)控。在沒有適當(dāng)?shù)南到y(tǒng)范圍監(jiān)控的情況下執(zhí)行回歸測試會將測試工作轉(zhuǎn)變?yōu)椴轮i游戲。正如我們在開放場景中所展示的那樣，系統(tǒng)的某個部分可能會發(fā)生錯誤，但這可能是由另一部分的行為引起的。

將回歸測試納入迭代模型

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

一種解決方案是在迭代之間錯開回歸測試。每次迭代都會發(fā)布代碼版本。但是，在迭代過程中創(chuàng)建的代碼的回歸測試在迭代開始的一半開始，并繼續(xù)進(jìn)行下一次迭代。在迭代中途開始回歸測試允許測試從業(yè)者在迭代期間新代碼“穩(wěn)定”時發(fā)現(xiàn)問題。然后，可以在以下迭代中實現(xiàn)和吸收修復(fù)。

將回歸測試僅限于迭代中正在開發(fā)的當(dāng)前版本的代碼會產(chǎn)生創(chuàng)建瀑布動態(tài)的風(fēng)險。在執(zhí)行修復(fù)之前，開發(fā)團隊可能會陷入停滯狀態(tài)，等待回歸測試完成。然后，一旦問題被開發(fā)人員發(fā)現(xiàn)并解決，回歸測試人員需要等到新代碼可用后才能采取進(jìn)一步行動。顯然，這種“切換和等待”模式與敏捷的軟件開發(fā)方法是對立的。對迭代進(jìn)行錯綜復(fù)雜的回歸測試可以為測試人員提供執(zhí)行所需測試范圍所需的時間，同時允許開發(fā)人員在此期間創(chuàng)建新代碼。

把它放在一起

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

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

這就是為什么mabl可以幫助團隊為他們的應(yīng)用程序創(chuàng)建自動化測試，并自動化回歸測試。使用機器智能，mabl分析測試輸出以監(jiān)控整體健康狀況下降，視覺變化和性能下降。