自動化單元測試實踐之路(3)

　　2.監控一些定時執行的任務

　　Jenkins將作為自動化單元測試持續集成的平臺,實現自動化構建。

　　圖-2-3-Jenkins平臺

　　代碼質量管理平臺：Sonar

　　Sonar (SonarQube)是一個開源平臺，用于管理源代碼的質量。Sonar 不只是一個質量數據報告工具，更是代碼質量管理平臺。支持的語言包括：Java、PHP、C#、C、Cobol、PL/SQL、Flex 等。

　　主要特點：

　　1.代碼覆蓋：通過單元測試，將會顯示哪行代碼被選中

　　2.改善編碼規則

　　3.搜尋編碼規則：按照名字，插件，激活級別和類別進行查詢

　　4.項目搜尋：按照項目的名字進行查詢

　　5.對比數據：比較同一張表中的任何測量的趨勢

　　Sonar將作為自動化單元測試反饋報告統一展現平臺，包括：

　　單元測試覆蓋率、成功率、代碼注釋、代碼復雜度等度量數據的展現。

　　圖-2-4 Sonar平臺

　　3 原則

　　自動化測試金字塔，也稱為自動化分層測試，Unit是整個金字塔的基石，最重要特點是運行速度非?？?第二個重要特點是UT應覆蓋代碼庫的大部分，能夠確定一旦UT通過后，應用程序就能正常工作。

　　Unit：70%，大部分自動化實現，用于驗證一個單獨函數或獨立功能模塊的代碼;

　　Service：20%，涉及兩個或兩個以上，甚至更多模塊之間交互的集成測試;

　　UI：10%，覆蓋三個或以上的功能模塊，真實用戶場景和數據的驗收測試;

　　這里僅僅列舉了每個層次的百分比，實際要根據團隊的方向來做調整。

　　自動化單元測試原則

　　提交代碼、運行測試的重點是什么?快速捕獲那些因修改向系統中引入的最常見錯誤，并通知開發人員，以便他們能快速修復他們。提交階段提供反饋的價值在于，對它的投入可以讓系統高效且更快地工作。

　　1、隔離UI操作

　　UI應當作為更高層次的測試Level，需要花費大量時間準備數據，業務邏輯復雜，過早進入UI階段，容易分散開發的單元測試精力。

　　2、隔離數據庫以及文件讀寫網絡開銷等操作

　　自動化測試中如果需要將結果寫入數據庫，然后再驗證改結果是否被正確寫入，這種驗證方法簡單、容易理解，但是它不是一個高效的方法。這個應當從集成測試的Level去解決。

　　首先：與數據庫的交互，是漫長的，甚至有可能要投入維護數據庫的時間，那將成為快速測試的一個障礙，開發人員不能得到及時有效的反饋。假設，我需要花費一個小時，才能驗證完畢與數據庫交互的結果，這種等待是多么漫長呀。

　　其次，數據管理需要成本，從數據的篩選(線上數據可能是T級)到測試環境的M級別，如何把篩選合適的大小，這都使得管理成本增加(當然在集成測試中可以使用DBUnit來解決部分問題)。

　　最后，如果一定要有讀寫操作才能完成的測試，也要反思代碼的可測試性做的如何?是否需要重構。

　　單元測試決不要依賴于數據庫以及文件系統、網絡開銷等一切外部依賴。

　　3、使用Mock替身與Spring容器隔離

　　如果在單元測試中，還需要啟動Spring容器進行依賴注入、加載依賴的WebService等，這個過程是相當消耗時間的。

　　可以使用模擬工具集：Mockito、EasyMock、JMock等來解決，研發團隊主要是基于Mockito的實踐。與需要組裝所有的依賴和狀態相比，使用模擬技術的測試運行起來通常是非?？?，這樣子開發人員在提交代碼之后，可以在持續集成平臺快速得到反饋。

　　4、設計簡單的測試

　　明確定義方法：

　　成功：public void testSendReportLongDateSuccess()

　　失?。簆ublic void testSendReportLongDateFail()，可以包括異常

　　和單一的斷言，避免在一個方法內使用多個復雜斷言，這會造成代碼結構的復雜，使得測試的復雜性提高。

　　5、定義測試套件的運行時間

　　使用Mock構建的單元測試，每個方法的構建時間應該是毫秒級別，整個類是秒級別，理想的是整體構建時間控制在5分鐘以內，如果超過怎么辦呢?

　　首先，拆分成多個套件，在多臺機器上并行執行這些套件;

原文轉自：http://www.uml.org.cn/Test/201407281.asp