白盒測試
我大膽的推廣下二八原則，國內軟件測試的現狀是百分之八十以上的測試人員在做黑盒測試工作，不到百分之二十的測試人員做過白盒子測試工作。這不到百分之二十的測試人員許多又是在與開發人員共同完成的白盒測試工作。白盒測試也正在越來越受重視，前景也越來越好。雖然未必做白盒測試，但是白盒子測試用例的設計方法是需要軟件測試人員掌握的，許多公司筆試，還有軟測試考試的時候都會有白盒測試用例設計的題目出現。（我的意思不是爲了應付考試而掌握哈，即使你現在沒做白盒的測試，也要時刻爲做白盒測試而準備着。）
在軟件測試一書中，白盒測試是這樣定義的：“軟件測試人員可以訪問程序員的代碼，並通過檢查代碼來協助測試---可以看盒子裏面。”
白盒子測試也分靜態和動態兩種：
靜態白盒測試是在不執行的條件下有條理地仔細審查軟件設計、體系結構和代碼，從而找出軟件缺陷的過程，有時也稱爲結構分析。進行靜態白盒子測試的首要原因就是儘早發現軟件缺陷，以找出動態黑盒子測試難以揭示或遇到的軟件缺陷；另一個好處是爲接受該軟件測試的黑盒測試員的測試案例提供思路，他們不必瞭解代碼細節，但是根據審查備註，可以確定似乎有問題或者存在軟件缺陷的特性範圍。動態白盒測試是指利用查看代碼功能和實現方式得到的信息來確定哪些要測試，哪些不要測試，如何開展測試。
動態白盒測試的另一個常用名稱是結構化測試，因爲軟件測試員可以查看並使用代碼的內部結構，從而設計和執行測試。 動態白盒測試包括四部分：
1.直接測試底層功能、過程、子程序和庫。即應用程序接口（API）
2.以完整程序的方式從頂層測試軟件，但是要根據對軟件運行的瞭解調整測試案例。
3.從軟件獲得讀取變量和狀態信息的訪問權，以便確定測試與預期結果是否相符，同時，強制軟件以正常測試難以實現的方式運行。
4. 估算執行測試時“命中”的代碼量和具體代碼，然後調整測試，去掉多餘的，補充遺漏的。
靜態的白盒測試我沒做過，在此就不敘述了。和黑盒測試一樣，動態白盒測試也是按部就班的來，首先寫測試計劃，然後設計測試用例，再次執行用例，寫測試報告，最後寫測試總結。我做過的白盒測試，驅動程序都是開發人員做好了的，我只是按每個類裏的每個函數設計測試用例，測試函數返回值。（許多內部保護類都是無法測試的。）下面我說說用例的設計。
白盒測試有六種用例有六種覆蓋的方法分別是：
1.語句覆蓋。這個是起碼要做到的覆蓋了，程序裏的每條可執行的語句都要至少執行一次。這個設計起來比較簡單，用例數據很直觀的就能看出來。但是語句裏的判定，分支等就沒什麼意義了。可以說這樣的測試是最低的要求了。
2.判定覆蓋。每個判斷的真假分支至少執行一次，就是真要至少取一次，假要至少取一次。這個設計起來也不難，覆蓋率要比語句覆蓋高近乎一倍，但是也在判定語句中也會遺漏許多路徑，因爲每個條件的取值是不在考慮範圍內的。
3.條件覆蓋。和判定覆蓋思路一樣，只是把重點從判定移動到條件上來了，每個判定中的每個條件可能至少滿足一次，也就是每個條件至少要取一次真的，再取一次假的。同樣它也會遺漏許多路徑，條件取真假並不能滿足判定也取到真假兩次。
4.判定條件覆蓋。既然上面的判定和條件多是片面的，那麼這個兩個覆蓋相結合是呼之欲出判定條件覆蓋。它要求判斷中的每個條件所有可能至少出現一次,並且每個判定本身的判定結果也要出現一次。不要以爲這樣就行了，要看看條件，條件和判定不一樣，判定取真假就覆蓋了判定，可是條件取真假兩次完全不能滿足條件的各種組合。所以纔有了5~。
5.條件組合覆蓋。每個判定中條件的各種可能組合至少滿足一次。條件各種可能都出現了，必然把判定給覆蓋了，它覆蓋了上面的4個哦，可是用例數量大大增加了！看項目情況定吧。
6.路徑覆蓋。概念比較好理解，把所有可能路徑至少都走一遍，但是用例數量可想而知了。
方法是固定的，掌握方法不能只記概念，實踐！實踐出真知！下面舉個實際的例子。
這是我以前做的測試試卷一里的題
