本發(fā)明涉及通信領域，尤其涉及一種應用(app，application)故障定位方法及裝置。

背景技術：

隨著移動通信網(wǎng)絡的迅猛發(fā)展，人們對網(wǎng)絡的服務質(zhì)量要求越來越高，網(wǎng)絡服務質(zhì)量的問題日益重要，為此，快速查找定位app故障是運營商的迫切需求?，F(xiàn)有app技術可以實現(xiàn)app故障的定位，通過客戶反饋問題，運營商獲得客戶遇到的app故障的信息，運營商依次檢測app網(wǎng)絡連接過程中的路徑連通性、現(xiàn)場測試抓包分析、app資源訪問路徑分析、app資源歸屬地分析后，分析定位app故障。

然而，現(xiàn)有的app故障分析存在如下缺陷：如果客戶不反饋故障，運營商獲取實時故障信息困難；目前的app故障定位工作，主要依賴于個別技術人員的經(jīng)驗，而靠技術人員對繁雜的網(wǎng)絡數(shù)據(jù)進行及時的分析和對比，得出正確的故障處理方案，效率很低；另外，技術工程師往往借助于單一類型的網(wǎng)絡數(shù)據(jù)來進行分析和對比，而不是根據(jù)所有與網(wǎng)絡相關的數(shù)據(jù)(如話統(tǒng)數(shù)據(jù)，路測數(shù)據(jù))得出網(wǎng)絡優(yōu)化方案，這顯然有一定的缺陷性。

因此，提供一種app故障定位方案，能夠?qū)崿F(xiàn)系統(tǒng)性分析app故障，解決人工效率低、服務質(zhì)量低等問題，已成為亟待解決的問題。

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

有鑒于此，本發(fā)明實施例期望提供一種app故障定位方法及裝置，至少解決了現(xiàn)有技術存在的問題，能夠高效準確的實現(xiàn)app故障定位，提高網(wǎng)絡服務 性能及用戶滿意度。

為達到上述目的，本發(fā)明實施例的技術方案是這樣實現(xiàn)的：

本發(fā)明實施例提供了一種app故障定位方法，所述方法包括：

獲取運行app的第一功能對應的流量數(shù)據(jù)包；

提取所述流量數(shù)據(jù)包中資源相關信息及app交互特征信息；

基于所述資源相關信息及app交互特征信息判斷所述app的第一功能是否存在故障，確定所述app的第一功能存在故障時，獲取相應的故障類型；

基于所述app交互特征信息及所述故障類型對所述app的第一功能進行故障檢測，并基于檢測結(jié)果定位所述app的第一功能的故障原因。

上述方案中，所述資源相關信息至少包括狀態(tài)碼，所述app交互特征信息至少包括：響應時間信息及資源大小信息；

所述基于所述資源相關信息及app交互特征信息判斷所述app的第一功能是否存在故障，確定所述app的第一功能存在故障時，獲取相應的故障類型，包括：

將所述狀態(tài)碼與預設的第一狀態(tài)碼進行匹配，匹配成功時，確定所述app的第一功能存在故障，且相應的故障類型為資源訪問失??；

匹配失敗時，將所述狀態(tài)碼與預設的第二狀態(tài)碼進行匹配，匹配成功時，依據(jù)所述響應時間信息及資源大小信息確定相應的資源下載速度，當所述資源下載速度小于預設的下載速度閾值時，確定所述app的第一功能存在故障，且相應的故障類型為資源訪問速度慢。

上述方案中，所述app交互特征信息還包括統(tǒng)一資源定位符url信息、互聯(lián)網(wǎng)協(xié)議ip地址信息及端口信息；

所述app的第一功能的故障類型為資源訪問速度慢時，所述基于所述app交互特征信息及所述故障類型對所述app的第一功能進行故障檢測，并基于檢測結(jié)果定位所述app的第一功能的故障原因，包括：

基于所述url信息、ip地址信息及端口信息對所述app的第一功能進行ping檢測及trace檢測，得到檢測結(jié)果，所述檢測結(jié)果至少包括丟包率信息 及路徑擁堵情況信息，基于所述丟包率信息及路徑擁堵情況信息定位所述app的第一功能的故障原因。

