軟件測試課件第3章 軟件測試方法1 靜態(tài)測試與動態(tài)測試

第3章軟件測試方法（一）靜態(tài)測試與動態(tài)測試3.1

靜態(tài)測試技術概述

靜態(tài)測試是不執(zhí)行被分析的程序，而是通過對模塊源代碼進行研讀、找出其中的錯誤或可疑之處，收集一些度量數據。靜態(tài)測試包括對軟件產品的需求和設計規(guī)格說明書的評審、對程序代碼的復審等。

靜態(tài)測試的查錯和分析功能是其他方法所不能替代的，可以采用人工或者計算機輔助靜態(tài)測試手段進行檢測。代碼檢查

主要檢查代碼和設計的一致性，代碼對標準的遵循，可讀性，代碼邏輯表達正確性，代碼結構合理性等方面；發(fā)現程序中不安全、不明確和模糊部分，找出程序中不可移植部分；發(fā)現違背程序編寫風格問題。其中包括變量檢查、命名和類型審查、程序邏輯審查、程序語法檢查和程序結構檢查等內容。包括桌面檢查、代碼審查和走查等3.1

靜態(tài)測試技術概述桌面檢查

桌面檢查是一種傳統的檢查方法，由程序員自己檢查編寫的程序。由于程序員熟悉自己的程序和程序設計風格，桌面檢查由程序員自己進行可以節(jié)省很多檢查時間。

桌面檢查需要首先運行拼寫檢查器、語法檢查器、句法檢查器等進行字面檢查，現在大多數集成開發(fā)環(huán)境集成了這些相應的工具幫助程序員在編寫代碼的同時就注意這些可能存在的缺陷。代碼檢查3.1

靜態(tài)測試技術概述Eg：第28行：返回數據類型應該為int，寫成了Int；第33行：缺少標點符號“;”；第37行：返回的關鍵字“return”拼寫錯誤；第41行：關鍵字“this”，寫成了“that”。代碼檢查3.1

靜態(tài)測試技術概述桌面檢查代碼審查

代碼審查是由若干程序員和測試人員組成一個審查小組，通過閱讀、討論和爭議，對程序進行靜態(tài)分析的過程。代碼審查分為兩步：小組負責人提前把設計規(guī)格說明書、控制流程圖、程序文本以及有關要求、規(guī)范等分發(fā)給小組成員，作為審查的依據；小組成員在充分閱讀這些材料后，召開程序審查會，在會上首先由程序員逐行講解程序邏輯，在此過程中程序員或其他小組成員可以提出問題展開討論，審查錯誤是否存在。代碼檢查3.1

靜態(tài)測試技術概述重要性激活結果檢查項總計

命名

重要Y通過命名規(guī)則是否與所采用的規(guī)范保持一致？

是否遵循了最小長度最多信息原則？重要Y通過has/can/is前綴的函數是否返回布爾型？注釋

重要Y通過注釋是否較清晰且必要？重要Y通過復雜的分支流程是否已經被注釋？

Y不通過距離較遠的}是否已經被注釋？

Y不通過非通用變量是否全部被注釋？重要Y不通過函數是否已經有文檔注釋？（功能、輸入、返回及其他可選）

特殊用法是否被注釋？聲明、空白、縮進

Y通過每行是否只聲明了一個變量？（特別是那些可能出錯的類型）重要Y通過變量是否已經在定義的同時初始化？重要Y通過類屬性是否都執(zhí)行了初始化？

Y通過代碼段落是否被合適地以空行分隔？

Y通過是否合理地使用了空格使程序更清晰？

Y通過代碼行長度是否在要求之內？

Y通過折行是否恰當？代碼檢查3.1

靜態(tài)測試技術概述Java代碼審查檢查表語句/功能的分布/規(guī)模

Y通過包含復合語句的{}是否成對出現并符合規(guī)范？

Y不通過是否給單個的循環(huán)、條件語句也加了{}？

Y通過if/if-else/if-elseif-else/do-while/switch-case語句的格式是否符合規(guī)范？

Y通過單個變量是否只做單個用途？重要Y通過單行是否只有單個功能？（不要使用；進行多行合并）重要Y通過單個函數是否執(zhí)行了單個功能并與其命名相符？

Y通過操作符＋＋和——操作符的應用是否復合規(guī)范？規(guī)模

