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