本發明涉及測試領域，具體而言，涉及一種對游戲服務器的容量進行測試的方法及裝置。

背景技術：

在一款新的產品(例如，新的應用、新的游戲)上市之前，需要對該產品的各方面性能進行綜合測試，下面以游戲上線為例進行說明：在對需要上線的新游戲進行測試時，需要對游戲服務器容量進行測量，該游戲服務器容量測試是在游戲大規模上線前，測試服務器上線后能承受的最大玩家同時在線個數(Peak Concurrent User，簡稱為PCU)。

在對游戲服務器容量進行測試時，需要構造玩家模型，在相關技術中，構造玩家模型主要是基于客戶端視角來進行構造的。如圖1所示，構造的主要流程可以包括以下操作：

通過打開客戶端體驗游戲，根據經驗確定核心游戲功能(也可稱為目標功能場景)，可以假設核心游戲功能為功能1，功能2，功能3；

整理各核心游戲功能消息時序，然后根據各功能的總游戲時間來設置消息包發送等待時間；

最后構造一個總的玩家模型，順序地進行功能1，功能2，功能3的操作，全部完成以后退出，重新進入繼續功能1，功能2，功能3，反復循環。

需要說明的是，采用相關技術中的構造玩家模型的方法，主要考慮了客戶端的核心游戲功能，以及核心功能的持續時間段。采用這種玩家模型構造方式會存在如下問題：

考慮游戲核心功能類型時，不同游戲核心功能場景(也可稱為目標功能場景)的使用頻次沒有進行差異化。

在較大量玩家同時在線的實際情況中，每個游戲功能場景被使用的頻次是不一樣的，并且不同游戲功能場景對于服務器端產生的資源消耗有很大差別，上述構造方式并未區分大量玩家在線時不同游戲功能場景的使用頻次，因此會導致容量評估結果極不準確；

以及，玩家模型中的玩家平均操作頻率在評估容量中同樣非常重要，該值的誤差會直接決定容量的誤差，比如在預估的操作頻率是每分鐘6個協議包(即，每分鐘發送6條消息)下，評估出單服最大在線是1萬個玩家，若實際的操作頻率是12個包，那么最大在線實際只能承載5千個玩家，如果參考1萬結果上線，很有可能導致玩家在線卡頓，大大影響用戶體驗，而如果預估的操作頻率偏大，則會浪費服務器資源。但是在相關技術的玩家模型構造方案中，該值是基于開發根據系統設計預估的，和實際值之間存在相當大的誤差。也就是說如果測試結果小于服務器的實際可承載的最大玩家同時在線，會導致服務器資源的大大浪費，如果服務器容量結果誤差達到50％，意味著要浪費50％的成本，在玩家同時在線很高的游戲中，這是一筆非常大的開銷浪費；如果測試結果高于服務器的實際可承載能力，就會導致玩家進入游戲失敗，或者在線游戲非常卡頓等情況，極大地影響用戶體驗。

由于相關技術中的玩家操作頻率和核心功能列表是根據設計預估的，并且核心功能的使用人數沒有進行差異化評估，會導致玩家模型不準確，基于該玩家模型確定的允許服務器最大同時在線人數也將極不準確。

針對上述的問題，目前尚未提出有效的解決方案。

技術實現要素：

本發明實施例提供了一種對游戲服務器的容量進行測試的方法及裝置，以至少解決相關技術中存在的服務器容量測試結果不準確的問題。

根據本發明實施例的一個方面，提供了一種對游戲服務器的容量進行測試的方法，包括：獲取消息指示信息，其中，所述消息指示信息用于指示當前游戲的游戲服務器在預定時間段內接收到所述當前游戲中的不同玩家發送的消息；根據所述消息指示信息確定平均消息發送頻率，以及所述消息在不同目標功能場景下的消息占比，其中，所述平均消息發送頻率用于指示單位時間內單個玩家向所述游戲服務器發送的消息的數量，所述游戲中的功能場景包括多個所述目標功能場景；根據所述平均消息發送頻率和所述消息在不同目標功能場景下的消息占比對所述游戲服務器的容量進行測試，得到測試結果，其中，所述測試結果包括同時在線的玩家的數量的最大值。

可選地，根據所述消息指示信息確定所述平均消息發送頻率包括：根據所述消息指示信息確定所述預定時間段內的平均在線玩家數量、以及所述游戲服務器在所述預定時間段內接收到的所述消息的總數；根據如下公式確定所述平均消息發送頻率：所述平均消息發送頻率＝所述消息的總數÷所述平均在線玩家數量÷所述預定時間段的時長。

可選地，根據所述消息指示信息確定所述消息在不同目標功能場景下的消息占比包括：從所述消息的消息號中確定出多個目標消息號；根據所述消息指示信息確定每個所述目標消息號下的目標消息的數量與所述消息的總數之間的比值，其中，所有所述目標消息號的比值之和大于預定閾值且小于1；按比例將所有所述目標消息號的比值擴大至目標比值，其中，所有所述目標消息號的目標比值之和等于1；獲取每個所述目標功能場景對應的所有所述目標消息號的目標比值之和，作為所述消息在所述目標功能場景下的消息占比，其中，每個所述目標消息號對應一個所述目標功能場景。

