本發(fā)明涉及計算機領域，尤其涉及一種獲取測試用例的方法以及服務器。

背景技術：

目前對于精準測試、精準回歸，測試人員完成測試用例的制作后，這些用例是需要被管理、維護起來。在常規(guī)的用例管理、維護方式下，如果用例的數(shù)量比較少，這些用例管理、維護起來也會很輕松，其管理、維護的成本是較低的；如果用例的數(shù)量龐大到以百、千數(shù)量級的時候，對于每次版本迭代、更新，測試人員在這些用例的維護上將花費巨大的時間和精力。

在現(xiàn)有技術中，測試人員在做回歸測試的時候，為了減少工作量，沒有執(zhí)行所有的測試用例，只需要執(zhí)行被涉及的測試用例那部分。而被涉及的測試用例在具體不同版本的變更總是不同的，取決于開發(fā)人員對版本的更新情況，當前方式是測試人員在測試的過程中采用手動評估的方式，即需要測試人員手動的篩選出哪些測試用例是本次版本更新涉及到的，這樣的方式是比較低效率的，同時因為手動評估所建立的對應關系的不完整、錯誤等一系列的問題。

技術實現(xiàn)要素：

本發(fā)明實施例提供了一種獲取測試用例的方法，使得服務器通過函數(shù)調用關系信息與所述目標函數(shù)確定得到的目標測試用例，和人為進行評估相比較，有效的提高了處理效率和準確率。

本發(fā)明第一方面提供一種獲取測試用例的方法，可以包括：

獲取被測對象的函數(shù)調用關系信息；

獲取目標函數(shù)，該目標函數(shù)為根據(jù)該被測對象的被測版本源碼和歷史版本源碼的差異信息確定的相關函數(shù)，該被測版本源碼是該歷史版本源碼經(jīng)過處理得到的；

根據(jù)該函數(shù)調用關系信息確定與該目標函數(shù)對應的目標測試用例。

本發(fā)明實施例第二方面提供一種服務器，可以包括：

第一獲取模塊，用于獲取被測對象的函數(shù)調用關系信息；

第二獲取模塊，用于獲取目標函數(shù)，該目標函數(shù)為根據(jù)該被測對象的被測版本源碼和歷史版本源碼的差異信息確定的相關函數(shù)，該被測版本源碼是該歷史版本源碼經(jīng)過處理得到的；

確定模塊，用于根據(jù)該函數(shù)調用關系信息確定與該目標函數(shù)對應的目標測試用例。

從以上技術方案可以看出，本發(fā)明實施例具有以下優(yōu)點：

在本發(fā)明實施例中，獲取被測對象的函數(shù)調用關系信息；獲取目標函數(shù)，該目標函數(shù)為根據(jù)該被測對象的被測版本源碼和歷史版本源碼的差異信息確定的相關函數(shù)，該被測版本源碼是該歷史版本源碼經(jīng)過處理得到的；根據(jù)該函數(shù)調用關系信息確定與該目標函數(shù)對應的目標測試用例。因為目標測試用例是服務器通過函數(shù)調用關系信息與該目標函數(shù)確定得到的，和人為進行評估相比較，有效的提高了處理效率和準確率。

附圖說明

為了更清楚地說明本發(fā)明實施例技術方案，下面將對實施例和現(xiàn)有技術描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的一些實施例，還可以根據(jù)這些附圖獲得其它的附圖。

圖1為本發(fā)明實施例中用例測試系統(tǒng)的一個實施例示意圖；

圖2為本發(fā)明實施例中用例測試系統(tǒng)的另一個實施例示意圖；

圖3為本發(fā)明實施例中獲取測試用例的方法的一個實施例示意圖；

圖4為本發(fā)明實施例中用例測試系統(tǒng)的另一個實施例示意圖；

圖5為本發(fā)明實施例中服務器的一個實施例示意圖；

圖6為本發(fā)明實施例中服務器的另一個實施例示意圖；

