冒煙測試和回歸測試
前言：冒煙測試和回歸測試，都只是測試的一種過程，這兩種測試貫穿了整個(gè) app 的生命周期。
冒煙測試
冒煙測試，究竟是什么
冒煙測試，是微軟首先提出來的一個(gè)概念（Smoke Testing）,一直以來都被認(rèn)為和 BVT(Build Verification Test --版本驗(yàn)證測試)扯不清。但它們其實(shí)共同點(diǎn)都是強(qiáng)調(diào)要對程序的主要功能進(jìn)行驗(yà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ì)量往往是一個(gè)痛點(diǎn)，雖然開發(fā)有自測，可是總還是有一些淺顯的問題存在，更有甚者還會阻塞測試工作，提測前進(jìn)行冒煙可以完美的解決這一問題，冒煙測試屬于自由體驗(yàn)，可以保證在主路徑上不會有嚴(yán)重的缺陷存在，提高提測質(zhì)量，解決測試阻塞的問題。
冒煙的時(shí)候經(jīng)常會有一個(gè)有趣的現(xiàn)象，大家會熱烈的討論某個(gè)功能該如何做，每個(gè)人說出自己的見解，更正不合理的產(chǎn)品需求，最后把解決方案記錄在bug列表中轉(zhuǎn)為產(chǎn)品需求。在不斷的冒煙測試中，代碼上的缺陷不斷被修復(fù)，同時(shí)產(chǎn)品功能也在不斷完善。
冒煙流程
冒煙流程是既簡單又很復(fù)雜，短短半小時(shí)看似短暫，卻像是濃縮了一整個(gè)項(xiàng)目流程進(jìn)來：首先得把主角“打包”出來，然后組織大家去冒煙，收集冒煙中的問題，最后錄入系統(tǒng)給相應(yīng)負(fù)責(zé)人解決。
冒煙包在build包的過程中經(jīng)常會有各種問題，因此需要在時(shí)間上預(yù)留一些buffer（緩沖時(shí)間），通常情況下需要提前半小時(shí)build（構(gòu)建）包，在build包前需要確認(rèn)各開發(fā)今天寫的代碼都已經(jīng)更新至svn或者 git。
每個(gè)版本由一個(gè)開發(fā)和一個(gè)測試負(fù)責(zé)，開發(fā)負(fù)責(zé)打包并收集各開發(fā)的feature（新功能，特色等）和體驗(yàn)路徑，測試負(fù)責(zé)將上一次冒煙修復(fù)的bug打印出來給大家回歸。
各角色在冒煙的時(shí)候不僅要體驗(yàn)新產(chǎn)品，也需要履行各自的職責(zé)：開發(fā)需要引導(dǎo)大家體驗(yàn)自己的feature，并講解需求，產(chǎn)品經(jīng)理和設(shè)計(jì)師需要關(guān)注需求是否正確實(shí)現(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。
冒煙測試中提出了這么多問題，怎么分類，如何處理，每一天的冒煙既是一個(gè)新的開始也是一個(gè)對上一次冒煙的閉環(huán)，bug分類的不同，發(fā)現(xiàn)階段的不同，其解決的方式也有所不同。
bug 的梳理和查殺
一般冒煙測試有三大類 bug：常規(guī)問題，crash 以及體驗(yàn)類問題。
- 常規(guī)類型的 bug 為冒煙測試常規(guī)缺陷，常規(guī)問題常規(guī)解決，這類缺陷在冒煙時(shí)由發(fā)現(xiàn)問題的人回歸，并對解決的結(jié)果作出判斷，評估該不該、是否已被解決，或者拒絕的理由是否合理，如果有異議或者沒修復(fù)可以要求重新打開該 bug。
- crash 屬于非常嚴(yán)重的一類 bug，如果解決方案不夠妥當(dāng)，可能會引入其他問題，如果僅僅是在冒煙期間沒有復(fù)現(xiàn)crash 就認(rèn)為已修復(fù)，這樣會太過草率。因此，每次冒煙的時(shí)候，開發(fā)要講解該 crash 是如何修復(fù)的，以及為什么會發(fā)生該 crash ，大家一起評估過這個(gè)修復(fù)方法后才算結(jié)束。
- 體驗(yàn)類 bug 比較特殊，如果覺得有產(chǎn)品缺陷的地方就可以提出此類 bug，產(chǎn)品會權(quán)衡要不要把這個(gè)bug 建議納入到產(chǎn)品中來，推進(jìn)產(chǎn)品完善。
由于冒煙是穿插在整個(gè)項(xiàng)目周期中的，在項(xiàng)目即將發(fā)布前可能依舊存在問題，此時(shí)修復(fù)這些問題，如果代碼改動太大，可能會引發(fā)其他的bug，所以如果是在項(xiàng)目后期冒煙中發(fā)現(xiàn)很難解的bug需要評估改動范圍，不然為了一個(gè)小問題而引入更多的bug就得不償失了。
冒煙測試技巧
- 用數(shù)據(jù)說明冒煙優(yōu)勢
冒煙過程中會出現(xiàn)各種 bug，這些 bug 的提前暴露可以在項(xiàng)目初期就開始修復(fù)，提升代碼質(zhì)量，成功非?？捎^，可以通過一兩個(gè)版本的數(shù)據(jù)讓大家認(rèn)識到冒煙對開發(fā)和產(chǎn)品質(zhì)量的重要程度。
- 項(xiàng)目 PM 的支持
任何工作的順利進(jìn)行都需要有上級的支持，項(xiàng)目 PM 對冒煙測試的支持可以減少冒煙測試中的阻力。
- 冒煙時(shí)間&地點(diǎn)
冒煙應(yīng)該選擇人比較疲勞的時(shí)候，這個(gè)時(shí)候工作效率不高，可以可用這個(gè)間隙半休息的狀態(tài)進(jìn)行冒煙，例如茶水間，例如休息室，能討論，能有零食慰藉，，提升大家冒煙的積極性。
總結(jié)
在版本快速迭代的節(jié)奏下，冒煙不僅僅是常規(guī)測試的一個(gè)有效補(bǔ)充，也是大家參與項(xiàng)目了解項(xiàng)目的橋梁?？偨Y(jié)冒煙主要達(dá)成以下幾項(xiàng)：
- 冒煙測試的目的: 確認(rèn)提測模塊的基本功能、實(shí)現(xiàn)邏輯符合需求，可以進(jìn)行后續(xù)的正式測試工作，將正式測試未知的風(fēng)險(xiǎn)降至最低，防止bug阻塞導(dǎo)致測試進(jìn)度阻塞 。
-
冒煙測試時(shí)機(jī):
- 1.新增功能提測時(shí)
- 2.Bug修改或需求變更對原有功能模塊邏輯和業(yè)務(wù)修改范圍過大的時(shí)候
-
冒煙測試時(shí)間安排:
- 冒煙測試的時(shí)間可根據(jù)模塊的復(fù)雜程度來定，復(fù)雜度越高的模塊，預(yù)測試的時(shí)間可以安排的長些
- 冒煙測試時(shí)間一般不超過該模塊一輪測試時(shí)間的10%
-
冒煙測試標(biāo)準(zhǔn): 有以下任何一條執(zhí)行結(jié)果，預(yù)測試不通過
- 提測模塊中，不可測試的功能點(diǎn)占總功能點(diǎn)的40%以上
- 崩潰或 Bug 導(dǎo)致70%以上的功能無法測試（即測試用例被阻塞）
- 崩潰頻繁導(dǎo)致無法進(jìn)行測試。
- 抽時(shí)隨機(jī)測試，半小時(shí)內(nèi)發(fā)現(xiàn) Bug 數(shù)量超過20以上
- 個(gè)別重大 Bug 影響60%以上的功能邏輯
冒煙測試主要是防止構(gòu)建版本不合格的情況下，浪費(fèi)大量時(shí)間進(jìn)行后續(xù)的細(xì)分測試。
回歸測試
回歸測試一般用于軟件后期迭代和維護(hù)過程中。主要是因?yàn)榭赡苄?Bug的發(fā)現(xiàn)，修復(fù)后對其它功能造成的影響，或者開發(fā)者對錯(cuò)誤的理解不夠透徹，引發(fā)的其它 bug。新功能的追加，新代碼可能對原有代碼帶來的影響。因此每當(dāng)APP發(fā)生變化時(shí)，我們就必須重新測試現(xiàn)有的功能，以便確定修改是否達(dá)到了預(yù)期的目的，檢查修改是否損害了原有的正常功能。同時(shí)，還需要補(bǔ)充新的測試用例來測試新的或被修改了的功能。為了驗(yàn)證修改的正確性及其影響就需要進(jìn)行回歸測試。
回歸測試主要是杜絕新代碼的融入給原版本帶來的不可預(yù)測的影響或者引發(fā)其他bug 的產(chǎn)生。
這兩種測試必須貫穿我們開發(fā)的整個(gè)過程，防止出現(xiàn)重大 bug 的出現(xiàn)。
參考：
