對反向代理軟件進行測試的方法及系統的制作方法

文檔序號：7770926閱讀：509來源：國知局

對反向代理軟件進行測試的方法及系統的制作方法
【專利摘要】本申請公開了對反向代理軟件進行測試的方法及系統，其中，所述方法包括：接收到案例場景可執行文件后，按照所述案例場景可執行文件啟動測試；當客戶端節點向反向代理節點發送第一請求消息、反向代理節點向服務器節點發送攜帶有所述第一請求消息的報文內容的第二請求消息時，驅動所述服務器節點通過預先在客戶端節點與服務器節點之間建立的消息通道，向所述客戶端節點獲取所述第一請求消息的原始報文內容；獲取所述第二請求消息中攜帶的第一請求消息的報文內容相對于所述第一請求消息的原始報文內容發生的第一變更信息；判斷所述第一變更信息是否符合預置的期望信息，如果不符合，則提供第一提示信息。通過本申請，能夠獲得更有效的測試結果。
【專利說明】對反向代理軟件進行測試的方法及系統

【技術領域】
[0001] 本申請涉及反向代理軟件測試【技術領域】，特別是涉及對反向代理軟件進行測試的方法及系統。

【背景技術】
[0002] 反向代理（Reverse Proxy)方式是指以代理服務器來接收Internet上的連接請求消息，然后將請求消息轉發給內部網絡上的服務器，并將從服務器上得到的結果返回給 Internet上請求消息連接的客戶端。參見圖1，反向代理位于Internet用戶與原始web服務器之間，它負責接收和處理所有對原始web服務器的請求消息。如果Internet用戶請求消息的頁面在代理服務器上有緩存，代理服務器直接將緩存內容發送給用戶；如果沒有緩存，則先向原始web服務器發出請求消息，從原始web服務器取回數據并在本地緩存后再發送給用戶。此時，代理服務器對外就表現為一個服務器。這種方式通過降低向web服務器的請求消息數，降低了 web服務器的負載。
[0003] 具體實現時，一般需要安裝反向代理軟件來實現反向代理服務器的上述功能。目前業界以及各大公司在使用的反向代理軟件有多種，反向代理軟件在實現對客戶端請求消息報文、原始服務器端的響應消息報文進行轉發的過程中，還可能會涉及到對請求消息報文或者響應消息報文的變更，當然，這種變更前提是，變更后的內容符合用戶的預期。也就是說，假設反向代理軟件對某報文中的某個字段的值進行了修改，則修改后的值應該符合 HTTP (Hypertext transfer protocol,超文本傳輸協議）協議中對該字段的值的規定。
[0004] 但是隨著業務種類、訪問流量的不斷的上升，Q)N (Content Delivery Network,內容分發網絡）線上所暴露的HTTP請求消息處理異常情況也呈現多樣化復雜化，軟件開發人員在開發反向代理軟件的過程中，需要確定某些特定請求消息下反向代理軟件到底執行何種動作才是符合協議規定的，而不是把僅僅能夠滿足業務需求作為目標。因此，需要開發出一套對反向代理軟件的協議一致性進行測試的工具，以期既能夠堵住協議標準支持方面存在的漏洞，把問題提前暴露于線下，又可以評估出不同產品不同版本間對HTTP/1. 1標準協議支持程度，方便做縱向、橫向對比。
[0005] 參見圖2,現有技術中提供的測試工具的具體原理如下：
[0006] 首先，采用某種HTTP請求消息模擬工具(例如linux上Curl工具)，用以模擬 Internet上的用戶行為，部署在測試機器1上；機器2上部署被測反向代理軟件；機器3上部署常用HTTP Server軟件，例如lighthttp、apache等，用以模擬原始Web服務器；并進行配置，使得機器1上HTTP模擬工具發出的請求消息，能夠通過被測反向代理從HTTP Server 上正確獲得所請求消息的內容數據，HTTP Server能夠接收和響應消息來自被測反向代理轉發的請求消息。之后就可以進入具體的測試流程：
[0007] 步驟一：手工填充HTTP模擬發送工具所需要的參數，發送請求消息報文至反向代理；
[0008] 步驟二：反向代理根據報文內容將請求消息轉發至HTTP Server軟件；
[0009] 步驟三：HTTP Server軟件根據自身HTTP/1. 1協議實現方案，回復響應消息報文至反向代理；
[0010] 步驟四：在機器1處HTTP請求消息發送端，借助某些工具，人工查看返回的報文內容是否符合預期；同時登陸機器2,執行反向代理的內置命令，查看反向代理的當前狀態和緩存行為是否符合預期。
[0011] 上述測試方法中，通過最后人工查看報文內容等是否符合預期，可以判斷出上述流程中是否存在問題，但是，其缺陷在于：無法確定問題是出現在反向代理軟件一端，還是 HTTP Server -端，或者是整個流程中的其他環節，因此，測試結果的有效性有待提高。

【發明內容】

[0012] 本申請提供了對反向代理軟件進行測試的方法及系統，能夠獲得更有效的測試結果。
[0013] 本申請提供了如下方案：
[0014] 一種對反向代理軟件進行測試的方法，其特征在于，包括：
[0015] 接收到案例場景可執行文件后，按照所述案例場景可執行文件啟動測試；
[0016] 當客戶端節點向反向代理節點發送第一請求消息、反向代理節點向服務器節點發送攜帶有所述第一請求消息的報文內容的第二請求消息時，按照所述案例場景可執行文件，驅動所述服務器節點通過預先在客戶端節點與服務器節點之間建立的消息通道，向所述客戶端節點獲取所述第一請求消息的原始報文內容；其中，所述反向代理節點中部署有被測反向代理軟件；
[0017] 獲取所述第二請求消息中攜帶的第一請求消息的報文內容相對于所述第一請求消息的原始報文內容發生的第一變更信息；
[0018] 根據所述案例場景可執行文件，判斷所述第一變更信息是否符合預置的期望信息，如果不符合，則提供第一提示信息。
[0019] 一種對反向代理軟件進行測試的方法，包括：
[0020] 接收到案例場景可執行文件后，按照所述案例場景可執行文件啟動測試；
[0021] 當客戶端節點向反向代理節點發送第三請求消息、反向代理節點根據緩存的報文內容返回響應消息時，按照所述案例場景可執行文件，驅動所述客戶端節點通過預先在客戶端節點與服務器節點之間建立的消息通道，查詢服務器節點是否收到發自反向代理節點的第四請求消息，并向所述服務器節點獲取針對所述第三請求消息的響應消息的原始報文內容；其中，所述反向代理節點中部署有被測反向代理軟件；
[0022] 如果服務器節點收到了發自反向代理節點的第二請求消息，則提供第四提示信息；
[0023] 獲取所述反向代理節點返回的響應消息的報文內容相對于所述原始報文內容發生的變更信息；
[0024] 根據所述案例場景可執行文件，判斷所述變更信息是否符合預置的期望信息，如果不符合，則提供第五提示信息。
[0025] 一種對反向代理軟件進行測試的系統，包括：
[0026] 測試啟動單元，用于接收到案例場景可執行文件后，按照所述案例場景可執行文件啟動測試；
[0027] 第一報文內容檢查單元，用于當客戶端節點向反向代理節點發送第一請求消息、反向代理節點向服務器節點發送攜帶有所述第一請求消息的報文內容的第二請求消息時，按照所述案例場景可執行文件，驅動所述服務器節點通過預先在客戶端節點與服務器節點之間建立的消息通道，向所述客戶端節點獲取所述第一請求消息的原始報文內容；其中，所述反向代理節點中部署有被測反向代理軟件；
[0028] 第一變更信息獲取單元，用于獲取所述第二請求消息中攜帶的第一請求消息的報文內容相對于所述第一請求消息的原始報文內容發生的第一變更信息；
[0029] 第一提示單元，用于根據所述案例場景可執行文件，判斷所述第一變更信息是否符合預置的期望信息，如果不符合，則提供第一提示信息。
[0030] 一種對反向代理軟件進行測試的系統，包括：
[0031] 測試啟動單元，用于接收到案例場景可執行文件后，按照所述案例場景可執行文件啟動測試；
[0032] 第三報文內容檢查單元，用于當客戶端節點向反向代理節點發送第三請求消息、反向代理節點根據緩存的報文內容返回響應消息時，按照所述案例場景可執行文件，驅動所述客戶端節點通過預先在客戶端節點與服務器節點之間建立的消息通道，查詢服務器節點是否收到發自反向代理節點的第四請求消息，并向所述服務器節點獲取針對所述第三請求消息的響應消息的原始報文內容；其中，所述反向代理節點中部署有被測反向代理軟件；
[0033] 第四提示單元，用于如果服務器節點收到了發自反向代理節點的第二請求消息，則提供第四提示信息；
[0034] 第三變更信息獲取單元，用于獲取所述反向代理節點返回的響應消息的報文內容相對于所述原始報文內容發生的變更信息；
[0035] 第五提示單元，用于根據所述案例場景可執行文件，判斷所述變更信息是否符合預置的期望信息，如果不符合，則提供第五提示信息。
[0036] 根據本申請提供的具體實施例，本申請公開了以下技術效果：
[0037] 通過本申請實施例，使得服務器端在收到反向代理節點發送的第二請求消息之后，可以進行報文內容檢查，也即通過預先建立的專用的消息通道，向客戶端索取第一請求消息的原始報文信息，然后將第二請求消息中攜帶的第一請求消息的報文內容與原始報文內容進行比對，找出其中發生變更之處，并與案例場景文件中寫明的期望信息進行比對，便可以確定反向代理軟件在此次轉發過程中，是否對報文內容進行了不符合用戶期望的變更，也即，反向代理軟件是否滿足協議一致性的要求。因此，通過這種方式，可以有效地檢測出反向代理軟件可能存在的問題。并且，客戶端節點與服務器節點之間傳送消息的原始報文內容時，可以通過專用的消息通道來進行，從而實現將報文內容與消息/信號的傳遞隔離開來，分別形成數據層面和控制層面，這樣既可以保證數據報文的安全準確，又可以保證消息/信號的高效傳遞。
[0038] 另外，通過對案例場景的格式化描述，可以降低案例提交者的門檻，提高測試案例場景的編寫效率；更為重要的是，使得系統可以識別出每一步驟的含義，實現對一些必須字段的智能補全。并且，通過對每一步驟的目的進行識別，甚至還可以對各個步驟之間的上下文依賴關系進行識別，可以獲知整個案例場景的測試目的，以此更準確地確定智能補全時需要填充的字段或者取值等信息，以便更真實的反映測試案例場景的需要。
[0039] 當然，實施本申請的任一產品并不一定需要同時達到以上所述的所有優點。

【專利附圖】

【附圖說明】
[0040] 為了更清楚地說明本申請實施例或現有技術中的技術方案，下面將對實施例中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本申請的一些實施例，對于本領域普通技術人員來講，在不付出創造性勞動的前提下，還可以根據這些附圖獲得其他的附圖。
[0041] 圖1是反向代理系統結構示意圖；
[0042] 圖2是現有技術中的測試方案示意圖；
[0043] 圖3是本申請實施例提供的方法的流程圖；
[0044] 圖4是本申請實施例提供的方法中的報文交互時序圖；
[0045] 圖5是本申請實施例提供的另一方法的流程圖；
[0046] 圖6是本申請實施例提供的另一方法中的報文交互時序圖；
[0047] 圖7是本申請實施例提供的數據一致性檢查方法流程圖；
[0048] 圖8是本申請實施例提供的復雜案例場景7]^意圖；
[0049] 圖9是本申請實施例提供的測試案例場景描述文件編譯方法的流程圖；
[0050] 圖10是本申請實施例提供的智能補全方法流程圖；
[0051] 圖11是本申請實施例提供的系統的示意圖；
[0052] 圖12是本申請實施例提供的另一系統的示意圖。

