本發(fā)明涉及計算機技術(shù)領(lǐng)域，特別涉及一種軟件異常檢測方法及裝置。

背景技術(shù)：

計算機技術(shù)的蓬勃發(fā)展，極大地豐富了人們的日常生活，這使得越來越多的用戶開始使用平板電腦、筆記本電腦或手機等設備從事上網(wǎng)活動，諸如通過安裝的軟件進行網(wǎng)頁瀏覽、視頻觀看、聊天交友等。眾所周知，在使用軟件上網(wǎng)過程中，由于受到軟件自身因素或硬盤故障、內(nèi)存故障等外部因素的影響，常常會出現(xiàn)軟件異常不能正常使用的情況。其中，大多數(shù)情況下造成軟件異常的原因是軟件自身出現(xiàn)了問題，因此時下在對軟件異常進行檢測時，首先且主要檢測軟件中是否存在異常文件。

在軟件發(fā)生異常的場景下，終端進行軟件異常檢測時目前通常直接采取單一檢測方式。以數(shù)字簽名檢驗的檢測方式為例，對于該軟件的每一個文件來說，軟件網(wǎng)站在發(fā)布該軟件之前均用一個哈希函數(shù)從文件的文本中生成摘要，然后用密鑰對這個摘要進行了加密，這個加密后的摘要將作為該文件的數(shù)字簽名和該文件一起發(fā)送給終端；這樣終端在對該文件進行異常檢測時，首先用與軟件網(wǎng)站一樣的哈希函數(shù)從接收到的文件中計算出摘要，接著再用軟件網(wǎng)站的公用密鑰來對該文件附加的數(shù)字簽名進行解密；如果這兩個摘要相同，那么終端確定該文件未發(fā)生異常。以MD5(Message Digest Algorithm MD5，消息摘要算法第五版)校驗的檢測方式為例，其中一個軟件通常由若干個文件組成，對于該軟件中的一個文件，根據(jù)從軟件網(wǎng)站獲取的與該軟件匹配的校驗碼對該文件進行MD5運算，得到計算結(jié)果；之后將得到的計算結(jié)果與上述校驗碼進行比較；如果上述計算結(jié)果與上述校驗碼一致，則證明該文件完整無誤，未發(fā)生異常。依次類推，完成對該軟件中所有文件的檢測。若該軟件中出現(xiàn)了異常文件，則表明出現(xiàn)的軟件異常情況是由這些異常文件引起的。

在實現(xiàn)本發(fā)明的過程中，發(fā)明人發(fā)現(xiàn)現(xiàn)有技術(shù)至少存在以下問題：

由于在軟件發(fā)生異常的場景下采取單一檢測方式對軟件異常進行檢測，因此檢測方式較為單一，不夠靈活，功能局限，智能性欠佳，效果不好。

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

為了解決現(xiàn)有技術(shù)的問題，本發(fā)明實施例提供了一種軟件異常檢測方法及裝置。所述技術(shù)方案如下：

一方面，提供了一種軟件異常檢測方法，所述方法包括：

在軟件運行正常時，若檢測到終端當前處于資源空閑狀態(tài)，則基于至少兩個檢測算法，對所述軟件包含的至少一個文件進行異常檢測；

在所述軟件發(fā)生異常時，確定所述軟件發(fā)生異常時的崩潰進程，獲取所述崩潰進程的調(diào)用棧，所述調(diào)用棧記錄了所述崩潰進程調(diào)用的文件，若所述調(diào)用的文件中存在屬性信息錯誤的文件，則確定所述崩潰進程調(diào)用的文件中存在異常文件，基于所述至少兩個檢測算法，對所述軟件包含的至少一個文件進行異常檢測。

另一方面，提供了一種軟件異常檢測裝置，所述裝置包括：

檢測模塊，用于在軟件運行正常時，若檢測到終端當前處于資源空閑狀態(tài)，則基于至少兩個檢測算法，對所述軟件包含的至少一個文件進行異常檢測；

第一確定模塊，用于在所述軟件發(fā)生異常時，確定所述軟件發(fā)生異常時的崩潰進程；

第一獲取模塊，用于獲取所述崩潰進程的調(diào)用棧，所述調(diào)用棧記錄了所述崩潰進程調(diào)用的文件；

第二確定模塊，用于在所述調(diào)用的文件中存在屬性信息錯誤的文件時，確定所述崩潰進程調(diào)用的文件中存在異常文件；

所述檢測模塊，還用于在確定所述崩潰進程調(diào)用的文件中存在異常文件時，基于所述至少兩個檢測算法，對所述軟件包含的至少一個文件進行異常檢測。

本發(fā)明實施例提供的技術(shù)方案帶來的有益效果是：

在軟件運行正常和異常的不同場景下采取不同的策略對軟件包含的文件進行異常檢測，且異常檢測過程基于至少兩個檢測算法，因此檢測方式多樣，較為靈活，功能豐富，智能性較優(yōu)，效果佳。

附圖說明

為了更清楚地說明本發(fā)明實施例中的技術(shù)方案，下面將對實施例描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的一些實施例，對于本領(lǐng)域普通技術(shù)人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據(jù)這些附圖獲得其他的附圖。

圖1A是本發(fā)明實施例提供的一種軟件異常檢測方法所涉及的實施環(huán)境架構(gòu)圖；

圖1B是本發(fā)明實施例提供的一種軟件異常檢測方法的流程圖；

圖1C是本發(fā)明實施例提供的另一種軟件異常檢測方法的流程圖；

圖1D是本發(fā)明實施例提供的一種軟件異常檢測的過程示意圖；

圖2A是本發(fā)明實施例提供的一種軟件異常檢測裝置的結(jié)構(gòu)示意圖；

圖2B是本發(fā)明實施例提供的另一種軟件異常檢測裝置的結(jié)構(gòu)示意圖；

圖2C是本發(fā)明實施例提供的另一種軟件異常檢測裝置的結(jié)構(gòu)示意圖；

