メインコンテンツまでスキップ
バージョン: 1.3.0

テスト実行方法

image

概要

image

テスト実行用プログラムはサーバープログラムとクライアントプログラムに大別されます。 図のように、サーバー稼働 PC の上で動作する 1 つのサーバープロセスに対して、複数のクライアント稼働 PC 上で動作する複数のクライアントプロセスが接続するというサーバー・クライアント型構成になっています。

そのためテスト実行時には以下作業を順番に行います。

  1. サーバー稼働 PCサーバープロセス起動コマンド1 回 実行
  2. 複数のクライアント稼働 PC複数クライアントプロセスの起動コマンド1 回 実行

実行手順 の章では同一の PC でサーバープロセスとクライアントプロセスを動かす手順を説明します。 コマンド実行例 の章では、複数マップの連続テストや、複数 PC でサーバープロセスとクライアントプロセスを別々に動かす場合のコマンド実行例を載せています。

実行手順

1. サーバープロセスの起動

まず動かしてみるための例として、サーバープロセスとクライアントプロセスを同じ PC 上で稼働する場合のコマンド例を示します。

$ cd Python
$ conda activate collisionchecker
$ python svrun_server.py -n 5 -m PL_010VIL -d ./data/alfort/

パラメータ
-n 最大同時接続数
-m テストマップ
-d 本テストバージョンに対応するデータが格納されたフォルダ (./data 以下のフォルダいずれか) のパス

サーバープロセスを起動すると Python/result/ フォルダに YYYYMMDDhhmm (プロセス実行日時を表す数字列) という名前のフォルダが生成されます。

フォルダ内には以下のファイルが生成されていきます。

  • pickle ファイル

    • テスト進捗データとテスト結果データのメモリデータが格納されており、サーバーの一時停止、またはマップ毎のテスト完了時に生成されます。
    • サーバーを一時停止した後に途中からテストを再開する際は、実行オプション (後述) で親フォルダ名である YYYYMMDDhhmm を指定します。
    • ファイル名規則は {テスト番号}_{マップ名}__coltest_data_server_progress.pickle です。
  • json ファイル

    • テスト結果データが格納されており、サーバーの一時停止、またはマップ毎のテスト完了時に生成されます。
    • ビューワーでこのファイルを読み込んでテスト結果を可視化します。
    • ファイル名規則は {テスト番号}_{マップ名}__reach_log.json です。
  • log ファイル

    • サーバープロセスのログ出力が格納されています。
    • ファイル名は coltest_data_server.log です。

2. クライアントプロセスの起動

手順 1 に引き続き、サーバープロセスとクライアントプロセスを同じ PC 上で稼働する場合を例とします。 手順 1 の後に別のコンソールを立ち上げ、以下のコマンドを実行します。

$ cd Python
$ conda activate collisionchecker
$ python svrun_client.py -n 5 -d ./data/alfort/

パラメータ
-n プロセス起動数
-d 本テストバージョンに対応するデータが格納されたフォルダ (./data 以下のフォルダいずれか) のパス

クライアントプロセスを起動すると Python/result/ フォルダ内に YYYYMMDDhhmm (プロセス実行日時を表す数字列) という名前のフォルダが生成されます。

フォルダ内には以下のファイルが生成されていきます。

  • log ファイル
    • クライアントプロセスのログ出力が格納されています。
    • ファイル名規則は {プロセス起動番号}.log です。

3. プロセスの定期監視

各稼働 PC の負荷監視

タスクマネージャーを起動し、CPU / GPU / メモリの負荷を確認します。
クライアント稼働 PC についてはゲーム起動時に CPU 負荷が高くなる傾向があるため、 平均 CPU 使用率が 70% 程度になるようにゲーム並列数を調整することを推奨します。

サーバーログの監視

サーバー稼働 PC についてはサーバーログを監視するとよいです。デフォルト設定では 2 分間隔で以下の例に示すようなログ出力されます。

テストが正常に動いているかどうかは、以下の値に着目することで判断できます。

  • FPS 値 秒間のメインループ処理回数です。 正常時はゲームのフレームレートに近い数値が表示されますが、この値が著しく低下している (例えば 1 以下) 場合はサーバープロセスが正しく動作していない可能性が高いです。

  • タイムプロファイル FPS 値が低下している際には各処理のタイムプロファイルを確認し、どの処理がボトルネックになっているかを確認できます。

