白盒測試體系的探索

什麼是白盒測試？很多人都聽說過白盒測試。通常的說法是，白盒測試是能看到全部産品源代碼的測試。常常，白盒測試都是和牛人綁在一起的。個人認為這是一種比較狹隘的說法。然而究竟什麼是白盒測試呢？可能有很多的人在做了很長時間的白盒測試以後發現，自己其實不是在做白盒測試，而是在做灰盒測試，原因是不夠“白”，因為他沒有看到全部的産品代碼。其實，我個人認為，這是做白盒測試的誤區。從廣義來說，個人認為，白盒測試就是代碼級的測試，是軟體半成品的測試，不存在所謂的灰盒測試。所謂的灰盒測試，隻不過是因為代碼的暴露程度不同而已，從本質上來說，都是白盒測試。其實，無論是作為一個測試者，還是作為一個開發者，誰也不能保證通曉所有的代碼，尤其是在現代軟體企業中工程師的職責和分工越來越細，第二、三方庫越來越豐富了以後。

    然而，我們該如何建構白盒測試體系呢？由前面的讨論，我們可以知道，産品代碼的暴露程度在白盒測試體系中有着十分重要的作用。如下圖：

     在代碼暴露量等于零的時候，測試的粒度和廣度不是等于零的，這裡代表的是黑盒測試。随着代碼暴露量的增加，測試的粒度和廣度并不是線性上升的，這裡主要展現了一個含義，代碼暴露量的邊際效應該是遞減的。也就是說，代碼暴露量的增加給測試帶來的難度是增加的。當代碼暴露量達到100%的時候，我們也很難做到測試覆寫率達到100%。

由此分析，我們可以将白盒測試體系按照代碼暴露量由多到少做如下的劃分：深度測試，單元測試，接口測試，內建測試，壓力測試與性能分析。這是一個完整的白盒測試體系，可以适用于各種系統的測試。深度測試，是指深入到系統中的每一個函數進行測試；單元測試，是指對系統中的各子業務單元進行測試，需要完成業務單元的開發以後進行；接口測試，包含兩個方面的内容，即系統内部接口和外部接口，内部接口測試需要考慮系統内部多态的實作，外部接口則需要測試系統提供服務的有效性；內建測試，常常是系統的所有代碼開發完成以後，可以對系統中所有業務單元進行內建，對各種業務邏輯進行測試，需要深入了解系統的需求；壓力測試與性能分析，這個部分其實也許不能算是白盒測試的範疇，然而，我依然把這一部分納入到白盒測試體系考慮的範疇，這也許是一個很有效的考察系統性能的途徑，因為通過白盒測試的方法，我們可以對系統進行精确施壓，對于這個問題，我在後面的分析中還會繼續談到。

然而，我們該如何做白盒測試呢？經過個人的實踐與總結，系統切分是白盒測試應用的一個很重要的方法。我們需要像庖丁解牛一樣，将系統進行有效的切分，對切分出來的系統進行逐個測試。大型複雜系統可以切分成若幹個小系統，小系統又可以切分成若幹子系統等等。例如，某應用系統，使用者終端是最終産品，在終端的下面我們可能有業務層的動态庫，在業務層的動态庫下面，我們可能有很多的基本功能動态庫等等。對于淘寶的J2EE架構，我們也可以進行同樣的系統拆分。對于切分的粒度，我們需要深入考慮投入産出比。切的過細，會導緻投入過多，可能得到的效果不一定明顯，也存在着邊際效用遞減的可能；而切的過粗則可能産出達不到要求。是以，在做系統切分的時候，需要掌握一個平衡點，對現有的資源和産品的測試需求做仔細的權衡。由于系統的切分，同時由于精确施壓，我們可以對單一子系統的性能做很好的分析與衡量，這将對系統的整體性能分析有非常大的幫助。

根據個人做白盒測試成功與失敗的經驗總結，在做白盒測試的時候，有一些重要的原則可能是決定白盒測試成敗的關鍵。原則一：在做系統切分的時候，我們要找到正确的系統邊界；在測試的時候，我們需要站在正确的角度來看待系統，找到正确的系統接口，并對其進行測試；原則二：直接面對産品代碼或者接口進行測試，不要使用中間件進行轉換；原則三：在做白盒測試之前需要先做好業務邏輯的抽象與設計，提高測試代碼的重用性，避免大量的粘貼與複制；原則四：測試腳本語言最好與産品開發語言一緻，例如，C++開發的産品最好用C++來測試，當然，這會增加一定的技術難度。