本申請涉及移動設(shè)備技術(shù)領(lǐng)域，尤其涉及一種移動應(yīng)用缺陷信息處理方法、裝置及系統(tǒng)。

背景技術(shù)：

智能操作系統(tǒng)的出現(xiàn)，使得手機的功能擴展性得到革命性的發(fā)展，并且衍生出如平板電腦、智能手表等多種類型的移動設(shè)備。其中，大量可隨意安裝卸載的app(應(yīng)用)是實現(xiàn)移動設(shè)備豐富功能的關(guān)鍵，很多優(yōu)秀的app甚至可以改變?nèi)藗兊纳罘绞健?/p>

在app的開發(fā)過程中，嚴(yán)格的測試是必不可少的，測試人員發(fā)現(xiàn)app中存在的各種bug(缺陷)后，需要將相關(guān)的bug信息反饋給開發(fā)人員，以便開發(fā)人員及時做出調(diào)整處理。

現(xiàn)有移動應(yīng)用bug提交方案，至少存在以下問題：

首先，測試人員在移動設(shè)備app上發(fā)現(xiàn)bug后，需要通過pc上的客戶端軟件來提交bug描述，后續(xù)開發(fā)人員解決bug后，測試人員在移動設(shè)備app驗證完畢后，再通過pc上的客戶端軟件關(guān)閉bug，這種方式存在平臺反復(fù)切換帶來的操作繁瑣問題之外，如果測試人員希望進一步提交界面截圖、應(yīng)用運行日志等輔助信息，則需要使用usb等方式連接pc與移動設(shè)備，以便將相關(guān)輔助信息從移動設(shè)備傳輸至pc，使用非常不便。

其次，從開發(fā)人員的角度，總是希望測試人員提供的bug信息盡量豐富而又不失針對性，這就對測試人員提出了較高的要求，例如提取應(yīng)用運行l(wèi)og(日志)信息，事實上很多非技術(shù)型測試人員并不具備這樣的技能。即便是具備相 關(guān)技能的測試人員，也需要手動去進行提取，導(dǎo)致測試工作效率受到影響。

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

針對上述技術(shù)問題，本申請?zhí)峁┮环N移動應(yīng)用缺陷信息處理方法、裝置及系統(tǒng)，技術(shù)方案如下：

一種移動應(yīng)用缺陷信息處理方法，該方法包括：

移動設(shè)備端獲得用戶手動輸入的用于描述本機應(yīng)用缺陷的第一類信息；

進一步根據(jù)預(yù)設(shè)的信息提取規(guī)則，從本機上自動提取用于描述所述應(yīng)用缺陷的第二類信息；

將所述第一類信息和所述第二類信息進行關(guān)聯(lián)處理，生成缺陷信息集合；

將所述缺陷信息集合通過網(wǎng)絡(luò)連接上傳至缺陷信息收集平臺。

一種移動應(yīng)用缺陷信息處理裝置，該裝置配置于移動設(shè)備側(cè)，該裝置包括：

信息輸入模塊，用于獲得用戶手動輸入的用于描述本機應(yīng)用缺陷的第一類信息；

信息提取模塊，用于進一步根據(jù)預(yù)設(shè)的信息提取規(guī)則，從本機上自動提取用于描述所述應(yīng)用缺陷的第二類信息；

信息關(guān)聯(lián)模塊，用于將所述第一類信息和所述第二類信息進行關(guān)聯(lián)處理，生成缺陷信息集合；

信息上傳模塊，用于將所述缺陷信息集合通過網(wǎng)絡(luò)連接上傳至缺陷信息收集平臺。

一種移動應(yīng)用缺陷信息處理系統(tǒng)，該系統(tǒng)包括配置于移動設(shè)備側(cè)的、移動應(yīng)用缺陷信息處理裝置，以及缺陷信息收集平臺；

所述缺陷信息收集平臺用于收集平臺端對不同的缺陷信息進行整合，生成缺陷信息集合數(shù)據(jù)庫。

