噴泉模型是一種以用戶需求為動力，以對象為驅(qū)動的模型，主要用于描述面向?qū)ο蟮能浖_發(fā)過程。該模型認為軟件開發(fā)過程自下而上周期的各階段是相互重疊和多次反復的，就像水噴上去又可以落下來，類似一個噴泉。各個開發(fā)階段沒有特定的次序要求，并且可以交互進行，可以在某個開發(fā)階段中隨時補充其他任何開發(fā)階段中的遺漏。采用噴泉模型的軟件過程如下圖所示：

噴泉模型主要用于面向?qū)ο蟮能浖?a href="/wiki/%E9%A1%B9%E7%9B%AE" title="項目">項目，軟件的某個部分通常被重復多次，相關對象在每次迭代中隨之加入漸進的軟件成分。各活動之間無明顯邊界，例如設計和實現(xiàn)之間沒有明顯的邊界，這也稱為“噴泉模型的無間隙性”。由于對象概念的引入，表達分析、設計及實現(xiàn)等活動只用對象類和關系，從而可以較容易地實現(xiàn)活動的迭代和無間隙。

噴泉模型是由B．H．Sollers和J．M．Edwards于1990年提出的一種新的開發(fā)模型。噴泉模型主要用于采用面向?qū)ο蠹夹g的軟件開發(fā)項目，噴泉一詞本身就體現(xiàn)了迭代和無間隙的特征。無間隙指在各項活動之間無明顯邊界，如分析、設計和編碼之間沒有明顯的界限。在編碼之前再進行需求分析和設計，期間添加有關功能，使系統(tǒng)得以演化。噴泉模型在系統(tǒng)某個部分常常被重復工作多次，相關對象在每次迭代中隨之加入漸進的系統(tǒng)。由于對象概念的引入，需求分析、設計、實現(xiàn)等活動只用對象類和關系來表達，從而可以較為容易地實現(xiàn)活動的迭代和無間隙，并且使得開發(fā)過程自然地包括復用。

1、噴泉模型的優(yōu)點

噴泉模型不像瀑布模型那樣，需要分析活動結束后才開始設計活動，設計活動結束后才開始編碼活動。該模型的各個階段沒有明顯的界限，開發(fā)人員可以同步進行開發(fā)。其優(yōu)點是可以提高軟件項目開發(fā)效率，節(jié)省開發(fā)時間，適應于面向?qū)ο蟮能浖_發(fā)過程。

2、噴泉模型的缺點

由于噴泉模型在各個開發(fā)階段是重疊的，因此在開發(fā)過程中需要大量的開發(fā)人員，因此不利于項目的管理。此外這種模型要求嚴格管理文檔，使得審核的難度加大，尤其是面對可能隨時加入各種信息、需求與資料的情況。

1.傳統(tǒng)的噴泉模型

傳統(tǒng)的噴泉模型如下圖所示，目前主要應用于面向?qū)ο蟮能浖_發(fā)中 。該模型的主要特點是認為軟件開發(fā)的各個階段是相互重疊和多次反復的，從圖中可以看出，軟件開發(fā)的規(guī)格說明階段、設計階段、編碼階段和測試階段可以交疊在一起，同時進行。這體現(xiàn)了各個開發(fā)過程的并行關系。噴泉的水可以噴上去又可以落下來，水既可以落在中間，也可以落在底部。這一點在模型中表現(xiàn)為各個測試階段的并行。噴泉的水不停的噴發(fā)、墜落，代表著開發(fā)和測試階段的復雜性和重復性。

2.改進的噴泉模型

在傳統(tǒng)噴泉模型的基礎上，提出了改進的噴泉模型，如下圖所示。以噴泉模型為基礎，可以實現(xiàn)盡早的、全面的展開測試，同時將測試工作進行迭代。另外，改進的噴泉將需求納入，使得模型完全實現(xiàn)了整個開發(fā)過程的無邊界、交互性。

該模型每一次測試過程包括四個階段。

