軟件測試規范(11)

　　表達式分析 ：對表達式進行分析，以發現和糾正在表達式中出現的錯誤。包括：在表達式中不正確地使用了括號造成錯誤。數組下標越界造成錯誤。除式為零造成錯誤。對負數開平方，或對π求正切值造成錯誤。以及對浮點數計算的誤差進行檢查。

　　界面分析 ：關于接口的靜態錯誤分析主要檢查過程、函數過程之間接口的一致性。因此要檢查形參與實參在類型、數量、維數、順序、使用上的一致性;檢查全局變量和公共數據區在使用上的一致性。

　　5.2人工測試

　　靜態分析中進行人工測試的主要方法有桌前檢查、代碼審查和走查。經驗表明，使用這種方法能夠有效地發現30%到70%的邏輯設計和編碼錯誤。

　?、?桌前檢查(Desk Checking)

　　由程序員自己檢查自己編寫的程序。程序員在程序通過編譯之后，進行單元測試設計之前，對源程序代碼進行分析，檢驗，并補充相關的文文件，目的是發現程序中的錯誤。檢查項目有：

　　檢查變數的交叉引用表 ：重點是檢查未說明的變量和違反了類型規定的變量;還要對照源程序，逐個檢查變量的引用、變量的使用序列;臨時變量在某條路徑上的重寫情況;局部變量、全局變量與特權變量的使用;

　　檢查標號的交叉引用表 ：驗證所有標號的正確性：檢查所有標號的命名是否正確;轉向指定位置的標號是否正確。

　　檢查子程序、宏、函數 ：驗證每次調用與被調用位置是否正確;確認每次被調用的子程序、宏、函數是否存在;檢驗調用序列中調用方式與參數順序、個數、類型上的一致性。

　　等值性檢查 ：檢查全部等價變量的類型的一致性，解釋所包含的類型差異。

　　常量檢查 ：確認每個常量的取值和數制、數據類型;檢查常量每次引用同它的取值、數制和類型的一致性;

　　標準檢查 ：用標準檢查程序或手工檢查程序中違反標準的問題。

　　風格檢查 ：檢查在程序設計風格方面發現的問題。

　　比較控制流 ：比較由程序員設計的控制流圖和由實際程序生成的控制流圖，尋找和解釋每個差異，修改文檔和校正錯誤。

　　選擇、啟動路徑 ：在程序員設計的控制流圖上選擇路徑，再到實際的控制流圖上啟動這條路徑。如果選擇的路徑在實際控制流圖上不能啟動，則源程序可能有錯。用這種方法啟動的路徑集合應保證源程序模塊的每行代碼都被檢查，即桌前檢查應至少是語句覆蓋。

　　對照程序的規格說明，詳細閱讀源代碼 ：程序員對照程序的規格說明書、規定的算法和程序設計語言的語法規則，仔細地閱讀源代碼，逐字逐句進行分析和思考，比較實際的代碼和期望的代碼，從它們的差異中發現程序的問題和錯誤。

　　補充文檔 ：桌前檢查的文檔是一種過渡性的文檔，不是公開的正式文檔。通過編寫文文件，也是對程序的一種下意識的檢查和測試，可以幫助程序員發現和抓住更多的錯誤。

　　這種桌前檢查，由于程序員熟悉自己的程序和自身的程序設計風格，可以節省很多的檢查時間，但應避免主觀片面性。

　?、?代碼會審(Code Reading Review)

　　代碼會審是由若干程序員和測試員組成一個會審小組，通過閱讀、討論和爭議，對程序進行靜態分析的過程。

　　代碼會審分兩步：第一步，小組負責人提前把設計規格說明書、控制流程圖、程序文本及有關要求、規范等分發給小組成員，作為評審的依據。小組成員在充分閱讀這些材料之后，進入審查的第二步：召開程序審查會。在會上，首先由程序員逐句講解程序的邏輯。在此過程中，程序員或其它小組成員可以提出問題，展開討論，審查錯誤是否存在。實踐表明，程序員在講解過程中能發現許多原來自己沒有發現的錯誤，而討論和爭議則促進了問題的暴露。

　　在會前，應當給會審小組每個成員準備一份常見錯誤的清單，把以往所有可能發生的常見錯誤羅列出來，供與會者對照檢查，以提高會審的實效。這個常見錯誤清單也叫做檢查表，它把程序中可能發生的各種錯誤進行分類，對每一類列舉出盡可能多的典型錯誤，然后把它們制成表格，供在會審時使用。這種檢查表類似于本章單元測試中給出的檢查表。

　?、?走查(Walkthroughs)

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

原文轉自：http://www.uml.org.cn/Test/201511262.asp