本申請所提供的技術(shù)方案，將bug信息提交端配置在移動設(shè)備上，測試人員在移動設(shè)備app上發(fā)現(xiàn)bug后，直接利用本機就可以上傳bug描述信息，既避免了切換操作平臺的麻煩，又便于直接從移動設(shè)備本地獲得各種輔助信息。 另外，應(yīng)用本申請方案，可以根據(jù)開發(fā)人員的實際需求自定義bug描述信息提取規(guī)則，進而實現(xiàn)bug信息提交端根據(jù)規(guī)則自動提取所需的各種bug描述信息，不需要人為參與。這樣既提高了測試人員的工作效率，也降低了對測試人員的技能要求。

應(yīng)當(dāng)理解的是，以上的一般描述和后文的細節(jié)描述僅是示例性和解釋性的，并不能限制本申請。

附圖說明

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

圖1是本申請的移動應(yīng)用缺陷信息處理系統(tǒng)的結(jié)構(gòu)示意圖；

圖2是本申請的移動應(yīng)用缺陷信息處理方法的流程示意圖；

圖3是本申請的移動應(yīng)用缺陷信息處理的具體應(yīng)用方案的示意圖；

圖4是本申請的移動應(yīng)用缺陷信息處理裝置的第一種結(jié)構(gòu)示意圖；

圖5是本申請的移動應(yīng)用缺陷信息處理裝置的第二種結(jié)構(gòu)示意圖。

具體實施方式

為了使本領(lǐng)域技術(shù)人員更好地理解本申請中的技術(shù)方案，下面將結(jié)合本申請實施例中的附圖，對本申請實施例中的技術(shù)方案進行詳細地描述，顯然，所描述的實施例僅僅是本申請一部分實施例，而不是全部的實施例?；诒旧暾堉械膶嵤├?，本領(lǐng)域普通技術(shù)人員所獲得的所有其他實施例，都應(yīng)當(dāng)屬于本申請保護的范圍。

圖1所示為本申請所提供一種移動應(yīng)用缺陷信息處理系統(tǒng)，該系統(tǒng)包括配置于移動設(shè)備中的缺陷信息處理裝置100、以及缺陷信息收集平臺200。其中移動設(shè)備可以是手機、平板電腦、可穿戴智能設(shè)備等形式，理想的應(yīng)用環(huán)境下， 缺陷信息處理裝置100與缺陷信息收集平臺200二者通過wifi、3g/4g等無線方式實現(xiàn)通信連接，當(dāng)然在特定環(huán)境下，使用有線方式實現(xiàn)通信連接也并不影響本申請方案的實現(xiàn)。

缺陷信息處理裝置100可以通過在基于智能操作系統(tǒng)(例如ios、android、windowsphone等)的移動設(shè)備中安裝專用app的方式實現(xiàn)，用于實現(xiàn)對本機安裝的其他app(即測試對象app)的bug收集以及上傳?？梢岳斫獾氖牵撗b置的相關(guān)功能，也可以是移動設(shè)備操作系統(tǒng)內(nèi)置的功能，或者在專用的測試終端上上實現(xiàn)，本申請對缺陷信息處理裝置100具體的實現(xiàn)方式并不需要進行限定。

信息收集平臺200負責(zé)接收各移動設(shè)備上傳的bug信息，并對這些信息進行存儲，以供開發(fā)人員后續(xù)查看。在信息收集平臺中可以僅存儲于一個測試對象app的bug信息，也可以存儲多個測試對象app的bug信息。

圖2所示為移動設(shè)備側(cè)的bug信息處理方法流程圖、該方法可以包括以下步驟：

s101，獲得用戶手動輸入的用于描述本機應(yīng)用缺陷的第一類信息；

對于人工實現(xiàn)的軟件測試而言，反饋bug最基本的方式就是提交bug信息直觀描述。其中一種最基本的描述方式是文字，隨著各種媒體技術(shù)的發(fā)展，目前也有許多測試系統(tǒng)允許測試人員上傳各種類型的媒體文件，以便令開發(fā)人員更快地了解bug情況，例如app界面截圖、app運行動畫視頻、app運行錄音、或者測試人員自己的語音描述等等，本申請將這一類需要用戶手動輸入的bug描述信息稱為“第一類信息”。

