3

SOA テストと従来のアプリケーション テストの違い

4

6 に答える 6

2

各「サービス・プロバイダー」は標準のビジネス指向のインターフェース (通常は WSDL テクノロジーで提供される) を持つ必要があるため、次のプロパティーは異なる場合があります。

  • 提供されるサービスは、ビジネス自体に大幅な変更を加える場合を除き、モジュールのリビジョンごとに変更しないでください。

  • モジュールは、モジュールのテストを容易にするクライアントが誰であるかを気にするべきではありません。

  • 理想的には、消費されるサービスはディレクトリによって提供され、モジュールにハードコーディングされません。これが成り立つ場合、システムの一部 (すべてではなく一部のモジュール) のテストもはるかに簡単になります。

編集：

  • また、他の人が指摘しているように、システムの現在のコンポーネントが互いに動作するかどうかではなく、仕様への適合性をテストする必要があります。たとえば、Web ページは Internet Explorer では正常に表示されても、仕様に準拠していないため、他のブラウザーでは使用できない場合があります。SOA に移行すると、サービスのプロバイダーをシームレスに置き換えることができることを期待します。
于 2009-07-16T13:09:37.910 に答える
1

通常、SOAサービステストはブラックボックスであり、公開されたWSDLコントラクトのみを考慮して使用しますが、特に検証に使用できる機能（操作）がない場合は、データベースで直接検証を行う必要がある場合があります。

また、最新のSOAプラットフォームは通常、他のサービス実装とリソースを共有するため、本番ボリューム以上の処理負荷をシミュレートし、メモリ、処理、およびI / O消費の影響を評価して、サービスへの悪影響を回避することが重要です。すでにデプロイされています。

最も複雑な懸念は、既存のクライアントを壊さずに新しい機能を実装する方法に関する契約と実装の進化に関連しています。これは、構文とセマンティックの問題があるため、特に面倒な場合があります。たとえば、次のようになります。

  • 互換性のない構文：新しいコントラクトバージョンには新しい要素を含めることができますが、新しい必須要素を含めることはできません。これにより、古いクライアントが破損するため、この種の問題は通常、現在のコントラクトと新しいコントラクトの両方で実装された自動テストを実行することで回避できます。
  • 検証の抽象化：多くの場合、正規モデル（xmlスキーマ）は、型変換を回避し、共通のビジネス言語を提供するために複数のサービスと共有されます。通常、これらのサービスには、すべてのサービス操作に必要なすべての検証がありません。次に、必要な検証ロジックがサービス実装で直接実行されます。新しいバージョンのサービスが、公開された契約に含まれていない新しい一連の検証を実装する場合は、クライアントに通知し、シナリオをテストする必要があります。

私がよく使用するツールは、 SOAP UIとJMeterであり、社内で開発されたフレームワークを使用してカスタム自動テストを作成します。

于 2012-08-08T13:28:54.520 に答える
0

いくつかの (貴重な?) アドバイス:

サービスの定義は、プロバイダーの実装に依存せずにサービス コンシューマーを検証するために、モック フレームワークの使用につながる必要があります。

コンシューマーの堅牢性を確認してください。メッセージが失われた場合、サービス プロバイダーが利用できない場合はどうなりますか。

于 2009-07-16T13:45:27.883 に答える
0

SOA テストは、従来のテストの拡張として定義できます。

従来のアプリケーションと同様に、最初にコンポーネントの単体テストを行い、次にコンポーネント レベルの機能テストを行い、その後にモジュール レベルのテストを行った後、エンド ツー エンドのアプリケーション テストを行います (特定のタスクを達成するために組み合わせたコンポーネントのセットである場合もあります)。 ) レベルの単体テスト、その後の機能テスト、プロセス (複合サービスまたはビジネス プロセス) レベルのテスト、エンド ツー エンドの統合テストなど。

プロセスはさまざまなタイプのサービスにまたがって存在するため、その一部はラッパーである可能性があり、一部のサービスには通信の制約、負荷の制約、サービス レベル アグリーメントがあり、これらすべてがテストのプロセスを複雑にし、テスト戦略を考え出す必要があります。

于 2011-09-09T12:43:01.010 に答える
0

覚えておく必要があるのは、多くの依存関係がある環境では、すべての依存関係をマップし、すべてのパスをテストする必要があるということです。

サービスがあると、多くのクライアントで使用する必要があるため、すべてのクライアントがテスト ケースに従う必要があります。

サービスでは、ネットワークの問題にも注意を払う必要があります。ネットワークに大量のトラフィックを入れて従来のテストを行い、スイッチをオフにして、それがどのように機能するかを確認します。

それに加えて、サービスを提供するために、他の種類の異なるアプローチは必要ありません。すべての入力と出力を制御するだけです。

于 2009-07-16T13:24:20.127 に答える