Java測試開發小技巧
發布時間:2023-01-12 13:10:50 已幫助:人 來源:北京龍騰測試
隨著it時代的發展JAVA已然是軟件測試工程師深受歡迎的,那么要如何才能掌握正確的Java測試開發操作流程呢,今天小編就教大家七個小妙招讓你瞬間成為JAVA工程師職業高手,一起跟我來了解下吧。
Java提供了若干用于單元測試的框架。TestNG和JUnit是最流行的測試框架。JUnit和TestNG的一些重要功能:
●易于設置和運行。
●支持注釋。
●允許忽略或分組并一起執行某些測試。
●支持參數化測試,即通過在運行時指定不同的值來運行單元測試。
●通過與構建工具,如Ant,Maven和Gradle集成來支持自動化的測試執行。
EasyMock是一個模擬框架,是單元測試框架,如JUnit和TestNG的補充。EasyMock本身不是一個完整的框架。它只是添加了創建模擬對象以便于測試的能力。例如,我們想要測試的一個方法可以調用從數據庫獲取數據的DAO類。在這種情況下,EasyMock可用于創建返回硬編碼數據的MockDAO。這使我們能夠輕松地測試我們意向的方法,而不必擔心數據庫訪問。
2.謹慎使用測試驅動開發!
測試驅動開發(TDD)是一個軟件開發過程,在這過程中,在開始任何編碼之前,我們基于需求來編寫測試。由于還沒有編碼,測試最初會失敗。然后寫入最小量的代碼以通過測試。然后重構代碼,直到被優化。
目標是編寫覆蓋所有需求的測試,而不是一開始就寫代碼,卻可能甚至都不能滿足需求。TDD是偉大的,因為它導致簡單的模塊化代碼,且易于維護。總體開發速度加快,容易發現缺陷。此外,單元測試被創建作為TDD方法的副產品。
然而,TDD可能不適合所有的情況。在設計復雜的項目中,專注于最簡單的設計以便于通過測試用例,而不提前思考可能會導致巨大的代碼更改。此外,TDD方法難以用于與遺留系統,GUI應用程序或與數據庫一起的應用程序交互的系統。另外,測試需要隨著代碼的改變而更新。
因此,在決定采用TDD方法之前,應考慮上述因素,并應根據項目的性質采取措施。
3.測量代碼覆蓋率
代碼覆蓋率衡量(以百分比表示)了在運行單元測試時執行的代碼量。通常,高覆蓋率的代碼含未檢測到的錯誤的幾率要低,因為其更多的源代碼在測試過程中被執行。測量代碼覆蓋率的一些做法括:
●使用代碼覆蓋工具,如Clover,Corbetura,JaCoCo或Sonar。使用工具可以提高測試質量,因為這些工具可以指出未經測試的代碼區域,讓你能夠開發開發額外的測試來覆蓋這些領域。
●每當寫入新功能時,立即寫新的測試覆蓋。
●確保有測試用例覆蓋代碼的所有分支,即if/else語句。
測試是開發的一個非常重要的方面,可以在很大程度上決定一個應用程序的命運。良好的測試可以在早期捕獲導致應用程序崩潰的問題,但較差的測試往往總是導致故障和停機。
雖然有三種主要類型的軟件測試:單元測試,功能測試和集成測試,但是在這篇博文中,我們將討論開發人員級單元測試。在我深入講述具體細節之前,讓我們先來回顧一下這三種測試的詳細內容。
軟件開發測試的類型
單元測試用于測試各個代碼組件,并確保代碼按照預期的方式。單元測試由開發人員編寫和執行。大多數情況下,使用JUnit或TestNG之類的測試框架。測試用例通常是在方法級別寫入并通過自動化執行。
集成測試檢查系統是否作為一個整體而。集成測試也由開發人員完成,但不是測試單個組件,而是旨在跨組件測試。系統由許多單獨的組件組成,如代碼,數據庫,Web服務器等。集成測試能夠發現如組件布線,網絡訪問,數據庫問題等問題。
功能測試通過將給定輸入的結果與規范進行比較來檢查每個功能是否正確實現。通常,這不是在開發人員級別的。功能測試由單獨的測試團隊執行。測試用例基于規范編寫,并且實際結果與預期結果進行比較。有若干工具可用于自動化的功能測試,如Selenium和QTP。
如前所述,單元測試可幫助開發人員確定代碼是否正常。在這篇博文中,我將提供在Java中單元測試的有用提示。
1.使用框架來用于單元測試
Java提供了若干用于單元測試的框架。TestNG和JUnit是最流行的測試框架。JUnit和TestNG的一些重要功能:
●易于設置和運行。
●支持注釋。
●允許忽略或分組并一起執行某些測試。
●支持參數化測試,即通過在運行時指定不同的值來運行單元測試。
●通過與構建工具,如Ant,Maven和Gradle集成來支持自動化的測試執行。
EasyMock是一個模擬框架,是單元測試框架,如JUnit和TestNG的補充。EasyMock本身不是一個完整的框架。它只是添加了創建模擬對象以便于測試的能力。例如,我們想要測試的一個方法可以調用從數據庫獲取數據的DAO類。在這種情況下,EasyMock可用于創建返回硬編碼數據的MockDAO。這使我們能夠輕松地測試我們意向的方法,而不必擔心數據庫訪問。
2.謹慎使用測試驅動開發!
測試驅動開發(TDD)是一個軟件開發過程,在這過程中,在開始任何編碼之前,我們基于需求來編寫測試。由于還沒有編碼,測試最初會失敗。然后寫入最小量的代碼以通過測試。然后重構代碼,直到被優化。
目標是編寫覆蓋所有需求的測試,而不是一開始就寫代碼,卻可能甚至都不能滿足需求。TDD是偉大的,因為它導致簡單的模塊化代碼,且易于維護。總體開發速度加快,容易發現缺陷。此外,單元測試被創建作為TDD方法的副產品。
然而,TDD可能不適合所有的情況。在設計復雜的項目中,專注于最簡單的設計以便于通過測試用例,而不提前思考可能會導致巨大的代碼更改。此外,TDD方法難以用于與遺留系統,GUI應用程序或與數據庫一起的應用程序交互的系統。另外,測試需要隨著代碼的改變而更新。
因此,在決定采用TDD方法之前,應考慮上述因素,并應根據項目的性質采取措施。
3.測量代碼覆蓋率
代碼覆蓋率衡量(以百分比表示)了在運行單元測試時執行的代碼量。通常,高覆蓋率的代碼含未檢測到的錯誤的幾率要低,因為其更多的源代碼在測試過程中被執行。測量代碼覆蓋率的一些做法括:
●使用代碼覆蓋工具,如Clover,Corbetura,JaCoCo或Sonar。使用工具可以提高測試質量,因為這些工具可以指出未經測試的代碼區域,讓你能夠開發開發額外的測試來覆蓋這些領域。
●每當寫入新功能時,立即寫新的測試覆蓋。
●確保有測試用例覆蓋代碼的所有分支,即if/else語句。高代碼覆蓋不能測試是完美的,所以要小心!
4.盡可能將測試數據外部化
在JUnit4之前,測試用例要運行的數據必須硬編碼到測試用例中。這導致了限制,為了使用不同的數據運行測試,測試用例代碼必須修改。但是,JUnit4以及TestNG支持外部化測試數據,以便可以針對不同的數據集運行測試用例,而無需更改源代碼。
5.使用斷言而不是Print語句
許多新手開發人員習慣于在每行代碼之后編寫System.out.println語句來驗證代碼是否正確執行。這種做法常常擴展到單元測試,從而導致測試代碼變得雜亂。除了混亂,這需要開發人員手動干預去驗證控制臺上打印的輸出,以檢查測試是否成功運行。更好的方法是使用自動指示測試結果的斷言。
6.構建具有確定性結果的測試
一些方法不具有確定性結果,即該方法的輸出不是預先知道的,并且每一次都可以改變。例如,考慮以下代碼,它有一個復雜的函數和一個計算執行復雜函數所需時間(以毫秒為單位)的方法:
7.除了正面情景外,還要測試負面情景和邊緣情況
通常,開發人員會花費大量的時間和精力編寫測試用例,以確保應用程序按預期。然而,測試負面測試用例也很重要。負面測試用例指的是測試系統是否可以處理無效數據的測試用例。例如,考慮一個簡單的函數,它能讀取長度為8的字母數字值,由用戶鍵入。除了字母數字值,應測試以下負面測試用例:
●用戶指定非字母數字值,如特殊字符。
●用戶指定空值。
●用戶指定大于或小于8個字符的值。