重要Y通過單個函數不超過規(guī)定行數？重要Y通過縮進層數是否不超過規(guī)定？重要Y通過是否已經消除了所有警告？重要Y通過常數變量是否聲明為final？重要Y不通過對象使用前是否進行了檢查？重要Y不通過局部對象變量使用后是否被復位為NULL？重要Y通過對數組的訪問是否是安全的？（合法的index取值為[0,MAX_SIZE-1]）。重要Y通過是否確認沒有同名變量局部重復定義問題?

Y通過程序中是否只使用了簡單的表達式？重要Y通過是否已經用（）使操作符優(yōu)先級明確化？重要Y通過所有判斷是否都使用了（常量==變量）的形式？

是否消除了流程懸掛？重要Y不通過是否每個if-elseif-else語句都有最后一個else以確保處理了全集？重要Y通過是否每個switch-case語句都有最后一個default以確保處理了全集？

Y通過for循環(huán)是否都使用了包含下限不包含上限的形式？（k=0;k<MAX）重要

XML標記書寫是否完整，字符串的拼寫是否正確?

Y不通過對于流操作代碼的異常捕獲是否有finally操作以關閉流對象?

退出代碼段時是否對臨時對象做了釋放處理?重要Y通過對浮點數值的相等判斷是否是恰當的？（嚴禁使用==直接判斷）代碼檢查3.1

靜態(tài)測試技術概述Java代碼審查檢查表可靠性（函數）

重要Y通過入口對象是否都被進行了判斷不為空？重要Y通過入口數據的合法范圍是否都被進行了判斷？(尤其是數組)重要Y通過是否對有異常拋出的方法都執(zhí)行了try...catch保護？重要Y通過是否函數的所有分支都有返回值？重要Y通過int的返回值是否合理？（負值為失敗，非負值成功）

Y通過對于反復進行了int返回值判斷是否定義了函數來處理？

關鍵代碼是否做了捕獲異常處理?重要

是否確保函數返回CORBA對象的任何一個屬性都不能為null?重要Y通過是否對方法返回值對象做了null檢查，該返回值定義時是否被初始化?重要Y通過是否對同步對象的遍歷訪問做了代碼同步?重要Y通過是否確認在對Map對象使用迭代遍歷過程中沒有做增減元素操作？重要Y通過線程處理函數循環(huán)內部是否有異常捕獲處理，防止線程拋出異常而退出?

原子操作代碼異常中斷，使用的相關外部變量是否恢復先前狀態(tài)?重要Y通過函數對錯誤的處理是恰當的？可維護性

重要Y通過實現代碼中是否消除了直接常量？（用于計數起點的簡單常數例外）

是否消除了導致結構模糊的連續(xù)賦值？（如a=(b=d+c)）

Y通過是否每個return前都要有日志記錄?

Y通過是否有冗余判斷語句？（如：if(b)returntrue;elsereturnfalse;）

是否把方法中的重復代碼抽象成私有函數?代碼檢查3.1

靜態(tài)測試技術概述代碼檢查常見錯誤表走查

走查與代碼審查基本相同，其過程分為兩步：把材料先發(fā)給走查小組的每個成員，認真研究程序，然后開會；開會的程序與代碼審查不同，不是簡單的讀程序和對照錯誤檢查表進行檢查，而是讓與會者充當計算機，即首先由測試組成員為所測程序準備一批有代表性的測試用例，提交給走查小組，走查小組開會扮演計算機角色，讓測試用例沿程序邏輯運行一遍，隨時記錄程序的跟蹤，供分析和討論用。代碼檢查3.1

靜態(tài)測試技術概述多次拷貝字符串:

測試所不能發(fā)現的一個錯誤是生成不可變(immutable)對象的多份拷貝。不可變對象是不可改變的，因此不需要拷貝它。最常用的不可變對象是String。如果你必須改變一個String對象的內容，你應該使用StringBuffer。下面的代碼可以正常工作：Strings=newString("Texthere");但是，這段代碼性能差，而且沒有必要這么復雜?？梢杂靡韵碌姆绞絹碇貙懮厦娴拇a：Stringtemp="Texthere";Strings=newString(temp);但是，這段代碼包含額外的String。更好的代碼為：Strings="Texthere";代碼檢查3.1

