第2章軟件測(cè)試的策略與過程-課件

1、第二章 軟件測(cè)試策略與過程1第2章 軟件測(cè)試策略與過程2.1 軟件測(cè)試的復(fù)雜性分析2.2 排除軟件缺陷的手段2.3 軟件測(cè)試方法與策略2.4 單元測(cè)試2.5 集成測(cè)試2.6 確認(rèn)測(cè)試2.7 系統(tǒng)測(cè)試2.8 驗(yàn)收測(cè)試2.9 測(cè)試后的調(diào)試2.10 面向?qū)ο蟮能浖y(cè)試2本章教學(xué)目標(biāo)理解軟件測(cè)試的復(fù)雜性理解軟件測(cè)試的方法與策略明確單元測(cè)試的主要任務(wù)和過程明確集成測(cè)試的方法和確認(rèn)測(cè)試的準(zhǔn)則明確系統(tǒng)測(cè)試的八個(gè)領(lǐng)域測(cè)試要點(diǎn)明確驗(yàn)收測(cè)試的主要內(nèi)容和相關(guān)配置32.1 軟件測(cè)試的復(fù)雜性分析1、無法對(duì)程序進(jìn)行完全測(cè)試 （1）測(cè)試所需要的輸入量太大 （2）測(cè)試的輸出結(jié)果太多 （3）軟件實(shí)現(xiàn)的途徑太多 （4）軟件規(guī)格說

2、明沒有一個(gè)客觀標(biāo)準(zhǔn)2、測(cè)試無法顯示潛在的軟件缺陷和故障 通過軟件測(cè)試只能報(bào)告軟件已被發(fā)現(xiàn)的缺陷和故障，無法報(bào)告隱藏的軟件故障。3、存在的故障現(xiàn)象與發(fā)現(xiàn)的故障數(shù)量成正比 結(jié)論：應(yīng)當(dāng)對(duì)故障集中的程序段進(jìn)行重點(diǎn)測(cè)試4M1D1D2D3D4M2M3M4M5M6M7D5=20次循環(huán)次數(shù)01220獨(dú)立路徑數(shù)51+52+53+5211014(1百萬億)每個(gè)測(cè)試用例（考慮、執(zhí)行、驗(yàn)證結(jié)果）5分鐘共需測(cè)試時(shí)間10億年無法進(jìn)行完全測(cè)試的例子-15無法進(jìn)行完全測(cè)試的例子-2程序PXYZ若X、Y為所有可能的整數(shù) 在字長32位機(jī)上測(cè)試X1、Y1 Z1 Xn、Yn Znn = 232232 = 264 1.84 10196

3、軟件測(cè)試的復(fù)雜性分析（續(xù)） 4、不能修復(fù)所有的軟件故障 原因：沒有足夠的進(jìn)行修復(fù)；修復(fù)的風(fēng)險(xiǎn)較大；不值得修復(fù);可不算做故障的一些缺陷；“殺蟲劑現(xiàn)象”。 結(jié)論：關(guān)鍵是要進(jìn)行正確的判斷、合理的取舍，根據(jù)風(fēng)險(xiǎn)分析決定哪些故障必須修復(fù)，哪些故障可以不修復(fù)。 5、軟件測(cè)試的代價(jià) 工作原則：就是如何將無邊無際的可能性減小到一個(gè)可以控制的范圍，以及如何針對(duì)軟件風(fēng)險(xiǎn)做出恰當(dāng)選擇，去粗存精，找到最佳的測(cè)試量，使得測(cè)試工作量不多也不少，既能達(dá)到測(cè)試的目的，又能較為經(jīng)濟(jì)。 7軟件測(cè)試的復(fù)雜性分析（續(xù)）軟件缺陷故障數(shù)量測(cè)試工作量測(cè)試中測(cè)試后測(cè)試費(fèi)用遺漏缺陷數(shù)目優(yōu)化測(cè)試量圖2-1 測(cè)試工作量和軟件缺陷數(shù)量之間的關(guān)系82

4、.2 排除軟件缺陷的手段軟件測(cè)試軟件項(xiàng)目評(píng)審9軟件測(cè)試軟件測(cè)試 測(cè)試在軟件開發(fā)中占有重要地位 測(cè)試成本占總開發(fā)成本的近一半10軟件開發(fā)成本分布軟件類型開發(fā)成本按階段分布%需求與設(shè)計(jì)實(shí)現(xiàn)測(cè)試控制軟件462034航空航天軟件342046操作系統(tǒng)331750科技計(jì)算軟件442630商業(yè)應(yīng)用軟件44282811測(cè)試人員所占比例12實(shí)際產(chǎn)品中的情況TeamExchange 2000Windows 2000Program Manager25About 250Developer140About 1700Tester350About 3200Tester / Dev2.5About 1.913需求分析設(shè)計(jì)走查

5、概要設(shè)計(jì)設(shè)計(jì)評(píng)審詳細(xì)設(shè)計(jì)編碼代碼走查單元測(cè)試集成測(cè)試確認(rèn)測(cè)試測(cè)試評(píng)審需求評(píng)審單元測(cè)試計(jì)劃軟件項(xiàng)目評(píng)審回歸測(cè)試系統(tǒng)測(cè)試14 T：測(cè)試 R：評(píng)審UT：單元測(cè)試 IT：集成測(cè)試ST：系統(tǒng)測(cè)試AT：驗(yàn)收測(cè)試引入消除傳遞RRRR需求設(shè)計(jì)編程測(cè) 試UTITATSTR運(yùn)行/維護(hù)T軟件生存期中缺陷的引入、傳遞與消除15缺陷跟蹤16缺陷的狀態(tài)MicrosoftFixedDuplicatedPostponedBy designNot reproWont fixAthens Olympic Games SystemOpenIn AnalysisAcceptedRejectedFixedDeliveredPendin

6、gClosedReopenedUnresolved17根據(jù)微軟的經(jīng)驗(yàn)，每修復(fù)三到四個(gè)Bug一般就會(huì)產(chǎn)生一個(gè)新的Bug。18測(cè)試對(duì)象程序測(cè)試：發(fā)現(xiàn)程序中的缺陷測(cè)試數(shù)據(jù)程序P比較結(jié)果數(shù)據(jù)預(yù)期數(shù)據(jù)相符不符追查缺陷19測(cè)試對(duì)象文檔測(cè)試：發(fā)現(xiàn)文檔中存在的各種錯(cuò)誤，以及各種文檔之間的邏輯不一致性等需求規(guī)格說明設(shè)計(jì)說明（概要與詳細(xì)）程序（代碼走查，編寫的代碼是否符合既定的規(guī)范和標(biāo)準(zhǔn)等，不是指可執(zhí)行的二進(jìn)制代碼）測(cè)試用例、測(cè)試計(jì)劃、測(cè)試結(jié)果報(bào)告用戶手冊(cè)、安裝/配置手冊(cè)、幫助文檔等其他樣本/范例，錯(cuò)誤提示信息和產(chǎn)品支持信息等所有與軟件產(chǎn)品有關(guān)聯(lián)的部分都可成為被測(cè)試的對(duì)象！20測(cè)試計(jì)劃測(cè)試用例測(cè)試程序測(cè)試建立可靠

7、性模型排錯(cuò)評(píng)估測(cè)試結(jié)果預(yù)期結(jié)果修正的軟件可靠性模型軟件配置測(cè)試配置測(cè)試工具測(cè)試結(jié)果錯(cuò)誤出錯(cuò)率回歸測(cè)試軟件測(cè)試信息流21為什么要實(shí)施測(cè)試評(píng)審PPlan 計(jì)劃 DDo 實(shí)施CCheck 檢驗(yàn)、審查AAction 措施、行動(dòng) 軟件開發(fā)中： PSDP 軟件開發(fā)計(jì)劃 SRS 軟件需求規(guī)格說明 D軟件設(shè)計(jì)、實(shí)現(xiàn)、編程 C軟件測(cè)試、軟件評(píng)審 A解決測(cè)試和評(píng)審中發(fā)現(xiàn)的問題回答：測(cè)試是否按計(jì)劃實(shí)施 測(cè)試是否充分而有效地檢驗(yàn)了功能、性能和使用要求體現(xiàn)PDCA循環(huán)APCD22APCDAPCDTestingP：制定測(cè)試計(jì)劃D：執(zhí)行測(cè)試C：測(cè)試評(píng)審A：解決測(cè)試評(píng)審發(fā)現(xiàn)的問題軟件開發(fā)軟件測(cè)試測(cè)試計(jì)劃與測(cè)試評(píng)審的關(guān)系23需

8、求分析概要設(shè)計(jì)詳細(xì)設(shè)計(jì)編碼單元測(cè)試集成測(cè)試確認(rèn)測(cè)試系統(tǒng)測(cè)試決定軟件與系統(tǒng)的配合關(guān)系測(cè)試與開發(fā)前期工作的關(guān)系24發(fā)現(xiàn)的錯(cuò)誤數(shù)周周總?cè)毕輸?shù)目不同階段的缺陷數(shù)目測(cè)試查錯(cuò)曲線25生存期各階段V、V&T活動(dòng)系統(tǒng)測(cè)試分析設(shè)計(jì)編碼維護(hù)安裝測(cè)試單元測(cè)試驗(yàn)證確認(rèn)系統(tǒng)測(cè)試 質(zhì)量控制集成測(cè)試回歸測(cè)試驗(yàn)收測(cè)試Do the thing rightDo the right thing26需求分析階段制定本項(xiàng)目的VV&T計(jì)劃設(shè)置基于需求的測(cè)試用例對(duì)需求進(jìn)行評(píng)審與分析對(duì)用戶手冊(cè)初稿進(jìn)行評(píng)審與分析概要設(shè)計(jì)階段修訂VV&T計(jì)劃制定基于設(shè)計(jì)的測(cè)試步驟對(duì)概要設(shè)計(jì)進(jìn)行評(píng)審與分析詳細(xì)設(shè)計(jì)階段設(shè)置基于設(shè)計(jì)的功能測(cè)試數(shù)據(jù)對(duì)詳細(xì)設(shè)計(jì)進(jìn)行評(píng)審與