圖7為本發(fā)明實施例中服務器的另一個實施例示意圖；

圖8為本發(fā)明實施例中服務器的另一個實施例示意圖。

具體實施方式

本發(fā)明實施例提供了一種獲取測試用例的方法，使得服務器通過函數(shù)調用關系信息與所述目標函數(shù)確定得到的目標測試用例，和人為進行評估相比較，有效的提高了處理效率和準確率。

為了使本技術領域的人員更好地理解本發(fā)明方案，下面將結合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本發(fā)明一部分的實施例，而不是全部的實施例?；诒景l(fā)明中的實施例，都應當屬于本發(fā)明保護的范圍。

本發(fā)明實施例可以應用于用例測試系統(tǒng)，如圖1所示，用例測試系統(tǒng)可以包括：函數(shù)調用關系樹分析功能模塊、用例差異分析功能模塊和函數(shù)差異分析功能模塊。具體的，如圖2所示，函數(shù)調用關系樹分析功能模塊又可以包括被測對象分析模塊、函數(shù)調用關系模塊和數(shù)據(jù)寫入模塊，用例差異分析功能模塊可以包括接口列表獲取模塊和數(shù)據(jù)存儲模塊，函數(shù)差異分析功能模塊可以包括SVN(Subversion，開放源代碼的版本控制系統(tǒng))Diff模塊和獲取差異函數(shù)模塊。即可以通過用例的收集管理、函數(shù)調用關系信息的獲取、SVN Diff等結合起來，根據(jù)這些信息獲取代碼變更(版本變更)所涉及的用例。

在本發(fā)明實施例中，上述的各個模塊的功能簡要的說明如下所示：

被測對象分析模塊：對可執(zhí)行文件或庫文件進行反匯編處理，獲取被測對象的各函數(shù)的信息。

函數(shù)調用關系模塊：對“被測對象分析模塊”所獲取的各函數(shù)的信息進行解析，獲取各函數(shù)間的調用關系。

數(shù)據(jù)寫入模塊：將獲取到的被測系統(tǒng)或模塊的各函數(shù)調用關系信息寫入到數(shù)據(jù)庫中。

SVN Diff模塊：調用SVN Diff命令，從SVN獲取兩個版本間代碼的差異信息。

獲取差異函數(shù)模塊：通過SVN Diff所獲取的差異化信息，獲取發(fā)生變化的代碼所屬的函數(shù)。

接口列表獲取模塊：根據(jù)數(shù)據(jù)庫中的各函數(shù)調用關系信息，找到與該函數(shù)具有直系關系的接口函數(shù)名列表，根據(jù)這些接口的函數(shù)名或者接口名所對應的命令字確定該接口所涉及的測試用例，并返回這些測試用例的列表。

下面對本發(fā)明實施例中所涉及的縮略語和關鍵術語的定義做一個簡單的說明，如下所示：

(1)精準測試：精準測試指通過某種方式確定某個特性或某個特性的變更所影響的測試范圍或涉及的測試用例。

(2)函數(shù)調用關系樹：以樹的形式將系統(tǒng)或模塊中函數(shù)間的調用與被調用關系保存起來。

(3)接口測試：接口測試是對被測系統(tǒng)或模塊的組件間的接口所進行的一種測試。針對互聯(lián)網(wǎng)領域，接口測試基本上是針對于協(xié)議的接口測試。

(4)Use Case(用例)是一個UML(Unified Modeling Language，統(tǒng)一建模語言或標準建模語言)中非常重要的概念，在使用UML的整個軟件開發(fā)過程中，Use Case處于一個中心地位。用例是對一組動作序列的抽象描述，系統(tǒng)執(zhí)行這些動作序列，產(chǎn)生相應的結果。這些結果要么反饋給參與者，要么作為其他用例的參數(shù)。