可選地，根據所述平均消息發送頻率和所述消息在不同目標功能場景下的消息占比對所述游戲服務器的容量進行測試包括：重復執行以下操作，直到模擬玩家發送的消息的響應時間和響應成功率不符合第一預定條件、或所述游戲服務器的空閑資源不符合第二預定條件：按照所述消息占比將當前數量的模擬玩家分別分配到每個所述目標功能場景中；將每個所述模擬玩家的消息發送頻率設置為所述平均消息發送頻率，其中，所述消息發送頻率用于表示在所述單位時間內向所述游戲服務器發送的消息的數量；根據所述分配的結果和所述設置的結果對所述游戲服務器的容量進行測試，并判斷所述測試的過程中所述模擬玩家發送的消息的響應時間和響應成功率是否符合所述第一預定條件、且判斷所述游戲服務器的空閑資源是否符合所述第二預定條件；若響應時間和響應成功率符合所述第一預定條件、且所述游戲服務器的空閑資源符合所述第二預定條件，則將所述當前數量進行增加，將增加后的結果作為所述當前數量；若響應時間和響應成功率不符合所述第一預定條件、或所述游戲服務器的資源不符合所述第二預定條件，則將前一次的當前數量記錄為所述同時在線的玩家的數量的最大值。

可選地，獲取所述消息指示信息包括：分別獲取預定天數內的每天的所述消息指示信息；根據所述消息指示信息確定平均消息發送頻率包括：根據每天的所述消息指示信息確定所述預定天數內的每天的平均消息發送頻率；并從所述預定天數內的每天的平均消息發送頻率中選取頻率值最大的平均消息發送頻率作為確定的所述平均消息發送頻率。

根據本發明實施例的另一方面，還提供了一種對游戲服務器的容量進行測試的裝置，包括：獲取模塊，用于獲取消息指示信息，其中，所述消息指示信息用于指示當前游戲的游戲服務器在預定時間段內接收到所述當前游戲中的不同玩家發送的消息；確定模塊，用于根據所述消息指示信息確定平均消息發送頻率，以及所述消息在不同目標功能場景下的消息占比，其中，所述平均消息發送頻率用于指示單位時間內單個玩家向所述游戲服務器發送的消息的數量，所述游戲中的功能場景包括多個所述目標功能場景；測試模塊，用于根據所述平均消息發送頻率和所述消息在不同目標功能場景下的消息占比對所述游戲服務器的容量進行測試，得到測試結果，其中，所述測試結果包括同時在線的玩家的數量的最大值。

可選地，所述確定模塊包括：第一確定單元，用于根據所述消息指示信息確定所述預定時間段內的平均在線玩家數量、以及所述游戲服務器在所述預定時間段內接收到的所述消息的總數；第二確定單元，用于根據如下公式確定所述平均消息發送頻率：所述平均消息發送頻率＝所述消息的總數÷所述平均在線玩家數量÷所述預定時間段的時長。

可選地，所述確定模塊包括：第三確定單元，用于從所述消息的消息號中確定出多個目標消息號；第四確定單元，用于根據所述消息指示信息確定每個所述目標消息號下的目標消息的數量與所述消息的總數之間的比值，其中，所有所述目標消息號的比值之和大于預定閾值且小于1；擴大單元，用于按比例將所有所述目標消息號的比值擴大至目標比值，其中，所有所述目標消息號的目標比值之和等于1；獲取單元，用于獲取每個所述目標功能場景對應的所有所述目標消息號的目標比值之和，作為所述消息在所述目標功能場景下的消息占比，其中，每個所述目標消息號對應一個所述目標功能場景。

可選地，所述測試模塊包括：執行單元，用于重復執行以下操作，直到模擬玩家發送的消息的響應時間和響應成功率不符合第一預定條件、或所述游戲服務器的空閑資源不符合第二預定條件：按照所述消息占比將當前數量的模擬玩家分別分配到每個所述目標功能場景中；將每個所述模擬玩家的消息發送頻率設置為所述平均消息發送頻率，其中，所述消息發送頻率用于表示在所述單位時間內向所述游戲服務器發送的消息的數量；根據所述分配的結果和所述設置的結果對所述游戲服務器的容量進行測試，并判斷所述測試的過程中所述模擬玩家發送的消息的響應時間和響應成功率是否符合所述第一預定條件、且判斷所述游戲服務器的空閑資源是否符合所述第二預定條件；若響應時間和響應成功率符合所述第一預定條件、且所述游戲服務器的空閑資源符合所述第二預定條件，則將所述當前數量進行增加，將增加后的結果作為所述當前數量；記錄單元，用于在響應時間和響應成功率不符合所述第一預定條件、或所述游戲服務器的資源不符合所述第二預定條件的情況下，則將前一次的當前數量記錄為所述同時在線的玩家的數量的最大值。

可選地，所述獲取模塊包括：獲取單元，用于分別獲取預定天數內的每天的所述消息指示信息；所述確定模塊包括：第五確定單元，用于根據每天的所述消息指示信息確定所述預定天數內的每天的平均消息發送頻率；并從所述預定天數內的每天的平均消息發送頻率中選取頻率值最大的平均消息發送頻率作為確定的所述平均消息發送頻率。

在本發明實施例中，采用的是獲取消息指示信息，其中，所述消息指示信息用于指示當前游戲的游戲服務器在預定時間段內接收到所述當前游戲中的不同玩家發送的消息；根據所述消息指示信息確定平均消息發送頻率，以及所述消息在不同目標功能場景下的消息占比，其中，所述平均消息發送頻率用于指示單位時間內單個玩家向所述游戲服務器發送的消息的數量，所述游戲中的功能場景包括多個所述目標功能場景；根據所述平均消息發送頻率和所述消息在不同目標功能場景下的消息占比對所述游戲服務器的容量進行測試，得到測試結果，其中，所述測試結果包括同時在線的玩家的數量的最大值的方式，即，在本發明中是根據真實的玩家數據確定的玩家平均消息發送頻率以及目標功能場景的占比，從而能夠得到準確的更為貼合實際的玩家的平均消息發送頻率以及目標功能場景的占比，以及能夠對不同的目標功能場景的使用頻次進行了差異化測試，從而對游戲服務器進行準確的容量評估，進而解決了相關技術中存在的服務器容量測試結果不準確的的技術問題。