圖2D是本發(fā)明實施例提供的另一種軟件異常檢測裝置的結(jié)構(gòu)示意圖；

圖2E是本發(fā)明實施例提供的另一種軟件異常檢測裝置的結(jié)構(gòu)示意圖；

圖2F是本發(fā)明實施例提供的另一種軟件異常檢測裝置的結(jié)構(gòu)示意圖；

圖3是本發(fā)明實施例提供的一種終端的結(jié)構(gòu)示意圖。

具體實施方式

為使本發(fā)明的目的、技術(shù)方案和優(yōu)點更加清楚，下面將結(jié)合附圖對本發(fā)明實施方式作進一步地詳細描述。

在對本發(fā)明實施例進行詳細地解釋說明之前，先對本發(fā)明實施例可能涉及到的名詞進行解釋。

數(shù)字簽名：又稱公鑰數(shù)字簽名、電子簽章，是一種類似寫在紙上的普通的物理簽名，但是使用了公鑰加密領(lǐng)域的技術(shù)實現(xiàn)的用于鑒別數(shù)字信息的方法。數(shù)字簽名，即是只有文件的發(fā)送方才能產(chǎn)生別人無法偽造的一段數(shù)字串，這段數(shù)字串同時也是對文件的發(fā)送方發(fā)送文件真實性的一個有效證明。簡單地說，所謂數(shù)字簽名就是附加在文件上的一些數(shù)據(jù)，或是對文件所作的密碼變換。這種數(shù)據(jù)或變換允許接收方用以確認文件的來源和文件的完整性，防止被人進行偽造。

詳細地簽名過程為：發(fā)送文件時，發(fā)送方用一個哈希函數(shù)從文件的文本中生成摘要，然后用自己的私人密鑰對這個摘要進行加密，這個加密后的摘要將作為該文件的數(shù)字簽名和該文件一起發(fā)送給接收方；接收方首先用與發(fā)送方一樣的哈希函數(shù)從接收到的原始文件中計算出摘要，接著再用發(fā)送方的公用密鑰來對該文件附加的數(shù)字簽名進行解密；如果這兩個摘要相同，那么接收方確認該數(shù)字簽名是發(fā)送方的，即校驗該數(shù)字簽名正確，否則校驗該數(shù)字簽名錯誤。其中，數(shù)字簽名有兩種功效：一是能確定文件確實是由發(fā)送方簽名并發(fā)出來的，因為別人假冒不了發(fā)送方的簽名。二是數(shù)字簽名能確定文件的完整性。因為數(shù)字簽名的特點是它代表了文件的特征，文件如果發(fā)生改變，摘要的值也將發(fā)生變化。其中，針對本發(fā)明實施例來說，發(fā)送方指代軟件網(wǎng)站，接收方指代終端。

此外，由于微軟提供的底層函數(shù)存在不穩(wěn)定性，校驗結(jié)果可能存在不準確的問題，即存在以下問題：如果校驗函數(shù)返回的結(jié)果是校驗通過，則文件一定是正確的。如果校驗函數(shù)返回的結(jié)果是校驗錯誤，則既可能是文件存在異常，也可能是接收方的計算機證書存在異常，而并非文件異常。

MD5(Message Digest Algorithm MD5，消息摘要算法第五版)檢驗：為計算機安全領(lǐng)域廣泛使用的一種散列函數(shù)，用以提供文件的完整性保護，將文件運算為另一固定長度值，是雜湊算法的基礎原理。MD5具有壓縮性，容易計算，抗修改性，強抗撞擊等特點。其中，MD5的校驗原理為：接收方接收到發(fā)送方發(fā)送的一個文件，同時發(fā)送方在發(fā)送這個文件時，還會發(fā)送一個檢驗碼；之后對這個文件做MD5運算，若得到的計算結(jié)果與接收到的校驗碼一致，則證明這個文件未發(fā)生異常。MD5校驗算法的檢測準確度要大于數(shù)字簽名校驗算法。

圖1A是本發(fā)明實施例提供的一種軟件異常檢測方法所涉及的實施環(huán)境架構(gòu)圖。參見圖1A，該架構(gòu)中包括終端11和服務器12。其中，終端11除了可為手機、平板電腦等移動終端外，還可為個人計算機等固定終端，本發(fā)明實施例對終端11的類型不進行具體限定。以終端11上安裝的安全管理軟件為例，終端11在不同場景下采取不同的策略進行軟件異常檢測：在該安全管理軟件運行正常時，若終端11檢測到當前自身處于資源空閑狀態(tài)，則基于至少兩個檢測算法，對該安全管理軟件包含的全部文件進行異常檢測；在該安全管理軟件發(fā)生異常時，若終端11檢測到該安全管理軟件的崩潰進程調(diào)用的文件中存在異常文件，則基于至少兩個檢測算法，對該安全管理軟件包含的全部文件進行異常檢測。服務器12可向終端11提供該安全管理軟件的任何可更新版本的安裝包，其中該安裝包既可以是該安全管理軟件整體的全量升級包，也可以是針對該安全管理軟件中部分文件的增量升級包。關(guān)于軟件異常檢測的詳細實施方式請參見下述實施例。

圖1B是本發(fā)明實施例提供的一種軟件異常檢測方法的流程圖。以圖1A所示的終端執(zhí)行軟件異常檢測方法為例，參見圖1B，本發(fā)明實施例提供的方法流程包括：

101、在啟動一個軟件后，判斷該軟件是否運行正常；若該軟件運行正常，則執(zhí)行下述步驟102；若該軟件發(fā)生異常，則執(zhí)行下述步驟103。

