什麼是回歸測試？
什麼是回歸測試？
一些軟體開發團隊試圖在不執行定期回歸測試的情況下度過難關，選擇只測試一次基本功能以確保它們可以工作，如果他們檢查了，則繼續滿懷希望地假設這些功能仍然可以工作，除非它們再次被修改。在某種程度上，這是有道理的：想要簡單地進行更改、測試它並繼續前進是很自然的。執行功能測試或高度具體的單元測試以確定新軟體元件是否正常運作，Doug Hoffman 等人稱之為「非回歸測試」。但當您尋找特定問題時，找到它可能相對容易；更難的是抓住所有你意想不到的問題。
同樣，對於開發人員和測試人員來說，重要的是要記得，即使是對應用程式原始碼進行看似微不足道的微小更改，也可能以令人驚訝的方式向外傳播，破壞看似與新功能或修改處完全無關的地方。當您執行回歸測試時，您要檢查以確保您的修改不僅按照您想要的方式執行，而且還沒有無意中導致先前測試時原本正常工作的程式碼出現問題。
幸運的是，對於準備好的回歸測試人員來說，在任何一項專案中，您的回歸測試庫都可以根據從一開始開發的測試案例來建立。功能測試、單元測試、整合測試、建置驗證測試，也就是在整個開發過程中能夠驗證各種元件是否按預期工作的所有測試項目，都可以整合到回歸測試套件，而「回歸測試」本身不是每次都要撰寫的。每次修改程式碼時，您只需重新執行可能相關的測試而非全部的回歸測試，並確保它們都是通過的。當然，在複雜的開發專案過程中，這些測試案例以及它們嘗試檢查的各種功能和流程可能會達到數千個，因此必須使用自動化測試軟體來進行全面的回歸測試。TestComplete 可以幫助您重複使用先前的自動化測試來輕鬆建立持續的回歸測試。
為了降低全世界開發團隊的壓力，專門從事回歸測試的各種自動化測試工具現在可以相對輕鬆地透過幾下滑鼠點擊來建立測試參數集，並根據先前的基準檢查新的程式碼迭代或控制狀態，從測試日誌中找出不一致的地方，並準確找出發生問題的功能位置及原因。您可能沒有足夠的資源和時間讓您的軟體重新執行每個測試，並檢查整個應用程式是否存在潛在錯誤，但這絕對比您人工進行測試要有效率的多 – 特別是如果您使用像 BitBar 這樣的視覺回歸工具。事實上，如果您採用好的自動化回歸測試工具，會讓您的工作變得簡單很多。
自動化的局限性
與大多數形式的自動化測試一樣，在自動駕駛功能上設定回歸測試程序並不是萬無一失的解決方案，通常仍然需要一些有意識的監督和輸入，以確保您的測試能捕捉所有應被找到的錯誤。當您日以繼夜地重複執行完全相同的測試套件時，測試過程本身可能會變得無聊。隨著時間的推移，開發人員可能會偷偷規避一些特定的測試，而您的標準回歸測試組可能會在最終變得什麼也測不到。
某個程度而言，確保您的軟體在開發時繼續遵守需求規格就像在地雷區中掃清道路一樣。為了安全地穿越敵方領土，專業拆雷人員不需要清理整個場地；他們只需要清理一條路徑，設定明確的界線，並持守在該路徑上。一旦有足夠多的士兵在那裡守衛，就不太可能有人在上面埋下新的地雷，而在這個比喻中，這些士兵代表了你的回歸測試。然而，這條持續暢通的道路並沒有說明其他可能仍然存在的地雷，無論是新的還是舊的，只是在等待無知的百姓踩上去。
同樣的，如果你的回歸測試變得過於自動化和墨守成規，這樣下來整個測試目的可能會導致適得其反的效果。您最終可能僅會為自己和開發團隊保持一條暢通的道路，但也同時忽略了應用程式的其他大量功能，讓您的最終用戶偶然發現未被發現的錯誤，最終成為受害者。當然，沿著阻力最小的單一路徑行走比在每個新步驟之後停下來掃描整個應用程式更容易，但是透過頻繁增加檢查範圍的方式來進行回歸測試是值得的。而很多時候使用一些老舊的人工測試可以來彌補您自動化測試的不足之處，或在當中取得平衡。
回歸測試的未來
為了使回歸測試有效，需要將其視為綜合測試方法的一部分，該方法具有成本效益和高效性，同時仍包含足夠的多樣性，例如精心設計的前端 UI 自動化測試以及基於智慧的有針對性的單元測試。基於風險優先順序－減少軟體檢查遺漏的地方。如今，許多採用 XP（eXtreme Programming）、RUP（Rational Unified Process）、Scrum 等工作流程的 Agile 實務工作環境都將回歸測試視為動態、迭代開發和部署計畫的重要面向。
但無論您的組織使用什麼軟體開發和 QA 流程，如果您花時間預先進行足夠仔細的規劃，制定以自動化回歸測試為核心的清晰且多樣化的測試策略，您可以幫助預防專案超出預算，讓您的團隊步入正軌，最重要的是，防止意外錯誤損害您的產品和公司的利潤。
文章來源: What is Regression Testing?, SmartBear 2024
https://smartbear.com/learn/automated-testing/what-is-regression-testing/