附圖說明

此處所說明的附圖用來提供對本發明的進一步理解，構成本申請的一部分，本發明的示意性實施例及其說明用于解釋本發明，并不構成對本發明的不當限定。在附圖中：

圖1是相關技術的一種對游戲服務器的容量進行測試的玩家操作流程示意圖；

圖2是根據本發明實施例的一種對游戲服務器的容量進行測試的方法的應用環境示意圖；

圖3是根據本發明實施例的一種對游戲服務器的容量進行測試的方法的流程圖；

圖4是根據本發明實施例的在線玩家人數變化圖；

圖5是根據本發明實施例的全部消息的格式示意圖；

圖6是根據本發明實施例的目標消息的格式示意圖；

圖7是根據本發明實施例的目標功能場景的占比示意圖；

圖8是根據本發明實施例的對服務器進行測試的玩家模型示意圖；

圖9是根據本發明實施例的對服務器進行測試的整體流程圖；

圖10是根據本發明實施例對游戲服務器的容量進行測試的裝置的結構框圖；

圖11是根據本發明實施例對游戲服務器的容量進行測試的裝置中確定模塊1004的結構框圖(一)；

圖12是根據本發明實施例對游戲服務器的容量進行測試的裝置中確定模塊1004的結構框圖(二)；

圖13是根據本發明實施例對游戲服務器的容量進行測試的裝置中測試模塊1006的結構框圖；

圖14是根據本發明實施例對游戲服務器的容量進行測試的裝置中獲取模塊1002和確定模塊1004的結構框圖；

圖15是根據本發明實施例對游戲服務器的容量進行測試的服務器的示意圖。

具體實施方式

為了使本技術領域的人員更好地理解本發明方案，下面將結合本發明實施例中的附圖，對本發明實施例中的技術方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本發明一部分的實施例，而不是全部的實施例。基于本發明中的實施例，本領域普通技術人員在沒有做出創造性勞動前提下所獲得的所有其他實施例，都應當屬于本發明保護的范圍。

需要說明的是，本發明的說明書和權利要求書及上述附圖中的術語“第一”、“第二”等是用于區別類似的對象，而不必用于描述特定的順序或先后次序。應該理解這樣使用的數據在適當情況下可以互換，以便這里描述的本發明的實施例能夠以除了在這里圖示或描述的那些以外的順序實施。此外，術語“包括”和“具有”以及他們的任何變形，意圖在于覆蓋不排他的包含，例如，包含了一系列步驟或單元的過程、方法、系統、產品或設備不必限于清楚地列出的那些步驟或單元，而是可包括沒有清楚地列出的或對于這些過程、方法、產品或設備固有的其它步驟或單元。

實施例1

根據本發明實施例，提供了一種對游戲服務器的容量進行測試的方法，該方法可以應用于如圖2所示的環境中，其中，運行有游戲客戶端的終端202(實際操作時，202的數量可以多個的，與實際玩家數量對應，在圖2中僅示意性地繪制了一個)，通過網絡204與游戲客戶端對應的游戲服務器206進行交互。本實施例中的方法可以應用于服務器(例如，圖2所示的游戲服務器206)中。

在本實施例中，在對游戲服務器的容量進行測試時，需要構造玩家模型，也就是說，本實施例中所構造的玩家模型是基于服務器視角的玩家模型。在本實施例中，是利用大樣本的真實玩家數據所進行的平均值的統計分析，減少單個誤差，從而得到玩家的準確平均值(即，上述的平均消息發送頻率)和各游戲功能場景占比情況。

可選地，本實施例中的測試方法可以通過如下方式實現：通過采集游戲灰度測試期(即真實玩家游戲時)玩家在線高峰時期的一定時段內，服務器接收的該時段內所有玩家在線發送的消息數量，分析和統計確定該時段內的單個玩家的平均操作頻率(例如，平均消息發送頻率)，各游戲功能場景的在線玩家數量。然后模擬計算當有M個(M為正整數，例如5000、8000、10000)玩家同時在線時，且單個玩家的操作頻率為上述的平均操作頻率，以及各游戲功能場景的在線玩家數量按照統計結果進行分布時，對服務器的壓力，并在服務器存在空閑容量的情況下逐步增加壓力，以得到測試游戲服務器的容量結果。

需要說明的是，上述用于實施對游戲服務器的容量進行測試的服務器可以但不限于替換為具有大數據處理能力的硬件設備，如處理器，本實施例中對此不做任何限定。

可選地，在本實施例中，上述終端可以包括但不限于以下至少之一：手機、平板電腦、筆記本電腦、臺式PC機及其他安裝有游戲客戶端的終端。上述網絡可以包括但不限于以下至少之一：廣域網、城域網、局域網。上述只是一種示例，本實施例對此不做任何限定。

根據本發明實施例，提供了一種對游戲服務器的容量進行測試的方法，如圖3所示，該方法包括：

步驟S302，獲取消息指示信息，其中，該消息指示信息用于指示當前游戲的游戲服務器在預定時間段內接收到當前游戲中的不同玩家發送的消息；

步驟S304，根據上述消息指示信息確定平均消息發送頻率，以及上述消息在不同目標功能場景下的消息占比，其中，該平均消息發送頻率用于指示單位時間內單個玩家向游戲服務器發送的消息的數量，上述游戲中的功能場景包括多個目標功能場景；

步驟S306，根據上述平均消息發送頻率和上述消息在不同目標功能場景下的消息占比對游戲服務器的容量進行測試，得到測試結果，其中，該測試結果包括同時在線的玩家的數量的最大值。