上述方案中，所述app交互特征信息還包括url信息、ip地址信息及端口信息；

所述app的第一功能的故障類型為資源訪問失敗時，所述基于所述app交互特征信息及所述故障類型對所述app的第一功能進行故障檢測，并基于檢測結(jié)果定位所述app的第一功能的故障原因，包括：

基于所述ip地址信息對所述app的第一功能進行第一次ping檢測，確定與所述app的第一功能對應的目標服務器的連通情況；

基于所述url信息、ip地址信息及端口信息對所述app的第一功能進行第二次ping檢測以及trace檢測，得到檢測結(jié)果，所述檢測結(jié)果至少包括丟包率信息及路徑擁堵情況信息；

基于與所述目標服務器的連通情況、所述資源下載速度信息、所述丟包率信息及路徑擁堵情況信息定位所述app的第一功能的故障原因。

上述方案中，所述方法還包括：

基于所述ip地址信息確定所述app的第一功能對應的資源歸屬地信息；

和/或獲取運行app的第一功能對應的數(shù)據(jù)包交換過程信息；

和/或獲取運行app的第一功能對應的中央處理器cpu使用率、內(nèi)存使用率信息；

將所述資源歸屬地信息、和/或所述數(shù)據(jù)包交換過程信息、和/或所述cpu使用率、內(nèi)存使用率信息作為定位所述app的第一功能的故障原因的參考信息。

本發(fā)明實施例還提供了一種app故障定位裝置，所述裝置位于終端，所述裝置包括：數(shù)據(jù)包獲取模塊、信息提取模塊、故障判斷模塊及故障定位模塊；其中，

所述數(shù)據(jù)包獲取模塊，用于獲取運行app的第一功能對應的流量數(shù)據(jù)包；

所述信息提取模塊，用于提取所述流量數(shù)據(jù)包中資源相關信息及app交互特征信息；

所述故障判斷模塊，用于基于所述資源相關信息及app交互特征信息判斷所述app的第一功能是否存在故障，確定所述app的第一功能存在故障時，獲取相應的故障類型；

所述故障定位模塊，用于基于所述app交互特征信息及所述故障類型對所述app的第一功能進行故障檢測，并基于檢測結(jié)果定位所述app的第一功能的故障原因。

上述方案中，所述資源相關信息至少包括狀態(tài)碼，所述app交互特征信息至少包括：響應時間信息及資源大小信息；

所述故障判斷模塊，還用于將所述狀態(tài)碼與預設的第一狀態(tài)碼進行匹配，匹配成功時，確定所述app的第一功能存在故障，且相應的故障類型為資源訪問失?。?/p>

匹配失敗時，將所述狀態(tài)碼與預設的第二狀態(tài)碼進行匹配，匹配成功時，依據(jù)所述響應時間信息及資源大小信息確定相應的資源下載速度，當所述資源下載速度小于預設的下載速度閾值時，確定所述app的第一功能存在故障，且相應的故障類型為資源訪問速度慢。

上述方案中，所述app交互特征信息還包括url信息、ip地址信息及端口信息；

所述app的第一功能的故障類型為資源訪問失敗時，所述故障定位模塊，還用于基于所述url信息、ip地址信息及端口信息對所述app的第一功能進行ping檢測及trace檢測，得到檢測結(jié)果，所述檢測結(jié)果至少包括丟包率信息及路徑擁堵情況信息，基于所述丟包率信息及路徑擁堵情況信息定位所述app的第一功能的故障原因。

上述方案中，所述app交互特征信息還包括url信息、ip地址信息及端口信息；

所述app的第一功能的故障類型為資源訪問速度慢時，所述故障定位模塊，還用于基于所述ip地址信息對所述app的第一功能進行第一次ping檢測，確定與所述app的第一功能對應的目標服務器的連通情況；

