軟件工程總結(jié)樣本

軟件工程復(fù)習(xí)提綱TOC\o"1-3"\h\u21448第1章 軟件工程簡介 225308軟件是什么 231863第2章 過程綜述 217106軟件工程定義 216169層次化 3285通用過程框架 326311第3章過程模型 4493各種過程模型 48189第4章敏捷視角下過程 615220敏捷宣言 631628第5章系統(tǒng)工程 727003第6章需求工程 89208質(zhì)量功能布置（QFD） 831442分析模型元素 1127078第7章構(gòu)建分析模型 1128431第8章設(shè)計(jì)工程 118885第9章進(jìn)行體系構(gòu)造設(shè)計(jì) 1220343體系構(gòu)造風(fēng)格分類 1231621第10章構(gòu)件級設(shè)計(jì)建模 131035第11章完畢顧客界面設(shè)計(jì) 136487黃金規(guī)則 133592第12章軟件測試方略 143753軟件測試需要籌劃和執(zhí)行一系列測試環(huán)節(jié) 1415195第13章測試技術(shù) 152417兩個不同測試用例設(shè)計(jì)技術(shù) 1517121第14章產(chǎn)品度量 15

第1章 軟件工程簡介軟件是什么軟件是形成配備一組術(shù)語或?qū)ο?，涉及：程?計(jì)算機(jī)程序)：指令集合,通過執(zhí)行這些指令可以滿足預(yù)期特性、功能和性能需求數(shù)據(jù)構(gòu)造:它使得程序可以充分運(yùn)用信息文檔:描述程序操作和使用文檔（圖文資料）舉例闡明“意外效應(yīng)法則”（lawofunintendedconsequences）在計(jì)算機(jī)軟件方面應(yīng)用。某些新科技創(chuàng)造創(chuàng)造會給其她某些看似無關(guān)技術(shù)領(lǐng)域、商業(yè)公司、公眾甚至整個社會文化帶來深遠(yuǎn)而出人意料影響和作用。如：用自己語言描述保證通曉規(guī)律（TheLawofConservationofFamiliarity）、質(zhì)量衰減規(guī)律（TheLawofDecliningQuality）以及組織穩(wěn)定性守恒規(guī)律（TheLawofConservationofOrganizationalStability）。保證通曉性規(guī)律(1980)：隨著E類型系統(tǒng)演化，所有有關(guān)人員（如開發(fā)人員、銷售人員和顧客）都必要清晰地理解演化內(nèi)容和過程，以便達(dá)到滿意演化效果。質(zhì)量衰減規(guī)律(1996)：如果沒有嚴(yán)格維護(hù)和適應(yīng)性調(diào)節(jié)使之適應(yīng)運(yùn)營環(huán)境變化，E類型系統(tǒng)質(zhì)量有衰減趨勢。組織穩(wěn)定性守恒規(guī)律(1980)：一種不斷演化E類型系統(tǒng)，其組織在全球范疇內(nèi)平均有效活動率在產(chǎn)品生命周期中是保持不變。在交付最后顧客之前，或者第1個版本投入使用之后，許多應(yīng)用程序都會有頻繁變更。為防止變更引起軟件失效，請?zhí)岢瞿承┯行Ы鉀Q辦法。一方面從心態(tài)上承認(rèn)變化是必然，咱們可以通過在軟件發(fā)布之邁進(jìn)行alpha，beta測試，運(yùn)用迭代模式，在吸取測試過程中經(jīng)驗(yàn)之后，立即改進(jìn)軟件。同步保持和顧客良好溝通，在提交顧客時進(jìn)行恰當(dāng)培訓(xùn)，讓顧客按照開發(fā)思路進(jìn)行試用，可以見減少因用法不當(dāng)引起變化。第2章 過程綜述軟件工程定義軟件工程是：（1）將系統(tǒng)化、規(guī)范、可量化辦法應(yīng)用于軟件開發(fā)、運(yùn)營和維護(hù)，即將工程化辦法應(yīng)用于軟件。（2）在（1）中所述辦法研究。層次化通用過程框架溝通（Communication）策劃（Planning）建模（Modeling）需求分析（Analysisofrequirements）設(shè)計(jì)（Design）構(gòu)建（Construction）代碼生成（Codegeneration）測試（Testing）布置（Deployment）重點(diǎn)：Baetjer說過“軟件過程為顧客和設(shè)計(jì)者之間、顧客和開發(fā)工具之間以及設(shè)計(jì)者和開發(fā)工具之間提供交互途徑[技術(shù)]?！痹O(shè)計(jì)下面問題“⑴設(shè)計(jì)者應(yīng)當(dāng)問顧客；⑵顧客應(yīng)當(dāng)問設(shè)計(jì)者；⑶顧客對將要構(gòu)建軟件自問；⑷設(shè)計(jì)者對于軟件產(chǎn)品和建造該產(chǎn)品采用軟件過程自問。（如何獲取需求）為溝通活動設(shè)計(jì)一種任務(wù)集辨認(rèn)重要客戶和其她共利益者與客戶會談環(huán)境無關(guān)話題寫一頁項(xiàng)目范疇評審范疇闡明討論項(xiàng)目大體階段商定各個部門代表，并使她們互相結(jié)識為籌劃活動做準(zhǔn)備用自己話描述過程框架。當(dāng)咱們談到框架活動合用于所有項(xiàng)目時，與否意味著對于不同規(guī)模和復(fù)雜度項(xiàng)目，可應(yīng)用相似工作任務(wù)？請解釋。過程框架定義了若干小框架活動，為完整軟件開發(fā)過程建立基本，這些框架活動可以廣泛用于所有軟件開發(fā)項(xiàng)目，無論這些項(xiàng)目復(fù)雜性和規(guī)模如何，此外，還涉及某些合用于各個軟件過程普適性活動。雖然過程框架是普適性，但是對于不同規(guī)模和復(fù)雜度項(xiàng)目不能應(yīng)用相似工作任務(wù)。一方面在軟件開發(fā)不同階段，工作任務(wù)不同。另一方面不同軟件項(xiàng)目有不同需求，有特殊背景，找不到一種通用工作任務(wù)。圖2-1中，基于“質(zhì)量關(guān)注點(diǎn)”指明了軟件工程三個層次。這意味著在整個開發(fā)組織內(nèi)采用質(zhì)量管理活動，如“全面質(zhì)量管理”。仔細(xì)研究，并列出全面質(zhì)量管理活動中核心原則大綱。過程模型各種過程模型慣例軟件過程模型力圖給軟件開發(fā)帶來秩序和構(gòu)造。盡管每一老式過程模型都建議了一種不同過程流，但均實(shí)現(xiàn)了同樣一組通用框架活動：溝通、籌劃、建模、構(gòu)建和布置。瀑布模型建議線性流程框架活動，與軟件世界里當(dāng)代軟件開發(fā)實(shí)際（持續(xù)變更、演化系統(tǒng)、急迫開發(fā)時間）不符；但瀑布模型的確合用于需求定義清晰且穩(wěn)定軟件開發(fā)；增量軟件過程模型通過一系列增量發(fā)布產(chǎn)生軟件。RAD模型迅速應(yīng)用程序開發(fā)，是為大型且必要在嚴(yán)格時間內(nèi)提交項(xiàng)目而設(shè)計(jì)；演化過程模型結(jié)識到大多數(shù)軟件工程項(xiàng)目迭代特性，其設(shè)計(jì)目是為了適應(yīng)變更演化模型（如原型模型、螺旋模型），其迅速產(chǎn)生增量工作產(chǎn)品（或是軟件工作版本），這些模型可以應(yīng)用于所有軟件工程活動——從概念開發(fā)到長期軟件維護(hù)?；跇?gòu)建模型強(qiáng)調(diào)構(gòu)件復(fù)用及組裝。形式化辦法模型倡導(dǎo)采用數(shù)學(xué)辦法進(jìn)行軟件開發(fā)和驗(yàn)證。面向方面模型目是解決跨整個軟件體系構(gòu)造橫切關(guān)注點(diǎn)；統(tǒng)一過程模型是一種“用例驅(qū)動、以體系構(gòu)造為核心、迭代及增量”軟件過程框架，由UML辦法和工具支持。統(tǒng)一過程是一種增量模型，定義了五個階段：起始階段：涉及顧客溝通和籌劃活動兩個方面，強(qiáng)調(diào)定義和細(xì)化用例，并將其作為重要模型；細(xì)化階段：涉及顧客溝通和建模活動，重點(diǎn)是創(chuàng)立分析和設(shè)計(jì)模型，強(qiáng)調(diào)類定義和體系構(gòu)造表達(dá)；構(gòu)建階段：細(xì)化設(shè)計(jì)模型，并將設(shè)計(jì)模型轉(zhuǎn)化為軟件構(gòu)建實(shí)現(xiàn)；轉(zhuǎn)化階段：將軟件從開發(fā)人員傳遞給最后顧客，并由顧客完畢Beta測試和驗(yàn)收測試；生產(chǎn)階段：持續(xù)地監(jiān)控軟件運(yùn)營，并提供技術(shù)支持。重點(diǎn)：開發(fā)質(zhì)量“足夠好”軟件，其長處和缺陷是什么？當(dāng)咱們追求開發(fā)速度賽過產(chǎn)品質(zhì)量時候，會產(chǎn)生什么后果？咱們總在質(zhì)量和開發(fā)速度之間做取舍，開發(fā)質(zhì)量“足夠好”軟件，明顯強(qiáng)調(diào)質(zhì)量，長處是使軟件符合或超過客戶預(yù)期，在性能上，交互上力圖做到盡善盡美。缺陷是忽視了開發(fā)成本，很容易導(dǎo)致開發(fā)時間延期，影響軟件工程后幾種階段工作，對全局導(dǎo)致不利影響。當(dāng)沿著螺旋過程流發(fā)展時候，你對正在開發(fā)或者維護(hù)軟件看法是什么？在螺旋模式下，開發(fā)過程是迭代式，采用循環(huán)方式逐漸加深系統(tǒng)定義和實(shí)現(xiàn)深度，同步減少風(fēng)險。當(dāng)軟件交付使用后，螺旋模式?jīng)]有停止，它將永遠(yuǎn)保持可操作性，每一圈完畢后都會計(jì)算成本，可以更好維護(hù)軟件?？梢院嫌脦追N過程模型嗎？如果可以，舉例闡明。可以。幾種過程模型，都是互相兼容可以互相擴(kuò)展，如螺旋模型結(jié)合了原型迭代性質(zhì)和瀑模型系統(tǒng)性和可控性特點(diǎn)。在詳細(xì)項(xiàng)目實(shí)行中，對于某一某些可以合用幾種過程模型，例如形式語言與自動機(jī)演示軟件在算法開發(fā)過程，就需要使用形式化辦法模型，用嚴(yán)格數(shù)學(xué)符號定義形式語言和自動機(jī)。尚有某些桌面應(yīng)用程序前臺UI某些，可以單獨(dú)使用RAD模型，例如用delphi語言開發(fā)桌面窗體就是一種RAD實(shí)現(xiàn)。而其她某些可以使用其她如瀑布式模型等辦法。敏捷視角下過程敏捷宣言個體和交互賽過過程和工具（Individualsandinteractionsoverprocessesandtools）可工作軟件賽過寬泛文檔（Workingsoftwareovercomprehensivedocumentation）客戶合伙賽過合同談判（Customercollaborationovercontractnegotiation）響應(yīng)變化賽過遵循籌劃（Respondingtochangeoverfollowingaplan）重點(diǎn)：與否每一種敏捷過程都可以用第2章所提及通用框架性活動來描述？建一張表，將通用活動和每個敏捷過程所定義活動相應(yīng)起來。用自己語言描述（用于軟件項(xiàng)目）敏捷性？普遍存在變化是敏捷基本動力，敏捷需要有效響應(yīng)變化，它勉勵在共利益者之間進(jìn)行更便利溝通和協(xié)作，強(qiáng)調(diào)可運(yùn)營軟件迅速交付。敏捷容許項(xiàng)目團(tuán)隊(duì)調(diào)節(jié)并合理安排任務(wù)，理解易變性并制定籌劃。精簡并維持最基本工作產(chǎn)品，強(qiáng)調(diào)增量交付，迅速提供可運(yùn)營軟件。許多敏捷過程模型推薦面對面交流，事實(shí)上，當(dāng)前軟件開發(fā)團(tuán)隊(duì)成員及其客戶在地理上是分散。你與否以為這意味著這種地理上分散應(yīng)當(dāng)避免？能否想出一種辦法克服這個問題。我以為這種地理上分散是現(xiàn)實(shí)，是無法避免。我以為可以分為客戶和開發(fā)人員分散，開發(fā)人員內(nèi)某些散兩種狀況。對于第一種：產(chǎn)品經(jīng)理需要同客戶建立一條良好通信信道，如通過email,即時聊天工具進(jìn)行定期溝通。對于第二種：開發(fā)人員需定期組織交流，通過webgroup消除地理上分散。為什么需求變化這樣大，人們終歸無法擬定她們想要什么嗎？我以為是這樣。其實(shí)需求是客戶對她們心目中軟件一種描述，由于軟件還沒有實(shí)現(xiàn)，這種描述便是不擬定，模糊。同步當(dāng)今世界處在高速變化之中，人們需求會隨著環(huán)境變化而變化。因此敏捷開發(fā)承認(rèn)變化，以為普遍存在變化是敏捷基本動力。系統(tǒng)工程在寫下每行代碼之前理解所要解決問題(詳見溝通與建模)理解基本設(shè)計(jì)原則和概念選取一種可以滿足軟件構(gòu)建以及運(yùn)營環(huán)境規(guī)定編程語言選取一種能提供工具以簡化工作編程環(huán)境構(gòu)件級編碼完畢后進(jìn)行單元測試系統(tǒng)工程層次圖重點(diǎn)：對你熟悉系統(tǒng)、產(chǎn)品或服務(wù)，建立它們層次系統(tǒng)。層次應(yīng)當(dāng)向下擴(kuò)展到簡樸系統(tǒng)要素（硬件、軟件等），至少得到層次樹一種分支。即時聊天系統(tǒng)系統(tǒng)工程師由3種來源：系統(tǒng)開發(fā)人員、顧客或某些外部組織。討論一下每種來源利與弊。描述一種抱負(fù)系統(tǒng)工程師。研究文獻(xiàn)并寫出一篇簡短文章描述建模和模仿工具是如何工作。或者是收集兩個或更多商用建?；蚰７鹿ぞ呶墨I(xiàn)，并且比較它們相似處與不同處。需求工程質(zhì)量功能布置（QFD）是一種將客戶規(guī)定轉(zhuǎn)化成軟件技術(shù)需求技術(shù)。QFD“目是最大限度地讓客戶從軟件工程過程中感到滿意”，并強(qiáng)調(diào)“什么是對客戶有價值”。確認(rèn)三類需求：正常需求：反映了在和客戶開會時擬定針對某產(chǎn)品或系統(tǒng)目的。如果實(shí)現(xiàn)了這些需求，將滿足客戶（例如：所規(guī)定圖形顯示類型、特定系統(tǒng)功能以及已定義性能級別）。盼望需求：隱含在產(chǎn)品或系統(tǒng)中，并且也許是非?；疽灾劣诳蛻魶]有顯式地闡明，但缺少這些將導(dǎo)致客戶明顯不滿（例如：易交互性、可操作性、可靠性、易安裝等）。令人興奮需求：反映了客戶盼望之外特點(diǎn)，但如果實(shí)現(xiàn)了這些特點(diǎn)，將會使客戶非常滿意。重點(diǎn)：為如下活動之一開發(fā)一種完整用例：在ATM提款；在餐廳使用信用卡付費(fèi)；使用一種在線經(jīng)紀(jì)人賬戶購買股票；使用在線書店搜索書（某個指定主題）；ATM用例圖“ATM取款”用例規(guī)約用例名稱：ATM取款簡述：客戶持銀行卡（本行或其她行）從ATM提取鈔票actors:客戶和銀行主機(jī)基本流：客戶插入銀行卡。ATM從銀行卡讀入卡號（含銀行標(biāo)記和賬號），驗(yàn)證卡有效性?？蛻糨斎朊艽a。ATM驗(yàn)證帳號和密碼。ATM顯示涉及取款在內(nèi)服務(wù)功能，客戶選取“取款”。輸入取款額：客戶輸入數(shù)量為50元倍數(shù)取款額。ATM向銀行主機(jī)告知卡號、密碼、賬號和取款額，獲得具有最新余額取款成功確認(rèn)信息。ATM打印并吐出憑條。ATM清點(diǎn)并吐出鈔票，記錄取款成功。ATM詢問客戶與否繼續(xù)服務(wù)?？蛻暨x取否，ATM吐出銀行卡，結(jié)束用例，否則回到環(huán)節(jié)5。[用例結(jié)束]備選流：3-7，10a.客戶取消服務(wù)：ATM記錄服務(wù)取消，打印憑條，吐出憑條和銀行卡，[用例失敗]3,6,11a.客戶未及時輸入超過30秒：ATM吞卡，[用例失敗]2a.卡無效：ATM吞卡，[用例失敗]2b.讀卡器或卡被損壞：ATM吞卡，[用例失敗]4a.密碼錯：4a1.客戶重新輸入密碼合計(jì)3次密碼錯誤：ATM吞卡，[用例失敗]4b.無此帳號：ATM吞卡，[用例失敗]5a.ATM無鈔票：ATM不顯示“取款”功能，客戶可選取其她服務(wù)，[用例失敗]6a.取款額超過ATM鈔票余額：ATM規(guī)定客戶重新輸入取款額。7a.帳戶余額局限性：ATM規(guī)定客戶重新輸入取款額。7b.取款額超過當(dāng)天最高限額：ATM規(guī)定客戶重新輸入取款額。7c.網(wǎng)絡(luò)或銀行主機(jī)失效、通訊超時：ATM記錄服務(wù)取消，打印憑條，吐出憑條和銀行卡，[用例失敗]8a.憑條打印失敗，紙用完或卡紙：8a1.ATM告知銀行主機(jī)取消取款8a2.ATM記錄服務(wù)取消，吐出銀行卡，[用例失敗]9a.吐鈔票失敗：9a1.ATM告知銀行主機(jī)取消取款9a2.ATM記錄服務(wù)取消，吐出銀行卡，[用例失敗]11a.客戶未及時取走卡：ATM吞卡，[用例失敗]業(yè)務(wù)規(guī)則：7b單日取款不得超過5000元6c每次取款不得超過元為什么大量軟件開發(fā)人員沒有足夠注重需求工程？此前有無什么狀況讓你可以跳過需求工程？一方面軟件開發(fā)人員以為客戶已經(jīng)把需求說清晰了，但是大多數(shù)狀況初步需求都是模糊。另一方面工程進(jìn)度規(guī)定很急迫，軟件開發(fā)人員迫切但愿投入到代碼編寫階段。最后和客戶溝通比較困難，使得大多數(shù)軟件開發(fā)人員不注重需求工程。又一次，項(xiàng)目時間很短，規(guī)定一種月完畢，咱們只是大體上對需求有一種結(jié)識，就跳過需求工程開始動手編碼，成果固然失敗了。簡短地討論一種分析模型每個元素，指出每個元素對模型貢獻(xiàn)，每個元素為什么是唯一以及每個元素所示概要信息。分析模型元素基于場景元素(用例圖)：使用基于場景辦法可以從顧客視角描述系統(tǒng)。例如基本用例和基于模板用例。普通分析模型第一步，作為創(chuàng)立其她模型輸入?；陬愒兀悎D）:每個使用場景都暗示著當(dāng)一種參加者與系統(tǒng)交互時所操做一組對象，這些對象被提成類——具備相似屬性和共同行為事務(wù)集合。行為元素(狀態(tài)圖)：狀態(tài)指明了在某個特殊事件后采用什么動作。面向信息流模式：描述信息轉(zhuǎn)換。第7章構(gòu)建分析模型重點(diǎn)：簡樸用幾句話嘗試闡明構(gòu)造化分析和面向?qū)ο蠓治鲋匾顒e？構(gòu)造化分析考慮數(shù)據(jù)和解決，其中數(shù)據(jù)作為獨(dú)立實(shí)體轉(zhuǎn)換，數(shù)據(jù)對象建模定義了對象屬性和關(guān)系，操作對象解決建模應(yīng)當(dāng)表白數(shù)據(jù)對象在系統(tǒng)內(nèi)流動時解決如何轉(zhuǎn)換數(shù)據(jù)。面向?qū)ο蠓治鲫P(guān)注于定義類和影響客戶需求類之間協(xié)作方式。有無也許在分析模型創(chuàng)立后及時開始編碼？解釋你答案，然后說服反方。設(shè)計(jì)工程重點(diǎn)：如果軟件設(shè)計(jì)不是程序（它擬定不是），那么它是什么？是一套結(jié)實(shí)、合用和賞心悅目模型或設(shè)計(jì)表達(dá)。它涉及數(shù)據(jù)、類設(shè)計(jì)，體系構(gòu)造設(shè)計(jì)、接口設(shè)計(jì)、構(gòu)件設(shè)計(jì)。當(dāng)你“編寫”程序時你設(shè)計(jì)軟件嗎？軟件設(shè)計(jì)和編碼有什么不同嗎？設(shè)計(jì)。軟件設(shè)計(jì)是逐漸細(xì)化一種可以工作模型，而編碼是在生成一種可執(zhí)行程序。軟件設(shè)計(jì)重要關(guān)注與否實(shí)現(xiàn)了顧客需求，必要從實(shí)現(xiàn)角度闡明數(shù)據(jù)域、功能域和行為域，是編碼工作指引。用你自己話闡明軟件體系構(gòu)造。系統(tǒng)構(gòu)造是程序構(gòu)件（模塊）構(gòu)造或組織，這些構(gòu)件交互形式以及這些構(gòu)件因此數(shù)據(jù)構(gòu)造。構(gòu)件可以被推廣，用于代表重要系統(tǒng)元素及其交互。進(jìn)行體系構(gòu)造設(shè)計(jì)體系構(gòu)造風(fēng)格分類以數(shù)據(jù)為中心體系構(gòu)造數(shù)據(jù)流體系構(gòu)造：當(dāng)輸入數(shù)據(jù)通過一系列計(jì)算和操作構(gòu)件變換形成輸出數(shù)據(jù)時，可以應(yīng)用這種體系構(gòu)造。信息流被描述為單個數(shù)據(jù)項(xiàng)，被稱為事務(wù)，她可以沿多條途徑中一條觸發(fā)其她數(shù)據(jù)流。調(diào)用和返回體系構(gòu)造面向?qū)ο篌w系構(gòu)造層次體系構(gòu)造重點(diǎn)：使用數(shù)據(jù)流程圖和解決論述，描述一種具備明顯數(shù)據(jù)流特性和一種具備明顯事務(wù)流特性計(jì)算機(jī)系統(tǒng)。數(shù)據(jù)流特性：opengl管線事務(wù)流特性：銀行轉(zhuǎn)賬以房子或建筑體系構(gòu)造作比喻，與軟件體系構(gòu)造進(jìn)行對比。老式建筑體系構(gòu)造學(xué)科和軟件體系構(gòu)造有何相似之處？有何不同之處？構(gòu)件級設(shè)計(jì)建模構(gòu)件：系統(tǒng)中某一定型化、可配備和可替代部件，該部件封裝并暴露了某些列接口。內(nèi)聚性：內(nèi)聚性cohesion意味著構(gòu)件或者類只封裝那些互有關(guān)聯(lián)密切，以及與構(gòu)件或類自身有密切關(guān)系屬性和操作。耦合性：類之間彼此聯(lián)系限度一種定性度量完畢顧客界面設(shè)計(jì)黃金規(guī)則置顧客于控制之下；以不逼迫顧客進(jìn)入不必要或不但愿動作方式來定義交互模式。提供靈活度交互。容許顧客交互被中斷和撤銷。當(dāng)技能級別增長時可以使交互流線化并容許定制交互。使顧客與內(nèi)部技術(shù)細(xì)節(jié)隔離開來。設(shè)計(jì)容許顧客與出當(dāng)前屏幕上對象直接交互。減少顧客記憶承擔(dān)；減少對短期記憶規(guī)定。建立故意義缺省。定義直觀快捷方式。界面視覺布局應(yīng)當(dāng)基于真實(shí)世界象征。以不斷進(jìn)展方式揭示信息。保持界面一致性。容許顧客將當(dāng)前任務(wù)放入故意義環(huán)境中。在應(yīng)用系統(tǒng)家族內(nèi)保持一致性。如果過去交互模型已經(jīng)建立起了顧客盼望，除非有不得已理由，否則不要變化它。重點(diǎn)：試給出兩個附加“減少顧客記憶承擔(dān)”、“保持界面一致性”設(shè)計(jì)原則。假設(shè)你被邀請開發(fā)一種基于WEB家庭銀行系統(tǒng)。請給出顧客模型、設(shè)計(jì)模型、心理模型和實(shí)現(xiàn)模型。軟件測試方略軟件測試需要籌劃和執(zhí)行一系列測試環(huán)節(jié)單元測試集成測試確認(rèn)測試系統(tǒng)測試重點(diǎn)：用自己話描述驗(yàn)證與確認(rèn)不同。兩者都要使用測試用例設(shè)計(jì)辦法和測試方略嗎？驗(yàn)證是保證軟件正的確現(xiàn)某一特定功能某些列活動；確認(rèn)是指保證開發(fā)軟件可追溯到顧客需求此外一系列活動。都需要。