本節書摘來自華章計算機《 測試反模式：有效規避常見的92種測試陷阱》一書中的第1章，第1.2節,作者：（美） donald g. firesmith 更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視。
圖1.1展示了一種常見的系統工程模組化方式：傳統的系統工程活動的v模型。v的左側是将使用者問題分解成小且可管理的部件的分析活動。類似地，v的右側顯示将部件合成（并測試）為能解決使用者問題的系統的活動。
https://yqfile.alicdn.com/47d5037eeffc61c08c3d8dae91563ee7fcf2a0f9.png" >
傳統的v模型雖然有用，但從測試人員的角度來看，它并不能真正代表系統工程。接下來的3個圖展示了3個更加詳細的v模型，它們更好地把握了系統工程的測試方面。
圖1.2展示了面向工作産品而不是活動的v模型。具體而言，這些是主要的可執行的工作産品，因為測試涉及了工作産品的執行。在這個例子中，v的左側展示了更加詳細的可執行子產品的分析，而v的右側展示了相應的實際系統的增量和疊代的合成。這款v模型顯示可執行的東西都是經過測試的，而不是生成它們的通用的系統工程活動。
https://yqfile.alicdn.com/d89e84b87f852855334c91fe37b1380d8f7ba062.png" >
圖1.3展示了雙v模型，它在單v模型上增加了相應的測試[feiler 2012]。關鍵點有：
每一個可執行的工作産品都需要測試。測試不需要（而且事實上不應該）限制在所實施的系統和它的部件中。測試任何可執行的需求、架構和設計同樣重要。這樣才可以在轉移到實際系統和其部件之前，發現和修複相關的缺陷。這通常包括對以下内容的測試：可執行需求、架構或者通過模組化語言（通常是基于狀态且充分正式的）建立的被測系統（sut）的設計模型，如spectrm-rl，結構分析和設計語言（aadl）以及程式設計語言（pdl）；sut的模拟；sut的可執行的原型。
測試應在相應的工作産品建立時建立和執行。帶有雙向箭頭的短箭頭是用來表明：可以先開發可執行的工作産品并用于驅動測試的建立；可以使用測試驅動開發（tdd），在這種情況下，測試在它們所測的工作産品之前開發。
該模型的頂行使用測試來确認系統是否滿足其利益相關者的需求（即建立了正确的系統）。相反，模型底部4行使用測試來驗證該系統是否正确地建立（即架構符合需求、設計符合架構、實施符合設計等）。
最後，在實踐中，底行的兩側通常被整合，進而使單元設計模型納入機關，并且程式設計語言用作程式設計語言（pdl）。同樣，單元設計模型測試被納入單元測試，使得同一單元測試可驗證單元設計和它的實作。
圖1.4記錄了三重v模型，其中增加了額外的驗證活動來驗證測試活動的正常進行。這是為了提供證據表明測試是充分完整的，不會産生大量的假陽性和假陰性的結果。
雖然v模型看起來是展現一個連續的瀑布開發周期，它們也可以用來展現一個漸近的（即增量、疊代和并發）開發周期，結合許多小的、可能重疊的v模型。然而，在大型、複雜系統的靈活開發中應用v模型時，存在一些潛在的複雜性，需要超過一個簡單的小v模型的集合，比如：
在架構上重要的需求和相關的架構需要盡可能快地敲定，因為所有後續的增量依賴于架構，一旦最初的增量是基于它的，再做修改是非常困難和昂貴的。
多個跨職能的靈活團隊将同時工作于不同的元件和子系統，是以他們的增量必須在團隊間進行協調，以産生可以內建和釋出的一緻的、可測試的元件和子系統。
最後，有趣的是，要注意這些v模型不隻是适用于正在開發的系統，同樣也适用于該系統的測試環境或測試床及其測試實驗室或裝置的開發。