基于所述url信息、ip地址信息及端口信息對所述app的第一功能進行第二次ping檢測以及trace檢測，得到檢測結(jié)果，所述檢測結(jié)果至少包括丟包率信息及路徑擁堵情況信息；

基于與所述目標服務器的連通情況、所述資源下載速度信息、所述丟包率信息及路徑擁堵情況信息定位所述app的第一功能的故障原因。

上述方案中，所述裝置還包括處理模塊，用于基于所述ip地址信息確定所述app的第一功能對應的資源歸屬地信息；

和/或獲取運行app的第一功能對應的數(shù)據(jù)包交換過程信息；

和/或獲取運行app的第一功能對應的cpu使用率、內(nèi)存使用率信息；

將所述資源歸屬地信息、和/或所述數(shù)據(jù)包交換過程信息、和/或所述cpu使用率、內(nèi)存使用率信息作為定位所述app的第一功能的故障原因的參考信息。

本發(fā)明實施例所提供的app故障定位方法及裝置，獲取運行app的第一功能對應的流量數(shù)據(jù)包；提取所述流量數(shù)據(jù)包中資源相關信息及app交互特征信息；基于所述資源相關信息及app交互特征信息判斷所述app的第一功能是否存在故障，確定所述app的第一功能存在故障時，獲取相應的故障類型；基于所述app交互特征信息及所述故障類型對所述app的第一功能進行故障檢測，并基于檢測結(jié)果定位所述app的第一功能的故障原因。如此，實現(xiàn)了自動抓取app的第一功能對應的流量數(shù)據(jù)包，并基于抓取的流量數(shù)據(jù)包判斷所述app的第一功能是否存在故障，解決了app故障依賴客戶投訴、影響網(wǎng)絡服務質(zhì)量的問題；在確定所述app的第一功能存在故障時，高效準確的實現(xiàn)app故障定位，提高網(wǎng)絡服務性能及用戶滿意度。

附圖說明

圖1為本發(fā)明實施例app故障定位方法流程示意圖一；

圖2為本發(fā)明實施例app故障定位方法流程示意圖二；

圖3為本發(fā)明實施例app故障定位方法流程示意圖三；

圖4為本發(fā)明實施例app故障定位裝置組成結(jié)構示意圖。

具體實施方式

在本發(fā)明實施例中，終端獲取運行app的第一功能對應的流量數(shù)據(jù)包；提取所述流量數(shù)據(jù)包中資源相關信息及app交互特征信息；基于所述資源相關信息及app交互特征信息判斷所述app的第一功能是否存在故障，確定所述app的第一功能存在故障時，獲取相應的故障類型；基于所述app交互特征信息及所述故障類型對所述app的第一功能進行故障檢測，并基于檢測結(jié)果定位所述app的第一功能的故障原因。

下面結(jié)合附圖及具體實施例對本發(fā)明再作進一步詳細的說明。

實施例一

圖1為本發(fā)明實施例app故障定位方法流程示意圖，如圖1所示，本發(fā)明實施例app故障定位方法包括：

步驟101：獲取運行app的第一功能對應的流量數(shù)據(jù)包。

這里，所述第一功能為所述app的任意一個功能；如：所述app為京東app，所述第一功能可以為京東超市、物流查詢、分類查詢，等等。

所述獲取可以為周期性的獲取或定時獲?。划敒橹芷谛垣@取時，所述周期可以依據(jù)實際需要進行設定，如一小時，如此，可以避免網(wǎng)絡波動對應app服務質(zhì)量帶來的影響；當為定時獲取時，時間的設定可以為熱點時間，如每天9點-11點或節(jié)日時間，用戶會大量使用特定app(如視頻、購物app)，若是在這個時間段出現(xiàn)app故障就需要在這些時間查找，因此，設定在熱點時間對app的某一功能進行故障檢測及定位，可提高對用戶的服務質(zhì)量。

所述獲取可以為抓取，可通過分析所述app所在終端的操作系統(tǒng)的底層代碼，確定抓取所述流量數(shù)據(jù)包的方式。

步驟102：提取所述流量數(shù)據(jù)包中資源相關信息及app交互特征信息。