為了實現(xiàn)對第一類信息的上傳，在本申請的缺陷信息處理裝置中可以提供文字輸入框、用于添加各類媒體文件的操作接口等等。根據(jù)實際的開發(fā)及測試需求，可以對測試人員輸入的第一類信息項目進行規(guī)定，例如規(guī)定“文本描述信息”、和“圖像信息”是必選項，“音頻信息”和“視頻信息”是可選項，等等。當(dāng)然，本申請對“第一類信息”所指代的具體項目以及各項信息的具體輸入實現(xiàn)方式并不需要進行限定。

這里需要說明的是，根據(jù)一般的測試規(guī)范，測試人員每次提交的bug信息，應(yīng)該是針對某一具體的app、某一具體bug的描述。在本說明書中，對一套bug信息提交流程的描述，也都是默認針對特定app特定bug的信息提交進行說明。但是這種測試需求不應(yīng)理解為對本申請方案的限制。

s102，進一步根據(jù)預(yù)設(shè)的信息提取規(guī)則，從本機上自動提取用于描述所述應(yīng)用缺陷的第二類信息；

從前一個步驟可以看出，“第一類信息”是從“人”的角度，通過文字、圖片等方式描述用戶使用過程中的直觀感受，這類信息的主要作用是告知開發(fā)人員“存在什么樣的缺陷”。而開發(fā)人員為了實際解決缺陷，往往還需要更多的輔助描述信息，例如移動設(shè)備的型號、操作系統(tǒng)版本、app版本、app運行日志等等，本申請將這類在移動設(shè)備上客觀存在的描述信息稱為“第二類信息”。

“第二類信息”一般是在用戶使用過程中無法直觀感受、或者不需要關(guān)注的信息，因此對于非技術(shù)型測試人員而言，往往不具備提供這些信息的技能，即使具備相關(guān)技能的測試人員，也需要手動去進行提取，導(dǎo)致測試工作效率受到影響。針對該問題，本申請方案可以根據(jù)開發(fā)人員的實際需求自定義bug描述信息提取規(guī)則，進而實現(xiàn)“第二類信息”的自動提取。

舉例說明：

對于app運行過程中的log信息，可以指定到app自用的log輸出目錄提取，也可以借助操作系統(tǒng)自帶命令或第三方工具輸出log信息；

對于操作系統(tǒng)的anr(applicationnotresponding，應(yīng)用無響應(yīng))信息，可以到操作系統(tǒng)/data/anr/目錄提??；

設(shè)備硬件信息、操作系統(tǒng)版本信息，可以利用特定的操作系統(tǒng)命令提取得到；

……

當(dāng)然，還有很多類型的信息，本申請無法一一列舉，總之，“第二類信息”的特征在于“客觀存在性”和“規(guī)律性”，因此在理論上，針對任何一種該類信息，都可以預(yù)先配置出相應(yīng)的通用提取規(guī)則。另外，針對不同的app，也可以 配置不同的提取規(guī)則。對于測試人員而言，只需提交反映主觀感受的“第一類信息”，后續(xù)缺陷信息處理裝置就可以根據(jù)當(dāng)前的測試對象app的對應(yīng)提取規(guī)則，自動提取出開發(fā)人員所需的信息，從而既提高了測試人員的工作效率，也降低了對測試人員的技能要求。

s103，將所述第一類信息和所述第二類信息進行關(guān)聯(lián)處理，生成缺陷信息集合；

本步驟的目的是將前兩個步驟所得到的各種信息以某種方式進行整合，形成描述特定app特定bug的信息集合，以便后續(xù)提交。進行關(guān)聯(lián)的方式可以是將各種信息打包為一個信息文件，也可以保持各種信息的分散狀態(tài)，對各種信息打上某種統(tǒng)一的標(biāo)識，例如添加測試用戶名、app名稱、時間戳等等內(nèi)容。本申請對關(guān)聯(lián)的形式并不需要進行限定。