(5)回歸測試：是指修改了舊代碼后，重新進行測試以確認修改沒有引入新的錯誤或導致其他代碼產(chǎn)生錯誤。自動回歸測試將大幅降低系統(tǒng)測試、維護升級等階段的成本?；貧w測試作為軟件生命周期的一個組成部分，在整個軟件測試過程中占有很大的工作量比重，軟件開發(fā)的各個階段都會進行多次回歸測試。在漸進和快速迭代開發(fā)中，新版本的連續(xù)發(fā)布使回歸測試進行的更加頻繁，而在極端編程方法中，更是要求每天都進行若干次回歸測試。因此，通過選擇正確的回歸測試策略來改進回歸測試的效率和有效性是很有意義的。

(6)Makefile：一個工程中的源文件不計其數(shù)，其按類型、功能、模塊分別放在若干個目錄中，makefile定義了一系列的規(guī)則來指定，哪些文件需要先編譯，哪些文件需要后編譯，哪些文件需要重新編譯，甚至于進行更復雜的功能操作，因為makefile就像一個Shell腳本一樣，其中也可以執(zhí)行操作系統(tǒng)的命令。

下面以實施例的方式對本發(fā)明技術方案做進一步的說明，如圖3所示，為本發(fā)明實施例中獲取測試用例的方法的一個實施例示意圖，包括：

301、獲取被測對象的函數(shù)調用關系信息；

在本發(fā)明實施例中，執(zhí)行主體可以為服務器，服務器獲取被測對象的函數(shù)調用關系信息，將函數(shù)調用關系信息保存在數(shù)據(jù)庫中。

其中，服務器獲取被測對象的函數(shù)調用關系信息，具體可以包括：服務器獲取被測對象的可執(zhí)行文件或者庫文件；服務器根據(jù)可執(zhí)行文件或者庫文件獲取函數(shù)調用關系信息，進一步的，可以為服務器對可執(zhí)行文件或者庫文件進行反匯編處理，確定與被測對象相關的函數(shù)信息；服務器對與被測對象相關的函數(shù)信息進行解析，得到函數(shù)調用關系信息。

在現(xiàn)有技術中，目前對于精準測試、精準回歸所采用的方式一般采用如下的兩種方式獲取被測對象的函數(shù)調用樹。一種方式是在Makefile中添加相應的編譯選項，然后執(zhí)行編譯生成的可執(zhí)行文件或庫文件，然后通過對執(zhí)行中所生成的信息文件的解析獲取函數(shù)的調用關系信息，從而生成函數(shù)的調用關系樹。另外的一種方式是通過對源代碼的分析，獲取函數(shù)的之間的調用關系，最后總結、歸納成函數(shù)調用關系樹。

而在本發(fā)明實施例中，只需要獲取被測對象的可執(zhí)行文件或者庫文件，進行反匯編處理，可以得到與被測對象相關的函數(shù)信息；服務器對與被測對象相關的函數(shù)信息進行解析，獲取函數(shù)調用關系信息。這樣就不需要測試人員在整個過程中的參與，很好的提高了效率，并減少了認為操作所導致的錯誤。

應理解，這里的被測對象可以是地圖、QQ、微信、大眾點評、微博、天氣、郵箱、銀行等應用程序。

示例性的，對于一個C語言編寫的項目，它的框架可以反應為一棵函數(shù)調用樹。如果在分析項目之前，能夠得到這樣一顆調用樹，那么就可以了解項目的整體框架；如果在項目運行之后，能夠跟蹤到該次運行過程中的函數(shù)調用，那么將有利于分析某些測試條件下項目的執(zhí)行流程；而如果在項目運行過程中(比如調試項目時)能夠跟蹤出某個位置之前的函數(shù)調用，那么將有利于確定潛在bug可能存在的位置。

對于這三種情況，雖然沒有任何一個工具能夠完全滿足，不過還是有一些不同的工具可以實現(xiàn)：無須運行項目本身，calltree就能夠根據(jù)整個項目的源代碼產(chǎn)生一棵函數(shù)調用樹，并可把該調用樹導出為dot格式的圖形。因此可以說calltree能夠在不運行項目的條件下對項目進行函數(shù)級別的分析。

