冒煙測(cè)試方案V10

1、冒煙測(cè)試方案 V1.0目錄1. 引言 31.1 測(cè)試目的 32. 測(cè)試范圍 32.1 測(cè)試內(nèi)容 33. 測(cè)試策略 33.1 測(cè)試方法 34. 測(cè)試實(shí)施 44.1 測(cè)試實(shí)現(xiàn)過程 44.2 測(cè)試要點(diǎn) 54.3 測(cè)試準(zhǔn)入準(zhǔn)出 54.4 冒煙測(cè)試自動(dòng)化 51.引言1.1 測(cè)試目的冒煙測(cè)試( Smoke Testing )可以說(shuō)是一種預(yù)測(cè)試，軟件代碼正式編譯并交付測(cè)試之前， 先盡量消除其“表面的”錯(cuò)誤，確保軟件基本功能符合需求規(guī)格說(shuō)明書要求， 減少后期測(cè)試開 發(fā)的負(fù)擔(dān)。2. 測(cè)試范圍2.1 測(cè)試內(nèi)容在實(shí)際的軟件測(cè)試工作中， Smoke Testing 在軟件研發(fā)的不同階段有所不同。大體可以 分為三類：1

2、. 形成集成測(cè)試版本以前 Smoke Testing 是隨著代碼的不斷開發(fā)必做的一項(xiàng)工作， 目的是驗(yàn)證各個(gè)單元能夠成功執(zhí)行，并保證測(cè)試版本能夠順利集成。2. 形成集成測(cè)試版本以后 在代碼 check in 到 daily build 之前執(zhí)行 Smoke Testi ng ，以保證新的或者更改過的代碼不破壞集成版本的完成性和穩(wěn)定性。3. 后期預(yù)測(cè)試 Bug 的修正后期 daily build 相對(duì)穩(wěn)定時(shí)，針對(duì)每個(gè) Bug 所做的 B ug Fix 都要先在“干凈的” build 中進(jìn)行 Smoke Testing ，測(cè)試通過的 Bug Fix 才能 check in 到新的 daily bui

3、ld 中。3. 測(cè)試策略3.1 測(cè)試方法1. 基于每日構(gòu)建的冒煙測(cè)試冒煙測(cè)試就是在每日 build 建立后，對(duì)系統(tǒng)的基本功能進(jìn)行簡(jiǎn)單的測(cè)試。這種測(cè)試強(qiáng)調(diào)功能 的覆蓋率，而不對(duì)功能的正確性進(jìn)行驗(yàn)證。冒煙測(cè)試一般用于每日構(gòu)建 (Nightly build)，構(gòu)建服務(wù)器首先從 VSS服務(wù)器上，下載最新的 源代碼，然后編譯單元測(cè)試，運(yùn)行單元測(cè)試通過后， 編譯可執(zhí)行文件，可執(zhí)行文件若可運(yùn)行， 并能執(zhí)行最基本的功能，則認(rèn)為通過了冒煙測(cè)試?；诿咳諛?gòu)建的冒煙測(cè)試的優(yōu)點(diǎn)主要有：a) 進(jìn)度可見并可以控制到 1-2 天的細(xì)粒度，很容易看到進(jìn)度的偏差；b) 及早的發(fā)現(xiàn)開發(fā) BUG 和缺陷并分析解決，對(duì)開發(fā)人員的一種

4、監(jiān)督和促進(jìn)，提高軟 件質(zhì)量c) 由于將大集成分解到每日構(gòu)建中的小集成， 避免了傳統(tǒng)產(chǎn)品集成或集成測(cè)試時(shí)候出 現(xiàn)的嚴(yán)重問題的可能。d) 在項(xiàng)目中宣灌質(zhì)量意識(shí)， 強(qiáng)調(diào)第一次就把事情做好， 而不是等測(cè)試來(lái)幫你發(fā)現(xiàn)問題 基于每日構(gòu)建的冒煙測(cè)試也存在一些風(fēng)險(xiǎn)和缺陷，具體主要有：a) 給開發(fā)人員太大壓力，開發(fā)每天都在較緊張環(huán)境中工作b) 需要額外的測(cè)試人力資源和每日構(gòu)建硬件環(huán)境的投入c) 開發(fā)人員不能專注，既要分心去修改 BUG ，又要開發(fā)新的功能點(diǎn)d) 對(duì)開發(fā)負(fù)責(zé)人要求更好，需要將功能細(xì)化到1-2 天的有明確輸出的功能點(diǎn)e) 發(fā)需要投入額外的精力來(lái)保證每日構(gòu)建順暢 基于每日構(gòu)建的冒煙測(cè)試適用場(chǎng)景a) 對(duì)