其中，在本實施例中，消息指示信息可以是不同玩家所發送的具體消息，也可以是不同玩家所發送的具體消息的標識信息，或者是其他的能夠指示不同玩家所發送的具體消息的指示信息。本實施例中的當前游戲中的不同玩家為實際玩家，即，在游戲灰度測試期間實際進行游戲操作的用戶。利用真實玩家數據所得到的測試結果更貼合實際情況。

本實施例中的目標功能場景主要針對的是核心功能場景，也就是說從當前游戲的所有功能場景中確定出來的一些重要的功能場景，其中，在確定目標功能場景時，可以根據二八理論，選取最有價值的占比總和為80％(當然，根據實際情況，該比例是可以靈活調整的，不僅僅局限于80％。例如，可以調整為90％，調整為70％)的功能場景，需要說明的是，在進行目標功能場景的選擇時，可以是依據場景下的消息發送的數量來進行確定，相應地，可以選取最優價值的占比總和為80％的核心消息，然后可以根據需求加入部分消息，其中，該重要消息可以是核心消息需要依賴于的部分非核心消息，或者，根據經驗判斷，可能是涉及功能比較復雜，需要在容量測試中覆蓋的消息。

由上述步驟可知，在本實施例中是根據真實的玩家數據確定的玩家平均消息發送頻率以及目標功能場景的占比，從而能夠得到準確的更為貼合實際的玩家的平均消息發送頻率以及目標功能場景的占比，以及能夠對不同的目標功能場景的使用頻次進行了差異化測試，從而對游戲服務器進行準確的容量評估，進而解決了相關技術中存在的服務器容量測試結果不準確的的技術問題。

可選地，在本實施例中，在根據上述消息指示信息確定平均消息發送頻率時，可以通過如下方式確定：根據上述消息指示信息確定預定時間段內的平均在線玩家數量、以及上述游戲服務器在預定時間段內接收到的消息的總數；根據如下公式確定上述平均消息發送頻率：平均消息發送頻率＝消息的總數÷平均在線玩家數量÷預定時間段的時長。在本實施例中，預定時間段是一天中在線玩家人數最多的一個時間段，例如，圖4所示是0點至21點期間的在線玩家人數變化圖，從圖4可知，人數最多的時間段大概是在12:00-14:00期間，在13：00達到頂峰，在進行測試時，可以選取12:00-14:00間的一段時間，例如選取12:30-13:00作為測試時間段(即，上述的預定時間段)。上述的平均在線玩家數量是根據選取的測試時間段中的玩家人數流量確定的，例如當選取12:30-13:00作為測試時間段時，假設監測到12:30-12:40間的在線人數為1000，12:40-12:50間的在線人數為1100，12:50-13:00間的在線人數為1200，則，該測試時間段中的平均在線玩家數量為1100。

可選地，在本實施例中，在根據上述消息指示信息確定消息在不同目標功能場景下的消息占比時，可以通過如下方式確定：從上述消息的消息號中確定出多個目標消息號；根據該消息指示信息確定每個目標消息號下的目標消息的數量與消息的總數之間的比值，其中，該所述目標消息號的比值之和大于預定閾值(該預定閾值可以根據實際情況進行確定，例如75％、80％)且小于1；按比例將所有目標消息號的比值擴大至目標比值，其中，所有目標消息號的目標比值之和等于1；獲取每個目標功能場景對應的所有目標消息號的目標比值之和，作為消息在目標功能場景下的消息占比，其中，每個目標消息號對應一個目標功能場景。例如，全部消息(假定全部消息為消息1-消息21)可以如圖5所示，選取的目標消息(假定目標消息為消息1-消息13)可以如圖6所示，圖6中的消息占比一列為消息1-消息13在全部消息(即，消息1-消息21)中的占比，圖6中的測試消息占比一列為消息1-消息13分別在選取的目標消息(即，消息1-消息21)中的占比。在本實施例中，一個目標功能場景可能對應多種目標消息，因此，在確定一個目標功能場景在所有目標功能場景下的占比時，可以根據一個目標功能場景對應的多種消息在所有消息的占比之和來進行確定，具體可參考圖7。

可選地，根據上述平均消息發送頻率和消息在不同目標功能場景下的消息占比對游戲服務器的容量進行測試時，可以同如下方式實現：重復執行以下操作，直到模擬玩家發送的消息的響應時間和響應成功率不符合第一預定條件、或游戲服務器的空閑資源不符合第二預定條件：按照消息占比將當前數量的模擬玩家分別分配到每個目標功能場景中；將每個模擬玩家的消息發送頻率設置為平均消息發送頻率，其中，該消息發送頻率用于表示在單位時間內向游戲服務器發送的消息的數量；根據所述分配的結果和設置的結果對游戲服務器的容量進行測試，并判斷測試的過程中模擬玩家發送的消息的響應時間和響應成功率是否符合第一預定條件、且判斷游戲服務器的空閑資源是否符合第二預定條件；若響應時間和響應成功率符合第一預定條件、且游戲服務器的空閑資源符合第二預定條件，則將當前數量進行增加，將增加后的結果作為當前數量；若響應時間和響應成功率不符合第一預定條件、或游戲服務器的資源不符合第二預定條件，則將前一次的當前數量記錄為同時在線的玩家的數量的最大值。在本實施例中，在通過大樣本的真實玩家數據確定了平均消息發送頻率和消息在不同目標功能場景下的消息占比時，便可以利用確定的平均消息發送頻率和消息在不同目標功能場景下的消息占比對游戲服務器的容量進行測試，在進行測試時，可以利用模擬玩家(即，用于模擬實際玩家的機器人)進行測試，在測試的過程中可以按照確定的平均消息發送頻率和消息在不同目標功能場景下的消息占比對模擬玩家進行配置，并利用配置后的模擬玩家進行消息的發送，以實現對游戲服務器的容量的測試，從本實施例中的描述可知，在對游戲服務器的容量進行測試時，需要循環執行一些測試操作，直到確定出符合測試要求的同時在線的玩家的數量的最大值為止。上述的測試操作流程可以參考圖8，在圖8中，游戲核心功能場景總共有N個，transPer[i]表示第i個核心功能場景的占比；核心功能場景1中Message_ID1_1,Message_ID1_2,Message_ID1_J分別表示第1個核心功能場景的第1個消息標識(Identification，簡稱為ID)，第2個消息ID，第J個消息ID，并且核心功能場景1總共有J個消息；核心功能場景N中Message_IDN_1,Message_IDN_2,Message_IDN_k分別表示第N個核心功能場景的第1個消息ID，第2個消息ID，第k個消息ID，并且核心功能場景N總共有k個消息。圖8中所示的等待時間需要根據具體情況確定(例如，根據某個副本的通關時間)，圖8中所示的機器人即本實施例中所述的模擬玩家，在本實施例中可以假設機器人的總數為1萬(w)個。

