移山 - 軟件測試討論(3)

　　單元測試必須覆蓋所測單元的所有代碼路徑。

　　問：啊!這樣豈不是要寫很多啰里啰唆的測試方法?

　　答：對，因為程序中很多缺陷都是從這些啰里啰唆的錯誤處理中產生的。如果你的模塊中某個錯誤處理路徑很難到達，那你也許要想想是否可以把這個錯誤處理拿掉。

　　[大栓：這對于那些愛寫復雜代碼的人是一個很好的懲罰，不對，是一個很好的鍛煉。]

　　[阿超：對，把單元測試的責任和代碼作者綁定在一起后，代碼作者就能更真切地體會到復雜代碼的副作用，因為驗證復雜代碼的正確性要困難得多。要注意的一點是：100% 的代碼覆蓋率并不等同于100% 的正確性，請看下列例子]

　　e.g.didn’t check return value.

　　e.g. memory leak

　　1.4.2.8單元測試應該集成到自動測試的框架中

　　另一個重要的措施是要把單元測試自動化，這樣每個人都能很容易地運行，并且單元測試每天都可以運行。每個人都可以隨時在自己機器上運行。團隊一般是在每日構建中運行單元測試, 這樣每個單元測試的錯誤就能及時發現并得到修改。

　　1.4.2.9單元測試必須和產品代碼一起保存和維護

　　單元測試必須和代碼一起進行版本維護。如果不是這樣，過了一陣，代碼和單元測試就會出現不一致，而且所有代碼的作者要花時間來確認哪些是程序出現的錯誤，哪些是由于單元測試更新滯后造成的錯誤。。。這樣就失去了單元測試的意義，同時又給大家增加了負擔，折騰多次以后，大家就會覺得維護單元測試是一件很費時費力的事。

　　1.5BVT 構建驗證測試 (Build Verification Test)

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

　　問：一個系統有這么多功能點，什么是基本，什么是不基本的?

　　答：第一，必須能安裝;第二，必須能夠實現一組核心場景(例如：對于字處理軟件來說，必須能打開/編輯/保存一個文檔文件，但是一些高級功能.

　　如: 文本自動糾錯, 則不在其中; 又如，網站系統，用戶可以注冊/上載/下載信息，但是一些高級功能，如刪除用戶，列出用戶參與的所有討論，則不在其中。

　　在運行BVT之前，可以運行所有的單元測試, 這樣可以保證系統的單元測試和程序員的單元測試版本保持一致。不少情況下，開發人員修改了程序和單元測試，但是忘了把更新的單元測試也同時簽入源代碼庫中。

　　通過BVT的構建可以稱為：可測 (self-test), 意思是說團隊可以用這一版本進行各種測試 – 因為它的基本功能都是可用的。通不過BVT的構建稱為“不可測”(self-hosed)

　　如果構建測試不能通過，那么自動測試框架會自動對每一個失敗的測試產生一個bug (小強)。一般的做法這些小強都是有最高優先級，是開發人員要首先修改這些小強。大家知道維持每日構建，并產生一個可測的版本是軟件開發過程質量控制的基礎。對于導致問題的小強，我們該怎么辦?

　　1. 找到導致失敗的原因，如果原因很簡單，程序員可以馬上修改，然后直接提交。

　　2. 找到導致失敗的原因的修改集，把此修改集剔出此版本(程序員必須修改好后再重新提交到源代碼庫中)。

　　3. 程序員必須在下一個構建開始前把此小強修理好。

　　方法1/2都可以使今天的構建成為“可測”，但是有時各方面的修改互相依賴，不能在短時間內解決所有問題，只能采用第三個辦法。

　　問：有人提到一種“smoke test”，冒煙測試，是什么回事?

　　答：這事實上是一種基本驗證測試，據說是從硬件設計行業流傳過來的說法 – 當年設計電路板的時候，很多情況下，新的電路板一插上電源就冒起白煙，燒壞了，如果插上電源后沒有冒煙，那就是通過了“冒煙測試”，可以進一步測試電路板的功能了。我們正在討論的BVT也是一種冒煙測試。

　　1.6功能測試 (functional test)

　　測試團隊拿到一個“可測”等級的構建，他們就會按照測試計劃，測試各自負責的模塊和功能，這個過程可能會產生總共10來個bug，也可能產生100個以上的bug，那么如何保證我們有效地測試了軟件，同時我們在這一步怎樣衡量構建的質量?

　　在MSF敏捷模式中，我們建議還是采用場景來規劃測試工作

　　在“基本場景”的基礎上，我們把所有系統目前理論上支持的場景都列出來，然后按功能分類測試，如果測試成功，就在此場景中標明“成功”，否則，就標明“失敗”，并且把失敗的情況用一個(或幾個)“小強”/bug來表示。

　　當所有的測試人員完成對場景的測試，我們自然地就得出了一個表：

　　場景ID 場景名 測試結果 Bug/小強id

　　3024 用戶登錄 成功

　　3026 用戶按價格排序 失敗 5032

　　3027 用戶按名字搜索 失敗 5033

　　…

　　?… … …

　　這樣我們就能很快地報告“功能測試56% 通過”等等。如果所有場景都能通過，(有些情況下可以把此標準從100% 降低到90% 左右)則這個構建的質量是“可用”，意味著這一個版本可以給用戶使用。 這種情況下，客戶，合作伙伴可以得到這樣的版本 – 這也是所謂“技術預覽版”，或“社區預覽版”的由來。

　　但是，有一個重要的問題要大家注意“可用”，并不是指軟件都沒有bug，而是指在目前的用戶場景中，按照場景的要求進行的操作，都能得到預期的效果。

　　1. 目前還沒有定義的用戶場景中，程序質量如何，還未得而知。

　　a. 場景中沒有考慮到多種語言設置

　　2. 不按照場景的要求進行的操作，結果如何，還未得而知。

　　a. 如：在某一場景中，場景規定用戶可以在最后付款前取消操作，回到上一步，如果一個測試人員發現在反復 提交/取消同一訪問多次，然后網頁出現問題，這并不能說明用戶場景失敗，當然這個極端的bug也必須找出原因并在適當的時間改正。

原文轉自：http://www.kjueaiud.com