在測試中發現錯誤後，要進行除錯的工作。當除錯工作完成後，我們不知道在被修改的程式中，是否引入了新的錯誤，而造成副作用，使程式/系統中原本沒有問題的部份，產生了問題。所以於除錯後，必須針對修改過的部份，把原本已通過的相關測試個案拿出來重新測試，檢查是否仍然能通過測試，以確保在除錯工作中沒有引入其它的錯誤，這就是『廻歸測試』。

要有效進行廻歸測試與除錯的工作，必須要有良好的建構管理為基礎。因為，在『廻歸測試』中若發現在除錯中產副作用時，往往須要比較修改前與修改後的程式/系統，以找出造成副作用的修改動作。此時，如果沒有良好的版本管制，就會把造成副作用的問題當成新Bug來除錯，這就會使問題複雜化。

以上簡單回答您的問題，希望對您有幫助。

軟體品質協會專案管理師 周茂松 敬上

最近在進行「迴歸測試」有一些心得跟大家分享。

如周sir講的一樣，迴歸測試在於進一步驗證問題解決後進入整合是否引發side effect。所以在QA完成後，我會想達到Quality 的Control。我透過單獨更新被修正的程式來驗證programmer的修正回報是否遺漏。也透過CVS的控管了解程式修正前後的差別繼而可以找出問題點,而不是當成新的bug回報。
所以在標準的迴歸測試動作下，我可以確實找到被programmer所遺漏的回報或是side effect。以最近一次的Patch來說,53個問題更新做完迴歸測試後，我另外找到了兩個不在異動清單內的修正與程式。如此我可以讓經我出品的軟體品質維持在一定的水準上。

Yao-Zen Lin
Software Quality Assurance Engineer
Sunnet.Corp

在IEEE Std 610.12-1990 IEEE Standard Glossary of Software Engineering Terminology (軟體工程術語標準彙編)中，對於「迴歸測試(regression testing)」是這麼定義的：
Selective retesting of a system or component to verify that modifications have not caused unintented effects and that the system or component still complies with its specified requirements.譯文如下：(儘可能使用國家標準的習慣譯法)

系統或組件的選擇性再測試，以查證所做的修改未引發非蓄意的效果，且系統或組件依然遵循其指定的需求。

由上面的定義，我們可以知道迴歸測試是「選擇性」地不是「全面性」地實施(當然，也可以「選擇全面性地實施」，但是要考慮到成本效益的問題)；測試的標的可以是某個系統或某個組件。其目的在知道是否在修改後產生非蓄意性的效果，系統或組件是否仍然滿足其指定的需求。

要怎麼實施？個人認為應該從了解迴歸測試的目的入手，我想，「修改部分是否引發非蓄意的效果」比較單純，只要使用一些測試個案，看沒改到的地方，其程式行為是不是依然正確，但是有關「是否仍然滿足其指定的需求」就需要特別注意了。因為所謂滿足需求就不只是程式的行為是正確的，沒有被動到的程式，其行為也一如以往。因為需求有功能性需求，非功能性需求。非功能性需求不是單純程式行為正確，結果也一如預期(正確性、可靠性)，還有可用性、可維護性、使用性、可操作性、可攜性、效率、反應時間......等等需求。迴歸測試實施的方式，與發展期間的測試並沒有太大的差異，從單元測試→軟體整合測試→軟體鑑定測試→系統整合測試→系統鑑定測試，只是需不需要鉅細糜遺地測？當然可以不需要，但是要有合理的測試邏輯。如果你只是小改或除錯，例如，將一個邏輯判斷符號，從"="改為">="，有可能就不需要勞師動眾，來個「高規格」的迴歸測試。但是，是不是真的不需要？那可能要看其他的需求了，或許其他的需求，例如在「正確性」、「效率」、「反應時間」等需求的考慮下，會需要「高規格」的全面性迴歸測試。那我們要如何來判斷呢？這個時候就需要建構管理的協助了。

經由建構管理所建立的追溯能力，我們就可以在修改的早期，預先知道每一項修改或除錯的結果，其可能的範圍，所涵蓋功能性與非功能性需求，這除了可以協助估算出所有的修改所需的工夫(efforts)之外，修改的成本、所需的資源、時間都可以事先概算出來，而由於知道修改範圍有多大，哪些功能性及非功能性需求被影響到，因此，負責測試規劃的人員，也就可以針對性的準備測試個案規格、測試程序規格、測試情境、測試腳本、測試環境等等，而不會事到臨頭恣意亂測，只要程式沒有出問題，就草率過關了。

另外與迴歸測試工作有關的建構管理工作，就是軟體全生命週期內的測試資料(測試個案規格、測試程序規格、測試腳本、測試情境、測試環境資料等)，都要納入建構管理機制的管制。每當需要實施迴歸測試的時候，我們就可以從建構管理機制中，將先前測試所使用的測試資料簽出修改及運用；用先前可用的測試資料測試時，沒有被改到的部分，理應都可以過關的，如果出現了問題(結果與預期不相符)，那很明顯，程式已經被(蓄意或非蓄意地)改變了。因此，建構管理對於迴歸測試的測試規劃、執行上，是可以降低相當多的工夫，提高測試效率的。

----------------
引文: