軟件測試模型參考模板

1、從各種資料上找到以下幾種測試模型，拷貝粘貼，內(nèi)容并非本人原創(chuàng)，只是為了方便學(xué)習(xí)和記憶?？偨Y(jié)如下：1、V模型在軟件測試方面，V模型是最廣為人知的模型，盡管很多富有實際經(jīng)驗的測試人員還是不太熟悉V模型，或者其它的模型。V模型已存在了很長時間，和瀑布開發(fā)模型有著一些共同的特性，由此也和瀑布模型一樣地受到了批評和質(zhì)疑。V模型中的過程從左到右，描述了基本的開發(fā)過程和測試行為。V模型的價值在于它非常明確地標(biāo)明了測試過程中存在的不同級別，并且清楚地描述了這些測試階段和開發(fā)過程期間各階段的對應(yīng)關(guān)系。2、W模型V模型的局限性在于沒有明確地說明早期的測試,無法體現(xiàn)“盡早地和不斷地進行軟件測試”的原則。在V模型中增

2、加軟件各開發(fā)階段應(yīng)同步進行的測試，演化為W 模型（如下圖）。在模型中不難看出，開發(fā)是“V”，測試是與此并行的“V”。基于“盡早地和不斷地進行軟件測試”的原則，在軟件的需求和設(shè)計階段的測試活動應(yīng)遵循IEEE1012-1998軟件驗證與確認（V&V）的原則。W模型由Evolutif公司提出，相對于V模型，W模型更科學(xué)。W模型是V模型的發(fā)展，強調(diào)的是測試伴隨著整個軟件開發(fā)周期，而且測試的對象不僅僅是程序，需求、功能和設(shè)計同樣要測試。測試與開發(fā)是同步進行的，從而有利于盡早地發(fā)現(xiàn)問題。1 / 6W模型也有局限性。W模型和V模型都把軟件的開發(fā)視為需求、設(shè)計、編碼等一系列串行的活動，無法支持迭代、自

3、發(fā)性以及變更調(diào)整。3、X模型X模型也是對V模型的改進,X模型提出針對單獨的程序片段進行相互分離的編碼和測試,此后通過頻繁的交接,通過集成最終合成為可執(zhí)行的程序。X模型的左邊描述的是針對單獨程序片段所進行的相互分離的編碼和測試，此后將進行頻繁的交接，通過集成最終成為可執(zhí)行的程序，然后再對這些可執(zhí)行程序進行測試。己通過集成測試的成品可以進行封裝并提交給用戶，也可以作為更大規(guī)模和范圍內(nèi)集成的一部分。多根并行的曲線表示變更可以在各個部分發(fā)生。由圖中可見，X模型還定位了探索性測試，這是不進行事先計劃的特殊類型的測試，這一方式往往能幫助有經(jīng)驗的測試人員在測試計劃之外發(fā)現(xiàn)更多的軟件錯誤。但這樣可能對測試造成

4、人力、物力和財力的浪費，對測試員的熟練程度要求比較高。4、H模型H模型中, 軟件測試過程活動完全獨立,貫穿于整個產(chǎn)品的周期,與其他流程并發(fā)地進行,某個測試點準(zhǔn)備就緒時,就可以從測試準(zhǔn)備階段進行到測試執(zhí)行階段。軟件測試可以盡早的進行,并且可以根據(jù)被測物的不同而分層次進行。這個示意圖演示了在整個生產(chǎn)周期中某個層次上的一次測試“微循環(huán)”。圖中標(biāo)注的其它流程可以是任意的開發(fā)流程,例如設(shè)計流程或者編碼流程。也就是說, 只要測試條件成熟了,測試準(zhǔn)備活動完成了,測試執(zhí)行活動就可以進行了。H模型揭示了一個原理:軟件測試是一個獨立的流程,貫穿產(chǎn)品整個生命周期,與其他流程并發(fā)地進行。H模型指出軟件測試要盡早準(zhǔn)備,

5、 盡早執(zhí)行。不同的測試活動可以是按照某個次序先后進行的,但也可能是反復(fù)的,只要某個測試達到準(zhǔn)備就緒點,測試執(zhí)行活動就可以開展。5、前置模型前置測試模型則體現(xiàn)了開發(fā)與測試的結(jié)合,要求對每一個交付內(nèi)容進行測試。前置測試模型是一個將測試和開發(fā)緊密結(jié)合的模型，此模型將開發(fā)和測試的生命周期整合在一起，隨項目開發(fā)生命周期從開始到結(jié)束每個關(guān)鍵行為。前置測試模型體現(xiàn)了以下的要點：（一）開發(fā)和測試相結(jié)合前置測試模型將開發(fā)和測試的生命周期整合在一起，標(biāo)識了項目生命周期從開始到結(jié)束之間的關(guān)鍵行為。并且表示了這些行為在項目周期中的價值所在。如果其中有些行為沒有得到很好的執(zhí)行，那么項目成功的可能性就會因此而有所降低。如

