7

私は現在、到達が困難な領域での単体テストを調査しており（これは非常に高レベルのビューです）、この質問に直面しました：スタブ/モックまたはサービスの仮想化？

私は答えを追求して読んでいますが、私が見つけることができる唯一のリソースは、SVベンダー（明らかに偏っている）から来ているようです。

一方が他方よりも絶対的に適切である場合、誰かが例を考えることができますか、そしてその理由は何ですか？答えが「状況によって異なります」の場合は、その理由/内容を提案してください。どちらの方法でも同じ結果が得られるようです。時間（開発する）または利用可能な資金（GreenHatなどは安くはありません！）の問題です。

前もって感謝します！

編集：

以下に投稿されたリンク（1）の1つを確認したところ、これが私が得ているものだと思います。

「仮想サービスは、自分で作成できる単なるテストスタブです。

独自のスタブをコーディングすることもできますが、非常に単純な動作を乗り越えると、ソフトウェア開発ライフサイクル全体で依存するすべてのシステムをモックアップするための労力とコストが圧倒的になります。サービス仮想化では、手動のコーディングや調整を必要とせずに、ソフトウェア側で直接観察することでシミュレーションとモデリングを実行できるという点で、自動化が求められます。そうしないと、アプリケーション機能自体を構築してテストするのと同じくらい多くの時間をスタブ環境の保守に費やす可能性があります。」

他のツールと同じですが、基本的には？

（1）http://servicevirtualization.com/top-10

4

4 に答える 4

4

素晴らしい質問です。基本的に、スタブはテスト スイートを環境から切断し、サービス仮想化は環境をエミュレートして、テストの真の意図をより適切に実行します。

さらに詳細に...

スタブは、外部依存関係を削除するために、オブジェクト、メソッド、または関数の代替実装を提供します。通常、スタブは単体テストとコンポーネント テストの際に次の 2 つの主な目的で使用されます。 .

単体テストを作成しようとしていて、データベース、外部ライブラリ (ファイル I/O など)、またはその他のシステム API への単純な呼び出しを置き換える必要がある場合、スタブはニーズに完全に適合する可能性があります。

通常、スタブ/モックは利用できないシステム コンポーネントを「スキップ」するために使用されますが、サービスの仮想化により、チーム メンバーは環境 (または特定のコンポーネント) をエミュレートし、その動作をチーム全体で利用できるようになります。たとえば、サービスの仮想化を使用して、進化している、まだ利用できない、またはアクセス/構成が困難な依存コンポーネント (サードパーティ サービス、データベース、メインフレーム、パッケージ化されたアプリケーションなど) の動作をエミュレートすることができます。テスト。

サービスの仮想化は、単純なスタブやモックよりもはるかに現実的な動作を表すことができます。依存アプリケーションにアクセスできる場合は、ライブ システムから記録することで、その現在の動作を「仮想資産」にキャプチャできます。または、予想される動作を表す仮想アセットをモデル化できます。次に、条件付き動作、パフォーマンス基準、およびテスト データをパラメーター化することで、この仮想資産を構成できます。さらに、仮想資産を簡単に変更して、システム動作の全範囲を検証するために実行する必要がある適切な障害条件、例外などを生成できます。

私が勤務する Parasoft は、これらのユース ケースの両方に対応しています。当社の開発テスト プラットフォームは、単体テスト用のスタブの生成と管理を容易にし、Jolt 賞を受賞した Parasoft Virtualize 製品はサービスの仮想化を提供します。詳細については、http ://www.parasoft.com/service-virtualizationおよびhttp://www.parasoft.com/development-testingを参照してください。

于 2012-08-22T22:53:40.117 に答える
1

違いの概要を説明したInfoQの記事は次のとおりです。

記事から：

スタブ: 通常、テスト スイートに密結合されたハードコードされたデータを返すインターフェイスの最小限の実装。これは、一連のテストが単純で、ハードコーディングされたデータをスタブに保持することが問題にならない場合に最も役立ちます。一部のスタブは手書きです。一部はツールで生成できます。通常、スタブは開発者が個人的に使用するために作成します。テスターと共有することはできますが、ハードコーディングされたソフトウェア プラットフォームと展開インフラストラクチャの依存関係に関連する相互運用性の問題により、通常、より広い共有は制限されます。一般的な方法は、ユニット、モジュール、および受け入れテストのために、スタブがクラス、メソッド、および関数と直接インプロセスで動作する場合です。スタブも準備できると言う開発者もいますが、スタブでの呼び出しを検証することはできません。スタブは「有線」で通信することもできます。

