本申請涉及測試技術領域，尤其涉及一種java注解測試方法及裝置。

背景技術：

annotation(注解)是jdk1.5及以后版本引入的一種特性。與類、接口、枚舉屬于同一層次。它可以聲明在包、類、字段、方法、局部變量、方法參數等的前面，用來對這些元素進行說明和注釋。注解是以‘@注解名’的形式存在于在代碼中，注解不會直接影響到程序的語義，但是可以用于實現創建文檔、跟蹤代碼中的依賴性、甚至執行基本編譯的檢查等功能。

除了java自帶的基本內置注解，開發人員經常使用的是自定義注解，用來標識當前接口或者方法具有的特定屬性，或者在調用方法前通過自定義的注解內容作一些基本判斷進而判決調用方法后的邏輯分支。也就是說，作為整體java代碼的一部分，接口或方法注解的正確性也會影響整個代碼功能的實現。因此在測試階段，如果在目標代碼中對接口或方法定義了注解，則除了需要對常規的接口或方法實現代碼進行測試之外，也有必要對接口或方法的注解進行測試。

現有對于接口或方法注解的測試主要有兩種方式：一種是通過人工白盒測試來確認注解是否標注正確；另一種是通過單元或組件測試來驗證注解的邏輯是否正確。兩種方式都存在不具備重復可用性、效率低下的問題。此外，單元測試盡管能在一定程度上實現自動化，但是卻存在應用場景受限的問題。

技術實現要素：

針對上述技術問題，本申請提供一種java注解測試方法及裝置，技術方案 如下：

一種java注解測試方法，用于對被測目標的注解進行測試，所述被測目標包括java方法或java接口，該測試方法包括：

接收測試入口參數，所述測試入口參數包括：被測目標的標識信息及測試期望信息；

根據被測目標的標識信息，利用java反射機制，獲取所述被測目標的注解；

利用java攔截器機制，執行所獲取到的注解邏輯；

根據所述測試期望信息得到測試結果。

一種java注解測試裝置，用于對被測目標的注解進行測試，所述被測目標包括java方法或java接口，該測試裝置包括：

入口參數接收模塊，用于接收測試入口參數，所述測試入口參數包括：被測目標的標識信息及測試期望信息；

注解獲取模塊，用于根據被測目標的標識信息，利用java反射機制，獲取所述被測目標的注解；

注解邏輯執行模塊，用于利用java攔截器機制，執行所獲取到的注解邏輯；

測試結果輸出模塊，用于根據所述測試期望信息得到測試結果。

本申請所提供的技術方案，利用java的攔截器機制和反射機制實現對java注解的測試，與現有技術相比，本申請方案只需一個通用的測試模板，通過修改少量的測試入口參數，就可以實現對各類接口或方法注解的自動測試，而且測試的內容可以同時涵蓋對注解自身邏輯正確性的校驗以及對方法或接口是否使用了正確注解的校驗，從而有效地提升了測試效率，并且降低測試所需的時間人力成本。

應當理解的是，以上的一般描述和后文的細節描述僅是示例性和解釋性的，并不能限制本申請。此外，本申請中的任一實施例并不需要達到上述的全部效果。

附圖說明

為了更清楚地說明本申請實施例或現有技術中的技術方案，下面將對實施例或現有技術描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本申請中記載的一些實施例，對于本領域普通技術人員來講，還可以根據這些附圖獲得其他的附圖。

圖1是本申請的java注解測試方法的第一種流程示意圖；

圖2是本申請的java注解測試方法的第二種流程示意圖；

圖3是本申請的java注解測試裝置的第一種結構示意圖；

圖4是本申請的java注解測試裝置的第二種結構示意圖。

具體實施方式

下面將結合本申請實施例中的附圖，對本申請實施例中的技術方案進行詳細地描述，顯然，所描述的實施例僅僅是本申請一部分實施例，而不是全部的實施例。基于本申請中的實施例，本領域普通技術人員所獲得的所有其他實施例，都應當屬于本申請保護的范圍。

為了方便理解本申請方案，首先介紹兩個注解在java接口或方法中的應用實例。

應用實例1：

軟件在接口或方法調用設計中都會去打印各種日志內容以輔助相關人員排查問題或者監控運行情況，而不同的接口或方法調用內容需要打印在不同的日志中，這種情況下，可以通過在接口或方法中添加注解的方式決定當前接口或方法被調用時需要打印信息到哪個日志中。舉例如下：

@logannotation(name＝"test.log")

publicstaticvoidsaying(){

}

上述代碼中，“@logannotation(name＝"test.log")”為注解內容，該注解實現 的功能是：告知系統當本方法(saying)被調用時，需要打印信息到test.log日志文件中，而這個注解的正確性直接決定了能否將正確的信息打印到正確的日志中，也進一步決定和影響了后續系統問題排查和運行監控的正確性。

應用實例2：

