在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)之外，修改的成本、所需的資源、時間都可以事先概算出來，而由於知道修改範圍有多大，哪些功能性及非功能性需求被影響到，因此，負責測試規劃的人員，也就可以針對性的準備測試個案規格、測試程序規格、測試情境、測試腳本、測試環境等等，而不會事到臨頭恣意亂測，只要程式沒有出問題，就草率過關了。

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

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