1. 核心
冒煙測試就是完成一個新版本的開發後，對該版本最基本的功能進行測試，保證基本的功能和流程能走通。
如果不通過，則打回開發那邊重新開發；
如果通過測試，才會進行下一步的測試(功能測試，集成測試，系統測試等等)。
簡化：門檻測試，一個開關而不是一個階段。
目的：版本驗證測試BVT（Build Verification Testing）。
時間：開發轉測試，歷時半至一個小時，很短。
對象：需求覆蓋，主功能路徑。
優點：節省測試時間，防止build失敗。
缺點：覆蓋率還是比較低。
操作：對著需求文檔把新功能過一遍；把所有流程功能走一遍；用monkey跑個一兩個小時；如果有歷史用例的話，可以把用例分級，冒煙級、詳細級、回歸級等等
用例：冒煙測試基本上不需要什麼用例，如果有的話，就用詳細用例裡，覆蓋需求文檔級別的用例就可以瞭
冒煙測試，是版本驗證測試，主要確認新的版本是否存在致命性bug，冒煙測試最大的優點在於節約測試的時間成本，減少測試輪數。
回歸測試，是軟件維護階段對軟件修改後進行的測試，指修改瞭舊代碼後，重新進行測試以確認修改沒有引入新的錯誤或導致其他代碼產生錯誤。
2. 定義
維基百科上對冒煙測試的解釋:
smoke testing is preliminary testing to reveal simple failures severe enough to, for example, reject a prospective software release. Smoke tests are a subset of [test cases] that cover the most important functionality of a component or system, used to aid assessment if main functions of the software appear to work correctly.[1][2] When used to determine if a computer program should be subjected to further, more fine-grained testing, a smoke test may be called an intake test.[1] Alternately, it is a set of tests run on each new build of a product to verify that the build is testable before the build is released into the hands of the test team.[5] In the DevOps paradigm, use of a BVT step is one hallmark of the continuous integration maturity stage.
冒煙測試這個名稱的來歷，最初是從電路板測試得來的。因為當電路板做好以後，首先會加電測試，如果板子沒有冒煙再進行其它測試，否則就必須重新來過。
而在軟件研發中，冒煙測試其實是微軟首先提出來的一個概念，和微軟一直提倡的每日build（構建版本）有很密切的聯系。具體說，冒煙測試就是在每日build（構建版本）建立後，對系統的基本功能進行簡單的測試。這種測試強調程序的主要功能進行的驗證，而不會對具體功能進行更深入的測試。
冒煙隻是這類測試活動更形象化一些的叫法，直接叫做BVT（Build Verification Testing）其實個人覺得更為貼切。
3. WHY
為什麼進行冒煙測試？軟件測試從業者都知道，bug發現得越晚，修復bug的成本就越高。那成本高在哪裡呢？
影響的代碼多，開發的修復成本會增加
影響的功能范圍較大，測試回歸的范圍增加
容易引發更多的bug，拉長測試周期，還有質量風險
更多的bug，會增加bug的提交、溝通成本
所以，如何盡早發現bug，把bug置解決是降低成本和控制止風險的有效方式，也是QA的主要職責之一。因此使用冒煙測試的方式，對開發提測的代碼進行審查，找出那些非常淺顯的bug是很有必要的
4. 特點
(1) 這種測試強調程序的主要功能進行的驗證，而不會對具體功能進行更深入的測試。
(2) 冒煙測試是隨著版本轉測進行的，它應該是一個開關(判斷版本能否轉測試)而不是一個研發流程中的測試階段。
(3) 冒煙測試用例一般選取的是測試用例中level 0的用例，保證主功能可用。
(4) 冒煙測試就是在一個新版本出來的時候，將軟件的全部功能過一遍，看有沒有什麼大問題。如果功能可以正常運行，不會影響測試進行，那麼這個版本就可以真正開始測試瞭。如果功能有重大問題或影響測試進行，那麼這個版本就是不合格的，不用進行進一步的測試。
5. 實現
開展冒煙測試工作有助於盡早發現軟件代碼存在的問題，提高軟件代碼的質量和開發效率。
基於持續集成(Continuous Integration，CI)的冒煙測試采用自動化測試腳本進行測試工作，能夠提高測試效率，減少測試人員大量的重復測試驗證工作。
冒煙測試的最佳實踐還是最好被自動化，在CI中每一個Build都自動的去執行主流程的測試，確保其是一個基本可用的版本。
冒煙測試可以手動執行，也可以自動化執行。穩定的系統適合自動化冒煙測試，集成過程中的系統適合手工冒煙測試，因為冒煙測試內容在動態變化，變化中的自動化腳本維護工作量比較大。
6. 案例選擇原則
既然隻是個準入門檻那就不會選擇全部案例進行測試，根據經驗，選擇全部案例數的 40%-50% 測試通過率在 80% 左右即可視為冒煙測試通過，允許測試準入，那這部分案例如何選擇呢？
遵循以下原則
A選取重要功能案例。
重要功能案例至少應占冒煙案例的 30%，特別關註對軟件功能實現具有重要影響的功能模塊測試案例，例如：一個事件（業務）的增加、刪除、修改、查詢，一個統計、計算邏輯的的結果校驗等。
B選取主要流程
主、分流程，對於主流程案例原則上應選取，分支流程案例可視其與主流程關聯度和影響度從高到低選擇部分。如主流程未通過，即使總案例通過率達到通過標準，該軟件也應被拒絕準入，待開發人員修正後重新進入冒煙測試環節。例如：一個審批流程，即使增加、刪除、修改、查詢的功能均通過，但如果整個流程環節中出現阻塞，無法完成完整的審批，則應視為冒煙未通過。
C篩選數據案例
篩選與主流程、重要功能相關度高的數據測試案例，原則是確保數據的埋設滿足主流程、重要功能測試條件。例如：想校驗一個商品購買的正確性，就離不開商品種類、單位、庫存、價格、購買數量等數據相關案例。這僅是一個簡單的商品購買，如果是統計分析則更需要大量不同種類、不同時點的數據作為測試基礎。
7. 涉及角色
冒煙測試在測試環境搭建與執行過程中，涉及到的人員包括:測試架構師、管理自動化工廠的測試工程師、開發工程師、持續集成工程師、質量工程師。
8. 冒煙測試 V.S. 回歸測試
冒煙測試，是版本驗證測試，主要確認新的版本是否存在致命性bug，冒煙測試最大的優點在於節約測試的時間成本，減少測試輪數。
回歸測試，是軟件維護階段對軟件修改後進行的測試，指修改瞭舊代碼後，重新進行測試以確認修改沒有引入新的錯誤或導致其他代碼產生錯誤。
