確認測試也叫有效性測試，有的也叫合格性測試。主要指針對軟件系統/軟件子系統的測試。一般來說，有種比較約定俗成的順序：UT--IT--VT--ST。
但實際上並非絕對如此，嚴格的說，確認測試在某種情況下就屬於集成測試，在某種情況下就屬於系統測試。
例如，當你的被測系統由軟件子系統、硬件子系統等一些子系統組成的時候，這個時候針對這個被測系統中的軟件子系統的測試就屬於集成測試中的“系統內集成（子系統間集成）”，由於確認測試本身就是測純軟件子系統的，所以在這個時候確認測試本身就屬於集成測試階段中的子系統集成測試了；
例如，而當你的被測系統本身就是一個純軟件系統時，這個時候針對這個系統的測試就變成了系統測試了，所以在這個時候確認測試又變成了系統測試階段的活動了。
至於冒煙測試，它和回歸測試的性質一樣——只是一個測試活動，並不是一個測試階段。也就是說，冒煙測試貫穿於測試的任何一個階段，單元測試里會有冒煙測試、集成測試里會有冒煙測試、系統測試里也會有冒煙測試。
冒煙測試和其他所有的測試活動的目的不一樣，它不是為了證明程序存在BUG，而是為了證明程序的基本功能、核心功能沒有問題。
當冒煙測試發生在集成測試的子系統間集成和系統測試的時候，這個時候，人們常常把冒煙測試等同為BVT（Build Verification Testing），也就是所謂的小版本驗證測試。
冒煙測試一般是由程序員來執行；冒煙測試帶有一定的隨機性，它不需要去設計正式的測試用例，這個活動在開發部門內開展；
系統預測試也叫“轉系統測試”（有的地方把“轉系統測試”看作為是針對“系統測試預測試報告”等輸入文檔的評審活動，其實大可不必去摳兩個詞匯的區分，這樣做意義不大），一般是由Tester來實施的，也可以在開發人員的配合之下開展，如果是這種情況下，系統預測試就是敏捷開發極限編程中的“結對編程、結對測試”了；
系統預測試是個別規范的大公司才有的流程，在微軟內部與之類似的有個“Buddy Test（合伙測試）”，指的是開發人員提交軟件版本后申請轉系統測試之前的功能性驗證（可能還包括其他方面的驗證），目的是確保系統的基本功能確實沒有問題，使得后續的系統測試能夠順利開展，不至於出現主要功能有致命問題，大量的用例被堵塞，導致系統測試無法繼續下去。
從順序上來說，是UT--IT--Pre ST--ST。也就是說PM（或開發人員）提出轉系統測試申請后，測試部門的Testers會進行系統預測試，完成后由測試主管組織測試部門人員進行這次轉系統測試評審。
至於CCB，全稱是Change Control Board——變更控制委員會，負責對軟件配置項進行變更管理。而變更管理包括了需求的變更以及由缺陷修復帶來的代碼變更。
V模型（其實應該是W模型），要明確一點，任何模型都不是完美的，雙V模型也有它的缺陷：雖然開發活動和測試活動是並行開展的，但是對於測試內部來說，單元測試、集成測試、系統測試都是串行展開的，而這種嚴格的階段之分只是一種理想狀況，並不適用現在大部分企業迭代式開發、增量式開發的軟件工程過程。實際上在開發過程中，UT、IT、ST可能會在某個時段內同時存在!
總的來說，你的測試過程圖只是簡介了企業整個研發測試流程圖，但是真正在企業中要量體裁衣，萬不可照搬照套。否則適得其反。