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