軟件測試 第3章靜態(tài)測試技術

1、第3章 靜態(tài)測試技術1. 靜態(tài)測試技術概述1 概念： 1.1 定義：是指不通過執(zhí)行被測程序而對軟件產品（包括工作產品）進行分析的測試活動測試對象：需求規(guī)約、分析和設計規(guī)約、代碼街開發(fā)過程中的各種文檔1.2 目的：一般是對工作產品進行確認 (例如設計規(guī)格說明是否正確實現(xiàn)了所有的系統(tǒng)需求)，并對設計的質量進行驗證1.3 優(yōu)點：靜態(tài)測試的成本低，效率高，可以在開發(fā)早期發(fā)現(xiàn)軟件中的缺陷和錯誤，是有效的測試技術。2 原則：2.1 所有違背編碼標準的因素都要進行評審，例如標識符如何命名，代碼如何縮進2.2 對代碼的復雜度進行評審，代碼要求易簡不易繁，提高可讀性，便于閱讀，代碼復雜度要降低2.3 審查并刪除

2、不可用的代碼、未被調用的過程和未使用的變量2.4 報告所有類型的數(shù)據(jù)流異常常見的數(shù)據(jù)流異常Ø 變量在初始化前使用（未初始化就使用），未定義先使用Ø 被賦值的變量一直末被使用：變量是多余無意義Ø 變量在兩次賦值之間末被使用：第一次賦值對程序而言是無意義Ø 參數(shù)不匹配：如果參數(shù)個數(shù)，類型，順序不匹配，函數(shù)調用則失敗Ø 可疑的類型轉換：例如實型數(shù)據(jù)轉為整型，小數(shù)會丟失，不為零的數(shù)據(jù)變?yōu)榱?，造成運算錯誤3 靜態(tài)測試方法分類：靜態(tài)測試人工方法（評審）由測試人員手工逐步執(zhí)行所有的活動，并觀察每一步是否成功完成代碼檢查桌面檢查代碼審查走查正規(guī)技術評審自動方法

3、使用一組測試工具對被測軟件進行分析和驗證說明：運行測試工具被測試軟件自己不運行而是被測試工具分析，作為測試工具輸入源2. 代碼檢查1. 概念：主要檢查代碼與設計的一致性，代碼對標準的遵循、可讀性，代碼邏輯表達的正確性，代碼結構的合理性等2. 代碼檢查類型：2.1 桌面檢查Ø 程序員在程序通過編譯后，對自己編寫的程序代碼進行分析、檢驗，補充相關文檔，目的是發(fā)現(xiàn)程序中的錯誤和缺陷2.2 代碼審查2.3 代碼走查3 代碼審查：3.1 由若干程序員和測試員組成一個審查小組，通過閱讀、討論和爭議，對程序進行靜態(tài)分析3.2 審查步驟Ø 第一步：準備：事先把審查材料（如設計規(guī)格說明、控制

4、流程圖、程序文本以及相關的要求和規(guī)范）分發(fā)給小組成員，準備一份常見的錯誤和缺陷清單（稱為檢查表），小組成員充分閱讀這些材料Ø 第二步：代碼審查會：程序員介紹程序邏輯，審查小組成員提問、討論、審查錯誤和缺陷是否存在3.3 GB/T 15532-2008計算機軟件測試規(guī)范附錄A介紹了靜態(tài)測試方法-代碼審查3.3.1 測試內容：檢查代碼和設計的一致性；檢查代碼執(zhí)行標準的情況；檢查代碼邏輯表達的正確性；檢查代碼結構的合理性；檢查代碼的可讀性3.3.2 組織：由四人以上組成，分別為組長、資深程序員、程序編寫者與專職測試人員3.3.3 過程：準備階段，程序閱讀，會議審查，形成報告3.3.4 代碼

5、審查單內容：寄存器使用，格式，入口和出口連接，程序語言的使用，存儲器使用，測試與轉移，性能，可維護性，邏輯，軟件等4 代碼走查：4.1 走查是一種非正式評審，被查工作產品的開發(fā)者向其他相關人員描述其產品并征求意見屬于一種即興的審查，如編寫了某一代碼，直接與其他編程人員討論，一般準備一組測試用例，人工模擬計算機運行軟件；雖然笨拙，但發(fā)現(xiàn)錯誤的概率很高，在發(fā)現(xiàn)錯誤的同時能找到解決的方法。4.2 代碼走查的步驟與代碼審查的步驟相似4.3 走查的參與者模擬計算機運行過程來人工執(zhí)行少量的、用于人工跟蹤的測試用例，其目的是質疑隱藏在源代碼之后的邏輯和基本假設4.4 走查的主要目標是對故障進行檢測和文檔化，