靜態(tài)測試技術概述Java代碼的走查與審查中常見錯誤：沒有克隆(clone)返回的對象:封裝(encapsulation)是面向對象編程的重要概念。但是Java為打破這種封裝提供了方便——Java允許返回私有數據的引用(reference)。代碼檢查3.1

靜態(tài)測試技術概述Java代碼的走查與審查中常見錯誤：檢查new操作的結果是否為nullJava編程新手有時候會檢查new操作的結果是否為null?？赡艿臋z查代碼為：檢查雖然沒有錯誤，但卻沒有必要。C/C++程序員在開始寫Java程序的時候常常會這么做，這是由于檢查C/C++中malloc()的返回結果是必要的，不這樣做就可能產生錯誤。但在Java中，new操作不允許返回null，如果真的返回null，很可能是虛擬機崩潰了，這時候即便檢查返回結果也是無濟于事。代碼檢查3.1

靜態(tài)測試技術概述Java代碼的走查與審查中常見錯誤：

用==替代equals

在Java中，有兩種方式檢查兩個數據是否相等：通過使用==操作符，或者使用所有對象都實現的equals方法。原子類型（int，float，char等）不是對象，因此他們只能使用==操作符，如下所示：對象更復雜些，==操作符檢查兩個引用是否指向同一個對象，而equals方法則實現更專門的相等性檢查。代碼檢查3.1

靜態(tài)測試技術概述Java代碼的走查與審查中常見錯誤：沒有正確實現equals，hashCode，或者clone等方法:

方法equals，hashCode，和clone是由java.lang.Object提供的缺省實現。但是，這些缺省實現在大部分時候毫無用處，因此許多類覆蓋其中的若干個方法以提供更有用的功能。而當繼承一個覆蓋了若干個這些方法的父類時，子類通常也需要覆蓋這些方法。代碼檢查3.1

靜態(tài)測試技術概述Java代碼的走查與審查中常見錯誤：

通過代碼檢查法可以獲得軟件組成的重要基本因素，例如變量標識符、過程標識符、常量等，組合這些基本因素就可以得到軟件的基本信息，包括：標號交叉引用表，變量交叉引用表，子程序、宏和函數表，等價表，常數表。通過這些軟件的基本信息可以實現以下功能：直接從表中查出說明和使用錯誤，如循環(huán)層次表、標號交叉引用表和變量交叉引用表；為用戶提供輔助信息，如子程序、宏和函數表、等價表和常數表；用來做錯誤預測和程序復雜度的計算，如操作符合操作數表等。代碼檢查3.1

靜態(tài)測試技術概述代碼檢查常用檢查項代碼檢查項目包括檢查變量的交叉引用表，檢查標號的交叉引用表，檢查子程序、宏和函數表，等價性檢查，常量檢查，標準檢查，風格檢查，比較控制流，選擇、激活路徑，對照程序說明，充分文檔等。代碼檢查3.1

靜態(tài)測試技術概述代碼檢查常用檢查項3.1

