所謂的V模型，其實是對瀑布模型的一種修改，也算一個Change吧，詳見下圖：

　　由于瀑布模型對于軟件的需求分析與設計階段考慮不足，導致可能會出現嚴重的設計問題，最后交付到客戶手里才會被發現，所以V模型就考慮到這點，針對開發的各個過程都會有相應的測試環節，比如用戶需求會對應驗收測試，需求分析和系統設計會對應確認測試和系統測試等等（詳見上表），這樣子起碼在交付前會把用戶需求方面的問題覆蓋到，不太會出現說這個產品不是客戶想要的這種問題。

　　但是缺點也是顯而易見的，跟瀑布模型一樣，測試過程還是放在了最后環節，雖然可以滿足客戶的需求，但是問題都只能到最后階段才能被發現，必然會導致上面瀑布模型發生相同情況，也就是成本和時間的增加，所以V模型充其量也只能是瀑布模型的2.0版本。（不過好歹已經有了Change，我相信在那個年代的背景呀，已經算挺不錯了，已經考慮到需要對需求分析這些進行測試了）

　　當然，時代總是在不斷地變化之中，你不懂得Change，那唯一的結局就是落后，落后就要挨打，有多少曾經風光的軟件公司在今天已經找不到蹤影，活下來的公司都是能不斷適應時代改變而改變的公司。

　　V模型雖然比瀑布模型稍微先進那么一點，但是總是沒法跟得上時代的進步，因為有現在看來顯而易見的缺點（當然，這里得說一下，即使在現在，瀑布模型和V模型還是有其用武之地，特別是那種對質量看得非常嚴格，基本上方案定了不會有改動的行業，所以它們沒有被淘汰，我這里講的Change其實更多是針對敏捷開發的公司的，這類公司其實以前就應該敏捷，只是那個時候沒敏捷的想法，但是它們的開發流程總是有敏捷的需求，所以這個流程總是在Change中，并且不斷地去適應和反過來推動它們的流程的繼續發展。）

　　上面講了這么多，大家已經知道了瀑布模型和V模型對于需要敏捷的公司有一個致命傷了，也就是他們的測試環節總是放在開發完成后，從而導致了所有的Bug都是只能在最后才能被發現，客觀上增加了產品是否能按時和正確地發布的風險。既然知道了問題所在，咱們的過程分析管理人員們也不是蓋的，紛紛想出了高招。

　　首先來介紹一下W模型（見下圖），W模型其實是有兩個V模型組成，其實也就是雙V了，看起來像W就叫做W模型了，W模型強調測試需要和開發同步進行，開發包括哪幾個步驟，測試就需要測哪幾個步驟，更重要一點是需要同步進行，也就是說你做完這一步我就需要測掉這一步，那開發的步驟也無非就包括了需求、設計和代碼了，所以這些步驟都進行測試。

　一看W模型，我就覺得這個模型已經很現代了，因為它終于把測試環節解放出來了，可以說是一個革命性的改變，把大家一直認為開發最后一步的測試環節，提到了跟開發同步的環節，并且把測試環節擴展到了需求和設計環節，這個理念已經跟現在的測試理念一樣了。

　　在W模型中，當客戶需求出來后，測試就會開始介入，看看需求里寫的是不是就是客戶當時所說；在設計完成后，看看設計文檔是不是真實地反映了客戶需求精神；在開發完成后，就開始單元測試，集成測試，確認測試，集成測試和驗收測試。這樣子的話，基本上也就解決了前面瀑布模型和V模型碰到的問題。（能提出這個模型的研究員，我覺得很厲害，贊一下！）

　　當然說了優點還是得說一下缺點，W模型雖然把測試與開發過程同步進行了，但是總是有前后關系，也就是一個過程完全完成后，才能進行下一個階段，比如說需求過程完全做完以后，再去由測試去研究是否符合客戶要求，然后才能開始設計階段；設計工作完全完成后，再檢查設計文檔是否真正體現客戶的需求，然后再開始編碼階段。。。。。。，這樣子的話，簡單的軟件還行，但是一旦一個軟件很復雜，需求可能會經常變更，這個模型就不知道怎么處理這種變更，因為它認為需求處理完了就完了，以后不會再有變更；設計驗證過了就Ok了，以后不會再有變化。如果某一天，已經在進行單元測試了，突然客戶一個需求改了，或者加了一個新功能，這個模型看著就蒙了，如果是經常有更改的話，這個模型就瘋了，呵呵。

　　其他還有幾種著名模型，比如H模型和X模型，都是對瀑布模型和V模型進行了不錯的更新，當然也還是有其局限性，上面W模型存在的問題還是沒法解決。

　　不過，時代還在繼續發展，還有More Change等著咱們呢，且繼續聽下回分解。

　　（未完待續）

本文出自seven的測試人生公眾號最新內容請見作者的GitHub頁：http://qaseven.github.io/

總結

以上是生活随笔為你收集整理的敏捷测试理论以及实践（2）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。