[關鍵字] 軟件測試 冒煙測試 驗收測試
關於冒煙測試，應該是微軟首先提出來的一個概念，和微軟一直提倡的每日build有很密切的聯繫。具體說，冒煙測試就是在每日build建立後，對系統的 基本功能進行簡單的測試。這種測試強調功能的覆蓋率，而不對功能的正確性進行驗證。從這一點看和所謂的“接受性（驗收）測試（Acceptance Test）”非常相似。不同之處就在於他們執行的頻率和被測的版本不同。
至於冒煙測試這個名稱的來歷，大概是從電路板測試得來的。因爲當電路板做好以後，首先會加電測試，如果板子沒有冒煙在進行其它測試，否則就必須重新來過。類似的如果冒煙測試沒有通過，那麼這個build也會返回給開發隊伍進行修正，測試人員測試的版本必須首先通過冒煙測試的考驗。
冒煙測試的說法據說是：
就象生產汽車一樣，汽車生產出來以後，首先發動汽車，看汽車能否冒煙，如果能，證明汽車最起碼可以開動了。說明完成了最基本的功能。
冒煙測試一般用於每日構建(Nightly build)，構建服務器首先從CVS服務器上，下載最新的源代碼，然後編譯單元測試，運行單元測試通過後，編譯可執行文件，可執行文件若可運行，並能執 行最基本的功能，則認爲通過了冒煙測試，這時，構建服務器會把程序打包成安裝文件，然後上傳到內部網站，第二天一早，測試人員來了以後，會收到構建服務器 發來的郵件提示昨晚是否構建成功。若構建成功，則測試人員進行相關的功能測試。所有這些功能的完成，一般是靠編寫腳本完成的，目前比較常用的腳本有 TCL，Perl，Python及功能弱弱的批處理。用這些可以完成系統的每日構建。
簡單的說，就是先保證系統能跑的起來，不至於讓測試工作做到一半突然出現錯誤導致業務中斷。目的就是先通過最基本的測試，如果最基本的測試都有問題，就直接打回開發部了，減少測試部門時間的浪費。
冒煙測試準則
在軟件中，“冒煙測試”這一術語描述的是在將代碼更改簽入到產品的源樹中之前對這些更改進行驗證的過程。在檢查了代碼後，冒煙測試是確定和修復軟件缺陷的最經濟有效的方法。冒煙測試設計用於確認代碼中的更改會按預期運行，且不會破壞整個版本的穩定性。
注意：“冒煙測試”這一術語源自硬件行業。該術語源於此做法：對一個硬件或硬件組件進行更改或修復後，直接給設備加電。如果沒有冒煙，則該組件就通過了測試。
下面的準則描述了冒煙測試的最佳做法。遵循準則的效果會有很大的不同，從增強團隊成員之間的交流，到形成特定的使用測試和調試工具的方式等。
與開發人員協同工作
· 代碼中進行了什麼更改。若要理解該更改，必須理解使用的技術；開發人員可以提供相關說明。
· 更改對功能有何影響。
· 更改對各組件的依存關係有何影響。
原文轉自：http://www.ltesting.net