這里，可通過解析所述流量數(shù)據(jù)包對應的超文本傳輸協(xié)議(http，hypertexttransferprotocol)響應頭獲取所述資源相關信息，解析所述流量數(shù)據(jù)包獲取所述app交互特征信息；

所述資源相關信息包括：統(tǒng)一資源定位符(url，uniformresourcelocator)、狀態(tài)碼、cache-control、connection、content-type、date、expires、last-modified、via、x-cache等信息；其中，通過所述cache-control及所述last-modified信息可判斷資源是否可緩存，通過所述x-cache信息可判斷資源是否在緩存中；

所述app交互特征信息包括：響應時間、url、ip地址、端口、資源大小、協(xié)議等信息；

其中，上述url及ip地址指運行所述app的第一功能對應的url及ip地址。

步驟103：基于所述資源相關信息及app交互特征信息判斷所述app的第一功能是否存在故障，確定所述app的第一功能存在故障時，獲取相應的故障類型。

基于本發(fā)明所述實施例，在實際應用中，本步驟具體包括：將所述狀態(tài)碼與預設的第一狀態(tài)碼進行匹配，匹配成功時，確定所述app的第一功能存在故障，且相應的故障類型為資源訪問失??；

匹配失敗時，將所述狀態(tài)碼與預設的第二狀態(tài)碼進行匹配，匹配成功時，依據(jù)所述響應時間信息及資源大小信息確定相應的資源下載速度，當所述資源下載速度小于預設的下載速度閾值時，確定所述app的第一功能存在故障，且相應的故障類型為資源訪問速度慢；

這里，所述第一狀態(tài)碼可以為資源訪問失敗，即頁面無法正常打開對應的狀態(tài)碼；所述第二狀態(tài)碼可以為資源訪問成功，即頁面可以正常打開對應的狀態(tài)碼，如：狀態(tài)碼為200或302；

所述下載速度閾值可以依據(jù)實際情況進行設定，在一實施例中，所述下載速度閾值可以為200kb/s；

也就是說，本步驟操作通過所述狀態(tài)碼確定所請求頁面無法正常打開時，則相應的故障為資源訪問失??；確定所請求頁面可以正常打開時，進一步判斷資源下載速度是否小于預設的下載速度閾值，若小于，則確定相應的故障為資 源訪問速度慢，若不小于，則確定不存在故障。

步驟104：基于所述app交互特征信息及所述故障類型對所述app的第一功能進行故障檢測，并基于檢測結(jié)果定位所述app的第一功能的故障原因。

在一實施例中，當確定所述app的第一功能存在故障，且所述app的第一功能的故障類型為資源訪問速度慢時，本步驟具體包括：

基于所述url信息、ip地址信息及端口信息對所述app的第一功能進行ping檢測及trace檢測，得到檢測結(jié)果，所述檢測結(jié)果至少包括丟包率信息及路徑擁堵情況信息，基于所述丟包率信息及路徑擁堵情況信息定位所述app的第一功能的故障原因。

當確定所述app的第一功能存在故障，且所述app的第一功能的故障類型為資源訪問失敗時，本步驟具體包括：

基于所述ip地址信息對所述app的第一功能進行第一次ping檢測，確定與所述app的第一功能對應的目標服務器的連通情況；

基于所述url信息、ip地址信息及端口信息對所述app的第一功能進行第二次ping檢測以及trace檢測，得到檢測結(jié)果，所述檢測結(jié)果至少包括丟包率信息及路徑擁堵情況信息；

基于與所述目標服務器的連通情況、所述資源下載速度信息、所述丟包率信息及路徑擁堵情況信息定位所述app的第一功能的故障原因。

進一步的，當所述app的第一功能的故障類型為資源訪問失敗時，所述方法還包括：

基于所述流量數(shù)據(jù)包判斷是否缺少資源訪問成功所需的關鍵元素，所述關鍵元素至少包括html元素及css元素，并依據(jù)判斷結(jié)果定位所述app的第一功能的故障原因。

