軟件測(cè)試基本概念

軟件測(cè)試基本概念1第1頁(yè)，課件共46頁(yè)，創(chuàng)作于2023年2月第1章回顧1.1軟件的含義1.2軟件開(kāi)發(fā)過(guò)程模型1.3UML代表著軟件建模的發(fā)展趨勢(shì)1.4軟件測(cè)試的重要性2第2頁(yè)，課件共46頁(yè)，創(chuàng)作于2023年2月第2章軟件測(cè)試的基本概念2.1軟件缺陷2.2驗(yàn)證和確認(rèn)2.3軟件測(cè)試的分類2.4測(cè)試模型2.5軟件測(cè)試的工作范疇3第3頁(yè)，課件共46頁(yè)，創(chuàng)作于2023年2月缺陷是質(zhì)量的對(duì)立面要了解什么是缺陷(defect)，就必須清楚“質(zhì)量(Quality)”概念，因?yàn)槿毕菔窍鄬?duì)質(zhì)量而存在的，違背了質(zhì)量、違背了客戶的意愿，不能滿足客戶的要求，就會(huì)引起缺陷或產(chǎn)生缺陷。4第4頁(yè)，課件共46頁(yè)，創(chuàng)作于2023年2月2.1軟件缺陷2.1.1軟件質(zhì)量的內(nèi)涵2.1.2軟件缺陷的定義2.1.3軟件缺陷的產(chǎn)生2.1.4軟件缺陷的構(gòu)成2.1.5修復(fù)軟件缺陷的代價(jià)5第5頁(yè)，課件共46頁(yè)，創(chuàng)作于2023年2月軟件質(zhì)量

的內(nèi)涵1質(zhì)量(Quality)的概念在RUP(“Rational標(biāo)準(zhǔn)過(guò)程”理論)中，質(zhì)量被定義為：滿足或超出認(rèn)定的一組需求，并使用經(jīng)過(guò)認(rèn)可的評(píng)測(cè)方法和標(biāo)準(zhǔn)來(lái)評(píng)估，還使用認(rèn)定的流程來(lái)生產(chǎn)。RUP：RationalUnifiedProcess6第6頁(yè)，課件共46頁(yè)，創(chuàng)作于2023年2月軟件質(zhì)量

的內(nèi)涵2軟件質(zhì)量的內(nèi)涵總結(jié)說(shuō)來(lái)，高品質(zhì)軟件應(yīng)該是相對(duì)的無(wú)產(chǎn)品缺陷(bugfree)或只有極少量的缺陷，它能夠及時(shí)遞交給客戶，所花費(fèi)用都在預(yù)算內(nèi)，并且滿足客戶需求，是可維護(hù)的。但是，有關(guān)質(zhì)量好壞的最終評(píng)價(jià)依賴于用戶的反饋。7第7頁(yè)，課件共46頁(yè)，創(chuàng)作于2023年2月高質(zhì)量軟件標(biāo)準(zhǔn)體系產(chǎn)品質(zhì)量是人們實(shí)踐產(chǎn)物的屬性和行為，是可以認(rèn)識(shí)，可以科學(xué)地描述的。并且可以通過(guò)一些方法和人類活動(dòng)，來(lái)改進(jìn)質(zhì)量.質(zhì)量模型:McCall模型,Boehm模型,ISO9126模型過(guò)程質(zhì)量:

軟件能力成熟度模型

CMM(CapabilityMaturityModel).

國(guó)際標(biāo)準(zhǔn)過(guò)程模型

ISO9000

軟件過(guò)程改進(jìn)和能力決斷

SPICE(SoftwareProcessImprovementandCapabilitydEtermination)

在商業(yè)過(guò)程中有關(guān)的質(zhì)量?jī)?nèi)容:

培訓(xùn)、成品制作、宣傳、發(fā)布日起、客戶、風(fēng)險(xiǎn)、成本等

8第8頁(yè)，課件共46頁(yè)，創(chuàng)作于2023年2月產(chǎn)品質(zhì)量的標(biāo)準(zhǔn)-功能性

Functionality-可用性

Usability(簡(jiǎn)單安裝;輕松使用;友好界面)-可靠性

Reliability(用戶使用的根本)-性能

Performance-容量

Capacity-可測(cè)量性

Scalability-可維護(hù)性

Servicemanageability-兼容性

Compatibility-可擴(kuò)展性