@zone(zonecal＝"com.google.map.calculate”)

publicstaticvoidshowinfo(){

}

上述代碼中，“@zone(zonecal＝"com.google.map.calculate”)”為注解內容，該注解實現的功能是：在執行給用戶展示信息的方法(showinfo)前，通過googlemap的計算功能得到調用當前方法時的位置信息，進而在方法內部可以根據這個位置信息提供個性化的信息。但如果這里注解對應的類方法執行邏輯有問題，后續就可能提供給用戶錯誤的信息，從而影響用戶體驗。

針對接口或方法注解，現有的一種測試方式是通過人工的方式對注解代碼閱讀判斷，以確定注解的內容是否正確。這種方式不具備自動化執行性及重復執行性，實際測試效率非常低下，而且需要消耗大量的時間及人力成本。

當注解內容對應的是一個邏輯類時，可以通過單元測試或者組件測試方式自動校驗這個類的處理邏輯是否正確，但是針對不同的注解，仍然需要單獨編寫單元測試腳本和準備對應的測試數據。另外這種方式的局限性在于：只能校驗每個注解自身的邏輯正確性，無法保證對應的接口或方法添加的注解是正確的目標注解。例如，單元測試可以分別校驗注解a和注解b的邏輯正確性，如果當前方法需要添加的是注解a，而實際編碼時添加的是注解b，這種錯誤是單元測試無法發現的。事實上，對于目標接口或方法中實際是否使用了正確的注解邏輯類，仍然需要通過人工白盒測試來確認。

針對以上問題，本申請提供一種java注解測試方法，用于對java方法或java接口進行測試，參見圖1所示，該方法可以包括以下步驟：

s101，接收測試入口參數，所述測試入口參數包括：被測目標的標識信息及測試期望信息；

s102，根據被測目標的標識信息，利用java反射機制，獲取所述被測目標的注解；

s103，利用java攔截器機制，執行所獲取到的注解邏輯；

s104，根據測試期望信息得到測試結果。

本申請方案使用到了java自身的兩種機制：攔截器機制和反射機制。

java中的攔截器用于動態攔截action調用的對象，它提供了一種機制，令開發者可以定義一段代碼，該代碼可以在一個action執行前或執行后實現一些特定的功能，也可以在一個action執行前阻止其執行。此外，java攔截器也提供了一種可以提取action中可重用部分的方式。

java反射機制是指：在運行狀態中，對于任意一個類，都能夠知道這個類的所有屬性和方法；對于任意一個對象，都能夠調用它的任意一個方法；這種動態獲取的信息以及動態調用對象的方法的功能稱為java的反射機制。

為了實現對不同接口或方法注解的通用性測試，本申請方案通過java攔截器機制，設置對被測目標進行攔截，(這里的被測目標可以是帶有注解的java方法或java接口)，以便在被測目標執行之前，先執行該被測目標的注解邏輯。其中被測目標的注解可以通過java反射機制獲取。

可見，對于整個測試系統而言，只需要兩類輸入參數：被測目標的標識以及測試期望信息。其中被測目標的標識用于告知測試系統：需要對哪個接口或方法的注解進行測試；測試期望信息則用于系統進行比對校驗，從而得到最終的測試結果。也就是說，針對不同的接口或方法，測試人員只需給將該接口或方法的名稱、以及對該方法或接口注解的期望測試信息作為入口參數提供給測試系統，后續系統就能夠完成對注解的測試工作。與現有的測試方案相比，不僅實現了自動化測試，而且可以在不同的方法或接口上復用同一套測試邏輯，有效地改善了總體的測試效率。

本申請方案的另一個優勢在于：既可以實現對注解自身邏輯正確性的校驗，也可以實現對方法或接口是否使用了正確注解的校驗。圖2示出了本申請java注解測試方法的另一種流程圖，與圖1相比，該流程具體劃分出兩個測試分支： 其中s104a用于對注解自身邏輯正確性進行校驗，s104b則用于對方法或接口是否使用了正確注解進行校驗。

具體而言，在s101接收的測試入口參數中，“測試期望信息”可以包括兩種：

1)期望注解邏輯值，也即在正確情況下，給定被測目標的注解邏輯執行后，應該得到正確的結果。

假設給定的被測目標為方法a，該方法a的注解邏輯執行后，應該得到的正確結果為x，則在s101將“方法a”和值x作為測試入口參數，提供給測試系統；

在s102，測試系統根據“方法a”利用反射機制獲取方法a當前實際使用的注解；

在s103，系統利用攔截器機制執行當前測試實際獲取到的注解邏輯并且得到執行結果，假設該值為x’。

需要說明的是，由于這里的測試需求僅包括對方法注解的測試，因此可以進一步利用攔截機制阻止被測目標(在本例中為方法a)的執行。

進而在s104a，通過判斷注解邏輯的執行結果x’和期望注解邏輯值x是否匹配，就可以確定被測目標方法a的注解執行邏輯是否正確。

2)期望注解信息，也即在正確情況下，應該對給定被測目標添加什么注解。

假設給定的被測目標為方法a，該方法a應該添加的注解為注解a。則在s101中，將“方法a”和“注解a”作為測試入口參數，提供給測試系統；

在s102，測試系統根據“方法a”利用反射機制獲取方法a當前實際使用的注解，假設獲取的到的結果為“注解a’”；

