噴泉模型
1.什么是噴泉模型
噴泉模型是一種以用戶需求為動力,以對象為驅(qū)動的模型,主要用于描述面向?qū)ο蟮能浖_發(fā)過程。該模型認(rèn)為軟件開發(fā)過程自下而上周期的各階段是相互重疊和多次反復(fù)的,就像水噴上去又可以落下來,類似一個噴泉。各個開發(fā)階段沒有特定的次序要求,并且可以交互進(jìn)行,可以在某個開發(fā)階段中隨時補充其他任何開發(fā)階段中的遺漏。采用噴泉模型的軟件過程如下圖所示:
噴泉模型主要用于面向?qū)ο蟮能浖?a href="/wiki/%E9%A1%B9%E7%9B%AE" title="項目">項目,軟件的某個部分通常被重復(fù)多次,相關(guān)對象在每次迭代中隨之加入漸進(jìn)的軟件成分。各活動之間無明顯邊界,例如設(shè)計和實現(xiàn)之間沒有明顯的邊界,這也稱為“噴泉模型的無間隙性”。由于對象概念的引入,表達(dá)分析、設(shè)計及實現(xiàn)等活動只用對象類和關(guān)系,從而可以較容易地實現(xiàn)活動的迭代和無間隙。
2.噴泉模型的概述
噴泉模型是由B.H.Sollers和J.M.Edwards于1990年提出的一種新的開發(fā)模型。噴泉模型主要用于采用面向?qū)ο蠹夹g(shù)的軟件開發(fā)項目,噴泉一詞本身就體現(xiàn)了迭代和無間隙的特征。無間隙指在各項活動之間無明顯邊界,如分析、設(shè)計和編碼之間沒有明顯的界限。在編碼之前再進(jìn)行需求分析和設(shè)計,期間添加有關(guān)功能,使系統(tǒng)得以演化。噴泉模型在系統(tǒng)某個部分常常被重復(fù)工作多次,相關(guān)對象在每次迭代中隨之加入漸進(jìn)的系統(tǒng)。由于對象概念的引入,需求分析、設(shè)計、實現(xiàn)等活動只用對象類和關(guān)系來表達(dá),從而可以較為容易地實現(xiàn)活動的迭代和無間隙,并且使得開發(fā)過程自然地包括復(fù)用。
3.噴泉模型的優(yōu)缺點
1、噴泉模型的優(yōu)點
噴泉模型不像瀑布模型那樣,需要分析活動結(jié)束后才開始設(shè)計活動,設(shè)計活動結(jié)束后才開始編碼活動。該模型的各個階段沒有明顯的界限,開發(fā)人員可以同步進(jìn)行開發(fā)。其優(yōu)點是可以提高軟件項目開發(fā)效率,節(jié)省開發(fā)時間,適應(yīng)于面向?qū)ο蟮能浖_發(fā)過程。
2、噴泉模型的缺點
由于噴泉模型在各個開發(fā)階段是重疊的,因此在開發(fā)過程中需要大量的開發(fā)人員,因此不利于項目的管理。此外這種模型要求嚴(yán)格管理文檔,使得審核的難度加大,尤其是面對可能隨時加入各種信息、需求與資料的情況。
4.改進(jìn)的噴泉模型
1.傳統(tǒng)的噴泉模型
傳統(tǒng)的噴泉模型如下圖所示,目前主要應(yīng)用于面向?qū)ο蟮能浖_發(fā)中 。該模型的主要特點是認(rèn)為軟件開發(fā)的各個階段是相互重疊和多次反復(fù)的,從圖中可以看出,軟件開發(fā)的規(guī)格說明階段、設(shè)計階段、編碼階段和測試階段可以交疊在一起,同時進(jìn)行。這體現(xiàn)了各個開發(fā)過程的并行關(guān)系。噴泉的水可以噴上去又可以落下來,水既可以落在中間,也可以落在底部。這一點在模型中表現(xiàn)為各個測試階段的并行。噴泉的水不停的噴發(fā)、墜落,代表著開發(fā)和測試階段的復(fù)雜性和重復(fù)性。
2.改進(jìn)的噴泉模型
在傳統(tǒng)噴泉模型的基礎(chǔ)上,提出了改進(jìn)的噴泉模型,如下圖所示。以噴泉模型為基礎(chǔ),可以實現(xiàn)盡早的、全面的展開測試,同時將測試工作進(jìn)行迭代。另外,改進(jìn)的噴泉將需求納入,使得模型完全實現(xiàn)了整個開發(fā)過程的無邊界、交互性。
該模型每一次測試過程包括四個階段。
第一階段為測試需求階段,包括提取和驗證需求。這一階段的測試主要是采用靜態(tài)測試。
第二階段為測試分析階段,又分為制定測試計劃、測試設(shè)計與開發(fā)兩個步驟。測試計劃包括確定測試策略和測試系統(tǒng),預(yù)估測試工作量等。測試設(shè)計與開發(fā)包括開發(fā)測試用例,驗證并調(diào)試測試等。
第三階段為測試執(zhí)行階段,強調(diào)測試人員和開發(fā)人員的配合。該階段的測試方法包括單元測試、集成測試、系統(tǒng)測試及驗收測試。除了對程序進(jìn)行測試外,還要對文檔等進(jìn)行測試。記錄測試結(jié)果并寫出測試總結(jié)報告,為下一輪的迭代測試打基礎(chǔ)。
第四階段為測試維護(hù)階段。開發(fā)者的維護(hù)包括修復(fù)顧客操作和為滿足不斷變化的顧客需求而對產(chǎn)品功能進(jìn)行增強時發(fā)現(xiàn)的缺陷;測試組的維護(hù)意味著對缺陷的修復(fù)進(jìn)行驗證,測試增強了的功能以及產(chǎn)品的新發(fā)布版本上運行回歸測試以確保修改前的產(chǎn)品具有的功能不因產(chǎn)品的新變化而被破壞。
從模型圖中可以看出,該模型除具有傳統(tǒng)噴泉模型的優(yōu)點外,還體現(xiàn)了以下特點:
(1)布式特點當(dāng)軟件結(jié)束計劃階段,分布在不同地域的軟件開發(fā)小組可以根據(jù)計劃,在不同或者相同的時間啟動項目開發(fā)。
(2)測試的充分軟件測試中測試用例的覆蓋率直接決定了軟件測試的質(zhì)量。改進(jìn)的噴泉模型大大擴大了設(shè)計和選取測試用例的范圍,可以從包括程序、文檔等所有可以使用的信息中獲得,提高了測試用例的覆蓋率,保證測試的充分性和完全性。
(3)完全實現(xiàn)了測試和開發(fā)的同步,以及各個過程內(nèi)各個階段之間的同步。真正實現(xiàn)了“全過程”測試,提高了軟件測試的質(zhì)量。
5.噴泉模型實例分析[1]
在給一個中型制造企業(yè)開發(fā)物流管理信息系統(tǒng)的過程中,使用改進(jìn)模型。這個物流管理信息系統(tǒng)基于C/S和B/S混合架構(gòu),一共分為六大子系統(tǒng),目的是解決企業(yè)內(nèi)部存在的“信息孤島”問題,實現(xiàn)企業(yè)內(nèi)部信息共享,幫助企業(yè)提高信息化水平。按照以往經(jīng)驗,開發(fā)一個物流管理信息系統(tǒng),其中有一半的時間是進(jìn)行各類測試。在開發(fā)這個系統(tǒng)時,所面臨的問題主要有以下幾點:
(1)企業(yè)的需求非常不固定,經(jīng)常變化。
(2)由于企業(yè)的規(guī)模不大,資金有限,要求在規(guī)定的時間內(nèi)必須完成開發(fā)。
(3)系統(tǒng)必須能正常運行,要求測試的完備性。
該系統(tǒng)開發(fā)小組一共四個成員,基于上述三個問題,采用了改進(jìn)的噴泉模型進(jìn)行軟件測試,一個編程,一個測試,開發(fā)與測試同步。本文以信息系統(tǒng)中的倉庫子系統(tǒng)為例,介紹如何使用該測試模型來解決以上問題。倉庫子系統(tǒng)結(jié)構(gòu)如圖5所示。
圖中一共分為三層,上層、中間層和底層,實際還有一層,稱為頂層。底層采用單元測試,中間層和上層采用集成測試,頂層采用系統(tǒng)測試。在整個系統(tǒng)開發(fā)過程中,嚴(yán)格按照測試模型進(jìn)行測試和開發(fā)。具體步驟和做法為:
(1)順層開發(fā)階段,對應(yīng)模型中的顧客分析。主要是對需求的確定和驗證。在確定用戶需求時,根據(jù)企業(yè)需求不穩(wěn)定的現(xiàn)狀,把企業(yè)的需求進(jìn)行分類,共分為三類:穩(wěn)定的,不穩(wěn)定的和極不穩(wěn)定的。
利用這些需求完成最初的需求說明書,根據(jù)測試模型,測試人員開始進(jìn)行設(shè)計驗收測試用例。對于極不穩(wěn)定的需求編制成一份文檔,并進(jìn)行確認(rèn),在以后的開發(fā)過程中邊開發(fā)邊對這些需求進(jìn)行更改。
(2)當(dāng)開發(fā)進(jìn)行到概要設(shè)計(圖中的上層)時,對應(yīng)測試模型中的系統(tǒng)分析階段。按照測試模型,采用邊開發(fā)邊測試的辦法。根據(jù)上一階段已經(jīng)通過驗收測試的需求說明書,將整個系統(tǒng)分成了六大子系統(tǒng),銷售子系統(tǒng)、采購子系統(tǒng)、倉庫子系統(tǒng)、生產(chǎn)子系統(tǒng)、財務(wù)子系統(tǒng)和服務(wù)器子系統(tǒng)。此時,測試人員結(jié)束驗收測試用例的設(shè)計,而進(jìn)入集成測試用例的設(shè)計。
(3)詳細(xì)設(shè)計階段,對應(yīng)測試模型的子系統(tǒng)分析。首先把倉庫分成系統(tǒng)管理、入庫管理、出庫管理、調(diào)撥管理、庫存統(tǒng)計和輔助管理六個模塊,這個過程測試人員繼續(xù)執(zhí)行測試用例的設(shè)計。然后進(jìn)入測試模型中的模塊分析階段,即開發(fā)人員根據(jù)需求文檔進(jìn)行更細(xì)小的模塊劃分。系統(tǒng)管理這個模塊由四個更小的模塊組成,入庫管理、出庫管理、調(diào)撥管理、庫存統(tǒng)計和輔助管理同樣進(jìn)行了更細(xì)的劃分。在這一過程中,需求中的不穩(wěn)定因素被確定下來,測試人員結(jié)束集成測試用例設(shè)計,轉(zhuǎn)而開發(fā)單元測試用例設(shè)計,測試人員大概能完成3/4的集成測試用例設(shè)計,并開始對文檔進(jìn)行驗收測試,記錄測試結(jié)果,反饋給開發(fā)人員,使其可以及時修改需求中出現(xiàn)的錯誤。
(4)代碼編寫階段。開發(fā)人員根據(jù)詳細(xì)設(shè)計的結(jié)果,從底層開始進(jìn)行代碼開發(fā)。測試人員繼續(xù)進(jìn)行單元測試用例的設(shè)計,測試用例的獲取范圍也擴大,可以從程序中選擇。例如完成庫存管理單元時,開發(fā)人員繼續(xù)開發(fā)下一個小單元,測試人員則開始進(jìn)行單元測試,并把測試后的結(jié)果反饋給開發(fā)人員,這樣開發(fā)人員能及時地改正錯誤。當(dāng)開發(fā)人員完成系統(tǒng)管理,開發(fā)入庫管理時,測試人員對系統(tǒng)管理進(jìn)行集成測試,并同時進(jìn)行單元測試。同樣將測試結(jié)果及時反饋給開發(fā)人員。當(dāng)整個倉庫子系統(tǒng)完成了2/3的模塊時,測試人員邊進(jìn)行單元測試和集成測試,邊進(jìn)行系統(tǒng)測試用例設(shè)計以及系統(tǒng)測試需要的測試環(huán)境設(shè)計。完成所有子系統(tǒng)時,開始進(jìn)行系統(tǒng)測試。
在最后執(zhí)行的驗收測試中發(fā)現(xiàn)的錯誤,先確定子系統(tǒng),再確定模塊,最后直接回到需求中查找錯誤,并執(zhí)行回歸測試。下表是測試過程中的一個測試實例。
為了能更清楚的說明改進(jìn)的噴泉模型的優(yōu)勢,我們把該模型每個階段測試的結(jié)果和舊有模型進(jìn)行了比對,如表2所示,并進(jìn)行了圖形分析,如下圖所示。
表2 新舊模型測試結(jié)果對比
舊模型 | 新模型 | |||
測試用例 | 出錯率 | 測試用例 | 出錯率 | |
需求分析階段 | 已完成的文檔 | 11% | ||
系統(tǒng)設(shè)計階段 | 準(zhǔn)確無誤的文檔信息 | 10.2% | 已經(jīng)完成的所有文檔 | 18.6% |
代碼開發(fā)階段 | 文檔、程序 | 24.6% | 所有文檔、程序 | 17.5% |
驗收測試階段 | 需求說明、程序 | l9% | 所有文檔、程序 | 10% |
從表2和上圖中可以看出,由于新模型實現(xiàn)了開發(fā)與測試并行,各個開發(fā)和測試階段的并行,擴大了測試用例的覆蓋率,而且軟件中出現(xiàn)的錯誤在前期就能及時發(fā)現(xiàn),不僅保證了測試的有效性和完備性,同時大大降低了測試在軟件中的費用。