淺談白盒測試的經驗
反思經歷過的項目的白盒測試工作，有失敗的地方，也有成功的地方，但更多的是積累了經驗。這里談談自己經歷這個項目后的感受：
1、程序員永遠是對的
測試員最需要的是交流，而白盒工作和程序員交流最多。但是，往往在測試工作中受到一些規范、流程的左右，必定要和程序員的觀念不合，甚至產生矛盾。這時候，就要記住——程序員永遠是對的，即使他們做錯了。
首先要尊重程序員的設計，不要妄加評論，即使這種設計不是***的，也體現了一個程序員自己的風格。只有在尊重程序員個性特點的基礎上，才能將來更好地合作。
2、程序員永遠是錯的
這一條看起來和上一條似乎矛盾，但是，上一條是大前提，這一條適用于具體的測試工作。測試員需要對一切抱持懷疑態度，白盒測試也是一樣，甚至更需要。作為一個測試遠，需要明白：
- 程序員是很不小心的
- 程序員是很懶的
- 程序員是很不注重細節的
每當進入工作時都先這么想，才能做到每個細節，每個要素都不放過，因為難不準程序就在某個不起眼的地方當掉了。
3、關注細節，自底向上
一般白盒測試的流程是先單元測試，再集成測試。這就體現了自底向上測試的理念。這個理念不僅僅適用于流程，在具體工作時也可以參照。比如測試一個模塊時，可以從細節做起，從小到大，從底層到上層。
4、一定要注意編碼規范！
這里要注意區分編碼規范和編碼風格的區別。不同的測試員有不同的風格，也是個性的體現，但如何能統一規范？有許多程序員根本不在乎規范問題，認為只要代碼能完成既定功能，沒有bug，就是完成了項目，其實不然。現在市面上，會寫程序的一抓一大把，但是能稱為“程序員”的人甚少，頂多算“懂程序的人”。
合格的程序員不僅僅是會寫代碼，而且還應該具備將代碼融入項目的素質。作為一個程序員，寫的是工程項目，開發的模塊是給大家用的。而不是小作業，小程序。所以，代碼要考慮到項目中其它合作開發人員的使用，考慮到測試員的閱讀，考慮到將來其它項目人員的維護，作為程序員就不能隨心所欲地寫代碼，而是要遵循編碼規范，端正編碼行為。
5、文檔在哪里？
項目的每個階段都需要產出文檔，這是連學生都知道的事情。但是，實際情況又怎么樣呢？可惜在中國，70%以上的項目開發時間不足而延期，那么怎么辦？犧牲測試時間，這種做法越來越多的開發團隊明白并不可取，那么，唯有犧牲寫文檔的時間。也許這種做法也不正確，但可以理解。
作為白盒測試人員，如何面對這種窘境？強迫開發人員騰出部分編碼時間來整理文檔似乎也是不可取的。我推薦的做法是要求開發人員騰出少許時間直接將內容口述講解給測試人員，因為項目時間緊，口述時間比寫成文檔要少得多，而且也挽救了測試時間（測試人員不用等文檔出來才開始測試）。
當然，文檔還是要的，因為還要考慮到維護人員和其它項目相關人員。
6、測試時間不夠怎么辦？
事實上很多項目（包括Avatar）都有這種情況發生，這時候就要學會取舍，不要墨守成規地按照流程做事。測試最終的目的是保證質量，合理利用測試員的經驗，優先測試那些你認為有必要的。
7、白盒測試與黑盒測試是相輔相成的
這句看似是廢話的道理，其實很多人還是不以為然。有的沒有配測試員的開發團隊，認為開發完成后做一次黑盒就夠了，完全不檢查自己的代碼，或者邊編碼邊測試，項目完成后也不進行一次整體回歸。
這都是不合理的做法，雖然看起來節省了開發時間，殊不知質量不合格的話，打回來進行二次開發需要花費更多的時間，并且無形中降低了團隊的聲譽。所以，用一句老話——“兩手都要抓，兩手都要硬”。
希望對你有幫助。
【編輯推薦】
