軟件測試策略與過程

軟件測試策略與過程第一頁，共三十一頁，2022年，8月28日本章教學(xué)目標(biāo)理解軟件測試的復(fù)雜性理解軟件測試的方法與策略明確單元測試的主要任務(wù)和過程明確集成測試的方法和確認測試的準(zhǔn)則明確系統(tǒng)測試的八個領(lǐng)域測試要點明確驗收測試的主要內(nèi)容和相關(guān)配置第二頁，共三十一頁，2022年，8月28日2.1軟件測試的復(fù)雜性分析1、無法對程序進行完全測試（1）測試所需要的輸入量太大（2）測試的輸出結(jié)果太多（3）軟件實現(xiàn)的途徑太多（4）軟件規(guī)格說明沒有一個客觀標(biāo)準(zhǔn)2、測試無法顯示潛在的軟件缺陷和故障

——通過軟件測試只能報告軟件已被發(fā)現(xiàn)的缺陷和故障，無法報告隱藏的軟件故障。3、存在的故障現(xiàn)象與發(fā)現(xiàn)的故障數(shù)量成正比

——結(jié)論：應(yīng)當(dāng)對故障集中的程序段進行重點測試第三頁，共三十一頁，2022年，8月28日軟件測試的復(fù)雜性分析（續(xù)）

4、不能修復(fù)所有的軟件故障

——原因：沒有足夠的時間進行修復(fù)；修復(fù)的風(fēng)險較大；不值得修復(fù)；可不算做故障的一些缺陷；“殺蟲劑現(xiàn)象”。

結(jié)論：關(guān)鍵是要進行正確的判斷、合理的取舍，根據(jù)風(fēng)險分析決定哪些故障必須修復(fù)，哪些故障可以不修復(fù)。

第四頁，共三十一頁，2022年，8月28日軟件測試的復(fù)雜性分析（續(xù)）

5、軟件測試的代價

——工作原則：針對軟件風(fēng)險做出恰當(dāng)選擇，去粗存精，找到最佳的測試量，既能達到測試的目的，又能較為經(jīng)濟。

第五頁，共三十一頁，2022年，8月28日2.2軟件測試方法與策略2.2.1靜態(tài)測試與動態(tài)測試2.2.2黑盒測試與白盒測試2.2.3軟件測試過程Return第六頁，共三十一頁，2022年，8月28日軟件測試策略什么是軟件測試策略？

——是為軟件工程過程定義的一個軟件測試的模板，也就是把特定的測試用例方法放置進去的一系列步驟。軟件測試策略的特征：（1）測試從模塊層開始，然后擴大延伸到整個基于計算機的系統(tǒng)集合中。（2）不同的測試技術(shù)適用于不同的時間點。（3）測試是由軟件的開發(fā)人員和（對于大型系統(tǒng)而言）獨立的測試組來管理的。（4）測試和調(diào)試是不同的活動，但是調(diào)試必須能夠適應(yīng)任何的測試策略。第七頁，共三十一頁，2022年，8月28日軟件測試充分性準(zhǔn)則P40對任何軟件都存在有限的充分測試集合。如果一個軟件系統(tǒng)在一個測試數(shù)據(jù)集合上的測試是充分的，那么再多測試一些數(shù)據(jù)也應(yīng)該是充分的。這一特性稱為單調(diào)性。即使對軟件所有成分都進行了充分的測試，也并不表明整個軟件的測試已經(jīng)充分了。這一特性稱為非復(fù)合性。即使對軟件系統(tǒng)整體的測試是充分的，也并不意味軟件系統(tǒng)中各個成分都已經(jīng)充分地得到了測試。這個特性稱為非分解性。軟件測試的充分性應(yīng)該與軟件的需求和軟件的實現(xiàn)都相關(guān)。軟件越復(fù)雜，需要的測試數(shù)據(jù)就越多。這一特性稱為復(fù)雜性。測試得越多，進一步測試所能得到的充分性增長就越少。這一特性稱為回報遞減率。請同學(xué)們自己慢慢體會以下定義：第八頁，共三十一頁，2022年，8月28日2.2.1靜態(tài)測試與動態(tài)測試根據(jù)程序是否運行，測試分為靜態(tài)測試與動態(tài)測試。1.靜態(tài)測試：指不實際運行被測軟件，只是靜態(tài)地檢查程序代碼、界面或文檔中可能存在的錯誤的過程，主要是對軟件的編程格式、結(jié)構(gòu)等方面進行評估。包括三個方面：對于代碼測試：主要測試代碼是否符合相應(yīng)的標(biāo)準(zhǔn)和規(guī)范。對于界面測試：主要測試軟件的實際界面與需求中的說明是否符合。對于文檔測試：主要測試用戶手冊和需求說明是否真正符合用戶的實際需求。

