冒煙測試和回歸測試
前言：冒煙測試和回歸測試，都只是測試的一種過程郎笆，這兩種測試貫穿了整個 app 的生命周期。
冒煙測試
冒煙測試般哼，究竟是什么
冒煙測試窃判，是微軟首先提出來的一個概念（Smoke Testing）,一直以來都被認(rèn)為和 BVT(Build Verification Test --版本驗證測試)扯不清钞楼。但它們其實共同點都是強(qiáng)調(diào)要對程序的主要功能進(jìn)行驗證，只有通過了主要功能的測試袄琳，才能后續(xù)更細(xì)化的測試流程询件。
冒煙測試的優(yōu)勢
冒煙測試，雖說是測試方法的一種唆樊，但如果緊緊認(rèn)為它是一種測試宛琅，那就太過淺顯了。冒煙測試可以彌補(bǔ)很多常規(guī)測試中的不足逗旁，冒煙不僅可以測出 bug嘿辟，更早的發(fā)現(xiàn)產(chǎn)品缺陷，還可以發(fā)現(xiàn)產(chǎn)品層的問題片效，也會進(jìn)一步提升提測質(zhì)量红伦。
在常規(guī)的測試中，提測質(zhì)量往往是一個痛點淀衣，雖然開發(fā)有自測昙读，可是總還是有一些淺顯的問題存在，更有甚者還會阻塞測試工作膨桥，提測前進(jìn)行冒煙可以完美的解決這一問題箕戳，冒煙測試屬于自由體驗某残，可以保證在主路徑上不會有嚴(yán)重的缺陷存在，提高提測質(zhì)量陵吸，解決測試阻塞的問題玻墅。
冒煙的時候經(jīng)常會有一個有趣的現(xiàn)象，大家會熱烈的討論某個功能該如何做壮虫，每個人說出自己的見解澳厢，更正不合理的產(chǎn)品需求，最后把解決方案記錄在bug列表中轉(zhuǎn)為產(chǎn)品需求囚似。在不斷的冒煙測試中剩拢，代碼上的缺陷不斷被修復(fù)，同時產(chǎn)品功能也在不斷完善饶唤。
冒煙流程
冒煙流程是既簡單又很復(fù)雜徐伐，短短半小時看似短暫，卻像是濃縮了一整個項目流程進(jìn)來：首先得把主角“打包”出來募狂，然后組織大家去冒煙办素，收集冒煙中的問題，最后錄入系統(tǒng)給相應(yīng)負(fù)責(zé)人解決祸穷。
冒煙包在build包的過程中經(jīng)常會有各種問題性穿，因此需要在時間上預(yù)留一些buffer（緩沖時間），通常情況下需要提前半小時build（構(gòu)建）包雷滚，在build包前需要確認(rèn)各開發(fā)今天寫的代碼都已經(jīng)更新至svn或者 git需曾。
每個版本由一個開發(fā)和一個測試負(fù)責(zé)，開發(fā)負(fù)責(zé)打包并收集各開發(fā)的feature（新功能祈远，特色等）和體驗路徑呆万，測試負(fù)責(zé)將上一次冒煙修復(fù)的bug打印出來給大家回歸。
各角色在冒煙的時候不僅要體驗新產(chǎn)品车份，也需要履行各自的職責(zé)：開發(fā)需要引導(dǎo)大家體驗自己的feature桑嘶，并講解需求，產(chǎn)品經(jīng)理和設(shè)計師需要關(guān)注需求是否正確實現(xiàn)躬充，測試則是要讓大家回歸已解決的bug（誰提的bug誰回歸）逃顶，拒絕的bug需要開發(fā)給出拒絕的原因，如果不合理充甚，提bug人可以將bug重新打開以政。
冒煙結(jié)束后，測試負(fù)責(zé)人需要根據(jù)bug list中的內(nèi)容伴找，將bug分模塊盈蛮，類型（bug，建議）技矮，具體格式為：
標(biāo)題格式說明：【版本+模塊名+FT+冒煙測試】【BUG/建議】xxxx–提bug人 抖誉，最后全部提給該版本的冒煙開發(fā)負(fù)責(zé)人殊轴，由他統(tǒng)一分配bug。
冒煙測試中提出了這么多問題袒炉，怎么分類旁理，如何處理，每一天的冒煙既是一個新的開始也是一個對上一次冒煙的閉環(huán)我磁，bug分類的不同孽文，發(fā)現(xiàn)階段的不同，其解決的方式也有所不同夺艰。
bug 的梳理和查殺
一般冒煙測試有三大類 bug：常規(guī)問題芋哭，crash 以及體驗類問題。
- 常規(guī)類型的 bug 為冒煙測試常規(guī)缺陷郁副，常規(guī)問題常規(guī)解決减牺，這類缺陷在冒煙時由發(fā)現(xiàn)問題的人回歸，并對解決的結(jié)果作出判斷存谎，評估該不該拔疚、是否已被解決，或者拒絕的理由是否合理愕贡，如果有異議或者沒修復(fù)可以要求重新打開該 bug。
- crash 屬于非常嚴(yán)重的一類 bug巷屿，如果解決方案不夠妥當(dāng)固以，可能會引入其他問題，如果僅僅是在冒煙期間沒有復(fù)現(xiàn)crash 就認(rèn)為已修復(fù)嘱巾，這樣會太過草率憨琳。因此，每次冒煙的時候旬昭，開發(fā)要講解該 crash 是如何修復(fù)的篙螟，以及為什么會發(fā)生該 crash ，大家一起評估過這個修復(fù)方法后才算結(jié)束问拘。
- 體驗類 bug 比較特殊遍略，如果覺得有產(chǎn)品缺陷的地方就可以提出此類 bug，產(chǎn)品會權(quán)衡要不要把這個bug 建議納入到產(chǎn)品中來骤坐，推進(jìn)產(chǎn)品完善绪杏。
由于冒煙是穿插在整個項目周期中的，在項目即將發(fā)布前可能依舊存在問題纽绍，此時修復(fù)這些問題蕾久，如果代碼改動太大，可能會引發(fā)其他的bug拌夏，所以如果是在項目后期冒煙中發(fā)現(xiàn)很難解的bug需要評估改動范圍僧著，不然為了一個小問題而引入更多的bug就得不償失了履因。
冒煙測試技巧
- 用數(shù)據(jù)說明冒煙優(yōu)勢
冒煙過程中會出現(xiàn)各種 bug，這些 bug 的提前暴露可以在項目初期就開始修復(fù)盹愚，提升代碼質(zhì)量栅迄，成功非常可觀杯拐，可以通過一兩個版本的數(shù)據(jù)讓大家認(rèn)識到冒煙對開發(fā)和產(chǎn)品質(zhì)量的重要程度霞篡。
- 項目 PM 的支持
任何工作的順利進(jìn)行都需要有上級的支持，項目 PM 對冒煙測試的支持可以減少冒煙測試中的阻力端逼。
- 冒煙時間&地點
冒煙應(yīng)該選擇人比較疲勞的時候朗兵，這個時候工作效率不高，可以可用這個間隙半休息的狀態(tài)進(jìn)行冒煙顶滩，例如茶水間余掖，例如休息室，能討論礁鲁，能有零食慰藉盐欺，，提升大家冒煙的積極性仅醇。
總結(jié)
在版本快速迭代的節(jié)奏下冗美，冒煙不僅僅是常規(guī)測試的一個有效補(bǔ)充，也是大家參與項目了解項目的橋梁析二》弁荩總結(jié)冒煙主要達(dá)成以下幾項：
- 冒煙測試的目的: 確認(rèn)提測模塊的基本功能、實現(xiàn)邏輯符合需求叶摄，可以進(jìn)行后續(xù)的正式測試工作属韧，將正式測試未知的風(fēng)險降至最低，防止bug阻塞導(dǎo)致測試進(jìn)度阻塞 蛤吓。
-
冒煙測試時機(jī):
- 1.新增功能提測時
- 2.Bug修改或需求變更對原有功能模塊邏輯和業(yè)務(wù)修改范圍過大的時候
-
冒煙測試時間安排:
- 冒煙測試的時間可根據(jù)模塊的復(fù)雜程度來定宵喂，復(fù)雜度越高的模塊，預(yù)測試的時間可以安排的長些
- 冒煙測試時間一般不超過該模塊一輪測試時間的10%
-
冒煙測試標(biāo)準(zhǔn): 有以下任何一條執(zhí)行結(jié)果会傲，預(yù)測試不通過
- 提測模塊中锅棕，不可測試的功能點占總功能點的40%以上
- 崩潰或 Bug 導(dǎo)致70%以上的功能無法測試（即測試用例被阻塞）
- 崩潰頻繁導(dǎo)致無法進(jìn)行測試。
- 抽時隨機(jī)測試淌山，半小時內(nèi)發(fā)現(xiàn) Bug 數(shù)量超過20以上
- 個別重大 Bug 影響60%以上的功能邏輯
冒煙測試主要是防止構(gòu)建版本不合格的情況下哲戚，浪費(fèi)大量時間進(jìn)行后續(xù)的細(xì)分測試。
回歸測試
回歸測試一般用于軟件后期迭代和維護(hù)過程中艾岂。主要是因為可能新 Bug的發(fā)現(xiàn)顺少，修復(fù)后對其它功能造成的影響，或者開發(fā)者對錯誤的理解不夠透徹，引發(fā)的其它 bug脆炎。新功能的追加梅猿，新代碼可能對原有代碼帶來的影響。因此每當(dāng)APP發(fā)生變化時秒裕，我們就必須重新測試現(xiàn)有的功能袱蚓，以便確定修改是否達(dá)到了預(yù)期的目的，檢查修改是否損害了原有的正常功能几蜻。同時喇潘，還需要補(bǔ)充新的測試用例來測試新的或被修改了的功能。為了驗證修改的正確性及其影響就需要進(jìn)行回歸測試梭稚。
回歸測試主要是杜絕新代碼的融入給原版本帶來的不可預(yù)測的影響或者引發(fā)其他bug 的產(chǎn)生颖低。
這兩種測試必須貫穿我們開發(fā)的整個過程，防止出現(xiàn)重大 bug 的出現(xiàn)弧烤。
參考：