在本發(fā)明實施例中，為了快速解決終端上軟件異常的問題，實現(xiàn)軟件的自我修復，提出了基于主動策略和被動策略的兩種軟件異常檢測和修復方式。其中，在軟件正常運行時執(zhí)行主動策略，在軟件發(fā)生異常時執(zhí)行被動策略。其中，軟件正常運行時軟件所提供的全部功能用戶均可使用，在軟件發(fā)生異常時，軟件處于崩潰(Crash)狀態(tài)，軟件所提供的功能不可使用。其中，在判斷一個軟件是否正常運行時，可采取下述幾種方式實現(xiàn)：判斷該軟件的啟動進程是否處于運行狀態(tài)；若該啟動進程處于不可運行狀態(tài)，則確定該軟件發(fā)生異常；或者，由于時下一般的軟件在發(fā)生異常時均會向用戶報錯或生成異常日志，因此可通過檢測該軟件的報錯信息或者異常日志來確定該軟件是否運行正常。若該軟件當前生成了報錯信息或異常日志，則確定該軟件發(fā)生異常；或者，在該軟件成功啟動后，判斷該軟件的任一功能所涉及的進程是否可正常運行；若某一功能所涉及的進程可正常運行，則確定該軟件發(fā)生正常。

102、若該軟件運行正常，則檢測終端當前是否處于資源空閑狀態(tài)；若檢測到終端當前處于資源空閑狀態(tài)，則基于至少兩個檢測算法，對該軟件包含的全部文件進行異常檢測。

在本發(fā)明實施例中，主動策略用戶的感知度低，不影響用戶平時正常使用終端。基于此，當該軟件在終端上正常運行的時候，該軟件會自動執(zhí)行一個定時任務，實時檢測終端的使用情況。如果終端當前處于資源空閑狀態(tài)，即終端的CPU(Central Processing Unit，中央處理單元)或內(nèi)存等部件的使用率較低，比如低于一個預設閾值，且與終端適配的鍵盤或鼠標等輸入設備均處于無輸入狀態(tài)，則執(zhí)行對該軟件的異常檢測邏輯，即基于至少兩個檢測算法，對該軟件包含的全部文件進行異常檢測，也即，對該軟件包括的每一個文件進行完整性校驗，以確定每一個文件是否有損壞。其中，該預設閾值可為10％或20％等等，其取值可以維持終端正常運行時的最低使用率為準。需要說明的是，在主動策略下執(zhí)行異常檢測邏輯時，針對的是該軟件包含的每一個文件，且這個異常檢測過程需采用低系統(tǒng)優(yōu)先級執(zhí)行，以最大限度地減少對終端的系統(tǒng)資源的占用。

此外，當該軟件運行正常時，在對該軟件包含的全部文件進行異常檢測的過程中，若尚未發(fā)現(xiàn)異常文件且終端由資源空閑狀態(tài)轉(zhuǎn)變?yōu)橘Y源繁忙狀態(tài)，則終止進行異常檢測；當終端再次處于資源空閑狀態(tài)時，繼續(xù)對全部文件中未被檢測的文件進行異常檢測。換句話說，在主動策略下執(zhí)行異常檢測邏輯時，如果尚未在該軟件包含的全部文件中發(fā)現(xiàn)異常文件，則這個異常檢測邏輯可以被用戶隨時打斷，比如當用戶的鼠標或鍵盤等輸入設備存在輸入時，則確定終端處于資源繁忙狀態(tài)，異常檢測邏輯的執(zhí)行進度終止。尋找下次終端處于資源空閑狀態(tài)時，繼續(xù)對執(zhí)行進度終止之前未進行檢測的文件進行異常檢測，或者重新執(zhí)行一個新的異常檢測邏輯從頭對該軟件包括的全部文件進行異常檢測。

進一步地，當該軟件運行正常時，在對該軟件包含的全部文件進行異常檢測的過程中，如果已經(jīng)發(fā)現(xiàn)該軟件中存在異常文件的情況，則該軟件在后續(xù)運行過程中，發(fā)生異常的概率較大，則用戶的鼠標、鍵盤等輸入設備的輸入不會影響異常檢測邏輯的執(zhí)行進度，因此即便在檢測到用戶的鼠標、鍵盤等輸入設備存在輸入的情況下，異常檢測邏輯也將持續(xù)完成。

其中，在基于至少兩個檢測算法，對該軟件包含的全部文件進行異常檢測時，通常采取下述方式實現(xiàn)：采用第一檢測算法，在全部文件中確定不存在異常的第一文件；采用檢測準確度大于第一檢測算法的第二檢測算法，在第二文件中確定存在異常的第二文件，其中第二文件為全部文件中除第一文件之外的其他文件；將第二文件確定為異常文件。

在本發(fā)明實施例中，第一檢測算法指代數(shù)字簽名校驗算法，第二檢測算法指代MD5校驗算法，由于數(shù)字簽名校驗算法檢測正常的文件一定正常，而檢測異常的文件則不一定異常，因此本發(fā)明實施例采用第一檢測算法判白，即僅采用第一檢測算法在該軟件包含的全部文件中確定不存在異常的第一文件，對于第一文件來說一定是不存在任何異常的正常文件。除了第一文件之外的全部文件中剩余的文件，第一檢測算法則確定為異常文件，由于第一檢測算法的精準度有限，因此剩余的文件中可能包含有真正異常的文件和誤判為異常的文件。因此接下來，采用檢測準確度大于數(shù)字簽名校驗算法的MD5校驗算法對全部文件中除了第一文件之外的第二文件進行異常檢測，此時本發(fā)明實施例采用第二檢測算法判黑，即采用第二檢測算法在第二文件中確定異常文件。此外，在檢測到一個異常文件后，會實時將該文件存入一個待修復文件列表中，以等待下一步的修復過程。

