重新測試教程：包含範例與最佳實踐的全面指南

重新測試是一個驗證特定功能在先前測試中失效的過程。這是為了確認在執行時間報告了某些錯誤的測試案例是否已被修復。

在軟體開發生命週期中，主要的關鍵元素是測試軟體的功能、性能、安全性及其他方面，這涉及檢查軟體是否有任何錯誤。然而，主要的挑戰是驗證軟體是否符合目標觀眾的工作。確保開發軟體的有效性和可靠性至關重要，而重新測試在此扮演著救星的角色。

軟體測試的主要目標是識別軟體應用程式中的錯誤或缺陷。測試工程師負責確定這些問題並向開發團隊報告以進行進一步評估。隨後，這些問題被解決並送回測試工程師進行重新驗證。

重新測試確保在軟體發布期間不會出現額外問題。這樣的過程可以通過手動使用特定的測試案例集來執行。無論重新測試中涉及的複雜性如何，我們應該理解這是交付高質量產品的軟體測試的根本部分。

什麼是重新測試？

您必須習慣於這樣的事實：在測試軟體時發現錯誤是測試工程師的工作角色。在這樣的任務中，他們負責修復並將錯誤或問題送回開發人員，確保他們修復這樣的錯誤或問題。這裡就是重新測試的用武之地。讓我們更清楚地理解這一點。

在軟體開發中，重新測試是驗證開發者提供的版本以確保錯誤已被修復的過程。簡單來說，假設你正在測試某個軟體的「版本號1」，如果遇到任何錯誤，例如其ID為A1，那麼測試員將針對此錯誤進行測試，並稱之為「版本號2」。

換句話說，在版本號1中發現的錯誤在版本號2中再次被測試，以檢查開發者是否已修復該錯誤。在這裡，測試員重新測試失敗的案例以驗證開發者所做的修復。

這是缺陷生命周期的一部分，其中對先前測試時無法運作、後由開發者修復的失敗測試案例進行測試。

遵循以下要點以獲取更多關於重新測試過程的信息：

• 對應於報告的錯誤的失敗測試案例會被重新測試。
• 重新測試的另一個名稱是確認測試。
• 對於新版本中報告的錯誤，應使用類似的測試數據和過程來驗證其可重現性。

A comprehensive example of the retest process will help you get a clearer picture.

為什麼重新測試很重要？

重新測試作為軟體測試生命周期的一部分，圍繞著與產品有效交付相關的多種重要性。毫無疑問，它是標準軟體測試過程的主要部分。但除此之外，它還為產品提供了額外的保證層，在釋放給最終用戶之前篩選其技術和功能性能。

在競爭激烈的軟件開發市場中，企業應確保高品質的數位應用程式，這要求最終產品的品質不容妥協。

自動化測試平台常能助您為已發布的產品獲得更佳的投資回報率。然而，重新測試透過驗證每個錯誤提供更多信心。相較於初次測試流程，它既不增加測試資源的額外成本，也不耗費大量時間。眾所周知，它是在相同環境中使用與失敗測試案例相關的類似數據執行的。

此外，重新測試過程專門針對特定應用模組中記錄的特定問題或錯誤。因此，您無需設置新的測試環境，亦無需投入更多精力進行端到端的產品品質驗證。

重新測試的範例

儘管上述解釋的範例能助您獲得表面資訊，接下來，我們將深入探討一個類似的範例，以更深層的視角了解其過程。

場景

作為軟件開發過程的一部分，發布了Build 2.0。在其測試期間，團隊發現並釋出了一個缺陷（例如，Defect 2.0.1）。類似的Defect 2.0.1將在Build 2.1中進行測試（條件是此缺陷在Build 2.1的發布說明中被提及），以確保缺陷已被修復。

執行過程

根據Bug生命週期，當錯誤被記錄後，它會立即被分享或報告給開發團隊。之後，其狀態被標記為“新建”。現在，由開發團隊來決定接受或拒絕該錯誤。

一旦錯誤被接受，開發者將修復它，並在下一階段釋出。其狀態被標記為“準備好進行QA”。目前，測試人員驗證該錯誤以確定其解決方案。因此，可以說重新測試是一種計劃中的測試。

測試人員使用先前版本中的相同測試案例和測試數據。如果未發現錯誤，其狀態將被標記為“已修復”。相反地，狀態保持為“未修復”。然後，缺陷重新測試文件被共享給開發團隊。

要深入了解重新測試，您必須知道其主要特點。這不僅有助於多樣化您的測試，還能擴大軟件品質建設的維度。

重新測試的特點

頂尖的軟件測試用戶體驗遵循迭代過程。為此，保留有關重新測試過程關鍵方面的信息有助於更好地交付應用程序。

以下是其主要特點：

• 它在新版本中以與先前相同文件實施和處理。
• 執行時，特定的測試案例被認為是失敗的。
• 當整個軟件需要重新測試以驗證其品質時，就會發生這種情況。
• 重新測試的測試案例無法自動化。
• 重新測試的過程依賴於開發團隊，他們負責接受或拒絕該錯誤。
• 測試人員會考慮功能變更方面的細節。