5、進(jìn)度偏差控制和要求很高的項(xiàng)目b) 開發(fā)檢查點(diǎn)和里程碑制定的很細(xì)致的項(xiàng)目c) 采用增量和迭代開發(fā)的項(xiàng)目 ,快速和敏捷開發(fā)的項(xiàng)目2. 基于送測(cè)版本的冒煙測(cè)試 此種方法來(lái)源于每日構(gòu)建和冒煙測(cè)試，只是把粒度放大了。不是做每日 build ，而是根據(jù)版 本計(jì)劃， 開發(fā)組定期發(fā)布送測(cè)版本， 測(cè)試組拿到新的版本先做冒煙測(cè)試， 測(cè)試通過則開始正 式測(cè)試，不通過就返給開發(fā)組。這種做法的優(yōu)點(diǎn)可以避免微軟的每日 build 和冒煙測(cè)試做法的一些缺陷， 同時(shí)也會(huì)因粒度粗 而有自身的缺點(diǎn)，在此就不做詳述。4. 測(cè)試實(shí)施4.1 測(cè)試實(shí)現(xiàn)過程1. 測(cè)試規(guī)劃階段： 冒煙測(cè)試用例的編寫，以及測(cè)試執(zhí)行，都是需要時(shí)間成本的，故在最

6、初 制作項(xiàng) 目計(jì)劃時(shí)，就應(yīng)該識(shí)別該任務(wù)，并充分考慮其工作量。根據(jù)項(xiàng)目實(shí)際，確定在 單元測(cè)試， 集成測(cè)試， 系統(tǒng)測(cè)試的哪個(gè)或哪幾個(gè)階段開展冒煙測(cè)試，明確準(zhǔn)入準(zhǔn)出標(biāo)準(zhǔn)。2. 冒煙測(cè)試用例設(shè)計(jì)： 分析系統(tǒng)主要功能和業(yè)務(wù)流程， 編寫覆蓋這些功能的正向測(cè)試用例， 推薦使用正交表， 運(yùn)用正交法制定一套測(cè)試用例。 如果沒有用例就無(wú)法跟蹤和掌握整個(gè) 冒煙測(cè)試的重點(diǎn)， 以及各個(gè)版本之間的冒煙對(duì)比。 冒煙測(cè)試用例應(yīng)該隨著系統(tǒng)的不斷擴(kuò) 展而不斷擴(kuò)展，它不應(yīng)該是一成不變的。3. 冒煙測(cè)試執(zhí)行： 每個(gè)版本發(fā)布時(shí)， 根據(jù)版本包含的功能特性， 評(píng)估需要執(zhí)行的冒煙測(cè)試 用例4. 冒煙測(cè)試結(jié)果輸出： 冒煙測(cè)試執(zhí)行情況， 通過的

7、測(cè)試用例數(shù)， 不通過的測(cè)試用例數(shù)，據(jù) 此判斷是否開始正式的測(cè)試。4.2 測(cè)試要點(diǎn)1. 業(yè)務(wù)流的測(cè)試，保證正常業(yè)務(wù)鏈路的通暢2. 工作流的測(cè)試， 主要是測(cè)試流程流轉(zhuǎn)是否正常， 至于流程步驟的內(nèi)容是否正確則不關(guān)注。3. 關(guān)鍵功能的測(cè)試，至少要保證系統(tǒng)運(yùn)轉(zhuǎn)，以及一些正常功能實(shí)現(xiàn)。4. 重要基本功能的測(cè)試，比如對(duì)核心業(yè)務(wù)有影響的一些增刪改等4.3 測(cè)試準(zhǔn)入準(zhǔn)出冒煙測(cè)試的入口準(zhǔn)則a) 軟件版本已經(jīng)發(fā)布b) 冒煙測(cè)試計(jì)劃和測(cè)試變更需求和用例通過評(píng)審c) 測(cè)試環(huán)境準(zhǔn)備完畢冒煙測(cè)試的出口準(zhǔn)則a) 發(fā)現(xiàn)的致命和嚴(yán)重類缺陷為 0b) 所有必選測(cè)試場(chǎng)景的通過率 =100%c) 隨即抽取的可選測(cè)試場(chǎng)景通過率 >80%4.4 冒煙測(cè)試自動(dòng)化冒煙測(cè)試可以手動(dòng)執(zhí)行， 可以考慮自動(dòng)化執(zhí)行。 穩(wěn)定的系統(tǒng)適合自動(dòng)化冒煙測(cè)試， 集成過程 中的系統(tǒng)適合手工冒煙測(cè)試， 因?yàn)槊盁煖y(cè)試內(nèi)容在動(dòng)態(tài)變化， 變化中的自動(dòng)化腳本維護(hù)工作 量比較大。自動(dòng)化冒煙測(cè)試腳本應(yīng)當(dāng)遵循的原則1. 覆蓋主要功能；2. 測(cè)試腳本要簡(jiǎn)單、易用和詳細(xì)說(shuō)明3. 測(cè)試腳本要獨(dú)立4. 每個(gè)測(cè)試腳本要盡可能的獨(dú)立5. 每個(gè)測(cè)試腳本覆蓋的測(cè)試點(diǎn)要盡可能的單一