9、分析軟件生存期各階段的VV&T活動(dòng)27程序編寫和單元測(cè)試完成測(cè)試用例說明書進(jìn)行單元測(cè)試進(jìn)行集成測(cè)試安裝進(jìn)行系統(tǒng)測(cè)試進(jìn)行驗(yàn)收測(cè)試運(yùn)行和維護(hù)階段軟件評(píng)價(jià)軟件修改評(píng)價(jià)回歸測(cè)試（引自美國國家標(biāo)準(zhǔn)局信息處理標(biāo)準(zhǔn)FIPS PUB101）軟件生存期各階段的VV&T活動(dòng)(續(xù))28如何正確對(duì)待測(cè)試工作明確測(cè)試工作意義加強(qiáng)責(zé)任心，疏忽可能造成惡果學(xué)習(xí)實(shí)踐鉆研，積累經(jīng)驗(yàn)，努力提高業(yè)務(wù)水平處理好與編程人員關(guān)系29測(cè)試工作評(píng)估問題你單位是否有專人負(fù)責(zé)測(cè)試工作？你們是否有、是否用測(cè)試計(jì)劃規(guī)范？你們是否有、是否用單元測(cè)試規(guī)程？你們是否有、是否用測(cè)試報(bào)告規(guī)范？測(cè)試過程（包括計(jì)劃和實(shí)施）與整個(gè)開發(fā)過程是否并行開展？（測(cè)試在開發(fā)

10、初期著手，在開發(fā)結(jié)束完成）測(cè)試能夠確認(rèn)規(guī)格說明得到正確的實(shí)現(xiàn)嗎？除規(guī)格說明以外，你能否確認(rèn)用戶的期望也能滿足嗎？測(cè)試人員能驗(yàn)證開發(fā)的階段（如需求和設(shè)計(jì)）的精確性和完全性嗎？測(cè)試人員向開發(fā)人員報(bào)告缺陷以期進(jìn)一步采取措施嗎？在制定計(jì)劃之前測(cè)試人員能估計(jì)業(yè)務(wù)風(fēng)險(xiǎn)嗎？30測(cè)試工作評(píng)估問題(續(xù))針對(duì)被測(cè)軟件是否提出了可度量的測(cè)試目標(biāo)？如已提出，它與商業(yè)風(fēng)險(xiǎn)有關(guān)嗎？測(cè)試中發(fā)現(xiàn)的缺陷是否做了紀(jì)錄和總結(jié)，使其用于改進(jìn)開發(fā)過程和測(cè)試過程？測(cè)試人員是否根據(jù)以前的工作經(jīng)驗(yàn)判斷可能的缺陷？是否有改進(jìn)測(cè)試過程的辦法？你為缺陷命名嗎？是否利用缺陷記錄、總結(jié)和事故數(shù)據(jù)來評(píng)價(jià)測(cè)試過程的有效性？是否采用度量（如千行代碼缺陷數(shù)）

11、來計(jì)劃和評(píng)價(jià)測(cè)試過程？是否已建立了測(cè)試人員的培訓(xùn)制度？采用測(cè)試工具來支持測(cè)試過程嗎？31不同等級(jí)的測(cè)試機(jī)構(gòu)等級(jí)否個(gè)數(shù)狀 態(tài)特 點(diǎn)117-20把測(cè)試工作當(dāng)作藝術(shù)(art)測(cè)試依賴于測(cè)試人員個(gè)人的技巧和創(chuàng)造性對(duì)測(cè)試人員無指導(dǎo)，無要求測(cè)試工作效果不穩(wěn)定，有時(shí)好，有時(shí)糟顧客和用戶不能靠測(cè)試的有效性判斷質(zhì)量213-16把測(cè)試工作當(dāng)作技藝(craft)有測(cè)試過程、規(guī)范、標(biāo)準(zhǔn)和測(cè)試計(jì)劃測(cè)試計(jì)劃得不到實(shí)施測(cè)試人員只熱衷于找缺陷，報(bào)告開發(fā)人員用戶不信任測(cè)試過程，只好做驗(yàn)收測(cè)試39-12執(zhí)行已確切定義的測(cè)試過程測(cè)試過程已被定義，單位但未得到有效執(zhí)行測(cè)試工作針對(duì)規(guī)格說明，重視問題的需求測(cè)試結(jié)束時(shí)沒有提供表明被測(cè)軟件

12、能否投入使用的正式報(bào)告32不同等級(jí)的測(cè)試機(jī)構(gòu)45-8先進(jìn)的測(cè)試機(jī)構(gòu)有明確的測(cè)試目標(biāo)，可優(yōu)化利用測(cè)試資源實(shí)現(xiàn)目標(biāo)重視測(cè)試過程薄弱環(huán)節(jié)的改進(jìn)50-4最先進(jìn)的測(cè)試機(jī)構(gòu)測(cè)試工作基于降低風(fēng)險(xiǎn)，測(cè)試人員工作有效測(cè)試得到度量，過程得到很好定義缺陷得到記錄、分析和總結(jié)，且用其改進(jìn)過程測(cè)試成本顯著下降顧客和用戶相信測(cè)試過程，不依靠驗(yàn)收測(cè)試取得滿意產(chǎn)品332.3 軟件測(cè)試方法與策略2.3.1 靜態(tài)測(cè)試與動(dòng)態(tài)測(cè)試2.3.2 黑盒測(cè)試與白盒測(cè)試2.3.3 軟件測(cè)試過程2.3.4 軟件測(cè)試原則Return34軟件測(cè)試策略什么是軟件測(cè)試策略？ 是為軟件工程過程定義的一個(gè)軟件測(cè)試的模板，也就是把特定的測(cè)試用例方法放置進(jìn)去的

13、一系列步驟。軟件測(cè)試策略包含的特征：（1）測(cè)試從模塊層開始，然后擴(kuò)大延伸到整個(gè)基于計(jì)算機(jī)的系統(tǒng)集合中。（2）不同的測(cè)試技術(shù)適用于不同的時(shí)間點(diǎn)。（3）測(cè)試是由軟件的開發(fā)人員和（對(duì)于大型系統(tǒng)而言）獨(dú)立的測(cè)試組來管理的。（4）測(cè)試和調(diào)試是不同的活動(dòng)，但是調(diào)試必須能夠適應(yīng)任何的測(cè)試策略。35軟件測(cè)試充分性準(zhǔn)則對(duì)任何軟件都存在有限的充分測(cè)試集合。如果一個(gè)軟件系統(tǒng)在一個(gè)測(cè)試數(shù)據(jù)集合上的測(cè)試是充分的，那么再多測(cè)試一些數(shù)據(jù)也應(yīng)該是充分的。這一特性稱為單調(diào)性。即使對(duì)軟件所有成分都進(jìn)行了充分的測(cè)試，也并不表明整個(gè)軟件的測(cè)試已經(jīng)充分了。這一特性稱為非復(fù)合性。即使對(duì)軟件系統(tǒng)整體的測(cè)試是充分的，也并不意味軟件系統(tǒng)中各個(gè)

14、成分都已經(jīng)充分地得到了測(cè)試。這個(gè)特性稱為非分解性。軟件測(cè)試的充分性應(yīng)該與軟件的需求和軟件的實(shí)現(xiàn)都相關(guān)。軟件越復(fù)雜，需要的測(cè)試數(shù)據(jù)就越多。這一特性稱為復(fù)雜性。測(cè)試得越多，進(jìn)一步測(cè)試所能得到的充分性增長就越少。這一特性稱為回報(bào)遞減率。362.3.1 靜態(tài)測(cè)試與動(dòng)態(tài)測(cè)試1、靜態(tài)測(cè)試靜態(tài)測(cè)試不實(shí)際運(yùn)行軟件，主要是對(duì)軟件的編程格式、結(jié)構(gòu)等方面進(jìn)行評(píng)估。靜態(tài)測(cè)試包括代碼檢查、靜態(tài)結(jié)構(gòu)分析、代碼質(zhì)量度量等。它可以由人工進(jìn)行，也可以借助軟件工具自動(dòng)進(jìn)行。靜態(tài)測(cè)試方法也可利用計(jì)算機(jī)作為對(duì)被測(cè)程序進(jìn)行特性分析的工具，但與人工測(cè)試方式有著根本區(qū)別。另一方面，因它并不真正運(yùn)行被測(cè)程序，只進(jìn)行特性分析，這又與動(dòng)態(tài)方法不

15、同。所以，靜態(tài)方法常常稱為“分析”，靜態(tài)測(cè)試是對(duì)被測(cè)程序進(jìn)行特性分析方法的總稱。37靜態(tài)測(cè)試與動(dòng)態(tài)測(cè)試（續(xù)）代碼檢查代碼檢查包括代碼走查、桌面檢查、代碼審查等，主要檢查代碼和設(shè)計(jì)的一致性，代碼對(duì)標(biāo)準(zhǔn)的遵循、可讀性，代碼的邏輯表達(dá)的正確性，代碼結(jié)構(gòu)的合理性等方面。代碼檢查的具體內(nèi)容：變量檢查、命名和類型審查、程序邏輯審查、程序語法檢查和程序結(jié)構(gòu)檢查等。代碼檢查的優(yōu)點(diǎn)：在實(shí)際使用中，代碼檢查比動(dòng)態(tài)測(cè)試更有效率，能快速找到缺陷，發(fā)現(xiàn)30%70%的邏輯設(shè)計(jì)和編碼缺陷；代碼檢查看到的是問題本身而非征兆。代碼檢查的缺點(diǎn)：非常耗費(fèi)時(shí)間，而且代碼檢查需要知識(shí)和經(jīng)驗(yàn)的積累。38靜態(tài)測(cè)試與動(dòng)態(tài)測(cè)試（續(xù)）靜態(tài)結(jié)構(gòu)分