在另一個實施例中，在確定該軟件中的異常文件后，本發(fā)明實施例還會執(zhí)行進一步檢測邏輯，其中執(zhí)行進一步檢測邏輯還需獲取異常文件的屬性信息。其中，異常文件的屬性信息包括文件版本信息、文件修改日期等，本發(fā)明實施例對此不進行具體限定。其中，根據(jù)文件的屬性信息可確定異常文件的異常原因。比如，在文件版本信息未發(fā)生變化的場景下，可通過判斷異常文件的修改日期來確定異常原因。示例來說，假設一個軟件的版本信息是V1.1，則安裝該軟件釋放文件時，文件的版本信息也應是V1.1，若一個異常文件最近一次的修改日期為11月8號12:00，此時該軟件的當前版本信息為V1.1，而在10月8號12:00時該軟件的版本信息和該異常文件的版本信息同樣為V1.1，則基于上述情況可知該文件異常的原因很大程度上可能是被惡意篡改了。在文件版本信息發(fā)生變化的場景下，繼續(xù)以上述例子為例，如果上述異常文件的當前版本信息為V2.3，則該異常文件在軟件安裝后應該是被執(zhí)行過升級，比如執(zhí)行過升級的時間是在10月8號之后的11月份，使得上述異常文件由V1.1升級到V2.3，而此時該軟件的當前版本信息仍然為V1.1，因此該文件出現(xiàn)異常的原因很大程度上可能是升級過程導致的。

其中，還可根據(jù)屬性信息中包括的文本版本信息進一步執(zhí)行異常文件的修復策略。當異常文件的當前版本信息與該軟件的當前版本信息不一致時，則確定異常文件的異常原因是出現(xiàn)了文件版本信息異常，會將該文件版本信息異常情況一并存入上述待修復文件列表中，以等待修復工具基于文件版本信息異常情況執(zhí)行不同于文件版本信息正常時的修復策略。具體地修復過程請參見下述步驟104。此外，在該軟件中存在異常文件的情況下，本發(fā)明實施例還包括對終端的內(nèi)存以及硬盤進行故障檢測的步驟，以確定文件異常原因是否由終端的內(nèi)存以及硬盤故障引起，因為在內(nèi)存或硬盤故障的情況下數(shù)據(jù)讀寫很大程度上會出現(xiàn)錯誤，從而導致文件異常；在得到對內(nèi)存以及硬盤進行故障檢測的檢測結(jié)果后，將檢測結(jié)果保存在本地，此外上述異常原因也可同該檢測結(jié)果一并保存在本地。另外，還可對異常文件執(zhí)行文件錯誤類型的判定，并將得到的判定結(jié)果保存在本地。本發(fā)明實施例對進一步檢測邏輯涉及的檢測種類不進行限定。

103、若該軟件發(fā)生異常，則確定軟件發(fā)生異常時的崩潰進程，獲取崩潰進程的調(diào)用棧，若該調(diào)用棧記錄的崩潰進程調(diào)用的文件中存在屬性信息錯誤的文件，確定檢測到該軟件的崩潰進程調(diào)用的文件中存在異常文件，則基于至少兩個檢測算法，對軟件包含的全部文件進行異常檢測。

在本發(fā)明實施例中，若如果該軟件的文件異常，并導致該軟件崩潰，則在該軟件崩潰之后，該軟件會自動調(diào)用異常上報工具來上報及分析軟件異常，并在檢測到該軟件的崩潰進程調(diào)用的文件中存在異常文件后，調(diào)用檢測工具對該軟件包括的全部文件進行異常檢測，即調(diào)用檢測工具，基于至少兩個檢測算法，對該軟件包含的全部文件進行異常檢測。其中，異常上報工具指代Bugreport工具。其中，Bugreport工具本質(zhì)上是一個進程文件，時下很多的軟件中均包括這一工具，在軟件的安裝文件夾中便可查找到。這一工具的主要作用是對軟件出錯返回報告，一旦其所屬軟件運行錯誤導致軟件崩潰，Bugreport工具便會將發(fā)生的錯誤以電子郵件等方式發(fā)送回服務器。其中，Bugreport工具在檢測該軟件的崩潰進程調(diào)用的文件中存在異常文件時，通常采取下述方式實現(xiàn)：確定該軟件發(fā)生異常時的崩潰進程；獲取崩潰進程的調(diào)用棧，其中調(diào)用棧中記錄了崩潰進程調(diào)用的文件；若調(diào)用的文件中存在屬性信息錯誤的文件，則確定崩潰進程調(diào)用的文件中存在異常文件。

即，Bugreport工具通過微軟提供的底層函數(shù)接口，分析該軟件的崩潰進程的調(diào)用棧，其中該調(diào)用棧中記錄了崩潰進程在未發(fā)生崩潰之前運行正常時調(diào)用的文件。進一步，Bugreport工具分析上述調(diào)用的文件的屬性信息，其中屬性信息可包括文件路徑、文件名、文件的數(shù)字簽名、文件MD5值，文件版本號、文件修改時間等，本發(fā)明實施例對此不進行具體限定。在本發(fā)明實施例中，通過對調(diào)用的文件進行數(shù)字簽名快速判定，確定上述調(diào)用的文件中是否存在異常文件，即判定上述調(diào)用的文件中是否存在受損的文件。其中，如果一個調(diào)用的文件的數(shù)字簽名錯誤，則該文件具有很高的概率受損，則Bugreport工具確定崩潰進程調(diào)用的文件中存在異常文件，會以最高系統(tǒng)優(yōu)先級調(diào)用檢測工具，而文件檢測工具也同樣采用最高系統(tǒng)優(yōu)先級執(zhí)行異常檢測邏輯，也即通過采取與上述步驟102類似的方式在該軟件包括的全部文件中確定異常文件，在確定異常文件后，后續(xù)修復工具也會采用最高系統(tǒng)優(yōu)先級執(zhí)行修復邏輯，以確保終端上的異常文件被及時修復。

針對被動策略來說，在檢測到一個異常文件后，也會實時將該文件存入一個待修復文件列表中，以等待下一步的修復過程。其中，進一步檢測邏輯同上述步驟102類似，本發(fā)明實施例對此不進行具體限定。

