軟件測試V模型

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