16、析靜態(tài)結(jié)構(gòu)分析主要是以圖形的方式表現(xiàn)程序的內(nèi)部結(jié)構(gòu)。例如函數(shù)調(diào)用關(guān)系圖、函數(shù)內(nèi)部控制流圖。其中： 函數(shù)調(diào)用關(guān)系圖以直觀的圖形方式描述一個(gè)應(yīng)用程序中各個(gè)函數(shù)的調(diào)用和被調(diào)用關(guān)系； 控制流圖顯示一個(gè)函數(shù)的邏輯結(jié)構(gòu)，由許多節(jié)點(diǎn)組成，一個(gè)節(jié)點(diǎn)代表一條語句或數(shù)條語句，連接結(jié)點(diǎn)的叫邊，邊表示節(jié)點(diǎn)間的控制流向。39靜態(tài)測(cè)試與動(dòng)態(tài)測(cè)試（續(xù)）代碼質(zhì)量度量軟件質(zhì)量包括六個(gè)方面：功能性、可靠性、易用性、效率、可維護(hù)性和可移植性。軟件的質(zhì)量是軟件屬性的各種標(biāo)準(zhǔn)度量的組合。針對(duì)軟件的可維護(hù)性，目前業(yè)界主要存在三種度量參數(shù)：Line復(fù)雜度、Halstead復(fù)雜度和McCabe復(fù)雜度。其中Line復(fù)雜度以代碼的行數(shù)作為計(jì)算的

17、基準(zhǔn)。Halstead以程序中使用到的運(yùn)算符與運(yùn)算元數(shù)量作為計(jì)數(shù)目標(biāo)（直接測(cè)量指標(biāo)），然后可以據(jù)以計(jì)算出程序容量、工作量等。McCabe復(fù)雜度 一般稱為圈復(fù)雜度，它將軟件的流程圖轉(zhuǎn)化為有向圖，然后以圖論來衡量軟件的質(zhì)量。40靜態(tài)測(cè)試與動(dòng)態(tài)測(cè)試（續(xù)）靜態(tài)測(cè)試階段的任務(wù)：（1）檢查算法的邏輯正確性。（2）檢查模塊接口的正確性。（3）檢查輸入?yún)?shù)是否有合法性檢查。（4）檢查調(diào)用其他模塊的接口是否正確。（5）檢查是否設(shè)置了適當(dāng)?shù)某鲥e(cuò)處理。（6）檢查表達(dá)式、語句是否正確，是否含有二義性。（7）檢查常量或全局變量使用是否正確。（8）檢查標(biāo)識(shí)符的使用是否規(guī)范、一致。（9）檢查程序風(fēng)格的一致性、規(guī)范性。（10

18、）檢查代碼是否可以優(yōu)化，算法效率是否最高。（11）檢查代碼注釋是否完整，是否正確反映了代碼的功能。41靜態(tài)測(cè)試與動(dòng)態(tài)測(cè)試（續(xù)）靜態(tài)測(cè)試可以完成以下工作：（1）發(fā)現(xiàn)下列程序的錯(cuò)誤：錯(cuò)用局部變量和全局變量；未定義的變量、不匹配的參數(shù)；不適當(dāng)?shù)难h(huán)嵌套或分支嵌套、死循環(huán)、不允許的遞歸；調(diào)用不存在的子程序，遺漏標(biāo)號(hào)或代碼。（2）找出以下問題的根源：從未使用過的變量；不會(huì)執(zhí)行到的代碼、從未使用過的標(biāo)號(hào)；潛在的死循環(huán)。（3）提供程序缺陷的間接信息：所用變量和常量的交叉應(yīng)用表；是否違背編碼規(guī)則；標(biāo)識(shí)符的使用方法和過程的調(diào)用層次。（4）為進(jìn)一步查找做好準(zhǔn)備。（5）選擇測(cè)試用例。（6）進(jìn)行符號(hào)測(cè)試。42靜態(tài)測(cè)試

19、與動(dòng)態(tài)測(cè)試（續(xù)）2、動(dòng)態(tài)測(cè)試動(dòng)態(tài)方法的主要特征是： 計(jì)算機(jī)必須真正運(yùn)行被測(cè)試的程序，通過輸入測(cè)試用例，對(duì)其運(yùn)行情況即輸入與輸出的對(duì)應(yīng)關(guān)系進(jìn)行分析，以達(dá)到檢測(cè)的目的。動(dòng)態(tài)測(cè)試包括： （1）功能確認(rèn)與接口測(cè)試 （2）覆蓋率分析 （3）性能分析 （4）內(nèi)存分析432.3.2 黑盒測(cè)試和白盒測(cè)試若測(cè)試規(guī)劃是基于產(chǎn)品的功能，目的是檢查程序各個(gè)功能是否能夠?qū)崿F(xiàn)，并檢查其中的功能錯(cuò)誤，則這種測(cè)試方法稱為黑盒測(cè)試(Black-box Testing)方法。 黑盒測(cè)試又稱為功能測(cè)試、數(shù)據(jù)驅(qū)動(dòng)測(cè)試和基于規(guī)格說明的測(cè)試。它是一種從用戶觀點(diǎn)出發(fā)的測(cè)試，一般被用來確認(rèn)軟件功能的正確性和可操作性。若測(cè)試規(guī)劃基于產(chǎn)品的內(nèi)部

20、結(jié)構(gòu)進(jìn)行測(cè)試，檢查內(nèi)部操作是否按規(guī)定執(zhí)行，軟件各個(gè)部分功能是否得到充分使用，則這種測(cè)試方法稱為白盒測(cè)試(White-box Testing)方法。 白盒測(cè)試又稱為結(jié)構(gòu)測(cè)試、邏輯驅(qū)動(dòng)測(cè)試或基于程序的測(cè)試，一般用來分析程序的內(nèi)部結(jié)構(gòu)。 44黑盒測(cè)試和白盒測(cè)試（續(xù)）白盒測(cè)試黑盒測(cè)試兩種測(cè)試方法從完全不同的角度出發(fā)，反映了測(cè)試思路的兩方面情況，適用于不同的測(cè)試階段。45黑盒測(cè)試和白盒測(cè)試（續(xù)）1、黑盒測(cè)試黑盒測(cè)試的基本觀點(diǎn)是：任何程序都可以看作是從輸入定義域映射到輸出值域的函數(shù)過程，被測(cè)程序被認(rèn)為是一個(gè)打不開的黑盒子，黑盒中的內(nèi)容（實(shí)現(xiàn)過程）完全不知道，只明確要做到什么。黑盒測(cè)試主要根據(jù)規(guī)格說明書設(shè)計(jì)

21、測(cè)試用例，并不涉及程序內(nèi)部構(gòu)造和內(nèi)部特性，只依靠被測(cè)程序輸入和輸出之間的關(guān)系或程序的功能設(shè)計(jì)測(cè)試用例。黑盒測(cè)試的特點(diǎn)：（1）黑盒測(cè)試與軟件的具體實(shí)現(xiàn)過程無關(guān)，在軟件實(shí)現(xiàn)的過程發(fā)生變化時(shí)，測(cè)試用例仍然可以使用。（2）黑盒測(cè)試用例的設(shè)計(jì)可以和軟件實(shí)現(xiàn)同時(shí)進(jìn)行，這樣能夠壓縮總的開發(fā)時(shí)間。46黑盒測(cè)試和白盒測(cè)試（續(xù)）輸入輸出黑盒測(cè)試是在程序接口進(jìn)行測(cè)試，它只是檢查程序功能是否按照規(guī)格說明書的規(guī)定正常使用。也被稱為用戶測(cè)試或功能測(cè)試。47黑盒測(cè)試和白盒測(cè)試（續(xù)）黑盒測(cè)試主要是為了發(fā)現(xiàn)以下幾類錯(cuò)誤：是否有不正確或遺漏了的功能？在接口上，輸入能否正確地接受？能否輸出正確的結(jié)果？是否有數(shù)據(jù)結(jié)構(gòu)錯(cuò)誤或外部信息訪

22、問錯(cuò)誤？性能上是否能夠滿足要求？是否有初始化或終止性錯(cuò)誤？黑盒測(cè)試的難點(diǎn)：在哪個(gè)層次上進(jìn)行測(cè)試？黑盒測(cè)試的具體技術(shù)方法 ： 邊界值分析法 等價(jià)類劃分法 因果圖法 決策表法48黑盒測(cè)試和白盒測(cè)試（續(xù)）2、白盒測(cè)試白盒測(cè)試將被測(cè)程序看作一個(gè)打開的盒子，測(cè)試者能夠看到被測(cè)源程序，可以分析被測(cè)程序的內(nèi)部結(jié)構(gòu)，此時(shí)測(cè)試的焦點(diǎn)集中在根據(jù)其內(nèi)部結(jié)構(gòu)設(shè)計(jì)測(cè)試用例。白盒測(cè)試要求是對(duì)某些程序的結(jié)構(gòu)特性做到一定程度的覆蓋，或者說這種測(cè)試是“基于覆蓋率的測(cè)試”通常的程序結(jié)構(gòu)覆蓋有： 語句覆蓋 判定覆蓋 條件覆蓋 判定/條件覆蓋 路徑覆蓋49黑盒測(cè)試和白盒測(cè)試（續(xù)）白盒測(cè)試需要完全了解程序結(jié)構(gòu)和處理過程，它按照程序內(nèi)部