在軟件發(fā)生異常的場景下，在調(diào)用異常上報工具對崩潰進程調(diào)用的文件進行檢測后；如果崩潰進程調(diào)用的文件中存在異常文件，則導致進程崩潰，進而導致軟件異常的原因很有可能由文件出現(xiàn)異常引起的。因此如上述步驟103所示還需調(diào)用檢測工具，基于至少兩個檢測算法對該軟件包含的全部文件進行異常檢測。之所以調(diào)用檢測工具進行全部文件的檢測是因為：一方面異常上報工具的檢測精準度不是特別高，因此還需采用檢測工具對崩潰進程調(diào)用的文件進行再次檢測。

另一方面，除了崩潰進程調(diào)用的文件之外，其他文件中還有可能存在潛在的可能引起軟件異常的文件，因此需要針對全部文件進行檢測。在另一個實施例中，如果崩潰進程調(diào)用的文件中沒有一個文件異常，則導致進程崩潰，進而導致軟件異常的原因基本上可以確定不是由文件出現(xiàn)異常引起的。此時的軟件異常情況很有可能是由于軟件或崩潰進程本身有bug(缺陷)存在，或者軟件當前的運行環(huán)境有問題存在，比如操作系統(tǒng)出現(xiàn)故障，或者終端的內(nèi)存或硬盤等方面出現(xiàn)了故障，針對這一情況，終端此時可向服務器上報當前的問題現(xiàn)場，或者在對上述可能造成軟件異常的情形進行相關(guān)檢測后，比如在進行內(nèi)存故障檢測或硬盤故障檢測后，將檢測結(jié)果上報給服務器，進而服務器在接收到終端上報的上述異常信息后，由服務器根據(jù)問題現(xiàn)場或接收到的檢測結(jié)果對軟件發(fā)生異常的原因進行進一步地分析。

本發(fā)明實施例提供的方法，在軟件運行正常和異常的不同場景下采取不同的策略對軟件包含的文件進行異常檢測，且異常檢測過程基于至少兩個檢測算法，因此檢測方式多樣，較為靈活，功能豐富，智能性較優(yōu)，效果佳。

圖1C是本實施例提供的一種軟件異常檢測方法，該方法在基于上述圖1B提供的軟件異常檢測方法檢測到異常情況后，還支持對異常文件進行修復的過程。以圖1A所示的終端執(zhí)行軟件異常檢測方法為例，參見圖1C，本發(fā)明實施例提供的方法流程包括：

111、在啟動一個軟件后，判斷該軟件是否運行正常；若該軟件運行正常，則執(zhí)行下述步驟112；若該軟件發(fā)生異常，則執(zhí)行下述步驟113。

該步驟111同上述圖1B中所示實施例的步驟101，具體參見上述內(nèi)容，此處不再贅述。

112、若該軟件運行正常，則檢測終端當前是否處于資源空閑狀態(tài)；若檢測到終端當前處于資源空閑狀態(tài)，則基于至少兩個檢測算法，對該軟件包含的全部文件進行異常檢測。

該步驟112同上述圖1B中所示實施例的步驟102，具體參見上述內(nèi)容，此處不再贅述。

113、若該軟件發(fā)生異常，則確定軟件發(fā)生異常時的崩潰進程，獲取崩潰進程的調(diào)用棧，若該調(diào)用棧記錄的崩潰進程調(diào)用的文件中存在屬性信息錯誤的文件，確定檢測到該軟件的崩潰進程調(diào)用的文件中存在異常文件，則基于至少兩個檢測算法，對軟件包含的全部文件進行異常檢測。

該步驟113同上述圖1B中所示實施例的步驟103，具體參見上述內(nèi)容，此處不再贅述。

114、對該軟件的異常文件進行修復。

針對主動策略來說，若在該軟件運行正常時檢測到全部文件中存在異常文件，且異常文件未導致軟件發(fā)生異常，則在對軟件中每一個文件進行異常檢測結(jié)束時，采用第一系統(tǒng)優(yōu)先級，對異常文件進行修復。針對被動策略來說，若在軟件發(fā)生異常時檢測到全部文件中存在異常文件，則在對軟件中每一個文件進行異常檢測結(jié)束時，采用第二系統(tǒng)優(yōu)先級，對異常文件進行修復；其中，第一系統(tǒng)優(yōu)先級的級別低于第二系統(tǒng)優(yōu)先級。比如，第一系統(tǒng)優(yōu)先級可為最低系統(tǒng)優(yōu)先級，而第二系統(tǒng)優(yōu)先級可為最高系統(tǒng)優(yōu)先級。即，在檢測到異常文件且并未導致軟件發(fā)生異常時，采用主動修復方式，可以慢慢執(zhí)行修復過程。該種主動修復方式的用戶感知度低，不影響用戶平時正常使用軟件；而當軟件因為文件異常而發(fā)生崩潰時，采用被動修復方式，需要對異常文件立即執(zhí)行修復過程，使得軟件盡快恢復正常運行。該種被動修復方式可以快速定位問題，提高軟件運行的穩(wěn)定性。需要說明的是，如果在軟件運行正常過程中，該軟件突然因為文件異常發(fā)生崩潰，則立即由主動策略跳轉(zhuǎn)為被動策略，執(zhí)行異常檢測邏輯以及修復邏輯。

在本發(fā)明實施例中，在對異常文件進行修復時，可采取下述方式實現(xiàn)：

情況一、文件版本信息未異常。若異常文件的當前版本信息與軟件的當前軟件版本信息一致，則在本地備份的該軟件的安裝包文件中，獲取與該異常文件同名的第一替換文件，以第一替換文件替換該異常文件。

情況二、文件版本信息異常。若異常文件的當前版本信息與軟件的當前軟件版本信息不一致，則從服務器獲取與該異常文件同名且版本最新的第二替換文件，以第二替換文件替換該異常文件。針對這種情況，證明在該軟件的軟件版本最后一次更新之后，該軟件包括的全部文件中有部分文件進行了模塊升級，因此從服務器中獲取與該異常文件同名且版本最新的文件替換異常文件，即采取模塊升級整體回滾的方式執(zhí)行修復過程。

