淺談白盒測試

　　針對測試，一直都有黑，白之分。由于白盒一般情況下需要有比較高的技術要求及比一般開發人員還要高的項目經驗和縝密的邏輯思維能力，所以一般做信息系統的軟件公司會忽略白盒測試。但個人一直覺得，對于一個健康的測試團隊來講，必須要有一個或多個熟悉白盒測試的人員。倒不一定說熟悉白盒測試的人員一定需要寫代碼，但一定要懂得如何去做白盒測試和白盒測試用例的設計。

　　一個成熟的軟件公司，必須要有一個精英匯集的研發團隊，人數在精不在多。這個研發團隊的功能主要有兩個。

　　其一，嚴密監控業界的最新動態，根據公司的技術，軟件習慣及文化，及時掌握最新的相關動態及技術信息，并將篩選出的有用信息及時轉換為相關生產力，向公司內部推送。

　　內部的推送形式也可以分兩種，一種是平板傳達，也就是互聯網上相關消息進行篩選后直接傳遞給開發人員，促進全員的整體技術能力的提升;另一種是實踐傳達，是將業界的相關最新技術研發人員自己掌握后，針對一些閃光點，做成成品DEMO，向相關高層人員，公司領導和各個業務口的項目經理進行推廣。

　　其二，創建，推廣及維護升級公司的整體技術框架及對于技術疑難問題的解答。一般情況下，項目的進度時間要求都比較高。因為一個業務負責人，不可能像專業人士那樣熟悉了解軟件開發流程，他們一旦決定做一個系統，巴不得第二天就要看到成果。雖然大家都知道前期很重要，但如果項目經理的經驗有點欠缺，往往就會被業務負責人牽著鼻子走，為了加快進度而忽略了前期的工作準備。在項目一開始，就給后面的項目推廣，人為的增加了難度。而有效規避該問題的一個重要手段就是，整個軟件開發團隊有統一的系統技術框架，將最常用的功能打包封裝，諸如內容管理，系統管理等功能，直接封裝好提高使用就好。針對業務功能很強的業務系統，那提供給最基礎的 Framework,WebCommer之類的內容。也能給項目組提供很大的方便，節省很多時間。這樣做的好處，除了可以提升項目后期開發的效率，縮短開發時間，避免不必要的加班外，統一的系統設計風格和統一的UI交互風格，讓熟悉該軟件團隊的人，在接觸到以前沒有涉及的系統時，會有似曾相識的感覺。增加陌生用戶對系統的親和。

　　有了以上的研發需求，那么作為系統質量保障的測試團隊，更需要對這些最底層的功能做好充分的測試，保證上層開發人員使用框架的正確性。這是一般的項目管理者都明白的道理，其實也是大家都明白的道理，好的醫生治病，還沒等病冒出來，就滅掉它了。

　　最底層的基礎框架，測試方法只能是白盒測試中的單元測試。而且單元測試只能在研發的工作中進行。主要在于，單元測試除了要窮舉測試用例外，還需要寫比正常開發量3-4倍的代碼量(該數據是我08年親身體驗得到的)。試想在一個有著Deadline 逼著的項目開發過程中，又有哪個項目經理會采納單元測試的方案?!又有哪個開發人員愿意去加班寫單元測試的代碼?又有哪個測試人員有精力又做黑盒又寫白盒?!

　　所以說，白盒測試的實施是需要很多條件的。其一，在研發項目中實施;其二，為了做到真正的測試透徹，不能有太大的測試時間壓力;其三，單元測試的編碼由開發人員來執行，而不是測試人員。

　　那么肯定有人要問了，大致的問題有兩個，1，白盒單元測試的代碼由開發人員來寫，測試人員干嘛?!2，如何來保障代碼的正確性?!

　　其實，回答了以上的兩個問題，也就是下來要闡述的，如何在項目中實施白盒測試了。還是畫圖說明要清晰一些。見下圖：

　　1、確定測試范圍，這項工作一定是需要做的。做事沒有范圍就沒有目標，不管是實施型項目還是研發型項目，都有一個確定的目標，這樣才能更好的衡量成果。測試工作當然也一樣。

　　2、測試用例設計：單元測試的用例設計很繁瑣，因為此處和項目的用例設計不同。項目的測試用例設計前面已經說過了，一般情況下，編寫者和執行者是一個人，大體記錄下測試思路即可。但單元測試的用例設計者和執行者是分開的，而且又主要是針對異常情況進行驗證的。所以單元測試的用例設計要注意，一個是窮舉，一個是邊界異常。

　　3、代碼編寫及走查：這兩步和在一起進行。個人主張誰寫的功能，誰來寫單元測試的代碼。一個是本人對他的代碼比較熟悉，寫起來上手快，不用走讀懂代碼那一段。另一個是測試人員的思路一般比較縝密，當開發人員嚴格按照測試用例將單元測試的用例代碼完成后，以后在開發過程中，針對自己的薄弱環節會有意識的加強異常的處理。但是，人的思路是有自己的特點的，自己寫的代碼往往在某一點總是出問題，那么代碼走查的工作就非常重要，一個是測試經理進行代碼通讀，檢查用例的覆蓋度和代碼的正確度，挑出明顯的代碼錯誤外，還應加強交叉檢查。通過其他人的眼睛來找到自己的差錯，更容易發現問題一些。

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