gprof則能夠在項目運行之后，把該次運行過程中的函數(shù)調用以文本的形式反應出來，于是kprof產(chǎn)生了，它不僅可以輔助gprof更好的分析程序代碼級別的運行情況，而且能夠導出當前執(zhí)行過程中的函數(shù)調用樹，并同樣可以把調用樹導出為dot格式的圖形。

gdb(Gnu DeBugger)，它是一個調試工具。它提供專門的backtrace命令來跟蹤程序執(zhí)行到某個位置(比如指定的斷點處)之前的函數(shù)調用，不過這個目前還是文本輸出的。

302、獲取目標函數(shù)，目標函數(shù)為根據(jù)被測對象的被測版本源碼和歷史版本源碼的差異信息確定的相關函數(shù)，被測版本源碼是歷史版本源碼經(jīng)過處理得到的；

在本發(fā)明實施例中，服務器獲取目標函數(shù)，目標函數(shù)為根據(jù)被測對象的被測版本源碼和歷史版本源碼的差異信息確定的相關函數(shù)，被測版本源碼是歷史版本源碼經(jīng)過處理得到的。

其中，獲取目標函數(shù)，具體可以包括：服務器調用版本控制指令；服務器將版本控制指令向版本控制系統(tǒng)SVN服務器發(fā)送，版本控制指令用于SVN服務器確定被測對象的被測版本源碼與歷史版本源碼的差異信息；服務器接收SVN服務器發(fā)送的差異信息；服務器根據(jù)差異信息確定目標函數(shù)。

示例性的，假設被測對象為微信，微信被測版本為6.5.3，歷史版本為6.5.2，其中，被測版本6.5.3是在歷史版本6.5.2的基礎上升級的；或者，歷史版本為6.5.0，被測版本6.5.3是在歷史版本6.5.0的基礎上升級的。版本控制指令可以為SVN Diff命令，服務器調用SVN Diff命令，即將SVN Diff命令向SVN服務器發(fā)送；SVN服務器根據(jù)SVN Diff命令，確定微信的被測版本6.5.3的源碼和歷史版本6.5.2的源碼的差異信息；SVN服務器再將該差異信息向服務器發(fā)送，服務器接收該差異信息之后，可以根據(jù)該差異信息確定目標函數(shù)。

服務器使用到SVN的命令，有export、diff等，對于diff命令，diff的結果會保存在一個文本文件中，如下面的例子所示：

第一行“Index：test/CategoryLogAo.java”表示的是存在差異的文件。

第二行是分隔符；

第三行老版本的文件名及其版本號，有“---”前綴；

第四行新版本的文件名及其版本號，有“+++”前綴；

第五行舊版本從42行可似乎后的6行和新版本從42行開始后的18行不一樣。此行有開始和結束都有@@；

后面表示的是版本間的具體差異的情況，如果行前有“+”表示新版本對于老版本而言有增加；如果行前“-”表示新版本對于老版本而言有減少。

需要說明的是，步驟301與302的時序不做限定，可以是先獲取被測對象的函數(shù)調用關系信息，再獲取目標函數(shù)；也可以是先獲取目標函數(shù)，再獲取被測對象的函數(shù)調用關系信息；還可以同時獲取被測對象的函數(shù)調用關系信息和目標函數(shù)。

303、根據(jù)函數(shù)調用關系信息確定與目標函數(shù)對應的目標測試用例；

在本發(fā)明實施例中，服務器獲取被測對象的函數(shù)調用關系信息以及目標函數(shù)之后，根據(jù)函數(shù)調用關系信息確定與目標函數(shù)對應的目標測試用例。具體可以包括：服務器根據(jù)函數(shù)調用關系信息，確定與目標函數(shù)對應的接口函數(shù)名列表；服務器根據(jù)接口函數(shù)名列表或者接口函數(shù)名列表中的接口函數(shù)名對應的命令字確定目標測試用例。需要說明的是，這里的目標測試用例是由于版本迭代更新而受到影響的測試用例。