6、果有業(yè)務(wù)需求，則系統(tǒng)開發(fā)過程將更有效率。在沒有業(yè)務(wù)需求的情況下進行開發(fā)和測試是不可能的。而且，業(yè)務(wù)需求最好在設(shè)計和開發(fā)之前就被正確定義。（二）對每一個交付內(nèi)容進行測試每一個交付的開發(fā)結(jié)果都必須通過一定的方式進行測試。源程序代碼并不是唯一需要測試的內(nèi)容。在圖中的綠色框表示了其它一些要測試的對象，包括可行性報告、業(yè)務(wù)需求說明，以及系統(tǒng)設(shè)計文檔等。這同V模型中開發(fā)和測試的對應(yīng)關(guān)系是相一致的，并且在其基礎(chǔ)上有所擴展，變得更為明確。前置測試模型包括2項測試計劃技術(shù):其中的第一項技術(shù)是開發(fā)基于需求的測試用例。這并不僅僅是為以后提交上來的程序的測試做好初始化準(zhǔn)備，也是為了驗證需求是否是可測試的。這些測試可以

7、交由用戶來進行驗收測試，或者由開發(fā)部門做某些技術(shù)測試。很多測試團體都認為，需求的可測試性即使不是需求首要的屬性，也應(yīng)是其最基本的屬性之一。因此，在必要的時候可以為每一個需求編寫測試用例。不過，基于需求的測試最多也只是和需求本身一樣重要。一項需求可能本身是錯誤的，但它仍是可測試的。而且，你無法為一些被忽略的需求來編寫測試用例。第二項技術(shù)是定義驗收標(biāo)準(zhǔn)。在接受交付的系統(tǒng)之前，用戶需要用驗收標(biāo)準(zhǔn)來進行驗證。驗收標(biāo)準(zhǔn)并不僅僅是定義需求，還應(yīng)在前置測試之前進行定義，這將幫助揭示某些需求是否正確，以及某些需求是否被忽略了。同樣的，系統(tǒng)設(shè)計在投入編碼實現(xiàn)之前也必須經(jīng)過測試，以確保其正確性和完整性。很多組織趨

8、向于對設(shè)計進行測試，而不是對需求進行測試。Goldsmith 曾提供過15項以上的測試方法來對設(shè)計進行測試，這些組織也只使用了其中很小的一部分。在對設(shè)計進行的測試中有一項非常有用的技術(shù)，即制訂計劃以確定應(yīng)如何針對提交的系統(tǒng)進行測試，這在處于設(shè)計階段并即將進入編碼階段時十分有用。（三）在設(shè)計階段進行計劃和測試設(shè)計設(shè)計階段是做測試計劃和測試設(shè)計的最好時機。很多組織要么根本不做測試計劃和測試設(shè)計，要么在即將開始執(zhí)行測試之間才飛快地完成測試計劃和設(shè)計。在這種情況下，測試只是驗證了程序的正確性，而不是驗證整個系統(tǒng)本該實現(xiàn)的東西。測試有2種主要的類型，這2種類型都需要測試計劃。在V模型中，驗收測試最早被定

9、義好，并在最后執(zhí)行，以驗證所交付的系統(tǒng)是否真正符合用戶業(yè)務(wù)的需求。與 V模型不同的是，前置測試模型認識到驗收測試中所包含的3種成份，其中的2種都與業(yè)務(wù)需求定義相聯(lián)系：即定義基于需求的測試，以及定義驗收標(biāo)準(zhǔn)。但是，第三種則需要等到系統(tǒng)設(shè)計完成，因為驗收測試計劃是由針對按設(shè)計實現(xiàn)的系統(tǒng)來進行的一些明確操作定義所組成，這些定義包括：如何判斷驗收標(biāo)準(zhǔn)已經(jīng)達到，以及基于需求的測試已算成功完成。技術(shù)測試主要是針對開發(fā)代碼的測試，例如V模型中所定義的動態(tài)的單元測試，集成測試和系統(tǒng)測試。另外，前置測試還提示我們應(yīng)增加靜態(tài)審查，以及獨立的QA測試。QA測試通常跟隨在系統(tǒng)測試之后，從技術(shù)部門的意見和用戶的預(yù)期方面

10、出發(fā)，進行最后的檢查.同樣的還有特別測試。我們?nèi)∶貏e測試，并把該名稱作為很多測試的一個統(tǒng)稱，這些測試包括負載測試、安全性測試、可用性測試等等，這些測試不是由業(yè)務(wù)邏輯和應(yīng)用來驅(qū)動的。對技術(shù)測試最基本的要求是驗證代碼的編寫和設(shè)計的要求是否相一致。一致的意思是系統(tǒng)確實提供了要求提供的，并且系統(tǒng)并沒有提供不要求提供的。技術(shù)測試在設(shè)計階段進行計劃和設(shè)計，并在開發(fā)階段由技術(shù)部門來執(zhí)行。（四）測試和開發(fā)結(jié)合在一起前置測試將測試執(zhí)行和開發(fā)結(jié)合在一起，并在開發(fā)階段以編碼-測試-編碼-測試的方式來體現(xiàn)。也就是說，程序片段一旦編寫完成，就會立即進行測試。普通情況下，先進行的測試是單元測試，因為開發(fā)人員認為通過測試

