軟件測(cè)試生命周期和測(cè)試模型

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

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

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

高可靠性按時(shí)交付 高性能第六頁(yè)，共三十七頁(yè)，編輯于2023年，星期二人類軟件

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

出生可行性研究 需求分析

兒童 少年設(shè)計(jì)、編碼、測(cè)試青年、中年、老年 軟件發(fā) 布維護(hù)死亡淘汰第七頁(yè)，共三十七頁(yè)，編輯于2023年，星期二

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

軟件開發(fā)的生命周期軟件開發(fā)的生命周期，也叫軟件開發(fā)流程，是指軟件的開發(fā)過程中需要經(jīng)過哪些環(huán)節(jié)。軟件開發(fā)的生命周期如圖所示：需求分析概要設(shè)計(jì)詳細(xì)設(shè)計(jì)編碼維護(hù)第九頁(yè)，共三十七頁(yè)，編輯于2023年，星期二

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

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

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

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

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

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

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

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

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

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

要關(guān)注軟件工程、質(zhì)量管理以及配置管理與軟件測(cè)試的關(guān)系；在不同的開發(fā)模式下，如何進(jìn)行軟件測(cè)試。第二十四頁(yè)，共三十七頁(yè)，編輯于2023年，星期二

軟件測(cè)試的生命周期剛才的軟件開發(fā)流程中根本沒有提及測(cè)試，那么在軟件開發(fā)的每一個(gè)環(huán)節(jié)中，需要做哪能些測(cè)試工作呢？測(cè)試生命周期如圖：測(cè)試需求測(cè)試計(jì)劃測(cè)試設(shè)計(jì)測(cè)試執(zhí)行測(cè)試評(píng)估第二十五頁(yè)，共三十七頁(yè)，編輯于2023年，星期二測(cè)試模型思考?

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

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

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

驗(yàn)收測(cè)試 系統(tǒng)測(cè)試 集成測(cè)試單元測(cè)試第二十八頁(yè)，共三十七頁(yè)，編輯于2023年，星期二測(cè)試計(jì)劃V模型(改進(jìn))需求分析定義

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

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

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

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

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

交付實(shí)施

驗(yàn)收測(cè)試系統(tǒng)測(cè)試開發(fā)一個(gè)VV，測(cè)試一個(gè)V集成集成測(cè)試概要設(shè)計(jì)集成設(shè)計(jì)設(shè)計(jì)

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

單元測(cè)試

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