應理解，對于用例與代碼差異結果的結合來確定變更所涉及的用例，當前的方式需要測試人員在測試的過程中建立這樣的對應關系，這樣的方式是比較低效率的，同時會帶來所建立的關系的不完整、錯誤等一系列的問題。本發(fā)明中采用接口的接口命令字作為接口與測試用例間的橋梁，對一個業(yè)務而言，命令字是唯一的，這樣就精確的建立了測試用例與函數(shù)接口間的對應關系。

304、以列表形式展示目標測試用例；

在本發(fā)明實施例中，服務器根據(jù)函數(shù)調用關系信息確定與目標函數(shù)對應的目標測試用例之后，可以以列表形式展示目標測試用例。

示例性的，服務器根據(jù)函數(shù)調用關系信息確定與目標函數(shù)對應的目標測試用例如下表1所示：

表1

305、根據(jù)目標測試用例對被測對象進行測試。

在本發(fā)明實施例中，服務器以列表形式展示目標測試用例，再根據(jù)目標測試用例對被測對象進行測試。即測試人員需要先對這些目標測試用例進行修改，根據(jù)修改后的目標測試用例對被測對象進行測試。

示例性的，服務器根據(jù)上述表1所示的目標測試用例對被測對象進行測試，這個過程通常稱呼精準測試，精準測試模塊能夠幫助用戶確定被測對象的版本迭代更新所涉及的測試用例，這樣用戶就可以直接運行所涉及的測試用例來完成版本的測試，而不用執(zhí)行全部的用例，測試效率得到提升。該功能的整個處理流程圖4所示，整個過程由程序來處理，用戶所需要處理的只是提供被測對象，執(zhí)行腳本命令，查看結果信息。

需要說明的是，步驟304和步驟305是可選的步驟，在實際應用中，根據(jù)實際需要確定是否執(zhí)行。

在本發(fā)明實施例中，服務器獲取被測對象的函數(shù)調用關系信息；服務器獲取目標函數(shù)，目標函數(shù)為根據(jù)被測對象的被測版本源碼和歷史版本源碼的差異信息確定的相關函數(shù)，被測版本源碼是歷史版本源碼經(jīng)過處理得到的；服務器根據(jù)函數(shù)調用關系信息確定與目標函數(shù)對應的目標測試用例。因為目標測試用例是服務器通過函數(shù)調用關系信息與目標函數(shù)確定得到的，和人為進行評估相比較，有效的提高了處理效率和準確率。

使用簡單：本發(fā)明在使用時不需要測試人員干預，對測試人員其所需要提供的僅僅是提供被測對象的可執(zhí)行文件或庫文件，以及代碼的svn路徑和版本號，然后執(zhí)行shell腳本即可，工具會將處理完成之后的用例列表返回給測試人員。

節(jié)省了時間：本發(fā)明所展示給測試人員的用例列表具有較強的參考價值。測試人員可以根據(jù)工具確定代碼的變更所涉及的用例，對于測試人員管理、維護、執(zhí)行測試用例都具有很強的參考價值，省去了測試人員人工查看代碼并評估其影響范圍的時間和精力。

有助于提高用例的質量：本發(fā)明采用的是抓包獲取掃描器輸入資源的方法，相對于爬蟲方式收集的方法，收集的資源要更加的全面，準確，從而提高了掃描質量，降低了漏掃率。

上面對本發(fā)明實施例中獲取測試用例的方法進行了說明，下面對本發(fā)明實施例中的服務器進行說明，如圖5所示，為本發(fā)明實施例中服務器的一個實施例示意圖，包括：

