軟體測試之冒煙測試中易犯的三個誤區

何為冒煙測試?

這一術語源自硬體行業。對一個硬體或硬體元件進行更改或修復後，直接給裝置加電。如果沒有冒煙，則該元件就透過了測試。冒煙測試，名字聽起來很奇怪，但是冒煙和測試完全就沒有什麼關係。冒煙測試引入到了軟體測試中，用來驗證主路徑是否暢通。在軟體中，“冒煙測試”這一術語描述的是在將程式碼更改嵌入到產品的源樹中之前對這些更改進行驗證的過程。在檢查了程式碼後，冒煙測試是確定和修復軟體缺陷的最經濟有效的方法。冒煙測試設計用於確認程式碼中的更改會按預期執行，且不會破壞整個版本的穩定性。

簡單點就是，發現BUG後開發人員fix bug後。測試人員針對該問題進行測試，冒煙測試的成功與否關係到下一步系統測試能否進行。與系統測試不同在於前者覆蓋範圍不夠，只要保證修改部分及其關聯的模組不出問題就可。

執行冒煙測試的前提。前面提到冒煙測試是與開發的合同協作，初步瞭解程式碼中進行了什麼更改。開發需告知此修改對其他功能是否影響;更改對各元件的依存關係有何影響。

軟體冒煙測試往往在敏捷開發團隊中有著非常大的幫助，在目前這種快速開發迭代的節奏下，如果依舊採用常規的提測、測試、迴歸流程，顯得過於死板和遲鈍，產品中存在的問題不能以第一時間反饋給各角色，而冒煙測試則是集合了整個團隊的力量共同助力產品的質量。這裡所說的冒煙測試是穿插在整個專案流程的各個階段，從而在專案週期中把控產品質量。

但是冒煙測試卻在工作中，容易陷入誤區。

誤區一：軟體開發員不知道冒煙測試

通常一提到冒煙測試，大家都習慣性的把關注點放在後面兩個字:測試 ,開發的同學一聽這個活動，很開心，這不是我們的活兒，應該是測試人員來完成的。真的是這樣麼?

其實在軟體研發中，冒煙測試其實是微軟首先提出來的一個概念，和微軟一直提倡的每日build(構建版本)有很密切的聯絡。具體說，冒煙測試就是在每日build(構建版本)建立後，對系統的基本功能進行簡單的測試。這種測試強調程式的主要功能進行的驗證，而不會對具體功能進行更深入的測試。

冒煙只是這類測試活動更形象化一些的叫法，直接叫做BVT(Build Verification Testing)更為貼切。

誤區二：冒煙測試為一個測試階段

有些團隊在定製流程時會有一個階段叫冒煙測試，但是就算不透過也會繼續做後面其它部分的測試。

反過頭來看當時微軟提出來的這個概念，它的重點其實在於 daily build ，也就是說冒煙測試是隨著每一次構建而走的，它應該是一個開關而不是一個研發流程中的測試階段。

如果透過過，你可以繼續後面的測試。如果不透過，直接返工等待下一次的構建。這才是冒煙測試應有的態度。

誤區三：冒煙測試需要把此次需求的主流程都走一遍

冒煙測試主要是測試系統的主流程是否可用，如果這次的需求不涉及到太多主流程上面的更改，那真的有必要把這些案例都加入到冒煙測試中麼?

最後，冒煙測試的最佳實踐還是最好被自動化，在CI中每一個Build都自動的去執行主流程的測試，確保其是一個基本可用的版本。