逍遙文工作室

軟體開發絕對少不了測試這個重要環節，每次在上線後都可能會出現不預期狀況，我們主要會歸咎測試量不足。我們進行的測試有很多種，那麼回歸測試 (Regression Testing) 是做什麼用途呢？🤔

在此想要徹底了解幾個議題：

• 回歸測試是什麼？
• 為什麼要做回歸測試？
• 為什麼叫做回歸測試？
• 回歸測試由誰進行？
• 回歸測試需要多少時間？

回歸測試是什麼？

回歸測試（Regression Testing）是軟體測試中的一種技術，用於確保在對軟體進行修改後，新版本沒有引入新的缺陷或錯誤，並且現有的功能仍然正常工作。這種測試通常在以下情況下進行：

1. 修復缺陷後：當修復了一個或多個缺陷時，需要進行回歸測試以確保這些修復沒有引入新的問題。
2. 添加新功能後：當添加新功能或特性時，回歸測試可以確保新功能與現有功能沒有衝突。
3. 優化程式碼後：程式碼優化或重構後，需要進行回歸測試以確保改進沒有引入新的缺陷。

回歸測試的主要目的是驗證軟體的穩定性和可靠性，並確保軟體在每次修改後仍能正常運行。這通常是通過重新運行之前已經通過的測試用例來實現的，以確保所有功能仍然按預期工作。

進行回歸測試的方法包括：

1. 手動回歸測試：測試人員手動執行先前的測試用例，這種方法較為耗時且容易出錯。
2. 自動化回歸測試：使用測試自動化工具來自動執行測試用例，這種方法較為高效且可重複性高。

自動化回歸測試通常更受歡迎，因為它能夠快速、精確地執行大量測試用例，並且減少了人為錯誤的可能性。

總之，回歸測試是軟體開發過程中不可或缺的一部分，它能夠幫助開發團隊維持軟體質量，確保每次修改後系統的穩定性和可靠性。

為什麼要做回歸測試？

回歸測試主要目的是確保在對軟體進行修改後，系統仍然能夠穩定、正常地運行。具體來說，回歸測試有以下幾個主要原因：

1. 檢測新缺陷：當程式碼被修改後，新程式碼可能會引入意想不到的缺陷。回歸測試有助於識別這些潛在的問題，確保修改不會對系統的其他部分造成負面影響。
2. 確保舊功能正常運行：系統中的一個小改動可能會影響到已經存在的功能。回歸測試確保所有現有功能在修改後仍然正常運行，這對於保持軟體的一致性和可靠性至關重要。
3. 提高軟體品質：透過定期進行回歸測試，能夠發現和修復問題，從而提高整個軟體的品值。這有助於降低軟體發佈後的維護成本和風險。
4. 支持持續整合和持續交付：在持續整合（CI）和持續交付（CD）的環境中，回歸測試是一個關鍵組成部分。每次程式碼變更後自動運行回歸測試，可以確保每個版本的軟體都是穩定和可靠的。
5. 驗證修復的有效性：當缺陷被修復後，需要確保修復是有效的並且沒有引入新的問題。回歸測試可以確認修復是否成功，並且沒有對其他功能造成影響。
6. 維持用戶信任：高品值、高穩定的軟體能夠增強用戶對產品的信任。透過回歸測試，能夠確保軟體在每次更新後都能正常工作，從而提高用戶滿意度和信任度。

總結，回歸測試在軟體開發中起著關鍵作用，幫助確保系統在進行修改後仍然穩定和高效，並減少潛在的風險和問題。

為什麼叫做回歸測試？

回歸測試這個名稱源於「回歸」這個詞，該詞有「回到之前的狀態」的意思。在軟體測試的上下文中，回歸測試旨在驗證在軟體修改後，系統是否能夠「回到」之前的正常工作狀態，確保新的變更沒有破壞已有的功能。

具體來說，回歸測試的目的是：

1. 驗證修復缺陷後的系統穩定性：當一個或多個缺陷被修復後，回歸測試檢查這些修復是否引入了新的問題或是否影響了其他功能。
2. 驗證新功能整合後的兼容性：當添加新功能或特性後，回歸測試檢查新功能是否與現有功能兼容，並確保整個系統的正常運行。
3. 檢查程式碼變更後的影響：當程式碼進行優化、重構或其他變更後，回歸測試確保這些變更沒有對系統的其他部分造成負面影響。