bug信息涉及的內(nèi)容范圍較廣，而不同測試人員/不同批次提交的bug信息內(nèi)容可能千差萬別，例如bug信息中包含/不包含截圖、bug信息中包含不同數(shù)量的截圖、bug信息中包含/不包含anr信息、等等。而對于開發(fā)人員來說，看到的只是不同測試人員提交的雜亂無規(guī)則的各種文件，無論是閱讀還是管理都非常困難。

與現(xiàn)有方案相比，應(yīng)用本申請方案，由于對“第二類信息”采用自動提取的方式，因此可以在一定程度保證“第二類信息”的提交規(guī)范化，但是實際應(yīng)用過程中也可能會存在信息提取失敗的情況，而且如果對于“第一類信息”的上傳沒有嚴(yán)格限制，則所提交的bug信息在整體上仍然會在一定程度上存在雜亂無規(guī)則的情況。

針對上述問題，本申請的提供一種優(yōu)選實施方案如下：

預(yù)先根據(jù)測試人員可能上傳的所有類型的bug信息，建立結(jié)構(gòu)化缺陷信息集合模型。進而在實際需要提交bug信息時，將本次需要上傳的不同類型的信息分別填充到模型中的相應(yīng)位置，從而得到一個結(jié)構(gòu)化的缺陷信息集合。

根據(jù)本申請方案，一方面，為測試人員提供了相對固定的第一類信息輸入接口，另一方面，對于第二類信息的提取也是統(tǒng)一的，因此每次上傳的bug信 息完全可以用一種統(tǒng)一的結(jié)構(gòu)加以表示，這就為信息的結(jié)構(gòu)化處理提供了良好的前提條件。

本申請中結(jié)構(gòu)化bug信息模型，與常規(guī)意義上的結(jié)構(gòu)化數(shù)據(jù)模型概念類似，將每份待提交的bug信息抽象為多種屬性進行描述，每種屬性以類似結(jié)構(gòu)化數(shù)據(jù)中“字段”的方式來表達，與常規(guī)意義上“字段”的區(qū)別在于：結(jié)構(gòu)化bug信息模型的字段內(nèi)容，除了可以是文本、數(shù)值等數(shù)據(jù)對象，還可以是圖像、視頻等文件對象。而對于本次上傳中沒有包含的對象，只需將相應(yīng)的字段內(nèi)容標(biāo)注為空即可。

相應(yīng)地，對bug信息的結(jié)構(gòu)化處理方式，既可以是將各種信息打包為一個結(jié)構(gòu)化的信息文件，也可以保持各種信息的分散狀態(tài)，根據(jù)模型字段的名稱，為各類信息添加相應(yīng)的字段標(biāo)識，本申請對結(jié)構(gòu)化的具體形式并不需要進行限定。

另外可以理解的是，在本申請的結(jié)構(gòu)化數(shù)據(jù)模型中，不僅限于記錄前述的第一類信息和第二類信息，還可以進一步記錄如測試人員標(biāo)識、上傳時間等其他輔助信息。

結(jié)構(gòu)化處理的好處在于：將原本散亂的信息按照統(tǒng)一的格式進行整理，還可以進一步實現(xiàn)信息摘要統(tǒng)計、字段索引等功能。對于開發(fā)人員來說，可以快速了解一份bug提交報告的整體情況、快速找到所需的信息、甚至還可以在不同的bug提交報告之間進行對比。

進一步地，從全局的角度考慮，在收集平臺側(cè)，需要接收并存儲不同測試人員、不同設(shè)備上傳的bug信息，根據(jù)現(xiàn)有的bug信息提交方案，各類bug信息處于雜亂無規(guī)則狀態(tài)，很難對全部的信息進行統(tǒng)一管理。而應(yīng)用本申請方案，由于每份bug報告都采用了結(jié)構(gòu)化處理方式，因此在收集平臺側(cè)，也更便于對不同移動設(shè)備端上傳的bug信息進行整合，生成結(jié)構(gòu)化的信息集合數(shù)據(jù)庫。從而進一步實現(xiàn)根據(jù)特定字段對bug信息進行分類、排序、篩選、查詢等高級管理功能。