【具體實施方式】
[0053] 下面將結合本申請實施例中的附圖，對本申請實施例中的技術方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本申請一部分實施例，而不是全部的實施例。基于本申請中的實施例，本領域普通技術人員所獲得的所有其他實施例，都屬于本申請保護的范圍。
[0054] 在本申請實施例中，提供了對反向代理軟件進行測試的套件，該套件中可以包括客戶端以及服務器端，用戶可以在其機器上安裝該套件，用以對被測反向代理軟件進行測試。也就是說，在本申請實施例中，客戶端以及服務器端可以安裝在同一機器上。其中，為了得到更有效的測試結果，更好的定位問題出現的位置，在客戶端和服務器端分別增加agent 代理，在部署測試套件的過程中，就可以在兩agent之間通過socket連接建立起專用消息通道，以供后續的測試過程使用。當然，由于客戶端以及服務器端可以部署在同一臺機器上，因此，為了能夠在兩者之間建立起socket連接，可以使得客戶端與服務器端對應不同的端口。另外，被測反向代理軟件也可以部署在測試套件所在的同一機器上，并且，也可以使得反向代理軟件對應其他的端口，這樣可以在同一機器上模擬不同的網絡節點。當然，在實際應用中，具體的測試工具也可以不必以套件的形式存在，而是分別在不同的機器上部署客戶端、被測反向代理軟件以及服務器端，在客戶端所在機器與服務器端所在機器之間建立起專用的消息通道，以供具體的測試過程使用。需要說明的是，關于本申請實施例的測試套件中涉及到的各端，無論是部署與同一臺機器上，還是部署在不同的機器上，但是每一端可以看作是一個節點，在測試的過程中，需要在各個節點之間進行報文交互，并判斷交互過程中是否出現不符合用戶預期的變更，等等，以此對被測反向代理軟件對協議一致性的支持方面進行測試。下面就對具體的測試過程進行詳細地介紹。
[0055] 實施例一
[0056] 本申請實施例一首先提供了一種對反向代理軟件進行測試的方法，在該方法中，針對的是報文交互過程中反向代理節點的緩存未命中（miss)的情況，參見圖3,具體可以包括以下步驟：
[0057] S301 :接收到案例場景可執行文件后，按照所述案例場景可執行文件啟動測試；
[0058] 具體實現時，在機器上部署了本申請實施例提供的測試套件，并建立起客戶端節點與服務器節點之間的專用消息通道之后，就可以執行具體的測試過程。但在具體實現時，在執行測試之前，還需要獲取到案例場景可執行文件，在收到該案例場景可執行文件之后，才會啟動具體的測試過程。其中，所謂的案例場景就是由測試人員根據需要，手動或者自動生成的對測試過程中具體交互流程的描述，例如，驅動客戶端產生請求消息，等等。也就是說，在機器中部署了本申請實施例中的測試套件之后，相當于搭建起了測試的基本架構，但是，如何使用該架構進行測試，還取決于案例場景可執行文件中的描述，該基本架構相當于可以支持案例場景的執行，各端可以測試執行模塊的驅動下產生請求消息、響應消息等。
[0059] 其中，具體的案例場景最初可以是由Java等語言描述的，之后進行編譯，得到可執行文件，然后就可以將案例場景可執行文件輸入到本申請實施例中的測試執行模塊來執行。也就是說，具體測試過程中，報文消息具體應該如何流動，客戶端、服務器端分別應該執行哪些處理，都可以是在案例場景中規定好的。在執行該可執行文件的過程中，就相當于驅動客戶端、服務器端按照可執行文件中的規定執行具體的操作，包括發送請求消息、響應消息，此外，在本申請實施例中還包括對內容進行檢查等，關于此，下文中會有詳細的介紹。
[0060] S302 :當客戶端節點向反向代理節點發送第一請求消息、反向代理節點向服務器節點發送攜帶有所述第一請求消息的報文內容的第二請求消息時，按照所述案例場景可執行文件，驅動所述服務器節點通過預先在客戶端節點與服務器節點之間建立的消息通道，向所述客戶端節點獲取所述第一請求消息的原始報文內容；其中，所述反向代理節點中部署有被測反向代理軟件；
[0061] 由于該實施例一針對的是報文交互過程中反向代理節點的緩存未命中的情況，也就是說，客戶端發起某請求消息，針對該請求消息的響應消息的報文內容尚未在反向代理節點上進行緩存。在這種情況下，客戶端在發出一個請求消息之后，反向代理節點會首先判斷在緩存中是否存在針對該請求消息的響應消息的報文內容，在判斷發現沒有之后，反向代理節點會向服務器節點發送一個請求消息。為了便于區分，將客戶端發送的請求消息稱為第一請求消息，將反向代理節點發送到服務器節點的請求消息稱為第二請求消息。
[0062] 其中，反向代理節點在收到客戶端節點的第一請求消息時，如果發現需要向服務器節點進行轉發，則在轉發之前，可能會對第一請求消息的報文內容進行一些變更，例如，在消息頭中加入一些字段等，然后再在第二請求消息中攜帶上變更后的第一請求消息的報文內容，并發送給服務器節點。具體如何對第一請求消息的報文內容進行修改，是由反向代理軟件來決定的，本申請實施例中的測試過程，主要的測試目的就是判斷這種更改是否符合用戶預期，也即是否符合協議中的規定。
[0063] 為了能夠達到上述測試目的，在反向代理節點向服務器節點發送了攜帶有第一請求消息的報文內容的第二請求消息之后，就可以按照案例場景可執行文件中的操作指示，驅動服務器節點通過預先在客戶端節點與服務器節點之間建立的消息通道，向客戶端節點獲取第一請求消息的原始報文內容，以便后續進行比對。也就是說，在本申請實施例中，由于預先已經在客戶端節點與服務器節點之間建立了專用的消息通道，因此，在服務器節點收到反向代理節點發送的第二請求消息之后，測試執行模塊就可以驅動服務器節點向客戶端節點索取第一請求消息的原始報文內容，這樣就可以在服務器節點處，將第二請求消息中攜帶的第一請求消息的報文內容與第一請求消息的原始報文內容進行比對，獲取發生的變更信息。
[0064] S303:獲取所述第二請求消息中攜帶的第一請求消息的報文內容相對于所述第一請求消息的原始報文內容發生的第一變更信息；
[0065] 在獲取到第一請求消息的原始報文內容之后，就可以判斷第二請求消息中攜帶的第一請求消息的報文內容相對于該原始報文內容發生的第一變更信息，也就是說判斷反向代理軟件在向服務器節點發送第二請求消息之前，對第一請求消息哪些內容進行了變更，變更后的值是什么，進而確定反向代理軟件進行的這種變更是否符合用戶的預期，是否符合協議中的規定。
[0066] S304:根據所述案例場景可執行文件，判斷所述第一變更信息是否符合預置的期望信息，如果不符合，則提供第一提示信息。
[0067] 關于期望反向代理軟件將第一請求消息的報文內容進行怎樣的變更，也是在案例場景描述文件中寫明的，因此，在步驟S303中獲取到第一變更信息之后，就可以判斷該第一變更信息與案例場景描述文件中寫明的期望值是否相同，如果不相同，則可以證明是反向代理軟件進行的變更不符合用戶的預期，不符合協議中的規定，因此，可以發出提示信息，并終止測試的進行。當然，在發出提示信息之后，也可以繼續執行測試，只要通過提示信息讓用戶知曉此處發生了問題即可。
[0068] 為便于描述，本申請實施例中從上述步驟S302中的通過專用消息通道獲取客戶端的原始報文內容，到步驟S303中獲取第一變更信息，再到步驟S304中判斷這種第一變更信息是否符合用戶的預期的過程，稱為服務器節點的報文內容檢查過程。
[0069] 通過本申請實施例一，使得服務器端在收到反向代理節點發送的第二請求消息之后，可以進行報文內容檢查，也即通過預先建立的專用的消息通道，向客戶端索取第一請求消息的原始報文信息，然后將第二請求消息中攜帶的第一請求消息的報文內容與原始報文內容進行比對，找出其中發生變更之處，并與案例場景文件中寫明的期望信息進行比對，便可以確定反向代理軟件在此次轉發過程中，是否對報文內容進行了不符合用戶期望的變更，也即，反向代理軟件是否滿足協議一致性的要求。因此，通過這種方式，可以有效地檢測出反向代理軟件可能存在的問題。并且，客戶端節點與服務器節點之間傳送消息的原始報文內容時，可以通過專用的消息通道來進行，從而實現將報文內容與消息/信號的傳遞隔離開來，分別形成數據層面和控制層面，這樣既可以保證數據報文的安全準確，又可以保證消息/信號的高效傳遞。
[0070] 在上述步驟S304中，如果發現第一變更信息符合預置的期望信息，則可以按照案例場景可執行文件繼續執行測試，首先，服務器節點就可以將第一請求消息對應的響應消息發送到反向代理節點，在反向代理節點可能會對服務器節點的響應消息的報文內容進行一定的修改，然后再重新生成響應消息，在其中攜帶上服務器節點的響應消息的報文內容，返回給客戶端。這里，為了便于區分，將服務器節點返回的響應消息稱為第一響應消息，將反向代理節點向客戶端節點返回的響應消息稱為第二響應消息，其中，第二響應消息中攜帶有第一響應消息的報文內容，并且該報文內容可能是被反向反向代理軟件修改過的。因此，案例場景描述文件中一般也會將此處確定為需要對報文內容進行檢查的地方。也就是說，需要驅動客戶端節點通過預先建立的專用消息通道，向服務器端索取第一響應消息的原始報文內容，然后就可以獲取第二響應消息中攜帶的第一響應消息的報文內容相對于第一響應消息的原始報文內容發生的第二變更信息，并根據案例場景描述文件，判斷該第二變更信息是否符合用戶預置的期望信息，如果不符合，則提供第二提示信息。也即，可以提示用戶反向代理軟件在此處出現了問題。具體實現時，在發出第二提示信息之后，可以終止此次測試過程，或者也可以繼續執行。
[0071 ] 另外，在實際應用中，在進行報文內容檢查的過程中，或者執行完某次報文內容檢查之后，可能需要獲取或者重置對端軟件的工作狀態，在本申請實施例中，同樣可以通過客戶端節點與服務器節點之間的專用消息通道實現。例如，在服務器節點執行完一次報文內容檢查之后，如果需要獲取/重置客戶端軟件的工作狀態，則可以在案例場景中寫明，在執行案例場景可執行文件的過程中，就可以根據案例場景中的描述，來驅動服務器向客戶端節點發送信號，獲取/重置客戶端軟件的工作狀態，達到對控制客戶端節點行為的目的。同理，在客戶端節點完成某次報文內容檢查之后，如果需要獲取/重置服務器端軟件的工作狀態，則可以在案例場景中寫明，在執行案例場景可執行文件的過程中，就可以根據案例場景中的描述，來驅動客戶端向服務器節點發送信號，獲取/重置服務器軟件的工作狀態，從而更新或維護整體測試環境。
[0072] 為了更好的理解本申請實施例一提供的上述方法，下面通過一個時序圖對上述方法進行詳細的介紹。參見圖4,在反向代理節點緩存未命中的情況下，報文交互的流程圖包括以下步驟：
[0073] S401 :客戶端節點（Client端）發送第一請求消息（Request請求)，請求到達反向代理后，緩存中并沒有從源服務器Server端事先獲得的數據，因此反向代理節點當前處于未命中miss狀態；
[0074] S402 :反向代理向Server端發起新的第二請求消息，并攜帶第一請求消息的報文內容，請求用戶所需要的內容。Server端收到請求后，首先通過以下方式執行報文內容檢查操作：Server使用本端的Agent,通過專用消息通道，向Client端索取第一請求消息 Request的原始報文內容，從而檢查Request請求報文在經過被測反向代理轉發后,是否已經發生了用戶不期望的內容變更。同時，Server端也可以通過該專用消息通道發送信號，獲取或重置Client端軟件工作狀態,從而達到控制Client行為的目的。
[0075] S403 :當Server端Request報文內容檢查通過后，將根據HTTP/1. 1協議相關規定，發送響應消息即Response報文。
[0076] S404 :Response報文經過被測反向代理后，將在反向代理處緩存一份副本，之后反向代理將Response報文轉發至Client端。同上所述，Client端首先執行報文內容檢查操作：Client使用本端的Agent,通過專用消息通道，向Server端索取Response消息的原始報文內容，從而檢查Response報文內容是否在經過反向代理后發生不可預期的變更。 Client端同樣可以通過該通道發送信號至Server端，獲取或重置Server端軟件狀態，從而更新或維護整體測試環境。
[0077] 實施例二
[0078] 以上實施例一對反向代理節點未命中的情況下，本申請實施例提供的測試方法，在該實施例二中，對反向代理節點命中（hit)的情況下，具體的測試過程進行詳細的介紹。
[0079] 參見圖5,本申請實施例二提供的對反向代理軟件進行測試的方法可以包括以下步驟：
[0080] S501 :接收到案例場景可執行文件后，按照所述案例場景可執行文件啟動測試；
[0081] 該步驟與步驟S301相同。
[0082] S502 :當客戶端節點向反向代理節點發送第三請求消息、反向代理節點根據緩存的報文內容返回響應消息時，按照所述案例場景可執行文件，驅動所述客戶端節點通過預先在客戶端節點與服務器節點之間建立的消息通道，查詢服務器節點是否收到發自反向代理節點的第四請求消息，并向所述服務器節點獲取針對所述第三請求消息的響應消息的原始報文內容；其中，所述反向代理節點中部署有被測反向代理軟件；
[0083] 對于反向代理節點的緩存命中了第三請求消息的情況下，反向代理節點就會直接向客戶端節點返回響應消息，并攜帶之前緩存的報文內容。也就是說，在正常的情況下，反向代理節點應該不再向原始服務器節點發送第四請求消息。另外，反向代理節點提供的響應消息的報文內容相對于原始服務器節點提供的原始報文內容可能已經發生了變更，而在正常情況下，這種變更應該符合用戶的預期。因此，在本申請實施例中，就可以對以上兩點進行檢查，從而達到測試的目的。
[0084] 具體實現時，這兩部分檢查的觸發以及用戶預期的變更后的信息都可以寫在案例場景描述文件中，這樣在執行案例場景可執行文件的過程中，就可以直接按照案例場景的描述，來驅動客戶端節點通過預先在客戶端節點與服務器節點之間建立的專用消息通道向服務器節點發送消息，查詢服務器節點是否收到發自反向代理節點的第四請求消息，并向服務器節點獲取針對第三請求消息的響應消息的原始報文內容。
[0085] S503:如果服務器節點收到了發自反向代理節點的第四請求消息，則提供第四提示信息；
[0086] 由于正常情況下，服務器節點應該不會收到反向代理節點發送的請求消息，而如果服務器節點收到了該消息，則證明反向代理軟件的處理是不符合用戶預期的，因此，可以向用戶發出相應的提示信息，提醒用戶發現了該問題。
[0087] S504 :獲取所述反向代理節點返回的響應消息的報文內容相對于所述原始報文內容發生的變更信息；
[0088] 在獲取到服務器節點的原始報文內容之后，可以將從反向代理節點獲取到的響應消息中攜帶的報文內容與原始報文內容進行比對，從而獲取到發生的變更信息。
[0089] S505:根據所述案例場景可執行文件，判斷所述變更信息是否符合預置的期望信息，如果不符合，則提供第五提示信息。
[0090] 由于案例場景描述信息中寫明了期望的變更信息，因此就可以判斷變更信息是否符合用戶的預期，如果不符合，則可以進行提示，告知用戶發現了該問題，提醒用戶注意。
[0091] 也就是說，在該實施例二中，對于反向代理節點能夠命中客戶端請求的情況，也提供了相應的測試方式，從而可以及時的發現反向代理節點在此過程中是否進行不符合用戶預期的操作，獲得有效的測試結果。
[0092] 為了更好地理解本申請實施例二中提供的測試方法，下面通過一個時序圖對上述方法進行詳細的介紹。參見圖6,在反向代理節點緩存命中的情況下，報文交互的流程圖包括以下步驟：
[0093] S601 :客戶端節點（Client端）發送Request請求后，報文內容在反向代理緩存中已經存在，此時緩存為hit命中狀態；
[0094] S602 :反向代理不再重新向源服務器節點（Server端）發起請求，而是直接將緩存中中命中的內容作為響應回復Client端。在此過程中，Server端沒有收到Request報文， Client端可以使用本端Agent通過專用的消息通道向Server端發送消息，查詢Server端是否如同預期一樣沒有收到發自反向代理的Request請求。并且，Client端在收到來自反向代理節點的響應消息后，同樣可以執行報文內容檢查動作，檢查來自反向代理緩存中的 Response副本相對于Server端的原始報文內容，是否發生不符合用戶預期的變化。同時也可以通過專用消息管道，獲取Server端當前狀態。
[0095] 下面對以上實施例一以及實施例二中的具體實現進行以下補充介紹。
[0096] 首先，在上述實施例一以及實施例二中，關于驅動服務器節點/客戶端節點通過預先建立的消息通道向客戶端節點/服務器節點索取原始報文內容，都是在案例場景描述中寫好的。也就是說，測試人員在寫案例場景描述文件時，可以先確定好需要在何時對報文進行檢查，并寫好期望的變更是怎樣的，這樣在執行可執行文件的過程中，在對應的環節上，測試執行模塊就會驅動對應的服務器節點/客戶端節點通過專用的消息通道向對端節點索取原始報文內容。這種在案例場景描述文件中指定的報文檢查時機，一般是測試人員認為可能會出現問題的地方。但是，在實際應用中，在報文傳遞的整個流程中，除了測試人員指定的可能會出現問題的地方之外，還有很多其他環節可能會出現問題。例如，在網絡傳輸的過程中，還可能導致傳輸的報文內容出錯等等。也就是說，假設通過報文內容檢查發現反向代理節點發送給服務器節點的第二請求消息中攜帶的第一請求消息的報文內容相對于原始報文內容發生的變更不符合預期，可能不完全是由于反向代理軟件在修改時造成的，還可能是由于報文內容在傳輸的過程中，由于網絡環境的因素，使得報文內容被篡改或者發生了不可預期的變化，等等。因此，如果能夠對這種環節也進行測試，則可以獲得更準確的測試結果。
[0097] 但是對于測試人員而言，在寫案例場景描述文件時，一般不會對報文傳輸中的各個環節都進行檢查，而是僅在其最為關心的結果地方進行檢查。為此，在本申請實施例中，可以由系統中的測試執行模塊驅動執行在其他環節上的檢查操作。其中，這里的測試執行模塊就是前文所述的用于執行案例場景可執行文件的模塊，也就是說，該模塊在按照案例場景可執行文件的規定驅動各端進行報文交互以及報文內容檢查的過程中，還可以對網絡傳輸過程中的數據一致性進行檢查，以便獲取到更準確的測試結果。
[0098] 具體實現時，在各節點之間都可以預先建立起專用的消息通道，當有消息從上一節點發送到當前節點時，測試執行模塊可以自動驅動當前節點通過預先在上一節點與當前節點之間建立的消息通道，獲取上一節點發出的消息的報文內容；并判斷當前節點接收到的消息報文內容與從消息通道獲取到的報文內容是否一致，如果不一致，則提供第三提示信息。這里，各節點就包括測試系統中的客戶端節點、反向代理節點、服務器節點，發送的消息就包括請求消息或者響應消息。也就是說，報文在流動到網絡中任何節點時，都可以通過專有消息通道獲取在上一節點發送的報文內容的拷貝，然后，通過md5校驗等方式，對節點通過網絡收到的報文內容，與通過專用消息通道獲取到的上一節點發出的報文內容進行一致性檢查，具體可以包括對報文頭部和報文主體內容的一致性檢查，當發現不一致時，可以及時給出提示或告警，這樣可以避免圖3或者圖5的測試過程中發生誤判。
[0099] 當然，對于案例場景描述文件中已經指定需要進行檢查的環節，測試執行模塊可以不必另外啟動上述一致性檢查過程。例如，參見圖7, 一個實際應用中的例子中，具體的數據一致性檢查過程可以包括以下步驟：
[0100] S701 :判斷案例場景中是否已經指定本端(也即當前接收到某消息的節點）需要檢驗HTTP報文body字段(報文主體內容)，如果已經指定，執行步驟S702,如果未指定，轉步驟 S703 ；
[0101] S702:數據一致性檢查程序結束，數據一致性校驗工作將會根據案例場景可執行文件的規定來執行；
[0102] S703 :讀取當前節點接收到的來自上一節點的報文內容；
[0103] S704 :從該報文內容中抽取body字段內容，定義為bodyl ;
[0104] S705:通過當前節點的Agent，通過專用消息通道獲取上一節點的原始報文的 body內容，定義為body2 ;
[0105] S706 :采用md5算法，檢驗md5(bodyl)是否與md5(body2)相等，若不相等，執行步驟S707,若相等，則轉步驟S708 ;
[0106] S707 :提示用戶，報文內容發生不可預期變更，同時，當前節點可以通過agent向上一節點發送重置（reset)信號，重置上一節點軟件的工作狀態；
[0107] S708 :判斷是否為當前節點最后一個檢查動作；
[0108] S709 :若為當前節點最后一個檢查動作，則程序結束；否則，轉到步驟S701。
[0109] 也就是說，在本申請實施例中，由于可以在兩個節點之間建立起專用消息通道，因此，除了可以在客戶端節點與服務器節點之間進行報文內容檢查之外，還可以在任意兩個節點之間進行數據一致性的檢查，從而能夠及時發現由于網絡環境等原因導致的報文內容被篡改或者其他不可預期的更改，提高最終測試結果的有效性。
[0110] 另外，關于實施例一以及實施例二中提到的案例場景描述文件以及案例場景可執行文件，如前文所述，按照現有技術中的方法，測試案例場景提交者可以使用Java等計算機語言來編寫案例場景描述文件，然后直接進行編譯得到案例場景可執行文件后，交由測試執行模塊來執行。但是，如果采用這種方法，則至少存在以下問題：一方面，對編寫案例場景描述文件的專業性門檻會比較高，因為測試案例場景提交者需要熟知各種計算機語言的語法規則等等，非專業技術人員難以掌握，因此提高了測試案例場景提交者的門檻，不利于大范圍推廣使用；另一方面，由于每次發送和接收報文都是一個獨立的過程，因此多次的發送、接收之間難以體現報文發送的上下文邏輯關系，無法反映出整個案例場景的測試執行目的以及希望獲得的結果，進而也就不利于幫助測試人員完成一些自動化的操作，如果案例場景中存在一些錯誤信息，只能提醒用戶有錯誤存在，但并不能準確的給出修改建議。
[0111] 為此，在本申請實施例中，還提供了一種格式化描述方式，在該格式化描述方式中，可以將報文交互過程按照步驟進行拆分，每一步驟分配一個關鍵字。如果需要對案例場景進行描述，則在描述文件中，每一步驟用對應的關鍵字以及附帶的報文內容信息表示。例如，對應于圖4中的報文交互流程，可以拆分為如下四步：
[0112] 第一步為客戶端節點Client向被測反向代理節點發起Request請求消息，本申請實施例中可以使用關鍵字Request來代表該步驟；
[0113] 第二步為被測反向代理向服務器節點Server發起Request請求消息，Server端在收到Request請求消息后，執行報文內容檢查，本申請實施例中可以使用ServerCheck來代表該步驟；
[0114] 第三步為Server根據HTTP/1. 1相關協議規定，向被測反向代理節點發出 Response響應消息，本申請實施例中使用關鍵字Response來代表該步驟；
[0115] 第四步為Client收到被測反向代理轉發的來自Server端的Response報文， Client收到后執行相應報文檢查，本申請實施例中使用關鍵字ClientCheck來代表該步驟。
[0116] 相應的，圖6所示的報文交互過程，就相當于可以拆分成上述第一步和第四步。通過指定的關鍵字，及相應關鍵字附帶報文內容信息，可以完整的描述本步驟內報文發送的特征和內容。其中，對于發送請求消息或者響應消息的步驟而言，關鍵字附帶的報文內容信息包括本端發送報文的格式、內容；對于進行報文內容檢查的步驟而言，關鍵字附帶的報文內容信息中還包括期望接收到的發自對端的報文內容。當然，以上關鍵字可以使用其他詞匯來替代。
[0117] 通過上述格式化定義，圖4中的案例場景可以描述如下：
[0118]
[0119]