Extensibility9第9頁(yè)，課件共46頁(yè)，創(chuàng)作于2023年2月軟件質(zhì)量特征

(ISO9126)

功能：與一組功能及其指定性質(zhì)有關(guān)的一組屬性，這里的功能是滿足明確或隱含的需求的那些功能。

可靠：在規(guī)定的一段時(shí)間和條件下，與軟件維持其性能水平的能力有關(guān)的一組屬性。

可用：由一組規(guī)定或潛在的用戶為使用軟件所需作的努力和所作的評(píng)價(jià)有關(guān)的一組屬性。

效率：與在規(guī)定條件下軟件的性能水平與所使用資源量之間關(guān)系有關(guān)的一組屬性。

可維護(hù)：與進(jìn)行指定的修改所需的努力有關(guān)的一組屬性。

可移植：與軟件從一個(gè)環(huán)境轉(zhuǎn)移到另一個(gè)環(huán)境的能力有關(guān)的一組屬性。

其中每一個(gè)質(zhì)量特征都分別與若干子特征相對(duì)應(yīng)。10第10頁(yè)，課件共46頁(yè)，創(chuàng)作于2023年2月ISO9126軟件質(zhì)量三層模型-SQRC

軟件質(zhì)量需求評(píng)價(jià)準(zhǔn)則（高層）-SQDC軟件質(zhì)量設(shè)計(jì)評(píng)價(jià)準(zhǔn)則（中層）-SQMC軟件質(zhì)量度量評(píng)價(jià)準(zhǔn)則（低層）11第11頁(yè)，課件共46頁(yè)，創(chuàng)作于2023年2月McCall軟件質(zhì)量模型互用性正確性可靠性效率完整性可用性可維護(hù)性可測(cè)試性靈活性可移植性重復(fù)性闡述性數(shù)據(jù)公開(kāi)性連貫性容錯(cuò)性執(zhí)行效率/儲(chǔ)存效率存取控制/存取檢查可訓(xùn)練溝通良好簡(jiǎn)單性易操作的工具自我操作性擴(kuò)展性一般性模塊性軟件系統(tǒng)獨(dú)立性機(jī)器獨(dú)立性通訊公開(kāi)性正確性可操作性產(chǎn)品操作產(chǎn)品修改產(chǎn)品轉(zhuǎn)換12第12頁(yè)，課件共46頁(yè)，創(chuàng)作于2023年2月什么是Bug?2.1.2軟件缺陷的定義Anyproblem/disfigurement/limitationinproductdesign&development

Featureorfunctioncan’tworkUnreasonabledesignPartlyrealizationinfunctionDataerrorRunerrorLimitationinfeaturesDifferencebetweenactualresultsandexpectedresultsUnfriendlyUI,LowperformanceOthers任何程序、系統(tǒng)中的問(wèn)題，和產(chǎn)品設(shè)計(jì)書(shū)的不一致性，不能滿足用戶的需求

13第13頁(yè)，課件共46頁(yè)，創(chuàng)作于2023年2月軟件缺陷IEEE(1983)729軟件缺陷一個(gè)標(biāo)準(zhǔn)的定義：

從產(chǎn)品內(nèi)部看，軟件缺陷是軟件產(chǎn)品開(kāi)發(fā)或維護(hù)過(guò)程中所存在的錯(cuò)誤、毛病等各種問(wèn)題；從外部看，軟件缺陷是系統(tǒng)所需要實(shí)現(xiàn)的某種功能的失效或違背。