23、邏輯測(cè)試程序，檢驗(yàn)程序中每條通路是否按預(yù)定要求正確工作。也被稱為程序員測(cè)試。應(yīng)用程序50黑盒測(cè)試和白盒測(cè)試（續(xù)） ？ X=2 y=2x Y=4 X=2Y=4未知等式與已知等式黑盒白盒3、黑盒測(cè)試法和白盒測(cè)試法的比較51黑盒測(cè)試和白盒測(cè)試（續(xù)）黑盒測(cè)試： 以用戶的觀點(diǎn)，從輸入數(shù)據(jù)與輸出數(shù)據(jù)的對(duì)應(yīng)關(guān)系，即根據(jù)程序外部特性進(jìn)行測(cè)試，而不考慮內(nèi)部結(jié)構(gòu)及工作情況。 黑盒測(cè)試技術(shù)注重于軟件的信息域（范圍），通過劃分程序的輸入和輸出域來確定測(cè)試用例。 若外部特性本身存在問題或規(guī)格說明的規(guī)定有誤，則應(yīng)用黑盒測(cè)試方法是不能發(fā)現(xiàn)問題的。 白盒測(cè)試： 只根據(jù)程序的內(nèi)部結(jié)構(gòu)進(jìn)行測(cè)試。 測(cè)試用例的設(shè)計(jì)要保證測(cè)試時(shí)程序的

24、所有語句至少執(zhí)行一次，而且要檢查所有的邏輯條件。 如果程序的結(jié)構(gòu)本身有問題，比如說程序邏輯有錯(cuò)誤或者有遺漏，那也是無法發(fā)現(xiàn)的。52黑盒測(cè)試和白盒測(cè)試（續(xù)）項(xiàng)目黑盒測(cè)試法白盒測(cè)試法規(guī)劃方面功能的測(cè)試結(jié)構(gòu)的測(cè)試優(yōu)點(diǎn)方面 能確保從用戶的角度出發(fā)進(jìn)行測(cè)試 能對(duì)程序內(nèi)部的特定部位進(jìn)行覆蓋測(cè)試缺點(diǎn)方面無法測(cè)試程序內(nèi)部特定部位；當(dāng)規(guī)格說明有誤，則不能發(fā)現(xiàn)問題無法檢查程序的外部特性； 無法對(duì)未實(shí)現(xiàn)規(guī)格說明的程序內(nèi)部欠缺部分進(jìn)行測(cè)試測(cè)試方法 邊界分析法 等價(jià)類劃分法 決策表測(cè)試 語句覆蓋，判定覆蓋， 條件覆蓋，判定/條件覆蓋， 路徑覆蓋，循環(huán)覆蓋， 模塊接口測(cè)試53黑盒測(cè)試和白盒測(cè)試（續(xù)）A只能用黑盒測(cè)試發(fā)現(xiàn)的

25、錯(cuò)誤C只能用白盒測(cè)試發(fā)現(xiàn)的錯(cuò)誤B用黑盒測(cè)試或白盒測(cè)試都能發(fā)現(xiàn)的錯(cuò)誤D用黑盒測(cè)試或白盒測(cè)試均無法發(fā)現(xiàn)的錯(cuò)誤A+B能用黑盒測(cè)試發(fā)現(xiàn)的錯(cuò)誤B+C能用白盒測(cè)試發(fā)現(xiàn)的錯(cuò)誤A+B+C 用兩種測(cè)試能發(fā)現(xiàn)的錯(cuò)誤A+B+C+D軟件中的全部錯(cuò)誤ABCD黑盒測(cè)試與白盒測(cè)試能夠發(fā)現(xiàn)的錯(cuò)誤542.3.3 軟件測(cè)試過程單元測(cè)試單元測(cè)試單元測(cè)試集成測(cè)試集成測(cè)試確認(rèn)測(cè)試系統(tǒng)測(cè)試* 這三個(gè)測(cè)試可能交叉與前后互換被測(cè)模塊被測(cè)模塊被測(cè)模塊設(shè)計(jì)信息單元 軟件需求其它元素用戶信息其它元素* * 驗(yàn)收測(cè)試* 交付用戶圖2-2 軟件測(cè)試的過程流程55軟件測(cè)試過程（續(xù)）單元測(cè)試：針對(duì)每個(gè)單元的測(cè)試,以確保每個(gè)模塊能正常工作為目標(biāo)。集成測(cè)試：

26、對(duì)已測(cè)試過的模塊進(jìn)行組裝,進(jìn)行集成測(cè)試。目的在于檢驗(yàn)與軟件設(shè)計(jì)相關(guān)的程序結(jié)構(gòu)問題。確認(rèn)（有效性）測(cè)試：是檢驗(yàn)所開發(fā)的軟件能否滿足所有功能和性能需求的最后手段。系統(tǒng)測(cè)試：檢驗(yàn)軟件產(chǎn)品能否與系統(tǒng)的其他部分（比如，硬件、數(shù)據(jù)庫及操作人員）協(xié)調(diào)工作。驗(yàn)收（用戶）測(cè)試：檢驗(yàn)軟件產(chǎn)品質(zhì)量的最后一道工序。主要突出用戶的作用，同時(shí)軟件開發(fā)人員也應(yīng)有一定程度的參與。56一個(gè)實(shí)用軟件測(cè)試過程一種簡單實(shí)用的軟件測(cè)試過程模型 POCERM測(cè)試過程中必需的基本測(cè)試活動(dòng)及其產(chǎn)生的結(jié)果擬定軟件測(cè)試計(jì)劃 (Plans)編制軟件測(cè)試大綱 (Outlines)設(shè)計(jì)和生成測(cè)試用例 (test Case generation)實(shí)施測(cè)

27、試 (Execution)生成軟件測(cè)試報(bào)告 (software testing Reports)軟件問題報(bào)告SPR (Software Problem Report)測(cè)試結(jié)果報(bào)告 (test result Reports)57一個(gè)實(shí)用軟件測(cè)試過程（續(xù)）基本特性：（1）計(jì)劃性: 任務(wù) 人員 設(shè)備 時(shí)間 相關(guān).（2）平行性: 開發(fā) 編碼 | 測(cè)試 再測(cè)試（3）完整性: 計(jì)劃+大綱+用例+SPRs+.（4）重用性: 測(cè)試 再測(cè)試 回歸測(cè)試 升級(jí) 多平臺(tái)（5）可重復(fù)性: SPRs 用例 大綱 再現(xiàn)Bugs（6）周期性: test cycles, regression, update（7）可管理性: w

28、ell structured and organized QE group + well planned and prepared task58軟件測(cè)試計(jì)劃一個(gè)大中型軟件系統(tǒng)的測(cè)試必須經(jīng)歷一個(gè)相當(dāng)復(fù)雜的測(cè)試過程，并且常常需要經(jīng)歷數(shù)月乃至史長時(shí)間，需要投入相當(dāng)可觀的人力和物力資源，所以針對(duì)整個(gè)項(xiàng)目的預(yù)定目標(biāo)和可能的實(shí)際條件，對(duì)系統(tǒng)的測(cè)試過程事先進(jìn)行認(rèn)真的計(jì)劃，軟件測(cè)試計(jì)劃可分為3個(gè)層次。 1)概要測(cè)試計(jì)劃:是軟件項(xiàng)目實(shí)施計(jì)劃中的一項(xiàng)重要內(nèi)容，應(yīng)當(dāng)在軟件開發(fā)初期，即需求分析階段制定。這項(xiàng)計(jì)劃應(yīng)當(dāng)定義被測(cè)試對(duì)象和測(cè)試目標(biāo);確定測(cè)試階段和測(cè)試周期的劃分;制定測(cè)試人員、軟硬件資源和測(cè)試進(jìn)度等方而的計(jì)劃;

29、規(guī)定軟件測(cè)試方法、測(cè)試標(biāo)準(zhǔn)以及支持環(huán)境和測(cè)試工具，比如：語句覆蓋率需達(dá)到95 , 3級(jí)以上的錯(cuò)誤改正率需95 ,所有決定不改正的“輕微”錯(cuò)誤都必須經(jīng)過專門的質(zhì)量評(píng)審委員會(huì)同意等。59軟件測(cè)試計(jì)劃（續(xù)）2)詳細(xì)測(cè)試計(jì)劃:是針對(duì)子系統(tǒng)在特定的測(cè)試階段所要進(jìn)行的測(cè)試工作制定詳細(xì)計(jì)劃。它詳細(xì)規(guī)定了測(cè)試小組的各項(xiàng)測(cè)試任務(wù)、測(cè)試策略、任務(wù)分配和進(jìn)度安排等。3)測(cè)試人員的測(cè)試實(shí)施計(jì)劃:是根據(jù)詳細(xì)測(cè)試計(jì)劃制定的測(cè)試者的測(cè)試具體實(shí)施計(jì)劃。它規(guī)定了測(cè)試者在每一輪測(cè)試中負(fù)貢測(cè)試的內(nèi)容、測(cè)試強(qiáng)度和工作進(jìn)度等。測(cè)試實(shí)施計(jì)劃是整個(gè)軟件測(cè)試計(jì)劃的組成部分，是檢查測(cè)試實(shí)際執(zhí)行情況的重要依據(jù)。60軟件測(cè)試大綱軟件測(cè)試大綱是軟件