6、而不是對開發(fā)者的能力進行評價5 走查過程：5.1 計劃走查會議5.2 走查產品5.3 走查會議5.4 解決問題5.5 記錄走查5.6 返工產品6 走查類型：6.1 規(guī)格說明走查Ø 規(guī)格說明走查包括：系統(tǒng)規(guī)格說明、項目計劃和需求分析Ø 目標是檢查規(guī)格說明中存在的問題以及不準確、不清晰和冗長之處Ø 參與者：用戶、高級分析員、項目分析員Ø 對象：數(shù)據(jù)流圖、數(shù)據(jù)字典、實體關系圖等6.2 設計走查Ø 設計走查包括初步設計和詳細設計Ø 目標是檢查設計結構中的缺陷、薄弱環(huán)節(jié)、錯誤和冗余Ø 參與者：用戶、分析人員、高級設計師、項目設計人員&

7、#216; 對象：結構圖、詳細設計文檔等6.3 代碼走查（使用人工方法模擬計算機運行軟件）Ø 目標是檢查代碼中的錯誤以及違背標準、不清晰、不一致的地方Ø 參與者：編碼人員、項目程序員、設計人員和外部程序員Ø 對象：代碼列表、編譯器列表等6.4 測試走查Ø 測試走查包括測試計劃和測試步驟Ø 目標是檢查測試文檔中不充分、不完整和不清晰的地方Ø 參與者：項目程序員、測試人員、分析人員和設計人員Ø 對象：測試計劃、測試步驟、測試數(shù)據(jù)示例等3 代碼檢查：代碼檢查的內容事項l 檢查變量的交叉引用表l 檢查標號的交叉引用表l 檢查子程序、

8、宏、函數(shù)l 等價性檢查l 常量檢查l 標準檢查l 風格檢查l 比較控制流l 選擇、激活路徑l 對照程序的規(guī)格說明，詳細閱讀源代碼，比較實際代碼與期望代碼的差異，從中發(fā)現(xiàn)程序的問題和錯誤l 補充文檔3. 正式評審（正規(guī)評審）1 概述：正式評審在軟件開發(fā)生存周期中每個階段結束時實施，采用正式的會議評審方式，通過正式評審的活動標志著該活動到達了一個里程碑，該活動的制品也就成為一個基線；正式評審也可以在出現(xiàn)嚴重問題的時候實施2 兩種類型：管理評審和技術評審a) 項目管理評審的任務是針對適用的項目計劃、進度安排、標準和指南進行項目狀態(tài)的評價b) 技術評審的任務是舉行技術評審以評價正在考慮中的軟件產品或服

9、務，并提供相關證據(jù)（如它們是完備的、符合標準和規(guī)范的等）3. 正式技術評審內容：3.1 評審會議Ø 由評審會主席和若干名評審員組成，參加者大多是與評審內容相關的技術專家，參加人員不宜太多，通常為35人Ø 必要時(如需求評審)可請用戶代表參加 ：是否與用戶需求一致3.2 評審記錄Ø 指派專人記錄會上提出的所有問題Ø 會議結束后將其整理成一份“評審問題列表”并存檔 3.3 評審報告Ø 評審會結束時應形成評審總結報告，總結報告應指明被評審的制品，參加評審的人員，評審中發(fā)現(xiàn)的問題以及評審的結論Ø 評審總結報告不必很長(通常一頁紙就夠了)，而“

10、評審問題列表”可作為評審總結報告的附件4 正式技術評審過程：4.1 計劃4.2 預備會4.3 會前準備（自評審）4.4 評審會4.5 修正錯誤4.6 復審4.7 復核5 正式技術評審的指導原則：5.1 評審產品，而不是評審生產者（對事不對人，不是對程序員的評判）5.2 制定議事日程且遵守日程5.3 限制爭論和辨駁（主要是發(fā)現(xiàn)問題，不是為了解決問題，解決問題應放到評審會以后處理）5.4 對各個問題都發(fā)表見解，但不要試圖解決所有記錄的問題5.5 做書面筆記5.6 限制參與者人數(shù)并堅持事先做準備5.7 為每個可能要評審的工作制品建立一個檢查表5.8 為正式技術評審分配資源和時間5.9 對所有評審者進行有意義的培訓5.10 評審以前所做的評審6 正式技術評審的檢查表：6.1 根據(jù)不同的評審活動（如軟件需求評審、軟件設計評審、源代碼評審等）設計不同的檢查表6.2 例如，軟件設計評審檢