在另一個實施例中，對異常文件的修復過程采取嘗試后重啟的方式，也即先嘗試替換文件，如果異常文件存在被占用等情況，則異常文件暫時無法被替換，此時對異常文件進行修復失敗，則等待終端執(zhí)行重啟操作；若之后的某一時刻檢測到終端執(zhí)行了重啟操作，則在重啟過程中再次執(zhí)行對異常文件進行修復的過程。

在另一個實施例中，在修復工具執(zhí)行完畢上述對異常文件的修復過程后，還可執(zhí)行該軟件的版本升級或該軟件中任一文件的版本升級。即，在對異常文件修復完畢后，檢測該軟件或該軟件中包含的任一文件是否存在可更新版本；若該軟件存在可更新版本，則從服務器獲取可更新版本的軟件安裝包，并根據(jù)軟件安裝包對該軟件進行升級；若任一文件存在可更新版本，則從服務器獲取可更新版本的文件安裝包，并根據(jù)文件安裝包對任一文件進行升級。

基于上述軟件異常檢測及修復過程，本實施例提供的方法可以圖1D進行概括說明。如圖1D所示，軟件啟動后，判斷該軟件是否運行正常，如果軟件運行正常，并在資源空閑時，對軟件執(zhí)行異常文件的檢測邏輯；如果軟件運行異常，啟動Bugreport工具檢測軟件的崩潰進程調(diào)用的文件中是否存在異常文件，如果崩潰進程調(diào)用的文件中存在異常文件，則對軟件執(zhí)行異常文件的檢測邏輯。無論是在上述哪種場景下對軟件執(zhí)行異常文件的檢測邏輯，在檢測到文件破壞等異常后，執(zhí)行修復過程。

本發(fā)明實施例提供的方法，在軟件運行正常和異常的不同場景下采取不同的策略對軟件包含的文件進行異常檢測，且異常檢測過程基于至少兩個檢測算法，因此檢測方式多樣，較為靈活，功能豐富，智能性較優(yōu)，效果佳。

另外，在檢測到異常文件后，通過針對異常文件對軟件的不同影響情況，采用不同的修復方式對異常文件進行修復，可進一步提高軟件運行的穩(wěn)定性。

本發(fā)明實施例提供了一種軟件異常檢測裝置的結(jié)構(gòu)示意圖。

參見圖2A，該裝置包括：

檢測模塊201，用于在軟件運行正常時，若檢測到終端當前處于資源空閑狀態(tài)，則基于至少兩個檢測算法，對軟件包含的全部文件進行異常檢測。

參見圖2B，該裝置包括：

第一確定模塊202，用于在所述軟件發(fā)生異常時，確定所述軟件發(fā)生異常時的崩潰進程；

第一獲取模塊203，用于獲取所述崩潰進程的調(diào)用棧，所述調(diào)用棧記錄了所述崩潰進程調(diào)用的文件；

第二確定模塊204，用于在所述調(diào)用的文件中存在屬性信息錯誤的文件時，確定所述崩潰進程調(diào)用的文件中存在異常文件；

檢測模塊201，還用于在確定所述崩潰進程調(diào)用的文件中存在異常文件時，基于至少兩個檢測算法，對軟件包含的全部文件進行異常檢測。

在另一個實施例中，檢測模塊201，基于至少兩個檢測算法，對所述軟件全部文件進行異常檢測時，用于采用第一檢測算法，在全部文件中確定不存在異常的第一文件；采用檢測準確度大于第一檢測算法的第二檢測算法，在第二文件中確定存在異常的文件，第二文件為全部文件中除第一文件之外的其他文件；將存在異常的文件確定為異常文件。

在另一個實施例中，參見圖2C，該裝置還包括：

上報模塊205，用于確定所述軟件發(fā)生異常時的崩潰進程之后，若未檢測到所述軟件的崩潰進程調(diào)用的文件中存在異常文件，則上報異常信息。

在另一個實施例中，參見圖2D，該裝置還包括：

修復模塊206，用于若在軟件運行正常時檢測到全部文件中存在異常文件，且異常文件未導致軟件發(fā)生異常，則在對軟件中每一個文件進行異常檢測結(jié)束時，采用第一系統(tǒng)優(yōu)先級，對異常文件進行修復；

修復模塊206，還用于若在軟件發(fā)生異常時檢測到全部文件中存在異常文件，則在對軟件中每一個文件進行異常檢測結(jié)束時，采用第二系統(tǒng)優(yōu)先級，對異常文件進行修復；

其中，第一系統(tǒng)優(yōu)先級的級別低于第二系統(tǒng)優(yōu)先級。

在另一個實施例中，參見圖2E，該裝置還包括：

第二獲取模塊207，用于在確定全部文件中的異常文件后，獲取異常文件的屬性信息；

第三確定模塊208，用于根據(jù)屬性信息，確定異常文件的異常原因；

檢測模塊201，還用于對終端的內(nèi)存以及硬盤進行故障檢測，得到檢測結(jié)果；保存模塊209，用于將異常原因和檢測結(jié)果保存在本地。

在另一個實施例中，修復模塊206，用于判斷異常文件的屬性信息中的當前版本信息與軟件的當前軟件版本信息是否一致；若異常文件的當前版本信息與軟件的當前軟件版本信息一致，則在本地備份的軟件的安裝包文件中，獲取與異常文件同名的第一替換文件，以第一替換文件替換異常文件；若異常文件的當前版本信息與軟件的當前軟件版本信息不一致，則從服務器獲取與異常文件同名且版本最新的第二替換文件，以第二替換文件替換異常文件。