30、測(cè)試的依據(jù)。它明確詳細(xì)地規(guī)定了在一次測(cè)試中針對(duì)系統(tǒng)的每一項(xiàng)功能或特性所必須完成的基木測(cè)試項(xiàng)目和測(cè)試完成的標(biāo)準(zhǔn)。無論是自動(dòng)測(cè)試還是手動(dòng)測(cè)試，都必須滿足測(cè)試大綱的要求。實(shí)際上，測(cè)試大綱是從測(cè)試的角度對(duì)被測(cè)對(duì)象的功能和各種特性的細(xì)化和展開。比如，針對(duì)系統(tǒng)功能的測(cè)試大綱是基于軟件質(zhì)量保證人員對(duì)系統(tǒng)需求規(guī)格說明書中有關(guān)系統(tǒng)功能定義的理解，將其逐一細(xì)化展開后編制而成的。因此，測(cè)試大綱不僅是軟件開發(fā)后期測(cè)試的依據(jù)，而且在系統(tǒng)的需求分析階段也是質(zhì)量保證的重要文檔和依據(jù)。61兩者的區(qū)別計(jì)劃是組織管理文檔，考慮的是組織架構(gòu)、工作任務(wù)分配、工作量估計(jì)、人力物力資源的分配、進(jìn)度的安排、風(fēng)險(xiǎn)的估計(jì)和規(guī)避、各任務(wù)通過準(zhǔn)則

31、等，并不涉及到技術(shù)層面的東西；測(cè)試大綱是技術(shù)文檔，考慮的是測(cè)試需求的細(xì)化、自動(dòng)化測(cè)試框架的設(shè)計(jì)、測(cè)試數(shù)據(jù)和測(cè)試腳本的設(shè)計(jì)、測(cè)試用例設(shè)計(jì)的原則等，不需考慮組織管理方面的因素。 62在測(cè)試工作開始以前，不應(yīng)設(shè)想程序中沒有缺陷或找不出缺陷。（測(cè)試心理學(xué)）測(cè)試以前應(yīng)預(yù)知測(cè)試的結(jié)果數(shù)據(jù)。盡可能避免測(cè)試自己寫的程序。堅(jiān)持獨(dú)立測(cè)試原則，必要的情況下建立獨(dú)立測(cè)試機(jī)構(gòu)。測(cè)試用例應(yīng)兼顧有效輸入和無效輸入。不僅要檢驗(yàn)程序是否做了該做的事，還應(yīng)檢驗(yàn)是否做了不該做的事。測(cè)試的充分性。測(cè)試的有效性。限于人力、物力，測(cè)試工作適可而止。（測(cè)試經(jīng)濟(jì)學(xué)）2.3.4 軟件測(cè)試的原則63軟件測(cè)試的原則(續(xù))保留一切測(cè)試用例。任何已測(cè)

32、程序的變更都應(yīng)重新進(jìn)行測(cè)試。（回歸測(cè)試）測(cè)試是不完全的。（測(cè)試不完全）測(cè)試具有免疫性。（軟件缺陷免疫性）測(cè)試是“泛型概念” 。（全程測(cè)試） 80-20原則。缺陷的必然性。 軟件測(cè)試的意義-事后分析。642.4 單元測(cè)試2.4.1 單元測(cè)試的主要任務(wù)2.4.2 單元測(cè)試的執(zhí)行過程Return65軟件測(cè)試的過程流程單元測(cè)試單元測(cè)試單元測(cè)試集成測(cè)試集成測(cè)試確認(rèn)測(cè)試系統(tǒng)測(cè)試* 這三個(gè)測(cè)試可能交叉與前后互換被測(cè)模塊被測(cè)模塊被測(cè)模塊設(shè)計(jì)信息單元 軟件需求其它元素用戶信息其它元素* * 驗(yàn)收測(cè)試* 交付用戶66單元測(cè)試的基本概念單元測(cè)試是對(duì)程序模塊進(jìn)行正確性檢驗(yàn)的測(cè)試工作。單元測(cè)試的目標(biāo)：驗(yàn)證開發(fā)人員所書寫

33、的編碼是否可以按照其所設(shè)想的方式執(zhí)行而產(chǎn)出符合預(yù)期值的結(jié)果，確保產(chǎn)生符合其需求的可靠的程序單元。符合需求的代碼通常應(yīng)該具備以下性質(zhì)： 正確性、清晰性、規(guī)范性、一致性、高效性67單元測(cè)試的誤區(qū)單元測(cè)試是一種浪費(fèi)時(shí)間的工作。單元測(cè)試只能證明代碼做了什么。我是一個(gè)很棒的程序員，是不是可以不進(jìn)行單元測(cè)試？集成測(cè)試可以捕捉所有的BUG。單元測(cè)試的成本效率不高。68單元測(cè)試的主要任務(wù)單元測(cè)試針對(duì)每個(gè)程序的模塊，主要測(cè)試5個(gè)方面的問題： 模塊接口、局部數(shù)據(jù)結(jié)構(gòu)、邊界條件、獨(dú)立的路徑和錯(cuò)誤處理。69單元測(cè)試的主要任務(wù)（續(xù)）模塊接口這是對(duì)模塊接口進(jìn)行的測(cè)試，檢查進(jìn)出程序單元的數(shù)據(jù)流是否正確。模塊接口測(cè)試必須在任

34、何其它測(cè)試之前進(jìn)行。模塊接口測(cè)試至少需要如下的測(cè)試項(xiàng)目：（1）調(diào)用所測(cè)模塊時(shí)的輸入?yún)?shù)與模塊的形式參數(shù)在個(gè)數(shù)、屬性、順序上是否匹配；（2）所測(cè)模塊調(diào)用子模塊時(shí)，它輸入給子模塊的參數(shù)與子模塊中的形式參數(shù)在個(gè)數(shù)、屬性、順序上是否匹配；（3）是否修改了只做輸入用的形式參數(shù)；（4）調(diào)用標(biāo)準(zhǔn)函數(shù)的參數(shù)在個(gè)數(shù)、屬性、順序上是否正確；（5）全局變量的定義在各模塊中是否一致。70單元測(cè)試的主要任務(wù)（續(xù)）局部數(shù)據(jù)結(jié)構(gòu)在模塊工作過程中，必須測(cè)試模塊內(nèi)部的數(shù)據(jù)能否保持完整性，包括內(nèi)部數(shù)據(jù)的內(nèi)容、形式及相互關(guān)系不發(fā)生錯(cuò)誤。對(duì)于局部數(shù)據(jù)結(jié)構(gòu)，應(yīng)該在單元測(cè)試中注意發(fā)現(xiàn)以下幾類錯(cuò)誤：（1）不正確的或不一致的類型說明。（2）

35、錯(cuò)誤的初始化或默認(rèn)值。（3）錯(cuò)誤的變量名，如拼寫錯(cuò)誤或書寫錯(cuò)誤。（4）下溢、上溢或者地址錯(cuò)誤。71單元測(cè)試的主要任務(wù)（續(xù)）路徑測(cè)試在單元測(cè)試中，最主要的測(cè)試是針對(duì)路徑的測(cè)試。測(cè)試用例必須能夠發(fā)現(xiàn)由于計(jì)算錯(cuò)誤、不正確的判定或不正常的控制流而產(chǎn)生的錯(cuò)誤。常見的錯(cuò)誤有： 誤解的或不正確的算術(shù)優(yōu)先級(jí)；混合模式的運(yùn)算；錯(cuò)誤的初始化；精確度不夠精確；表達(dá)式的不正確符號(hào)表示。針對(duì)判定和條件覆蓋，測(cè)試用例還要能夠發(fā)現(xiàn)如下錯(cuò)誤： 不同數(shù)據(jù)類型的比較；不正確的邏輯操作或優(yōu)先級(jí)；應(yīng)當(dāng)相等的地方由于精確度的錯(cuò)誤而不能相等；不正確的判定或不正確的變量；不正確的或不存在的循環(huán)終止；當(dāng)遇到分支循環(huán)時(shí)不能退出；不適當(dāng)?shù)匦薷难?/p>

36、環(huán)變量。72單元測(cè)試的主要任務(wù)（續(xù)）邊界條件邊界測(cè)試是單元測(cè)試的最后一步，必須采用邊界值分析方法來設(shè)計(jì)測(cè)試用例，認(rèn)真仔細(xì)地測(cè)試為限制數(shù)據(jù)處理而設(shè)置的邊界處，看模塊是否能夠正常工作。一些可能與邊界有關(guān)的數(shù)據(jù)類型如數(shù)值、字符、位置、數(shù)量、尺寸等，還要注意這些邊界的首個(gè)、最后一個(gè)、最大值、最小值、最長、最短、最高、最低等特征。在邊界條件測(cè)試中，應(yīng)設(shè)計(jì)測(cè)試用例檢查以下情況： （1）在n次循環(huán)的第0次、1次、n次是否有錯(cuò)誤。 （2）運(yùn)算或判斷中取最大值、最小值時(shí)是否有錯(cuò)誤。 （3）數(shù)據(jù)流、控制流中剛好等于、大于、小于確定的比較值是否出現(xiàn)錯(cuò)誤。73單元測(cè)試的主要任務(wù)（續(xù)）出錯(cuò)處理測(cè)試出錯(cuò)處理的重點(diǎn)是模塊在

37、工作中發(fā)生了錯(cuò)誤，其中的出錯(cuò)處理設(shè)施是否有效。檢驗(yàn)程序中的出錯(cuò)處理可能面對(duì)的情況有：（1）對(duì)運(yùn)行發(fā)生的錯(cuò)誤描述難以理解。（2）所報(bào)告的錯(cuò)誤與實(shí)際遇到的錯(cuò)誤不一致。（3）出錯(cuò)后，在錯(cuò)誤處理之前就引起系統(tǒng)的干預(yù)。（4）例外條件的處理不正確。（5）提供的錯(cuò)誤信息不足，以至于無法找到錯(cuò)誤的原因。742.4.2 單元測(cè)試的執(zhí)行過程何時(shí)進(jìn)行單元測(cè)試？單元測(cè)試常常是和代碼編寫工作同時(shí)進(jìn)行的，在完成了程序編寫、復(fù)查和語法正確性驗(yàn)證后，就應(yīng)進(jìn)行單元測(cè)試用例設(shè)計(jì)。在單元測(cè)試時(shí)，如果模塊不是獨(dú)立的程序，需要設(shè)置一些輔助測(cè)試模塊。輔助測(cè)試模塊有兩種： （1）驅(qū)動(dòng)模塊(Drive) 用來模擬被測(cè)試模塊的上一級(jí)模塊，相當(dāng)

