望文生義，構建驗證測試是指在一個構建完成之后，團隊自動運行的一套驗證系統的基本功能的測試。大多數情況下，這一套系統都是在自動構建成功后自動運行的，有些情況下也會手工運行，但是由于構建是自動生成的，我們也要努力讓BVT自動運行。
問：一個系統有這么多功能點，什么是基本，什么是不基本的？
答：第一，必須能安裝；第二，必須能夠實現一組核心場景（例如：對于字處理軟件來說，必須能打開/編輯/保存一個文檔文件，但是一些高級功能，如:文本自動糾錯,則不在其中；又如，網站系統，用戶可以注冊/上載/下載信息，但是一些高級功能，如刪除用戶，列出用戶參與的所有討論，則不在其中。
通過BVT的構建可以稱為：可測（self-test）,意思是說團隊可以用這一版本進行各種測試–因為它的基本功能都是可用的。通不過BVT的構建稱為“不可測”（self-hosed）
如果構建測試不能通過，那么自動測試框架會自動對每一個失敗的測試產生一個bug（小強）。一般的做法這些小強都是有最高優先級，是開發人員要首先修改這些小強。大家知道維持每日構建，并產生一個可測的版本是軟件開發過程質量控制的基礎。對于導致問題的小強，我們該怎么辦？
1．找到導致失敗的原因，如果原因很簡單，程序員可以馬上修改，然后直接提交。
2．找到導致失敗的原因的修改集，把此修改集剔出此版本（程序員必須修改好后再重新提交到源代碼庫中）。
3．程序員必須在下一個構建開始前把此小強修理好。
方法1/2都可以使今天的構建成為“可測”，但是有時各方面的修改互相依賴，不能在短時間內解決所有問題，只能采用第三個辦法。
問：有人提到一種“smoke test”，冒煙測試，是什么回事？
答：這事實上是一種基本驗證測試，據說是從硬件設計行業流傳過來的說法–當年設計電路板的時候，很多情況下，新的電路板一插上電源就冒起白煙，燒壞了，如果插上電源后沒有冒煙，那就是通過了“冒煙測試”，可以進一步測試電路板的功能了。我們正在討論的BVT也是一種冒煙測試。
1.6 功能測試（functional test）
測試團隊拿到一個“可測”等級的構建，他們就會按照測試計劃，測試各自負責的模塊和功能，這個過程可能會產生總共10來個bug，也可能產生100個以上的bug，那么如何保證我們有效地測試了軟件，同時我們在這一步怎樣衡量構建的質量？
在“基本場景”的基礎上，我們把所有系統目前理論上支持的場景都列出來，然后按功能分類測試，如果測試成功，就在此場景中標明“成功”，否則，就標明“失敗”，并且把失敗的情況用一個（或幾個）“小強”/bug來表示。
當所有的測試人員完成對場景的測試，我們自然地就得出了一個表：
|
場景ID |
場景名 |
測試結果 |
Bug/小強id |
|
3024 |
用戶登錄 |
成功 |
|
|
3026 |
用戶按價格排序 |
失敗 |
5032 |
|
3027 |
用戶按名字搜索 |
失敗 |
5033 |
|
…
|
… |
… |
… |
