軟件測試生命周期和測試模型

軟件測試生命周期和測試模型回顧：軟件測試分類黑盒測試、白盒測試的概念靜態(tài)測試、動態(tài)測試的概念單元測試、集成測試、系統(tǒng)測試、驗收測試的概念功能測試、性能測試的概念和應用回歸測試、冒煙測試、隨機測試的概念第2頁,共37頁，2024年2月25日，星期天本章目標軟件工程概念、軟件工程的目標軟件的生命周期開發(fā)過程模型：瀑布、原型、螺旋、RUP、XP等測試過程模型：V模型、W模型、H模型軟件測試過程和開發(fā)過程的關系第3頁,共37頁，2024年2月25日，星期天軟件測試周期和測試模型掌握黑測試過程模型：V模型、W模型、H模型了解軟件測試過程第4頁,共37頁，2024年2月25日，星期天軟件工程的定義IEEE給出了一個全面的定義：把系統(tǒng)化的、規(guī)范的、可度量的途徑應用于軟件開發(fā)、運行和維護的過程．也就是把工程化應用于軟件中.通俗定義：采用工程的概念、原理、技術和方法來開發(fā)與維護軟件，把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來，以經濟地開發(fā)出高質量的軟件并有效地維護它，這就是軟件工程。第5頁,共37頁，2024年2月25日，星期天軟件工程的目標軟件工程的目標：

付出較低的開發(fā)成本。 達到要求的軟件功能。 取得較好的軟件性能 開發(fā)的軟件易于移植。軟件工程的目標之間的相互關系：

低開發(fā)成本需要較低的維護費用。易于維護能按時完成開發(fā)任務。能夠及時交付使用。開的軟件可靠高。

高可靠性按時交付 高性能第6頁,共37頁，2024年2月25日，星期天人類軟件

軟件生命周期什么是軟件生命周期？軟件生命周期是軟件工程中非常重要的概念。軟件生命周期：是指軟件開發(fā)和測試全部過程、活動和任務的結構框架，是從可行性研究到需求分析、軟件設計、編碼、測試、發(fā)布后的維護的過程。一個軟件項目的生命周期和人類的生命周期的類比如圖

出生可行性研究 需求分析

兒童 少年設計、編碼、測試青年、中年、老年 軟件發(fā) 布維護死亡淘汰第7頁,共37頁，2024年2月25日，星期天

軟件生命周期要素需求分析:根據客戶的要求，清楚了解客戶需求中的產品功能、特性、性能、界面和具體規(guī)格等，然后進行分析，確定軟件產品所能達到的目標。設計:根據需求分析的結果，考慮如何在邏輯、程序上去實現所定義的產品功能、特性等，可以分為概要設計和詳細設計，也可分為數據結構設計、軟件體系結構設計、應用接口設計、模塊設計、界面設計等。編程:將設計轉換成計算機可識別的指令。測試:對設計、編程進行驗證和用戶需求確認的過程維護：維持軟件運行，修改軟件缺陷、增強已有功能、增加新功能、升級等。第8頁,共37頁，2024年2月25日，星期天

軟件開發(fā)的生命周期軟件開發(fā)的生命周期，也叫軟件開發(fā)流程，是指軟件的開發(fā)過程中需要經過哪些環(huán)節(jié)。軟件開發(fā)的生命周期如圖所示：需求分析概要設計詳細設計編碼維護第9頁,共37頁，2024年2月25日，星期天

軟件開發(fā)過程開發(fā)人員構建產品

Softwaredefect,“bug” Fixedbug BugintroducedasaresultoffixinganotherbugCodingLock-downTest&StabilizeRelease第10頁,共37頁，2024年2月25日，星期天軟件開發(fā)過程模型思考&測試切入點在軟件開發(fā)的幾十年實踐中，人們總結了很多模型，如：瀑布模型、快速原型模型、螺旋模型、RUP等一系列的模型；這些模型對于軟件開發(fā)過程具有很好的指導作用，但是非常遺憾的是，在這些過程方法中，并沒有充分強調測試的價值，也沒有給測試以足夠的重視。第11頁,共37頁，2024年2月25日，星期天2.瀑布模型每瀑布模型切入點線性模型：1.占有重要的地位，是所有其他模型的一個基礎。瀑布模型每一個階段執(zhí)行一次次，按線性順序進行的軟件開發(fā)。測試的切入點：測試階段處于軟件實現后，必須在代碼完成后留出足夠的時間預留給測試活動，否則將導致測試不充分，很多問題到用戶使用時才爆發(fā)。第12頁,共37頁，2024年2月25日，星期天瀑布模型瀑布模型的優(yōu)點：開發(fā)的各個階段比較清晰。強調早期計劃及需求調查。適合需求穩(wěn)定的產品開發(fā)。前面未發(fā)現的錯誤會傳遞并擴散到后面的階段，可能導致項目失敗。瀑布模型的缺點：依賴于早期的需求調查，不適應需求的變化。單一流程不可逆。風險往往遲至后期才顯露，失去及早糾正的機會。測試僅是編碼的一個階段。改良：沿用瀑布模型的線性思想，細化了各個階段，在某些重要關注的階段之間摻入迭代的思想第13頁,共37頁，2024年2月25日，星期天原型的表示原型的使用