可選地，在本實施例中，獲取上述消息指示信息包括：分別獲取預定天數內的每天的消息指示信息；根據上述消息指示信息確定平均消息發送頻率包括：根據每天的消息指示信息確定上述預定天數內的每天的平均消息發送頻率；并從上述預定天數內的每天的平均消息發送頻率中選取頻率值最大的平均消息發送頻率作為確定的平均消息發送頻率。也就是說，僅僅依據一天的測試結果來確定平均消息發送頻率可能是不準確的，因此，可以連續幾天(例如，三天)記錄在線玩家人數以及統計在線玩家發送的消息的數量，并綜合對比幾天的記錄來確定最終的平均消息發送頻率，例如，可以將幾天中確定的最大的平均消息發送頻率作為最終的消息發送頻率。

下面結合圖9對游戲服務器的容量測試方法進行描述，如圖9所示，該方法包括如下步驟：

S1，維持游戲服務器穩定運行至少3天，并且在服務器端記錄下這段時間內所有客戶端發送過來的消息。然后觀察這段時間內的在線玩家人數，如圖4所示，可以得到13:00期間，會達到一個玩家在線人數的峰值，記錄游戲的平均在線玩家數量。

S2，統計在線玩家人數峰值期間：起始時間為12:30，結束時間為13：00的半小時內，服務器接收到的全部在線玩家發送的消息數。數據格式可參考圖5。

S3，根據消息記錄統計數據，計算單個玩家的發包頻率(每分鐘的發包個數)。可以按照公式messNumPerM＝TotalMNums÷TotalPNums÷TotalMs計算單個玩家的發包頻率，其中，表示統計的消息數總和，TotalPNums表示統計的平均在線玩家數量，TotalMs表示統計的時間長度(單位：分鐘)，即可以得到單個玩家每分鐘發包個數。

S4，根據消息記錄統計數據，確定各個核心功能場景(對應于上述的目標功能場景)的占比。

在確定各個核心功能場景的占比時，可以首先選取核心消息列表(對應于上述的目標消息的列表)。如圖6所示，按照降序排列后，根據二八理論，選取最有價值的占比總和為80％的核心消息，然后再根據需求加入部分消息，需要加入的部分消息包括如下情況：1)核心消息需要依賴于的部分非核心消息。2)部分重要功能的消息，根據經驗判斷，可能是涉及功能比較復雜，需要在容量測試中覆蓋。然后將核心消息的占比做轉換，讓選取的消息占比為100％。

然后，分析核心功能場景和核心消息的所屬關系，計算出核心功能場景的占比。由于游戲中單個功能場景比較復雜，單個核心功能場景可能依賴于多條消息的配合使用。如圖7中所示，各核心功能場景的占比TransPer[i]可以通過如下公式確定：其中j表示屬于該游戲的核心功能場景i的消息ID。

S5，計算得到單個玩家發包頻率messNumPerM和核心游戲場景占比TransPer[i]后，在進行給定值PCU測試時，分配所有核心功能場景的機器人個數，并且設置好單個機器人的發包頻率。機器人的分配和不同核心功能場景的流程可參考圖8。

S6，選擇壓測工具，開發壓測腳本，并設置好同時在線人數為N時的各個參數，測試出當前壓力下，觀察所有消息的響應成功率，響應時間，以及服務器的各種資源消耗。如果成功率和響應時間都符合要求，同時服務器資源還有空閑。可逐步增加玩家總在線人數TotalNum后測試，并觀察結果，直至資源消耗遇到瓶頸導致消息成功率或者響應時間不達標，或者服務器資源沒有空閑為止。那么前一組最大同時測試結果符合要求的TotalNum即為服務器的單服最大承載人數PCU。

需要說明的是，對于前述的各方法實施例，為了簡單描述，故將其都表述為一系列的動作組合，但是本領域技術人員應該知悉，本發明并不受所描述的動作順序的限制，因為依據本發明，某些步驟可以采用其他順序或者同時進行。其次，本領域技術人員也應該知悉，說明書中所描述的實施例均屬于優選實施例，所涉及的動作和模塊并不一定是本發明所必須的。

通過以上的實施方式的描述，本領域的技術人員可以清楚地了解到根據上述實施例的方法可借助軟件加必需的通用硬件平臺的方式來實現，當然也可以通過硬件，但很多情況下前者是更佳的實施方式。基于這樣的理解，本發明的技術方案本質上或者說對現有技術做出貢獻的部分可以以軟件產品的形式體現出來，該計算機軟件產品存儲在一個存儲介質(如ROM/RAM、磁碟、光盤)中，包括若干指令用以使得一臺終端設備(可以是手機，計算機，服務器，或者網絡設備等)執行本發明各個實施例所述的方法。