第九頁，共三十一頁，2022年，8月28日案例1：C語言程序的靜態(tài)分析和動態(tài)測試#include<stdio.h>max(floatx,floaty)floatz;z=x>y?x:yreturn(z);}main(){floata,b;intc;scanf(“%f,%f”,&a,&b);c=max(a,b);printf(“Maxis%d\n”,c);}第十頁，共三十一頁，2022年，8月28日案例1修改后，如下#include<stdio.h>max(floatx,floaty)//返回兩個單精度數(shù)中的大數(shù)

{floatz;z=x>y?x:yreturn(z);}main(){floata,b,c;scanf(“%f,%f”,&a,&b);c=max(a,b);printf(“Maxis%d\n”,c);}

可參考C語言編碼規(guī)范第十一頁，共三十一頁，2022年，8月28日2.2.1靜態(tài)測試與動態(tài)測試靜態(tài)測試：靜態(tài)測試包括代碼檢查、靜態(tài)結(jié)構(gòu)分析、代碼質(zhì)量度量等。它可以由人工進行，也可以借助軟件工具自動進行。靜態(tài)測試方法也可稱為“靜態(tài)分析”。第十二頁，共三十一頁，2022年，8月28日靜態(tài)測試與動態(tài)測試（續(xù)）

代碼檢查代碼檢查包括代碼走查、桌面檢查、代碼審查等，主要檢查代碼和設(shè)計的一致性，代碼對標(biāo)準(zhǔn)的遵循、可讀性，代碼的邏輯表達的正確性，代碼結(jié)構(gòu)的合理性等方面。具體內(nèi)容：變量檢查、命名和類型審查、程序邏輯審查、程序語法檢查和程序結(jié)構(gòu)檢查等。優(yōu)點：實際使用中，能快速找到缺陷，發(fā)現(xiàn)30%～70%的邏輯設(shè)計和編碼缺陷；。缺點：耗費時間，需要知識和經(jīng)驗的積累。第十三頁，共三十一頁，2022年，8月28日靜態(tài)測試與動態(tài)測試（續(xù)）

靜態(tài)結(jié)構(gòu)分析靜態(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é)點間的控制流向。第十四頁，共三十一頁，2022年，8月28日靜態(tài)測試與動態(tài)測試（續(xù)）