以對不同app的bug信息管理為例，根據(jù)現(xiàn)有的bug信息提交方案，需要 針對不同app、甚至相同app的不同版本的bug信息分別進行管理，隨著app種類、版本數(shù)量的不斷增加，整體的維護開銷難以控制。而應(yīng)用本申請方案，由于采用了統(tǒng)一的結(jié)構(gòu)化bug信息模型，因此完全可以將不同app、不同版本的bug信息進行統(tǒng)一的結(jié)構(gòu)化存儲，在需要查看使用的時候，通過簡單的字段篩選或查詢操作，就可以找到特定app、特定版本的bug信息，不僅使用上更加方便，而且有效降低了數(shù)據(jù)的整體維護開銷。

s104，將缺陷信息集合通過網(wǎng)絡(luò)連接上傳至缺陷信息收集平臺。

缺陷信息處理裝置將上述得到的bug信息集合上傳至信息收集平臺，必要時可以添加測試用戶標(biāo)識、上傳時間等輔助信息，當(dāng)然該操作也可以在前一步驟中實現(xiàn)，本申請對此并不需要進行限定。

理想的應(yīng)用環(huán)境下，移動設(shè)備通過wifi、3g/4g等無線方式接入信息收集平臺，當(dāng)然在特定環(huán)境下，移動設(shè)備通過有線方式接入信息收集平臺也并不影響本申請方案的實現(xiàn)。

上述s101-s104提供了一套完整的bug信息上傳方案，在此基礎(chǔ)上，本申請的缺陷信息處理裝置還可以進一步提供對已上傳缺陷信息集合的管理功能。除了常用的bug解決標(biāo)識操作(即bug關(guān)閉操作之外)，測試人員還可以在移動設(shè)備上向收集平臺側(cè)發(fā)起查詢、添加、修改、刪除等管理操作。

上述的查詢操作，可以基于bug信息集合的一種或多種標(biāo)識發(fā)起，例如測試用戶標(biāo)識、上傳時間等等。特別地，對于采用結(jié)構(gòu)化方式上傳的bug信息集合，還可以針對一個或多個具體的信息字段發(fā)起查詢，例如：查詢在“bug文字描述字段”中包含特定文本的bug信息。

對于添加、修改、刪除等寫入類操作，測試人員可以通過先查詢、再針對查詢結(jié)果進行寫入操作的方式實現(xiàn)，也可以直接利用bug信息集合的某種標(biāo)識或具體字段直接進行寫入操作。其中寫入操作的對象既可以是文本、數(shù)值等數(shù)據(jù)對象，也可以是圖像、視頻等文件對象。

當(dāng)然，在實現(xiàn)上述功能時，可以要求用戶提供相應(yīng)的認證信息，例如文本密碼、聲紋、指紋等等。對于不同身份的用戶，也可以提供不同級別的操作權(quán) 限，本申請對具體實現(xiàn)方式不再做進一步說明。

圖3示出了應(yīng)用在andriod手機環(huán)境下的一種具體的bug信息處理方案的示意圖。

參見圖3左側(cè)所示，在bug信息集合中，第一類信息包括：bug文字描述、截圖信息；第二類信息包括：logcat信息、anr信息、手機系統(tǒng)信息、app版本信息；各部分bug信息的獲取方式如下：

bug文字描述：測試人員在輸入框中手工輸入；

截圖信息：測試人員通過手機自帶的截圖功能獲取圖片，然后在此處只需要選取bug發(fā)生時的截圖即可；

logcat信息：使用logcat工具，通過logcat-d-vtime-f命令，將日志信息文本保存到應(yīng)用目錄下，上傳時直接從該目錄自動提??；開發(fā)人員可以根據(jù)logcat的文本信息，找到crash、exception等關(guān)鍵字，作為bug修復(fù)的重要參考依據(jù)。

anr日志信息：android系統(tǒng)在觸發(fā)anr問題時會自動將堆棧信息保存到/data/anr目錄下；上傳時直接從該目錄自動提??；