14第14頁(yè)，課件共46頁(yè)，創(chuàng)作于2023年2月軟件開(kāi)發(fā)描述圖15第15頁(yè)，課件共46頁(yè)，創(chuàng)作于2023年2月軟件缺陷軟件錯(cuò)誤產(chǎn)生的可能原因是：需求規(guī)格說(shuō)明書(shū)包含錯(cuò)誤的需求、或漏掉一些需求，或沒(méi)有準(zhǔn)確表達(dá)客戶所需要的內(nèi)容需求規(guī)格說(shuō)明書(shū)中有些功能不可能或無(wú)法實(shí)現(xiàn)系統(tǒng)設(shè)計(jì)(systemdesign)中的不合理性程序設(shè)計(jì)中的錯(cuò)誤程序代碼中的問(wèn)題，包括錯(cuò)誤的算法、復(fù)雜的邏輯等16第16頁(yè)，課件共46頁(yè)，創(chuàng)作于2023年2月軟件缺陷軟件缺陷的主要類型/現(xiàn)象：功能、特性沒(méi)有實(shí)現(xiàn)或部分實(shí)現(xiàn)設(shè)計(jì)不合理，存在缺陷實(shí)際結(jié)果和預(yù)期結(jié)果不一致運(yùn)行出錯(cuò)，包括運(yùn)行中斷、系統(tǒng)崩潰、界面混亂數(shù)據(jù)結(jié)果不正確、精度不夠用戶不能接受的其他問(wèn)題，如存取時(shí)間過(guò)長(zhǎng)、界面不美觀17第17頁(yè)，課件共46頁(yè)，創(chuàng)作于2023年2月軟件缺陷的種類:按照嚴(yán)重性級(jí)別的定義不盡相同，但一般可以概括為4種類型：致命的(fatal)：致命的錯(cuò)誤，造成系統(tǒng)或應(yīng)用程序崩潰(crash)、死機(jī)、系統(tǒng)懸掛，或造成數(shù)據(jù)丟失、主要功能完全喪失等。嚴(yán)重的(critical)：嚴(yán)重錯(cuò)誤，指功能或特性沒(méi)有實(shí)現(xiàn)，主要功能部分喪失，次要功能完全喪失，提示信息不太準(zhǔn)確，或致命的錯(cuò)誤聲明一般的(major)：不太嚴(yán)重的錯(cuò)誤，這樣的軟件缺陷雖然不影響系統(tǒng)的基本使用，但沒(méi)有很好地實(shí)現(xiàn)功能，沒(méi)有達(dá)到預(yù)期效果。如次要功能喪失，提示信息不太準(zhǔn)確，或用戶界面差，操作時(shí)間長(zhǎng)微小的(minor)：一些小問(wèn)題，對(duì)功能幾乎沒(méi)有影響，產(chǎn)品或?qū)傩匀钥墒褂?，如有個(gè)別錯(cuò)別字、文字排列不整齊等。此外，有時(shí)還需要“建議(Suggestion)”級(jí)別來(lái)處理測(cè)試人員所提出的建議或質(zhì)疑。軟件缺陷18第18頁(yè)，課件共46頁(yè)，創(chuàng)作于2023年2月軟件缺陷的狀態(tài)軟件缺陷除了嚴(yán)重性以外，還存在反映軟件缺陷處于一種什么樣的狀態(tài)，便于跟蹤和管理某個(gè)產(chǎn)品的缺陷，可以定義不同的bug狀態(tài)：激活狀態(tài)(Active或Open)：?jiǎn)栴}沒(méi)有解決，測(cè)試人員新報(bào)的bug，或驗(yàn)證后bug依然存在已修正狀態(tài)(Fixed或Resolved)：開(kāi)發(fā)人員針對(duì)所存在的缺陷，修改程序，認(rèn)為已解決問(wèn)題，或通過(guò)單元測(cè)試關(guān)閉或非激活狀態(tài)(Close或Inactive)：測(cè)試人員驗(yàn)證fixedbug后，確認(rèn)bug不存在之后的狀態(tài)。此外，還有下面一些中間狀態(tài)：保留(Hold)：bug目前無(wú)法解決或是由第三方軟件產(chǎn)品引起的延期(Differed):bug暫時(shí)不需要解決或在下一版本中解決更徹底一些軟件缺陷19第19頁(yè)，課件共46頁(yè)，創(chuàng)作于2023年2月造成軟件缺陷產(chǎn)生的主要原因有：1.技術(shù)問(wèn)題主要包括：算法錯(cuò)誤、語(yǔ)法錯(cuò)誤、計(jì)算和精度問(wèn)題、系統(tǒng)結(jié)構(gòu)不合理、算法不科學(xué)，造成系統(tǒng)性能低下、接口參數(shù)傳遞不匹配，導(dǎo)致模塊集成出現(xiàn)問(wèn)題2.團(tuán)隊(duì)工作對(duì)客戶的需求不是十分清楚，或者和用戶的溝通存在一些困難；開(kāi)發(fā)人員相互理解不一致；設(shè)計(jì)或編程上的一些假定或依賴性，沒(méi)有得到充分的溝通3.軟件本身文檔錯(cuò)誤、用戶使用場(chǎng)合(userscenario)，時(shí)間上不協(xié)調(diào)、或不一致性所帶來(lái)的問(wèn)題。系統(tǒng)的自我恢復(fù)或數(shù)據(jù)的異地備份、災(zāi)難性恢復(fù)等問(wèn)題軟件缺陷的產(chǎn)生20第20頁(yè)，課件共46頁(yè)，創(chuàng)作于2023年2月軟件缺陷構(gòu)成