進一步的，所述方法還包括：基于所述url對應的資源類型及所述狀態(tài)碼對所述app的第一功能進行資源下載測試、視頻播放測試、游戲測試、網(wǎng)頁測試等，并將測試結(jié)果信息作為定位所述app的第一功能的故障原因的參考信息。

進一步的，所述方法還包括：基于所述ip地址信息確定所述app的第一 功能對應的資源歸屬地信息；

和/或獲取運行app的第一功能對應的數(shù)據(jù)包交換過程信息；

和/或獲取運行app的第一功能對應的中央處理器cpu使用率、內(nèi)存使用率信息；

將所述資源歸屬地信息、和/或所述數(shù)據(jù)包交換過程信息、和/或所述cpu使用率、內(nèi)存使用率信息作為定位所述app的第一功能的故障原因的參考信息。

在一實施例中，可多次(如n次，n大于1)獲取所述app的第一功能對應的多個流量數(shù)據(jù)包，并基于所述多個流量數(shù)據(jù)包確定所述app的第一功能的故障次數(shù)(資源訪問失敗次數(shù)/資源訪問速度慢次數(shù))，然后基于對每次所述app的第一功能的故障的定位結(jié)果確定故障的最終原因；如：對所述流量數(shù)據(jù)包進行5次抓取，分別基于每次抓取的數(shù)據(jù)包進行故障分析確定出現(xiàn)故障的次數(shù)為4，分別基于出現(xiàn)故障的4次數(shù)據(jù)包進行故障定位，確定3次故障原因為a，一次原因為b，可確定所述app的第一功能的故障原因為a。

實施例二

圖2為本發(fā)明實施例app故障定位方法流程示意圖，如圖2所示，本發(fā)明實施例app故障定位方法包括：

步驟201：獲取運行app的第一功能對應的流量數(shù)據(jù)包。

這里，所述第一功能為所述app的任意一個功能；如：所述app為京東app，所述第一功能可以為京東超市、物流查詢、分類查詢，等等。

所述獲取可以為周期性的獲取或定時獲??；當為周期性獲取時，所述周期可以依據(jù)實際需要進行設定，如一小時，如此，可以避免網(wǎng)絡波動對應app服務質(zhì)量帶來的影響；當為定時獲取時，時間的設定可以為熱點時間，如每天9點-11點或節(jié)日時間，用戶會大量使用特定app(如視頻、購物app)，若是在這個時間段出現(xiàn)app故障就需要在這些時間查找，因此，設定在熱點時間對app的某一功能進行故障檢測及定位，可提高對用戶的服務質(zhì)量。

所述獲取可以為抓取，可通過分析所述app所在終端的操作系統(tǒng)的底層代碼，確定抓取所述流量數(shù)據(jù)包的方式。

步驟202：提取所述流量數(shù)據(jù)包中資源相關信息及app交互特征信息。

這里，可通過解析所述流量數(shù)據(jù)包對應的http響應頭，即頁面響應頭獲取所述資源相關信息，解析所述流量數(shù)據(jù)包獲取所述app交互特征信息；

所述資源相關信息包括：url、狀態(tài)碼、cache-control、connection、content-type、date、expires、last-modified、via、x-cache等信息；其中，通過所述cache-control及所述last-modified信息可判斷資源是否可緩存，通過所述x-cache信息可判斷資源是否在緩存中；

所述app交互特征信息包括：響應時間、url、ip地址、端口、資源大小、協(xié)議等信息；

其中，上述url及ip地址指運行所述app的第一功能對應的url及ip地址。

步驟203：基于所述資源相關信息及app交互特征信息判斷所述app的第一功能是否存在故障，如果存在故障，執(zhí)行步驟204；否則，執(zhí)行步驟205。

在本發(fā)明實施例中，所述故障包括兩種，分別為資源訪問失敗的故障及資源訪問速度慢的故障；

本步驟具體包括：將所述狀態(tài)碼與預設的第一狀態(tài)碼進行匹配，匹配成功時，確定所述app的第一功能存在故障，且相應的故障類型為資源訪問失敗；

