BVT測試介紹：
BVT測試也稱為"冒煙測試". 版本驗證測試 （BVT） 通常由一組廣泛的測試組成，這些測試用于驗證特定版本的總體質量。BVT 通常根據設定的計劃自動運行，經常在夜間進行。也可以手動運行，例如自動運行失敗后。如果 BVT 中的所有測試均已通過，則認為該版本成功。就是拿到一個軟件，首先不急于完全測試，而是在很短的時候內把軟件的基本功能走一遍，看有沒有什么大的問題，如 果存在大的問題，就沒有必要再進一步測試了?？梢怨澕s時間，提高測試效率。冒煙測試，也有稱作煙霧測試（smoke Test）：一種用于驗證系統基本功能的實現并達到一定程度的穩定性的測試。這種測試經常用作進入下一個等級的測試的入口準則的一部分。關于冒煙測試，應該是微軟首 先提出來的一個概念，和微軟一直提倡的每日build有很密切的聯系。具體說冒煙測試就是在每日build建立后對系統的基本功能進行簡單的測試，這種測 試強調功能的覆蓋率，而不對功能的正確性進行驗證。從這一點看和所謂的“接受性（驗收）測試（Acceptance Test）”非常相似。不同之處就在于他們執行的頻率和被測的版本不同。至于冒煙測試這個名稱的來歷，大概是從電路板測試得來的。因為當電路板做好以后， 首先會加電測試，如果板子沒有冒煙在進行其它測 試，否則就必須重新來過。類似的如果冒煙測試沒有通過，那么這個build也會返回給開發隊伍進行修正，測試人員測試的版本必須首先通過冒煙測試的考驗。 冒煙測試應該是對整個系統流程從輸入到輸出的完整測試。測試不必是面面俱到的，但是應該能夠發現系統中較大的問題。冒煙測試應該是足夠充分的，通過了冒煙 測試的build就可以認為是經過充分測試、足夠穩定的。不進行冒煙測試的build是沒有太大價值的。冒煙測試就像一個哨兵，在阻止著產品質量惡化和集 成問題的產生，不進行冒煙測試，每日構造可能會變成浪費時間的練習。冒煙測試必須隨著系統的擴充而擴充。最初，冒煙測試可能是非常簡單的，比如驗證系統是 否會打印“Hello World”，隨著系統功能的擴充，冒煙測試需要越來越充分。最初的冒煙測試也許只需要幾秒鐘來執行，逐漸地，測試可能會花費30分鐘，1小時，甚至更 長。
BVT測試培訓內容：
單元測試，使用白盒測試，設計用例是針對詳細設計文檔產生的。
集成測試，設計用例是針對概要設計說明書產生的。
系統測試，設計用例是針對軟件需求規格說明書產生的。
驗收測試，測試用例正常情況下應該由客戶給出，由客戶進行驗證，以便下結論是否可交付。
BVT測試的特點：主要是針對主體功能及各入口點，時間短，測試用例也只有正面的，負責人一般式項目經理或者技術經理。
何時應該進行BVT測試：從上面的BVT測試介紹中可以看出來，bvt測試當然是測試的次數越多越好，但是針對現實情況，測試部要求在送測之 前，程序在vss上打了基線，然后項目經理或者技術經理從vss上拿下最新的版本，然后做bvt測試，如果測試通過，則才可以填寫送測單，并將bvt測試 情況寫在其中，如果bvt測試沒通過，則需要修改bug，然后重新打基線，從新做BVT測試。BVT通過的要求并不是說所有的bug全部都改掉，而是沒有 重大的 bug，允許有小bug的存在。
BVT測試，以及測試用例的編寫，都是需要時間成本的，故在最初制作項目計劃時，就應該識別該任務，并充分考慮其工作量。
BVT測試用例，應該隨著系統的不斷擴展而不斷擴展，它不應該是一成不變的。
BVT測試應該包含的內容：
1、業務流的測試，保證正常業務鏈路的通暢。
2、工作流的測試，主要是測試流程流轉是否正常，至于流程步驟的表單內容是否正確則不關注。
3、關鍵功能的測試，至少要保證系統運轉所需的啟動數據，以及一些開關控制正常。
4、重要基本功能的測試，比如對核心業務有影響的一些增刪改等。
BVT測試的過程：
1、各單元測試通過
2、打版本
3、拿最新版本
4、根據部署文檔部署，盡量與用戶環境一致
5、執行BVT測試用例
6、BVT測試結束后，如果成功，則填寫送測單，并在送測單種寫明bvt測試結果；如果不成功，則修改bug，重新進行BVT測試。