一.靜態白盒子測試：檢查設計和**
靜態測試是指測試非執行部分——檢查和審查。白盒測試是指訪
問**，能夠檢視和審查。靜態白盒測試實在不執行的條件下有條理地
仔細審查軟體設計、體系結構和**，從而找出軟體缺陷的過程。有時
也稱為結構分析。
進行靜態白盒子測試的首要原因就是盡早發現軟體缺陷，以找出
動態黑盒子測試難以揭示或遇到的軟體缺陷；另乙個好處是為接受該軟
件測試的黑盒測試員的測試案例提供思路，他們不必了解**細節，但
是根據審查備註，可以確定似乎有問題或者存在軟體缺陷的特性範圍。
二.正式審查
正式審查就是進行靜態白盒子測試的過程。正式審查含義廣泛，從
程式設計師之間的交談，到**的嚴格檢查均屬於此過程。
有4個基本要素：
1.確定問題。審查的目標是找出軟體的問題，不僅是出錯的專案，還包
括遺漏的專案。全部的批評應直指**，而不是其建立者。合作者不應
該互相指責。個人情緒化感覺要保留。
2.遵守規則。 審查要遵守一套固定的規則，規則可能設定要審查的代
碼量、花費多少時間、哪些內容要做備註等等。其重要性在於合作者了
解自己的作用和目標，這有助於使審查進展的更加順利。
3. 準備。每個合作者需要了解自己的責任和義務，並積極參與審查。
在審查過程中找出問題大部分的缺陷是在準備期間發現的，而不是實際
審查期間。
4.編寫報告。審查小組必須做出總結審查結果的書面報告，並使報告便
於開發小組使用。審查結果必須盡快告訴別人，比如發現多少問題，在
哪發現的。
正式審查有三種型別：
1.同事審查：召集小組成員進行初次正式審查是最簡單的方法就是同時
審查。類似於「各抒己見」型別的討論。常常僅在編寫**的程式設計師和
充當審查者的其他一兩個程式設計師和測試員之間進行；
2.公開陳述：公開陳述是使同事審查正規化的下一步。編寫**的程式
員像5人小組或其它類似的程式設計師或測試員正式表述。審查人員應該在
審查之前接到軟體拷貝，以便檢查並編寫備註和問題，在審查過程中提
問。3.檢驗：檢驗是最正式的審查型別，具有高度組織化，要求每乙個參與
者都接受訓練。檢驗與同事審查不同之處在於，表述**的人不是原來
的程式設計師。這就迫使他學習和了解要表述的材料，從而有可能在檢驗會
議上提出不同的看法和解釋。另外的參與者稱為檢驗員，職責是從不同
的角度（如使用者、測試員或產品支援人員）的角度審查**。檢驗會議
後，檢驗員可能再次碰頭討論他們發現的不足之處，並與會議主席共同
準備乙份書面報告，明確解決問題所必須重做的工作。然後程式設計師進行
修改，由會議驗證修改結果，可能要要進行重新檢驗，以便找到其餘的
軟體缺陷。
三.編碼標準和規範
3個堅持標準和規範的重要原因：
1.可靠性。事實證明按照按規範編寫的**更可靠，軟體缺陷將更少。
2.可讀性/維護性。符合標準和規範的**易於閱讀，理解和維護。
3.移植性。如果**符合裝置標準，遷移到另乙個平台就會容易，甚至
沒有任何障礙。
標準由4個主要部分組成：
1.標題。描述標準包含的主題。
2.標準（或規範）。描述標準（或規範）內容，解釋哪些允許，哪些不
允許。3.解釋說明。給出標準背後的原因，讓人理解這為什麼是好的程式設計習慣
4.示例。給出如何使用此種標準的簡單程式示例，這不是必需的。
但是，對軟體進行正式審查時，測試和註解的物件僅限於錯誤和缺
漏，而不管是否堅持標準或者規範！
四.通用**審查清單
1.資料引用錯誤
資料引用錯誤是指使用未經正確地初始化的變數、常量、陣列、字串或記錄。
a. 是否引用了未初始化的變數？
b. 陣列和字串的下標是整數值嗎？下標總是在陣列和字串大小範圍之內嗎？
c.在檢索操作或者應用陣列下標時是否包含"丟掉乙個"這樣的潛在錯誤？
d.是否在應該使用常量的地方使用了變數？
e.變數是否被賦予不同型別的值？
f.為引用的指標分配記憶體了嗎？
g.乙個資料結構是否在多個函式或者子程式中引用，在每乙個引用中明確定義結構了嗎？
2.資料宣告錯誤
資料宣告錯誤是指不正確地宣告或使用變數和常量。
a.所有變數都賦予正確的長度、型別和儲存類了嗎？
b. 變數是否在宣告的同時進行了初始化？是否正確初始化並與其型別一致？
c.變數有相似的名稱嗎？
d.存在宣告過、但從未引用或者只引用過一次的變數嗎？
e.在特定模組中所有變數都顯式地宣告了嗎？
3.計算錯誤
計算錯誤是指基本的數學邏輯問題。
a.計算中是否使用了不同資料型別的變數，如整數與浮點數相加？
b.計算中是否使用了資料型別相同但位元組長度不同的變數？
c.計算時是否了解和考慮到編譯器對型別或長度不一致的變數的轉換規則？
d.賦值的目的變數是否小於賦值表示式的值？
e.在數值計算過程中是否可能出現溢位？
f.除數或模是否可能為零？
g.對於整型算術運算或某些計算，特別是除法的**處理是否會丟失精度？
h. 變數的值是否超過有意義的範圍？
i. 對於包含多個操作的表示式，求值次序是否混亂，運算優先順序對嗎？需要加括號使其清晰嗎？
4.比較錯誤
小於、大於、等於、不等於、真、假、比較和判斷錯誤很可能是邊界條件問題。
a.比較得正確嗎？
b.存在分數或者浮點數之間的比較嗎？如果有，精度問題會影響比較嗎？1.00000001和1.00000002極其接近，它們相等嗎？
c.每乙個邏輯表示式都正確地表達了嗎？邏輯計算如期進行了嗎？求值次序有疑問嗎？
d.邏輯表示式的運算元是邏輯值嗎？
5.控制流程錯誤
控制流程錯誤是指程式語言中迴圈等控制結構未按預期方式工作，通常由計算或者比較錯誤直接或間接造成。
a.程式中的語句組是否對應？
b.程式、模組、子程式和迴圈能否終止？如果不能，可以接受嗎？
c.可能存在永遠不停的迴圈嗎？
d.迴圈可能從不執行嗎？如果是這樣，可能接受嗎？
e.對於多分支語句，索引變數能超出可能的分支數目嗎？如果超出，該情況能正確處理嗎？
f.是否存在"丟掉乙個"錯誤，導致意外進入迴圈？
6.子程式引數錯誤
子程式引數錯誤的**是軟體子程式不正確地傳遞資料。
a.子程式接收的引數型別和大小與呼叫**傳送的匹配嗎？次序正確嗎？
b.如果子程式有多個入口點，引用的引數是否與當前入口點沒有關係？
c.常量是否當作形參傳遞，意外在子程式中改動？
d. 子程式是更改了僅作為輸入值的引數？
e.每乙個引數的單位是否與相應的形參匹配？
f.如果存在全域性變數，在所有引用子程式中是否有相似的定義和屬性？
7.輸入/輸出錯誤
輸入/輸出錯誤包括檔案讀取、接受鍵盤或滑鼠輸入以及向輸出裝置寫入錯誤等。
a.軟體是否嚴格遵守外設讀寫資料的專用格式？
c. 軟體是否處理外設未連線、不可用、或者讀寫過程中儲存空間佔滿等情況？
d.軟體以預期的方式處理預計的錯誤嗎？
e.檢查錯誤提示資訊的準確性、正確性、語法和拼寫了嗎？
8.其他錯誤
a.軟體是否使用其他外語？是否處理擴充套件ascii字元？是否需用統一編碼取代ascii？
b. 軟體是否需要移植到其他編譯器？
c.是否考慮了相容性，以使軟體能夠執行於不同數量的可用記憶體、不同的內部硬體、不同的外設等？
d.程式編譯是否產生"警告"或者"提示"資訊？這些資訊通常指示語句有疑問。
python 白盒測試 白盒測試方法
白盒測試是單元測試階段常用到的測試方法，其特點有 1 可以構成測試資料，使特定程式部分得到測試 2 有一定的充分性度量手段 3 可獲得較多工具支援 4 通常只用於單元測試。下邊通過一段 來看一下白盒測試中的邏輯覆蓋 那麼為了清晰，我們畫出乙個該程式的流程圖 1 語句覆蓋 語句覆蓋是最弱的邏輯覆蓋準則...
軟體測試學習5 靜態白盒測試
靜態白盒測試 檢查設計和 靜態白盒測試是指在不執行軟體的條件下有條理地仔細審查軟體設計 體系結構和 從而找出軟體缺陷的過程，有時稱為結構化分析。進行靜態白盒測試的首要原因是盡早發現軟體缺陷，以找出動態黑盒測四難以發現或隔離的軟體缺陷，黑盒測試員在接受軟體測試時設計和應用測試用例提供思路，它們通過聽 ...
什麼是 黑盒測試 白盒測試 靜態測試？
單元測試 看源 分析程式內部邏輯結構 整合測試 對設計的檢測 系統測試 測試功能 交接測試 即確認測試 測試是否符合使用者需求 黑盒測試法 一般用來確認軟體功能的正確性和可操作性,目的是檢測軟體的各個功能是否能得以實現,把被測試的程式當作乙個黑盒,不考慮其內部結構,在知道該程式的輸入和輸出之間的關係...