匹配失敗時，將所述狀態(tài)碼與預設的第二狀態(tài)碼進行匹配，匹配成功時，依據(jù)所述響應時間信息及資源大小信息確定相應的資源下載速度，當所述資源下載速度小于預設的下載速度閾值時，確定所述app的第一功能存在故障，且相應的故障類型為資源訪問速度慢；

這里，所述第一狀態(tài)碼可以為資源訪問失敗，即頁面無法正常打開對應的狀態(tài)碼；所述第二狀態(tài)碼可以為資源訪問成功，即頁面可以正常打開對應的狀態(tài)碼，如：狀態(tài)碼為200或302；

所述下載速度閾值可以依據(jù)實際情況進行設定，在一實施例中，所述下載速度閾值可以為200kb/s；

也就是說，本步驟操作通過所述狀態(tài)碼確定所請求頁面無法正常打開時， 則相應的故障為資源訪問失??；確定所請求頁面可以正常打開時，進一步判斷資源下載速度是否小于預設的下載速度閾值，若小于，則確定相應的故障為資源訪問速度慢，若不小于，則確定不存在故障。

步驟204：獲取到所述app的第一功能的故障類型為資源訪問速度慢，對所述app的第一功能進行故障檢測，并基于檢測結(jié)果定位所述app的第一功能的故障原因。

在本發(fā)明實施例中，對所述app的第一功能進行故障檢測，并基于檢測結(jié)果定位所述app的第一功能的故障原因，包括：

基于所述url信息、ip地址信息及端口信息對所述app的第一功能進行ping檢測及trace檢測，得到檢測結(jié)果，所述檢測結(jié)果至少包括丟包率信息及路徑擁堵情況信息，基于所述丟包率信息及路徑擁堵情況信息定位所述app的第一功能的故障原因。

進一步的，所述方法還包括：

基于所述ip地址信息確定所述app的第一功能對應的資源歸屬地信息；

和/或獲取運行app的第一功能對應的數(shù)據(jù)包交換過程信息；

和/或獲取運行app的第一功能對應的中央處理器cpu使用率、內(nèi)存使用率信息；

將所述資源歸屬地信息、和/或所述數(shù)據(jù)包交換過程信息、和/或所述cpu使用率、內(nèi)存使用率信息作為定位所述app的第一功能的故障原因的參考信息。

步驟205：結(jié)束本次處理流程。

實施例三

圖3為本發(fā)明實施例app故障定位方法流程示意圖，如圖3所示，本發(fā)明實施例app故障定位方法包括：

步驟301：獲取運行app的第一功能對應的流量數(shù)據(jù)包。

這里，所述第一功能為所述app的任意一個功能；如：所述app為京東app，所述第一功能可以為京東超市、物流查詢、分類查詢，等等。

所述獲取可以為周期性的獲取或定時獲??；當為周期性獲取時，所述周期 可以依據(jù)實際需要進行設定，如一小時，如此，可以避免網(wǎng)絡波動對應app服務質(zhì)量帶來的影響；當為定時獲取時，時間的設定可以為熱點時間，如每天9點-11點或節(jié)日時間，用戶會大量使用特定app(如視頻、購物app)，若是在這個時間段出現(xiàn)app故障就需要在這些時間查找，因此，設定在熱點時間對app的某一功能進行故障檢測及定位，可提高對用戶的服務質(zhì)量。

所述獲取可以為抓取，可通過分析所述app所在終端的操作系統(tǒng)的底層代碼，確定抓取所述流量數(shù)據(jù)包的方式。

步驟302：提取所述流量數(shù)據(jù)包中資源相關信息及app交互特征信息。

這里，可通過解析所述流量數(shù)據(jù)包對應的http響應頭，即頁面響應頭獲取所述資源相關信息，解析所述流量數(shù)據(jù)包獲取所述app交互特征信息；

所述資源相關信息包括：url、狀態(tài)碼、cache-control、connection、content-type、date、expires、last-modified、via、x-cache等信息；其中，通過所述cache-control及所述last-modified信息可判斷資源是否可緩存，通過所述x-cache信息可判斷資源是否在緩存中；

