第2章軟件測試的策略與過程-課件

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

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

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

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

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

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

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

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

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

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

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

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

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

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

15、同。所以，靜態(tài)方法常常稱為“分析”，靜態(tài)測試是對被測程序進行特性分析方法的總稱。37靜態(tài)測試與動態(tài)測試（續(xù)）代碼檢查代碼檢查包括代碼走查、桌面檢查、代碼審查等，主要檢查代碼和設(shè)計的一致性，代碼對標(biāo)準(zhǔn)的遵循、可讀性，代碼的邏輯表達的正確性，代碼結(jié)構(gòu)的合理性等方面。代碼檢查的具體內(nèi)容：變量檢查、命名和類型審查、程序邏輯審查、程序語法檢查和程序結(jié)構(gòu)檢查等。代碼檢查的優(yōu)點：在實際使用中，代碼檢查比動態(tài)測試更有效率，能快速找到缺陷，發(fā)現(xiàn)30%70%的邏輯設(shè)計和編碼缺陷；代碼檢查看到的是問題本身而非征兆。代碼檢查的缺點：非常耗費時間，而且代碼檢查需要知識和經(jīng)驗的積累。38靜態(tài)測試與動態(tài)測試（續(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)系圖以直觀的圖形方式描述一個應(yīng)用程序中各個函數(shù)的調(diào)用和被調(diào)用關(guān)系； 控制流圖顯示一個函數(shù)的邏輯結(jié)構(gòu)，由許多節(jié)點組成，一個節(jié)點代表一條語句或數(shù)條語句，連接結(jié)點的叫邊，邊表示節(jié)點間的控制流向。39靜態(tài)測試與動態(tài)測試（續(xù)）代碼質(zhì)量度量軟件質(zhì)量包括六個方面：功能性、可靠性、易用性、效率、可維護性和可移植性。軟件的質(zhì)量是軟件屬性的各種標(biāo)準(zhǔn)度量的組合。針對軟件的可維護性，目前業(yè)界主要存在三種度量參數(shù)：Line復(fù)雜度、Halstead復(fù)雜度和McCabe復(fù)雜度。其中Line復(fù)雜度以代碼的行數(shù)作為計算的

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

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

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

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

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

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

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

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

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

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

27、試 (Execution)生成軟件測試報告 (software testing Reports)軟件問題報告SPR (Software Problem Report)測試結(jié)果報告 (test result Reports)57一個實用軟件測試過程（續(xù)）基本特性：（1）計劃性: 任務(wù) 人員 設(shè)備 時間 相關(guān).（2）平行性: 開發(fā) 編碼 | 測試 再測試（3）完整性: 計劃+大綱+用例+SPRs+.（4）重用性: 測試 再測試 回歸測試 升級 多平臺（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軟件測試計劃一個大中型軟件系統(tǒng)的測試必須經(jīng)歷一個相當(dāng)復(fù)雜的測試過程，并且常常需要經(jīng)歷數(shù)月乃至史長時間，需要投入相當(dāng)可觀的人力和物力資源，所以針對整個項目的預(yù)定目標(biāo)和可能的實際條件，對系統(tǒng)的測試過程事先進行認(rèn)真的計劃，軟件測試計劃可分為3個層次。 1)概要測試計劃:是軟件項目實施計劃中的一項重要內(nèi)容，應(yīng)當(dāng)在軟件開發(fā)初期，即需求分析階段制定。這項計劃應(yīng)當(dāng)定義被測試對象和測試目標(biāo);確定測試階段和測試周期的劃分;制定測試人員、軟硬件資源和測試進度等方而的計劃;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

44、成在結(jié)構(gòu)中的一個主控路徑下的所有模塊，主控路徑的選擇是任意的。 廣度優(yōu)先方式的集成： 首先沿著水平方向，把每一層中所有直接隸屬于上一層的模塊集成起來，直到底層。86自頂向下增量式測試（續(xù)）集成測試的整個過程由3個步驟完成： （1）主控模塊作為測試驅(qū)動器。 （2）根據(jù)集成的方式（深度或廣度），下層的樁模塊一次一次地被替換為真正的模塊。 （3）在每個模塊被集成時，都必須進行單元測試。 重復(fù)第2步，直到整個系統(tǒng)被測試完成。 實例 按照廣度優(yōu)先方式進行集成測試 實例 按照深度優(yōu)先方式進行集成測試87自頂向下增量式測試（續(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自頂向下增量式測試（續(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自底向上增量式測試自底向上增量式測試表示逐步集成和逐步測試的工作是按結(jié)構(gòu)圖自下而上進行的，即從程序模塊結(jié)構(gòu)的最底層模塊開始集成和測試。由于是從最底層開始集成，對于一個給定層次的模塊，它的子模塊（包括子模塊的所有下屬模塊）已經(jīng)集成并測試完成，所以不再需要使用樁模塊進行輔助測試。在模塊的測試過程中需要從子模塊得到的信息可以直接運行子模塊得到。 實例 采用自底向上增量式測試方法進行集成測試90自

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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