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

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

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

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

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

Yao-Zen Lin
Software Quality Assurance Engineer
Sunnet.Corp

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

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

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

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

請問什麼是[迴歸測試] ? 如何進行 ?

請問[迴歸測試]和系統的建構管理有相關性嗎 ?

請賜教，謝謝 !

先回答第一個問題，如何驗證<開發>團隊遞交給<測試>團隊的程式已經做完單元測試？方式之一是：<開發>團隊在做單元測試時，一樣要留下客觀的書面證據。方式之二是：要客觀衡量的數據。也就是要有公司政策訂定或歷史的數據。於完成單元測試交付<測試>團隊後，程式碼的缺陷密度(Defect density)(bug 數/KLOC)要低於多少，當測試團隊於測試中發現某個測試項目的缺陷密度高於此數字時，不論是否做過單元測試，都退回給<開發>團隊重新執行單元測試並除錯。個人認為這就是為什麼CMMI要將“度量與分析”流程領域放在Level 2而“驗證”、“確認”放在Level 3的原因。

第二個問題，在文字上看起來有些許的模糊，我把它重新定義為：測試團隊如何界定其自身的測試工作範圍？(如果不是原意請包涵)要回答這個問題，先要了解測試基本上分為三個層級，即單元測試、整合測試與系統測試。測試團隊理應為整個軟體測試工作負起全部的責任。但是，在執行上可將單元測試委託給<開發>團隊去設計、執行，甚或單元測試的規劃工作也可委由他們來做。除此之外，其它的測試工作都要由測試團隊來處理。當然，這只是眾多方式中的一種。您可以依據貴公司的組織政策、文化與專案的特性而做不同的考量與安排。

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

您好,

想請問如果公司成立一個測試團隊,專門負責SIT&UAT的測試(不含UT),可能會遇到的第一個問題是,如何驗證<開發>團隊遞交給<測試>團隊的程式是已做完UT的?

另外一個問題是,<測試>團隊在寫測試個案時,往往寫的測試個案會與UT個案有重覆,如果不做,又好像沒有測試完全,如果都做,<測試>團隊等於UT也幫忙做了,到底身為<測試>團隊的人最好如何界定測試的範圍?

謝謝!!

第一個問題：資訊系統進行測試及驗收時，需要實測多少「測試個案」才足夠 ?
這個問題本身並不是問得很貼切，比較正確的問法應該是這樣的：測試及驗收時測試工作要做到多完整？當然，很直覺的說法是要百分之一百的完成。那麼問題來了，這個百分之百的分母與分子各為何？這個問題的答案是依資訊系統種類、大小、複雜度與健全度等級以及甲方的要求不同而不同的。以測試的行話來說就是涵蓋率。

那麼什麼是「測試涵蓋率」? 測試涵蓋率是一個有關測試活動完整性的量測制(metrics)，它是回答“ 測試活動到底完成了多少？”這問題的一種簡易方式。一般以需求為基準或程式碼為基準兩種方式來計算。以需求為基準的測試涵蓋率就是以需求個數為分母，用已通過測試的需求為分子所計算出來的一個百分比。以程程碼為基礎的測試涵蓋率就是以通過測試的程式碼數量除全部的程式碼數量所算出來的一個百分比數字。

關於第三個問題，我把它拆成兩部份來說明。一、基本上資訊系統的測試活動有三層：單元測試、整合測試與系統測試(這是乙方做的)，各個測試有自己的測試個案，也可共用部份相同的測試個案。這三層測試活動完成後，才進行驗收測試(這是甲方做的)，驗收測試的測試個案通常為系統測試的(必要時也可包括另外二種)測試個案的子集，當然也可以是全部的系統測試個案，至於用那一種方式則由合約來約定。 二、當系統經過測試，逐一修正每個錯誤程式後，最後「測試個案」還需要全部重做一次嗎 ? 正規而言，已通過測試的測試個案，在程式經過修改後(不論是因為除錯或變更而修改)，都必須重新測試。這樣的測試就是廻歸測試。

歡迎您來參加我下週六(4/8)即將講授的「如何撰寫測試文件?」課程。

軟體品質協會資深管理師 周茂松 敬上

請問資訊系統進行測試及驗收時，需要實測多少「測試個案」才足夠 ?

何謂「測試涵蓋率」?

當系統經過測試，逐一修正每個錯誤程式並且完成單元測試後，最後「測試個案」還需要全部重做一次嗎 ?

請問何謂「迴歸測試」?

以上敬請賜教，3Q !

4/8“如何撰寫測試文件”課程的主要目標是希望讓參加的學員，充分了解在一個軟體開發專案中，有關“測試”的過程應該產生那些文件，這些文件應該包含那些內容。

為了顧及學員來自各方，在背景上可能有的差異，首先我會對軟體、生命週期計畫以及與測試有關的一些基本觀念做一簡單的說明。

接下來，才會進入主題測試文件的介紹。這部份是以IEEE-829為主軸，包括：測試計畫、測試設計規格、測試個案、測試程序、測試項目移轉報告、測試日誌、測試事件報告與測試綜合報告。

最後，以實務中遇到的一些問題與實例，作為這項課程的總結。

至於您是否適合報名的問題，您還是要問問自己，前面所說的這些內容您是否都已了解? 您是否能夠撰寫合乎標準的測試文件? 如果答案都是肯定的，我想您就不必浪費金錢與時間了。否則的話，我認為您應該可以從這個課程中，得到一些對您有用的東西。

軟體品質協會資深管理師 周茂松

我是去年94年度最後一期的"軟體測試"學員(已結業),
我可以報名上4/8的課嗎?講師是那位?