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