資料結構
網路
關係資料庫管理系統 (RDBMS)
作業系統
Java
MS Excel
iOS
HTML
CSS
Android
Python
C 語言程式設計
C++
C#
MongoDB
MySQL
Javascript
PHP
物理學
化學
生物學
數學
英語
經濟學
心理學
社會學
服裝設計
法律學迴歸測試與重新測試的比較
重新測試
重新測試是指檢查在最終執行中發現存在缺陷或錯誤的單個測試用例的過程。在大多數情況下，測試人員在測試軟體程式時會發現這些缺陷，並將它們報告給開發人員進行更正。然後，開發人員修復錯誤並將其返回給測試人員進行審查。此持續過程稱為重新測試。
示例 - 假設已釋出版本 1.0。測試團隊在測試版本 1.0 時發現了某些問題（例如，缺陷 ID 1.0.1 和缺陷 ID 1.0.2）並進行了報告。測試團隊在版本 1.1 中檢查缺陷 1.0.1 和 1.0.2（僅當版本 1.1 發行說明中指定了這兩個問題時），以檢視它們是否已得到解決。
流程
一旦測試人員發現問題，就會根據缺陷生命週期將該缺陷提交給開發團隊。該缺陷的狀態應為“新建”。
開發團隊可能會接受或拒絕該缺陷。如果開發團隊同意修復該問題，它將包含在下一個版本中。該缺陷的狀態將變為“準備就緒，等待 QA”。
現在，測試人員檢查該缺陷以檢視它是否已得到解決。這種型別的測試稱為重新測試。重新測試是一種定期進行的測試方法。我們使用與先前版本中相同的測試用例和測試資料。
如果未檢測到該問題，則缺陷狀態將更改為“已修復”，否則狀態將更改為“未修復”，並將缺陷重新測試文件傳送給開發團隊。
何時應重新測試
當發行說明中提到特定問題修復時 - 開發團隊釋出新版本後，測試團隊必須測試之前報告的問題，以確保已解決這些問題。
當缺陷被拒絕時 - 有時，開發團隊會拒絕測試人員發現的一些問題，理由是該缺陷的狀態為“無法重現”。在這種情況下，測試人員必須重新測試相同的問題，以確保它是合法的並且對於開發人員是可以重現的。
當客戶請求重新測試時 - 客戶有時可能會要求我們重複測試，以建立對產品質量的信任。在這種情況下，測試團隊將重新測試產品。
修改程式碼後，絕不應僅重新測試問題修復就釋出產品；我們還必須進行迴歸測試。
什麼是迴歸測試以及它是如何工作的？
迴歸測試是一種軟體測試型別，用於確保最近的程式或程式碼修改不會破壞當前的功能。迴歸測試只是對以前執行的測試用例進行完整或部分重新執行，以確認當前功能是否正常工作。
迴歸測試可確保新的程式碼修改不會對當前功能產生意外後果。它確保在進行了最新的程式碼修改後，舊程式碼繼續發揮作用。
需要進行迴歸測試 - 當需要更改程式碼並且我們需要檢視更改後的程式碼是否影響軟體程式的其他部分時，迴歸測試的需求最常出現。當向軟體程式引入新功能時，以及針對錯誤和效能問題，也需要進行迴歸測試。
迴歸測試：分步指南
要開始迴歸測試過程，我們必須首先除錯程式碼以查詢任何缺陷。在檢測到缺陷並實施必要的修改後，透過從測試套件中選擇涵蓋更新和受影響程式碼部分的適當測試用例來執行迴歸測試。
軟體維護包括增強功能、錯誤修復、最佳化和消除現有功能。這些更改可能會導致系統出現故障。因此，需要進行迴歸測試。可以使用以下策略進行迴歸測試
應重複所有測試。
這是迴歸測試方法之一，其中重新執行現有測試桶或套件中的所有測試。這非常昂貴，因為它需要大量的時間和金錢。
迴歸測試選擇
迴歸測試選擇是一種方法，其中從測試套件中執行一部分測試用例，以檢視更新的程式碼是否對軟體應用程式有任何影響。測試用例分為兩類：可重用的測試用例，可在後續迴歸週期中重複使用；過時的測試用例，無法重複使用。
測試用例優先順序
根據測試用例的業務影響、嚴重性和使用頻率對其進行優先順序排序。如果對測試用例進行優先順序排序，則迴歸測試套件將大大減少。
迴歸測試測試用例選擇
根據行業統計資料，客戶報告的大部分缺陷是由最後時刻的錯誤修補程式造成的，這些修補程式產生了意外後果，這使得為迴歸測試選擇測試用例成為一門藝術，而不是一項簡單的任務。可以使用以下測試場景來建立有效的迴歸測試 -
缺陷數量較多的測試場景
如果功能更可見，使用者將能夠看到更多功能。
測試產品基本功能的測試場景
經歷重大和最近更改的功能的案例研究
所有整合測試用例
所有擴充套件測試用例
邊界值測試用例
下面顯示了一些成功的測試示例。
一系列失敗的測試場景
迴歸測試工具
如果您的軟體經常更新，則迴歸測試成本將會增加。在這種情況下，手動執行測試用例會增加測試執行時間和成本。在這種情況下，迴歸測試用例的自動化是最佳選擇。自動化的程度取決於可以在後續迴歸週期中重複使用的測試用例的數量。
以下是軟體工程中用於功能和迴歸測試的最重要的工具 -
Avo Assure
Eggplant
Selenium
Quick Test Professional (QTP)
Rational Functional Tester (RFT)
配置管理與迴歸測試
在程式碼不斷更新的敏捷環境中，迴歸測試期間的配置管理變得至關重要。為了確保迴歸測試成功，請牢記以下幾點 -
應使用配置管理解決方案執行迴歸測試程式碼。
在迴歸測試階段，不允許對程式碼進行任何修改。開發人員更改不得影響迴歸測試程式碼。
需要隔離用於迴歸測試的資料庫。不允許進行任何資料庫更新。
良好的迴歸方法可以為企業節省時間和金錢。根據銀行業的一個案例研究，迴歸在問題修復方面節省了高達 60% 的時間和 40% 的金錢（這些問題本來可以透過迴歸測試發現）。
QA 候選人經常詢問重新測試與迴歸測試。
迴歸測試與重新測試
透過的測試用例會進行迴歸測試，而失敗的測試用例會進行重新測試。
迴歸測試查詢意外後果，而重新測試確保已修復初始缺陷。
迴歸測試不包括缺陷驗證，而重新測試則包括缺陷驗證。
迴歸測試被稱為通用測試，而重新測試被稱為計劃測試。
自動化允許進行迴歸測試，但不允許進行重新測試。
下面提供了帶有示例的完整比較。
| 迴歸測試 | 重新測試 |
|---|---|
| 迴歸測試用於確保最近的程式或程式碼修改沒有破壞任何現有的功能。 | 在解決故障後，會進行重新測試以確保在最終執行中失敗的測試用例透過。 |
| 迴歸測試的目標是確保新的程式碼修改不會影響當前的功能。 | 根據缺陷修復，進行重新測試。 |
| 迴歸測試不包括缺陷驗證。 | 重新測試包括缺陷檢查。 |
| 根據專案和可用資源，迴歸測試和重新測試可以同時進行。 | 重新測試比迴歸測試具有更高的優先順序，因此在迴歸測試之前完成。 |
| 迴歸測試可以自動化，但手動測試可能代價高昂且耗時。 | 重新測試的測試用例無法自動化。 |
| 迴歸測試是一種用於各種目的的測試。 | 重新測試是一種定期進行的測試方法。 |
| 透過的測試用例會進行迴歸測試。 | 只有失敗的測試用例才會進行重新測試。 |
| 迴歸測試查詢意外後果。 | 重新測試確保已解決初始問題。 |
| 僅當修改現有專案或需要修改時才執行迴歸測試。 | 使用新的構建，重新測試使用相同的資料和環境但不同的輸入執行缺陷。 |
| 迴歸測試用例可能存在於功能規範、使用者培訓和手冊以及已修復問題的缺陷報告中。 | 在開始測試之前，無法獲取重新測試的測試用例 |
649 次檢視
