關(guān)于靜態(tài)白盒測試 檢驗代碼的一些問題
白盒測試也稱結(jié)構(gòu)測試或邏輯驅(qū)動測試，它是按照程序內(nèi)部的結(jié)構(gòu)測試程序，通過測試來檢測產(chǎn)品內(nèi)部動作是否按照設計規(guī)格說明書的規(guī)定正常進行，檢驗程序中的每條通路是否都能按預定要求正確工作。下面介紹靜態(tài)白盒測試，關(guān)于檢驗代碼的一些問題。
1. 說出靜態(tài)白盒測試的幾點好處。
靜態(tài)白盒測試在開發(fā)過程早期發(fā)現(xiàn)軟件缺陷，使修復的時間和費用大幅度降低。軟件測試員可以得到軟件如何運作的信息，存在哪些弱點和危險，而且可以與程序員建立良好的伙伴關(guān)系。項目狀態(tài)可以傳達給參與測試的所有小組成員。
2. 靜態(tài)白盒測試可以找出遺漏之處和問題？
對。遺漏的問題比普通的問題更重要，通過靜態(tài)白盒測試可以發(fā)現(xiàn)。當根據(jù)公布的標準和規(guī)范檢查代碼，在正式審查中仔細分析時，遺漏的問題就顯而易見了。
3. 正式審查由哪些關(guān)鍵要素組成？
過程。按照過程進行是正式檢查和兩個程序員之間互查代碼的區(qū)別。
4. 除了更正式外，檢驗與其他審查類型有什么重大差別？
主要區(qū)別是，檢驗時在場的不是代碼的原創(chuàng)者。這迫使另一個人完全理解要檢查的軟件。這比讓其他人只是審查軟件尋找軟件缺陷更有效。
5. 緩沖區(qū)溢出錯誤作為一個常見的安全問題術(shù)語哪一級錯誤？是由什么原因引起的？
數(shù)據(jù)引用。它們是由于使用了未正確聲明或未進行初始化的變量、常量、數(shù)組、字符串或記錄。
通用代碼審查清單：
在代碼審查時，我們可以運用代碼審查清單，將以往所有可能發(fā)生的常見錯誤羅列出來，供與會者對照檢查，從而提高會審效率。
（1）數(shù)據(jù)引用錯誤
數(shù)據(jù)引用錯誤是指使用未經(jīng)正確地初始化的變量、常量、數(shù)組、字符串或記錄。
＊ 是否引用了未初始化的變量？
＊ 數(shù)組和字符串的下標是整數(shù)值嗎？下標總是在數(shù)組和字符串大小范圍之內(nèi)嗎？
＊ 在檢索操作或者應用數(shù)組下標時是否包含“丟掉一個”這樣的潛在錯誤？
＊ 是否在應該使用常量的地方使用了變量？
＊ 變量是否被賦予不同類型的值？
＊ 為引用的指針分配內(nèi)存了嗎？
＊ 一個數(shù)據(jù)結(jié)構(gòu)是否在多個函數(shù)或者子程序中引用，在每一個引用中明確定義結(jié)構(gòu)了嗎？
（2）數(shù)據(jù)聲明錯誤
數(shù)據(jù)聲明錯誤是指不正確地聲明或使用變量和常量。
＊ 所有變量都賦予正確的長度、類型和存儲類了嗎？
＊ 變量是否在聲明的同時進行了初始化？是否正確初始化并與其類型一致？
＊ 變量有相似的名稱嗎？
＊ 存在聲明過、但從未引用或者只引用過一次的變量嗎？
＊ 在特定模塊中所有變量都顯式地聲明了嗎？
（3）計算錯誤
計算錯誤是指基本的數(shù)學邏輯問題。
＊ 計算中是否使用了不同數(shù)據(jù)類型的變量，如整數(shù)與浮點數(shù)相加？
＊ 計算中是否使用了數(shù)據(jù)類型相同但字節(jié)長度不同的變量？
＊ 計算時是否了解和考慮到編譯器對類型或長度不一致的變量的轉(zhuǎn)換規(guī)則？
＊ 賦值的目的變量是否小于賦值表達式的值？
＊ 在數(shù)值計算過程中是否可能出現(xiàn)溢出？
＊ 除數(shù)或模是否可能為零？
＊ 對于整型算術(shù)運算或某些計算，特別是除法的代碼處理是否會丟失精度？
＊ 變量的值是否超過有意義的范圍？
＊ 對于包含多個操作的表達式，求值次序是否混亂，運算優(yōu)先級對嗎？需要加括號使其清晰嗎？
（4）比較錯誤
小于、大于、等于、不等于、真、假、比較和判斷錯誤很可能是邊界條件問題。
＊ 比較得正確嗎？
＊ 存在分數(shù)或者浮點數(shù)之間的比較嗎？如果有，精度問題會影響比較嗎？1.00000001和1.00000002極其接近，它們相等嗎？
＊ 每一個邏輯表達式都正確地表達了嗎？邏輯計算如期進行了嗎？求值次序有疑問嗎？
＊ 邏輯表達式的操作數(shù)是邏輯值嗎？
（5）控制流程錯誤
控制流程錯誤是指編程語言中循環(huán)等控制結(jié)構(gòu)未按預期方式工作，通常由計算或者比較錯誤直接或間接造成。
＊ 程序中的語句組是否對應？
＊ 程序、模塊、子程序和循環(huán)能否終止？如果不能，可以接受嗎？
＊ 可能存在永遠不停的循環(huán)嗎？
＊ 循環(huán)可能從不執(zhí)行嗎？如果是這樣，可能接受嗎？
＊ 對于多分支語句，索引變量能超出可能的分支數(shù)目嗎？如果超出，該情況能正確處理嗎？
＊ 是否存在“丟掉一個”錯誤，導致意外進入循環(huán)？
（6）子程序參數(shù)錯誤
子程序參數(shù)錯誤的來源是軟件子程序不正確地傳遞數(shù)據(jù)。
＊ 子程序接收的參數(shù)類型和大小與調(diào)用代碼發(fā)送的匹配嗎？次序正確嗎？
＊ 如果子程序有多個入口點，引用的參數(shù)是否與當前入口點沒有關(guān)系？
＊ 常量是否當作形參傳遞，意外在子程序中改動？
＊ 子程序是更改了僅作為輸入值的參數(shù)？
＊ 每一個參數(shù)的單位是否與相應的形參匹配？
＊ 如果存在全局變量，在所有引用子程序中是否有相似的定義和屬性？
（7）輸入/輸出錯誤
輸入/輸出錯誤包括文件讀取、接受鍵盤或鼠標輸入以及向輸出設備寫入錯誤等。
＊ 軟件是否嚴格遵守外設讀寫數(shù)據(jù)的專用格式？
＊ 文件或者外設不存在或者未準備好的錯誤情況有處理嗎？
＊ 軟件是否處理外設未連接、不可用、或者讀寫過程中存儲空間占滿等情況？
＊ 軟件以預期的方式處理預計的錯誤嗎？
＊ 檢查錯誤提示信息的準確性、正確性、語法和拼寫了嗎？
（8）其他錯誤
＊ 軟件是否使用其他外語？是否處理擴展ASCII字符？是否需用統(tǒng)一編碼取代ASCII？
＊ 軟件是否需要移植到其他編譯器？
＊ 是否考慮了兼容性，以使軟件能夠運行于不同數(shù)量的可用內(nèi)存、不同的內(nèi)部硬件、不同的外設等？
＊ 程序編譯是否產(chǎn)生“警告”或者“提示”信息？這些信息通常指示語句有疑問。
但在項目小組驗證代碼時，并不能簡單地以這些代碼審查清單未標準，因為這只是用做一個通用的示例。其中雖然有謝好的測試用例應該在測試代碼時考慮，但是，英愛研讀其他公開的標準之后再采用自己的標準。
【編輯推薦】