快速原型模型快速原型模型：

在開發(fā)真實系統(tǒng)之前，構造一個原型，在該原型的基礎上，逐漸完成整個系統(tǒng)的開發(fā)工作。第一步是建造一個快速原型，實現用戶與系統(tǒng)的交互，用戶對原型進行評價，進一步細化待開發(fā)軟件的需求。通過逐步調整原型使其滿足用戶的要求，開發(fā)人員可以確定用戶的真正需求是什么；第二步則在第一步的基礎上開發(fā)出用戶滿意的軟件產品。

?快速分析快速分析評價構造運行?需求說明?構造原型?原型?運行原型?評價原型?修改意見第14頁,共37頁，2024年2月25日，星期天快速原型模型快速原型模型的優(yōu)點：較短的開發(fā)過程。更好的滿足用戶的需求并減少項目失敗的風險。用戶對新系統(tǒng)更容易、更快的理解?？焖僭偷娜秉c：減少對更改和增補的靈活性和適應性。減少對非預期失敗情況的準備。不適合大型系統(tǒng)的開發(fā)（適合開發(fā)小型的、靈活性高的系統(tǒng)）第15頁,共37頁，2024年2月25日，星期天快速原型模型分類快速原型模型又可分為增量模型、漸進模型、演化模型增量模型：對于需求不能很快全部明確的系統(tǒng)，軟件開發(fā)項目難于做到一次開發(fā)成功，此時可以使用增量模型。應盡可能明確已知的需求，完成相應的需求分析，并按瀑布模型的方法進行第一次的開發(fā)工作。在系統(tǒng)集成時，通過實驗找出需求中的欠缺和不足，明確那些未知的軟件需求，再迭代進行部分分析和開發(fā)。漸進模型：此模型主要是針對部分需求盡管明確，但一時難以準確進行定義的系統(tǒng)設計，如用戶的操作界面等。使用此模型時，可以先做初步的需求分析，之后立即進行設計和編碼，隨后與系統(tǒng)進行第一次集成。根據集成后反映的問題進一步做更全面的需求分析、設計、編碼、測試。演化模型：是一種非整體開發(fā)的模型。軟件在該模型中是“逐漸”開發(fā)出來的，開發(fā)出一部分，向用展示一部分，可讓用戶及早看到部分軟件，及早發(fā)現問題，也可以先開發(fā)一個原型軟件，完成部分主要功能，展示給用戶并征求用戶的意見，然后逐步完善，最終獲得滿意的軟件產品。演化模型具有較大的靈活性，適合于軟件需求不明確，設計方案有一定風險的軟件。第16頁,共37頁，2024年2月25日，星期天出一個核心的系統(tǒng)（游戲引擎）螺旋模型

螺旋模型將瀑布模型和快速原型模型結合起來，強調了其他模型所忽視的風險分析。之所以叫螺旋模型，是因為這是一個迭代開發(fā)的過程，每一個迭代均由需求、設計、編碼、集成等階段組成。實際上這個模型可看作是重復執(zhí)行的多個“瀑布模型”，并在“瀑布模型”的每一個階段之前，引入非常嚴格的風險控制。直到消除風險之后，才開始下一階段的開發(fā)工作。 很多軟件公司在開發(fā)游戲軟件時都采用了螺旋模型特的思想，首先開發(fā) 個核心的系統(tǒng)（游戲引擎），然后再逐漸添加新的游戲場景，每每一次都是一輪小的循環(huán)。螺旋模型適合于大型軟件的開發(fā)。第17頁,共37頁，2024年2月25日，星期天螺旋模型

