リプレイ/障害注入

プロキシモードや通常のスタブ動作で記録したキャプチャを「シナリオ」として保存し、実機なしで決定論的に再生します。加えて送信に障害(遅延・ロス・切断)を注入することで、テスト対象アプリのタイムアウト処理・リトライ動作・異常系ハンドリングを検証できます。

まず試すならリプレイ/障害注入を試す(設備の間欠障害)。録画済みシナリオを同梱しており、実機なしで「開く → 再生 → 障害注入」を通しで試せる手順ガイドです。

概要

シナリオ録画・決定論リプレイは次の2段階で使います。

  1. 録画(ログ記録 → シナリオ保存)
    プロキシモードで実機とアプリ間の通信を中継しながらログペインに記録し、「シナリオとして保存」ボタンで .commscenario ファイルに書き出す。スタブ動作時の記録も同様に保存できる。
  2. 再生(シナリオ読込 → リプレイ)
    「リプレイ」タブ(セッションの5番目タブ)でシナリオを読み込み、再生する。CommSim が実機の代わりに録画通りの応答を返す。
テスト対象アプリ下流
CommSimシナリオを再生
⇠ 実機不要
実機録画時のみ使用

「障害注入」タブ(6番目タブ)を組み合わせると、CommSim がシナリオの応答を返す際に意図的に遅延・ロス・切断を起こし、テスト対象アプリが異常系を正しく処理するかを確認できます。障害注入はリプレイ専用ではなくセッション全体に効く設定のため、独立したタブに置いています(詳細)。

リプレイタブ:シナリオ読込・再生モード・速度・再生/停止ボタン・進行表示

シナリオの保存と読込

シナリオとして保存する

  1. 画面下部のログ常設ペインを見る。
  2. 記録が十分に溜まったところで「シナリオとして保存」ボタンをクリックする。
  3. ファイル保存ダイアログが開く。任意の場所に .commscenario という拡張子で保存する。

シナリオファイル(.commscenario)はプロジェクトファイル(.commsim)とは独立した JSON ファイルです。プロジェクトをまたいで使い回せます。

シナリオを読み込む

  1. 「リプレイ」タブ(5番目タブ)を開く。
  2. シナリオを開く」ボタンをクリックし、保存済みの .commscenario ファイルを選択する。
  3. 読み込まれたシナリオの名前・ステップ数が表示される。

再生モード

再生モードは2種類あります。通信パターンに合わせて選択します。

モード動作向いているシナリオ
対話モード(既定) テスト対象アプリからの受信を待ち合わせ、録画上の対応する応答を相対遅延つきで返す。CommSim が実機役として振る舞う。 要求-応答型の往復通信(コマンド → 応答 → コマンド → 応答 …)
素(す)モード 受信を待たず、録画した「機器→アプリ」方向のパケットを時刻順にそのまま送出する。 センサからの周期テレメトリなど、一方向の定期送出

対話モードのシーケンスイメージ

  • RXアプリ → CommSim: リクエスト A受信を待ち合わせ
  • TXCommSim → アプリ: レスポンス A録画の対応応答を相対遅延つきで返す
  • RXアプリ → CommSim: リクエスト B次の受信を待ち合わせ
  • TXCommSim → アプリ: レスポンス B録画の対応応答を返す

素モードのシーケンスイメージ

  • TXCommSim → アプリ: テレメトリ 1録画時刻順に送出
  • TXCommSim → アプリ: テレメトリ 2
  • TXCommSim → アプリ: テレメトリ 3

対話モードで受信パケットが録画上の期待パケットと一致しない場合、またはタイムアウトした場合は、ログと進行表示にその旨が表示されます。一致しなくても次のステップへ進む(寛容モード)か停止するか(厳格モード)は設定で選択できます。

再生速度

録画時の実時間タイミングに対して再生速度を倍率で指定します。

設定値動作
等倍(×1)録画通りの実時間で再生する
スロー(×0.5)録画の2倍の時間をかけて再生する
高速(×2)録画の半分の時間で再生する
超高速(×5)録画の5分の1の時間で再生する
即時遅延なしで可能な限り高速に送出する

実時間タイミングはベストエフォートです。システムの負荷状況によって ±数十 ms の誤差が生じることがあります。厳密なタイミング試験が必要な場合は等倍再生を基本としてください。

進行表示

リプレイの進行状況はタブ内に常時表示されます。

表示内容
ステップ N / M現在のステップ番号と総ステップ数
受信待ち対話モードで次の受信を待っている状態
実行中送信ステップを実行している状態
完了すべてのステップが正常に終了した
停止「停止」ボタンまたは異常により中断した

対話モードで受信が期待と一致しなかった場合、またはタイムアウトした場合は、進行表示とログペインに警告が記録されます。

障害注入

障害注入」タブ(セッションの6番目タブ)で「障害注入を有効にする」をオンにすると、CommSim からアプリへの送信に意図的な障害(遅延・ゆらぎ・ロス・切断)を加えられます。

障害注入はリプレイ専用の機能ではありません。設定はセッション単位で効き、下流(テスト対象アプリ側)へ出る全送信——オートメーション・バイナリ構造応答・リプレイ・手動送信・中継時に実機から受けてアプリへ返すデータ——に等しく適用されます。リプレイを使っていなくても、通常のスタブ動作のまま「応答が遅い/たまに落ちる」状況を作れます。
(中継時にアプリから実機へ転送するデータは対象外です。)

