一個產(chǎn)品只有通過檢驗才能投放市場，同樣的，一個業(yè)務(wù)類也只有在經(jīng)驗測試后才能保證功能的正確性，以便被其他類或程序調(diào)用，否則隱藏其中的Bug就蔓延開了。業(yè)務(wù)功能點測試是測試人員的職責(zé)，但業(yè)務(wù)類API的正確性必須由開發(fā)人員保證。

　　回憶一下最近你所開發(fā)的系統(tǒng)，往往一個最難忘的情節(jié)是通宵達旦地毯式搜索某個刁專的Bug，歷盡千辛萬苦，最終找到并解決了它。查找一個隱藏的Bug往往是踏破鐵蹄無覓處，而找到后卻是：解決全不費功夫。

　　造成這尷尬窘局有以下幾點原因：

　　其一是使用增量式測試策略，即先編寫功能代碼，在模塊開發(fā)完畢后才回過頭來編寫測試用例，因為一個功能模塊可能包含許多相互關(guān)聯(lián)的類，形成了層層調(diào)用，交錯復(fù)雜的調(diào)用網(wǎng)絡(luò)，一旦發(fā)現(xiàn)了Bug，只得查戶口似的逐一排查，其艱辛程度可想而知。

　　其二是使用不正確的測試方法，如在每個類中提供一個main()測試函數(shù)，對類中的功能方法進行測試，通過運行類的main()方法查看類功能的正確性。在某種程序上，這或許是一個值得贊揚的工作習(xí)慣，但工作方式卻不足取。因為每個類都必須單獨運行，以執(zhí)行其測試功能，并由開發(fā)人員觀察測試的正確性。隨著程序規(guī)模的擴大，類數(shù)目直線上升，原有的類也會發(fā)生代碼的調(diào)整，一些功能點可能就變成了漏網(wǎng)之魚，變成了茫茫"類"海里的黑戶口，將來"違法亂紀(jì)"起來就很難監(jiān)控了。

　　針對這些傳統(tǒng)測試思想的不足，測試先行、頻繁測試、自動測試的測試思想被越來越多的開發(fā)人員所接受并付諸實踐。

　　測試先行乍聽起來有點讓人不可思議，一件東西還沒有做出來就想著怎么去測試它？仔細分析，這并不荒唐，因為這讓你在設(shè)計類時，站在調(diào)用者的角度去理解類的對外接口，迫使你深入理解類的外在關(guān)系，考慮接口的用途，而在具體編寫程序時才去具體考慮內(nèi)部實現(xiàn)細節(jié)，這樣設(shè)計出接口將更易使用，結(jié)構(gòu)也會更趨合理。

　　頻繁測試，即指測試不應(yīng)當(dāng)是階段性的工作，而應(yīng)當(dāng)在程序編寫過程中不斷進行。因為系統(tǒng)中的類之間往往都存在較多的關(guān)聯(lián)關(guān)系，當(dāng)更改了類的功能時，往往會有多個類受到直接或間接的影響。所以你應(yīng)該頻繁測試以及早發(fā)現(xiàn)這種因功能、調(diào)整而引起的Bug，越早發(fā)現(xiàn)錯誤解決它的代價越小。頻繁測試也是XP編程的一個重要環(huán)節(jié)，XP編程總讓人覺得他們注重功能實現(xiàn)而忽視測試，其實他們也非常關(guān)注測試，畢竟測試可以使他們盡可能快的穩(wěn)步前進。

　　所謂自動測試并不是說有一個工具可以讓你像安檢器一樣，自動測試出你類中的問題。而是指應(yīng)用一定的測試框架，為每個業(yè)務(wù)類編寫?yīng)毩⒌臏y試用例，類代碼調(diào)整后，對應(yīng)的測試用例同步調(diào)整。多個測試用例組成一個測試套件一起批量運行，它們就像一個強大的Bug嗅探器，一旦發(fā)現(xiàn)Bug就會輸出特定的信息報告錯誤，只要一個測試用例沒有通過測試就說明程序中有問題。測試用例中所包含的測試規(guī)則完成由你定制，這個測試套件對Bug嗅探的"靈敏度"完全取決于測試用例的測試規(guī)則，框架提供編寫和運行測試用例的規(guī)范性方法。

　　在編寫一個業(yè)務(wù)類時，需要相應(yīng)編寫對應(yīng)的測試用例，一開始挺招"慣性定律"抵觸的，因為它要求你將創(chuàng)建一個測試用例類，似乎需要更多的工作。但你的付出是會得到加倍回報的，隨著軟件類規(guī)模的增大你會發(fā)現(xiàn)，當(dāng)傳統(tǒng)測試方法越來越捉襟見肘，窮于應(yīng)付時，基于測試框架的測試技術(shù)依然"談笑自如"。當(dāng)然別人這么說，我們也不應(yīng)當(dāng)馬上就深信不疑，疑惑永遠是值得推崇的科學(xué)精神，我們應(yīng)該通過自己的實踐卻真真切切地體會這種改進所帶來的快樂。