實施例2

根據本發明實施例，還提供了一種用于實施上述對游戲服務器的容量進行測試的裝置，圖10是根據本發明實施例對游戲服務器的容量進行測試的裝置的結構框圖，如圖10所示，該裝置包括獲取模塊1002、確定模塊1004和測試模塊1006，下面對該裝置進行說明：

獲取模塊1002，用于獲取消息指示信息，其中，該消息指示信息用于指示當前游戲的游戲服務器在預定時間段內接收到當前游戲中的不同玩家發送的消息；

確定模塊1004，用于根據上述消息指示信息確定平均消息發送頻率，以及消息在不同目標功能場景下的消息占比，其中，該平均消息發送頻率用于指示單位時間內單個玩家向游戲服務器發送的消息的數量，上述游戲中的功能場景包括多個所述目標功能場景；

測試模塊1006，用于根據上述平均消息發送頻率和消息在不同目標功能場景下的消息占比對上述游戲服務器的容量進行測試，得到測試結果，其中，該測試結果包括同時在線的玩家的數量的最大值。

其中，在本實施例中，消息指示信息可以是不同玩家所發送的具體消息，也可以是不同玩家所發送的具體消息的標識信息，或者是其他的能夠指示不同玩家所發送的具體消息的指示信息。本實施例中的當前游戲中的不同玩家為實際玩家，即，在游戲灰度測試期間實際進行游戲操作的用戶。利用真實玩家數據所得到的測試結果更貼合實際情況。

本實施例中的目標功能場景主要針對的是核心功能場景，也就是說從當前游戲的所有功能場景中確定出來的一些重要的功能場景，其中，在確定目標功能場景時，可以根據二八理論，選取最有價值的占比總和為80％(當然，根據實際情況，該比例是可以靈活調整的，不僅僅局限于80％。例如，可以調整為90％，調整為70％)的功能場景，需要說明的是，在進行目標功能場景的選擇時，可以是依據場景下的消息發送的數量來進行確定，相應地，可以選取最優價值的占比總和為80％的核心消息，然后可以根據需求加入部分消息，其中，該重要消息可以是核心消息需要依賴于的部分非核心消息，或者，根據經驗判斷，可能是涉及功能比較復雜，需要在容量測試中覆蓋的消息。

由上述步驟可知，在本實施例中是根據真實的玩家數據確定的玩家平均消息發送頻率以及目標功能場景的占比，從而能夠得到準確的更為貼合實際的玩家的平均消息發送頻率以及目標功能場景的占比，以及能夠對不同的目標功能場景的使用頻次進行了差異化測試，從而對游戲服務器進行準確的容量評估，進而解決了相關技術中存在的服務器容量測試結果不準確的的技術問題。

圖11是根據本發明實施例對游戲服務器的容量進行測試的裝置中確定模塊1004的結構框圖(一)，如圖11所示，該確定模塊1004包括第一確定單元1102和第二確定單元1104，下面對該確定模塊1004進行說明：

第一確定單元1102，用于根據消息指示信息確定上述預定時間段內的平均在線玩家數量、以及游戲服務器在預定時間段內接收到的消息的總數；

第二確定單元1104，用于根據如下公式確定上述平均消息發送頻率：平均消息發送頻率＝消息的總數÷平均在線玩家數量÷預定時間段的時長。

在本實施例中，預定時間段是一天中在線玩家人數最多的一個時間段，例如，圖4所示是0點至21點期間的在線玩家人數變化圖，從圖4可知，人數最多的時間段大概是在12:00-14:00期間，在13：00達到頂峰，在進行測試時，可以選取12:00-14:00間的一段時間，例如選取12:30-13:00作為測試時間段(即，上述的預定時間段)。上述的平均在線玩家數量是根據選取的測試時間段中的玩家人數流量確定的，例如當選取12:30-13:00作為測試時間段時，假設監測到12:30-12:40間的在線人數為1000，12:40-12:50間的在線人數為1100，12:50-13:00間的在線人數為1200，則，該測試時間段中的平均在線玩家數量為1100。

圖12是根據本發明實施例對游戲服務器的容量進行測試的裝置中確定模塊1004的結構框圖(二)，如圖12所示，該確定模塊1004包括第三確定單元1202、第四確定單元1204、擴大單元1206和獲取單元1208，下面對該確定模塊1004進行說明：

第三確定單元1202，用于從消息的消息號中確定出多個目標消息號；

第四確定單元1204，用于根據消息指示信息確定每個目標消息號下的目標消息的數量與消息的總數之間的比值，其中，所有目標消息號的比值之和大于預定閾值且小于1；

擴大單元1206，用于按比例將所有目標消息號的比值擴大至目標比值，其中，所有目標消息號的目標比值之和等于1；

獲取單元1208，用于獲取每個目標功能場景對應的所有目標消息號的目標比值之和，作為上述消息在目標功能場景下的消息占比，其中，每個目標消息號對應一個目標功能場景。

在本實施例中全部消息(假定全部消息為消息1-消息21)可以如圖5所示，選取的目標消息(假定目標消息為消息1-消息13)可以如圖6所示，圖6中的消息占比一列為消息1-消息13在全部消息(即，消息1-消息21)中的占比，圖6中的測試消息占比一列為消息1-消息13分別在選取的目標消息(即，消息1-消息21)中的占比。在本實施例中，一個目標功能場景可能對應多種目標消息，因此，在確定一個目標功能場景在所有目標功能場景下的占比時，可以根據一個目標功能場景對應的多種消息在所有消息的占比之和來進行確定，具體可參考圖7。

