望文生義,構建驗證測試是指在一個構建完成之后,團隊自動運行的一套驗證系統的基本功能的測試。大多數情況下,這一套系統都是在自動構建成功后自動運行的,有些情況下也會手工運行,但是由于構建是自動生成的,我們也要努力讓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 |
…
|
… |
… |
… |