21第21頁(yè)，課件共46頁(yè)，創(chuàng)作于2023年2月軟件缺陷在不同階段的分布在真正的程序測(cè)試之前，通過(guò)審查、評(píng)審會(huì)可以發(fā)現(xiàn)更多的缺陷。規(guī)格說(shuō)明書(shū)的缺陷會(huì)在需求分析審查、設(shè)計(jì)、編碼、測(cè)試等過(guò)程中會(huì)逐步發(fā)現(xiàn)，而不能在需求分析一個(gè)階段發(fā)現(xiàn)22第22頁(yè)，課件共46頁(yè)，創(chuàng)作于2023年2月缺陷成本軟件缺陷的發(fā)現(xiàn)隨著時(shí)間的推移帶來(lái)的成本越來(lái)越大。23第23頁(yè)，課件共46頁(yè)，創(chuàng)作于2023年2月2.2驗(yàn)證和確認(rèn)2.2.1驗(yàn)證和確認(rèn)2.2.2評(píng)審2.2.3質(zhì)量保證和測(cè)試的關(guān)系24第24頁(yè)，課件共46頁(yè)，創(chuàng)作于2023年2月驗(yàn)證和確認(rèn)（V&V）

Verification：Arewebuildingtheproductright？是否正確地構(gòu)造了軟件？即是否正確地做事，驗(yàn)證開(kāi)發(fā)過(guò)程是否遵守已定義好的內(nèi)容。驗(yàn)證產(chǎn)品滿足規(guī)格設(shè)計(jì)說(shuō)明書(shū)的一致性Validation：Arewebuildingtherightproduct?

是否構(gòu)造了正是用戶所需要的軟件？即是否正在做正確的事。驗(yàn)證產(chǎn)品所實(shí)現(xiàn)的功能是否滿足用戶的需求25第25頁(yè)，課件共46頁(yè)，創(chuàng)作于2023年2月評(píng)審?fù)ㄟ^(guò)軟件評(píng)審，可以更早地發(fā)現(xiàn)需求工程、軟件設(shè)計(jì)等各個(gè)方面的問(wèn)題，大大減少大量的后期返工，將質(zhì)量成本從昂貴的后期返工轉(zhuǎn)化為前期的缺陷發(fā)現(xiàn)。評(píng)審是對(duì)軟件元素或者項(xiàng)目狀態(tài)的一種評(píng)估手段，以確定其是否與計(jì)劃的結(jié)果保持一致，并使其得到改進(jìn)。檢驗(yàn)工作產(chǎn)品是否正確地滿足了以往工作產(chǎn)品中建立的規(guī)范。軟件評(píng)審是軟件測(cè)試的組成部分。26第26頁(yè)，課件共46頁(yè)，創(chuàng)作于2023年2月評(píng)審分類管理評(píng)審技術(shù)評(píng)審文檔評(píng)審流程評(píng)審27第27頁(yè)，課件共46頁(yè)，創(chuàng)作于2023年2月什么是SQA?軟件質(zhì)量保證是通過(guò)對(duì)軟件產(chǎn)品和活動(dòng)有計(jì)劃的進(jìn)行評(píng)審和審計(jì)來(lái)驗(yàn)證軟件是否合乎標(biāo)準(zhǔn)的系統(tǒng)工程活動(dòng).

確保SQA活動(dòng)要自始至有計(jì)劃的進(jìn)行審查軟件產(chǎn)品和活動(dòng)是否遵守適用的標(biāo)準(zhǔn)、規(guī)程和要求并得到客觀驗(yàn)證。SQA的活動(dòng)和結(jié)果要保證全員參與，溝通順暢。逐級(jí)解決不符合問(wèn)題28第28頁(yè)，課件共46頁(yè)，創(chuàng)作于2023年2月SQA與軟件測(cè)試有什么關(guān)系和區(qū)別？