障害注入タブ:障害注入を有効にするチェック、ロス率・シード・遅延・ゆらぎ・切断の各入力欄と適用範囲の説明
障害注入タブ(6番目タブ)。適用範囲の説明が欄の下に常時表示される。
設定項目説明
ロス率(%) 指定した確率でパケットをドロップする。0 = ドロップなし / 100 = 全パケットをドロップ
遅延(ms) 送信前に加える固定の遅延時間
ゆらぎ(ms) 遅延に加えるランダムな上乗せ幅(0〜指定値の一様乱数)。ネットワークジッタの模倣
切断(送信 N 回で) 指定した送信回数に達したとき接続を切断する。0 = 切断なし
シード 乱数シード値。同じシードを使うと毎回同じ壊れ方になる(決定論)。異なるシードで多様な障害パターンを試せる

障害注入のシーケンスイメージ

  • RXアプリ → CommSim: リクエスト
  • TXCommSim → アプリ: レスポンス(遅延あり)遅延 + ゆらぎを付加して送出
  • RXアプリ → CommSim: リクエスト
  • --(ドロップ)ロス率により送出をスキップ
  • RXアプリ → CommSim: リトライアプリがタイムアウトを検知してリトライ
  • TXCommSim → アプリ: レスポンス

障害設定の適用タイミング

セッション起動中でも、値を変えた時点ですぐ反映されます。停止・再起動は不要です。反映したときは設定欄の下に現在値のサマリが出て、ログにも1行記録されるので「今どの条件で流しているか」を後から追えます。

シードだけは起動中に変更できません。乱数列の途中で種を変えると「同じシードなら同じ壊れ方」という決定論が崩れるためです。シードを変えたいときはセッションを停止してから設定してください。
なお、遅延やロス率を途中で変えても切断カウンタ(送信 N 回で切断)はリセットされません。カウンタを最初から数え直したいときもセッションを停止してください。

注入対象

障害注入は下流(テスト対象アプリ側)へ出る送信に適用されます。中継(プロキシ)動作では、実機から受けてアプリへ返すデータには適用されますが、アプリから実機へ転送するデータには適用されません(実機への入力は改変しない、という方針です)。

他のツールとの違い

ネットワーク障害だけを再現するなら Clumsy(Windows)・tc netem(Linux)・Toxiproxy といったツールもあります。CommSim の障害注入がそれらと違うのは、スタブの応答内容と障害条件を同じ画面で同時に決められる点です。

  • 応答と障害がひとつのプロジェクトに残る — 「この応答定義+このシード+この遅延」の組み合わせを .commsim に保存でき、同僚に渡せば同じ条件で再現できます。OS の設定やプロキシ設定を別途共有する必要がありません。
  • 実機なしで完結する — 通信相手そのものを CommSim が務めるため、障害を入れるための中継先(実機やサーバ)を用意する必要がありません。
  • ログが1本に揃う — 落としたパケット・遅らせた送信も、通常の送受信と同じログに時系列で並びます。別ツールのログと突き合わせる手間がありません。
  • シードで決定論的に再現できる — 同じシードなら同じ順序で同じパケットが落ちます。「たまに再現するバグ」を毎回同じ形で出せます。

逆に、TCP/IP スタックそのものの挙動(パケット並べ替え・帯域制限・ルーティング障害)を再現したい場合は、専用のネットワークエミュレータのほうが適しています。CommSim が扱うのはアプリケーション層の送信単位です。

注意事項・制限

リプレイが使えるセッション

リプレイは次の条件を満たすセッションでのみ使用できます。

  • 起動中のセッションであること
  • 転送先(上流)が設定されていない(スタブとして動作中)こと

転送先ありのセッション(中継動作)ではリプレイは使用できません。タブ内にその旨が表示されます。実機との中継中にリプレイを重ねると応答の二重送信が起きるためです。

リプレイ中の制限(オートメーション・バイナリ構造応答との排他)

受信に応答を返す仕組みは、「オートメーション+バイナリ構造応答」か「リプレイ」のどちらか片方だけが動きます。リプレイ実行中は次の機能が抑止されます。

  • オートメーション — トリガーによる自動送信・自動応答が抑止されます
  • バイナリ構造応答 — フィールド条件にマッチしても応答しません
  • 手動送信(画面最下部の手動送信バー) — ボタンが無効になります

これらが同時に応答を返すと「二重応答」になり、シナリオどおりの再生ができなくなるためです。

リプレイ実行中は、タブヘッダのバッジ(「自動応答(停止中)」「リプレイ(▶ 実行中)」)で、どのタブを開いていても排他状態だと分かります。「自動応答」タブを開くと案内バーが出て、そこの「リプレイを停止」で通常動作へ戻せます。ヘッダの「リプレイ中」バッジにも停止ボタンが併設されているので、リプレイタブへ移動しなくてもその場で止められます。オートメーションやバイナリ構造応答が「有効なのに反応しない」ときは、まずタブヘッダのバッジを確認してください。

タイミングの精度

再生タイミングはベストエフォートです。システムの負荷によって実際の送出タイミングが録画より数十 ms 前後することがあります。正確なタイミング要件がある場合はテスト計画に余裕を持たせてください。

次に読む