圖13是根據本發明實施例對游戲服務器的容量進行測試的裝置中測試模塊1006的結構框圖，如圖13所示，該測試模塊1006包括執行單元1302和記錄單元1304，下面對該測試模塊1006進行說明：

執行單元1302，用于重復執行以下操作，直到模擬玩家發送的消息的響應時間和響應成功率不符合第一預定條件、或游戲服務器的空閑資源不符合第二預定條件：按照消息占比將當前數量的模擬玩家分別分配到每個目標功能場景中；將每個模擬玩家的消息發送頻率設置為平均消息發送頻率，其中，消息發送頻率用于表示在單位時間內向游戲服務器發送的消息的數量；根據分配的結果和設置的結果對游戲服務器的容量進行測試，并判斷測試的過程中模擬玩家發送的消息的響應時間和響應成功率是否符合第一預定條件、且判斷游戲服務器的空閑資源是否符合第二預定條件；若響應時間和響應成功率符合第一預定條件、且游戲服務器的空閑資源符合第二預定條件，則將當前數量進行增加，將增加后的結果作為當前數量；

記錄單元1304，用于在響應時間和響應成功率不符合第一預定條件、或游戲服務器的資源不符合第二預定條件的情況下，則將前一次的當前數量記錄為同時在線的玩家的數量的最大值。

在本實施例中，在通過大樣本的真實玩家數據確定了平均消息發送頻率和消息在不同目標功能場景下的消息占比時，便可以利用確定的平均消息發送頻率和消息在不同目標功能場景下的消息占比對游戲服務器的容量進行測試，在進行測試時，可以利用模擬玩家(即，用于模擬實際玩家的機器人)進行測試，在測試的過程中可以按照確定的平均消息發送頻率和消息在不同目標功能場景下的消息占比對模擬玩家進行配置，并利用配置后的模擬玩家進行消息的發送，以實現對游戲服務器的容量的測試，從本實施例中的描述可知，在對游戲服務器的容量進行測試時，需要循環執行一些測試操作，直到確定出符合測試要求的同時在線的玩家的數量的最大值為止。上述的測試操作流程可以參考圖8，在圖8中，游戲核心功能場景總共有N個，transPer[i]表示第i個核心功能場景的占比；核心功能場景1中Message_ID1_1,Message_ID1_2,Message_ID1_J分別表示第1個核心功能場景的第1個消息標識(Identification，簡稱為ID)，第2個消息ID，第J個消息ID，并且核心功能場景1總共有J個消息；核心功能場景N中Message_IDN_1,Message_IDN_2,Message_IDN_k分別表示第N個核心功能場景的第1個消息ID，第2個消息ID，第k個消息ID，并且核心功能場景N總共有k個消息。圖8中所示的等待時間需要根據具體情況確定(例如，根據某個副本的通關時間)，圖8中所示的機器人即本實施例中所述的模擬玩家，在本實施例中可以假設機器人的總數為1萬(w)個。

圖14是根據本發明實施例對游戲服務器的容量進行測試的裝置中獲取模塊1002和確定模塊1004的結構框圖，如圖14所示，獲取模塊1002包括獲取單元1402，確定模塊1004包括第五確定單元1404，下面對各單元進行說明：

獲取單元1402，用于分別獲取預定天數內的每天的消息指示信息；

第五確定單元1404，用于根據每天的消息指示信息確定預定天數內的每天的平均消息發送頻率；并從預定天數內的每天的平均消息發送頻率中選取頻率值最大的平均消息發送頻率作為確定的平均消息發送頻率。

在本實施例中，僅僅依據一天的測試結果來確定平均消息發送頻率可能是不準確的，因此，可以連續幾天(例如，三天)記錄在線玩家人數以及統計在線玩家發送的消息的數量，并綜合對比幾天的記錄來確定最終的平均消息發送頻率，例如，可以將幾天中確定的最大的平均消息發送頻率作為最終的消息發送頻率。

實施例3

根據本發明實施例，還提供了一種用于實施上述對游戲服務器的容量進行測試的服務器，如圖15所示，該服務器包括：

通訊接口1502，用于獲取消息指示信息，其中，消息指示信息用于指示當前游戲的游戲服務器在預定時間段內接收到當前游戲中的不同玩家發送的消息；

處理器1504，用于根據消息指示信息確定平均消息發送頻率，以及消息在不同目標功能場景下的消息占比，其中，平均消息發送頻率用于指示單位時間內單個玩家向游戲服務器發送的消息的數量，游戲中的功能場景包括多個目標功能場景；以及，根據平均消息發送頻率和消息在不同目標功能場景下的消息占比對游戲服務器的容量進行測試，得到測試結果，其中，測試結果包括同時在線的玩家的數量的最大值。

可選地，本實施例中的具體示例可以參考上述實施例1和實施例2中所描述的示例，本實施例在此不再贅述。

實施例4

本發明的實施例還提供了一種存儲介質。可選地，在本實施例中，上述存儲介質可以位于網絡中的多個網絡設備中的至少一個網絡設備。

可選地，在本實施例中，存儲介質被設置為存儲用于執行以下步驟的程序代碼：

S1，用于獲取消息指示信息，其中，消息指示信息用于指示當前游戲的游戲服務器在預定時間段內接收到當前游戲中的不同玩家發送的消息；

S2，用于根據消息指示信息確定平均消息發送頻率，以及消息在不同目標功能場景下的消息占比，其中，平均消息發送頻率用于指示單位時間內單個玩家向游戲服務器發送的消息的數量，游戲中的功能場景包括多個目標功能場景；

