程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> 網頁編程 >> JSP編程 >> 關於JSP >> JBuilder 2005單元測試之慨述

JBuilder 2005單元測試之慨述

編輯:關於JSP

  一個產品只有通過檢驗才能投放市場,同樣的,一個業務類也只有在經驗測試後才能保證功能的正確性,以便被其他類或程序調用,否則隱藏其中的Bug就蔓延開了。業務功能點測試是測試人員的職責,但業務類API的正確性必須由開發人員保證。

  回憶一下最近你所開發的系統,往往一個最難忘的情節是通宵達旦地毯式搜索某個刁專的Bug,歷盡千辛萬苦,最終找到並解決了它。查找一個隱藏的Bug往往是踏破鐵蹄無覓處,而找到後卻是:解決全不費功夫。

  造成這尴尬窘局有以下幾點原因:

  其一是使用增量式測試策略,即先編寫功能代碼,在模塊開發完畢後才回過頭來編寫測試用例,因為一個功能模塊可能包含許多相互關聯的類,形成了層層調用,交錯復雜的調用網絡,一旦發現了Bug,只得查戶口似的逐一排查,其艱辛程度可想而知。

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

  針對這些傳統測試思想的不足,測試先行、頻繁測試、自動測試的測試思想被越來越多的開發人員所接受並付諸實踐。

  測試先行乍聽起來有點讓人不可思議,一件東西還沒有做出來就想著怎麼去測試它?仔細分析,這並不荒唐,因為這讓你在設計類時,站在調用者的角度去理解類的對外接口,迫使你深入理解類的外在關系,考慮接口的用途,而在具體編寫程序時才去具體考慮內部實現細節,這樣設計出接口將更易使用,結構也會更趨合理。

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

  所謂自動測試並不是說有一個工具可以讓你像安檢器一樣,自動測試出你類中的問題。而是指應用一定的測試框架,為每個業務類編寫獨立的測試用例,類代碼調整後,對應的測試用例同步調整。多個測試用例組成一個測試套件一起批量運行,它們就像一個強大的Bug嗅探器,一旦發現Bug就會輸出特定的信息報告錯誤,只要一個測試用例沒有通過測試就說明程序中有問題。測試用例中所包含的測試規則完成由你定制,這個測試套件對Bug嗅探的"靈敏度"完全取決於測試用例的測試規則,框架提供編寫和運行測試用例的規范性方法。

  在編寫一個業務類時,需要相應編寫對應的測試用例,一開始挺招"慣性定律"抵觸的,因為它要求你將創建一個測試用例類,似乎需要更多的工作。但你的付出是會得到加倍回報的,隨著軟件類規模的增大你會發現,當傳統測試方法越來越捉襟見肘,窮於應付時,基於測試框架的測試技術依然"談笑自如"。當然別人這麼說,我們也不應當馬上就深信不疑,疑惑永遠是值得推崇的科學精神,我們應該通過自己的實踐卻真真切切地體會這種改進所帶來的快樂。
  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved