一種適用于osgi的檢測框架的制作方法
【專利摘要】本發明提供了一種適用于OSGI的檢測框架，該框架在OSGI環境中運行基本的Junit單元檢測，建立單獨的檢測模塊，把業務邏輯代碼和檢測代碼完全分離，為后續項目構建和集成提供前提便利條件，檢測運行環境收集所有檢測模塊里的檢測用例，以集合的形式，對所有的檢測用例進行匯總，方便檢測的整體運行。
【專利說明】—種適用于OSGI的檢測框架
【技術領域】
[0001]本發明涉及一種軟件構件化設備，具體涉及一種適用于OSGI的檢測框架。
【背景技術】
[0002]OSGI (Open Service Gateway Initiative)技術是面向 Java 的動態模型系統，OSGi的主要職責是讓開發者能夠構建動態化、模塊化的Java系統。使用OSGi后，應用的過程就像搭積木一樣搭建，例如，對于一個正在運行的系統，其中一個模塊要使用日志服務，但是目前的系統并沒有提供日志服務的模塊，此時可以直接從網上下載實現日志服務API的模塊，然后動態安裝此模塊，隨后其他要使用日志服務的模塊就可以使用了。
[0003]在OSGi環境里，針對業務邏輯模塊，編寫專門的檢測模塊，這樣可以做到檢測代碼和業務邏輯代碼完全分離。提供包含Junit檢測框架的檢測環境模塊收集各個檢測模塊的檢測用例，并且為檢測模塊提供Junit運行環境支持。
[0004]OSGi框架中每一個模塊都是一個Bundle，Bundle從形式上講是在META-1NF目錄下的MANIFEST.MF文件中加入了 OSGi特定描述的一個jar包。Bundle的生命周期被OSGi
框架管理。
[0005]目前業界廣泛應用的OSGi運行框架，被稱為Java語言的動態模塊系統。它為模塊化應用的開發定義了一個基礎架構，它使用Bundle的概念把復雜的應用程序模塊化。Bundle的生命周期由OSGi運行框架維護，并且Bundle之間是相互依賴的,這也決定了加載Bundle時的順序。在帶來松耦合互相依賴的同時，也產生了嚴格的訪問控制，只有少數的接口能夠被其他Bundle訪問到，傳統的單元檢測無法在OSGi環境里運行。在檢測中，經常需要對Bundle中非公開的包或方法進行檢測。并且檢測代碼如何與業務邏輯代碼分開也存在問題。
[0006]OSGi運行環境經常是由十幾個或者幾十個Bundle組成，如果針對每一個Bundle都寫好檢測代碼，那么單獨運行每一個檢測用例也很麻煩，需要手動去執行每一個TestCase0如何把所有的檢測用戶匯總在一個專門的檢測Bundle里面,能夠一次性運行所有的檢測，也是面臨的一個問題。
[0007]所以需要針對OSGi特點，提供一種單元檢測框架，該框架可以在OSGi環境中運行基本的Junit單元檢測，把業務邏輯代碼和檢測代碼完全分離，并且通過專門的檢測運行環境對所有的檢測用例進行匯總，方便檢測的整體運行。
【發明內容】
[0008]為了克服上述現有技術的不足，本發明提供一種適用于OSGI的檢測框架，該框架可以在OSGI環境中運行基本的Junit單元檢測。建立單獨的檢測模塊，把業務邏輯代碼和檢測代碼完全分離，為后續項目構建和集成提供前提便利條件。檢測運行環境收集所有檢測模塊里的檢測用例，以集合的形式，對所有的檢測用例進行匯總，方便檢測的整體運行。
[0009]為了實現上述發明目的，本發明采取如下技術方案:
[0010]一種適用于OSGI的檢測框架，其包括多個業務模塊、多個檢測模塊和檢測運行環境模塊。
[0011]本發明提供的優選技術方案中，編寫業務模塊的元數據描述配置文件，將業務模塊中需要進行檢測的接口以OSgi服務的方式對外導出。
[0012]本發明提供的第二優選技術方案中，所述檢測模塊分別引入OSgi服務，并編寫檢測用例。
[0013]本發明提供的第三優選技術方案中，所述檢測用例確保方法接收預期范圍內的輸入，為每一次檢測輸入返回預期的輸出。
[0014]本發明提供的第四優選技術方案中，每個檢測模塊中，都新建Junit檢測組件，運行所述檢測模塊里所有的檢測用例，每一個檢測組件都聲明一個Spring Bean。
[0015]本發明提供的第五優選技術方案中，在Spring配置文件里引入所述SpringBean，新建一個檢測集合組件，實例化檢測模塊中的檢測組件，遍歷和執行所有的檢測用例。
[0016]本發明提供的第六優選技術方案中，在寫檢測代碼的過程中，若會出現檢測業務模塊方法依賴的業務模塊沒有完成的情況，為了不影響本業務模塊的單元檢測和能夠和其他模塊隔離，使用Mock對象來模擬協同模塊預期的行為。
[0017]本發明提供的第七優選技術方案中，所述多個業務模塊之間具有獨立和依賴兩種關系。
[0018]本發明提供的第八優選技術方案中，所述檢測框架適用于OSGI環境與Maven持續集成環境結合在一起，進行持續集成檢測。
[0019]與最接近的現有技術比，本發明的有益效果:
[0020]本發明提供的技術方案使用EasyMock來模擬其他模塊的功能，在明確的知道其他模塊接受的指令和返回的結果的情況下，通過這個方式可以實現對模塊之間邏輯調用的檢測。由于這種方法并沒有實際調用其他模塊，所以待依賴模塊開發完成之后，可以使用加載依賴Bean的方式對依賴的模塊功能進行調用，實現模塊的單元檢測部分。
[0021]本發明提供的框架中結合Mock模擬的思想，可以將本模塊與其他依賴模塊完全分隔開，這樣檢測不受協同模塊開發進度的影響；另一方面通過與Mock對象協作，可以獲得一個孤立的檢測環境。
【專利附圖】
【附圖說明】
[0022]圖1是框架的整體架構設計圖
[0023]圖2是檢測方案的功能分布圖
【具體實施方式】
[0024]下面結合附圖對本發明作進一步詳細說明。
[0025]假設現在運行環境里包含兩個業務模塊:A和B，且A、B之間有依賴關系。檢測框架的具體設計如下:
[0026](I)、編輯兩個業務模塊的元數據描述配置文件，將兩個模塊中需要進行檢測的接口以osgi服務的方式對外導出。
[0027]通過注冊osgi服務，檢測模塊可以在OSGi容器里引用這些服務用來進行單元檢測。
[0028](2)、新建檢測模塊=TestA和TestB，分別引入上一步中的osgi服務，編寫檢測用例。
[0029]檢測用例確保方法接受預期范圍內的輸入，并且為每一次檢測輸入返回預期的輸出。
[0030](3)、在檢測模塊里，新建Junit檢測組件(Test Suite)，涵蓋檢測模塊里所有的檢測用例。
[0031]通過這樣的方式，為每一個模塊內的檢測用例提供一個整體對外接口，這樣可以通過調用這個接口一次性運行所有的檢測用例。每一個檢測組件都聲明成一個SpringBean0
[0032](4)、新建檢測環境模塊,在Spring配置文件里引入Spring Bean。新建一個檢測集合組件(Test Runner)，通過實例化其他檢測模塊的檢測組件Bean，可以遍歷和執行所有的檢測用例。
[0033]這里需要在OSGi環境里集成Spring環境，這樣才能正常定義和實例化Bean。在實例化Bean的過程中，可以使用Applicat1nContext通過ClassPathXmlApplicat1nContext讀取依賴的xml文件來實現。對于實例化過程中一些可以忽略的空指針問題，可以使用Mock來模擬預期行為。
[0034]通過類的名字和包名注冊Bean并發布為OSGi服務。在寫檢測代碼的過程中，可能會出現檢測方法依賴的模塊還沒有完成的情況，此時為了不影響本模塊的單元檢測，也為了能夠將本模塊與其他模塊隔離，可以使用Mock對象來模擬協同模塊預期的行為。這樣做一是可以將本模塊與其他依賴模塊完全分隔開，這樣檢測不受協同模塊開發進度的影響；另一方面通過與Mock對象協作，可以獲得一個孤立的檢測環境。此外，Mock對象還可以模擬在系統中不容易構造和比較復雜的對象，節省檢測時間。
[0035]如圖2所示，檢測框架的具體實施方案有如下步驟:
[0036](I)、在檢測模塊TestAuthorizat1n里定義好檢測的接口方法,檢測接口定義如下:
[0037]Public void testGetAuthorizat1nByld(String id)；
[0038]Authorizat1n定義用戶授權數據庫；
[0039]String id定義查詢數據庫的索引值；
[0040]上面的testGetAuthorizat1nByld接口用來檢測業務模塊對授權數據庫Authorizat1n的查詢過程。
[0041](2)、在檢測模塊里定義好檢測組件用來對外提供統一的檢測接口:
[0042]Public static Test suite (BundleContext be)；
[0043]BundleContext be是OSGi運行框架的容器環境；
[0044]Test返回檢測用例的匯總,通過定義JunitTestSuite類型的suite變量,添加檢測用例 suite.addTestSuite (TestAuthorizat1n.class)。
[0045](3)、檢測環境模塊整體運行檢測，TestRunner運行檢測的接口定義如下:
[0046]Public void runAllTests(Map<String, Test>testcases)；
[0047]參數Map〈String, TestHestcases用來收集所有從實例化Bean中獲取的檢測組件，其中String字段是檢測組件的類名，Test字段是對應的以注解OTest定義的Junit檢測方法。
[0048]獲取檢測用例集合的接口定義如下:
[0049]Public Map<String, Test>getTestCases()；
[0050]其中實例化Bean通過繼承自BeanFactory接口的Applicat1nContext,使用其實現類ClassPathXmlApplicat1nContext,從類路徑中尋找指定的XML配置文件,找到并裝載完成Applicat1nContext的實例化工作。
[0051]為了運行檢測用例，需要在本模塊里添加Junit運行環境。目的除了要為檢測用例提供Junit檢測框架的支持，還可以接受其他檢測模塊注冊的檢測用例，并且能夠運行這些檢測用例。
[0052]最后應當說明的是:以上實施例僅用以說明本發明的技術方案而非對其限制，盡管參照上述實施例對本發明進行了詳細的說明，所屬領域的普通技術人員依然可以對本發明的【具體實施方式】進行修改或者等同替換，這些未脫離本發明精神和范圍的任何修改或者等同替換，均在申請待批的本發明的權利要求保護范圍之內。
【權利要求】
1.一種適用于OSGI的檢測框架，其特征在于，所述框架包括業務模塊、檢測模塊和檢測運行環境模塊。
2.根據權利要求1所述檢測框架，其特征在于，編輯業務模塊的元數據描述配置文件，將業務模塊中需要進行檢測的接口以osgi服務的方式對外導出。
3.根據權利要求1所述檢測框架，其特征在于，將所述檢測模塊引入osgi服務，并在檢測模塊中編寫檢測用例。
4.根據權利要求3所述檢測框架，其特征在于，所述檢測用例確保方法接收預期范圍內的輸入，為每一次檢測輸入返回預期的輸出。
5.根據權利要求1所述檢測框架，其特征在于，每個檢測模塊中新建Junit檢測組件，運行所述檢測模塊里所有的檢測用例，每一個檢測組件都聲明一個Spring Bean。
6.根據權利要求5所述檢測框架，其特征在于，在Spring配置文件里引入所述SpringBean，新建一個檢測集合組件，實例化檢測模塊中的檢測組件，遍歷和執行所有的檢測用例。
7.根據權利要求1所述檢測框架，其特征在于，在寫檢測代碼的過程中，若會出現檢測業務模塊方法依賴的業務模塊沒有完成的情況，為了不影響本業務模塊的單元檢測和能夠和其他模塊隔離，使用Mock對象來模擬協同模塊預期的行為。
8.根據權利要求1所述檢測框架，其特征在于，所述業務模塊之間具有獨立和依賴兩種關系。
9.根據權利要求1所述檢測框架，其特征在于，所述檢測框架適用于OSGI環境與Maven持續集成環境結合在一起,進行持續集成檢測。
【文檔編號】G06F11/36GK104182346SQ201410438592
【公開日】2014年12月3日 申請日期:2014年8月29日 優先權日:2014年8月29日
【發明者】郝秋影, 郭鵬, 李守超 申請人:曙光信息產業(北京)有限公司