冒煙測試與迴歸測試的區別

        冒煙測試，是微軟首先提出來的一個概念，和微軟一直提倡的每日build（構建版本）有很密切的聯繫。具體說，冒煙測試就是在每日build（構建版本）創建後，對系統的基本功能進行簡單的測試。這種測試強調程序的主要功能進行的驗證，也叫版本驗證測試，提交測試。
        冒煙測試這個名稱的來歷，是從電路板測試得來的。由於當電路板作好之後，首先會加電測試，若是板子沒有冒煙在進行其它測試，不然就必須從新來過。相似的若是冒煙測試沒有經過，那麼這個build也會返回給開發隊伍進行修正，測試人員測試的版本必須首先經過冒煙測試的考驗。
        冒煙測試的說法聽說是：象生產汽車同樣，汽車生產出來之後，首先發動汽車，看汽車可否冒煙，若是能，證實汽車最起碼能夠開動了。說明完成了最基本的功能。
        冒煙測試通常用於每日構建(Nightly build)，構建服務器首先從CVS服務器上，下載最新的源代碼，而後編譯單元測試，運行單元測試經過後，編譯可執行文件，可執行文件若可運行，並能執行最基本的功能，則認爲經過了冒煙測試，這時，構建服務器會把程序打包成安裝文件，而後上傳到內部網站，次日一早，測試人員來了之後，會收到構建服務器發來的郵件提示昨晚是否構建成功。若構建成功，則測試人員進行相關的功能測試。全部這些功能的完成，通常是靠編寫腳本完成的，目前比較經常使用的腳本有TCL,PERL,PYTHON及功能弱弱的批處理。用這些能夠完成系統的每日構建。
        總的來講，冒煙測試就是先保證系統能跑的起來，不至於讓測試工做作到一半忽然出現錯誤致使業務中斷。目的就是先經過最基本的測試，若是最基本的測試都有問題，就直接打回開發部了，減小測試部門時間的浪費。 
        而回歸測試，是軟件維護階段對軟件修改後進行的測試。
        在軟件生命週期中的任何一個階段，只要軟件發生了改變，就可能給該軟件帶來問題。軟件的改變多是源於發現了錯誤並作了修改，也有多是由於在集成或維護階段加入了新的模塊。當軟件中所含錯誤被發現時，若是錯誤跟蹤與管理系統不夠完善，就可能會遺漏對這些錯誤的修改；而開發者對錯誤理解的不夠透徹，也可能致使所作的修改只修正了錯誤的外在表現，而沒有修復錯誤自己，從而形成修改失敗；修改還有可能產生反作用從而致使軟件未被修改的部分產生新的問題，使原本工做正常的功能產生錯誤。一樣，在有新代碼加入軟件的時候，除了新加入的代碼中有可能含有錯誤外，新代碼還有可能對原有的代碼帶來影響。所以，每當軟件發生變化時，咱們就必須從新測試現有的功能，以便肯定修改是否達到了預期的目的，檢查修改是否損害了原有的正常功能。同時，還須要補充新的測試用例來測試新的或被修改了的功能。爲了驗證修改的正確性及其影響就須要進行迴歸測試。