一.冒煙測試是干嘛的
通常一提到冒煙測試，大家都習慣性的把關注點放在后面兩個字:測試 ,開發的同學一聽這個活動，很開心，這不是我們的活兒，應該是測試人員來完成的。真的是這樣么？
冒煙測試這個名稱的來歷，最初是從電路板測試得來的。因為當電路板做好以后，首先會加電測試，如果板子沒有冒煙再進行其它測試，否則就必須重新來過。
而在軟件研發中，冒煙測試其實是微軟首先提出來的一個概念，和微軟一直提倡的每日build（構建版本）有很密切的聯系。具體說，冒煙測試就是在每日build（構建版本）建立后，對系統的基本功能進行簡單的測試。這種測試強調程序的主要功能進行的驗證，而不會對具體功能進行更深入的測試。
冒煙只是這類測試活動更形象化一些的叫法，直接叫做BVT（Build Verification Testing）其實CC先生個人覺得更為貼切。
二.冒煙測試不是一個測試階段
有些團隊在定制流程時會有一個階段叫冒煙測試，但是就算不通過也會繼續做后面其它部分的測試。就像平時進機場的時候機場口都會有個小哥哥或者小姐姐拿一個不知名的物體對你掃一次，大多數情況下旅客們都是面無表情的走過他們身邊，掃就掃唄，又不少兩斤肉。
實際上什么打火機啊，充電寶啊會在之后的安檢過程才會被一一挑出來。
我們反過頭來看當時微軟提出來的這個概念，它的重點其實在於 daily build ，也就是說冒煙測試是隨着每一次構建而走的，它應該是一個開關而不是一個研發流程中的測試階段。
過，你可以繼續后面的測試。不過，直接返工等待下一次的構建。這才是冒煙測試應有的態度。
三.不需要從頭就開始測試
一些團隊通常為了督促開發人員提高研發質量而把冒煙通過率作為一個衡量指標。CC先生認為出發點是極好的，實現手段上經常會有一點點小偏差。
冒煙測試主要是測試系統的主流程是否可用，如果這次的需求不涉及到太多主流程上面的更改，那真的有必要把這些案例都加入到冒煙測試中么？
最后，冒煙測試的最佳實踐還是最好被自動化，在CI中每一個Build都自動的去執行主流程的測試，確保其是一個基本可用的版本。當這個單獨job確實沒問題后，再歸類到一個大版本中，去進行詳細的測試流程。