軟件測試生命周期和測試模型_第1頁
軟件測試生命周期和測試模型_第2頁
軟件測試生命周期和測試模型_第3頁
軟件測試生命周期和測試模型_第4頁
軟件測試生命周期和測試模型_第5頁
已閱讀5頁,還剩32頁未讀 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報或認(rèn)領(lǐng)

文檔簡介

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

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

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

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

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

出生可行性研究 需求分析

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

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

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

軟件開發(fā)過程開發(fā)人員構(gòu)建產(chǎn)品

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

快速原型模型快速原型模型:

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

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

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

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

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

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

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

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

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

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

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

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

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

確認(rèn)需求客戶、市場、產(chǎn)品人員測試目標(biāo)

驗收測試黑盒方法測試系統(tǒng)、結(jié)構(gòu) 設(shè)計

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

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

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

交付實施

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

單元測試設(shè)計詳細(xì)設(shè)計

單元測試

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

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

最新文檔

評論

0/150

提交評論