什麼是迴歸測試？（定義、測試用例、示例）

---

什麼是迴歸測試以及它是如何工作的？

迴歸測試是一種用於確保軟體更新不會影響產品當前功能的測試。

這是為了保證任何新的功能、錯誤修復或對當前功能的修改都不會破壞產品。為了驗證修改的影響，會重新執行之前執行的測試用例。

迴歸測試是一種軟體測試，其中會重新執行測試用例，以檢視應用程式以前的功能是否仍在正常執行，以及新的更改是否導致了任何新的缺陷。

當原始功能發生重大更改時，即使只是一個錯誤修復，也可能會在新版本上執行迴歸測試。

迴歸是指重新測試程式中未更改的元素。

何時應執行迴歸測試？

迴歸測試通常在修改或新功能驗證之後進行。但這並非總是如此。對於需要數月才能完成的版本，迴歸測試必須包含在日常測試周期中。當對每週版本的修改進行功能測試完成後，可以執行迴歸測試。

重新測試的一種變體是迴歸檢查（這僅僅是重複測試）。重新測試的原因可能是任何事情。假設您在一天結束時測試某個功能，並且您無法完成測試，並且被迫在未確定測試成功或失敗的情況下停止該過程。

當您第二天返回時，您重複考試——這表示您正在重複您已經完成的測試。重新測試是重新進行測試的簡單過程。

迴歸測試本質上是一種重新測試。應用程式/程式碼中有一些東西發生了變化，特別是對於這個獨特的場合。它可能是程式碼、設計或任何其他決定系統整體結構的東西。

在這種情況下，迴歸測試是一種重新測試，用於確保修改不會影響以前正常執行的任何內容。

最常見的原因是由於程式碼的新版本被開發出來（由於範圍/需求的擴充套件）或問題得到解決。

迴歸測試的目的是什麼？

當程式設計師修復缺陷或為新功能新增新程式碼到系統時，就會發生迴歸。

新引入的功能和現有功能可能有很多依賴關係。

這是一個質量檢查，以檢視新程式碼是否與舊程式碼相容，以便不會損壞未修改的程式碼。測試團隊通常負責檢查系統是否存在任何最後一刻的更改。

在這種情況下，只需要測試受影響的應用程式區域，以便在覆蓋所有重要的系統元素的同時按時完成測試過程。

當應用程式持續更改/改進時，此測試至關重要。附加功能不應對已經過測試的程式碼產生不利影響。

迴歸測試對於查詢由於程式碼修改而產生的問題是必要的。如果不進行此測試，產品可能在現實世界中存在重大缺陷，從而危及客戶。

測試人員報告產品價格顯示不正確的問題，即顯示的價格低於產品的實際價格，必須儘快解決。

開發人員修復問題後，必須對其進行重新測試，並且還需要進行迴歸測試，因為雖然已更正報告頁面上的價格，但它可能仍在摘要頁面上顯示不正確價格（總價與其他費用一起顯示），或在傳送給客戶的電子郵件中。

如果不進行此測試，消費者將蒙受損失，因為網站使用錯誤的價格計算總成本，並透過電子郵件向客戶傳送相同的金額。如果在客戶批准後以更低的價格線上提供產品，消費者將損失金錢。

因此，測試起著重要作用，既必要又實用。

迴歸測試型別

下面列出了多種迴歸測試型別：

• 單元迴歸 − 在單元測試階段，程式碼是隔離測試的，這意味著停用對被測試單元的任何依賴關係，允許單元獨立測試而沒有任何差異。

• 部分迴歸 − 部分迴歸用於確保即使對程式碼進行了修改並將單元與其他未修改或已存在的程式碼合併後，程式碼也能繼續正常執行。

• 完全迴歸 − 當代碼中的更改影響多個模組並且不知道另一個模組更改的影響時，使用完全迴歸。對整個產品進行迴歸測試，以檢視由於更改的程式碼是否產生了任何修改。

迴歸測試技術

下面列出了多種方法。

全部重測

顧名思義，重新執行完整的測試套件，以確保程式碼更改不會導致任何問題。這種方法比其他方法成本更高，因為它需要更多的時間和金錢。

選擇性迴歸測試

在此技術中，選擇測試套件中的測試用例來重新執行。這與重新執行整個套件不同。測試用例的選擇基於模組程式碼的更改。

測試用例有兩種型別：可重用測試用例和已過時測試用例。可重用測試用例可以在後續的迴歸週期中重複使用，但已過時的測試用例不會在後續的迴歸週期中使用。

測試用例優先順序排序

首先進行高優先順序測試用例，然後進行中優先順序和低優先順序測試用例。測試用例的重要性取決於其關鍵性和對產品的影響，以及最常用產品的功能。

混合方法

混合方法結合了迴歸測試選擇和測試用例優先順序排序。僅選擇基於其優先順序重新執行的測試用例，而不是整個測試套件。

迴歸測試選擇

迴歸測試選擇是一種方法，其中執行測試套件中的一部分測試用例，以檢視更新的程式碼是否對軟體應用程式有任何影響。測試用例分為兩類：可在後續迴歸週期中重複使用的可重用測試用例和不能重複使用的已過時測試用例。

測試用例優先順序排序

根據測試用例的業務影響、關鍵性和使用頻率對其進行優先順序排序。如果對測試用例進行優先順序排序，迴歸測試套件將大大減少。

迴歸測試用例選擇

根據行業統計資料，客戶報告的大部分缺陷是由最後一刻的錯誤修復程式造成的意外後果，這使得選擇迴歸測試的測試用例成為一種藝術，而不是一項簡單的任務。可以使用以下測試場景來建立有效的迴歸測試：

• 缺陷數量較高的測試場景

• 如果使用者可見性更高，他們將能夠看到更多功能。

• 測試產品基本功能的測試場景

• 近期發生重大更改的功能案例研究

• 所有整合測試用例

• 所有擴充套件測試用例

• 邊界值測試用例

• 下面顯示了一些成功的測試示例。

• 一些失敗的測試場景

下面列出了迴歸測試的不同好處。

• 它提高了產品的質量。

• 這保證了任何錯誤補丁或新增的內容都不會影響產品的當前功能。

• 可以使用自動化技術進行此測試。

• 這將保證以前已解決的問題不會再次出現。

迴歸測試示例

我們將使用一個涉及影像處理軟體開發的專案來演示如何進行迴歸測試。

討論將基於現實情況，涵蓋手動和自動迴歸測試。

但首先，讓我們看看一些現實世界的例子，說明這種測試的不同之處及其重點；

• 錯誤迴歸 − 對聲稱已解決的錯誤進行重新測試。

• 舊修復方法 − 對以前已解決的所有問題和錯誤進行重新測試，以確保這些區域仍然功能正常。迴歸測試的建立目標就是如此。

• 轉換/移植方法 − 在這種情況下，軟體被遷移到不同的平臺。下一步是執行迴歸測試，以檢視遷移的軟體是否成功整合。大部分更改將針對較新的環境，而不是之前的環境。

• 配置方法 − 在這種情況下，引入了更新版本的應用程式或裝置，並且程式在其上或與其一起執行。轉換測試與這種情況非常相似。但是，只有環境和與問題程式相關的少陣列件會發生更改，原始程式碼或平臺不會更改。

有幾種可用於自動化迴歸測試用例的自動化工具；但是，應根據專案的需要選擇工具。由於迴歸測試套件需要經常更新，因此工具應該能夠更新測試套件。

至此，我們將結束討論，並期望未來對這個問題會有更清晰的認識。