軟件測試技術課件：靜態(tài)白盒測試

靜態(tài)白盒測試靜態(tài)測試靜態(tài)測試不運行程序，測試非運行部分—檢驗和審查白盒測試訪問代碼，能夠查看和審查靜態(tài)白盒測試在不執(zhí)行軟件的條件下有條理地仔細審查軟件的設計、體系結構和代碼，從而找出軟件缺陷的過程，有時也稱為結構化分析進行靜態(tài)白盒原因盡發(fā)現(xiàn)軟件缺陷，以找出黑盒測試難以發(fā)現(xiàn)或隔離的軟件缺陷，能讓開發(fā)過程初期讓測試小組集中精力過行軟件設計的審查為黑盒測試員在接受軟件測試時設計和應用測試用例提供思路正式審查

基本要素確定問題（審查的目的是找出軟件問題）遵守規(guī)則（要遵守固定的規(guī)則）準備期間（發(fā)現(xiàn)問題）編寫報告是尋找缺陷的第一步正式審查副作用

間接效果交流（學習的良機）質(zhì)量（變得細心）小組同志化（了解對方）解決方案程序代碼審查

代碼審查的目標： 產(chǎn)生正確性、清晰性、規(guī)范性、一致性和高效性的合格代碼代碼審查的范圍： 業(yè)務邏輯、算法效率、代碼風格，編程規(guī)則代碼審查的方法 互查（Peer-To-Peer）、走查（Walk-Through）、會議評審(Inspection）程序代碼審查選擇要審查的代碼模塊的準則：對于正確操作產(chǎn)品起關鍵作用的模塊復雜度高的模塊與過去發(fā)生錯誤率較高的模塊功能類似的模塊相對較新的或缺乏經(jīng)驗的軟件工程師編寫的模塊在項目應用靜態(tài)白盒測試會議評審組織一般五到七人主審員：協(xié)調(diào)本次審查并主持討論責任人：負責被審查的產(chǎn)品講解員：在審查會上講解被審查的產(chǎn)品審查員：審查產(chǎn)品記錄員：記錄在審查會議上討論的問題經(jīng)理：責任人的管理者編碼標準和規(guī)范有些代碼雖然可以正常運行，編寫不符合某種標準和規(guī)范。三個重要的原因：可靠性、可讀性/維護性、移植性四部分組成：標題、標準、解釋說明、示例例如：命名規(guī)則匈牙利命名規(guī)則非常簡單，變數(shù)名以一個或者多個小寫字母開始，這些字母表示變量的類型

iNum、cSex等

GNU命名規(guī)則文檔名+主版本號+輔版本號+補丁編號

Foobar-1.2.3.src.tar.gz編程規(guī)則的審查

Java最基本語句的使用

Trycatchthrowsfinally線程中的異常重載函數(shù)的審查C++中的重載函數(shù)的審查，最好，不同返回類型用不同的函數(shù)名內(nèi)存分配和管理內(nèi)存及時釋放和避免緩沖區(qū)溢出

程序性能審查 減少創(chuàng)建對象 減少循環(huán)體的執(zhí)行代碼 提高異常處理效率 減少IO操作通用代碼審查清單一、數(shù)據(jù)引用錯誤。二、數(shù)據(jù)聲明錯誤。三、計算錯誤。四、比較錯誤。五、控制流程錯誤。六、子程序參數(shù)錯誤。七、輸入/輸出錯誤。八、其他檢查。一、數(shù)據(jù)引用錯誤定義：是指使用未經(jīng)正確初始化用法和引用方式的變量、常量、數(shù)組、字符串或記錄而導致的軟件缺陷。

是否引用了未初始化的變量？查找遺漏之處與查找錯誤同等重要。數(shù)據(jù)引用錯誤數(shù)組和字符串的下標是整數(shù)值嗎？下標總是在數(shù)組和字符串大小范圍之內(nèi)嗎？在檢索操作或者應用數(shù)組下標時是否包含“丟掉一個”這樣的潛在錯誤？是否在應該使用常量的地方使用了變量－例如在檢查數(shù)組范圍時？變量是否被賦予不同類型的值？例如，無意中使代碼為整形變量賦予一個浮點數(shù)值？為引用的指針分配內(nèi)存了嗎？一個數(shù)據(jù)結構是否在多個函數(shù)或者子程序中引用，在每一個引用中明確定義結構了嗎？二、數(shù)據(jù)聲明錯誤。

產(chǎn)生的原因：不正確地聲明或使用變量和常量數(shù)據(jù)聲明錯誤所有變量都賦予正確的長度、類型和存儲類了嗎？變量是否在聲明的同時進行了初始化？是否正確初始化并與其類型一致？變量有類似的名稱嗎？這基本上不算軟件缺陷，但有可能是程序中其他地方出現(xiàn)名稱混淆的信息。存在聲明過、但從未引用或者只引用過一次的變量嗎？在特定模塊中所有變量都顯式聲明了嗎？如果沒有，是否可以理解為該變量與更高級別的模塊共享？三、計算錯誤

是基本的數(shù)據(jù)邏輯問題，計算無法得到預期結果。計算錯誤計算中是否使用了不同數(shù)據(jù)類型的變量，例如將整數(shù)與浮點數(shù)相加？計算中是否使用了不同數(shù)據(jù)類型相同但不同長度的變量－例如，將字節(jié)與字相加?計算時是否了解和考慮到編譯器對類型或長度不一致的變量的轉(zhuǎn)換規(guī)則？賦值的目的變量是否小于賦值表達式的值？在數(shù)值計算過程中是否可能出現(xiàn)溢出？除數(shù)/模是否可能為零？對于整型算術運算，某些計算，特別是除法的代碼處理是否會丟失精度？變量的值是否超過有意義的范圍？例如，可能性的計算結果是否小于0%或者大于100%？對于包含多個操作數(shù)的表達式，求值的次序是否混亂，運算優(yōu)先級對嗎？需要加括號使其清晰嗎？四、比較錯誤小于、大于、等于、不等于、真、假。比較和判斷錯誤很可能是邊界條件問題。

比較得正確嗎？雖然聽起來簡單，但是比較應該是小于還是小于或等于常常發(fā)生混淆。比較錯誤存在分數(shù)或者浮點值之間的比較嗎？如果有，精度問題會影響比較嗎？1.00000001和1.00000002極其接近，它們相等嗎？每一個邏輯表達式都正確表達了嗎？邏輯計算如期進行了嗎？求值次序有疑問嗎？邏輯表達式的操作數(shù)是邏輯值嗎？例如，是否包含整數(shù)值的整型變量用于邏輯計算中？五、控制流程錯誤原因：編程語言中循環(huán)等控制結構未按預期方式工作。它們通常由計算或者比較錯誤直接或間接造成?？刂屏鞒体e誤

如果程序包含begin..end和do...while等語句組，end是否對應？程序、模塊、子程序和循環(huán)能否終止？如果不能，可以接受嗎？可能存在永遠不停的循環(huán)嗎？循環(huán)可能從不執(zhí)行嗎？如果是這樣，可以接受嗎？如果程序包含像switch...case語句這樣的多個分支，索引變量能超出可能的分支數(shù)目嗎？如果超出，該情況能正確處理嗎？是否存在“丟掉一個”錯誤，導致意外進入循環(huán)？

六、子程序參數(shù)錯誤來源于軟件子程序不正確地傳遞數(shù)據(jù)。

子程序參數(shù)錯誤子程序接收的參數(shù)類型和大小與調(diào)用代碼發(fā)送的匹配嗎？次序正確嗎？如果子程序有多個入口點，引用的參數(shù)是否與當前入口點沒有關聯(lián)？常量是否當作形參傳遞，意外在子程序中改動？子程序是更改了僅作為輸入值的參數(shù)？每一個參數(shù)的單位是否與相應的形參匹配。如果存在全局變量，在所有引用子程序中是否有相似的定義和屬性？七、輸入/輸出錯誤包括文件讀取、接受鍵盤或者鼠標輸入以及向打印機或者屏幕等輸出設備寫入錯誤。

輸入/輸出錯誤軟件是否嚴格遵守外部設備讀寫數(shù)據(jù)的專用格式？文件或者外設不存在或者未準備好的錯誤情況有處理嗎？軟件是否處理外部設備未連接、不可用，或者讀寫過程中存儲空間占滿等情況？軟件以預期方式處理預計的錯誤嗎？檢查錯誤提示信息的準確性、正確性、語法或拼寫了嗎？

其他檢查軟件是否使用其他外語？是否處理擴展ASCII字符？是否需要用統(tǒng)一編碼取代ASCII？軟件是否要移植到其他編譯器和CPU，具有這樣做的許可嗎？如果沒有計劃或者測試，那么，移植性可能成為一個大難題。是否考慮了兼容性，以使軟件能夠運行于不同數(shù)量的可用內(nèi)存，不同的內(nèi)部硬件，例如圖形卡和顯卡，不同的外設，例如打印機和調(diào)制解調(diào)器？程序編譯是否產(chǎn)生“警告”或者“提示”信息？這些信息通常指示進行了有疑問的處理。純粹主義者可能認為警告信息是不可接受的。靜態(tài)白盒測試所面臨的主要問題管理者會花的時間太多認為靜態(tài)檢查代碼體現(xiàn)不出生產(chǎn)率所以不做或者虎頭蛇尾靜態(tài)測試工具FindBugs?-FindBugsinJavaProgramsC++test

總結靜態(tài)白盒測試被證實是早期發(fā)現(xiàn)軟件缺陷最有效的方法。但這是一項需要大量準備工作才能有成效的任務，但是許多研究表明花費的時間與得到的好處相比是值得的.動態(tài)白盒測試與單元測試回顧：靜態(tài)白盒測試基本概念在不執(zhí)行軟件的條件下有條理地仔細審查軟件的設計、體系結構和代碼，從而找出軟件缺陷的過程，有時也稱為結構化分析原因

盡早發(fā)現(xiàn)軟件錯誤;為黑盒測試人員提供建議方式：

正式審查：1.確定問題2.遵守規(guī)則3.準備期間4.編寫報告方法：互查、走查、會議評審動態(tài)白盒測試檢查代碼并觀察運行狀況.利用查看代碼（做什么）和實現(xiàn)方法(怎么做)得到的信息來確定哪些需要測試、哪些不要測試、如何開展測試又稱為結構化測試(structraltesting)39不執(zhí)行代碼白盒測試發(fā)現(xiàn)缺陷不執(zhí)行代碼解決缺陷測試與調(diào)試明確概念調(diào)試動態(tài)白盒測試內(nèi)容直接測試底層函數(shù)、過程、子程序和庫。以完整程序的方式從頂層測試軟件。但是根椐對軟件運行的了解調(diào)整測試用例；從軟件獲得讀取變量和狀態(tài)信息的訪問權，以便確定測試與預期結果是否相符，同時強制軟件以正常難以實現(xiàn)的方式運行;估算執(zhí)行測試時“命令”的代碼量和具體代碼，然后調(diào)整測試，去掉多余的測試用例，補充遺漏的用例.白盒測試期望達到的目的

所有獨立路徑至少都能測試一遍；所有邏輯判斷都能測試True和False兩條路徑；所有循環(huán)結構都能測試到邊界和循環(huán)域內(nèi)的情況；確保內(nèi)部數(shù)據(jù)結構的有效性。白盒測試主要方法3-1邏輯覆蓋測試法

3-2基本路徑測試法

3-3循環(huán)路徑覆蓋法3-1邏輯覆蓋測試法

語句覆蓋判定覆蓋條件覆蓋判定/條件覆蓋條件組合覆蓋路徑覆蓋邏輯覆蓋測試法語句覆蓋每條語句至少執(zhí)行一次。判定覆蓋每個判定的每個分支至少執(zhí)行一次。條件覆蓋每種條件下的語句都應該被執(zhí)行。邏輯覆蓋測試法判定/條件覆蓋同時滿足判定覆蓋和條件覆蓋條件組合覆蓋每個判定中，各條件的每一種組合至少出現(xiàn)一次。路徑覆蓋程序中每一條可能的路徑至少執(zhí)行一次。46案例代碼Line1:voidDoWork(intx,inty,intz)Line2:{Line3:

intk=0,j=0;Line4:if((x>3)&&(z<10))Line5:{Line6:

k=x*y-1;//語句塊1Line7:

j=sqrt(k);Line8:}Line9:

if((x==4)||(y>5))Line10:{Line11:

j=x*y+10;//語句塊2Line12:}Line13:

j=j%3;//語句塊3Line14:}47輔助方法－流程圖x>3&&z<10x==4||y>5入口

語句塊1語句塊2語句塊3出口abcde

畫出模塊的流程圖發(fā)現(xiàn)問題輔助設計測試用例48語句覆蓋－設計用例測試用例輸入為：{x=4、y=5、z=5}x>3&&z<10x==4||y>5入口

語句塊1語句塊2語句塊3出口abcde程序執(zhí)行的路徑是：abd49分支/判定覆蓋測試用例的輸入為：{x=4、y=5、z=5}{x=2、y=5、z=5}x>3&&z<10x==4||y>5入口

語句塊1語句塊2語句塊3出口abcde程序執(zhí)行的路徑是：abd程序執(zhí)行的路徑是：ace50條件覆蓋－設計用例x>3&&z<10x==4||y>5入口

語句塊1語句塊2語句塊3出口abcdeT1和－T1T2和－T2T3和－T3T4和－T451條件覆蓋－設計用例測試用例的輸入為：{x=4、y=6、z=5}{x=2、y=5、z=5}{x=4、y=5、z=15}x>3&&z<10x==4||y>5入口

語句塊1語句塊2語句塊3出口abcde程序執(zhí)行的路徑是：abd程序執(zhí)行的路徑是：ace程序執(zhí)行的路徑是：acdx>3&&z<10x==4||y>5入口

語句塊1語句塊2語句塊3出口abcde條件覆蓋－設計用例測試用例通過路徑條件取值覆蓋分支x=4、y=6、z=5abdT1、T2、T3、T4bdx=2、y=5、z=5ace-T1、T2、-T3、-T4cex=4、y=5、z=15acdT1、-T2、T3、-T4cd52測試用例通過路徑條件取值覆蓋分支x=2、y=6、z=5acd-T1、T2、-T3、T4cdx=4、y=5、z=5acdT1、-T2、T3、-T4cd則可以設計測試用例如下：假如根據(jù)定義設計測試用例如下：判定－條件覆蓋測試用例測試用例

通過路徑

條件取值覆蓋分支x=4、y=6、z=5abdT1、T2、T3、T4bdx=2、y=5、z=11ace-T1、-T2、-T3、-T4ce53

根據(jù)定義只需設計以下兩個測試用例便可以覆蓋8個條件值以及4個判斷分支。54條件組合測試用例測試用例

通過路徑

條件取值覆蓋組合號x=4、y=6、z=5abdT1、T2、T3、T41和5x=4、y=5、z=15acdT1、-T2、T3、-T42和6x=2、y=6、z=5acd-T1、T2、-T3、T43和7x=2、y=5、z=15ace-T1、-T2、-T3、-T44和8丟失了一條路徑abe55路徑測試測試用例測試用例通過路徑覆蓋條件x=4、y=6、z=5abdT1、T2、T3、T4x=4、y=5、z=15acdT1、-T2、T3、-T4x=2、y=6、z=15ace-T1、-T2、-T3、-T4x=5、y=6、z=5abeT1、T2、-T3、-T4在上面的測試用例中修改一個測試用例則可對程序進行了全部的路徑覆蓋。

3-2基本路徑測試法基本路徑測試法是在程序控制流圖的基礎上，通過分析控制構造的環(huán)路復雜性，導出基本可執(zhí)行路徑集合，從而設計測試用例的方法。571236784591110基本路徑測試2-1路徑測試路徑是控制流程圖中節(jié)點的順序，始于入口節(jié)點，止于出口節(jié)點程序控制結構相應的流程圖分支測試程序可能通過的路徑是：路徑1：1–11路徑2：1–2–3–4–5–10–1–11路徑3：1–2–3–6–8–9–10–1–11路徑4：1–2–3–6–7–9–10–1–1158基本路徑測試2-2計算路徑數(shù)，以便可以測試軟件流程圖矩陣圖14523cbaegfd節(jié)點連接到節(jié)點1154325432aefbgcd用鏈接權重替代交叉點值的字母，矩陣就可以成為評估測試中控制結構的有效工具替換后的矩陣圖1和0表示連接存在，字母被替換為1循環(huán)路徑覆蓋法五種測試用例1）整個跳過循環(huán)

2）只有一次通過循環(huán)

3）兩次通過循環(huán)

4）m此通過循環(huán)，m<循環(huán)最大次數(shù)

5）n-1,n,n+1次通過循環(huán)動態(tài)白盒測試步驟

1

分析模塊函數(shù)；

2

在模塊中找到相應的關鍵點（函數(shù)）；

3

根據(jù)第二點，畫出模塊程序流程圖；

4

計算圈復雜度；

5

根據(jù)圈復雜度算出測試用例的最優(yōu)個數(shù)；

6

根據(jù)路徑測試法和圈復雜度寫出具體測試用例；

7

進行測試。

練習publicbooleanmodule(intaValue,intbValue){ booleanflag=false; if(aValue>8&&bValue>9){ if((aValue*bValue)>150){ flag=true; }else{ flag=false; } }else{ if((aValue+bValue)>10){ flag=true; }else{ flag=false; } } returnflag; }將測試進行分段測試越早發(fā)生越好。代碼分段構建和測試，最后合在一起形成更大的部分。單元集成系統(tǒng)用戶驗收測試階段單元測試概念定義單元測試是對軟件基本組成單元進行的測試時機在代碼完成后由開發(fā)人員完成,QA人員輔助意義盡早發(fā)現(xiàn)錯誤，發(fā)現(xiàn)的越早成本越低12小時6小時3小時單元測試集成測試系統(tǒng)測試運行單元程序有時需要基于被測單元的接口，開發(fā)相應的驅(qū)動模塊和樁模塊。

驅(qū)動模塊（drive）:對底層或子層模塊進行測試所編寫的調(diào)用這些模塊的程序。樁模塊（stub）：對頂層或上層模塊進行測試時所編寫的替代下層模塊的程序。單元測試內(nèi)容單元測試的步驟第一步:人工靜態(tài)檢查

這個階段工作主要是保證代碼算法的邏輯正確性(盡量通過人工檢查發(fā)現(xiàn)代碼的邏輯錯誤)、清晰性、規(guī)范性、一致性、算法高效性。并盡可能的發(fā)現(xiàn)程序中沒有發(fā)現(xiàn)的錯誤。第二步:動態(tài)執(zhí)行跟蹤通過設計測試用例，執(zhí)行待測程序來跟蹤比較實際結果與預期結果來發(fā)現(xiàn)錯誤。

動態(tài)跟蹤調(diào)試，是單元測試的重點與難點。人工靜態(tài)檢查1. 確定所編寫的代碼是否實現(xiàn)了模塊或方法所要求的功能。2. 確定形式參數(shù)個數(shù)、數(shù)據(jù)類型、順序是否正確;確定返回值類型及返回值的正確性。

3. 確定對輸入?yún)?shù)有沒有作正確性檢查;

如果沒有作正確性檢查，確定該參數(shù)是否的確無需做參數(shù)正確性檢查。