在另一個實施例中，修復模塊206，用于若對異常文件進行修復失敗，則在檢測到終端執(zhí)行重啟操作后，在重啟過程中再次執(zhí)行對異常文件進行修復的過程。

在另一個實施例中，參見圖2F，該裝置還包括：

升級模塊210，還用于檢測軟件或軟件中包含的任一文件是否存在可更新版本；若軟件存在可更新版本，則從服務器獲取可更新版本的軟件安裝包，并根據(jù)軟件安裝包對軟件進行升級；

升級模塊210，還用于若任一文件存在可更新版本，則從服務器獲取可更新版本的文件安裝包，并根據(jù)文件安裝包對任一文件進行升級。

在另一個實施例中，檢測模塊201，還用于當軟件運行正常時，在對軟件包含的全部文件進行異常檢測的過程中，若尚未發(fā)現(xiàn)異常文件且終端由資源空閑狀態(tài)轉(zhuǎn)變?yōu)橘Y源繁忙狀態(tài)，則終止進行異常檢測；當終端再次處于資源空閑狀態(tài)時，繼續(xù)對全部文件中未被檢測的文件進行異常檢測。

本發(fā)明實施例提供的裝置，在軟件運行正常和異常的不同場景下采取不同的策略對軟件包含的文件進行異常檢測，且異常檢測過程基于至少兩個檢測算法，因此檢測方式多樣，較為靈活，功能豐富，智能性較優(yōu)，效果佳。

另外，在檢測到異常文件后，通過針對異常文件對軟件的不同影響情況，采用不同的修復方式對異常文件進行修復，可進一步提高軟件運行的穩(wěn)定性。

需要說明的是：上述實施例提供的軟件異常檢測裝置在檢測軟件異常時，僅以上述各功能模塊的劃分進行舉例說明，實際應用中，可以根據(jù)需要而將上述功能分配由不同的功能模塊完成，即將裝置的內(nèi)部結(jié)構(gòu)劃分成不同的功能模塊，以完成以上描述的全部或者部分功能。另外，上述實施例提供的軟件異常檢測裝置與軟件異常檢測方法實施例屬于同一構(gòu)思，其具體實現(xiàn)過程詳見方法實施例，這里不再贅述。

圖3是本發(fā)明實施例提供的一種終端的結(jié)構(gòu)示意圖，該終端可以用于執(zhí)行上述實施例中提供的軟件異常檢測方法。參見圖3，該終端300包括：

RF(Radio Frequency，射頻)電路110、包括有一個或一個以上計算機可讀存儲介質(zhì)的存儲器120、輸入單元130、顯示單元140、傳感器150、音頻電路160、WiFi(Wireless Fidelity，無線保真)模塊170、包括有一個或者一個以上處理核心的處理器180、以及電源190等部件。本領(lǐng)域技術(shù)人員可以理解，圖3中示出的終端結(jié)構(gòu)并不構(gòu)成對終端的限定，可以包括比圖示更多或更少的部件，或者組合某些部件，或者不同的部件布置。其中：

RF電路110可用于收發(fā)信息或通話過程中，信號的接收和發(fā)送，特別地，將基站的下行信息接收后，交由一個或者一個以上處理器180處理；另外，將涉及上行的數(shù)據(jù)發(fā)送給基站。通常，RF電路110包括但不限于天線、至少一個放大器、調(diào)諧器、一個或多個振蕩器、用戶身份模塊(SIM)卡、收發(fā)信機、耦合器、LNA(Low Noise Amplifier，低噪聲放大器)、雙工器等。此外，RF電路110還可以通過無線通信與網(wǎng)絡和其他設備通信。無線通信可以使用任一通信標準或協(xié)議，包括但不限于GSM(Global System of Mobile communication，全球移動通訊系統(tǒng))、GPRS(General Packet Radio Service，通用分組無線服務)、CDMA(Code Division Multiple Access，碼分多址)、WCDMA(Wideband Code Division Multiple Access,寬帶碼分多址)、LTE(Long Term Evolution,長期演進)、電子郵件、SMS(Short Messaging Service，短消息服務)等。

存儲器120可用于存儲軟件程序以及模塊，處理器180通過運行存儲在存儲器120的軟件程序以及模塊，從而執(zhí)行各種功能應用以及數(shù)據(jù)處理。存儲器120可主要包括存儲程序區(qū)和存儲數(shù)據(jù)區(qū)，其中，存儲程序區(qū)可存儲操作系統(tǒng)、至少一個功能所需的應用程序(比如聲音播放功能、圖像播放功能等)等；存儲數(shù)據(jù)區(qū)可存儲根據(jù)終端300的使用所創(chuàng)建的數(shù)據(jù)(比如音頻數(shù)據(jù)、電話本等)等。此外，存儲器120可以包括高速隨機存取存儲器，還可以包括非易失性存儲器，例如至少一個磁盤存儲器件、閃存器件、或其他易失性固態(tài)存儲器件。相應地，存儲器120還可以包括存儲器控制器，以提供處理器180和輸入單元130對存儲器120的訪問。

輸入單元130可用于接收輸入的數(shù)字或字符信息，以及產(chǎn)生與用戶設置以及功能控制有關(guān)的鍵盤、鼠標、操作桿、光學或者軌跡球信號輸入。具體地，輸入單元130可包括觸敏表面131以及其他輸入設備132。觸敏表面131，也稱為觸摸顯示屏或者觸控板，可收集用戶在其上或附近的觸摸操作(比如用戶使用手指、觸筆等任何適合的物體或附件在觸敏表面131上或在觸敏表面131附近的操作)，并根據(jù)預先設定的程式驅(qū)動相應的連接裝置?？蛇x的，觸敏表面131可包括觸摸檢測裝置和觸摸控制器兩個部分。其中，觸摸檢測裝置檢測用戶的觸摸方位，并檢測觸摸操作帶來的信號，將信號傳送給觸摸控制器；觸摸控制器從觸摸檢測裝置上接收觸摸信息，并將它轉(zhuǎn)換成觸點坐標，再送給處理器180，并能接收處理器180發(fā)來的命令并加以執(zhí)行。此外，可以采用電阻式、電容式、紅外線以及表面聲波等多種類型實現(xiàn)觸敏表面131。除了觸敏表面131，輸入單元130還可以包括其他輸入設備132。具體地，其他輸入設備132可以包括但不限于物理鍵盤、功能鍵(比如音量控制按鍵、開關(guān)按鍵等)、軌跡球、鼠標、操作桿等中的一種或多種。