手機系統(tǒng)信息：通過getprop工具獲取本機的相關(guān)信息，然后分別過濾brand和product.model后篩選出品牌以及型號等信息；

app版本信息：該信息需要從android系統(tǒng)的堆棧中獲取，通過dumpsyspackage<packagename>獲取被測對象的所有信息，過濾versionname后獲得被測對象的具體版本號；

通過以上手工和自動結(jié)合的方式，可以完成一個描述bug必需信息的收集。

在bug信息管理部分，借助阿里云oss實現(xiàn)數(shù)據(jù)在服務(wù)端的存儲。oss服務(wù)端的文件為json類型，文件內(nèi)容和相應(yīng)java對象通過gson工具進行映射，從而實現(xiàn)對對象實例的操作進而完成對json文件的編輯，類似hibernate的實現(xiàn)原理。用戶側(cè)對oss服務(wù)器上json文件的操作主要通過osssdk提供的api完成。

在oss上文件的組織形式分三層，見圖3右側(cè)所示。

第一層是包含所有bug信息的bugoverriew.json文件，其中包含了id(bug的標(biāo)識序列號)、bugdesc(bug的概述)、link(bug具體信息的json在oss的 object名稱)等信息。

第二層是bugmessage.json文件，該文件內(nèi)容對應(yīng)的java對象信息如下：

第三層則是bug對應(yīng)的附件信息，主要是logcat日志、anr日志、圖片這三種類型的文件。通過上面的分層結(jié)構(gòu)，可以實現(xiàn)bug信息的結(jié)構(gòu)化存儲，進而實現(xiàn)對bug信息的各種高級管理功能。而應(yīng)用本申請方案，上述功能不僅能在平臺側(cè)實現(xiàn)，測試用戶在手機端也可以直接已上傳的bug信息進行管理操作，例如圖中所示的query(查詢)、add(添加)、刪除(delete)、modify(修改)操作等等。

可以理解的是，上述方案僅是本申請的一種具體實施方式，不應(yīng)理解為對本申請方案的限定。

相應(yīng)于上述方法實施例，本申請還提供一種移動應(yīng)用缺陷信息處理裝置，該裝置配置于移動設(shè)備側(cè)，參見圖4所示，該裝置可以包括：

信息輸入模塊110，用于獲得用戶手動輸入的用于描述本機應(yīng)用缺陷的第一類信息。

其中，第一類信息，可以包括以下一種或多種：

文本信息、圖像信息、音頻信息、視頻信息。

信息提取模塊120，用于進一步根據(jù)預(yù)設(shè)的信息提取規(guī)則，從本機上自動提取用于描述所述應(yīng)用缺陷的第二類信息。

其中，第二類信息，可以包括以下一種或多種：

應(yīng)用的版本信息、應(yīng)用的運行日志信息、移動設(shè)備的操作系統(tǒng)版本信息、移動設(shè)備的操作系統(tǒng)anr信息、移動設(shè)備的硬件信息。

信息關(guān)聯(lián)模塊130，用于將第一類信息和第二類信息進行關(guān)聯(lián)處理，生成缺陷信息集合。

信息上傳模塊140，用于將缺陷信息集合通過網(wǎng)絡(luò)連接上傳至缺陷信息收集平臺。

在本申請的一種具體實施方式中，信息關(guān)聯(lián)模塊130可以具體用于：

根據(jù)預(yù)設(shè)的結(jié)構(gòu)化模型，將不同類型的信息分別填充到模型中的預(yù)設(shè)位置，生成結(jié)構(gòu)化的缺陷信息集合。

參見圖5所示，在本申請的一種具體實施方式中，上述裝置還可以包括：

信息管理模塊150，用于向缺陷信息收集平臺發(fā)起針對已上傳缺陷信息集合的管理操作；

其中，管理操作可以包括以下一種或多種：

缺陷解決標(biāo)識操作、查詢操作、添加操作、修改操作、刪除操作。

上述裝置中各個模塊的功能和作用的實現(xiàn)過程具體詳見上述方法中對應(yīng)步驟的實現(xiàn)過程，在此不再贅述。

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

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

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