何爲冒煙測試?
這一術語源自硬件行業。對一個硬件或硬件組件進行更改或修復後，直接給設備加電。如果沒有冒煙，則該組件就通過了測試。冒煙測試，名字聽起來很奇怪，但是冒煙和測試完全就沒有什麼關係。冒煙測試引入到了軟件測試中，用來驗證主路徑是否暢通。在軟件中，“冒煙測試”這一術語描述的是在將代碼更改嵌入到產品的源樹中之前對這些更改進行驗證的過程。在檢查了代碼後，冒煙測試是確定和修復軟件缺陷的最經濟有效的方法。冒煙測試設計用於確認代碼中的更改會按預期運行，且不會破壞整個版本的穩定性。
簡單點就是，發現BUG後開發人員fix bug後。測試人員針對該問題進行測試，冒煙測試的成功與否關係到下一步系統測試能否進行。與系統測試不同在於前者覆蓋範圍不夠，只要保證修改部分及其關聯的模塊不出問題就可。
執行冒煙測試的前提。前面提到冒煙測試是與開發的合同協作，初步瞭解代碼中進行了什麼更改。開發需告知此修改對其他功能是否影響;更改對各組件的依存關係有何影響。
軟件冒煙測試往往在敏捷開發團隊中有着非常大的幫助，在目前這種快速開發迭代的節奏下，如果依舊採用常規的提測、測試、迴歸流程，顯得過於死板和遲鈍，產品中存在的問題不能以第一時間反饋給各角色，而冒煙測試則是集合了整個團隊的力量共同助力產品的質量。這裏所說的冒煙測試是穿插在整個項目流程的各個階段，從而在項目週期中把控產品質量。
但是冒煙測試卻在工作中，容易陷入誤區。
誤區一：軟件開發員不知道冒煙測試
通常一提到冒煙測試，大家都習慣性的把關注點放在後面兩個字:測試 ,開發的同學一聽這個活動，很開心，這不是我們的活兒，應該是測試人員來完成的。真的是這樣麼?
其實在軟件研發中，冒煙測試其實是微軟首先提出來的一個概念，和微軟一直提倡的每日build(構建版本)有很密切的聯繫。具體說，冒煙測試就是在每日build(構建版本)建立後，對系統的基本功能進行簡單的測試。這種測試強調程序的主要功能進行的驗證，而不會對具體功能進行更深入的測試。
冒煙只是這類測試活動更形象化一些的叫法，直接叫做BVT(Build Verification Testing)更爲貼切。
誤區二：冒煙測試爲一個測試階段
有些團隊在定製流程時會有一個階段叫冒煙測試，但是就算不通過也會繼續做後面其它部分的測試。
反過頭來看當時微軟提出來的這個概念，它的重點其實在於 daily build ，也就是說冒煙測試是隨着每一次構建而走的，它應該是一個開關而不是一個研發流程中的測試階段。
如果通過過，你可以繼續後面的測試。如果不通過，直接返工等待下一次的構建。這纔是冒煙測試應有的態度。
誤區三：冒煙測試需要把此次需求的主流程都走一遍
冒煙測試主要是測試系統的主流程是否可用，如果這次的需求不涉及到太多主流程上面的更改，那真的有必要把這些案例都加入到冒煙測試中麼?
最後，冒煙測試的最佳實踐還是最好被自動化，在CI中每一個Build都自動的去執行主流程的測試，確保其是一個基本可用的版本。