回歸測試的核心理念是確保軟體在每次變更後仍能保持穩定和可靠，因此回到之前已知的穩定狀態這一概念非常重要，這也是為什麼這種測試被稱為「回歸測試」的原因。

回歸測試由誰進行？

回歸測試通常由專門的測試人員（QA 工程師）或開發團隊成員（RD 工程師）進行，具體由誰進行可能會根據團隊的結構和專案的需求有所不同。以下是一些常見的情況：

1. 專業測試團隊：
   • QA工程師：專門的軟體測試工程師通常負責設計、編寫和執行回歸測試。他們會根據測試計劃和測試用例來確保軟體的各項功能在修改後仍然正常工作。
   • 測試自動化工程師：專注於自動化測試的工程師負責編寫和維護自動化測試腳本，這些腳本可以在每次程式碼變更後自動執行，從而節省時間和提高測試效率。
2. 開發團隊：
   • 開發人員：在某些敏捷開發或持續整合/持續交付（CI/CD）環境中，開發人員可能會自己進行回歸測試，特別是在進行單元測試和整合測試時。他們會確保在提交程式碼之前，新修改的程式碼不會破壞現有功能。
3. 混合模式：
   • 跨職能團隊：有些團隊採用跨職能模式，測試人員和開發人員共同合作進行回歸測試。測試人員負責設計測試用例和監控測試結果，而開發人員則可能參與測試腳本的編寫和測試的執行。
   • 持續測試：在持續整合和持續交付（CI/CD）環境中，回歸測試通常是自動化的一部分。測試自動化工具會在每次程式碼提交後自動運行回歸測試，並將結果反饋給開發團隊，以便及時修復問題。

無論由誰進行，回歸測試的目標都是確保在對軟體進行任何修改後，所有現有功能仍能正常運行，從而提高軟體的穩定性和可靠性。

回歸測試需要多少時間？

回歸測試所需的時間會因多種因素而異，包括軟體的規模、複雜性、測試用例的數量、自動化程度以及團隊的經驗等。以下是一些影響回歸測試時間的主要因素：

1. 軟體規模和複雜性：
   • 大規模和高複雜度的軟體需要更多的測試用例來覆蓋所有功能和場景，因而回歸測試時間會較長。
   • 小規模和低複雜度的軟體則相對需要較少的測試用例，回歸測試時間會較短。
2. 測試用例數量：
   • 測試用例越多，回歸測試所需的時間越長。
   • 測試用例少則時間相對較短。
3. 自動化程度：
   • 自動化測試可以顯著減少回歸測試的時間。自動化測試腳本可以快速且準確地執行大量測試用例，通常只需數小時或更短時間。
   • 手動測試則會耗費更多時間，尤其是當測試用例較多時，可能需要數天甚至數週。
4. 測試環境和工具：
   • 高效的測試環境和先進的測試工具可以加快測試過程，減少測試時間。
   • 測試環境不穩定或工具不夠先進則可能延長測試時間。
5. 團隊經驗和技能：
   • 有經驗的測試團隊和熟練的測試人員可以更有效地設計和執行測試，從而縮短回歸測試時間。
   • 缺乏經驗的團隊可能需要更多時間來完成相同的測試工作。

回歸測試時間範例

• 小型專案：對於一個功能簡單的小型專案，如果測試用例較少且部分測試自動化，回歸測試可能只需幾個小時到一天時間。
• 中型專案：對於一個功能較多且複雜度中等的專案，回歸測試可能需要幾天時間，特別是如果大部分測試是手動的。
• 大型專案：對於一個功能豐富且複雜的大型專案，回歸測試可能需要數週時間，特別是如果測試用例數量龐大且大部分是手動測試。不過，這種情況下通常會強烈建議進行測試自動化，以縮短測試時間。

總結，回歸測試所需的時間是不固定的，具體情況需要根據專案特點和測試策略來決定。有效的測試自動化和優化的測試環境可以顯著減少測試所需時間。

.

對我們團隊來說，主要考量是人力與時間的分配，想要以最少的時間成本來達到最優的人力分配。看來就是要有所取捨，先將要測試的項目分門別類，然後排列優先順序來執行。🙃