ファジングにおける相互運用性の課題

ファジングにおける相互運用性の課題を克服する方法を理解することは、効率的で包括的なテスト結果を確保するのに役立ちます。

図 1: Defensics interoperability testing ビュー

ただし、ファジングを始める前に、ファザーと SUT の相互運用性を確保することが重要です。これは、SUT が異常な入力だけでなく通常の入力も処理できる状態になるようにするためです。SUT が正しい状態にない場合、ファジングを実行できない可能性があります。

有効なテストケース

送信されたメッセージと予期される応答を含むプロトコル・メッセージがテストケースを構成します。Defensics の用語では、異常のないメッセージを valid message（有効なメッセージ）と呼びます。したがって、有効なメッセージのみを含むテストケースは、valid test case（有効なテストケース）、または略して valid case（有効なケース）と呼ばれます。

たとえば、Bluetooth AVRCP プロトコルの有効なテストケースの 1 つは、Get Capability 要求メッセージと予期される Capability 応答を持っています。 テストシーケンスには、要求メッセージ、応答メッセージ、およびテスト対象への L2CAP 接続を設定するために必要なメッセージが含まれます。

図 2: Defensics Bluetooth AVRCP test suites の Get Capability テスト シーケンス

多くのプロトコルでは、通信コンポーネントの役割がメッセージの種類と予想される通信の方向に影響します。たとえば、サーバー方向のテスト中に、クライアント側が通信を開始すると想定されます。サーバーの役割は、プロトコルに応じて、コントローラー、ゲートウェイ、セントラル、またはアクセスポイントと呼ばれることもあります。クライアントの指示中は、テスト対象が通信を開始すると想定されます。

通常、Defensics には役割ごとに独自のテストスイートがあります。 AVRCP の例では、サーバーターゲットをテストする Defensics Bluetooth AVRCP test suite が左側にあり、クライアントターゲットをテストする Defensics Bluetooth AVRCP controller test suite が右側にあります。 Defensics test suite によってテストされたすべてのプロトコルメッセージは、テストスイートのデータシートにリストされています。

図 3: Defensics Bluetooth AVRCP controller test suite の test case ビューに AVRCP Get Capability valid test case を表示している

相互運用性のチェック

ユーザーがテストターゲットに対して相互運用性チェックを実行する場合、各テストグループから有効なテストケースを実行することによってチェックが実行されます。テストターゲットが有効なテストケースに対して期待した応答を返した場合、有効なテストケースの相互運用性チェックは合格です。有効なケースが失敗した場合は、テストターゲットがその機能をサポートしていない、機能が有効になっていない、テストターゲットまたはテストスイートの構成が正しくない、またはタイムアウトが短すぎる可能性があります。

いずれの場合も、有効なテストケースが合格しない場合、SUT は異常メッセージを受信できる正しい状態にないか、すべての異常メッセージを受信しません（マルチメッセージ テスト ケースの場合）。 相互運用性チェックの結果に基づいて、失敗したテストグループをテスト計画から除外して、テスト時間を短縮することができます。

図 4: Defensics Bluetooth LE link layer test suite との相互運用性テストにより、テスト対象で暗号化がサポートされていないことが示された

プロトコル内のオプションのメッセージ、特定のタイプのテスト ターゲットでのみ使用されるメッセージ、およびプロトコルのバージョンが異なるため、テストターゲットは多くの場合、すべてのプロトコルメッセージをサポートしません。相互に排他的なテストケースが存在する場合もあります。テストターゲットが 1 つのタイプのメッセージトランスポート チャネル（TCP など）をサポートしていない場合、別のタイプのチャネル（UDP など）は同時にサポートされません。

Client direction testing は、通信を開始するためにユーザーのアクションが必要な場合があり、サポートされる機能がより制限されていることが多いため、相互運用性の点でより困難です。たとえば、Bluetooth クライアントの場合、ユーザーは接続を選択してアクションを開始する必要がある場合があります。 このような場合、手動操作ではタイムアウトが発生する可能性があるため、テストを効率的に行うためにスクリプトを作成する必要があります。

プロトコルパラメーター、期待される応答、メッセージングの順序、またはファザーとテストターゲット間のメッセージングのタイミングを変更することで、相互運用性を高めることができる場合があります。 次のセクションでは、テストターゲットのさまざまなニーズに対応するために Defensics が提供する構成方法を要約します。

シーケンスファイルと設定