顯示單元140可用于顯示由用戶輸入的信息或提供給用戶的信息以及終端300的各種圖形用戶接口，這些圖形用戶接口可以由圖形、文本、圖標、視頻和其任意組合來構(gòu)成。顯示單元140可包括顯示面板141，可選的，可以采用LCD(Liquid Crystal Display，液晶顯示器)、OLED(Organic Light-Emitting Diode,有機發(fā)光二極管)等形式來配置顯示面板141。進一步的，觸敏表面131可覆蓋顯示面板141，當觸敏表面131檢測到在其上或附近的觸摸操作后，傳送給處理器180以確定觸摸事件的類型，隨后處理器180根據(jù)觸摸事件的類型在顯示面板141上提供相應的視覺輸出。雖然在圖3中，觸敏表面131與顯示面板141是作為兩個獨立的部件來實現(xiàn)輸入和輸出功能，但是在某些實施例中，可以將觸敏表面131與顯示面板141集成而實現(xiàn)輸入和輸出功能。

終端300還可包括至少一種傳感器150，比如光傳感器、運動傳感器以及其他傳感器。具體地，光傳感器可包括環(huán)境光傳感器及接近傳感器，其中，環(huán)境光傳感器可根據(jù)環(huán)境光線的明暗來調(diào)節(jié)顯示面板141的亮度，接近傳感器可在終端300移動到耳邊時，關(guān)閉顯示面板141和/或背光。作為運動傳感器的一種，重力加速度傳感器可檢測各個方向上(一般為三軸)加速度的大小，靜止時可檢測出重力的大小及方向，可用于識別手機姿態(tài)的應用(比如橫豎屏切換、相關(guān)游戲、磁力計姿態(tài)校準)、振動識別相關(guān)功能(比如計步器、敲擊)等；至于終端300還可配置的陀螺儀、氣壓計、濕度計、溫度計、紅外線傳感器等其他傳感器，在此不再贅述。

音頻電路160、揚聲器161，傳聲器162可提供用戶與終端300之間的音頻接口。音頻電路160可將接收到的音頻數(shù)據(jù)轉(zhuǎn)換后的電信號，傳輸?shù)綋P聲器161，由揚聲器161轉(zhuǎn)換為聲音信號輸出；另一方面，傳聲器162將收集的聲音信號轉(zhuǎn)換為電信號，由音頻電路160接收后轉(zhuǎn)換為音頻數(shù)據(jù)，再將音頻數(shù)據(jù)輸出處理器180處理后，經(jīng)RF電路110以發(fā)送給比如另一終端，或者將音頻數(shù)據(jù)輸出至存儲器120以便進一步處理。音頻電路160還可能包括耳塞插孔，以提供外設耳機與終端300的通信。

WiFi屬于短距離無線傳輸技術(shù)，終端300通過WiFi模塊170可以幫助用戶收發(fā)電子郵件、瀏覽網(wǎng)頁和訪問流式媒體等，它為用戶提供了無線的寬帶互聯(lián)網(wǎng)訪問。

處理器180是終端300的控制中心，利用各種接口和線路連接整個手機的各個部分，通過運行或執(zhí)行存儲在存儲器120內(nèi)的軟件程序和/或模塊，以及調(diào)用存儲在存儲器120內(nèi)的數(shù)據(jù)，執(zhí)行終端300的各種功能和處理數(shù)據(jù)，從而對手機進行整體監(jiān)控?？蛇x的，處理器180可包括一個或多個處理核心；優(yōu)選的，處理器180可集成應用處理器和調(diào)制解調(diào)處理器，其中，應用處理器主要處理操作系統(tǒng)、用戶界面和應用程序等，調(diào)制解調(diào)處理器主要處理無線通信?？梢岳斫獾氖?，上述調(diào)制解調(diào)處理器也可以不集成到處理器180中。

終端300還包括給各個部件供電的電源190(比如電池)，優(yōu)選的，電源可以通過電源管理系統(tǒng)與處理器180邏輯相連，從而通過電源管理系統(tǒng)實現(xiàn)管理充電、放電、以及功耗管理等功能。電源190還可以包括一個或一個以上的直流或交流電源、再充電系統(tǒng)、電源故障檢測電路、電源轉(zhuǎn)換器或者逆變器、電源狀態(tài)指示器等任意組件。

盡管未示出，終端300還可以包括攝像頭、藍牙模塊等，在此不再贅述。具體在本實施例中，終端的顯示單元是觸摸屏顯示器，終端還包括有存儲器，以及一個或者一個以上的程序，其中一個或者一個以上程序存儲于存儲器中，且經(jīng)配置以由一個或者一個以上處理器執(zhí)行述一個或者一個以上程序包含用于執(zhí)行上述軟件異常檢測方法的指令。

本領(lǐng)域普通技術(shù)人員可以理解實現(xiàn)上述實施例的全部或部分步驟可以通過硬件來完成，也可以通過程序來指令相關(guān)的硬件完成，所述的程序可以存儲于一種計算機可讀存儲介質(zhì)中，上述提到的存儲介質(zhì)可以是只讀存儲器，磁盤或光盤等。

以上所述僅為本發(fā)明的較佳實施例，并不用以限制本發(fā)明，凡在本發(fā)明的精神和原則之內(nèi)，所作的任何修改、等同替換、改進等，均應包含在本發(fā)明的保護范圍之內(nèi)。