# ログ日時
2022/04/08-20:51
# テスト対象マップ名 衝突済みの目標点数/総目標点数 (未衝突数, 衝突中数, 衝突済み数)
PL_010VIL tested=178 / total=619 (not_tested=413, testing=28, tested=178)
# 秒間のメインループ処理回数
FPS=32.76
# 前回のログ出力以降にクライアントから受信したデータ数
result_total_cnt=570
# 現在接続しているクライアントプロセス数
connectiong_clients=36
# 以降、各処理のタイムプロファイル
# {処理キーワード, 前回のログ出力以降に各処理に割かれた時間} の形式
# 受信処理のタイムプロファイル
key=Recv, elapsed_sec=2.471668243408203
# 通信プロトコル (C2S_REQUEST_AGENT_ID) 受信処理のタイムプロファイル
key=C2S_REQUEST_AGENT_ID, elapsed_sec=0.0
# 通信プロトコル (C2S_REQUEST_MAP_INFO) 受信処理のタイムプロファイル
key=C2S_REQUEST_MAP_INFO, elapsed_sec=0.0
# 通信プロトコル (C2S_REQUEST_TARGET_INFO) 受信処理のタイムプロファイル
key=C2S_REQUEST_TARGET_INFO, elapsed_sec=0.0
# 通信プロトコル (C2S_NOTICE_START_CHECK) 受信処理のタイムプロファイル
key=C2S_NOTICE_START_CHECK, elapsed_sec=0.0
# 通信プロトコル (C2S_NOTICE_POSITION) 受信処理のタイムプロファイル
key=C2S_NOTICE_POSITION, elapsed_sec=1.3314945697784424
# 到達点管理クラスのデータ処理関数実行時間
key=Reach_UpdateAgent_InRecv, elapsed_sec=0.9931182861328125
# 通信プロトコル (C2S_NOTICE_END_CHECK) 受信処理のタイムプロファイル
key=C2S_NOTICE_END_CHECK, elapsed_sec=0.0
# 通信プロトコル (C2S_NOTICE_RESTART) 受信処理のタイムプロファイル
key=C2S_NOTICE_RESTART, elapsed_sec=0.0
# 通信プロトコル (C2S_NOTICE_LACK_COLLISION) 受信処理のタイムプロファイル
key=C2S_NOTICE_LACK_COLLISION, elapsed_sec=0.0

コマンド実行オプション

サーバープログラム

$ cd Python
$ conda activate collisionchecker
$ python svrun_server.py -n 5 -m PL_010VIL PL_020RIV -d ./data/alfort/ -u 202201071258 --addr 127.0.0.1 --port 8050

パラメータ
-n --listennum 最大同時接続数
-m --map テストマップ名 (複数入力した場合は順次テスト)
-d --datafolder 本テストバージョンに対応するデータが格納されたフォルダのパス (必須)
-u --timeuuid 再実行する際のメモリデータ pickle 識別番号 (途中から再開する時以外は省略可)
--addr サーバーListenアドレス (サーバー、クライアントを同一 PC で実行する場合は省略可)
--port サーバーListenポート (サーバー、クライアントを同一 PC で実行する場合は省略可)

クライアントプログラム

$ cd Python
$ conda activate collisionchecker
$ python svrun_client.py -n 5 -d ./data/alfort/ --logfolder ./result/ --envresx 320 --envresy 180 --envaddr 127.0.0.1 --envport 8000 --svaddr 127.0.0.1 --svport 8050

パラメータ
-n --num プロセス起動数
-d --datafolder 本テストバージョンに対応するデータが格納されたフォルダのパス (必須)
--logfolder ログ出力フォルダ (省略可)
--envresx ゲーム解像度横幅 (省略可)
--envresy ゲーム解像度縦幅 (省略可)
--envaddr ゲーム通信アドレス (省略可)
--envport ゲーム通信ポート (省略可)
--svaddr サーバー接続アドレス (サーバー、クライアントを同一 PC で実行する場合は省略可)
--svport サーバー接続ポート (サーバー、クライアントを同一 PC で実行する場合は省略可)

コマンド実行例

例: 複数マップテスト

条件設定:

  • サーバープロセスとクライアントプロセスが同じ PC で稼働する

目的:

  • 複数マップのテストを順次実行する

サーバー側:

$ cd Python
$ conda activate collisionchecker
$ python svrun_server.py -n 30 -m PL_010VIL PL_020RIV -d ./data/alfort/

パラメータ
-n 最大同時接続数
-m テストマップ (PL_010VIL -> PL_020RIV の順番でテストが行われる)
-d 本テストバージョンに対応するデータが格納されたフォルダのパス

クライアント側:

(手順 2 と同じ)

例: テストの再実行

条件設定:

  • サーバープロセスとクライアントプロセスが同じ PC で稼働する
  • テスト中にサーバープロセスを一時停止した
  • 再実行するために読み込む pickle データは result/202201071258 フォルダにあるものを使用

目的:

  • 一時停止したところからテストを再開する

サーバー側:

$ cd Python
$ conda activate collisionchecker
$ python svrun_server.py -n 15 -m PL_010VIL -d ./data/alfort/ -u 202201071258

パラメータ
-n 最大同時接続数
-m テストマップ
-d 本テストバージョンに対応するデータが格納されたフォルダのパス
-u 再実行する際のメモリデータ pickle 識別番号

クライアント側:

(手順 2 と同じ)

例: 複数 PC を用いた並列テスト

条件設定:

  • サーバープロセスとクライアントプロセスが別々の PC で稼働する
  • サーバー稼働 PC の IP アドレス は 192.168.20.157

目的:

  • クライアントプロセス数を増やしてテスト時間を短くする

サーバー側:

$ cd Python
$ conda activate collisionchecker
$ python svrun_server.py -n 160 -m PL_010VIL -d ./data/alfort/ --addr 0.0.0.0 --port 8050

パラメータ
-n 最大同時接続数
-m テストマップ
-d 本テストバージョンに対応するデータが格納されたフォルダのパス
--addr サーバー Listen アドレス (任意のアドレスから受け付ける場合は 0.0.0.0)
--port サーバー Listen ポート

クライアント側:

$ cd Python
$ conda activate collisionchecker
$ python svrun_client.py -n 5 -d ./data/alfort/ --svaddr 192.168.20.157 --svport 8050

パラメータ
-n プロセス起動数
-d 本テストバージョンに対応するデータが格納されたフォルダのパス
--svaddr サーバー接続アドレス
--svport サーバー接続ポート