【權利要求】
1. 一種對反向代理軟件進行測試的方法，其特征在于，包括：接收到案例場景可執行文件后，按照所述案例場景可執行文件啟動測試；當客戶端節點向反向代理節點發送第一請求消息、反向代理節點向服務器節點發送攜帶有所述第一請求消息的報文內容的第二請求消息時，按照所述案例場景可執行文件，驅動所述服務器節點通過預先在客戶端節點與服務器節點之間建立的消息通道，向所述客戶端節點獲取所述第一請求消息的原始報文內容；其中，所述反向代理節點中部署有被測反向代理軟件；獲取所述第二請求消息中攜帶的第一請求消息的報文內容相對于所述第一請求消息的原始報文內容發生的第一變更信息；根據所述案例場景可執行文件，判斷所述第一變更信息是否符合預置的期望信息，女口果不符合，則提供第一提示信息。
2. 根據權利要求1所述的方法，其特征在于，還包括：按照所述案例場景可執行文件，驅動所述服務器節點通過所述消息通道向客戶端節點發送信號，獲取或重置客戶端節點的工作狀態。
3. 根據權利要求1所述的方法，其特征在于，還包括：如果所述第一變更信息符合預置的期望信息，則按照所述案例場景可執行文件繼續執行測試；當服務器節點向反向代理節點返回第一響應消息、反向代理節點向客戶端節點返回攜帶有所述第一響應消息的報文內容的第二響應消息時，按照所述案例場景可執行文件，驅動所述客戶端節點通過所述消息通道向所述服務器節點獲取所述第一響應消息的原始報文內容；獲取所述第二響應消息中攜帶的第一響應消息的報文內容相對于所述第一響應消息的原始報文內容發生的第二變更信息；根據所述案例場景可執行文件，判斷所述第二變更信息是否符合預置的期望信息，女口果不符合，提供第二提示信息。
4. 根據權利要求3所述的方法，其特征在于，還包括：按照所述案例場景可執行文件，驅動所述客戶端節點通過所述消息通道向服務器節點發送信號，獲取或重置服務器節點的工作狀態。
5. 根據權利要求1至4任一項所述的方法，其特征在于，還包括：當有消息從上一節點發送到當前節點時，自動驅動當前節點通過預先在上一節點與當前節點之間建立的消息通道，獲取上一節點發出的消息的報文內容；所述消息包括請求消息或者響應消息；判斷當前節點接收到的消息報文內容與上一節點發出的消息的報文內容是否一致，女口果不一致，則提供第H提示信息。
6. 根據權利要求1至4任一項所述的方法，其特征在于，還包括：接收案例場景描述文件，所述描述文件中，通過多個步驟描述案例場景，每一步驟用對應的關鍵字W及附帶的報文內容信息表示；創建可執行文件，初始狀態下，所述可執行文件為空；從所述案例場景描述文件中讀取各個關鍵字W及各自附帶的報文內容信息； w所述關鍵字為函數名，所述附帶的報文內容信息為函數參數，寫入所述可執行文件， W便生成所述案例場景可執行文件。
7. 根據權利要求6所述的方法，其特征在于，所述多個步驟包括客戶端節點向反向代理節點發出請求消息、服務器節點收到反向代理節點發送的請求消息后執行報文內容檢查、服務器節點向反向代理節點發送響應消息、客戶端節點收到反向代理節點發送的響應消息后執行報文內容檢查；其中，對于發送請求消息或者響應消息的步驟而言，關鍵字附帶的報文內容信息包括本端發送報文的格式、內容；對于進行報文內容檢查的步驟而言，關鍵字附帶的報文內容信息中還包括期望接收到的發自對端的報文內容。
8. 根據權利要求7所述的方法，其特征在于，同一步驟在同一案例場景描述文件中出現一次或多次。
9. 根據權利要求6所述的方法，其特征在于，還包括：對案例場景描述文件關鍵字附帶的報文內容信息進行補全。
10. 根據權利要求9所述的方法，其特征在于，所述對案例場景描述文件關鍵字附帶的報文內容信息進行補全，包括：檢查關鍵字附帶的報文內容信息中必須的字段是否存在；如果所述必須的字段存在，則檢查該字段對應的值是否存在；如果該字段對應的值不存在，貝時Ij用預知的默認值進行填充。
11. 根據權利要求10所述的方法，其特征在于，還包括：如果所述必須的字段不存在，則檢查與所述必須的字段具有同等效用的字段是否存在；如果所述同等效用的字段存在，則檢查該同等效用的字段對應的值是否存在；如果該同等效用的字段對應的值不存在，貝時Ij用預知的默認值進行填充；如果所述同等效用的字段不存在，貝時Ij用預知的默認字段名W及對應的值進行填充。
12. 根據權利要求9所述的方法，其特征在于，還包括：根據所述案例場景描述文件中的關鍵字確定各個步驟上下文之間的依賴關系；根據所述依賴關系確定各個關鍵字附帶的報文內容信息中需要補全的字段W及對應的取值。
13. 根據權利要求6所述的方法，其特征在于，還包括：根據所述案例場景描述文件中的關鍵字確定各個步驟上下文之間的依賴關系；根據所述依賴關系判斷各個關鍵字附帶的報文內容信息中已經寫入的信息是否真實反映場景需要；如果不能真實反映場景需要，則對所述報文內容信息中已經寫入的信息進行修改。
14. 一種對反向代理軟件進行測試的方法，其特征在于，包括：接收到案例場景可執行文件后，按照所述案例場景可執行文件啟動測試；當客戶端節點向反向代理節點發送第H請求消息、反向代理節點根據緩存的報文內容返回響應消息時，按照所述案例場景可執行文件，驅動所述客戶端節點通過預先在客戶端節點與服務器節點之間建立的消息通道，查詢服務器節點是否收到發自反向代理節點的第四請求消息，并向所述服務器節點獲取針對所述第H請求消息的響應消息的原始報文內容；其中，所述反向代理節點中部署有被測反向代理軟件；女口果服務器節點收到了發自反向代理節點的第二請求消息，則提供第四提示信息；獲取所述反向代理節點返回的響應消息的報文內容相對于所述原始報文內容發生的變更信息；根據所述案例場景可執行文件，判斷所述變更信息是否符合預置的期望信息，如果不符合，則提供第五提示信息。
15. -種對反向代理軟件進行測試的系統，其特征在于，包括：測試啟動單元，用于接收到案例場景可執行文件后，按照所述案例場景可執行文件啟動測試；第一報文內容檢查單元，用于當客戶端節點向反向代理節點發送第一請求消息、反向代理節點向服務器節點發送攜帶有所述第一請求消息的報文內容的第二請求消息時，按照所述案例場景可執行文件，驅動所述服務器節點通過預先在客戶端節點與服務器節點之間建立的消息通道，向所述客戶端節點獲取所述第一請求消息的原始報文內容；其中，所述反向代理節點中部署有被測反向代理軟件；第一變更信息獲取單元，用于獲取所述第二請求消息中攜帶的第一請求消息的報文內容相對于所述第一請求消息的原始報文內容發生的第一變更信息；第一提示單元，用于根據所述案例場景可執行文件，判斷所述第一變更信息是否符合預置的期望信息，如果不符合，則提供第一提示信息。
16. -種對反向代理軟件進行測試的系統，其特征在于，包括：測試啟動單元，用于接收到案例場景可執行文件后，按照所述案例場景可執行文件啟動測試；第H報文內容檢查單元，用于當客戶端節點向反向代理節點發送第H請求消息、反向代理節點根據緩存的報文內容返回響應消息時，按照所述案例場景可執行文件，驅動所述客戶端節點通過預先在客戶端節點與服務器節點之間建立的消息通道，查詢服務器節點是否收到發自反向代理節點的第四請求消息，并向所述服務器節點獲取針對所述第H請求消息的響應消息的原始報文內容；其中，所述反向代理節點中部署有被測反向代理軟件；第四提示單元，用于如果服務器節點收到了發自反向代理節點的第二請求消息，則提供第四提示信息；第H變更信息獲取單元，用于獲取所述反向代理節點返回的響應消息的報文內容相對于所述原始報文內容發生的變更信息；第五提示單元，用于根據所述案例場景可執行文件，判斷所述變更信息是否符合預置的期望信息，如果不符合，則提供第五提示信息。
【文檔編號】H04L29/08GK104468655SQ201310428726
【公開日】2015年3月25日申請日期:2013年9月18日優先權日:2013年9月18日
【發明者】閔慶歡, 陳睿申請人:阿里巴巴集團控股有限公司

完整全部詳細技術資料下載