作者：sweetojiang團隊：騰訊移動品質中心TMQ
冒煙測試，名字聽起來很奇怪，冒煙和測試完全就沒有什麼關系，為什麼兩者會聯系到一起？冒煙測試本是說硬體測試時進行加電，如果電路闆沒有冒煙則說明電路設計沒有問題，後來冒煙測試引入到了軟體測試中，用來驗證主路徑是否暢通。
軟體冒煙測試往往在靈活開發團隊中有着非常大的幫助，在目前這種快速開發疊代的節奏下，如果依舊采用正常的提測、測試、回歸流程，顯得過于死闆和遲鈍，産品中存在的問題不能以第一時間回報給各角色，而冒煙測試則是集合了整個團隊的力量共同助力産品的品質。這裡所說的冒煙測試是穿插在整個項目流程的各個階段，進而在項目周期中把控産品品質。
那你可能會問了，如此大規模的冒煙測試，傾盡團隊各方的力量，它到底有哪些優勢值得我們投入這麼多精力？下面我們就來講講冒煙有什麼厲害之處。
冒煙測試，雖說是測試方法的一種，那你認為它僅僅是一種測試，那就太過淺顯了，冒煙測試可以彌補很多正常測試中不足，冒煙不僅可以測出bug，更早的發現産品缺陷，還可以發現産品層面的問題，另外，也會彌補測試中機型不足的問題，同時也可以進一步提升提測品質。
在産品研發的過程中，常常會有這麼一個問題，所有的人隻熟悉自己負責的子產品，而每天一次的冒煙讓每一個角色都可以融入到産品中，更多了解自己的産品，發現産品的優缺點，提出自己對于産品的想法。對于産品經理，可以第一時間接觸到産品，在産品的剛有雛形的時候來驗收産品，避免研發過程中需求了解錯誤，減少修複成本。
一般在測試工作中，機型有限，測試時不能兼顧到所有機型，然而某些缺陷隻在特定機型上才會暴露，如果等到産品上線發現适配問題再修複，修複成本會很大，冒煙測試中多了十幾個機型，更容易暴露機型問題。
除了機型問題，在正常的測試中，提測品質往往是一個痛點，雖然開發有自測，可是總還是有一些淺顯的問題存在，更有甚者還會阻塞測試工作，提測前進行冒煙可以完美的解決這一問題，冒煙測試屬于自由體驗，可以保證在主路徑上不會有嚴重的缺陷存在，提高提測品質，解決測試阻塞的問題。
冒煙的時候經常會有一個有趣的現象，大家會熱烈的讨論某個功能該如何做，每個人說出自己的見解，更正不合理的産品需求，最後把解決方案記錄在bug清單中轉為産品需求。
在不斷的冒煙測試中，代碼上的缺陷不斷被修複，同時産品功能也在不斷完善。原來冒煙測試這麼厲害，教練，我要學！既然要學總要有各流程吧，下面我們介紹一些冒煙測試中的“套路”。
冒煙流程是既簡單又很複雜，短短半小時看似短暫，卻像是濃縮了一整個項目流程進來：首先得把主角“打包”出來，然後組織大家去冒煙，收集冒煙中的問題，最後錄入系統給相應負責人解決。
冒煙包在build包的過程中經常會有各種問題，是以需要在時間上預留一些buff，通常情況下需要提前半小時build包，在build包前需要确認各開發今天寫的代碼都已經更新至svn。
每個版本由一個開發和一個測試負責，開發負責打包并收集各開發的feature和體驗路徑，測試負責将上一次冒煙修複的bug列印出來給大家回歸。
各角色在冒煙的時候不僅要體驗新産品，也需要履行各自的職責：開發需要引導大家體驗自己的feature，并講解需求，産品經理和設計師需要關注需求是否正确實作，測試則是要讓大家回歸已解決的bug（誰提的bug誰回歸），拒絕的bug需要開發給出拒絕的原因，如果不合理，提bug人可以将bug重新打開。
冒煙結束後，測試負責人需要根據bug list中的内容，将bug分子產品，類型（bug，建議），具體格式為：
标題格式說明：【版本+子產品名+FT+冒煙測試】【BUG/建議】xxxx--提bug人 ，最後全部提給該版本的冒煙開發負責人，由他統一配置設定bug。
冒煙測試中提出了這麼多問題，怎麼分類，如何處理，每一天的冒煙既是一個新的開始也是一個對上一次冒煙的閉環，bug分類的不同，發現階段的不同，其解決的方式也有所不同。
冒煙中，同一個bug在不同的手機上會有不同的表現，是以經常會有重複bug出現，或相似bug，表現不一緻就會提bug，這樣導緻bug的“含金量”不高，一個版本下來可能有效的冒煙bug隻有6、7成，但是在bug面前甯肯讓其重複也不能遺漏。
這是我們Feature Team某個版本的冒煙bug資料，單冒煙一項就提了153個bug，bug雖多，線上品質卻從未出過問題。
有效的bug有7成，拒絕bug以重複bug和建議類bug偏多，約占到總bug的89%。那剩下的3成拒絕bug應該如何看待，難道拒絕了就沒有存在的價值了嗎？
并非如此，重複bug一般說明問題該bug容易複現，是以需要重點照顧，雖然被定位為無效bug，但是重複bug可以幫助開發找到需要重點關注的地方。建議類bug一般是對産品需求的看法，千人千面，并不是所有的意見都符合産品邏輯，但是這些建議卻值得産品經理去思考。
有效的bug該如何解決，當然bug的種類很多，不同類型的bug解決的方式也有所差別，目前我們冒煙測試有三大類bug：正常問題，crash以及體驗類問題。
正常類型的bug為冒煙時的正常缺陷，正常問題正常解決，這類缺陷在冒煙時由發現問題的人回歸，并對解決的結果作出判斷，評估該bug是否已被解決，或者拒絕理由是否合理，如果有異議可以要求重新打開該bug。
Crash屬于非常嚴重的一類型bug，如果解決方案不夠妥當，可能會引入其他問題，如果僅僅是在冒煙期間沒有複現crash就認為已修複，這樣會太過草率，是以，每次冒煙的時候，開發會講解該crash是如何修複的，為什麼會發生該crash，大家一起評估過這個修複方法後才算結束。
體驗類bug比較特殊，如果覺得有産品缺陷的地方就可以提這一類bug，這類bug一般會轉到産品名下，産品會權衡要不要把這個建議納入到産品中來。
由于冒煙是穿插在整個項目周期中的，在項目即将釋出前可能依舊存在問題，此時修複這些問題，如果代碼改動太大，可能會引發其他的bug，是以如果是在項目後期冒煙中發現很難解的bug需要評估改動範圍，不然為了一個小問題而引入更多的bug就得不償失了。
上面說了這麼多，真正要施行下去是有一定難度的，每天讓大家從工作中抽出寶貴的半小時時間用于體驗産品，對于每天加班的開發來說是很難接受的，那有沒有什麼捷徑可以走，這麼厲害的東西不能出師未捷身先死啊，總得通過某些方式把它推行下去吧。
冒煙過程中會出現各種bug，這些bug的提前暴露可以在項目初期就開始修複，提升代碼品質，成果非常可觀，可以通過一兩個版本的資料情況讓大家認識到冒煙對産品品質的重要程度。
任何工作的順利進行都需要有上級的支援，項目PM對冒煙測試的支援可以減少冒煙測試中遭遇的各種阻力。
通常情況下，冒煙應當選擇在人比較疲勞的時候，這個時間段工作效率不高，可以利用這個時間進行冒煙，解決了時間使用率低的問題，同時也能緩解工作的疲勞。
至于地點，隻要不是在自己的工位上冒煙就可以，最好能找個茶水間，讓大家放松心情的同時進行冒煙。
如此以來，可以讓項目組成員意識到，冒煙不僅僅是工作的一部分，同時可以緩解工作的疲勞，提升大家冒煙的積極性。
冒煙的時候可以準備零食給大家，對于冒煙積極的同學可以提供物質獎勵。
當然，組織冒煙的技巧不僅限于此，此時就是你開辟腦洞的時刻了，隻要能讓冒煙測試順利的開展下去，再“卑劣”的想法都值得去嘗試。
在版本快速疊代的節奏下，冒煙測試不僅成為正常測試的一個有效補充，也為其他角色了解測試搭建了一個很好的橋梁，這個過程需要各個人員積極的參與和優化才能得到理想的效果。
擷取更多測試幹貨，請搜尋微信公衆号：騰訊移動品質中心TMQ！
原創聲明，本文系作者授權雲+社群發表，未經許可，不得轉載。如有侵權，請聯系 [email protected] 删除。