BVT測試介紹：
BVT測試也稱為"冒煙測試".版本驗證測試 (BVT) 通常由一組廣泛的測試組成，這些測試用于驗證特定版本的總體質(zhì)量。BVT 通常根據(jù)設定的計劃自動運行，經(jīng)常在夜間進行。也可以手動運行，例如自動運行失敗后。如果 BVT 中的所有測試均已通過，則認為該版本成功。就是拿到一個軟件，首先不急于完全測試，而是在很短的時候內(nèi)把軟件的基本功能走一遍，看有沒有什么大的問題，如果存在大的問題，就沒有必要再進一步測試了?？梢怨?jié)約時間，提高測試效率。
冒煙測試，也有稱作煙霧測試（smoke Test):一種用于驗證系統(tǒng)基本功能的實現(xiàn)并達到一定程度的穩(wěn)定性的測試。這種測試經(jīng)常用作進入下一個等級的測試的入口準則的一部分。關(guān)于冒煙測試，應該是微軟首先提出來的一個概念，和微軟一直提倡的每日build有很密切的聯(lián)系。具體說冒煙測試就是在每日build建立后對系統(tǒng)的基本功能進行簡單的測試，這種測試強調(diào)功能的覆蓋率，而不對功能的正確性進行驗證。從這一點看和所謂的“接受性（驗收）測試（Acceptance Test）”非常相似。不同之處就在于他們執(zhí)行的頻率和被測的版本不同。 至于冒煙測試這個名稱的來歷，大概是從電路板測試得來的。因為當電路板做好以后，首先會加電測試，如果板子沒有冒煙在進行其它測試，否則就必須重新來過。類似的如果冒煙測試沒有通過，那么這個build也會返回給開發(fā)隊伍進行修正，測試人員測試的版本必須首先通過冒煙測試的考驗。冒煙測試應該是對整個系統(tǒng)流程從輸入到輸出的完整測試。測試不必是面面俱到的，但是應該能夠發(fā)現(xiàn)系統(tǒng)中較大的問題。冒煙測試應該是足夠充分的，通過了冒煙測試的build就可以認為是經(jīng)過充分測試、足夠穩(wěn)定的。
不進行冒煙測試的build是沒有太大價值的。冒煙測試就像一個哨兵，在阻止著產(chǎn)品質(zhì)量惡化和集成問題的產(chǎn)生，不進行冒煙測試，每日構(gòu)造可能會變成浪費時間的練習。冒煙測試必須隨著系統(tǒng)的擴充而擴充。最初，冒煙測試可能是非常簡單的，比如驗證系統(tǒng)是否會打印“Hello World”，隨著系統(tǒng)功能的擴充，冒煙測試需要越來越充分。最初的冒煙測試也許只需要幾秒鐘來執(zhí)行，逐漸地，測試可能會花費30分鐘，1小時，甚至更長。
BVT測試內(nèi)容：
單元測試，使用白盒測試，設計用例是針對詳細設計文檔產(chǎn)生的。
集成測試，設計用例是針對概要設計說明書產(chǎn)生的。
系統(tǒng)測試，設計用例是針對軟件需求規(guī)格說明書產(chǎn)生的。
驗收測試，測試用例正常情況下應該由客戶給出，由客戶進行驗證，以便下結(jié)論是否可交付。
BVT測試的特點：
主要是針對主體功能及各入口點，時間短，測試用例也只有正面的，負責人一般式項目經(jīng)理或者技術(shù)經(jīng)理。
何時應該進行BVT測試：從上面的BVT測試介紹中可以看出來，bvt測試當然是測試的次數(shù)越多越好，但是針對現(xiàn)實情況，測試部要求在送測之前，程序在vss上打了基線，然后項目經(jīng)理或者技術(shù)經(jīng)理從vss上拿下最新的版本，然后做bvt測試，如果測試通過，則才可以填寫送測單，并將bvt測試情況寫在其中，如果vbt測試沒通過，則需要修改bug，然后重新打基線，從新做bvt測試。bvt通過的要求并不是說所有的bug全部都改掉，而是沒有重大的bug，允許有小bug的存在。
bvt測試，以及測試用例的編寫，都是需要時間成本的，故在最初制作項目計劃時，就應該識別該任務，并充分考慮其工作量。
bvt測試用例，應該隨著系統(tǒng)的不斷擴展而不斷擴展，它不應該是一成不變的。
BVT測試應該包含的內(nèi)容：
1、業(yè)務流的測試，保證正常業(yè)務鏈路的通暢。
2、工作流的測試，主要是測試流程流轉(zhuǎn)是否正常，至于流程步驟的表單內(nèi)容是否正確則不關(guān)注。
3、關(guān)鍵功能的測試，至少要保證系統(tǒng)運轉(zhuǎn)所需的啟動數(shù)據(jù)，以及一些開關(guān)控制正常。
4、重要基本功能的測試，比如對核心業(yè)務有影響的一些增刪改等。
BVT測試的過程：
1、各單元測試通過
2、打版本
3、拿最新版本
4、根據(jù)部署文檔部署，盡量與用戶環(huán)境一致
5、執(zhí)行bvt測試用例
6、bvt測試結(jié)束后，如果成功，則填寫送測單，并在送測單種寫明bvt測試結(jié)果；如果不成功，則修改bug，重新進行bvt測試。
每日構(gòu)建 (Daily Build)
每日構(gòu)建要求團隊成員協(xié)同工作，并激勵開發(fā)人員彼此堅持同步。假如新版本的迭代被延遲，則該延遲很輕易導致具有多個依附項的產(chǎn)品不同步。遵守每日構(gòu)建和冒煙測試的進程，任何更改過的或新的二進制文件都可確保實現(xiàn)高質(zhì)量。將高質(zhì)量的每日構(gòu)建作為團隊最主要的義務。如果由于簽進代碼未進行冒煙測試而導致版本中止，則需要開發(fā)人員和測試人員結(jié)束所有其他工作，直到問題被解決為止。對導致中止版本的人員的處分不應當很重，但這個處分必定要能強調(diào)這樣一個道理：準確的每日構(gòu)建是團隊最主要的義務。
每日構(gòu)建和BVT測試的長處重要有:
1、進度可見并可以把持到1-2天的細粒度，很輕易看到進度的偏差
2、及早的發(fā)明開發(fā)BUG和缺點并剖析解決，對開發(fā)人員的一種監(jiān)視和增進，進步軟件質(zhì)量
3、由于將大集成分解到每日構(gòu)建中的小集成，避免了傳統(tǒng)產(chǎn)品集成或集成測試時候呈現(xiàn)的嚴重問題的可能。
4、在項目中宣灌質(zhì)量意識，強調(diào)第一次就把事情做好，而不是等測試來幫你發(fā)明問題
每日構(gòu)建和BVT存在一些風險和缺點，具體重要有:
1、給開發(fā)者太大壓力，開發(fā)天天都在較緊張環(huán)境中工作
2、需要額外的測試人力資源和每日構(gòu)建硬件環(huán)境的投入
3、開發(fā)職員不能專注，既要分心往修正BUG，又要開發(fā)新的功效點
4、對開發(fā)負責人要求更好，需要將功能細化到1-2天的有明白輸出的功能點
5、開發(fā)須要投進額外的精神來保證逐日構(gòu)建順暢
實用場景
1、對進度偏差把持和要求很高的項目
2、開發(fā)檢討點和里程碑制訂的很過細的項目
3、采取增量和迭代開發(fā)的項目,快速和迅速開發(fā)的項目
每日構(gòu)建提前需要進行的籌備工作
1、對開發(fā)進度打算的請求，需要細化出每1-2天的開發(fā)進度規(guī)劃，可以到一個很小的功效點。
2、對逐日構(gòu)建測試規(guī)劃的請求，須要依據(jù)開發(fā)進度打算來部署冒煙測試和體系測試進度方案。
3、需要提前籌備好每日構(gòu)建的環(huán)境(每日構(gòu)建必需是獨立的環(huán)境)