螺旋模型將開過程分為幾個螺旋周期，每個螺旋周期大致和瀑布模型相符合，螺旋模型沿著螺旋線旋轉，即在笛卡樂坐標的4個象限上分別表達了4個方面的活動，如圖所示：制定計劃風險分析實施開發(fā)客戶評估第18頁,共37頁，2024年2月25日，星期天螺旋模型螺旋模型的優(yōu)點：螺旋模型很大程度上是一種風險驅動的方法體系，因為在每個階段之前及經常發(fā)生的循環(huán)之前，都必須首先進行風險評估。螺旋模型的缺點：采用螺旋模型需要具有相當豐富的風險評估經驗和專門知識，在風險較大的項目開發(fā)中,如果未能夠及時標識風險，勢必造成重大損失。過多的迭代次數會增加開發(fā)成本，延遲提交時間。第19頁,共37頁，2024年2月25日，星期天RUP模型RUP：RationalUnifiedProcess(rational統(tǒng)一過程)RUP動態(tài)結構：初識階段細化階段構造階段移交階段第20頁,共37頁，2024年2月25日，星期天思考：XP...第21頁,共37頁，2024年2月25日，星期天XP-extremeProgramming極限編程最簡單的可能就是最有效的極限編程適合小團隊(2-10programmers)高風險快速變化或不穩(wěn)定的需求強調可測試性格言“溝通、簡化、反饋、激勵”KentBeck第22頁,共37頁，2024年2月25日，星期天以客戶端來“測試驅XP-eXtremeProgramming極限編程XP注重人的因數，提倡盡量敏捷輕量級的過程。

重要過程：測試驅動、迭代開發(fā)、持續(xù)集成構建、客戶現場參與(確定迭代內的功能集，提供業(yè)務邏輯的確認，驗證程序等)、只在必要時做簡單設計XP的缺點：要求客戶現場參與。通常國內項目都是前期作需求確認，無法提供整個開發(fā)過程的需求確認支持。除非是分段來確認（如迭代結束時）。

測試驅動開發(fā)。目前還很難做到，因為編寫測試腳本需要花費不少精力，一般項目無法做到。由此也無法作重構，無法保證能有靈活的設計來支持因前期不明確的需求而導致的變更。缺少文檔、設計支持。Xp只在必要時才寫文檔及設計，這樣可能導致xp新手缺乏良好的設計指引，項目開發(fā)過程透明度不夠，可能會失控。XP可借鑒的地方對整個開發(fā)過程：迭代開發(fā)、持續(xù)集成對特定迭代：編碼規(guī)范、保持設計靈活(允許需求改動)設計編碼過程：測試驅動、重構(用在編碼過程中，以客戶端來測試驅動”業(yè)務邏輯層、以重構減少重復代碼)第23頁,共37頁，2024年2月25日，星期天軟件測試&軟件工程軟件測試與軟件工程息息相關，軟件測試是軟件工程組成中不可或缺的一部分。

在軟件工程、項目管理、質量管理得到規(guī)范化應用的企業(yè)，軟件測試也會進行得比較順利，軟件測試發(fā)揮的價值也會更大。

要關注軟件工程、質量管理以及配置管理與軟件測試的關系；在不同的開發(fā)模式下，如何進行軟件測試。第24頁,共37頁，2024年2月25日，星期天

軟件測試的生命周期剛才的軟件開發(fā)流程中根本沒有提及測試，那么在軟件開發(fā)的每一個環(huán)節(jié)中，需要做哪能些測試工作呢？測試生命周期如圖：測試需求測試計劃測試設計測試執(zhí)行測試評估第25頁,共37頁，2024年2月25日，星期天測試模型思考?

軟件測試雖然較軟件開發(fā)的發(fā)展時間短，但是也已經總結了很多模型了。我們常見的有：V模型、W模型、H模型、X模型等。當然由于測試與開發(fā)的結合非常緊密，在這些測試模型中也都把開發(fā)過程進行了很好的總結，體現了測試與開發(fā)的融合。

那么測試的過程和軟件開發(fā)的過程一樣么？是否有很多的看上去很專業(yè)，似乎很有內涵的模型呢？第26頁,共37頁，2024年2月25日，星期天V模型誕生V模型是最具有代表意義的測試模型；V模型最早是由PaulRook在20世紀80年代后期提出，由英國國家計算機中心文獻中發(fā)布，旨在改進軟件開發(fā)的效率和效果；V模型推出的時代背景：在V模型推出之前，人們通常把測試過程作為在需求分析、概要設計、詳細設計、編碼全部完成之后的一個階段，盡管當時已經出現了測試工作會占用這個項目周期一半的時間，但是大多數人認為測試只是一個收尾工作；V模型在這個時候推出，就是為了改進之前行業(yè)的普遍認識。V模型本身是軟件開發(fā)中，瀑布模型的變種，它反映了測試活動與分析和設計的關系。V模型標明了測試過程中本身存在的不同階段，從左到右，描述了開發(fā)過程和測試過程間的階段對應關系。第27頁,共37頁，2024年2月25日，星期天