何時應該執行重新測試？

作為測試人員，決定何時進行重新測試至關重要。答案很直接。首先，您必須考慮您的專案規模和功能，這些都需要測試。

例如，如果一個組織擁有廣泛的產品線，分布在各種產品中，重新測試就成為常態。這是因為需要及時發布軟體應用程式，這也可能以多種方式影響系統的其他部分。

在不同的情況下，我們可以使用重新測試作為過程。下面解釋了一些情況：

發現被拒絕的錯誤時

測試人員發現的錯誤多次被開發者拒絕並標記為“無法重現”。在這種情況下，會對同一個錯誤進行重新測試，以告知開發者該問題是可重現且有效的。

發行說明中強調的錯誤修復需求

在軟體開發過程中，當開發團隊發布新版本時，會進行重新測試。在這裡，測試人員會測試先前報告的錯誤，以確保它們已被修復。

客戶請求

軟體品質是每個組織關注的重點。為此，客戶可能會要求對特定使用案例進行重新測試，以確保產品品質。

其他情境

值得注意的是，每當修復一個錯誤時，開發人員會創建額外的測試案例。這表明應該花更多時間編寫測試案例而非修復它們。儘管您對自己的代碼庫充滿信心，但在每次發布時重新測試應用程式的關鍵部分仍然至關重要。

例如，新功能可能導致意外行為，並在初次檢測時難以發現錯誤。這些問題只有在測試過程中或根據用戶反饋變得明顯時才可能被察覺。這種情況要求您進行「重新測試」，以消除對新發現錯誤的疑慮。

重新測試的好處

軟體應用程式的品質取決於重新測試過程的成功與否。它確保了軟體開發生命週期中應用程式的穩定性。

以下是其主要優點的概述：

• 確認錯誤是否已被修復。
• 提升產品和開發應用程式的品質。
• 確保應用程式或產品的工作符合用戶期望。
• 由於針對特定問題，修復錯誤所需的時間較少。
• 使用新版本與相同數據和流程進行工作。
• 不需要新的測試環境設置。

儘管重新測試過程具有多項優點，但也存在一些缺點。讓我們從以下段落中了解這一點。

重新測試的缺點

A retest process also has some drawbacks, which can hamper or create challenges in the testing process. Knowing such limitations will help you address those while retesting to avoid any issues.

讓我們來看看具體有哪些：

• 需要新版本來驗證缺陷。
• 重新測試的測試案例只能在開始後獲取。
• 無法自動化重新測試的測試案例。
• 重新測試失敗的測試案例需要額外時間和努力。
• 除非發現或修正錯誤，否則無法保證重新測試作為測試過程的一部分。

針對重新測試的缺點，可以說重新測試對某些測試人員來說可能具有挑戰性。尤其是新手測試人員經常試圖尋找替代方法來解決問題。在此，讓他們困惑的是回歸測試這個術語。然而，回歸測試與重新測試之間存在顯著差異。

回歸測試與重新測試之間的區別是什麼？

如果您是軟件測試的新手，您可能會認為“重新測試”和“回歸測試”這兩個術語相似。然而，事實是它們雖然相關，但有所不同。在本節中，我們將探討重新測試過程與回歸測試有何不同。

首先，回歸測試和重新測試是軟件驗證過程中的組成部分。重新測試主要在開發的特定階段結束時進行。換句話說，當你想確保一個可工作的產品沒有被之前的測試中的錯誤所困擾時，你會進行重新測試。相反，回歸測試可以在任何開發階段執行，以確保特定代碼部分的正確工作。

在某些情況下，測試人員可以通過簡單地閱讀早期的測試輸出或報告來運行重新測試，以檢查任何問題及其修復。也可以通過單獨檢查早期的案例來進行全面的調查，以確保它們得到處理。然而，回歸測試主要是通過一個測試計劃並在每個應用程序版本上執行，從最新版本開始。在這種方法中，你必須確保對應用程序的每個變化都進行了適當的測試。

以下是回歸測試和重新測試過程之間的一些關鍵差異點：

通過一個例子理解回歸測試和重新測試

回歸測試和重新測試之間的區別可以通過以下例子來解釋。

假設，如果銀行網絡應用程序的登錄頁面存在一個問題，客戶無法訪問他們的帳戶詳細信息。儘管他們被要求再次嘗試登錄，但他們未能登錄到他們的帳戶。支持團隊調查了這個問題，並確保這種情況不會再次發生。

開發團隊進行了代碼層面的修改，以確保在所有瀏覽器中都能成功登錄到帳戶頁面。然而，此處的測試不僅涉及登錄頁面，還需確保代碼變更不會影響銀行網路應用程式的其他功能。這裡進行的測試將針對應用程式的修改進行檢驗，這稱為回歸測試。