38、于被測(cè)模塊的主程序。它接收數(shù)據(jù)，將相關(guān)數(shù)據(jù)傳送給被測(cè)模塊，啟動(dòng)被測(cè)模塊，并打印出相應(yīng)的結(jié)果。 （2）樁模塊(Stub) 用來模擬被測(cè)模塊工作過程中所調(diào)用的模塊。它們一般只進(jìn)行很少的數(shù)據(jù)處理。 驅(qū)動(dòng)模塊和樁模塊都是額外的開銷，雖然在單元測(cè)試中必須編寫，但并不需要作為最終的產(chǎn)品提供給用戶。 75單元測(cè)試的執(zhí)行過程（續(xù)）被測(cè)模塊、驅(qū)動(dòng)模塊和樁模塊共同構(gòu)成了一個(gè)如下圖所示的單元測(cè)試的測(cè)試環(huán)境：測(cè)試用例被測(cè)模塊驅(qū)動(dòng)模塊測(cè)試結(jié)果樁模塊1樁模塊2樁模塊3樁模塊n樁模塊76單元測(cè)試和集成測(cè)試的關(guān)系對(duì)象不同：單元測(cè)試是程序模塊（詳細(xì)設(shè)計(jì)），集成測(cè)試是模塊（概要設(shè)計(jì)）以及模塊組合；測(cè)試方法不同：單元測(cè)試主要使用基

39、于代碼的白盒，集成測(cè)試主要使用基于功能的黑盒測(cè)試；測(cè)試時(shí)間不同：集成測(cè)試在單元測(cè)試之后；測(cè)試內(nèi)容不同：單元測(cè)試主要測(cè)試模塊內(nèi)部；集成測(cè)試主要測(cè)試模塊之間接口；二者的界限趨向模糊。77單元測(cè)試和系統(tǒng)測(cè)試的關(guān)系對(duì)象不同：單元測(cè)試是證明程序模塊的正確，系統(tǒng)測(cè)試是證明系統(tǒng)是否滿足用戶的需求；出發(fā)點(diǎn)不同：單元測(cè)試主要從程序員的角度測(cè)試，系統(tǒng)測(cè)試主要從用戶的角度測(cè)試；測(cè)試時(shí)間不同：系統(tǒng)測(cè)試在單元測(cè)試之后；測(cè)試內(nèi)容不同：單元測(cè)試主要測(cè)試模塊內(nèi)部，系統(tǒng)測(cè)試主要根據(jù)需求規(guī)格說明書進(jìn)行；測(cè)試錯(cuò)誤定位：單元測(cè)試定位容易可以并行，系統(tǒng)測(cè)試發(fā)現(xiàn)錯(cuò)誤比較難定位；78單元測(cè)試經(jīng)驗(yàn)總結(jié) 測(cè)試人員在進(jìn)行測(cè)試的工作過程中，應(yīng)該注

40、意積累測(cè)試工作經(jīng)驗(yàn)，這樣可以縮短單元測(cè)試的時(shí)間，提高測(cè)試效果和效率。如： 1、在做單元測(cè)試的過程中，要靈活選用測(cè)試用例設(shè)計(jì)技術(shù)，首先使用黑盒測(cè)試用例設(shè)計(jì)技術(shù)，然后根據(jù)相應(yīng)的覆蓋率統(tǒng)計(jì)再補(bǔ)充白盒測(cè)試用例。既減少了測(cè)試工作的重復(fù)，又保證了單元測(cè)試的完整性。 2、應(yīng)該盡量開發(fā)簡單測(cè)試驅(qū)動(dòng)代碼，增強(qiáng)其可讀性。最重要的是，單元測(cè)試代碼中不能包含分支和邏輯語句，因?yàn)檫@意味著有多個(gè)測(cè)試在同時(shí)進(jìn)行。這樣將會(huì)使測(cè)試代碼變得難以理解和維護(hù)。79單元測(cè)試小結(jié) 通過單元測(cè)試，我們驗(yàn)證開發(fā)人員所書寫的編碼是可以按照其所設(shè)想的方式執(zhí)行的，產(chǎn)出了符合預(yù)期值的結(jié)果。這就實(shí)現(xiàn)了單元測(cè)試的目的。相比后面階段的測(cè)試，單元測(cè)試的創(chuàng)建

41、更簡單，維護(hù)更容易，并且可以更方便的進(jìn)行重復(fù)。 從全程的費(fèi)用來考慮， 相比起那些復(fù)雜且曠日持久的集成測(cè)試，或是不穩(wěn)定的軟件系統(tǒng)來說，單元測(cè)試所需的費(fèi)用是很低的。 模塊單元設(shè)計(jì)完畢之后的開發(fā)階段就是單元測(cè)試。802.5 集成測(cè)試2.5.1 非增量式測(cè)試2.5.2 增量式測(cè)試2.5.3 不同集成測(cè)試方法的比較2.5.4 回歸測(cè)試Return81集成測(cè)試應(yīng)該考慮的問題在把各個(gè)模塊連接起來的時(shí)候，穿越模塊接口的數(shù)據(jù)是否會(huì)丟失；各個(gè)子功能組合起來，能否達(dá)到預(yù)期要求的父功能；一個(gè)模塊的功能是否會(huì)對(duì)另一個(gè)模塊的功能產(chǎn)生不利的影響；全局的數(shù)據(jù)結(jié)構(gòu)是否有問題；單個(gè)模塊的誤差積累起來，是否會(huì)有放大，從而達(dá)到不可接

42、受的程度。822.5.1 非增量式測(cè)試非增量式測(cè)試是采用一步到位的方法來構(gòu)造測(cè)試： 對(duì)所有模塊進(jìn)行個(gè)別的單元測(cè)試后，按照程序結(jié)構(gòu)圖將各模塊連接起來，把連接后的程序當(dāng)作一個(gè)整體進(jìn)行測(cè)試。非增量式測(cè)試的缺點(diǎn)： 當(dāng)一次集成的模塊較多時(shí)，非增量式測(cè)試容易出現(xiàn)混亂，因?yàn)闇y(cè)試時(shí)可能發(fā)現(xiàn)了許多故障，為每一個(gè)故障定位和糾正非常困難，并且在修正一個(gè)故障的同時(shí)，可能又引入了新的故障，新舊故障混雜，很難判定出錯(cuò)的具體原因和位置。 83非增量式測(cè)試 As3s4s5d2 Cd4 Ed5 Fd1 B s1d3 s2 DABCDEFABCDEF（1）程序結(jié)構(gòu)圖（3）集成測(cè)試示意圖（2）單元測(cè)試示意圖842.5.2 增量式測(cè)

43、試增量式測(cè)試的集成是逐步實(shí)現(xiàn)的： 逐次將未曾集成測(cè)試的模塊和已經(jīng)集成測(cè)試的模塊（或子系統(tǒng)）結(jié)合成程序包，再將這些模塊集成為較大系統(tǒng)，在集成的過程中邊連接邊測(cè)試，以發(fā)現(xiàn)連接過程中產(chǎn)生的問題。 按照不同的實(shí)施次序，增量式集成測(cè)試又可以分為三種不同的方法： （1）自頂向下增量式測(cè)試 （2）自底向上增量式測(cè)試 （3）混合增量式測(cè)試85自頂向下增量式測(cè)試自頂向下增量式測(cè)試表示逐步集成和逐步測(cè)試是按照結(jié)構(gòu)圖自上而下進(jìn)行的，即模塊集成的順序是首先集成主控模塊（主程序），然后依照控制層次結(jié)構(gòu)向下進(jìn)行集成。從屬于主控模塊的按深度優(yōu)先方式（縱向）或者廣度優(yōu)先方式（橫向）集成到結(jié)構(gòu)中去。深度優(yōu)先方式的集成： 首先集

44、成在結(jié)構(gòu)中的一個(gè)主控路徑下的所有模塊，主控路徑的選擇是任意的。 廣度優(yōu)先方式的集成： 首先沿著水平方向，把每一層中所有直接隸屬于上一層的模塊集成起來，直到底層。86自頂向下增量式測(cè)試（續(xù)）集成測(cè)試的整個(gè)過程由3個(gè)步驟完成： （1）主控模塊作為測(cè)試驅(qū)動(dòng)器。 （2）根據(jù)集成的方式（深度或廣度），下層的樁模塊一次一次地被替換為真正的模塊。 （3）在每個(gè)模塊被集成時(shí)，都必須進(jìn)行單元測(cè)試。 重復(fù)第2步，直到整個(gè)系統(tǒng)被測(cè)試完成。 實(shí)例 按照廣度優(yōu)先方式進(jìn)行集成測(cè)試 實(shí)例 按照深度優(yōu)先方式進(jìn)行集成測(cè)試87自頂向下增量式測(cè)試（續(xù)） A B C D E F A S1 S2 S3 A B C D S4 S5 A

45、B C D E F（1）（2）（3）廣度優(yōu)先方式88自頂向下增量式測(cè)試（續(xù)） A B C D E F A S1 S2 S3 A B S2 S3 E A B C S3 E（1）（2）（3）深度優(yōu)先方式（4）89自底向上增量式測(cè)試自底向上增量式測(cè)試表示逐步集成和逐步測(cè)試的工作是按結(jié)構(gòu)圖自下而上進(jìn)行的，即從程序模塊結(jié)構(gòu)的最底層模塊開始集成和測(cè)試。由于是從最底層開始集成，對(duì)于一個(gè)給定層次的模塊，它的子模塊（包括子模塊的所有下屬模塊）已經(jīng)集成并測(cè)試完成，所以不再需要使用樁模塊進(jìn)行輔助測(cè)試。在模塊的測(cè)試過程中需要從子模塊得到的信息可以直接運(yùn)行子模塊得到。 實(shí)例 采用自底向上增量式測(cè)試方法進(jìn)行集成測(cè)試90自