V模型V模型從左至右，將開發(fā)和測試兩個大階段分開，形成V字形。單元測試所檢測代碼的開發(fā)是否符合詳細設計的要求。集成測試所檢測此前測試過的各組成部分是否能完好地結合到一起。系統(tǒng)測試所檢測已集成在一起的產品是否符合系統(tǒng)規(guī)格說明書的要求。驗收測試則檢測產品是否符合最終用戶的需求。用戶需求 規(guī)格說明書 概要設計 詳細設計 編碼

驗收測試 系統(tǒng)測試 集成測試單元測試第28頁,共37頁，2024年2月25日，星期天測試計劃V模型(改進)需求分析定義

確認需求客戶、市場、產品人員測試目標

驗收測試黑盒方法測試系統(tǒng)、結構 設計

工程師、技術人員 系統(tǒng)測試設 計和環(huán)境技術實現

系統(tǒng)測試灰盒方法測試詳細或程序 設計功能測試用例 設計功能測試

分析/設計復審（靜態(tài)測試）編碼單元測試檢驗、動態(tài)測試白盒方法測試第29頁,共37頁，2024年2月25日，星期天V模型優(yōu)缺點V模型的優(yōu)點：開發(fā)V模型即包含了底層測試又包含了高層測試； 底層測試：檢驗源代碼質量的測試，如：單元測試； 高層測試：檢驗整個系統(tǒng)的需要，如：系統(tǒng)測試；V模型清楚地標識出了軟件開發(fā)的階段。它采用自頂向下逐步求精的方式把整個開發(fā)過程分成不同的階段，每個階段的工作都很明確，因此便于控制開發(fā)過程。當所有的階段都完成之后，該軟件的開發(fā)過程也隨之結束。V模型的缺點：V模型僅僅把測試過程作為在需求分析、概要設計、詳細設計以及編碼之后的一個階段，容易使人誤解測試是軟件開發(fā)的最后一個階段，是軟件開發(fā)的從屬。V模型的另一個大缺點正是它自身的順序性所導致的。到了測試階段，程序已經完成，錯誤已經產生，很多前期的錯誤一直到測試階段才發(fā)現，甚至無法發(fā)現，往往無從修改了。同時實際的開發(fā)過程中，在需求階段很難把用戶的需求完全明確下來，因此，當需求變更時將會導致階段反復，而且都要重復需求、設計、編碼、測試等過程，返工量非常大，模型靈活性比較低。第30頁,共37頁，2024年2月25日，星期天W模型誕生IEEEstd1012-1998《軟件驗證和確認（V&V）》的原則中提出了在軟件的需求和設計階段也應有測試活動，并且提出了相應的原則；W模型由Evolutif公司提出，提出了開發(fā)一個V，測試一個V，組合的W模型；測試伴隨著整個軟件開發(fā)周期，面且測試的對象I不僅僅是程序，需求、功能和設計同樣要測試。第31頁,共37頁，2024年2月25日，星期天w模型用戶需求需求分析&系統(tǒng)設計驗收測試設計 確認&系統(tǒng)測試設計

交付實施

驗收測試系統(tǒng)測試開發(fā)一個VV，測試一個V集成集成測試概要設計集成設計設計

單元測試設計詳細設計

單元測試

編碼第32頁,共37頁，2024年2月25日，星期天W模型優(yōu)缺點W模型的優(yōu)點：開發(fā)強調測試伴隨整個軟件開發(fā)周期，而且測試的對象不僅僅是程序，需求、功能和設計同樣要測試；更早的介入測試，可以發(fā)現開發(fā)初期的缺陷，那么可以用更加低的成本進行缺陷修復。測試被看成單獨的、和開發(fā)并行的一種流程，有效的保證了測試的獨立性；同樣是分階段的工作，便于控制項目過程；W模型的缺點：依賴于軟件開發(fā)和軟件測試依然保持一前一后的線性關系，依然無法支持迭代、自發(fā)性和需求等變更調整；對于當前很多項目，在執(zhí)行的過程中根本不產生文檔，那么W模型基本無法適用；使用起來技術復雜度很高，對于需求和設計的測試需要很高的技術才能執(zhí)行，實踐起來困難。第33頁,共37頁，2024年2月25日，星期天思考：兩個相似的模型我們都了解，再看一個靈活的模型，H模型！第34頁,共37頁，2024年2月25日，星期天H模型的誕生誕生背景：人們發(fā)現雖然軟件開發(fā)中需求、設計、編碼等活動被分階段