在再次檢查與所做修改相對應的問題時，測試團隊嘗試登錄該頁面，但失敗了。支援團隊與相關開發者溝通並解釋了問題。然而，開發者告訴我們他們已經修復了問題。品質保證團隊測試網路應用程式的運作，以檢查問題是否已解決，這稱為重新測試。

因此，重新測試在軟體測試過程中是必不可少的，並且是確保其運作的前提。

我們討論了重新測試過程的重要性，這讓人們了解它與軟體測試的關聯。首先，讓我們了解它在軟體測試中的一些典型應用。以下是重新測試在軟體測試中的一些應用：

• 用於糾正任何特定的錯誤或缺陷，這需要驗證。
• 檢查整個系統的運作以驗證最終功能。
• 檢查系統特定部分的品質。

重新測試的階段

重新測試過程涉及手動方法。它也考慮了測試軟體應用程式的基本階段。

以下是重新測試過程中涉及的階段：

1. 測試案例的選擇 

測試案例選擇是一種方法，其中從測試套件中選擇特定的測試案例來檢查軟件中的錯誤是否已修正。一般來說，測試案例分為可重用和過時兩類，其中可重用的測試案例用於進行重新測試。

2. 測試案例的應用

重新測試過程的主要焦點是比較測試案例的預期輸出。因此，必須應用具有標準預先執行結果表的測試案例。

3. 時間估算

在識別測試案例時，測試人員應考慮重新測試所需的總執行時間。像測試案例評估這樣的因素可能會增加額外時間。

4. 模塊追蹤

在測試案例失敗的情況下，識別對應的錯誤模塊是一個主要挑戰。因此，軟件部分被劃分為不同的單獨模塊。

為此，針對特定單獨模塊實施小型測試案例。未顯示預期結果的模塊被標記為有缺陷的模塊。通過這種方式，完成了有缺陷模塊的追蹤。

5. 模塊的重新測試

對有缺陷的模塊進行重新測試，直到其被修復。

6. 模塊的重整合

在修復有缺陷的模塊後，將完整的測試案例整合應用於軟件。進一步檢查軟件的運作情況。

如何進行重新測試？

軟件應用程序的重新測試只能通過手動方法進行。如上節所述，主要原因是它僅專注於特定缺陷。因此，手動測試方法更為適合，因為它比自動化方法更精確。

要進行重新測試，測試團隊應對軟件應用程序的當前狀態有深入了解。了解軟件的工作原理以及如何通過修正錯誤使其有效，這有助於手動方法的實施。

測試人員手動執行測試案例以驗證應用程序中的更改。這是為了確保這些更改不會導致任何新缺陷，並且在新版本中消除了已發現的失敗案例。您可以在修改軟件更改、修復缺陷並完成軟件測試周期後進行手動重新測試。

您可以按照以下步驟手動進行重新測試：

1. 確定軟件應用程序的更改以及需要重新測試的區域。
2. 根據更改審查和更新需要重新測試的測試案例。
3. 應手動執行開發的測試案例。
4. 分析實際輸出與預期結果，以評估更改不會導致新缺陷。
5. 如果發現缺陷，應記錄並報告給開發團隊。
6. 重複手動重新測試過程，直到所有缺陷都被修復。

然而，您可能會疑惑為何不能透過自動化方法進行重新測試。這背後有幾個原因。讓我們從以下段落中獲得一些啟示：

重新測試能否自動化？

您無法使用自動化方法對應用程式進行重新測試。以下列出了一些常見原因：

• 複雜性：某些失敗案例可能是由於軟體的複雜性所導致。因此，這類失敗案例難以自動化。
• 意外結果：軟體中的變更可能會產生意料之外的結果。在這種情況下，失敗案例需要透過手動測試來驗證結果。
• 成本與資源：自動化重新測試流程可能成本高昂，因為這涉及使用額外的硬體和軟體。對於軟體中的微小變更，其成本難以合理化。
• 時間限制：自動化重新測試流程需要耗費大量時間，且在及時發布的壓力下，手動方法是最合適的選擇。

進行重新測試時需考慮的事項

至此，我們已理解重新測試過程的重要性及其執行方式。然而，在重新測試中存在有效的考慮因素需要關注。以下是需要考慮的幾個要點：

• 重新測試過程需要在根據首份報告修正問題後，建立新的軟體版本。
• 軟體送交重測時可能會經歷程式碼層級的變更，因此，在應用程式釋出前進行回歸測試至關重要。
• 重測的覆蓋範圍與範疇需待問題修正後方能知曉，因此，重測階段無法如回歸測試般執行自動化。
• 若重測中發現的問題持續存在，應用程式的開發時間可能會增加。需要進行更全面及策略性的評估，以探究根本原因。

儘管重測過程中會遇到挑戰，組織仍需專注於測試方法的認真執行。透過雲端進行重測，將能更有效地達成此目標。以下將詳細探討此議題。

如何在雲端執行重測？

自動化重測流程並非總是可行，有時需透過手動測試來確保軟體品質。然而，這在某些情況下可能耗時且不具擴展性。雲端測試平台能助您克服與測試基礎架構相關的挑戰。