46、底向上增量式測(cè)試 A B C D E F d2 Cd1 Ed3 Fd4 B Ed5 F D A B C D E F91混合增量式測(cè)試混合增量式測(cè)試是把自頂向下測(cè)試和自底向上測(cè)試這兩種方式結(jié)合起來進(jìn)行集成和測(cè)試。這樣可以兼具兩者的優(yōu)點(diǎn)，而摒棄其缺點(diǎn)。常見的兩種混合增量式測(cè)試方式：（1）衍變的自頂向下的增量式測(cè)試：基本思想是強(qiáng)化對(duì)輸入/輸出模塊和引入新算法模塊的測(cè)試，并自底向上集成為功能相對(duì)完整且相對(duì)獨(dú)立的子系統(tǒng)，然后由主模塊開始自頂向下進(jìn)行增量式測(cè)試。（2）自底向上-自頂向下的增量式測(cè)試：首先對(duì)含讀操作的子系統(tǒng)自底向上直至根節(jié)點(diǎn)模塊進(jìn)行集成和測(cè)試，然后對(duì)含寫操作的子系統(tǒng)做自頂向下的集成與測(cè)試。9

47、2集成測(cè)試方法非增量測(cè)試增量測(cè)試 自頂向下測(cè)試 廣度優(yōu)先 深度優(yōu)先 自底向上測(cè)試 混合測(cè)試932.5.3 不同集成測(cè)試方法的比較1、非增量式測(cè)試與增量式測(cè)試的比較非增量式測(cè)試的方法是先分散測(cè)試，然后集中起來再一次完成集成測(cè)試。假如在模塊的接口處存在錯(cuò)誤，只會(huì)在最后的集成測(cè)試時(shí)一下子暴露出來。增量式測(cè)試是逐步集成和逐步測(cè)試的方法，把可能出現(xiàn)的差錯(cuò)分散暴露出來，便于找出問題和修改。而且一些模塊在逐步集成的測(cè)試中，得到了較多次的考驗(yàn)，因此，可能會(huì)取得較好的測(cè)試效果。結(jié)論：增量式測(cè)試要比非增量式測(cè)試具有一定的優(yōu)越性。94不同集成測(cè)試方法的比較（續(xù)）2、自頂向下與自底向上增量式測(cè)試的比較自頂向下增量式測(cè)

48、試： 優(yōu)點(diǎn)在于它可以自然的做到逐步求精，一開始就能讓測(cè)試者看到系統(tǒng)的框架。 缺點(diǎn)是需要提供樁模塊，并且在輸入/輸出模塊接入系統(tǒng)以前，在樁模塊中表示測(cè)試數(shù)據(jù)有一定困難。自底向上增量式測(cè)試： 優(yōu)點(diǎn)在于，由于驅(qū)動(dòng)模塊模擬了所有調(diào)用參數(shù)，即使數(shù)據(jù)流并未構(gòu)成有向的非環(huán)狀圖，生成測(cè)試數(shù)據(jù)也無困難。 缺點(diǎn)在于，直到最后一個(gè)模塊被加進(jìn)去之后才能看到整個(gè)程序（系統(tǒng)）的框架。95集成測(cè)試與系統(tǒng)測(cè)試的區(qū)別1、測(cè)試對(duì)象 集成測(cè)試的測(cè)試對(duì)象是由通過了單元測(cè)試的各個(gè)模塊所集成起來的組件。而系統(tǒng)測(cè)試的測(cè)試對(duì)象，除了軟件之外，還有計(jì)算機(jī)硬件及相關(guān)的外圍設(shè)備、數(shù)據(jù)采集和傳輸機(jī)構(gòu)、計(jì)算機(jī)系統(tǒng)操作人員等的整個(gè)系統(tǒng)。2、測(cè)試時(shí)間 集

49、成測(cè)試是介于單元測(cè)試和系統(tǒng)測(cè)試之間的測(cè)試。 在測(cè)試時(shí)間上，先于系統(tǒng)測(cè)試。96集成測(cè)試與系統(tǒng)測(cè)試的區(qū)別 3、測(cè)試方法 集成測(cè)試通常會(huì)采用灰盒測(cè)試。而系統(tǒng)測(cè)試通常使用黑盒測(cè)試。 4、測(cè)試內(nèi)容 集成測(cè)試的主要內(nèi)容就是各個(gè)單元模塊之間的接口，以及各個(gè)模塊集成后所實(shí)現(xiàn)的功能。而系統(tǒng)測(cè)試的主要內(nèi)容就是整個(gè)系統(tǒng)的功能和性能。97集成測(cè)試與系統(tǒng)測(cè)試的區(qū)別 5、測(cè)試目的 集成測(cè)試的主要目的就是發(fā)現(xiàn)單元之間接口的錯(cuò)誤，以及發(fā)現(xiàn)集成后的軟件同軟件概要設(shè)計(jì)說明不一致的地方。而系統(tǒng)測(cè)試的主要目的就是，通過與系統(tǒng)需求定義相比較之后發(fā)現(xiàn)軟件與系統(tǒng)定義不符合或矛盾的地方。 6、測(cè)試角度 集成測(cè)試工作的開展更多的是站在測(cè)試工作

50、人員的角度上。系統(tǒng)測(cè)試工作的開展更多的是站在用戶的角度來進(jìn)行。982.5.4 回歸測(cè)試什么是回歸測(cè)試？ 在集成測(cè)試策略的環(huán)境中，回歸測(cè)試是對(duì)某些已經(jīng)進(jìn)行過的測(cè)試的某些子集再重新進(jìn)行一遍，以保證上述改變不會(huì)傳播無法預(yù)料的副作用或引發(fā)新的問題。 在更廣的環(huán)境里，回歸測(cè)試就是用來保證（由于測(cè)試或其他原因的）改動(dòng)不會(huì)帶來不可預(yù)料的行為或另外的錯(cuò)誤。回歸測(cè)試可以通過重新執(zhí)行所有的測(cè)試用例的一個(gè)子集人工地進(jìn)行，也可以使用自動(dòng)化的捕獲回放工具來進(jìn)行?；貧w測(cè)試集包括三種不同類型的測(cè)試用例： （1）能夠測(cè)試軟件的所有功能的代表性測(cè)試用例 （2）專門針對(duì)可能會(huì)被修改而影響軟件功能的附加測(cè)試 （3）針對(duì)修改過的軟件

51、成分的測(cè)試992.6 確認(rèn)測(cè)試1、確認(rèn)測(cè)試的準(zhǔn)則 確認(rèn)測(cè)試也稱為合格性測(cè)試，是檢驗(yàn)所開發(fā)的軟件是否能按用戶提出的要求進(jìn)行。軟件確認(rèn)要通過一系列證明軟件功能和要求一致的黑盒測(cè)試來完成。 經(jīng)過確認(rèn)測(cè)試，應(yīng)該為已開發(fā)的軟件給出結(jié)論性評(píng)價(jià)：（1）經(jīng)過檢驗(yàn)的軟件的功能、性能及其他要求均已滿足需求規(guī)格說明書的規(guī)定，則可被認(rèn)為是合格的軟件。（2）經(jīng)過檢驗(yàn)發(fā)現(xiàn)與需求說明書有相當(dāng)?shù)钠x，得到一個(gè)各項(xiàng)缺陷清單。100確認(rèn)測(cè)試（續(xù)）2、配置審查的內(nèi)容 確認(rèn)測(cè)試過程的重要環(huán)節(jié)就是配置審查工作。其目的在于確保已開發(fā)軟件的所有文件資料均已編寫齊全，并得到分類編目，足以支持運(yùn)行以后的軟件維護(hù)工作。 配置審查的文件資料包括用

52、戶所需的以下資料： （1）用戶手冊(cè) （2）操作手冊(cè) （3）設(shè)計(jì)資料 如：設(shè)計(jì)說明書、源程序以及測(cè)試資料（測(cè)試說明書、測(cè)試報(bào)告）等1012.7 系統(tǒng)測(cè)試為什么要進(jìn)行系統(tǒng)測(cè)試？ 由于軟件只是計(jì)算機(jī)系統(tǒng)中的一個(gè)組成部分，軟件開發(fā)完成之后，最終還要和系統(tǒng)中的硬件系統(tǒng)、某些支持軟件、數(shù)據(jù)信息等其他部分配套運(yùn)行。因此，在投入運(yùn)行前要完成系統(tǒng)測(cè)試，以保證各組成部分不僅能單獨(dú)的得到檢驗(yàn)，而且在系統(tǒng)各部分協(xié)調(diào)工作的環(huán)境下也能正常工作。盡管每一個(gè)檢驗(yàn)有特定的目標(biāo)，然而所有的檢測(cè)工作都要驗(yàn)證系統(tǒng)中每個(gè)部分均已得到正確的集成，并能完成指定的功能。嚴(yán)格的說，系統(tǒng)測(cè)試超出了軟件工程范圍。通常這項(xiàng)工作并不由系統(tǒng)開發(fā)人員或系