S3，根據平均消息發送頻率和消息在不同目標功能場景下的消息占比對游戲服務器的容量進行測試，得到測試結果，其中，測試結果包括同時在線的玩家的數量的最大值。

可選地，存儲介質還被設置為存儲用于執行以下步驟的程序代碼：

S1，根據消息指示信息確定預定時間段內的平均在線玩家數量、以及游戲服務器在預定時間段內接收到的消息的總數；

S2，根據如下公式確定平均消息發送頻率：平均消息發送頻率＝消息的總數÷平均在線玩家數量÷預定時間段的時長。

可選地，存儲介質還被設置為存儲用于執行以下步驟的程序代碼：

S1，從消息的消息號中確定出多個目標消息號；

S2，根據消息指示信息確定每個目標消息號下的目標消息的數量與消息的總數之間的比值，其中，所有目標消息號的比值之和大于預定閾值且小于1；

S3，按比例將所有目標消息號的比值擴大至目標比值，其中，所有目標消息號的目標比值之和等于1；

S4，獲取每個目標功能場景對應的所有目標消息號的目標比值之和，作為消息在目標功能場景下的消息占比，其中，每個目標消息號對應一個目標功能場景。

可選地，存儲介質還被設置為存儲用于執行以下步驟的程序代碼：

S1，重復執行以下操作，直到模擬玩家發送的消息的響應時間和響應成功率不符合第一預定條件、或游戲服務器的空閑資源不符合第二預定條件：按照消息占比將當前數量的模擬玩家分別分配到每個目標功能場景中；將每個模擬玩家的消息發送頻率設置為平均消息發送頻率，其中，消息發送頻率用于表示在單位時間內向游戲服務器發送的消息的數量；根據分配的結果和設置的結果對游戲服務器的容量進行測試，并判斷測試的過程中模擬玩家發送的消息的響應時間和響應成功率是否符合第一預定條件、且判斷游戲服務器的空閑資源是否符合第二預定條件；若響應時間和響應成功率符合第一預定條件、且游戲服務器的空閑資源符合第二預定條件，則將當前數量進行增加，將增加后的結果作為當前數量；

S2，若響應時間和響應成功率不符合第一預定條件、或游戲服務器的資源不符合第二預定條件，則將前一次的當前數量記錄為同時在線的玩家的數量的最大值。

可選地，存儲介質還被設置為存儲用于執行以下步驟的程序代碼：

S1，分別獲取預定天數內的每天的消息指示信息；

S2，根據每天的消息指示信息確定預定天數內的每天的平均消息發送頻率；并從預定天數內的每天的平均消息發送頻率中選取頻率值最大的平均消息發送頻率作為確定的平均消息發送頻率。

可選地，在本實施例中，上述存儲介質可以包括但不限于：U盤、只讀存儲器(Read-Only Memory，簡稱為ROM)、隨機存取存儲器(Random Access Memory，簡稱為RAM)、移動硬盤、磁碟或者光盤等各種可以存儲程序代碼的介質。

可選地，本實施例中的具體示例可以參考上述實施例1和實施例2中所描述的示例，本實施例在此不再贅述。

需要說明的是，上述各實施例主要描述的是對游戲服務器的容量進行測試的方案，上述各實施例中的方案也可以應用到其他類型的服務器的容量測試中。

通過本發明各實施例中的方案，能夠準確地模擬線上玩家行為，測試出較為準確地服務器容量結果，讓玩家在享受到流暢服務的同時，還能夠最大化地利用服務器資源。

上述本發明實施例序號僅僅為了描述，不代表實施例的優劣。

上述實施例中的集成的單元如果以軟件功能單元的形式實現并作為獨立的產品銷售或使用時，可以存儲在上述計算機可讀取的存儲介質中。基于這樣的理解，本發明的技術方案本質上或者說對現有技術做出貢獻的部分或者該技術方案的全部或部分可以以軟件產品的形式體現出來，該計算機軟件產品存儲在存儲介質中，包括若干指令用以使得一臺或多臺計算機設備(可為個人計算機、服務器或者網絡設備等)執行本發明各個實施例所述方法的全部或部分步驟。

在本發明的上述實施例中，對各個實施例的描述都各有側重，某個實施例中沒有詳述的部分，可以參見其他實施例的相關描述。

在本申請所提供的幾個實施例中，應該理解到，所揭露的客戶端，可通過其它的方式實現。其中，以上所描述的裝置實施例僅僅是示意性的，例如所述單元的劃分，僅僅為一種邏輯功能劃分，實際實現時可以有另外的劃分方式，例如多個單元或組件可以結合或者可以集成到另一個系統，或一些特征可以忽略，或不執行。另一點，所顯示或討論的相互之間的耦合或直接耦合或通信連接可以是通過一些接口，單元或模塊的間接耦合或通信連接，可以是電性或其它的形式。

所述作為分離部件說明的單元可以是或者也可以不是物理上分開的，作為單元顯示的部件可以是或者也可以不是物理單元，即可以位于一個地方，或者也可以分布到多個網絡單元上。可以根據實際的需要選擇其中的部分或者全部單元來實現本實施例方案的目的。

另外，在本發明各個實施例中的各功能單元可以集成在一個處理單元中，也可以是各個單元單獨物理存在，也可以兩個或兩個以上單元集成在一個單元中。上述集成的單元既可以采用硬件的形式實現，也可以采用軟件功能單元的形式實現。

以上所述僅是本發明的優選實施方式，應當指出，對于本技術領域的普通技術人員來說，在不脫離本發明原理的前提下，還可以做出若干改進和潤飾，這些改進和潤飾也應視為本發明的保護范圍。