29第29頁(yè)，課件共46頁(yè)，創(chuàng)作于2023年2月SQA與軟件測(cè)試的關(guān)系SQA是管理工作、審查對(duì)象是流程、強(qiáng)調(diào)以預(yù)防為主測(cè)試是技術(shù)工作、測(cè)試對(duì)象是產(chǎn)品、主要是以事后檢查SQA指導(dǎo)測(cè)試、監(jiān)控測(cè)試測(cè)試為SQA提供依據(jù)30第30頁(yè)，課件共46頁(yè)，創(chuàng)作于2023年2月2.3軟件測(cè)試的分類方法目標(biāo)/特性單元測(cè)試系統(tǒng)測(cè)試驗(yàn)收測(cè)試性能測(cè)試強(qiáng)壯性測(cè)試功能測(cè)試白盒測(cè)試黑盒測(cè)試測(cè)試階段或?qū)哟芜m用性測(cè)試可靠性測(cè)試集成測(cè)試安全性測(cè)試31第31頁(yè)，課件共46頁(yè)，創(chuàng)作于2023年2月不同的分類按測(cè)試的對(duì)象或范圍分類，如單元測(cè)試、文檔測(cè)試、系統(tǒng)測(cè)試等）按測(cè)試目的分類，如功能測(cè)試、回歸測(cè)試、性能測(cè)試、可靠性測(cè)試、安全性測(cè)試和兼容性測(cè)試等根據(jù)測(cè)試過(guò)程中被測(cè)軟件是否被執(zhí)行，分為靜態(tài)測(cè)試和動(dòng)態(tài)測(cè)試根據(jù)是否針對(duì)系統(tǒng)的內(nèi)部結(jié)構(gòu)和具體實(shí)現(xiàn)算法來(lái)完成測(cè)試，可分為白盒測(cè)試和黑盒測(cè)試32第32頁(yè)，課件共46頁(yè)，創(chuàng)作于2023年2月2.4.1軟件測(cè)試模型：V模型33第33頁(yè)，課件共46頁(yè)，創(chuàng)作于2023年2月2.4.2軟件測(cè)試模型：X模型34第34頁(yè)，課件共46頁(yè)，創(chuàng)作于2023年2月2.5軟件測(cè)試的工作范疇軟件測(cè)試工作的組織與管理：制定測(cè)試策略、測(cè)試計(jì)劃，確認(rèn)所采用的測(cè)試方法與規(guī)范，控制測(cè)試進(jìn)度，管理測(cè)試資源。測(cè)試工作的實(shí)施：編制符合標(biāo)準(zhǔn)的測(cè)試文檔，搭建測(cè)試環(huán)境，開(kāi)發(fā)測(cè)試腳本、與開(kāi)發(fā)組織協(xié)作實(shí)現(xiàn)各階段的測(cè)試活動(dòng)。35第35頁(yè)，課件共46頁(yè)，創(chuàng)作于2023年2月測(cè)試工作流程36第36頁(yè)，課件共46頁(yè)，創(chuàng)作于2023年2月2.5.1測(cè)試計(jì)劃制定在測(cè)試計(jì)劃中，主要包括以下內(nèi)容：1.制定測(cè)試策略制定測(cè)試策略主要分析測(cè)試的目標(biāo)和指標(biāo)，確定測(cè)試的對(duì)象和依據(jù)，明確測(cè)試的重點(diǎn)和采用的方法2.確定測(cè)試范圍測(cè)試主要依據(jù)“產(chǎn)品設(shè)計(jì)規(guī)格說(shuō)明書(shū)”，根據(jù)產(chǎn)品的新特性或功能修改需求所做的代碼變化，以及這種變化可能引起的問(wèn)題或給其他模塊造成的影響。3.所需資源和日程安排資源包括計(jì)算機(jī)硬件、軟件和人力資源。在進(jìn)行資源安排時(shí)，更重要的是設(shè)置不同的角色，清楚地定義每個(gè)人的工作內(nèi)容和責(zé)任。對(duì)于日程安排，主要是設(shè)置整個(gè)測(cè)試周期的項(xiàng)目進(jìn)程。為了合理、準(zhǔn)確地安排日程，對(duì)測(cè)試工作量要進(jìn)行正確的估計(jì)。37第37頁(yè)，課件共46頁(yè)，創(chuàng)作于2023年2月2.5.2設(shè)計(jì)測(cè)試用例在單元測(cè)試階段，主要用白盒測(cè)試方法設(shè)計(jì)測(cè)試用例；在功能測(cè)試階段，主要用黑盒測(cè)試方法來(lái)設(shè)計(jì)測(cè)試用例。測(cè)試用例定義了為執(zhí)行測(cè)試所需要的條件或環(huán)境、輸入或操作步驟，以及所期望的結(jié)果。測(cè)試環(huán)境是測(cè)試的基礎(chǔ)。要盡量模擬軟件系統(tǒng)實(shí)際應(yīng)用的環(huán)境。輸入值。除了正常的輸入值，關(guān)鍵是需要尋找哪些是屬于邊界條件的輸入值和正常輸入值。期望結(jié)果或標(biāo)準(zhǔn)。是根據(jù)系統(tǒng)設(shè)計(jì)規(guī)格說(shuō)明書(shū)來(lái)確定的輸出結(jié)果、標(biāo)準(zhǔn)。有時(shí)是由經(jīng)驗(yàn)作出正確判斷、理解所確定。38第38頁(yè)，課件共46頁(yè)，創(chuàng)作于2023年2月2.5.3執(zhí)行測(cè)試執(zhí)行測(cè)試主要有下列一些活動(dòng)：建立必要的測(cè)試環(huán)境按照所寫(xiě)的測(cè)試用例，編寫(xiě)測(cè)試腳本根據(jù)測(cè)試對(duì)象和目的，構(gòu)造測(cè)試用例的集合運(yùn)行測(cè)試腳本或手工按測(cè)試用例進(jìn)行記錄測(cè)試結(jié)果結(jié)果比較分析，找出軟件缺陷將軟件缺陷記錄到缺陷數(shù)據(jù)庫(kù)中，清楚地描述該缺陷跟蹤和管理軟件缺陷驗(yàn)證被處理的軟件缺陷，并進(jìn)行回歸測(cè)試對(duì)測(cè)試過(guò)程進(jìn)行管理，保證測(cè)試工作執(zhí)行的正確性，實(shí)現(xiàn)資源調(diào)撥和相關(guān)合作方的協(xié)調(diào)。對(duì)測(cè)試中的問(wèn)題進(jìn)行全程跟蹤39第39頁(yè)，課件共46頁(yè)，創(chuàng)作于2023年2月2.5.4測(cè)試結(jié)果分析和質(zhì)量報(bào)告一個(gè)好的測(cè)試報(bào)告建立在測(cè)試結(jié)果的基礎(chǔ)之上，不僅要提供必要測(cè)試結(jié)果的實(shí)際數(shù)據(jù)，同時(shí)要對(duì)結(jié)果進(jìn)行分析，發(fā)現(xiàn)產(chǎn)品中問(wèn)題的本質(zhì)，對(duì)產(chǎn)品質(zhì)量進(jìn)行準(zhǔn)確的評(píng)估。分析的對(duì)象和內(nèi)容是：測(cè)試的覆蓋率bug分析產(chǎn)品總體質(zhì)量分析40第40頁(yè)，課件共46頁(yè)，創(chuàng)作于2023年2月習(xí)題1．單元測(cè)試是以

