x模型的目標是彌補v模型的一些缺陷。x模型真的能解決測試過程各方面的問題，例如交接、經常性的整合？
在軟體測試
方面，v模型是最廣為人知的模型，儘管很多富有實際經驗的測試人員還是不太熟悉v模型，或者其它的模型。v模型已存在了很長時間，和瀑布開發模型有著一些共同的特性，由此也和瀑布模型一樣地受到了批評和質疑。
v模型中的過程從左到右，描述了基本的開發過程和測試行為。v模型的價值在於它非常明確地標明了測試過程中存在的不同級別，並且清楚地描述了這些測試階段和開發過程期間各階段的對應關係。
圖1--v模型示意圖
在v模型中，單元測試是基於**的測試，最初由開發人員執行，以驗證其可執行程式**的各個部分是否已達到了預期的功能要求；
整合測試驗證了2個或多個單元之間的整合是否正確，並有針對性地對詳細設計中所定義的各單元之間的介面進行檢查；
在所有單元測試和整合測試完成後，系統測試開始以客戶環境模擬系統的執行，以驗證系統是否達到了在概要設計中所定義的功能和效能；
最後，當技術部門完成了所有測試工作後，由業務專家或使用者進行驗收測試，以確保產品能真正符合使用者業務上的需要。
儘管很多人對v模型表示了否定，但很少有人真正詳細地討論這些問題。brian marick（《the craft of software testing (prentice hall, 1995)》一書的作者）曾如此表示。在star2000 (software testing analysis and review) 東部會議上，marick曾經和dorothy graham（本系列文章的另一位作者）進行過一場論爭，並在其個人**www.testing.com上對v模型提出過一些中肯的反對意見。
x模型
marick曾提出過一些觀點和意見，其中首先是marick不建議要建立乙個替代模型。這裡我很冒昧地引用了一些marick的想法，並重新經過組織，形成了「x模型」。其實並不是為了和v模型相對應而選擇這樣的名字，而是由於其它一些原因：x通常代表未知，而marick也認為他的觀點並不足以支撐乙個模型的完整描述，但其中已經有乙個模型所需要的一些主要內容，其中也包括了象探索性測試（exploratory testing）這樣的亮點。我還需要在使用文字方面也向marick道歉，因為認同marick觀點的無疑大多屬於x一代（x一代）。另外，我勾畫了一張x形狀的示意圖，我相信該圖能夠很好地以另一種表達形式來體現marick的觀點。
圖2--x模型示意圖
軟體測試
：不可忽略的階段
》文章中所提到的很多
測試技術
的概念。
marick對v模型的最主要批評是v模型無法引導專案的全部過程。他認為乙個模型必須能處理開發的所有方面，包括交接，頻繁重複的整合，以及需求文件的缺乏等等。
解決交接和頻繁整合的週期的問題
marick認為乙個模型不應該規定那些和當前所公認的實踐不一致的行為。我也很認同這一點。x模型的左邊描述的是針對單獨程式片段所進行的相互分離的編碼和測試，此後將進行頻繁的交接，通過整合最終合成為可執行的程式。(右上半部分），這些可執行程式還需要進行測試。已通過整合測試的成品可以進行封版並提交給使用者，也可以作為更大規模和範圍內整合的一部分。多根並行的曲線表示變更可以在各個部分發生。
由上圖中可見，x模型還定位了探索性測試（右下方）。這是不進行事先計畫的特殊型別的測試，諸如「我這麼測一下結果會怎麼樣？」，這一方式往往能幫助有經驗的測試人員在測試計畫之外發現更多的軟體錯誤。marick雖然沒有對此進行明確的說明，但一定很樂意看到該方法的界定。
然而，關注於這樣的低階別的行為可能會引起不同的議論。乙個模型和乙個單獨的專案計畫有所不同。模型不應該描述每個專案的具體細節，模型應該對專案進行指導和支援。當然，**的交接也可以簡單地認為是一種整合的形式。而v模型也並沒有限制各種建立週期的發生次數。
marick和graham都一致認同，應該在執行測試之前進行測試設計。marick建議：「在你掌握相關知識時進行設計，在你手頭有交付內容時進行測試。」x模型包含了測試設計的步驟，就象使用不同的
測試工具
所要包含的步驟一樣，而v模型沒有這麼做。但是，marick的例子提示，x模型在這層意義上看也並不是乙個真的模型，取而代之的是，應該允許在任何時候選擇使用測試設計步驟。
事先計畫
marick對v模型提出質疑，也因為v模型基於一套必須按照一定順序嚴格排列的開發步驟，而這很可能並沒有反映實際的實踐過程。
儘管很多專案缺乏足夠的需求，v模型還是從需求處理開始。v模型提示我們要對各開發階段中已經得到的內容進行測試，但它沒有規定我們要取得多少內容。如果沒有任何的需求資料，開發人員知道他們要做什麼嗎？我主張在x模型和其它模型中都需要足夠的需求並至少進行一次發布。雖然在沒有模型的情況下也必須正常工作，但乙個有效的模型，可以鼓勵很多好的實踐方法的採用。因此，v模型的乙個強項是它明確的需求角色的確認，而x模型沒有這麼做，這大概是x模型的乙個不足之處。
marick也質疑了單元測試和整合測試的區別，因為在某些場合人們可能會跳過單元測試而熱衷於直接進行整合測試。marick擔心人們盲目地跟隨「學院派的v模型」，按照模型所指導的步驟進行工作，而實際上某些做法並不切合實用。我已經盡自己的努力把marick的關於需要很多具有可伸縮性的行為的期望結合進了x模型，這樣，x模型並不要求在進行作為建立可執行程式（圖中右上方）的乙個組成部分的整合測試之前，對每乙個程式片段都進行單元測試（圖中左側的行為）。但x模型沒能提供是否要跳過單元測試的判斷準則。
在「階段」之外
乙個模型的主要目標應該是描述如何把某件事情做好。當乙個模型所規定的基本要求還不完整的時候，模型可以幫助我們認識到這些不足，這也是其價值所在。雖然我們承認，在沒有足夠多的需求的前提下，系統開發還可以繼續下去，x模型可能會提倡付出額外的努力來進行更多的實踐行為。同樣的，也可以因為喜歡整合測試而選擇跳過單元測試，但其價值可能有一些虛幻的成分在，因為一般來說，在單元測試中發現問題進行解決的代價較小，而在整合測試中發現問題所付出的代價要大得多。
乙個代表落後的實踐的模型，其存在僅僅是因為它是普通的、常見的，這樣的模型只能簡單地保證以後我們可以維持落後的實踐的重複，而不對改進作出變化。人們甚至還認為落後的實踐不但是難以避免的，而且還是必然的，並終於拒絕把改進作為一種美德。
例如，開發者有時並不真正去研究如何更好地定義使用者的業務需求，而是簡單地認為這樣的工作是不現實的，因為「使用者並不真正知道他們要什麼」，或者認為「需求始終是要變化的」。於是，這些開發人員可能進一步宣稱不了解需求的做法是合理可行的，因為他們可以使用一些更高階的做法，例如原型法。雖然這樣的技術對確認需求，達成理解上的一致是有用的，但實際上這不是一條直接通向編碼的捷徑。這種情況下，編碼是非常低效的、要耗費很多任務作量來發現真正的使用者業務需求。從專案總體計畫方面來看，採用迭代方法以及一些更直接的發現需求的方法會顯得更有價值。
同樣的，x模型及其探索性測試的提倡也是為了避免把大量時間花費在測試文件編寫上面，那樣的話，真正用於測試的時間就減少了。（不知道為什麼，有些測試專家似乎並不把撰寫測試計畫視為一種美德。我可能是最後乙個鼓勵寫文件和填寫一些**的人，我認為這其中自有價值。我曾經看到過很多存在大量冗餘的測試計畫文件的例子，這些計畫並不值得花那麼多時間來寫。但這並不說明寫測試計畫是一件不好的行為，應該說寫很糟糕的測試計畫才是一件不好的行為。在另一方面，把重要資訊寫下來，可以取得數倍的回報。這可以使我們更加全面了解，避免遺忘，實現更多的共享。
軟體測試 V模型，還是X模型？
x模型的目標是彌補v模型的一些缺陷。x模型真的能解決測試過程各方面的問題，例如交接 經常性的整合？在軟體測試方面，v模型是最廣為人知的模型，儘管很多富有實際經驗的測試人員還是不太熟悉v模型，或者其它的模型。v模型已存在了很長時間，和瀑布開發模型有著一些共同的特性，由此也和瀑布模型一樣地受到了批評和質...
軟體測試V模型
他通過開發和測試同時進行的方式來縮短開發周期，提高開發效率。可以說，v模型是軟體開發測試中最重要的一種模型。v模型大體可以劃分為下面幾個不同的階段步驟，既需求分析 概要設計 詳細設計 編碼 單元測試 整合測試 系統測試 驗收測試。需求分析 既你首先要明確客戶需要的是什麼，需要軟體作成什麼樣子，需要有...
解析軟體測試V模型
v模型的特點是 開發與測試緊密相連。在v模型中，從專案的需求分析 概要設計 詳細設計到具體的編碼編寫。開發的每乙個環節都和軟體的測試緊密 相扣，下面我們來看看v模型是如何實現這一特點的。一 專案最先開始的是需求分析階段，需求分析階段的目標是 1 獲得使用者的需求。2 明確系統功能的劃分。3 分析需求...