所述app交互特征信息包括：響應時間、url、ip地址、端口、資源大小、協(xié)議等信息；

其中，上述url及ip地址指運行所述app的第一功能對應的url及ip地址。

步驟303：基于所述資源相關信息及app交互特征信息判斷所述app的第一功能是否存在故障，如果存在故障，執(zhí)行步驟304；否則，執(zhí)行步驟305。

在本發(fā)明實施例中，所述故障包括兩種，分別為資源訪問失敗的故障及資源訪問速度慢的故障；

本步驟具體包括：將所述狀態(tài)碼與預設的第一狀態(tài)碼進行匹配，匹配成功時，確定所述app的第一功能存在故障，且相應的故障類型為資源訪問失?。?/p>

匹配失敗時，將所述狀態(tài)碼與預設的第二狀態(tài)碼進行匹配，匹配成功時，依據(jù)所述響應時間信息及資源大小信息確定相應的資源下載速度，當所述資源下載速度小于預設的下載速度閾值時，確定所述app的第一功能存在故障，且 相應的故障類型為資源訪問速度慢；

這里，所述第一狀態(tài)碼可以為資源訪問失敗，即頁面無法正常打開對應的狀態(tài)碼；所述第二狀態(tài)碼可以為資源訪問成功，即頁面可以正常打開對應的狀態(tài)碼，如：狀態(tài)碼為200或302；

所述下載速度閾值可以依據(jù)實際情況進行設定，在一實施例中，所述下載速度閾值可以為200kb/s；

也就是說，本步驟操作通過所述狀態(tài)碼確定所請求頁面無法正常打開時，則相應的故障為資源訪問失敗；確定所請求頁面可以正常打開時，進一步判斷資源下載速度是否小于預設的下載速度閾值，若小于，則確定相應的故障為資源訪問速度慢，若不小于，則確定不存在故障。

步驟304：獲取到所述app的第一功能的故障類型為資源訪問失敗，對所述app的第一功能進行故障檢測，并基于檢測結(jié)果定位所述app的第一功能的故障原因。

在本發(fā)明實施例中，對所述app的第一功能進行故障檢測，并基于檢測結(jié)果定位所述app的第一功能的故障原因，包括：

基于所述ip地址信息對所述app的第一功能進行第一次ping檢測，確定與所述app的第一功能對應的目標服務器的連通情況；

基于所述url信息、ip地址信息及端口信息對所述app的第一功能進行第二次ping檢測以及trace檢測，得到檢測結(jié)果，所述檢測結(jié)果至少包括丟包率信息及路徑擁堵情況信息；

基于與所述目標服務器的連通情況、所述資源下載速度信息、所述丟包率信息及路徑擁堵情況信息定位所述app的第一功能的故障原因。

進一步的，當所述app的第一功能的故障類型為資源訪問失敗時，所述方法還包括：

基于所述流量數(shù)據(jù)包判斷是否缺少資源訪問成功所需的關鍵元素，所述關鍵元素至少包括html元素及css元素，并依據(jù)判斷結(jié)果定位所述app的第一功能的故障原因。

進一步的，所述方法還包括：基于所述ip地址信息確定所述app的第一功能對應的資源歸屬地信息；

和/或獲取運行app的第一功能對應的數(shù)據(jù)包交換過程信息；

和/或獲取運行app的第一功能對應的中央處理器cpu使用率、內(nèi)存使用率信息；

將所述資源歸屬地信息、和/或所述數(shù)據(jù)包交換過程信息、和/或所述cpu使用率、內(nèi)存使用率信息作為定位所述app的第一功能的故障原因的參考信息。

步驟305：結(jié)束本次處理流程。

實施例四

圖4為本發(fā)明實施例app故障定位裝置的組成結(jié)構示意圖，所述裝置位于終端，如圖4所示，本發(fā)明實施例app故障定位裝置的組成包括：數(shù)據(jù)包獲取模塊41、信息提取模塊42、故障判斷模塊43及故障定位模塊44；其中，