a說(shuō)明書(shū)為指導(dǎo)，測(cè)試源程序代碼；集成測(cè)試以

b說(shuō)明書(shū)為指導(dǎo)，測(cè)試軟件結(jié)構(gòu)；確認(rèn)測(cè)試以

c說(shuō)明書(shū)為指導(dǎo)。a.詳細(xì)設(shè)計(jì)b.概要設(shè)計(jì)c.需求分析2．軟件是包括

a、

b、

c、

d的完整集合。a.程序b.文檔c.數(shù)據(jù)d.服務(wù)填空題：3．動(dòng)態(tài)測(cè)試分為

a即功能測(cè)試，和

b即結(jié)構(gòu)測(cè)試。

a.黑盒測(cè)試b.白盒測(cè)試41第41頁(yè)，課件共46頁(yè)，創(chuàng)作于2023年2月習(xí)題1．測(cè)試是為了驗(yàn)證軟件正確地實(shí)現(xiàn)了用戶需求。2．確認(rèn)測(cè)試主要測(cè)試軟件功能是否滿足用戶的合理需求，以“需求規(guī)格說(shuō)明書(shū)”為測(cè)試依據(jù)。判斷題：3．如果發(fā)布的軟件有質(zhì)量問(wèn)題，那是軟件測(cè)試人員的錯(cuò)。4.設(shè)計(jì)－實(shí)現(xiàn)－測(cè)試，軟件測(cè)試是開(kāi)發(fā)后期的一個(gè)階段。對(duì)錯(cuò)錯(cuò)錯(cuò)42第42頁(yè)，課件共46頁(yè)，創(chuàng)