第一階段為測試需求階段，包括提取和驗證需求。這一階段的測試主要是采用靜態(tài)測試。

第二階段為測試分析階段，又分為制定測試計劃、測試設計與開發(fā)兩個步驟。測試計劃包括確定測試策略和測試系統(tǒng)，預估測試工作量等。測試設計與開發(fā)包括開發(fā)測試用例，驗證并調(diào)試測試等。

第三階段為測試執(zhí)行階段，強調(diào)測試人員和開發(fā)人員的配合。該階段的測試方法包括單元測試、集成測試、系統(tǒng)測試及驗收測試。除了對程序進行測試外，還要對文檔等進行測試。記錄測試結果并寫出測試總結報告，為下一輪的迭代測試打基礎。

第四階段為測試維護階段。開發(fā)者的維護包括修復顧客操作和為滿足不斷變化的顧客需求而對產(chǎn)品功能進行增強時發(fā)現(xiàn)的缺陷；測試組的維護意味著對缺陷的修復進行驗證，測試增強了的功能以及產(chǎn)品的新發(fā)布版本上運行回歸測試以確保修改前的產(chǎn)品具有的功能不因產(chǎn)品的新變化而被破壞。

從模型圖中可以看出，該模型除具有傳統(tǒng)噴泉模型的優(yōu)點外，還體現(xiàn)了以下特點：

(1)布式特點當軟件結束計劃階段，分布在不同地域的軟件開發(fā)小組可以根據(jù)計劃，在不同或者相同的時間啟動項目開發(fā)。

(2)測試的充分軟件測試中測試用例的覆蓋率直接決定了軟件測試的質(zhì)量。改進的噴泉模型大大擴大了設計和選取測試用例的范圍，可以從包括程序、文檔等所有可以使用的信息中獲得，提高了測試用例的覆蓋率，保證測試的充分性和完全性。

(3)完全實現(xiàn)了測試和開發(fā)的同步，以及各個過程內(nèi)各個階段之間的同步。真正實現(xiàn)了“全過程”測試，提高了軟件測試的質(zhì)量。

在給一個中型制造企業(yè)開發(fā)物流管理信息系統(tǒng)的過程中，使用改進模型。這個物流管理信息系統(tǒng)基于C／S和B／S混合架構，一共分為六大子系統(tǒng)，目的是解決企業(yè)內(nèi)部存在的“信息孤島”問題，實現(xiàn)企業(yè)內(nèi)部信息共享，幫助企業(yè)提高信息化水平。按照以往經(jīng)驗，開發(fā)一個物流管理信息系統(tǒng)，其中有一半的時間是進行各類測試。在開發(fā)這個系統(tǒng)時，所面臨的問題主要有以下幾點：

(1)企業(yè)的需求非常不固定，經(jīng)常變化。

(2)由于企業(yè)的規(guī)模不大，資金有限，要求在規(guī)定的時間內(nèi)必須完成開發(fā)。

(3)系統(tǒng)必須能正常運行，要求測試的完備性。

該系統(tǒng)開發(fā)小組一共四個成員，基于上述三個問題，采用了改進的噴泉模型進行軟件測試，一個編程，一個測試，開發(fā)與測試同步。本文以信息系統(tǒng)中的倉庫子系統(tǒng)為例，介紹如何使用該測試模型來解決以上問題。倉庫子系統(tǒng)結構如圖5所示。

圖中一共分為三層，上層、中間層和底層，實際還有一層，稱為頂層。底層采用單元測試，中間層和上層采用集成測試，頂層采用系統(tǒng)測試。在整個系統(tǒng)開發(fā)過程中，嚴格按照測試模型進行測試和開發(fā)。具體步驟和做法為：

(1)順層開發(fā)階段，對應模型中的顧客分析。主要是對需求的確定和驗證。在確定用戶需求時，根據(jù)企業(yè)需求不穩(wěn)定的現(xiàn)狀，把企業(yè)的需求進行分類，共分為三類：穩(wěn)定的，不穩(wěn)定的和極不穩(wěn)定的。

利用這些需求完成最初的需求說明書，根據(jù)測試模型，測試人員開始進行設計驗收測試用例。對于極不穩(wěn)定的需求編制成一份文檔，并進行確認，在以后的開發(fā)過程中邊開發(fā)邊對這些需求進行更改。

(2)當開發(fā)進行到概要設計(圖中的上層)時，對應測試模型中的系統(tǒng)分析階段。按照測試模型，采用邊開發(fā)邊測試的辦法。根據(jù)上一階段已經(jīng)通過驗收測試的需求說明書，將整個系統(tǒng)分成了六大子系統(tǒng)，銷售子系統(tǒng)、采購子系統(tǒng)、倉庫子系統(tǒng)、生產(chǎn)子系統(tǒng)、財務子系統(tǒng)和服務器子系統(tǒng)。此時，測試人員結束驗收測試用例的設計，而進入集成測試用例的設計。

(3)詳細設計階段，對應測試模型的子系統(tǒng)分析。首先把倉庫分成系統(tǒng)管理、入庫管理、出庫管理、調(diào)撥管理、庫存統(tǒng)計和輔助管理六個模塊，這個過程測試人員繼續(xù)執(zhí)行測試用例的設計。然后進入測試模型中的模塊分析階段，即開發(fā)人員根據(jù)需求文檔進行更細小的模塊劃分。系統(tǒng)管理這個模塊由四個更小的模塊組成，入庫管理、出庫管理、調(diào)撥管理、庫存統(tǒng)計和輔助管理同樣進行了更細的劃分。在這一過程中，需求中的不穩(wěn)定因素被確定下來，測試人員結束集成測試用例設計，轉(zhuǎn)而開發(fā)單元測試用例設計，測試人員大概能完成3／4的集成測試用例設計，并開始對文檔進行驗收測試，記錄測試結果，反饋給開發(fā)人員，使其可以及時修改需求中出現(xiàn)的錯誤。

(4)代碼編寫階段。開發(fā)人員根據(jù)詳細設計的結果，從底層開始進行代碼開發(fā)。測試人員繼續(xù)進行單元測試用例的設計，測試用例的獲取范圍也擴大，可以從程序中選擇。例如完成庫存管理單元時，開發(fā)人員繼續(xù)開發(fā)下一個小單元，測試人員則開始進行單元測試，并把測試后的結果反饋給開發(fā)人員，這樣開發(fā)人員能及時地改正錯誤。當開發(fā)人員完成系統(tǒng)管理，開發(fā)入庫管理時，測試人員對系統(tǒng)管理進行集成測試，并同時進行單元測試。同樣將測試結果及時反饋給開發(fā)人員。當整個倉庫子系統(tǒng)完成了2／3的模塊時，測試人員邊進行單元測試和集成測試，邊進行系統(tǒng)測試用例設計以及系統(tǒng)測試需要的測試環(huán)境設計。完成所有子系統(tǒng)時，開始進行系統(tǒng)測試。

在最后執(zhí)行的驗收測試中發(fā)現(xiàn)的錯誤，先確定子系統(tǒng)，再確定模塊，最后直接回到需求中查找錯誤，并執(zhí)行回歸測試。下表是測試過程中的一個測試實例。

為了能更清楚的說明改進的噴泉模型的優(yōu)勢，我們把該模型每個階段測試的結果和舊有模型進行了比對，如表2所示，并進行了圖形分析，如下圖所示。

表2 新舊模型測試結果對比

從表2和上圖中可以看出，由于新模型實現(xiàn)了開發(fā)與測試并行，各個開發(fā)和測試階段的并行，擴大了測試用例的覆蓋率，而且軟件中出現(xiàn)的錯誤在前期就能及時發(fā)現(xiàn)，不僅保證了測試的有效性和完備性，同時大大降低了測試在軟件中的費用。