有効なテストケースは、シーケンスファイルと呼ばれる XML 形式のファイルで提供されます。テストスイートは、SUT のさまざまなプロトコル機能と機能の相互運用性チェックを実行するために複数のシーケンスファイルを提供する場合があります。たとえば、さまざまなメッセージトランスポートチャネルの有効なケースは、ユーザーが選択できるさまざまなシーケンスファイルで見つけることができます。プロトコル機能ごとに異なるシーケンスファイルが存在する場合もあります。

図 5: Defensics Bluetooth OBEX server test suite には、単一応答モードの有無にかかわらず、MAP、PBAP、OPP、および FTP 機能をテストするための独自のシーケンスファイルがあります。

テストスイートによっては、単一のシーケンスファイルのみを提供するものや、ユーザーが編集可能なシーケンスをまったく提供しないものもあります。 設定を再読み込み（新しいプロトコルモデルとテストシーケンスを使用してテストスイートを再読み込み）して、有効なテストケースのシーケンスを変更することもできます。たとえば、スイートのロード時のデフォルト設定値が UDP であった場合、トランスポートチャネルは、TCP でサポートされている有効なテストケースのみを使用してテストスイートをリロードできます。

多くの場合、最大限の相互運用性と完全なテストカバレッジを実現するには、正しい構成を 1 つ見つけるだけで十分です。ただし、テストターゲットが複数のトランスポートチャネルおよび機能をサポートしている場合、最大のテストカバレッジを達成するには、使用可能なすべてのテストシーケンスを異なる設定で実行する必要があります。

.

メッセージの順序とプロトコルのパラメータ

シーケンスには、テストスイートまたはテストターゲットに固有のパラメータを保持する複数の送信プロトコルメッセージが含まれる場合があります。アドレスやポートなど明らかなものもありますが、構成可能なテストスイートの設定として表示される簡単な構成パラメーターも多数あります。 オプションのパラメーターが多すぎてすべてを個別の設定として提供できない場合は、テストスイートの開発者が選択する必要があります。 最も一般的なパラメータの一部は設定として提供でき、残りはシーケンスファイルを手動で編集することで変更できます。

パラメータのデフォルト値は、テストターゲットからの最小限の要件を備えた既知の良好な値に設定されます。 これは相互運用性を最大化するための設計上の選択です。 多くの場合、有効なテストケースでは値が 0 になり、異常なテストケースでは他の値が表示されます。

図 6: Defensics Bluetooth L2CAP test suite のデフォルト値での設定

課題はパラメーターだけではありません。メッセージのタイミングと順序によっても、相互運用性の問題が発生する可能性があります。タイミングもテストの速度に影響します。たとえば、入力タイムアウトを増やすと、異常により入力メッセージが表示されないとファジングが遅くなります。 設計者は最初に速度を選択するかもしれませんが、スキップされるケースの数を減らすために、応答の遅いテスト ターゲットではタイムアウト値を増やすことが必要になる場合があります。

図 7: Defensics Bluetooth test suiteでのタイミング設定

課題はパラメーターだけではありません。 メッセージのタイミングと順序によっても、相互運用性の問題が発生する可能性があります。 タイミングもテスト速度に影響します。たとえば、入力タイムアウトを増やすとファジングが遅くなりますが、これは異常により入力メッセージが表示されないためです。設計者は最初に速度を選択するかもしれませんが、スキップされるテストケースの数を減らすために、応答の遅いテストターゲットではタイムアウト値を増やすことが必要になる場合があります。

まとめ

デフォルトではテストデータが無効、不正、または予期しないものであるため、相互運用性はファジングテスト中の最初の懸念事項ではありません。ただし、テストカバレッジを最大化するには、テストターゲットがテストデータを正しく受信できる状態である必要があります。正しいテスト状態であることを担保するには、テストスイートとテストターゲット間の相互運用性が必要です。

Defensics チームは、幅広い実装との相互運用性のために有意義なテストシーケンスを作成していますが、明らかな理由もなく相互運用性テストが失敗する場合があります。テストスイートのドキュメントに解決策が記載されていない場合、当社のサポートチームがいつでも相互運用性の問題を喜んで解決します。 多くの場合、テストターゲットにはゴールデン サンプルが存在しないため、開発者は相互運用性を継続的に改善するために現場からのフィードバックを受け取ることに関心を持っています。

ファジングソリューションについてもっと学ぶ