靜態(tài)測試技術概述檢查變量的交叉引用表，重點檢查未說明變量和違反了類型規(guī)定的變量，還要對照源程序，逐個檢查變量的引用、變量的使用序列、臨時變量在某條路徑上的重寫情況，局部變量、全局變量與特權變量的使用；檢查標號的交叉引用表，驗證所有標號的正確性，檢查所有標號的命名是否正確，轉向指定位置的標號是否正確；檢查子程序、宏和函數表，調用每次調用和所調用位置是否正確，確定每次調用的子程序、宏和函數是否存在，檢驗調用序列中調用方式與參數順序、個數、類型上的一致性；等價性檢查，檢查所有等價變量類型的一致性，解釋所包含的類型差異；標準檢查，用標準檢查工具軟件或手工檢查程序中違反標準的問題；風格檢查，檢查發(fā)現程序在設計風格方面的問題；代碼檢查常用檢查項比較控制流，比較由程序員設計的控制流圖和由程序生成的實際控制流圖，尋找和解釋每個差異，修改文檔并修正錯誤；選擇、激活路徑，在程序員設計的控制流圖上選擇路徑，再到實際控制流圖上激活這條路徑，如果選擇的路徑在實際控制流圖上不能被激活，則源程序可能存在錯誤；對照程序說明，閱讀程序源代碼，逐行進行分析思考，比較實際的代碼和期望的代碼，從它們的差異中發(fā)現程序的錯誤和問題；充分文檔，代碼檢查的文檔是一種過渡性文檔，不是公開的正式文檔，通過編寫文檔，也是對程序的一種下意識的檢查和測試，可以幫助程序員發(fā)現更多的錯誤，管理部門也可以通過檢查文檔，了解模塊質量、完全性、測試方法和程序員能力。靜態(tài)結構分析靜態(tài)結構分析主要是以圖的形式表現程序的內部結構，供測試人員對程序結構進行分析。靜態(tài)結構分析是一種對代碼機械性的、程式化的特性進行分析的方法。常用的關系圖主要有函數調用關系圖和模塊控制流圖。函數調用關系圖函數調用關系圖列出所有函數，用連線表示調用關系，通過應用程序各函數之間的調用關系展示了系統的結構，利用函數調用關系圖可以檢查函數的調用關系是否正確，是否存在孤立的函數而沒有被調用，明確函數被調用的頻繁度，對調用頻繁的函數可以重點檢查。通過查看函數調用關系圖，可以發(fā)現系統是否存在結構缺陷，發(fā)現哪些函數是重要的，哪些是次要的，需要使用什么級別的覆蓋要求等；模塊控制流圖模塊控制流圖是由許多節(jié)點和連接節(jié)點的邊組成的圖形，其中每個節(jié)點代表一條或多條語句，邊表示控制流向，模塊控制流圖可以直觀的反映出一個函數的內部結構，通過檢查這些模塊控制流圖可以很快的發(fā)現軟件錯誤與缺陷。模塊控制流圖符號:基本結構圖:

類型和單元分析為了強化在源程序中數據類型的檢查，在程序設計語言中擴展了一些新的數據類型，例如僅能在數組中使用的下標類型和在循環(huán)語句中當作控制變量使用的計數器類型，這樣就可以靜態(tài)預處理程序，分析程序中的類型錯誤。引用分析在靜態(tài)錯誤分析中，最廣泛使用的技術就是發(fā)現引用異常。如果沿著程序的控制路徑，變量在賦值以前被引用，或變量在賦值以后未被引用，這時就發(fā)生引用異常。為了檢測引用異常，需要檢查通過程序的每一條路徑。通常采用類似深度優(yōu)先的方法遍歷程序流程圖的每一條路徑，也可以建立引用異常的探測工具，這類工具包含兩個表：定義表和未引用表。每張表都包含一組變量表。未引用表包含已被賦值但未必引用的一些變量。當掃描達到一個出度大于1的節(jié)點V時，深度優(yōu)先探測算法要求先檢查最左分支的那部分程序流圖，然后再檢查其他分支。在最左分支檢查完之前，應把定義表和未引用表的當前內容用一個棧暫時存儲起來，當最左分支檢查完之后，算法控制返回到節(jié)點V，從棧中恢復該節(jié)點的定義表和未引用表的舊的副表，然后再去遍歷該節(jié)點的下一個分支，這個過程要繼續(xù)到全部分支檢查完為止。表達式分析對表達式進行分析，以發(fā)現和糾正在表達式中出現的錯誤，包括：在表達式中不正確的使用括號造成的錯誤；數組下標越界造成的錯誤；除數為零造成的錯誤；對負數開平方，或者對Π求正切造成的錯誤。最復雜的一類表達式分析是對浮點數計算造成的誤差的檢查。由于使用二進制數不能精確的表示十進制浮點數，常常使計算結果出乎意料。接口分析接口分析是程序的靜態(tài)錯誤分析和設計分析共同研究的問題。接口一致性的設計可以分析檢查模塊之間接口的一致性和外部數據庫之間接口的一致性。程序關于接口的靜態(tài)錯誤分析檢查過程與實參在類型、函數過程接口之間的一致性，因此要檢查形參與實參在類型、數量、維數、順序、使用上的一致性；檢查全局變量和公共數據區(qū)在使用上的一致性。E.g.程序:猜數字游戲E.g.程序:猜數字游戲從該函數調用關系圖中，可以得到以下信息：函數之間的調用關系符合設計規(guī)格說明書的要求；不存在遞歸調用；調用層次最