SCU白盒測試課件

白盒測試

White-boxtesting

任課老師：黃武2024/3/31白盒測試

White-boxtesting

任課老師：黃武1提綱白盒測試概述靜態(tài)白盒測試動態(tài)白盒測試2024/3/31提綱白盒測試概述2024/3/3121.白盒測試概述白盒測試概念白盒測試過程白盒測試的應用范圍白盒測試的優(yōu)點白盒測試的缺點白盒測試的發(fā)展歷程2024/3/311.白盒測試概述白盒測試概念2024/3/3131.1白盒測試概念白盒測試是一種基于軟件內(nèi)部路徑，結構和代碼實現(xiàn)基礎上的軟件測試策略，該測試方法通常需要詳細的編程技巧例：請找出下面代碼的錯誤

voidmain() { intx;

if(x<0) x=-x; ///翻轉負數(shù) }2024/3/311.1白盒測試概念白盒測試是一種基于軟件內(nèi)部路徑，結構和代41.2白盒測試過程通用的白盒測試過程如下：分析測試軟件的內(nèi)部實現(xiàn)識別被測軟件的工作路徑選擇輸入，執(zhí)行被測路徑，并確定期望的測試結果運行測試比較真實輸出和期望輸出的異同作出被測軟件功能正確性的判斷2024/3/311.2白盒測試過程通用的白盒測試過程如下：2024/3/351.3白盒測試的應用范圍白盒測試能夠應用到所有的系統(tǒng)開發(fā)階段，包括單元測試，集成測試和系統(tǒng)測試白盒測試通常進行路徑測試，我們可以通過這種方法測試單元內(nèi)部，單元之間，子系統(tǒng)之間以及系統(tǒng)內(nèi)部的各種執(zhí)行路徑路徑（測試路徑）：從開始到結束執(zhí)行之間運行的語句序列UnitIntegrationSystem白盒測試的應用xx()y()x()y()main()…2024/3/311.3白盒測試的應用范圍白盒測試能夠應用到所有的系統(tǒng)開發(fā)階61.4白盒測試的優(yōu)點迫使測試人員去思考軟件的實現(xiàn)可以識別和測試代碼中的每條分支路徑，對代碼的測試比較徹底揭示隱藏在代碼中的錯誤或缺陷根據(jù)內(nèi)部結果進行最優(yōu)化測試2024/3/311.4白盒測試的優(yōu)點迫使測試人員去思考軟件的實現(xiàn)2024/71.5白盒測試的缺點執(zhí)行路徑可能非常多造成無法進行完全測試白盒測試假設控制流是正確的，因此測試人員只基于存在的路徑進行測試，而對于不存在的路徑則無法測試測試員必須具備編程知識，可能有很多測試員不具備這種知識，將無法進行白盒測試，比如財會人員無法對財務軟件進行白盒測試2024/3/311.5白盒測試的缺點執(zhí)行路徑可能非常多造成無法進行完全測試81.6白盒測試的發(fā)展歷程項目代數(shù)是否評估測試效果是否自動測試是否持續(xù)測試是否調(diào)測一體第一代否否否否第二代是是否否第三代是是是否第四代是是是是第1代到第4代白盒測試方法的主要差別2024/3/311.6白盒測試的發(fā)展歷程項目是否評估測試效果91.6.1白盒測試的發(fā)展歷程說明第1代白盒測試方法屬于無組織、無約束的測試方法，典型情況是拿調(diào)試當測試，或者簡單的在被測代碼中加入print、assert等語句第2代白盒測試方法主要克服第1代方法的兩大缺陷：一是沒有測試評估（比如覆蓋率），二是未對測試操作進行重用，重用測試操作必然以某種形式化語言描述測試過程。常見的第2代白盒測試工具有：Rational的RTRT、Parasoft的CppTest、IPL的Cantata++等2024/3/311.6.1白盒測試的發(fā)展歷程說明第1代白盒測試方法屬于無組101.6.1幾代白盒測試的差異說明第3代白盒測試方法區(qū)別第2代方法最主要特點是：它支持持續(xù)集成的操作模式，這在理念上有了一次飛躍。第3代白盒方法主要代表是xUnit系列測試工具，如JUnit、NUnit、DUnit等第4代白盒測試方法相對第3代方法，主要是引入了調(diào)測一體的理念。遵循第4代白盒測試方法的測試工具主要以VcTester為代表2024/3/311.6.1幾代白盒測試的差異說明第3代白盒測試方法區(qū)別第2112靜態(tài)白盒測試靜態(tài)白盒測試概述正式審查編碼標準和規(guī)范通用代碼審查清單2024/3/312靜態(tài)白盒測試靜態(tài)白盒測試概述2024/3/31122.1靜態(tài)白盒測試概述靜態(tài)白盒測試是指在不執(zhí)行軟件的條件下有條理地仔細審查軟件設計、體系結構和代碼，從而找出軟件缺陷的過程，有時又稱為結構分析對于要求嚴格的代碼，比如軍隊，金融，工業(yè)控制，醫(yī)藥類軟件，通常會自覺組織靜態(tài)白盒測試2024/3/312.1靜態(tài)白盒測試概述靜態(tài)白盒測試是指在不執(zhí)行軟件的條件下132.1.1靜態(tài)白盒測試的原因靜態(tài)白盒測試可以從整體上把握軟件代碼的質量，比如可以輕易找到代碼不合規(guī)范的地方進行靜態(tài)白盒測試可以盡早發(fā)現(xiàn)軟件缺陷，便于及時改進靜態(tài)白盒測試為動態(tài)測試準備的案例提供思路2024/3/312.1.1靜態(tài)白盒測試的原因靜態(tài)白盒測試可以從整體上把握軟14靜態(tài)白盒測試的原因2024/3/31靜態(tài)白盒測試的原因2024/3/31152.1.2靜態(tài)白盒測試的困難由于靜態(tài)白盒測試投入高，耗時多，而且沒有直接的產(chǎn)出，很多公司難于接受，往往不能善始善終靜態(tài)白盒測試要求公司具有對編程標準和規(guī)范了解深刻的程序員，但很多公司不具備這種程序員，造成執(zhí)行困難靜態(tài)白盒測試可能會減緩軟件開發(fā)的進度2024/3/312.1.2靜態(tài)白盒測試的困難由于靜態(tài)白盒測試投入高，耗時多162.2正式審查正式審查是進行靜態(tài)白盒測試的過程，其含義廣泛，從兩個程序員之間的交談，到代碼的嚴格檢查均屬于此正式審查是一個逐步建立的過程。如果正確進行正式審查，這將是早期發(fā)現(xiàn)軟件缺陷的好方法2024/3/312.2正式審查正式審查是進行靜態(tài)白盒測試的過程，其含義廣泛172.2.1正式審查的4個要素審查準備 每一個合作者都要精心準備，他們在審查中扮演不同角色，比如程序員，測試員，管理員等，明確自己的責任和義務。很多問題是在準備階段發(fā)現(xiàn)的遵守規(guī)則 審查要遵守一套固定的規(guī)則，比如設定要評審的代碼量，花費的時間，審查的形式，哪些需要備注等2024/3/312.2.1正式審查的4個要素審查準備2024/3/31182.2.1正式審查的4個要素確定問題 審查的目標是找出軟件的問題，包括錯誤和遺漏。在審查時，只針對代碼而不要針對程序員，避免相互指責編寫審查報告 審查小組必須做出總結審查結果的書面報告，并使報告便于開發(fā)小組的成員使用2024/3/312.2.1正式審查的4個要素確定問題2024/3/31192.2.2正式審查的間接效果交流——審查成員之間加強了交流，從而相互理解，相互學習質量——程序員的代碼通過逐行審查，不僅提高審查代碼的質量，同時也對程序員起到促進作用2024/3/312.2.2正式審查的間接效果交流——審查成員之間加強了交流202.2.3同事審查同事審查是指在編寫代碼的程序員和充當審查員的程序員或測試員之間進行的小范圍正式審查，這是最簡單的正式審查，又被稱為伙伴審查為了避免同事審查流于形式，同事審查也要保證正式審查的4個關鍵要素：審查準備，遵守規(guī)則，確定問題以及編寫審查報告2024/3/312.2.3同事審查同事審查是指在編寫代碼的程序員和充當審查212.2.4公開陳述公開陳述是使同事審查正規(guī)化的下一步。編程人員需要向專門組成的審查小組公開陳述代碼，包括逐行的解釋代碼，說明代碼的工作原理等，審查人員則需要提出問題在進行公開陳述之前，程序員要向審查人員提供代碼，以便審查人員事先檢查和提出問題在審查人員中至少有一位資深的程序員2024/3/312.2.4公開陳述公開陳述是使同事審查正規(guī)化的下一步。編程222.2.5檢驗檢驗是最正式的審查類型，具有高度的組織化，要求每一個參與者都接受訓練檢驗與公開陳述的不同之處在于表述代碼的人員不是代碼的編寫者，這要求他學習和了解表述的材料，從而有可能在檢驗會議上提出不同的看法和解釋另外的參與者稱為檢驗員，其職責是從不同角度，例如用戶、測試人員或者產(chǎn)品支持人員的角度去審查代碼檢驗經(jīng)證實是在所有軟件交付內(nèi)容中，特別是設計文檔和代碼中發(fā)現(xiàn)軟件缺陷的最有效方法2024/3/312.2.5檢驗檢驗是最正式的審查類型，具有高度的組織化，要232.3編碼標準和規(guī)范標準（Standard）——1986年國際標準化組織發(fā)布的ISO第2號指南中提出的標準定義（草案）是：“得到一致（絕大多數(shù)）同意，并經(jīng)公認的標準化團體批準，作為工作或工作成果的衡量準則、規(guī)則或特性要求，供（有關各方）共同重復使用的文件，目的是在給定范圍內(nèi)達到最佳有序化程度?！睒藴时容^嚴格，有些標準帶有強制性規(guī)范（Specification）——某一范疇內(nèi)以明文規(guī)定或約定俗成的形式規(guī)定的規(guī)則規(guī)范相對標準而言比較放松一些，不具有強制性2024/3/312.3編碼標準和規(guī)范標準（Standard）——1986年242.3.1堅持編碼標準和規(guī)范的原因堅持符合標準和規(guī)范編碼的三個重要原因：可靠性——嚴格按照某種標準或規(guī)范編寫的代碼比不這樣做的代碼更加可靠，缺陷更少可讀性/維護性——符合標準和規(guī)范的代碼易于閱讀、理解和維護可移植性——代碼經(jīng)常在不同的硬件上運行，或者使用不同的編譯器，如果代碼遵循設備標準，將更容易使軟件具有移植性軟件審查小組在開始審查前需要了解相應的標準和規(guī)范2024/3/312.3.1堅持編碼標準和規(guī)范的原因堅持符合標準和規(guī)范編碼的252.3.2標準或規(guī)范的格式軟件標準通常由4個部分組成標題：描述標準包含的主題內(nèi)容：描述標準或規(guī)范內(nèi)容解釋說明：給出標準背后的原因，以使程序員理解采用標準的原因示例：給出如何使用標準的簡單程序示例，這是可選擇的2024/3/312.3.2標準或規(guī)范的格式軟件標準通常由4個部分組成202262.3.3標準或規(guī)范的示例TOPIC:3.05Control-RestrictiononcontrolstructuresSTANDARD Thegotostatement(andhencelabelsaswell)shouldnotbeused. Thewhileloopshouldbeusedinsteadofthedo-whileloop,exceptwherethelogicoftheproblemexplicitrequiresdoingthebodyatleastonceregardlessofloopcondition. Ifasingleif-elsecanreplaceacontinue,andif-elseshouldbeusedJUSTIFICATION Thegotostatementisprohibitedfortheempiricalreasonthatitsuseishighlycorrelatedwitherrorsandhare-to-readcode,andfortheabstractreasonthatalgorithmsshouldbeexpressedinstructuresthatfacilitatecheckingtheprogramagainstthe…2024/3/312.3.3標準或規(guī)范的示例TOPIC:3.05Cont27

標準或規(guī)范的示例1TOPIC:7.02 C_problems–problemareasfromCGUIDELINE TrytoavoidClanguagefeaturesifaconflictwithprogramminginC++DonotmixC-styleFILEI/O(usingstdio.h)withC++styleI/O(usingiostream.horstream.h)onthesamefile.AvoidusingCfunctionslikememcpyormemcmpforcopyingorcomparingobjectsofatypeotherthanarray-of-charorjust-a-struct.AvoidtheCmacroNULL;use0instead.JUSTIFICATION EachofthesefeaturesconcernsanareaoftraditionalCusagewhichcreatessomeprobleminC++.2024/3/31標準或規(guī)范的示例1TOPIC:7.02 28

公司內(nèi)部的規(guī)范示例TOPIC:sentence每行一個語句每行最多包含一個語句。如 a++; //推薦

b--; //推薦 a++;b--; //不推薦2024/3/31公司內(nèi)部的規(guī)范示例TOPIC:senten292.3.4標準或規(guī)范的資源2024/3/312.3.4標準或規(guī)范的資源2024/3/3130

標準或規(guī)范的資源網(wǎng)站1全國信息技術標準化網(wǎng)/2024/3/31標準或規(guī)范的資源網(wǎng)站1全國信息技術標準化網(wǎng)31

標準或規(guī)范的資源網(wǎng)站2電氣電子工程師協(xié)會2024/3/31標準或規(guī)范的資源網(wǎng)站2電氣電子工程師協(xié)會322.3.5程序風格遵循不同的標準、規(guī)范（包括自己的）就形成了程序員的編程風格比如在函數(shù)前進入注釋，每行代碼不超過100列寬，遵循嚴格的縮進格式良好的代碼風格是代碼維護的基礎，比如/************************************************************** FUNCTION:voidFill_Scan_Disp_Data(DWORDdwStart,intiNum,short*p) PURPOSE: Thisfunctionfillpdatatodisplayingbuffer. PARAMETERS:dwStart ->displaybufferstartposition. iNum ->thedatanumbertofilldisplayingbuf. *p ->Temporarydatabufferpointer.

RETURN: None.*************************************************************/voidCTM_WAVEDoc::Fill_Scan_Disp_Data(DWORDdwStart,intiNum,short*p){ …}2024/3/312.3.5程序風格遵循不同的標準、規(guī)范（包括自己的）就形成332.4通用代碼審查清單數(shù)據(jù)引用錯誤數(shù)據(jù)聲明錯誤計算錯誤比較錯誤控制流錯誤子程序參數(shù)錯誤輸入/輸出錯誤其他錯誤2024/3/312.4通用代碼審查清單數(shù)據(jù)引用錯誤2024/3/31342.4.1數(shù)據(jù)引用錯誤數(shù)據(jù)引用錯誤是指使用未經(jīng)正確初始化和引用方式的變量、常量、數(shù)據(jù)、字符串等導致的軟件缺陷，包括：是否引用了未初始化的變量數(shù)組和字符串的下標是否為整數(shù)，是否未訪問邊界或越界是否在使用常量的地方使用了變量變量是否被賦予不同類型的值使用了未分配內(nèi)存指針嗎等2024/3/312.4.1數(shù)據(jù)引用錯誤數(shù)據(jù)引用錯誤是指使用未經(jīng)正確初始化和35

數(shù)據(jù)引用錯誤舉例變量被賦于不同數(shù)據(jù)類型的值2024/3/31數(shù)據(jù)引用錯誤舉例變量被賦于不同數(shù)據(jù)類型的值2362.4.2數(shù)據(jù)聲明錯誤數(shù)據(jù)聲明錯誤的原因是不正確地聲明或使用變量和常量，包括：所有變量都賦予了正確的長度、類型嗎？變量是否在聲明的同時進行了初始化存在聲明過但從未引用過的變量嗎在特定模塊中所有變量都顯示聲明了嗎？如果沒有，是否可以理解為該變量與更高級別的模塊共享（全局變量）2024/3/312.4.2數(shù)據(jù)聲明錯誤數(shù)據(jù)聲明錯誤的原因是不正確地聲明或使37

數(shù)據(jù)聲明錯誤舉例intGet_Max_Value(intstart,intiNum,short*p){

short max,min; max=*(p+start); //Thefirstvalueevaluatetomax

for(inti=start+1;i<start+iNum;i++)

if(max<*(p+i)) max=*(p+i);

return(max);}min變量申明后從未使用過2024/3/31數(shù)據(jù)聲明錯誤舉例intGet_Max_Va382.4.3計算錯誤計算錯誤是基本的數(shù)據(jù)邏輯問題，即不能得到正確的計算結果，包括：計算中是否使用了不同數(shù)據(jù)類型的變量賦值的目的變量是否小于賦值的源變量在數(shù)值計算中是否可能出現(xiàn)溢出除數(shù)/模是否可能為0對于整形運算，是否會丟失精度變量的值是否超過有意義的范圍對于包含多個操作數(shù)據(jù)求值表達式是否不清晰2024/3/312.4.3計算錯誤計算錯誤是基本的數(shù)據(jù)邏輯問題，即不能得到39

計算錯誤舉例intGet_Ave_Value(intstart,intiNum,short*p){

int ave =0;

int sum=*(p+start);

for(inti=start+1;i<start+iNum;i++) sum+=*(p+i); ave=sum/iNum; //ifiNum=0，It’serror

return(ave);}2024/3/31計算錯誤舉例intGet_Ave_Valu402.4.4比較錯誤小于、大于、等于、不等于、真、假等比較和判斷邏輯錯誤，可能造成邊界條件問題，包括：比較正確嗎，應該使用小于還是小于等于精度會影響浮點數(shù)之間的比較結果嗎？1.00000001和1.00000002是否相等每一個邏輯表達式都正確計算嗎，次序正確嗎邏輯表達式的值都是邏輯值嗎，是否包含整數(shù)的整形變量2024/3/312.4.4比較錯誤小于、大于、等于、不等于、真、假等比較和41

比較錯誤舉例intRead_Queue_Data(intiNum,long*buf){

//1.------------------setreverseflag.-------------------------------- if(rp+iNum>iQueue_Size) bReverse_Flag=false;

//2.------------------Readactualdatafromqueue.--------------

for(inti=0;i<iNum;i++) *(buf+i)=*(lpData+(rp+i)%iQueue_Size); rp=(rp+iNum)%iQueue_Size;//Modifythereadpointer

return(iNum);}>和>=混淆引發(fā)錯誤2024/3/31比較錯誤舉例intRead_Queue_D422.4.5控制流錯誤控制流程錯誤的原因是編程語言中循環(huán)等控制結構未按預期方式工作，他們通常由計算或比較錯誤直接或間接引起，包括：復合語句是否配對程序、模塊、子程序和循環(huán)能否終止可能存在死循環(huán)嗎循環(huán)可能從不執(zhí)行嗎在switch…case語句中超出分支范圍是否處理2024/3/312.4.5控制流錯誤控制流程錯誤的原因是編程語言中循環(huán)等控43

控制流錯誤舉例switch(iType){

case LABEL_TYPE_GENERAL: Draw_A_Label(i,pDC,label,rect);

break;

case LABEL_TYPE_STIMULATE: Draw_A_Sti_Label(i,pDC,label,rect);

break;

case LABEL_TYPE_DROP: Draw_A_Drop_Label(i,pDC,label,rect);

break;}如果不出現(xiàn)上面三種情況，程序如何處理？2024/3/31控制流錯誤舉例switch(iType442.4.6子程序參數(shù)錯誤子程序參數(shù)錯誤的來源是軟件子程序不正確地傳遞參數(shù)，包括：子程序接收的參數(shù)類型和大小與調(diào)用代碼發(fā)送的實參匹配嗎如果子程序有多個入口點，引用的參數(shù)是否與當前入口點沒有關聯(lián)常量是否當作形參傳遞，意外在子程序中改動子程序是否更改了僅作為輸入值的參數(shù)每一個參數(shù)的單位與相應的形參匹配嗎——比如ms和s，ml和l等2024/3/312.4.6子程序參數(shù)錯誤子程序參數(shù)錯誤的來源是軟件子程序不452.4.7輸入/輸出錯誤輸入/輸出錯誤包括文件讀取、鍵盤或鼠標輸入以及打印機輸出等設備寫入錯誤，包括：軟件是否遵守外部設備讀寫數(shù)據(jù)的專用格式文件或者外設不存在或未準備好如何處理外設未連接、不可用或者讀寫過程中存貯器滿如何處理檢查錯誤提示信息的準確性，正確性以及語法和拼寫等2024/3/312.4.7輸入/輸出錯誤輸入/輸出錯誤包括文件讀取、鍵盤或462.4.8其他錯誤其他錯誤包括：軟件是否存在國際化問題軟件是否要運行在不同的操作系統(tǒng)下是否考慮了軟件的硬件兼容性，比如內(nèi)存、圖形捕獲卡等程序編譯是否產(chǎn)生了警告或提示信息，這些信息通常指示進行了有疑問的處理2024/3/312.4.8其他錯誤其他錯誤包括：2024/3/31472.4.9通用代碼審查清單總結上面的通用代碼審查清單在我們進行靜態(tài)白盒測試時起到指南的作用由于上面的錯誤具有通用性，目前很多系統(tǒng)的編譯器都能夠對這些錯誤進行檢查，如果我們提高編譯器檢查錯誤的等級，那么它會列舉出很多這樣的錯誤供我們參考2024/3/312.4.9通用代碼審查清單總結上面的通用代碼審查清單在我們48在VC6.0中設置編譯警告級別選擇“Project”菜單下的“Settings”命令進入2024/3/31在VC6.0中設置編譯警告級別選擇“Project”菜單493動態(tài)白盒測試動態(tài)白盒測試概述動態(tài)白盒測試和調(diào)試分段測試數(shù)據(jù)范圍控制流測試2024/3/313動態(tài)白盒測試動態(tài)白盒測試概述2024/3/31503.1動態(tài)白盒測試概述動態(tài)白盒測試是指利用查看代碼功能和實現(xiàn)方式得到的信息來確定哪些要測試，哪些不測試，如何開展測試，又稱為結構測試2024/3/313.1動態(tài)白盒測試概述動態(tài)白盒測試是指利用查看代碼功能和實513.1.1動態(tài)白盒測試的內(nèi)容直接測試底層功能、過程、子程序和庫以完整程序的方式從頂層測試軟件，但是根據(jù)對軟件運行的了解調(diào)整測試案例從軟件獲得讀取變量和狀態(tài)信息的訪問權，以便確定測試與預期結果是否相符，同時，強制軟件以正常測試難以實現(xiàn)的方式運行估算執(zhí)行測試時覆蓋的代碼量，然后調(diào)整測試，去掉多余的，補充遺漏的2024/3/313.1.1動態(tài)白盒測試的內(nèi)容直接測試底層功能、過程、子程序523.2動態(tài)白盒測試和調(diào)試動態(tài)白盒測試的目標是尋找軟件缺陷，調(diào)試的目標是修復軟件缺陷進行動態(tài)白盒測試，需要使用與程序員相同的工具，了解程序的運行狀態(tài)動態(tài)白盒子分離軟件缺陷調(diào)試調(diào)試編程測試動態(tài)白盒測試和調(diào)試的關系2024/3/313.2動態(tài)白盒測試和調(diào)試動態(tài)白盒測試的目標是尋找軟件缺陷，533.3分段測試一開始就對程序進行整體測試，可能會造成兩個缺陷：難以找到導致問題的原因，因為受到眾多因素的影響某些缺陷掩蓋了其他缺陷，導致一個缺陷解決馬上又引起新的缺陷2024/3/313.3分段測試一開始就對程序進行整體測試，可能會造成兩個缺543.3.1單元和集成測試我們應該采取代碼分段建立和測試的策略，這樣容易形成穩(wěn)定的代碼主程序模塊1模塊2模塊11模塊111模塊112模塊113模塊21模塊22模塊12獨立建立代碼模塊并分別測試，然后再集成測試2024/3/313.3.1單元和集成測試我們應該采取代碼分段建立和測試的策553.3.2單元測試在底層進行的測試被稱為單元測試或模塊測試采取這種測試策略很容易隔離軟件缺陷在單元級發(fā)現(xiàn)問題時，問題肯定在單元中在多個單元集成時發(fā)現(xiàn)軟件缺陷，那么它通常與模塊之間的交互相關2024/3/313.3.2單元測試在底層進行的測試被稱為單元測試或模塊測試56

自底向上的單元測試自底向上的測試中，需要編寫稱為測試驅動的模塊以進行單元測試測試驅動模塊以將來真正模塊同樣的方式掛接，向處于測試的模塊發(fā)送測試案例數(shù)據(jù)，接受返回結果，并驗證正確性實際軟件華式到攝氏度轉換模塊溫度數(shù)據(jù)結果測試驅動模塊華式到攝氏度轉換模塊測試案例數(shù)據(jù)結果模擬2024/3/31自底向上的單元測試自底向上的測試中，需要編寫57

自頂向下的單元測試自頂向下的測試中，是對完成的高層軟件進行測試，而下層軟件則使用存根代碼來模擬這樣做的目的是測試在實際中不宜出現(xiàn)的數(shù)據(jù)，因為存根軟件可以按要求產(chǎn)生各種數(shù)據(jù)溫度顯示模塊溫度計接口模塊測試過的溫度顯示模塊測試員書寫的存根模塊模擬測試文件實際配置測試配置2024/3/31自頂向下的單元測試自頂向下的測試中，是對完成583.4數(shù)據(jù)范圍由于軟件可以分為數(shù)據(jù)和狀態(tài)，白盒測試也包含數(shù)據(jù)測試和狀態(tài)測試數(shù)據(jù)包括常量、變量、數(shù)組、結構，鍵盤和鼠標輸入、文件、屏幕輸出，網(wǎng)絡輸入\輸出等數(shù)據(jù)流范圍主要是指在整個軟件中跟蹤一批數(shù)據(jù)如果在底層測試函數(shù)，就會使用調(diào)試器觀察變量在運行期間值的變化2024/3/313.4數(shù)據(jù)范圍由于軟件可以分為數(shù)據(jù)和狀態(tài)，白盒測試也包含數(shù)593.4.1次邊界在白盒測試中，我們通過查看代碼，找到程序內(nèi)部的次邊界，然后建立他們的測試案例下面是程序內(nèi)部的一些次邊界的例子：計算時從采用數(shù)據(jù)表轉換為使用公式為了獲得更高的精度，復雜的數(shù)值分析程序根據(jù)數(shù)字大小切換不同的處理方式2024/3/313.4.1次邊界在白盒測試中，我們通過查看代碼，找到程序內(nèi)603.4.2公式和等式查看公式中存在的數(shù)據(jù)隱患，例如計算銀行復利的公式如下： A=P(1+r/n)nt其中：P=本金 r=年利率 t=年數(shù) n=每年復加的利率次數(shù) A=若干年的本息總和

在上面的代碼中，如果設定n=0，就會造成代碼崩潰2024/3/313.4.2公式和等式查看公式中存在的數(shù)據(jù)隱患，例如計算銀行613.4.4錯誤強制有些數(shù)據(jù)在實際系統(tǒng)中很難出現(xiàn)，我們難于測試，比如連接超過10個的USB設備，屏幕的分辨率為3000像素，為了對這些情況進行測試，我們需要在調(diào)試器中強制設定相關變量的值，以便調(diào)試在這些情況下的程序運行2024/3/313.4.4錯誤強制有些數(shù)據(jù)在實際系統(tǒng)中很難出現(xiàn)，我們難于測62

錯誤強制舉例在VC6中強制修改變量的值2024/3/31錯誤強制舉例在VC6中強制修改變量的值202633.5控制流測試我們除了測試數(shù)據(jù)之外，還需要對程序的控制流進行測試我們需要測試程序的狀態(tài)以及其中的程序流程，必須設法進入和退出每一個模塊，執(zhí)行每一行代碼，追蹤每一條邏輯和決策分支，這些測試稱為控制流測試，即代碼范圍分析我們通常會使用代碼范圍分析工具作這樣的工作2024/3/313.5控制流測試我們除了測試數(shù)據(jù)之外，還需要對程序的控制流643.5.1控制流測試概述控制流測試通過識別程序代碼中的執(zhí)行路徑建立覆蓋那些路徑的測試案例不幸的是，試圖對任何適當?shù)哪K進行徹底地控制流路徑測試都是不現(xiàn)實的。測試路徑的數(shù)量太多造成無法在合理的時間內(nèi)測試完成測試中每增加一個判定條件就會加倍測試路徑并且任何一個循環(huán)將被乘增量測試路徑（2n）2024/3/313.5.1控制流測試概述控制流測試通過識別程序代碼中的執(zhí)行65

控制流測試的缺陷路徑太多使控制流無法完全測試 for(i=0;i<1000;i++) for(j=0;j<1000;j++) for(k=0;k<1000;k++) doSomethingWith(i,j,k); doSomethingWith()函數(shù)將執(zhí)行10億次(1000

1000

1000)，相當于10億條路徑2024/3/31控制流測試的缺陷路徑太多使控制流無法完全測試66

控制流測試的缺陷2程序執(zhí)行路徑可能在模塊中被遺失，任何基于實現(xiàn)路徑的測試方法都不能測試沒有實現(xiàn)的路徑，例如：

if(a>0) doIsGreater();

if(a==0) doIsEqual();

//遺失語句：if(a<0)doIsLess();2024/3/31控制流測試的缺陷2程序執(zhí)行路徑可能在模塊中被67

控制流測試的缺陷3軟件本身的邏輯錯誤無法通過測試找到，例如：

//actual(butincorrect)code a=a+1;

//correctcode a=a-1;2024/3/31控制流測試的缺陷3軟件本身的邏輯錯誤無法通過683.5.2控制流圖盡管控制流測試存在缺陷，但它仍然是白盒測試的重要工具控制流圖是控制流測試的基礎，控制流圖包含3個部分：進程塊（ProcessBlock）判定點（DecisionPoint）連接點（JunctionPoint

）2024/3/313.5.2控制流圖盡管控制流測試存在缺陷，但它仍然是白盒測69

控制流圖的進程塊進程塊是從頭至尾順序執(zhí)行的程序語句序列，只有起始塊可以沒有進入點，只有結束塊可以沒有退出點一旦進程塊啟動，其內(nèi)部的每一條語句都會被順序執(zhí)行進程塊使用圓型泡泡+入口點+出口點構成Processblock2024/3/31控制流圖的進程塊進程塊是從頭至尾順序執(zhí)行的程70

控制流圖的判定點判定點是模塊中某一點，在這一點控制流能夠改變方向。很多判定點是二值化的并且使用if-then-else語句實現(xiàn)；多路判定點通常使用case語句實現(xiàn)。判定點使用包含一個輸入和多個輸出的泡泡表示ifcase判定點2024/3/31控制流圖的判定點判定點是模塊中某一點，在這一71

控制流圖的連接點連接點是將控制流結合起來的點連接點使用包含多個輸入和1個輸出的泡泡表示連接點2024/3/31控制流圖的連接點連接點是將控制流結合起來的點72

控制流圖的舉例下面代碼的控制流圖如右所示： q=1; b=2；

if(a==2) {x=x+2;}

else {x=x/2;} p=q/r;

if(b/c>3) {z=x+y;}q=1b=2if(a==2)x=x+2x=x/2p=q/rif(b/c>3)z=x+y2024/3/31控制流圖的舉例下面代碼的控制流圖如右所示：q733.5.3代碼測試的覆蓋范圍在控制流測試中，定義了8種級別測試覆蓋范圍（coverage）覆蓋范圍（coverage）的意思是已經(jīng)被測試的代碼百分比2024/3/313.5.3代碼測試的覆蓋范圍在控制流測試中，定義了8種級別74

小于100%語句覆蓋范圍0級：測試與調(diào)試之間沒有區(qū)別，除了支持調(diào)試，測試本身沒有目的缺陷可能會偶爾被發(fā)現(xiàn)，但是沒有正式的努力去找到它們2024/3/31小于100%語句覆蓋范圍0級：2024/375100%語句覆蓋范圍1級：最低覆蓋范圍是指100%語句覆蓋，可以簡稱為語句覆蓋語句覆蓋意味著測試模塊中的每一條語句都至少被執(zhí)行一次。這好像是合理的目標，但這種測試會導致很多缺陷遺失，例如：

1.if(a>0) 2. {x=x+1;} 3.if(b==3) 4.

{y=0;}if(b=3)y=0if(a>0)x=x+1左邊程序段的狀態(tài)圖用例a=6,b=3就可以完成100%語句覆蓋2024/3/31100%語句覆蓋范圍1級：if(b=3)y76

語句(statement)覆蓋范圍上例中有4條獨立的路徑，但卻只執(zhí)行了一條，由于測試路徑的遺漏，可能會導致缺陷的發(fā)生。語句測試只是入門測試if(b=3)y=0if(a>0)x=x+1if(b=3)y=0if(a>0)x=x+11234falsefalsetruefalsefalsetruetruetrue2024/3/31語句(statement)覆蓋范圍上例中有77

判定(decision)覆蓋范圍2級：下一級的控制流測試是100%判定測試，這又被稱為分支測試在分支測試下，要求測試用例至少保證每個判定條件為真、假的情況至少出現(xiàn)一次分支測試不能保證路徑覆蓋，但是可以保證語句覆蓋2024/3/31判定(decision)覆蓋范圍2級：2078

判定(decision)覆蓋范圍比如針對上一個案例，我們需要使用兩個案例：a=-2，b=2和a=4，b=3進行判定覆蓋if(b=3)y=0if(a>0)x=x+1if(b=3)y=0if(a>0)x=x+1test1test2falsefalsetruetrue2024/3/31判定(decision)覆蓋范圍比如針對上79

條件（condition)覆蓋范圍并不是所有的條件語句都是簡單的判定，有些條件包含多個邏輯或表達式的組合，例如：

1.

if(a>0&&c==1)

2. {x=x+1;}