代碼質(zhì)量度量軟件質(zhì)量包括六個方面：功能性、可靠性、易用性、效率、可維護性和可移植性。軟件的質(zhì)量是軟件屬性的各種標(biāo)準(zhǔn)度量的組合。針對軟件的可維護性，目前業(yè)界主要存在三種度量參數(shù)：Line復(fù)雜度、Halstead復(fù)雜度和McCabe復(fù)雜度。其中Line復(fù)雜度以代碼的行數(shù)作為計算的基準(zhǔn)。Halstead以程序中使用到的運算符與運算元數(shù)量作為計數(shù)目標(biāo)（直接測量指標(biāo)），然后可以據(jù)以計算出程序容量、工作量等。McCabe復(fù)雜度一般稱為圈復(fù)雜度，它將軟件的流程圖轉(zhuǎn)化為有向圖，然后以圖論來衡量軟件的質(zhì)量。第十五頁，共三十一頁，2022年，8月28日靜態(tài)測試與動態(tài)測試（續(xù)）靜態(tài)測試階段的任務(wù)：P41（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）檢查代碼是否可以優(yōu)化，算法效率是否最高。（11）檢查代碼注釋是否完整，是否正確反映了代碼的功能。第十六頁，共三十一頁，2022年，8月28日靜態(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）進行符號測試。第十七頁，共三十一頁，2022年，8月28日靜態(tài)測試與動態(tài)測試（續(xù)）2、動態(tài)測試指實際運行被測程序，輸入相應(yīng)的測試數(shù)據(jù)，檢查實際輸出結(jié)果與預(yù)期結(jié)果是否相符的過程。例如，前面的案例1，輸入數(shù)據(jù)1.2,3.5則輸出為：1.200000與預(yù)期的相符第十八頁，共三十一頁，2022年，8月28日靜態(tài)測試與動態(tài)測試（續(xù)）動態(tài)測試包括：（1）功能確認與接口測試：測試各單元功能正確性、單元間的接口等。（2）覆蓋率分析：對代碼的執(zhí)行路徑覆蓋范圍進行評估。（3）性能分析：查找性能瓶頸（4）內(nèi)存分析：測量內(nèi)存使用情況，了解內(nèi)存分配情況，找出發(fā)生錯誤的原由。第十九頁，共三十一頁，2022年，8月28日2.2.2黑盒測試和白盒測試（續(xù)）1、黑盒測試(Black-boxTesting)：指把被測軟件看作是一個黑盒子，不關(guān)心里面的結(jié)構(gòu)，只關(guān)心輸入數(shù)據(jù)和輸出結(jié)果。例如，只關(guān)心輸入x=2時，輸出結(jié)果是否為y=4。測試規(guī)劃是基于產(chǎn)品的功能。也稱為功能測試、數(shù)據(jù)驅(qū)動測試和基于規(guī)格說明的測試，實際上還包括性能測試。第二十頁，共三十一頁，2022年，8月28日輸入輸出黑盒測試是在程序接口進行測試，它只是檢查程序功能是否按照規(guī)格說明書的規(guī)定正常使用。也被稱為用戶測試。第二十一頁，共三十一頁，2022年，8月28日黑盒測試主要根據(jù)規(guī)格說明書設(shè)計測試用例，并不涉及程序內(nèi)部構(gòu)造和內(nèi)部特性，只依靠被測程序輸入和輸出之間的關(guān)系或程序的功能設(shè)計測試用例。黑盒測試的特點：（1）黑盒測試與軟件的具體實現(xiàn)過程無關(guān)，在軟件實現(xiàn)的過程發(fā)生變化時，測試用例仍然可以使用。（2）黑盒測試用例的設(shè)計可以和軟件實現(xiàn)同時進行，這樣能夠壓縮總的開發(fā)時間。第二十二頁，共三十一頁，2022年，8月28日黑盒測試主要用于發(fā)現(xiàn)以下幾類錯誤：是否有不正確或遺漏了的功能？在接口上，輸入能否正確地接受？能否輸出正確的結(jié)果？是否有數(shù)據(jù)結(jié)構(gòu)錯誤或外部信息訪問錯誤？性能上是否滿足用戶需求？是否有初始化或終止性錯誤？黑盒測試的具體技術(shù)方法：邊界值分析法等價類劃分法因果圖法決策表法第二十三頁，共三十一頁，2022年，8月28日2、白盒測試(White-boxTesting)：指將被測軟件看作一個打開的盒子，研究盒子里面的代碼和程序結(jié)構(gòu)。測試規(guī)劃基于產(chǎn)品的內(nèi)部結(jié)構(gòu)。

又稱為結(jié)構(gòu)測試，一般用來分析程序的內(nèi)部結(jié)構(gòu)。

第二十四頁，共三十一頁，2022年，8月28日白盒測試需要完全了解程序結(jié)構(gòu)和處理過程，它按照程序內(nèi)部邏輯測試程序，檢驗程序中每條通路是否按預(yù)定要求正確工作。也被稱為程序員測試。應(yīng)用程序第二十五頁，共三十一頁，2022年，8月28日白盒測試要求是對某些程序的結(jié)構(gòu)特性做到一定程度的覆蓋，或者說這種測試是“基于覆蓋率的測試”。通常的程序結(jié)構(gòu)覆蓋有：語句覆蓋判定覆蓋條件覆蓋判定/條件覆蓋路徑覆蓋第二十六頁，共三十一頁，2022年，8月28日？X=2

y=2xY=4X=2Y=4未知等式與已知等式黑盒白盒3、黑盒測試法和白盒測試法的比較第二十七頁，共三十一頁，2022年，8月28日黑盒測試和白盒測試的比較P45黑盒測試：

——根據(jù)輸入數(shù)據(jù)與輸出數(shù)據(jù)的對應(yīng)關(guān)系進行測試，而不考慮內(nèi)部結(jié)構(gòu)及工作情況。

——注重于軟件的范圍，通過劃分程序的輸入和輸出域來確定測試用例。

——若外部特性本身存在問題或規(guī)格說明的規(guī)定有誤，則應(yīng)用黑盒測試方法是不能發(fā)現(xiàn)問題的。白盒測試：

——只根據(jù)程序的內(nèi)部結(jié)構(gòu)進行測試。

——測試用例的設(shè)計要保證測試時程序的所有語句至少執(zhí)行一次，而且要檢查所有的邏輯條件。

——如果程序的結(jié)構(gòu)本身有問題，比如說程序邏輯有錯誤或者有遺漏，那也是無法發(fā)現(xiàn)的。第二十八頁，共三十一頁，2022年，8月28日項目黑盒測試法白盒測試法規(guī)劃方面功能和性能的測試結(jié)構(gòu)的測試優(yōu)點方面能確保從用戶的角度出發(fā)進行測試能對程序內(nèi)部的特定部位進行覆蓋測試缺點方面無法測試程序內(nèi)部特定部位；當(dāng)規(guī)格說明有誤，則不能發(fā)現(xiàn)問題無法檢查程序的外部特性；無法對未實現(xiàn)規(guī)格說明的程序內(nèi)部欠缺部分進行