53、統(tǒng)開發(fā)組織來承擔(dān)，而是由軟件用戶或軟件開發(fā)機(jī)構(gòu)委托獨(dú)立測(cè)試機(jī)構(gòu)來完成。 102恢復(fù)測(cè)試恢復(fù)測(cè)試是通過各種手段，強(qiáng)制性地使軟件出錯(cuò)，使其不能正常工作，進(jìn)而檢驗(yàn)系統(tǒng)的恢復(fù)能力?；謴?fù)測(cè)試包含的內(nèi)容： 如果系統(tǒng)恢復(fù)是自動(dòng)的（由系統(tǒng)自身完成），則應(yīng)該檢驗(yàn)：重新初始化、檢驗(yàn)點(diǎn)設(shè)置機(jī)構(gòu)、數(shù)據(jù)恢復(fù)以及重新啟動(dòng)是否正確。 如果這一恢復(fù)需要人為干預(yù)，則應(yīng)考慮平均修復(fù)時(shí)間是否在限定的、可以接受的范圍之內(nèi)。103安全測(cè)試安全測(cè)試的目的在于驗(yàn)證安裝在系統(tǒng)內(nèi)的保護(hù)機(jī)制能否在實(shí)際中保護(hù)系統(tǒng)且不受非法入侵，不受各種非法干擾。在安全測(cè)試中，測(cè)試者扮演著試圖攻擊系統(tǒng)的個(gè)人角色： 嘗試去通過外部的手段來獲取系統(tǒng)的密碼 使用可以瓦解

54、任何防守的客戶軟件來攻擊系統(tǒng) 把系統(tǒng)“癱瘓”，使得其他用戶無法訪問 有目的地引發(fā)系統(tǒng)錯(cuò)誤，期望在恢復(fù)過程中侵入系統(tǒng) 通過瀏覽非保密的數(shù)據(jù)，從中找到進(jìn)入系統(tǒng)的鑰匙系統(tǒng)的安全測(cè)試要設(shè)置一些測(cè)試用例試圖突破系統(tǒng)的安全保密措施，檢驗(yàn)系統(tǒng)是否有安全保密的漏洞。 104強(qiáng)度測(cè)試從本質(zhì)上來說，強(qiáng)度測(cè)試（也稱壓力測(cè)試-Stress Testing）的目的是要檢測(cè)非正常的情形，測(cè)試是想要破壞程序。 強(qiáng)度測(cè)試需要在反常規(guī)數(shù)據(jù)量、頻率或資源的方式下運(yùn)行系統(tǒng)，以檢驗(yàn)系統(tǒng)能力的最高實(shí)際限度。 舉例： 如果正常的中斷頻率為每秒5次，強(qiáng)度測(cè)試設(shè)計(jì)為每秒50次中斷。 把輸入數(shù)據(jù)的量提高一個(gè)數(shù)量級(jí)來測(cè)試輸入功能會(huì)如何響應(yīng)。 若

55、某系統(tǒng)正常運(yùn)行可支持200個(gè)終端并行工作，強(qiáng)度測(cè)試則檢驗(yàn)1000個(gè)終端并行工作的情況。 運(yùn)行大量的消耗內(nèi)存或其他系統(tǒng)資源的測(cè)試實(shí)例。105性能測(cè)試性能測(cè)試用來測(cè)試軟件在系統(tǒng)集成中的運(yùn)行性能，特別是針對(duì)實(shí)時(shí)系統(tǒng)和嵌入式系統(tǒng)，僅提供符合功能需求但不符合性能需求的軟件是不能被接受的。性能測(cè)試可以在測(cè)試過程的任意階段進(jìn)行，但只有當(dāng)整個(gè)系統(tǒng)的所有成分都集成在一起后，才能檢查一個(gè)系統(tǒng)的真正性能。性能測(cè)試常常和強(qiáng)度（壓力）測(cè)試結(jié)合起來進(jìn)行，而且常常需要硬件和軟件測(cè)試設(shè)備，這就是說，常常有必要在一種苛刻的環(huán)境中衡量資源的使用（比如，處理器周期）。106正確性測(cè)試正確性測(cè)試檢查軟件的功能是否符合規(guī)格說明。正確性

56、測(cè)試的方法： 枚舉法，即構(gòu)造一些合理輸入，檢查是否得到期望的輸出。測(cè)試時(shí)應(yīng)盡量設(shè)法減少枚舉的次數(shù)，關(guān)鍵在于尋找等價(jià)區(qū)間，因?yàn)樵诘葍r(jià)區(qū)間中，只需用任意值測(cè)試一次即可。 邊界值測(cè)試，即采用定義域或者等價(jià)區(qū)間的邊界值進(jìn)行測(cè)試。因?yàn)槌绦蛟O(shè)計(jì)容易疏忽邊界情況，程序也容易在邊界值處出錯(cuò)。 107可靠性測(cè)試可靠性測(cè)試是從驗(yàn)證的角度出發(fā)，檢驗(yàn)系統(tǒng)的可靠性是否達(dá)到預(yù)期的目標(biāo)，同時(shí)給出當(dāng)前系統(tǒng)可能的可靠性增長情況。對(duì)可靠性性測(cè)試來說，最關(guān)鍵的測(cè)試數(shù)據(jù)包括失效間隔時(shí)間，失效修復(fù)時(shí)間，失效數(shù)量，失效級(jí)別等。根據(jù)獲得的測(cè)試數(shù)據(jù)，應(yīng)用可靠性模型，可以得到系統(tǒng)的失效率及可靠性增長趨勢(shì)?？煽啃灾笜?biāo)有時(shí)很難測(cè)試，通常采用平均無

57、故障時(shí)間或系統(tǒng)投入運(yùn)行后出現(xiàn)的故障不能大于多少數(shù)量這些指標(biāo)來對(duì)可靠性進(jìn)行評(píng)估。108兼容性測(cè)試軟件兼容性測(cè)試是檢測(cè)各軟件之間能否正確地交互和共享信息，其目標(biāo)是保證軟件按照用戶期望的方式進(jìn)行交互，使用其它軟件檢查軟件操作的過程。兼容性的測(cè)試通常需要解決以下問題： （1）新開發(fā)的軟件需要與哪種操作系統(tǒng)、Web瀏覽器和應(yīng)用軟件保持兼容，如果要測(cè)試的軟件是一個(gè)平臺(tái)，那么要求應(yīng)用程序能在其上運(yùn)行。 （2）應(yīng)該遵守哪種定義軟件之間交互的標(biāo)準(zhǔn)或者規(guī)范。 （3）軟件使用何種數(shù)據(jù)與其它平臺(tái)、與新的軟件進(jìn)行交互和共享信息。109兼容性測(cè)試（續(xù)）軟件兼容的實(shí)例：從Web頁面剪切文字，然后在文字處理程序中打開的文檔中

58、粘貼。從電子表格程序保存賬目數(shù)據(jù)，然后在另一個(gè)完全不同的電子表格程序中讀入這些數(shù)據(jù)。使圖形處理軟件在同一操作系統(tǒng)下的不同版本正常工作。使文字處理程序從聯(lián)系人管理程序中讀取姓名和地址，打印個(gè)性化的邀請(qǐng)函和信封。升級(jí)到新的數(shù)據(jù)庫程序，讀入現(xiàn)存所有數(shù)據(jù)庫，并能夠像老版本一樣對(duì)其中的數(shù)據(jù)進(jìn)行處理。110兼容性測(cè)試（續(xù)）兼容性通常有4種向前兼容與向后兼容、不同版本間的兼容、標(biāo)準(zhǔn)和規(guī)范、數(shù)據(jù)共享兼容 （1）向前兼容和向后兼容 向前兼容是指可以使用軟件的未來版本，向后兼容是指可以使用軟件的以前版本。并非所有的軟件都要求向前兼容和向后兼容，這是軟件設(shè)計(jì)者需要決定的產(chǎn)品特性。 使用文本文件可以對(duì)向前兼容和向后兼

59、容作一個(gè)簡單的演示：在Windows 98上用Notepad創(chuàng)建的文本文件，它可以向后兼容MS-DOS 1.0后的所有版本，它還可以向前兼容Windows 2000甚至以后的版本。111兼容性測(cè)試（續(xù)）在Windows 98上運(yùn)行的Notepad MYDATE.TXT在MS-DOS1.0上運(yùn)行的Edit.exe在Windows 3.1上運(yùn)行的Notepad 在Windows 95上運(yùn)行的Notepad 向后兼容在Windows 2000上運(yùn)行的WordPad在未來操作系統(tǒng)上運(yùn)行的未知軟件向前兼容112兼容性測(cè)試（續(xù)） （2）不同版本間的兼容 不同版本間的兼容是指要實(shí)現(xiàn)測(cè)試平臺(tái)和應(yīng)用軟件多個(gè)版本

60、之間能夠正常工作。舉例： 現(xiàn)在要測(cè)試一個(gè)流行的操作系統(tǒng)的新版本，當(dāng)前操作系統(tǒng)上可能有數(shù)幾十上百萬現(xiàn)有程序，則新操作系統(tǒng)的目標(biāo)是與它們百分之百兼容。因?yàn)椴豢赡茉谝粋€(gè)操作系統(tǒng)上測(cè)試所有的軟件程序，因此需要決定哪些是最重要的、必須進(jìn)行的。對(duì)于測(cè)試新應(yīng)用軟件也一樣，需要決定在哪個(gè)平臺(tái)版本上測(cè)試，以及和什么應(yīng)用程序一起測(cè)試。 113兼容性測(cè)試（續(xù)） （3）標(biāo)準(zhǔn)和規(guī)范 適用于軟件平臺(tái)的標(biāo)準(zhǔn)和規(guī)范有兩個(gè)級(jí)別高級(jí)標(biāo)準(zhǔn)和低級(jí)標(biāo)準(zhǔn)。 高級(jí)標(biāo)準(zhǔn)是產(chǎn)品應(yīng)當(dāng)普遍遵守的，例如軟件能在何種操作系統(tǒng)上運(yùn)行？是互聯(lián)網(wǎng)上的程序嗎？它運(yùn)行于何種瀏覽器？每一項(xiàng)問題都關(guān)系到平臺(tái)，假若應(yīng)用程序聲明與某個(gè)平臺(tái)兼容，就必須最受關(guān)于該平臺(tái)的標(biāo)