11、來發(fā)現(xiàn)錯誤是最經(jīng)濟的方式。但也可參考X模型，即一個程序片段也需要相關(guān)的集成測試，甚至有時還需要一些特殊測試。對于一個特定的程序片段，其測試的順序可以按照V模型的規(guī)定，但其中還會交織一些程序片段的開發(fā)，而不是按階段完全地隔離。在技術(shù)測試計劃中必須定義好這樣的結(jié)合。測試的主體方法和結(jié)構(gòu)應(yīng)在設(shè)計階段定義完成，并在開發(fā)階段進行補充和升版。這尤其會對基于代碼的測試產(chǎn)生影響，這種測試主要包括針對單元的測試和集成測試。不管在哪種情況下，如果在執(zhí)行測試之前做一點計劃和設(shè)計，都會提高測試效率，改善測試結(jié)果，而且對測試重用也更加有利。（五）讓驗收測試和技術(shù)測試保持相互獨立驗收測試應(yīng)該獨立于技術(shù)測試，這樣可以提供雙

12、重的保險，以保證設(shè)計及程序編碼能夠符合最終用戶的需求。驗收測試既可以在實施階段的第一步來執(zhí)行，也可以在開發(fā)階段的最后一步執(zhí)行。前置測試模型提倡驗收測試和技術(shù)測試沿循2條不同的路線來進行，每條路線分別地驗證系統(tǒng)是否能夠如預(yù)期的設(shè)想進行正常工作。這樣，當(dāng)單獨設(shè)計好的驗收測試完成了系統(tǒng)的驗證, 我們即可確信這是一個正確的系統(tǒng)。（六）反復(fù)交替的開發(fā)和測試在項目中從很多方面可以看到變更的發(fā)生，例如需要重新訪問前一階段的內(nèi)容，或者地跟蹤并糾正以前提交的內(nèi)容，修復(fù)錯誤，排除多余的成分，以及增加新發(fā)現(xiàn)的功能，等等。開發(fā)和測試需要一起反復(fù)交替地執(zhí)行。模型并沒有明確指出參與的系統(tǒng)部分的大小。這一點和V模型中所提供

13、的內(nèi)容相似。不同的是，前置測試模型對反復(fù)和交替進行了非常明確的描述。（七）發(fā)現(xiàn)內(nèi)在的價值前置測試能給需要使用測試技術(shù)的開發(fā)人員、測試人員、項目經(jīng)理和用戶等帶來很多不同于傳統(tǒng)方法的內(nèi)在的價值。與以前的方法中很少劃分優(yōu)先級所不同的是，前置測試用較低的成本來及早發(fā)現(xiàn)錯誤，并且充分強調(diào)了測試對確保系統(tǒng)的高質(zhì)量的重要意義。前置測試代表了整個對測試的新的不同的觀念。在整個開發(fā)過程中，反復(fù)使用了各種測試技術(shù)以使開發(fā)人員、經(jīng)理和用戶節(jié)省其時間，簡化其工作。通常情況下，開發(fā)人員會將測試工作視為阻礙其按期完成開發(fā)進度的額外的負擔(dān)。然而，當(dāng)我們提前定義好該如何對程序進行測試以后，我們會發(fā)現(xiàn)開發(fā)人員將節(jié)省至少20%的

14、時間。雖然開發(fā)人員很少意識到他們的時間是如何分配的，也許他們只是感覺到有一大塊時間從重新修改中節(jié)省下來可用來進行其它的開發(fā)。保守地說，在編碼之前對設(shè)計進行測試可以節(jié)省總共將近一半的時間，這可以從以下方面體現(xiàn)出來：針對設(shè)計的測試編寫是檢驗設(shè)計的一個非常好的方法，由此可以及時避免因為設(shè)計不正確而造成的重復(fù)開發(fā)及代碼修改。通常情況下，這樣的測試可以使設(shè)計中的邏輯缺陷凸顯出來。另一方面，編寫測試用例還能揭示設(shè)計中比較模糊的地方?？偟膩碚f，如果你不能勾畫出如何對程序進行測試，那么程序員很可能也很難確定他們所開發(fā)的程序怎樣才算是正確的。測試工作先于程序開發(fā)而進行，這樣可以明顯地看到程序應(yīng)該如何工作，否則，如果要等到程序開發(fā)完成后才開始測試，那么測試只是查驗開發(fā)人員的代碼是如何運行的。而提前的測試可以幫助開發(fā)人員立刻得到正確的錯誤定位。在測試先于編碼的情況下，開發(fā)人員可以在一完成編碼時就立刻進行測試。而且，她會更有效率，在同一