![]( "冒煙測試")
冒煙測試
冒煙測試(smoke test)在測試中發現問題，找到了一個
Bug，然後開發人員會來修復這個Bug。這時想知道這次修復是否真的解決了程序的Bug，或者是否會對其它模塊造成影響，就需要針對此問題進行專門測試，這個過程就被稱爲Smoke Test。在很多情況下，做Smoke Test是開發人員在試圖解決一個問題的時候，造成了其它功能模塊一系列的連鎖反應，原因可能是隻集中考慮了一開始的那個問題，而忽略其它的問題，這就可能引起了新的Bug。Smoke
Test優點是節省測試時間，防止build失敗。缺點是覆蓋率還是比較低。
冒煙測試是自由測試的一種。
冒煙測試（smoke testing）,據說是
微軟起的名字。在《微軟項目求生法則》一書第14章“構建過程”關於冒煙測試，就是開發人員在個人版本的
軟件上執行目前的冒煙測試項目，確定新的程序代碼不出故障。
冒煙測試的名稱可以理解爲該種測試耗時短，僅用一袋煙功夫足夠了。也有人認爲是形象地類比新電路板功基本功能檢查。任何新電路板焊好後，先通電檢查，如果存在設計缺陷，電路板可能會短路，板子冒煙了。
冒煙測試的對象是每一個新編譯的需要正式測試的軟件版本，目的是確認軟件基本功能正常，可以進行後續的正式測試工作。冒煙測試的執行者是版本編譯人員。
在一般軟件公司，軟件在編寫過程中，內部需要編譯多個版本(Builds)，但是隻有有限的幾個版本需要執行正式測試（根據項目開發計劃），這些需要執行的中間測試版本，在剛剛編譯出來後，軟件編譯人員需要進行基本性能確認測試，例如是否可以正確安裝/
卸載，主要功能是否實現，是否存在嚴重死機或數據嚴重丟失等Bug。如果通過了該測試，則可以根據正式測試文檔進行正式測試。否則，就需要重新編譯版本，再次執行版本可接收確認測試，直到成功。
新版本的基本功能確認檢查的測試，有的公司稱爲版本健康檢查(Build Sanity Check)。對於編譯的本地化軟件新版本，除了進行上面提到的各種測試檢查，還要檢查是否在新的本地化版本中正確包含了全部應該本地化的文件。可以通過採用文件和目錄結構比較工具，首先比較源語言版本和本地化版本的文件和目錄中的文件數目、文件名稱和文件日期等，這個過程稱爲版本
鏡像檢查(Build Image Check)。其次，分別安裝源語言版本和本地化版本，比較安裝後的文件和目錄結構中的文件數目、文件名稱和文件日期等，這個過程稱爲版本安裝檢查(Build
Installing Check)。
與開發人員協同工作
由於冒煙測試特別關注更改過的代碼，因此必須與編寫代碼的開發人員協同工作。必須瞭解以下內容：
1、代碼中進行了什麼更改。若要理解該更改，必須理解使用的技術；開發人員可以提供相關說明。
2、更改對功能有何影響。
3、更改對各組件的依存關係有何影響。
在進行冒煙測試前檢查代碼
在運行冒煙測試前，進行側重於代碼中的所有更改的代碼檢查。代碼檢查是驗證代碼質量並確保代碼無缺陷和錯誤的最有效、最經濟的方法。冒煙測試確保通過代碼檢查或風險評估標識的主要的關鍵區域或薄弱區域已通過驗證，因爲如果失敗，測試就無法繼續。
在乾淨的調試版本中安裝私有二進制文件
由於冒煙測試必須側重於僅對更新後的二進制文件中的功能更改進行驗證，所以必須通過使用被測試文件的調試二進制文件來使測試在乾淨的測試環境中運行。
注意：在冒煙測試中，使用不匹配的二進制
文件進行測試是一個常見錯誤。爲了避免此錯誤，當兩個或多個更新後的二進制文件之間存在依賴項時，請在測試版本中包括所有更新後的二進制文件。否則，測試的結果可能無效。
創建每日構建 (Daily Build)
每日構建要求團隊成員協同工作，並鼓勵開發人員彼此保持同步。如果新版本的迭代被延遲，則該延遲很容易導致具有多個依賴項的產品不同步。遵循每日構建和冒煙測試的過程，任何更改過的或新的二進制文件都可確保實現高質量。
注意：將高質量的每日構建作爲團隊最重要的任務。如果由於簽入代碼未進行冒煙測試而導致版本中斷，則需要開發人員和測試人員停止所有其他工作，直到問題被解決爲止。對導致中斷版本的人員的處罰不應該很重，但這個處罰一定要能強調這樣一個道理：正確日構建是
團隊最重要的任務。
不需要執行窮舉測試。冒煙測試的目的不是確保二進制文件100%沒有錯誤。這樣需要花費太多的時間。執行冒煙測試是爲了在高級別驗證版本。要確保二進制文件中的更改不會破壞常規版本的穩定性，也不會導致功能中出現嚴重錯誤。
Web測試和負載測試
生成Web測試和負載測試時，在運行任何時間長、工作量大的測試之前運行冒煙測試是一種很好的做法。在Web測試和負載測試中，冒煙測試時間短，工作量也小。使用冒煙測試是爲了在運行性能測試或
壓力測試之前，確保一切都已正確配置並可按預期運行。