所述數(shù)據(jù)包獲取模塊41，用于獲取運行app的第一功能對應的流量數(shù)據(jù)包；

所述信息提取模塊42，用于提取所述流量數(shù)據(jù)包中資源相關信息及app交互特征信息；

所述故障判斷模塊43，用于基于所述資源相關信息及app交互特征信息判斷所述app的第一功能是否存在故障，確定所述app的第一功能存在故障時，獲取相應的故障類型；

所述故障定位模塊44，用于基于所述app交互特征信息及所述故障類型對所述app的第一功能進行故障檢測，并基于檢測結(jié)果定位所述app的第一功能的故障原因。

在一實施例中，所述資源相關信息至少包括狀態(tài)碼，所述app交互特征信息至少包括：響應時間信息及資源大小信息；

所述故障判斷模塊43，還用于將所述狀態(tài)碼與預設的第一狀態(tài)碼進行匹配，匹配成功時，確定所述app的第一功能存在故障，且相應的故障類型為資源訪問失??；

匹配失敗時，將所述狀態(tài)碼與預設的第二狀態(tài)碼進行匹配，匹配成功時，依據(jù)所述響應時間信息及資源大小信息確定相應的資源下載速度，當所述資源下載速度小于預設的下載速度閾值時，確定所述app的第一功能存在故障，且相應的故障類型為資源訪問速度慢。

在一實施例中，所述app交互特征信息還包括url信息、ip地址信息及端口信息；

所述app的第一功能的故障類型為資源訪問失敗時，所述故障定位模塊44，還用于基于所述url信息、ip地址信息及端口信息對所述app的第一功能進行ping檢測及trace檢測，得到檢測結(jié)果，所述檢測結(jié)果至少包括丟包率信息及路徑擁堵情況信息，基于所述丟包率信息及路徑擁堵情況信息定位所述app的第一功能的故障原因。

在一實施例中，所述app交互特征信息還包括url信息、ip地址信息及端口信息；

所述app的第一功能的故障類型為資源訪問速度慢時，所述故障定位模塊44，還用于基于所述ip地址信息對所述app的第一功能進行第一次ping檢測，確定與所述app的第一功能對應的目標服務器的連通情況；

基于所述url信息、ip地址信息及端口信息對所述app的第一功能進行第二次ping檢測以及trace檢測，得到檢測結(jié)果，所述檢測結(jié)果至少包括丟包率信息及路徑擁堵情況信息；

基于與所述目標服務器的連通情況、所述資源下載速度信息、所述丟包率信息及路徑擁堵情況信息定位所述app的第一功能的故障原因。

在一實施例中，所述裝置還包括處理模塊45，用于基于所述ip地址信息確定所述app的第一功能對應的資源歸屬地信息；

和/或獲取運行app的第一功能對應的數(shù)據(jù)包交換過程信息；

和/或獲取運行app的第一功能對應的cpu使用率、內(nèi)存使用率信息；

將所述資源歸屬地信息、和/或所述數(shù)據(jù)包交換過程信息、和/或所述cpu使用率、內(nèi)存使用率信息作為定位所述app的第一功能的故障原因的參考信息。

在本發(fā)明實施例中，所述app故障定位裝置中的數(shù)據(jù)包獲取模塊41、信息提取模塊42、故障判斷模塊43、故障定位模塊44及處理模塊45均可由終端中的中央處理器(cpu，centralprocessingunit)或數(shù)字信號處理器(dsp，digitalsignalprocessor)、或現(xiàn)場可編程門陣列(fpga，fieldprogrammablegatearray)、或集成電路(asic，applicationspecificintegratedcircuit)實現(xiàn)。

這里需要指出的是：以上涉及app故障定位裝置的描述，與上述方法描述是類似的，同方法的有益效果描述，不做贅述。對于本發(fā)明所述app故障定位裝置實施例中未披露的技術細節(jié)，請參照本發(fā)明方法實施例的描述。

以上所述，僅為本發(fā)明較佳實施例而已，并非用于限定本發(fā)明的保護范圍。