軟件測試V模型

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