モック: テストによって定義された期待値に対して出力を検証する、プログラム可能なインターフェイス オブザーバー。Java の Mockito、JMock、WireMock など、サードパーティのライブラリを使用して作成されることがよくあります。これは、大規模なテスト スイートがあり、スタブでは不十分な場合に最も役立ちます。各テストには異なるデータ セットアップが必要であり、それらをスタブで維持するにはコストがかかるためです。モックを使用すると、テストでデータの設定を維持できます。モックは通常、個人使用のために開発者によって作成されますが、テスターと共有できます。ただし、ハードコーディングされたソフトウェア プラットフォームと展開インフラストラクチャの依存関係に関連する相互運用性の問題により、より広い共有は通常制限されます。ほとんどの場合、ユニット、モジュール、および受け入れテストのクラス、メソッド、および関数をインプロセスで直接処理します。モックは、事前定義された基準 (要求またはパラメーターの一致とも呼ばれます) を満たす特定の要求に基づいて応答を提供します。モックは状態ではなく相互作用にも焦点を当てているため、モックは通常ステートフルです。たとえば、特定のメソッドが呼び出された回数や、特定のオブジェクトに対して行われた呼び出しの順序を確認できます。

仮想サービス: Software-as-a-Service (SaaS) として提供されることが多いテスト ダブルは、常にリモートで呼び出され、メソッドや関数で直接インプロセスで動作することはありません。多くの場合、仮想サービスは、インターフェイスまたは API ドキュメントに基づいて対話パターンをゼロから構築するのではなく、サービス仮想化プラットフォームの 1 つを使用してトラフィックを記録することによって作成されます。仮想サービスを使用して、チームがコミュニケーションを取り、他の開発チームやテスト チームとアーティファクトを共有するための共通の基盤を確立できます。仮想サービスはリモートで (HTTP、TCP などを介して) 呼び出され、通常は複数のプロトコル (HTTP、MQ、TCP など) をサポートしますが、スタブまたはモックは通常 1 つだけをサポートします。仮想サービスでは、特に企業全体の可視性を備えた環境に展開されている場合に、ユーザーの承認が必要になることがあります。仮想サービスの作成に使用されるサービス仮想化ツールには、ほとんどの場合、特定のプロトコルがどのように機能するかの詳細に飛び込む前に、技術に精通していないソフトウェア テスターがすぐに使えるようにするユーザー インターフェイスがあります。それらは、データベースに支えられている場合があります。また、応答時間や遅い接続など、システムの非機能特性をシミュレートすることもできます。特定の要求基準に対して一連のスタブ化された応答を提供し、他のすべての要求をライブ バックエンド システムに渡す (部分スタブ化) 仮想サービスを見つけることができる場合があります。モックと同様に、仮想サービスは非常に複雑なリクエスト マッチャーを持つことができ、さまざまな種類のリクエストに対して 1 つのレスポンスを返すことができます。仮想サービスは、要求の属性とデータに基づいて応答の一部を構築することにより、システムの動作をシミュレートする場合があります。

テストダブルが次のカテゴリのどれに当てはまるかを明確に判断することは、多くの場合困難です。それらは厳密な定義ではなくスペクトルとして扱われるべきです。

于 2017-11-05T16:32:40.260 に答える
0

つまり、SV はスタブよりもリアルに動作を表現できるということです。サービスの仮想化はサイロとして運用する必要はありません。それらは複合動作を表すことができます。たとえば、ある仮想エンドポイントで資金を転送するための呼び出しは、別の仮想エンドポイントで口座残高の更新をトリガーできます。これにより、仮想アセットはステートフルな方法で動作し、動作が複数の接続、プロトコル、またはインターフェイスにまたがる場合でも、システム全体の動作を簡単にモデル化できます。

于 2012-08-29T14:20:05.340 に答える