進而在s104b，通過判斷所獲取到的注解(注解a’)與期望注解信息(注解a)是否匹配，就可以確定被測目標方法a是否使用了正確的注解。

當然，根據實際的測試需求，s104a和s104b兩個測試分支既可以分別獨立執行，也可以全部執行，本申請對此不做限定。

另外，在實際的測試需求中，有時可能僅希望對一些特定的注解進行測試， 或者對于包含多個注解的方法或接口，僅希望對其中的部分注解進行測試。基于這中需求，可以設置注解過濾規則，用于定義哪些注解存在/不存在測試需求。進而，在s102獲取被測目標的注解后，可以根據注解過濾規則對所獲取到的注解進行過濾，僅保留具有測試需求的注解進行后續的測試項目(包括s103-s104a分支以及s104b分支)。其中，注解過濾規則可以以相對靜態的方式預先配置在系統中，這種方式比較適用于對多個被測目標具有統一注解過濾的場景；此外，也可以將注解過濾規則以測試入口參數的形式提供給測試系統，以便于測試人員靈活配置測試需求；當然在實際應用中，上述兩種方式也可以同時采用，即兩種方式配置的規則可以同時生效。如有需要，可以進一步配置相應的優先級原則，以應付靜態配置規則和動態配置的規則發生沖突的情形。

在本申請方案的另一個應用實例中，可以直接將上述注解測試的功能直接集成在對普通接口或方法的測試工具中，作為對一般接口或方法的測試工具的功能完善。

例如，對于如下方法：

@zone(zonecal＝"com.google.map.calculate”)

publicstaticvoidshowinfo(){

}

普通的方法測試腳本中，只會對showinfo方法的邏輯進行校驗，但是不會對注解信息做任何校驗處理。應用本申請方案，只需在原測試腳本中添加注解校驗點，即可實現對注解本身邏輯正確性和/或目標方法被添加注解正確性的校驗。由于攔截器機制具有阻止被測目標執行的功能，因此也可以實現對注解的測試過程和對方法的測試過程不發生重復或沖突。

相應于上述方法實施例，本申請還提供一種java注解測試裝置，該裝置用于對被測目標的注解進行測試，被測目標可以是java方法或java接口，參見圖3所示，該裝置可以包括：

入口參數接收模塊110，用于接收測試入口參數，測試入口參數可以包括：被測目標的標識信息及測試期望信息；

注解獲取模塊120，用于根據被測目標的標識信息，利用java反射機制，獲取被測目標的注解；

注解邏輯執行模塊130，用于利用java攔截器機制，執行所獲取到的注解邏輯；優選地，該裝置還可以用于被測目標的執行。

測試結果輸出模塊140，用于根據測試期望信息得到測試結果。

在本申請的一種具體實施方式中，測試期望信息可以包括：期望注解邏輯值；

相應地，測試結果輸出模塊140可以具體用于：判斷注解邏輯的執行結果與期望注解邏輯值是否匹配，以確定被測目標的注解執行邏輯是否正確。

在本申請的一種具體實施方式中，測試期望信息可以包括：期望注解信息；

相應地，測試結果輸出模塊140可以具體用于：判斷所獲取到的注解與期望注解信息是否匹配，以確定被測目標是否使用了正確的注解。

參見圖4所示，本申請所提供的java注解測試裝置還可以包括：

注解過濾模塊150，用于在注解獲取模塊120獲取被測目標的注解后，根據注解過濾規則，對所獲取到的注解進行過濾，該注解過濾規則用于定義注解是否存在測試需求。具體可以是預先配置的注解過濾規則，也可以是入口參數接收模塊110以測試入口參數形式接收的注解過濾規則(規則傳輸如圖4虛線所示)。

通過以上的實施方式的描述可知，本領域的技術人員可以清楚地了解到本申請可借助軟件加必需的通用硬件平臺的方式來實現。基于這樣的理解，本申請的技術方案本質上或者說對現有技術做出貢獻的部分可以以軟件產品的形式體現出來，該計算機軟件產品可以存儲在存儲介質中，如rom/ram、磁碟、光盤等，包括若干指令用以使得一臺計算機設備(可以是個人計算機，服務器，或者網絡設備等)執行本申請各個實施例或者實施例的某些部分所述的方法。

本說明書中的各個實施例均采用遞進的方式描述，各個實施例之間相同相似的部分互相參見即可，每個實施例重點說明的都是與其他實施例的不同之處。尤其，對于裝置實施例而言，由于其基本相似于方法實施例，所以描述得比較 簡單，相關之處參見方法實施例的部分說明即可。以上所描述的裝置實施例僅僅是示意性的，其中所述作為分離部件說明的模塊可以是或者也可以不是物理上分開的，在實施本申請方案時可以把各模塊的功能在同一個或多個軟件和/或硬件中實現。也可以根據實際的需要選擇其中的部分或者全部模塊來實現本實施例方案的目的。本領域普通技術人員在不付出創造性勞動的情況下，即可以理解并實施。

以上所述僅是本申請的具體實施方式，應當指出，對于本技術領域的普通技術人員來說，在不脫離本申請原理的前提下，還可以做出若干改進和潤飾，這些改進和潤飾也應視為本申請的保護范圍。