件測試之白盒測試體系的探索 軟件測試方法
什么是白盒測試？很多人都聽說過白盒測試。通常的說法是，白盒測試是能看到全部產品源代碼的測試。常常，白盒測試都是和牛人綁在一起的。個人認為這是一種比較狹隘的說法。然而究竟什么是白盒測試呢？可能有很多的人在做了很長時間的白盒測試以后發現，自己其實不是在做白盒測試，而是在做灰盒測試，原因是不夠“ 白”，因為他沒有看到全部的產品代碼。其實，我個人認為，這是做白盒測試的誤區。從廣義來說，個人認為，白盒測試就是代碼級的測試，是軟件半成品的測試，不存在所謂的灰盒測試。所謂的灰盒測試，只不過是因為代碼的暴露程度不同而已，從本質上來說，都是白盒測試。其實，無論是作為一個測試者，還是作為一個開發者，誰也不能保證通曉所有的代碼，尤其是在現代軟件企業中工程師的職責和分工越來越細，第二、三方庫越來越豐富了以后。
然而，我們該如何構建白盒測試體系呢？由前面的討論，我們可以知道，產品代碼的暴露程度在白盒測試體系中有著十分重要的作用。如下圖：
在代碼暴露量等于零的時候，測試的粒度和廣度不是等于零的，這里代表的是黑盒測試。隨著代碼暴露量的增加，測試的粒度和廣度并不是線性上升的，這里主要體現了一個含義，代碼暴露量的邊際效應該是遞減的。也就是說，代碼暴露量的增加給測試帶來的難度是增加的。當代碼暴露量達到100%的時候，我們也很難做到測試覆蓋率達到100%。
由此分析，我們可以將白盒測試體系按照代碼暴露量由多到少做如下的劃分：深度測試，單元測試，接口測試，集成測試，壓力測試與性能分析。這是一個完整的白盒測試體系，可以適用于各種系統的測試。深度測試，是指深入到系統中的每一個函數進行測試；單元測試，是指對系統中的各子業務單元進行測試，需要完成業務單元的開發以后進行；接口測試，包含兩個方面的內容，即系統內部接口和外部接口，內部接口測試需要考慮系統內部多態的實現，外部接口則需要測試系統提供服務的有效性；集成測試，常常是系統的所有代碼開發完成以后，可以對系統中所有業務單元進行集成，對各種業務邏輯進行測試，需要深入了解系統的需求；壓力測試與性能分析，這個部分其實也許不能算是白盒測試的范疇，然而，我依然把這一部分納入到白盒測試體系考慮的范疇，這也許是一個很有效的考察系統性能的途徑，因為通過白盒測試的方法，我們可以對系統進行精確施壓，對于這個問題，我在后面的分析中還會繼續談到。
然而，我們該如何做白盒測試呢？經過個人的實踐與總結，系統切分是白盒測試應用的一個很重要的方法。我們需要像庖丁解牛一樣，將系統進行有效的切分，對切分出來的系統進行逐個測試。大型復雜系統可以切分成若干個小系統，小系統又可以切分成若干子系統等等。例如，某應用系統，用戶終端是最終產品，在終端的下面我們可能有業務層的動態庫，在業務層的動態庫下面，我們可能有很多的基本功能動態庫等等。對于淘寶的J2EE架構，我們也可以進行同樣的系統拆分。對于切分的粒度，我們需要深入考慮投入產出比。切的過細，會導致投入過多，可能得到的效果不一定明顯，也存在著邊際效用遞減的可能；而切的過粗則可能產出達不到要求。因此，在做系統切分的時候，需要掌握一個平衡點，對現有的資源和產品的測試需求做仔細的權衡。由于系統的切分，同時由于精確施壓，我們可以對單一子系統的性能做很好的分析與衡量，這將對系統的整體性能分析有非常大的幫助。
根據個人做白盒測試成功與失敗的經驗總結，在做白盒測試的時候，有一些重要的原則可能是決定白盒測試成敗的關鍵。原則一：在做系統切分的時候，我們要找到正確的系統邊界；在測試的時候，我們需要站在正確的角度來看待系統，找到正確的系統接口，并對其進行測試；原則二：直接面對產品代碼或者接口進行測試，不要使用中間件進行轉換；原則三：在做白盒測試之前需要先做好業務邏輯的抽象與設計，提高測試代碼的重用性，避免大量的粘貼與復制；原則四：測試腳本語言最好與產品開發語言一致，例如，C++開發的產品最好用C++來測試，當然，這會增加一定的技術難度。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