第一獲取模塊501，用于獲取被測對象的函數(shù)調用關系信息；

第二獲取模塊502，用于獲取目標函數(shù)，目標函數(shù)為根據(jù)被測對象的被測版本源碼和歷史版本源碼的差異信息確定的相關函數(shù)，被測版本源碼是歷史版本源碼經(jīng)過處理得到的；

確定模塊503，用于根據(jù)函數(shù)調用關系信息確定與目標函數(shù)對應的目標測試用例。

可選的，在本發(fā)明的一些實施例中，第一獲取模塊501，具體用于：

獲取被測對象的可執(zhí)行文件或者庫文件；

根據(jù)可執(zhí)行文件或者庫文件獲取與被測對象相關的函數(shù)信息；

對與被測對象相關的函數(shù)信息進行解析，得到函數(shù)調用關系信息。

可選的，在本發(fā)明的一些實施例中，第二獲取模塊502，具體用于：

調用版本控制指令；

將版本控制指令向版本控制系統(tǒng)SVN服務器發(fā)送，版本控制指令用于SVN服務器確定被測對象的被測版本源碼與歷史版本源碼的差異信息；

接收SVN服務器發(fā)送的差異信息；

根據(jù)差異信息確定目標函數(shù)。

可選的，在本發(fā)明的一些實施例中，確定模塊503，具體用于：

根據(jù)函數(shù)調用關系信息，確定與目標函數(shù)對應的接口函數(shù)名列表；

根據(jù)接口函數(shù)名列表或者接口函數(shù)名列表中的接口函數(shù)名對應的命令字確定目標測試用例。

可選的，在本發(fā)明的一些實施例中，在圖5所示的基礎上，如圖6所示，為本發(fā)明實施例中服務器的一個實施例示意圖，服務器還包括：

保存模塊504，用于將函數(shù)調用關系信息保存在數(shù)據(jù)庫中。

可選的，在本發(fā)明的一些實施例中，在圖6所示的基礎上，如圖7所示，為本發(fā)明實施例中服務器的一個實施例示意圖，服務器還包括：

展示模塊505，用于以列表形式展示目標測試用例；

測試模塊506，用于根據(jù)目標測試用例對被測對象進行測試。

如圖8所示，為本發(fā)明實施例中服務器的一個實施例示意圖，包括：

該服務器可因配置或性能不同而產(chǎn)生比較大的差異，可以包括收發(fā)器801，一個或一個以上中央處理器(central processing units，CPU)802(例如，一個或一個以上處理器)和存儲器803，一個或一個以上存儲應用程序8041或數(shù)據(jù)8042的存儲介質804(例如一個或一個以上海量存儲設備)。其中，存儲器803和存儲介質804可以是短暫存儲或持久存儲。存儲在存儲介質804的程序可以包括一個或一個以上模塊(圖8中沒示出)，每個模塊可以包括對服務器中的一系列指令操作。更進一步地，中央處理器802可以設置為與存儲介質804通信，在服務器上執(zhí)行存儲介質804中的一系列指令操作。

在本發(fā)明實施例中，該服務器所包括的中央處理器802還具有以下功能：

獲取被測對象的函數(shù)調用關系信息；

獲取目標函數(shù)，目標函數(shù)為根據(jù)被測對象的被測版本源碼和歷史版本源碼的差異信息確定的相關函數(shù)，被測版本源碼是歷史版本源碼經(jīng)過處理得到的；

根據(jù)函數(shù)調用關系信息確定與目標函數(shù)對應的目標測試用例。

可選的，在本發(fā)明的一些實施例中，中央處理器802具體用于：

獲取被測對象的可執(zhí)行文件或者庫文件；

根據(jù)可執(zhí)行文件或者庫文件獲取與被測對象相關的函數(shù)信息；

對與被測對象相關的函數(shù)信息進行解析，得到函數(shù)調用關系信息。

可選的，在本發(fā)明的一些實施例中，中央處理器802具體用于：

