本申請涉及互聯(lián)網(wǎng)
技術(shù)領(lǐng)域：
，尤其涉及異常場景模擬方法、裝置及設(shè)備。
背景技術(shù)：
：在一些系統(tǒng)中，需要將接收的第一信息轉(zhuǎn)換為第二信息。第二信息是經(jīng)過轉(zhuǎn)換后，本系統(tǒng)可直接使用的信息。在網(wǎng)絡(luò)異常、配置異常等異常場景下，將第一信息進行轉(zhuǎn)換獲得的信息為異常信息，針對異常信息可以采用恢復(fù)機制進行第二信息的恢復(fù)。在產(chǎn)品上線前，需要對產(chǎn)品各功能進行驗證，特別是對恢復(fù)機制進行驗證，則可以通過模擬異常場景的方式進行恢復(fù)機制的驗證。以支付渠道中掉單查詢驗證為例，在發(fā)起業(yè)務(wù)請求前，人工將緩存中各返回碼對應(yīng)的結(jié)果狀態(tài)修改為異常結(jié)果狀態(tài)，在發(fā)起業(yè)務(wù)請求后，接收支付渠道對應(yīng)的支付端發(fā)送的包含交易返回碼的交易結(jié)果信息，根據(jù)緩存中的映射關(guān)系將交易返回碼轉(zhuǎn)換為相應(yīng)的結(jié)果狀態(tài)。由于人工已將所有返回碼的結(jié)果狀態(tài)修改為異常結(jié)果狀態(tài)，因此轉(zhuǎn)換后的結(jié)果狀態(tài)為異常結(jié)果狀態(tài)，即該次交易處于掉單狀態(tài)，則啟動掉單查詢的恢復(fù)機制。監(jiān)測到恢復(fù)機制啟動時，人工將緩存中各返回碼對應(yīng)的結(jié)果狀態(tài)恢復(fù)為正確的結(jié)果狀態(tài)，以使恢復(fù)機制啟動后，向信息端發(fā)送查詢信息，根據(jù)接收的查詢返回碼、查詢結(jié)果中的交易返回碼以及恢復(fù)后的映射關(guān)系獲得正確的結(jié)果狀態(tài)，從而對掉單查詢進行驗證?？梢?，需要人工模擬異常場景，浪費了人力資源、且效率低。技術(shù)實現(xiàn)要素：本申請?zhí)峁┊惓鼍澳M方法、裝置及設(shè)備，以解決現(xiàn)有技術(shù)浪費人力、模擬效率低的問題。根據(jù)本申請實施例的第一方面，提供一種異常場景模擬方法，包括：接收到信息端發(fā)送的第一信息時，攔截將所述第一信息轉(zhuǎn)換為第二信息的轉(zhuǎn)換請求；根據(jù)所述第一信息判斷預(yù)存的攔截配置中的攔截條件是否滿足，所述攔截配置中包括攔截條件和攔截條件對應(yīng)的異常信息，所述異常信息是在真實異常場景下產(chǎn)生的異于所述第二信息的信息；根據(jù)判斷結(jié)果確定是否將所述第一信息轉(zhuǎn)換為所述異常信息。根據(jù)本申請實施例的第二方面，提供一種異常場景模擬方法，所述方法包括：攔截返回碼查詢請求，所述返回碼查詢請求攜帶渠道信息和/或接口信息；查詢預(yù)先注入的攔截配置信息，所述攔截配置信息包括待攔截的渠道信息和\或接口信息；如果攔截配置信息包括渠道信息，則當前運行環(huán)境為指定的預(yù)發(fā)布環(huán)境、且返回碼查詢請求中攜帶的渠道信息和攔截配置信息中渠道信息一致時，將該返回碼對應(yīng)的狀態(tài)更改為異常狀態(tài)；如果攔截配置信息包括接口信息，則當前運行環(huán)境為指定的預(yù)發(fā)布環(huán)境、且返回碼查詢請求中攜帶的接口信息和攔截配置信息中接口信息一致時，將該返回碼對應(yīng)的狀態(tài)更改為異常狀態(tài)；如果攔截配置信息包括渠道信息和接口信息，則當前運行環(huán)境為指定的預(yù)發(fā)布環(huán)境、且返回碼查詢請求中攜帶的渠道信息和接口信息分別與攔截配置信息中的渠道信息和接口信息一致時，將該返回碼對應(yīng)的狀態(tài)更改為異常狀態(tài)。根據(jù)本申請實施例的第三方面，提供一種異常場景模擬裝置，所述裝置包括：攔截模塊，用于接收到信息端發(fā)送的第一信息時，攔截將所述第一信息轉(zhuǎn)換為第二信息的轉(zhuǎn)換請求；判斷模塊，用于根據(jù)所述第一信息判斷預(yù)存的攔截配置中的攔截條件是否滿足，所述攔截配置中包括攔截條件和攔截條件對應(yīng)的異常信息，所述異常信息是在真實異常場景下產(chǎn)生的異于所述第二信息的信息；轉(zhuǎn)換模塊，用于根據(jù)判斷結(jié)果確定是否將所述第一信息轉(zhuǎn)換為所述異常信息。根據(jù)本申請實施例的第四方面，提供一種異常場景模擬裝置，所述裝置包括：請求攔截模塊，用于攔截返回碼查詢請求，所述返回碼查詢請求攜帶渠道信息和/或接口信息；信息查詢模塊，用于查詢預(yù)先注入的攔截配置信息，所述攔截配置信息包括待攔截的渠道信息和\或接口信息；轉(zhuǎn)換模塊，用于：如果攔截配置信息包括渠道信息，則當前運行環(huán)境為指定的預(yù)發(fā)布環(huán)境、且返回碼查詢請求中攜帶的渠道信息和攔截配置信息中渠道信息一致時，將該返回碼對應(yīng)的狀態(tài)更改為異常狀態(tài)；如果攔截配置信息包括接口信息，則當前運行環(huán)境為指定的預(yù)發(fā)布環(huán)境、且返回碼查詢請求中攜帶的接口信息和攔截配置信息中接口信息一致時，將該返回碼對應(yīng)的狀態(tài)更改為異常狀態(tài)；如果攔截配置信息包括渠道信息和接口信息，則當前運行環(huán)境為指定的預(yù)發(fā)布環(huán)境、且返回碼查詢請求中攜帶的渠道信息和接口信息分別與攔截配置信息中的渠道信息和接口信息一致時，將該返回碼對應(yīng)的狀態(tài)更改為異常狀態(tài)。根據(jù)本申請實施例的第五方面，提供一種設(shè)備，包括：處理器；用于存儲所述處理器可執(zhí)行指令的存儲器；其中，所述處理器被配置為：接收到信息端發(fā)送的第一信息時，攔截將所述第一信息轉(zhuǎn)換為第二信息的轉(zhuǎn)換請求；根據(jù)所述第一信息判斷預(yù)存的攔截配置中的攔截條件是否滿足，所述攔截配置中包括攔截條件和攔截條件對應(yīng)的異常信息，所述異常信息是在真實異常場景下產(chǎn)生的異于所述第二信息的信息；根據(jù)判斷結(jié)果確定是否將所述第一信息轉(zhuǎn)換為所述異常信息。應(yīng)用本申請實施例異常場景模擬方法、裝置及設(shè)備時，在接收到信息端發(fā)送的第一信息時，攔截轉(zhuǎn)換請求，通過第一信息判斷是否滿足預(yù)存的攔截配置中的攔截條件的方式，來決定是否將第一信息轉(zhuǎn)換為異常信息，從而通過攔截機制實現(xiàn)自動化模擬異常場景，避免了人工修改造成的人力浪費、效率低以及出錯率高的問題，進一步提高了恢復(fù)機制驗證效率。應(yīng)當理解的是，以上的一般描述和后文的細節(jié)描述僅是示例性和解釋性的，并不能限制本申請。附圖說明此處的附圖被并入說明書中并構(gòu)成本說明書的一部分，示出了符合本申請的實施例，并與說明書一起用于解釋本申請的原理。圖1為本申請異常場景模擬方法的一個實施例流程圖。圖2為本申請異常場景模擬方法的另一個實施例流程圖。圖3為本申請異常場景模擬方法的另一個實施例流程圖。圖4為本申請異常場景模擬裝置所在設(shè)備的一種硬件結(jié)構(gòu)圖。圖5為本申請異常場景模擬裝置的一個實施例框圖。圖6為本申請異常場景模擬裝置的另一個實施例框圖。具體實施方式這里將詳細地對示例性實施例進行說明，其示例表示在附圖中。下面的描述涉及附圖時，除非另有表示，不同附圖中的相同數(shù)字表示相同或相似的要素。以下示例性實施例中所描述的實施方式并不代表與本申請相一致的所有實施方式。相反，它們僅是與如所附權(quán)利要求書中所詳述的、本申請的一些方面相一致的裝置和方法的例子。在本申請使用的術(shù)語是僅僅出于描述特定實施例的目的，而非旨在限制本申請。在本申請和所附權(quán)利要求書中所使用的單數(shù)形式的“一種”、“所述”和“該”也旨在包括多數(shù)形式，除非上下文清楚地表示其他含義。還應(yīng)當理解，本文中使用的術(shù)語“和/或”是指并包含一個或多個相關(guān)聯(lián)的列出項目的任何或所有可能組合。應(yīng)當理解，盡管在本申請可能采用術(shù)語第一、第二、第三等來描述各種信息，但這些信息不應(yīng)限于這些術(shù)語。這些術(shù)語僅用來將同一類型的信息彼此區(qū)分開。例如，在不脫離本申請范圍的情況下，第一信息也可以被稱為第二信息，類似地，第二信息也可以被稱為第一信息。取決于語境，如在此所使用的詞語“如果”可以被解釋成為“在……時”或“當……時”或“響應(yīng)于確定”。在一些系統(tǒng)中，需要將接收的第一信息轉(zhuǎn)換為可識別的第二信息。在網(wǎng)絡(luò)異常、配置異常等異常場景下，將第一信息進行轉(zhuǎn)換獲得的信息為異常信息，針對異常信息可以采用恢復(fù)機制進行第二信息的恢復(fù)。在產(chǎn)品上線前，需要對產(chǎn)品各功能進行驗證，特別是對恢復(fù)機制進行驗證，而驗證過程中不能確定是否出現(xiàn)異常場景，則可以通過模擬異常場景的方式進行恢復(fù)機制的驗證。相關(guān)技術(shù)中，工作人員在系統(tǒng)每次接收信息端發(fā)送的第一信息之前，預(yù)先將本地配置信息中的映射關(guān)系進行修改，將第一信息映射的第二信息修改為異常信息。在系統(tǒng)接收信息端發(fā)送的第一信息時，由于本地配置信息中的映射關(guān)系已被篡改，則根據(jù)已篡改的映射關(guān)系將第一信息轉(zhuǎn)換為異常信息。在確定轉(zhuǎn)換結(jié)果為異常信息時，判定出現(xiàn)異常場景，啟動恢復(fù)機制。為了實現(xiàn)恢復(fù)機制的驗證，工作人員需要將本地配置信息中的映射關(guān)系進行恢復(fù)，以使恢復(fù)機制基于正確的配置信息恢復(fù)出正確的第二信息?？梢?，在模擬異常場景過程中需要人工參與，浪費人力資源，模擬效率低，從而導(dǎo)致恢復(fù)機制驗證的效率低。為了節(jié)省人力、提高模擬效率，本申請?zhí)峁┮环N異常場景模擬方法。該方法適用于需要將接收的第一信息轉(zhuǎn)換為可識別的第二信息、且通過恢復(fù)機制對轉(zhuǎn)換的異常信息進行恢復(fù)的系統(tǒng)中。在該系統(tǒng)設(shè)計中，對網(wǎng)絡(luò)異常、配置異常等異常場景，可等同于將第二信息轉(zhuǎn)換為異常信息。針對異常信息，采用恢復(fù)機制進行恢復(fù)。為了實現(xiàn)異常場景的模擬的自動化，可以在接收到信息端發(fā)送的第一信息時，攔截轉(zhuǎn)換請求，通過第一信息判斷是否滿足預(yù)存的攔截配置中的攔截條件的方式，來決定是否將第一信息轉(zhuǎn)換為異常信息，從而通過攔截機制實現(xiàn)自動化模擬異常場景，避免了人工修改造成的人力浪費、效率低以及出錯率高的問題，進一步提高了恢復(fù)機制驗證效率。如圖1所示，圖1為本申請異常場景模擬方法的一個實施例流程圖，包括以下步驟101至步驟103：在步驟101中，接收到信息端發(fā)送的第一信息時，攔截將所述第一信息轉(zhuǎn)換為第二信息的轉(zhuǎn)換請求。在步驟102中，根據(jù)所述第一信息判斷預(yù)存的攔截配置中的攔截條件是否滿足，所述攔截配置中包括攔截條件和攔截條件對應(yīng)的異常信息，所述異常信息是在真實異常場景下產(chǎn)生的異于所述第二信息的信息。在步驟103中，根據(jù)判斷結(jié)果確定是否將所述第一信息轉(zhuǎn)換為所述異常信息。其中，第一信息是信息端發(fā)送的需要本執(zhí)行端轉(zhuǎn)換的信息。信息端是發(fā)送第一信息的一端，例如，信息端可以是支付渠道對應(yīng)的支付端。用戶在第三方支付場景下選擇的通道可以稱為支付渠道，比如用戶在支付頁面選擇工商銀行進行支付，工商銀行這條渠道為本次支付的支付渠道。基于此，本方法執(zhí)行端可以為第三方支付平臺，如支付寶支付平臺、百度錢包支付平臺、微信支付平臺、財付通支付平臺等。又如，信息端可以是接入支付平臺的外部商戶平臺，如百度外賣、美團外賣，本方法執(zhí)行端可以為支付平臺。又如，信息端可以是支付平臺，本方法執(zhí)行端可以為外部商戶平臺等。在接收到信息端發(fā)送的第一信息時，可以生成轉(zhuǎn)換請求，轉(zhuǎn)換請求用于將第一信息轉(zhuǎn)換為第二信息。第二信息是經(jīng)過轉(zhuǎn)換后，本系統(tǒng)可直接使用的信息。相關(guān)技術(shù)中直接根據(jù)轉(zhuǎn)換請求從本地存儲的配置信息中映射出第一信息對應(yīng)的第二信息。而本申請為了模擬異常場景，采用攔截機制攔截該轉(zhuǎn)換請求。在一個例子中，可以采用面向切面的攔截機制攔截轉(zhuǎn)換請求，并執(zhí)行步驟102和步驟103。在攔截轉(zhuǎn)換請求后，可以根據(jù)第一信息判斷預(yù)存的攔截配置中的攔截條件是否滿足。攔截配置可以包括攔截條件和攔截條件對應(yīng)的異常信息。其中，攔截條件是預(yù)先設(shè)定的用于判斷是否將第一信息轉(zhuǎn)換為異常信息的條件，可以通過第一信息判斷攔截條件是否滿足。例如，可以判斷第一信息是否為滿足攔截條件的信息；也可以判斷第一信息當前所在的運行環(huán)境是否為攔截條件中指定的預(yù)發(fā)布環(huán)境等。異常信息是在真實異常場景下產(chǎn)生的異于所述第二信息的信息，例如，異常信息可以是在異常場景下將第一信息轉(zhuǎn)換后得到的信息，也可以是在異常場景下沒有收到第一信息產(chǎn)生的異常信息。其中，真實的異常場景可以是一種異常場景，則可以通過攔截的方式模擬異常信息對應(yīng)的某一種異常場景。真實的異常場景也可以是多種異常場景，利用一種異常信息來表示多種異常場景下產(chǎn)生的信息，從而實現(xiàn)通過攔截的方式模擬多種異常場景。例如，可以用“未知狀態(tài)”來表示一種或多種真實異常場景下產(chǎn)生的異常信息。比如，網(wǎng)絡(luò)異常時，本系統(tǒng)在設(shè)定時間內(nèi)無法收到相應(yīng)的第一信息，則可以等同于目前業(yè)務(wù)處于未知狀態(tài)。又如第二信息不可識別時，可以等同于目前業(yè)務(wù)處于未知狀態(tài)。在根據(jù)第一信息判斷預(yù)存的攔截配置中的攔截條件是否滿足后，可以根據(jù)判斷結(jié)果確定是否將第一信息轉(zhuǎn)換為異常信息。由于異常信息是在真實異常場景下產(chǎn)生的異于所述第二信息的信息，因此，將第一信息轉(zhuǎn)換為異常信息相當于將當前的環(huán)境模擬為異常環(huán)境，從而實現(xiàn)異常環(huán)境的自動化模擬。在一個例子中，當所述攔截條件滿足時，將所述第一信息轉(zhuǎn)換為所述異常信息；當所述攔截條件不滿足時，根據(jù)所述轉(zhuǎn)換請求和本地存儲的配置信息將所述第一信息轉(zhuǎn)換為第二信息，所述配置信息包括第一信息與第二信息之間的映射關(guān)系。可見，在攔截條件不滿足時，可以跳出攔截程序，跳出攔截程序可以理解為終止攔截程序，跳出攔截程序后，可以執(zhí)行原有的轉(zhuǎn)換服務(wù)，通過本地存儲的配置信息進行正常的信息轉(zhuǎn)換，從而可以獲得正常的第二信息。在該例子中，可以通過控制攔截條件來限制攔截的轉(zhuǎn)換請求，實現(xiàn)針對接收到不同信息自動確定是否進行異常場景模擬。以恢復(fù)機制中的查詢恢復(fù)機制為例，可以將交易后接收到的交易結(jié)果信息限定為滿足攔截條件，將查詢后接收到的查詢結(jié)果信息限定為不滿足攔截條件，則將交易結(jié)果信息轉(zhuǎn)換為異常信息，而不將查詢結(jié)果信息轉(zhuǎn)換為異常信息，實現(xiàn)自動化確定是否進行異常信息轉(zhuǎn)換，無需工作人員將本地配置信息中的映射關(guān)系進行恢復(fù)，避免了人工恢復(fù)造成的人力浪費。由上述實施例可見，在接收到信息端發(fā)送的第一信息時，攔截轉(zhuǎn)換請求，通過判斷轉(zhuǎn)換請求是否滿足預(yù)存的攔截配置中的攔截條件的方式，來決定是否將第一信息轉(zhuǎn)換為異常信息，在滿足攔截條件時將第一信息轉(zhuǎn)換為異常信息，在不滿足攔截條件時進行正常的信息轉(zhuǎn)換，從而通過攔截機制實現(xiàn)自動化模擬異常場景，并且無需工作人員將本地配置信息中的映射關(guān)系進行恢復(fù)，避免了人工修改和恢復(fù)造成的人力浪費、效率低以及出錯率高的問題，從而可以提高恢復(fù)機制驗證效率。在一個可選的實現(xiàn)方式中，可以接收用于操作內(nèi)存的注入請求，根據(jù)所述注入請求確定需要增加攔截配置時，將所述注入請求中攜帶的攔截配置緩存在緩存區(qū)中，根據(jù)所述注入請求確定需要清空緩存區(qū)中的攔截配置時，清空所述緩存區(qū)中的攔截配置。該實施例列舉了預(yù)先注入攔截配置和清除攔截配置的方法。攔截配置中包括攔截條件和攔截條件對應(yīng)的異常信息。其中，可以根據(jù)注入請求確定對應(yīng)內(nèi)存的緩存區(qū)，并在該緩存區(qū)執(zhí)行新增攔截配置操作或清除攔截配置操作。注入請求是用于操作內(nèi)存的請求，可以是在緩存區(qū)中寫入攔截配置的請求，也可以是清除緩存區(qū)中攔截配置的請求。在一個例子中，可以通過注入請求中是否攜帶攔截配置來確定注入請求類型。例如，當注入請求中攜帶攔截配置時，將所述注入請求中攜帶的攔截配置緩存在緩存區(qū)中；當注入請求為空時，清空所述緩存區(qū)中的攔截配置。在另一個例子中，也可以通過請求命令確定注入請求類型，例如，若注入請求為注入攔截配置請求，則將攔截配置緩存在緩存區(qū)中；又如，若注入請求為清空請求/無效請求等，則清空所述緩存區(qū)中的攔截配置。在一個例子中，可以采用JMX(JavaManagementExtensions，即Java管理擴展)技術(shù)進行攔截配置的寫入和刪除，實現(xiàn)對運行時內(nèi)存進行操作，該種方式比較容易實現(xiàn)。以下以一個具體的應(yīng)用場景為例進行說明。在該實施例中，信息端可以為支付渠道對應(yīng)的支付端，第一信息可以包括指示交易結(jié)果的返回碼或指示查詢結(jié)果的返回碼。當?shù)谝恍畔ㄖ甘窘灰捉Y(jié)果的返回碼時，第一信息為支付端返回的有關(guān)交易結(jié)果的信息。當?shù)谝恍畔ㄖ甘静樵兘Y(jié)果的返回碼時，第一信息是啟動恢復(fù)機制進行查詢后支付端返回的有關(guān)查詢結(jié)果的信息。為了驗證查詢恢復(fù)機制，在配置攔截條件時，可以將支付端返回的有關(guān)交易結(jié)果的信息配置為滿足攔截條件，將支付端返回的有關(guān)查詢結(jié)果的信息配置為不滿足攔截條件。該實施例方法可以適用于基于返回碼判斷交易狀態(tài)的系統(tǒng)中，例如第三方支付平臺中。在出現(xiàn)網(wǎng)絡(luò)異常、配置異常等異常場景時，支付渠道對應(yīng)的支付端和本執(zhí)行端之間會出現(xiàn)掉單。所謂掉單是支付過程中因網(wǎng)絡(luò)、系統(tǒng)不穩(wěn)定等導(dǎo)致的超時、無結(jié)果等情況。將掉單的狀態(tài)進行恢復(fù)，稱為恢復(fù)。恢復(fù)可以有兩種方式，一種是通過重發(fā)實現(xiàn)恢復(fù)，這種方式可以解決由網(wǎng)絡(luò)問題導(dǎo)致的掉單。另一種是通過掉單查詢實現(xiàn)恢復(fù)，通過向渠道端發(fā)送查詢信息，根據(jù)接收的查詢返回碼、查詢結(jié)果中的交易返回碼獲得正確的結(jié)果狀態(tài)，實現(xiàn)恢復(fù)。可見，掉單查詢是用來恢復(fù)的一種手段。對于一筆交易的結(jié)果，可以通過接口+返回碼的形式來映射出交易結(jié)果信息的結(jié)果狀態(tài)，即將交易結(jié)果信息轉(zhuǎn)換為結(jié)果狀態(tài)，該結(jié)果狀態(tài)是本系統(tǒng)可識別的唯一表示交易成敗的狀態(tài)信息。在異常場景下會產(chǎn)生異常結(jié)果狀態(tài)，即掉單。檢測到異常結(jié)果狀態(tài)后，可以啟動查詢的恢復(fù)機制。對于查詢交易的返回碼可以有兩層處理，查詢交易本身的查詢返回碼只用于表示本次查詢調(diào)用是否成功，查詢的結(jié)果若為成功，則可以利用查詢結(jié)果中的交易返回碼(即原流水的返回碼)再做一次返回碼映射，從而獲得正確的結(jié)果狀態(tài)，實現(xiàn)結(jié)果狀態(tài)的恢復(fù)。其中，交易返回碼可以包括支付返回碼、退款返回碼、提現(xiàn)返回碼等。例如，resultCode為查詢接口的返回碼，origResultCode為原交易的返回碼：另外，作為其中一種本地存儲的配置信息，可以如下所示：接口名稱返回碼結(jié)果狀態(tài)描述支付接口A0000S成功支付接口A0001U未知支付接口A0002F失敗查詢接口B0000S成功查詢接口B0003F失敗通過對比配置信息可知，【查詢接口B，返回碼0000】對應(yīng)的結(jié)果狀態(tài)為S，表示查詢成功，其中查詢結(jié)果含原流水結(jié)果，例如【支付接口A，返回碼0000】，根據(jù)配置信息可以確定原交易也成功。支付渠道上線前，需要符合一系列標準，在發(fā)布之前會有一系列的設(shè)計開發(fā)，是否符合設(shè)計標準，需要在真實的場景下驗證。支付渠道驗證中其中一個驗證是掉單查詢驗證。為了實現(xiàn)掉單查詢驗證，需要進行異常場景模擬。為了避免現(xiàn)有技術(shù)中人工模擬異常場景導(dǎo)致人力浪費、效率低的缺陷，本申請?zhí)峁┮环N異常場景模擬方法。如圖2所示，圖2為本申請異常場景模擬方法的另一個實施例流程圖，包括以下步驟201至步驟204：在步驟201中，接收到支付渠道對應(yīng)的支付端發(fā)送的包括指示交易結(jié)果的返回碼或指示查詢結(jié)果的返回碼的第一信息時，攔截轉(zhuǎn)換請求，所述轉(zhuǎn)換請求用于將所述第一信息轉(zhuǎn)換為可識別的結(jié)果信息。其中，結(jié)果信息可以是用于標識結(jié)果的一種狀態(tài)信息，是本系統(tǒng)可識別的唯一表示成敗的狀態(tài)信息。在步驟202中，根據(jù)所述第一信息判斷預(yù)存的攔截配置中的攔截條件是否滿足，所述攔截配置中包括攔截條件和攔截條件對應(yīng)的異常結(jié)果信息，所述異常結(jié)果信息用來表示真實異常場景下產(chǎn)生的信息。在一個例子中，異常結(jié)果信息可以為未知狀態(tài)，從而實現(xiàn)將異常場景等同于返回了未知狀態(tài)，即未知結(jié)果。在步驟203中，當所述攔截條件滿足時，將所述第一信息轉(zhuǎn)換為所述異常結(jié)果信息。在步驟204中，當所述攔截條件不滿足時，根據(jù)所述轉(zhuǎn)換請求和本地存儲的配置信息將所述第一信息轉(zhuǎn)換為相應(yīng)的結(jié)果信息。其中，當攔截條件不滿足時，根據(jù)所述轉(zhuǎn)換請求和本地存儲的配置信息將所述第一信息轉(zhuǎn)換為相應(yīng)的結(jié)果信息，相當于跳出攔截程序，所述攔截程序是攔截轉(zhuǎn)換請求的程序，所述配置信息包括第一信息與結(jié)果信息之間的映射關(guān)系。本地存儲的配置信息中記錄的是正確的映射關(guān)系，從而可以將第一信息轉(zhuǎn)換為正確的結(jié)果信息。在步驟201之前，可以進行攔截配置的注入或刪除。具體的，可以通過操作內(nèi)存的入口接收用于操作內(nèi)存的注入請求；根據(jù)所述注入請求確定需要清空緩存區(qū)中的攔截配置時，清空所述緩存區(qū)中的攔截配置；根據(jù)所述注入請求確定需要增加攔截配置時，將所述注入請求中攜帶的攔截配置緩存在緩存區(qū)中。其中，攔截配置可以包括攔截條件和攔截條件對應(yīng)的異常結(jié)果信息。攔截條件是根據(jù)第一信息判斷是否進行異常場景模擬的條件，在一個可選的實現(xiàn)方式中，攔截條件可以包括下述一種或多種條件：第一種條件：如果攔截配置包括渠道信息，所述第一信息中的渠道信息與攔截配置中的渠道信息匹配。第一信息中可以包括渠道信息，如果攔截配置包括渠道信息，則可以判斷第一信息中的渠道信息是否與攔截配置中的渠道信息匹配，如果匹配，則判定滿足攔截條件。其中，攔截配置中可以包括一個或多個渠道信息，只要第一信息中的渠道信息在攔截配置的渠道信息中，則判定第一信息中的渠道信息與攔截配置中的渠道信息匹配。在一個例子中，渠道信息可以是交易渠道標識，則可以判斷第一信息中的交易渠道標識是否在攔截配置的攔截渠道標識中，如果在，則滿足攔截條件。其中，攔截渠道標識是用于標識支付渠道的標識，可以是數(shù)字、字符串、符號、字母等，只要能唯一標識支付渠道即可。在攔截配置中可以存儲一個或多個攔截渠道標識，根據(jù)每次需要驗證的支付渠道確定攔截配置中存儲的攔截渠道標識。第二種條件：如果攔截配置包括接口信息，所述第一信息中的接口信息與攔截配置中的接口信息匹配。其中，接口是為完成某類業(yè)務(wù)而提供與外界交互的機制。不同類型的交易對應(yīng)不同的接口信息。在該條件中，可以判斷第一信息中的接口信息是否與攔截配置中的接口信息匹配，如果匹配，則判定滿足攔截條件。攔截配置中可以包括一個或多個接口信息，只要第一信息中的接口信息在攔截配置的接口信息中，則判定第一信息中的接口信息與攔截配置中的接口信息匹配。在一個例子中，接口信息可以是接口標識，不同的交易對應(yīng)不同的接口標識，例如接口A用于標識支付，接口C用于標識退款等。本條件可以通過接口標識來限定交易類型，從而對指定交易類型進行異常場景模擬。另外，不僅交易對應(yīng)有相應(yīng)的接口標識，查詢也對應(yīng)有相應(yīng)的接口標識。為了實現(xiàn)查詢的恢復(fù)機制，可以限定攔截配置的攔截接口標識中不包括查詢接口標識，則在檢測到掉單時，可以根據(jù)啟動查詢的恢復(fù)機制，從支付渠道對應(yīng)的支付端進行查詢，接收到包括指示查詢結(jié)果的返回碼的第一信息時，由于第一信息中的查詢接口標識不在攔截配置中，則不滿足攔截條件，可以跳出攔截程序，根據(jù)轉(zhuǎn)換請求和本地存儲的配置信息將第一信息轉(zhuǎn)換為正確的結(jié)果信息。具體的，將第一信息中的查詢返回碼和配置信息進行映射，確定查詢?yōu)槌晒顟B(tài)時，將第一信息中的交易返回碼和配置信息進行映射，從而將交易返回碼轉(zhuǎn)換成對應(yīng)的結(jié)果信息?？梢?，無需工作人員將本地配置信息中的映射關(guān)系進行恢復(fù)，避免了人工恢復(fù)造成的人力浪費。第三種條件：如果攔截配置包括交易返回碼，所述第一信息中的返回碼與攔截配置中的交易返回碼匹配。其中，不同支付渠道對應(yīng)的支付端與第三方支付平臺規(guī)約的交易返回碼不同，例如某些規(guī)約中0000可以表示成功，在另一些規(guī)約中1111可以表示成功。在該實施例中，可以通過第一信息中的交易返回碼來判斷攔截條件是否滿足，若滿足，則將第一信息轉(zhuǎn)換為異常結(jié)果信息，實現(xiàn)異常場景模擬。第四種條件：當前運行環(huán)境為指定的預(yù)發(fā)布環(huán)境。當前運行環(huán)境是指本次結(jié)果信息所在運行環(huán)境。其中，為用戶提供真實的體驗服務(wù)的環(huán)境稱為生產(chǎn)環(huán)境。數(shù)據(jù)、用戶、服務(wù)均都是真實存在的。預(yù)發(fā)布環(huán)境屬于生產(chǎn)環(huán)境的一個特例，在這個環(huán)境里，應(yīng)用屬于最新版本，這個環(huán)境驗證通過后，才可真正的發(fā)布到生產(chǎn)環(huán)境。只有特定的用戶群體才能訪問預(yù)發(fā)布環(huán)境。本實施例將異常場景模擬限定在預(yù)發(fā)布環(huán)境中，從而不會影響用戶在生成環(huán)境中的實際操作，不會由于模擬的異常場景影響用戶體驗?？梢岳斫獾氖牵鲜鰲l件可以進行自由組合，在同時滿足組合條件時，才將第一信息轉(zhuǎn)換為異常結(jié)果信息，進而進行掉單查詢的驗證。例如，攔截配置示例：{"渠道A":{"接口A":"狀態(tài)U"},"渠道A":{"接口B":"狀態(tài)U"},"渠道B":{"接口A":"狀態(tài)U"}}可見，可以在接收到支付渠道對應(yīng)的支付端發(fā)送的第一信息時，攔截轉(zhuǎn)換請求，根據(jù)第一信息判斷預(yù)存的攔截配置中的攔截條件是否滿足，當攔截條件滿足時，將第一信息轉(zhuǎn)換為異常結(jié)果狀態(tài)U。本申請列舉其中一種組合進行說明，該異常場景模擬方法包括以下步驟：攔截返回碼查詢請求，所述返回碼查詢請求攜帶渠道信息和/或接口信息。查詢預(yù)先注入的攔截配置信息，所述攔截配置信息包括待攔截的渠道信息和\或接口信息。如果攔截配置信息包括渠道信息，則當前運行環(huán)境為指定的預(yù)發(fā)布環(huán)境、且返回碼查詢請求中攜帶的渠道信息和攔截配置信息中渠道信息一致時，將該返回碼對應(yīng)的狀態(tài)更改為異常狀態(tài)。如果攔截配置信息包括接口信息，則當前運行環(huán)境為指定的預(yù)發(fā)布環(huán)境、且返回碼查詢請求中攜帶的接口信息和攔截配置信息中接口信息一致時，將該返回碼對應(yīng)的狀態(tài)更改為異常狀態(tài)。如果攔截配置信息包括渠道信息和接口信息，則當前運行環(huán)境為指定的預(yù)發(fā)布環(huán)境、且返回碼查詢請求中攜帶的渠道信息和接口信息分別與攔截配置信息中的渠道信息和接口信息一致時，將該返回碼對應(yīng)的狀態(tài)更改為異常狀態(tài)。其中，本實施例所述返回碼查詢請求是在系統(tǒng)接收到包括返回碼的信息后，需要將返回碼進行轉(zhuǎn)換的轉(zhuǎn)換請求?？梢?，可以通過返回碼查詢請求中攜帶的渠道信息和/或接口信息、以及攔截配置信息中的待攔截的渠道信息和\或接口信息，從而判斷是否將返回碼對應(yīng)的狀態(tài)更改為異常狀態(tài)，從而實現(xiàn)異常場景的模擬。進一步的，本申請還列舉一個具體應(yīng)用實例進行說明。如圖3所示，圖3為本申請異常場景模擬方法的另一個實施例流程圖，包括以下步驟301至步驟306：在步驟301中，接收到攜帶返回碼的第一信息時，攔截轉(zhuǎn)換請求。在步驟302中，判斷當前運行環(huán)境是否為預(yù)發(fā)布環(huán)境，若是，則進入步驟304，否則進入步驟303。在步驟303中，根據(jù)轉(zhuǎn)換請求和本地存儲的配置信息將第一信息中返回碼的狀態(tài)轉(zhuǎn)換為正常的結(jié)果狀態(tài)。在步驟304中，根據(jù)第一信息判斷當前支付渠道是否為攔截渠道，若是，則進入步驟305，否則進入步驟303。在步驟305中，判斷第一信息中的接口標識是否在攔截配置的攔截接口標識中，若是，則進入步驟306，否則進入步驟303。在步驟306中，將第一信息中返回碼的狀態(tài)轉(zhuǎn)換為未知狀態(tài)?？梢岳斫獾氖牵襟E302、304、305三個判斷步驟沒有絕對的先后順序，具體可根據(jù)需要調(diào)整。可見，本實施例中對網(wǎng)絡(luò)異常、返回碼不可識別等異常場景，等同于返回了未知狀態(tài)。通過多種條件判斷是否將第一信息轉(zhuǎn)換為未知狀態(tài)，可以避免誤攔截。另外，在緩存區(qū)中除了將注入請求中攜帶的攔截配置緩存在緩存區(qū)中外，還可以根據(jù)注入請求清空緩存區(qū)中的攔截配置?？梢岳斫獾氖?，針對一些已經(jīng)驗證過的功能，可以將其對應(yīng)的攔截配置進行刪除，避免對新功能進行驗證時，由于舊攔截配置影響對新功能的驗證。通過上述異常場景模擬方法模擬異常場景后，可以根據(jù)所模擬的異常場景對渠道驗證過程中掉單查詢進行驗證。例如可以利用用例的方式實現(xiàn)對渠道驗證過程中掉單查詢進行驗證。例如，對同一銀行卡支付預(yù)設(shè)金額，第一次正常支付，第二次在本方法模擬的異常場景下進行支付，若兩次結(jié)果相同，則掉單查詢功能驗證通過?？梢岳斫獾氖牵唧w的驗證方法可以采用相關(guān)技術(shù)中的驗證方法，在此不再一一贅述。與本申請異常場景模擬方法的實施例相對應(yīng)，本申請還提供了異常場景模擬裝置及設(shè)備的實施例。本申請異常場景模擬裝置的實施例可以應(yīng)用在需要將接收的第一信息轉(zhuǎn)換為可識別的第二信息、且通過恢復(fù)機制對轉(zhuǎn)換的異常信息進行恢復(fù)的各種設(shè)備上，例如，該設(shè)備可以包括服務(wù)器、服務(wù)器集群或者云平臺等。其中，裝置實施例可以通過軟件實現(xiàn)，也可以通過硬件或者軟硬件結(jié)合的方式實現(xiàn)。以軟件實現(xiàn)為例，作為一個邏輯意義上的裝置，是通過其所在設(shè)備的處理器將非易失性存儲器中對應(yīng)的計算機程序指令讀取到內(nèi)存中運行形成的。從硬件層面而言，如圖4所示，為本申請異常場景模擬裝置431所在設(shè)備的一種硬件結(jié)構(gòu)圖，除了圖4所示的處理器410、內(nèi)存430、網(wǎng)絡(luò)接口440、以及非易失性存儲器420之外，實施例中裝置所在的設(shè)備通常根據(jù)該設(shè)備的實際功能，還可以包括其他硬件，圖4中不再一一示出。參見圖5，為本申請異常場景模擬裝置的一個實施例框圖：該裝置包括：攔截模塊510、判斷模塊520和轉(zhuǎn)換模塊530。其中，攔截模塊510，用于接收到信息端發(fā)送的第一信息時，攔截將所述第一信息轉(zhuǎn)換為第二信息的轉(zhuǎn)換請求。判斷模塊520，用于根據(jù)所述第一信息判斷預(yù)存的攔截配置中的攔截條件是否滿足，所述攔截配置中包括攔截條件和攔截條件對應(yīng)的異常信息，所述異常信息是在真實異常場景下產(chǎn)生的異于所述第二信息的信息。轉(zhuǎn)換模塊530，用于根據(jù)判斷結(jié)果確定是否將所述第一信息轉(zhuǎn)換為所述異常信息。在一個可選的實現(xiàn)方式中，所述轉(zhuǎn)換模塊530(圖5未示出)包括：第一轉(zhuǎn)換子模塊，用于當所述攔截條件滿足時，將所述第一信息轉(zhuǎn)換為所述異常信息。第二轉(zhuǎn)換子模塊，用于當所述攔截條件不滿足時，根據(jù)所述轉(zhuǎn)換請求和本地存儲的配置信息將所述第一信息轉(zhuǎn)換為第二信息，所述配置信息包括第一信息與第二信息之間的映射關(guān)系。在一個可選的實現(xiàn)方式中，所述信息端為支付渠道對應(yīng)的支付端，所述第一信息包括指示交易結(jié)果的返回碼或指示查詢結(jié)果的返回碼，所述攔截條件包括下述一種或多種條件：如果攔截配置包括渠道信息，所述第一信息中的渠道信息與攔截配置中的渠道信息匹配。如果攔截配置包括接口信息，所述第一信息中的接口信息與攔截配置中的接口信息匹配。如果攔截配置包括交易返回碼，所述第一信息中的返回碼與攔截配置中的交易返回碼匹配。當前運行環(huán)境為指定的預(yù)發(fā)布環(huán)境。在一個可選的實現(xiàn)方式中，所述裝置還包括：驗證模塊，用于根據(jù)所模擬的異常場景對渠道驗證過程中掉單查詢進行驗證。在一個可選的實現(xiàn)方式中，所述裝置還包括：請求接收模塊，用于接收用于操作內(nèi)存的注入請求。添加模塊，用于根據(jù)所述注入請求確定需要增加攔截配置時，將所述注入請求中攜帶的攔截配置緩存在緩存區(qū)中。清除模塊，用于根據(jù)所述注入請求確定需要清空緩存區(qū)中的攔截配置時，清空所述緩存區(qū)中的攔截配置。參見圖6，為本申請異常場景模擬裝置的另一個實施例框圖：該裝置包括：請求攔截模塊610、信息查詢模塊620和轉(zhuǎn)換模塊630。其中，請求攔截模塊610，用于攔截返回碼查詢請求，所述返回碼查詢請求攜帶渠道信息和/或接口信息。信息查詢模塊620，用于查詢預(yù)先注入的攔截配置信息，所述攔截配置信息包括待攔截的渠道信息和\或接口信息。轉(zhuǎn)換模塊630，用于：如果攔截配置信息包括渠道信息，則當前運行環(huán)境為指定的預(yù)發(fā)布環(huán)境、且返回碼查詢請求中攜帶的渠道信息和攔截配置信息中渠道信息一致時，將該返回碼對應(yīng)的狀態(tài)更改為異常狀態(tài)。如果攔截配置信息包括接口信息，則當前運行環(huán)境為指定的預(yù)發(fā)布環(huán)境、且返回碼查詢請求中攜帶的接口信息和攔截配置信息中接口信息一致時，將該返回碼對應(yīng)的狀態(tài)更改為異常狀態(tài)。如果攔截配置信息包括渠道信息和接口信息，則當前運行環(huán)境為指定的預(yù)發(fā)布環(huán)境、且返回碼查詢請求中攜帶的渠道信息和接口信息分別與攔截配置信息中的渠道信息和接口信息一致時，將該返回碼對應(yīng)的狀態(tài)更改為異常狀態(tài)?；诖?，本申請還提供一種設(shè)備，包括：處理器；用于存儲所述處理器可執(zhí)行指令的存儲器；其中，所述處理器被配置為：接收到信息端發(fā)送的第一信息時，攔截將所述第一信息轉(zhuǎn)換為第二信息的轉(zhuǎn)換請求。根據(jù)所述第一信息判斷預(yù)存的攔截配置中的攔截條件是否滿足，所述攔截配置中包括攔截條件和攔截條件對應(yīng)的異常信息，所述異常信息是在真實異常場景下產(chǎn)生的異于所述第二信息的信息。根據(jù)判斷結(jié)果確定是否將所述第一信息轉(zhuǎn)換為所述異常信息。上述裝置中各個模塊的功能和作用的實現(xiàn)過程具體詳見上述方法中對應(yīng)步驟的實現(xiàn)過程，在此不再贅述。對于裝置實施例而言，由于其基本對應(yīng)于方法實施例，所以相關(guān)之處參見方法實施例的部分說明即可。以上所描述的裝置實施例僅僅是示意性的，其中所述作為分離部件說明的模塊可以是或者也可以不是物理上分開的，作為模塊顯示的部件可以是或者也可以不是物理模塊，即可以位于一個地方，或者也可以分布到多個網(wǎng)絡(luò)模塊上?？梢愿鶕?jù)實際的需要選擇其中的部分或者全部模塊來實現(xiàn)本申請方案的目的。本領(lǐng)域普通技術(shù)人員在不付出創(chuàng)造性勞動的情況下，即可以理解并實施。本領(lǐng)域技術(shù)人員在考慮說明書及實踐這里申請的發(fā)明后，將容易想到本申請的其它實施方案。本申請旨在涵蓋本申請的任何變型、用途或者適應(yīng)性變化，這些變型、用途或者適應(yīng)性變化遵循本申請的一般性原理并包括本申請未申請的本
技術(shù)領(lǐng)域：
中的公知常識或慣用技術(shù)手段。說明書和實施例僅被視為示例性的，本申請的真正范圍和精神由下面的權(quán)利要求指出。應(yīng)當理解的是，本申請并不局限于上面已經(jīng)描述并在附圖中示出的精確結(jié)構(gòu)，并且可以在不脫離其范圍進行各種修改和改變。本申請的范圍僅由所附的權(quán)利要求來限制。當前第1頁1 2 3