調用版本控制指令；

將版本控制指令向版本控制系統(tǒng)SVN服務器發(fā)送，版本控制指令用于SVN服務器確定被測對象的被測版本源碼與歷史版本源碼的差異信息；

接收SVN服務器發(fā)送的差異信息；

根據(jù)差異信息確定目標函數(shù)。

可選的，在本發(fā)明的一些實施例中，中央處理器802具體用于：

根據(jù)函數(shù)調用關系信息，確定與目標函數(shù)對應的接口函數(shù)名列表；

根據(jù)接口函數(shù)名列表或者接口函數(shù)名列表中的接口函數(shù)名對應的命令字確定目標測試用例。

可選的，在本發(fā)明的一些實施例中，中央處理器802還用于：

將函數(shù)調用關系信息保存在數(shù)據(jù)庫中。

可選的，在本發(fā)明的一些實施例中，中央處理器802還用于：

以列表形式展示目標測試用例；

根據(jù)目標測試用例對被測對象進行測試。

所屬領域的技術人員可以清楚地了解到，為描述的方便和簡潔，上述描述的系統(tǒng)，裝置和單元的具體工作過程，可以參考前述方法實施例中的對應過程，在此不再贅述。

在本申請所提供的幾個實施例中，應該理解到，所揭露的系統(tǒng)，裝置和方法，可以通過其它的方式實現(xiàn)。例如，以上所描述的裝置實施例僅僅是示意性的，例如，所述單元的劃分，僅僅為一種邏輯功能劃分，實際實現(xiàn)時可以有另外的劃分方式，例如多個單元或組件可以結合或者可以集成到另一個系統(tǒng)，或一些特征可以忽略，或不執(zhí)行。另一點，所顯示或討論的相互之間的耦合或直接耦合或通信連接可以是通過一些接口，裝置或單元的間接耦合或通信連接，可以是電性，機械或其它的形式。

所述作為分離部件說明的單元可以是或者也可以不是物理上分開的，作為單元顯示的部件可以是或者也可以不是物理單元，即可以位于一個地方，或者也可以分布到多個網(wǎng)絡單元上?？梢愿鶕?jù)實際的需要選擇其中的部分或者全部單元來實現(xiàn)本實施例方案的目的。

另外，在本發(fā)明各個實施例中的各功能單元可以集成在一個處理單元中，也可以是各個單元單獨物理存在，也可以兩個或兩個以上單元集成在一個單元中。上述集成的單元既可以采用硬件的形式實現(xiàn)，也可以采用軟件功能單元的形式實現(xiàn)。

所述集成的單元如果以軟件功能單元的形式實現(xiàn)并作為獨立的產(chǎn)品銷售或使用時，可以存儲在一個計算機可讀取存儲介質中。基于這樣的理解，本發(fā)明的技術方案本質上或者說對現(xiàn)有技術做出貢獻的部分或者該技術方案的全部或部分可以以軟件產(chǎn)品的形式體現(xiàn)出來，該計算機軟件產(chǎn)品存儲在一個存儲介質中，包括若干指令用以使得一臺計算機設備(可以是個人計算機，服務器，或者網(wǎng)絡設備等)執(zhí)行本發(fā)明各個實施例所述方法的全部或部分步驟。而前述的存儲介質包括：U盤、移動硬盤、只讀存儲器(ROM，Read-Only Memory)、隨機存取存儲器(RAM，Random Access Memory)、磁碟或者光盤等各種可以存儲程序代碼的介質。

以上所述，以上實施例僅用以說明本發(fā)明的技術方案，而非對其限制；盡管參照前述實施例對本發(fā)明進行了詳細的說明，本領域的普通技術人員應當理解：其依然可以對前述各實施例所記載的技術方案進行修改，或者對其中部分技術特征進行等同替換；而這些修改或者替換，并不使相應技術方案的本質脫離本發(fā)明各實施例技術方案的精神和范圍。