SoapUI-クイックガイド
SOAPは、Simple Object AccessProtocolの頭字語です。これは、World Wide Web Consortium（W3C）によって定義されています。https://www.w3.org/TR/2000/NOTE-SOAP-20000508 次のように-
SOAPは、分散型の分散環境で情報を交換するための軽量プロトコルです。これは、3つの部分で構成されるXMLベースのプロトコルです。メッセージの内容とその処理方法を記述するためのフレームワークを定義するエンベロープ。アプリケーション定義のデータ型のインスタンスを表現するための一連のエンコーディングルール。リモートプロシージャコールと応答を表すための規則。
SOAP-重要な機能
以下は、SOAPのいくつかの重要な機能です。
これは、インターネットを介して通信するように設計された通信プロトコルです。
XMLメッセージング用にHTTPを拡張できます。
Webサービスのデータ転送を提供します。
完全なドキュメントを交換したり、リモートプロシージャを呼び出したりできます。
メッセージのブロードキャストに使用できます。
プラットフォームと言語の両方に依存しません。
これは、送信される情報とその方法を定義するXMLの方法です。
これにより、クライアントアプリケーションはリモートサービスに簡単に接続し、リモートメソッドを呼び出すことができます。
SOAPはさまざまなメッセージングシステムで使用でき、さまざまなトランスポートプロトコルを介して配信できますが、SOAPの最初の焦点は、HTTPを介して転送されるリモートプロシージャコールです。CORBA、DCOM、Java RMIなどの他のフレームワークはSOAPと同様の機能を提供しますが、SOAPメッセージは完全にXMLで記述されているため、プラットフォームや言語に依存しません。
SOAPメッセージは、次の要素を含む通常のXMLドキュメントです-
Envelope−メッセージの開始と終了を定義します。これは必須の要素です。
Header−中間ポイントまたは最終エンドポイントのいずれかで、メッセージの処理に使用されるメッセージのオプションの属性が含まれます。これはオプションの要素です。
Body−送信されるメッセージを構成するXMLデータが含まれます。これは必須の要素です。
Fault −メッセージの処理中に発生したエラーに関する情報を提供するオプションのFault要素。
これらの要素はすべて、SOAPエンベロープのデフォルトの名前空間で宣言されています-
https://www.w3.org/2001/12/soap-envelope
SOAPエンコーディングとデータ型のデフォルトの名前空間は-です。
https://www.w3.org/2001/12/soap-encoding
Note−これらの仕様はすべて変更される可能性があります。したがって、W3Webサイトで入手可能な最新の仕様で更新を続けてください。
SOAP-メッセージ構造
次のブロックは、SOAPメッセージの一般的な構造を示しています。
<?xml version = "1.0"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV = "http://www.w3.org/2001/12/soap-envelope"
SOAP-ENV:encodingStyle = "http://www.w3.org/2001/12/soap-encoding">
<SOAP-ENV:Header>
...
...
</SOAP-ENV:Header>
<SOAP-ENV:Body>
...
...
<SOAP-ENV:Fault>
...
...
</SOAP-ENV:Fault>
</SOAP-ENV:Body>
</SOAP_ENV:Envelope>RESTは、Representational StateTransferの頭字語です。これは、ソフトウェアを設計するアーキテクチャスタイルとして定義できます。RESTは仕様またはW3C標準ではありません。したがって、RESTfulサービスを使用する方が簡単です。ミドルウェア仕様のフレームワークは必要ありません。
REST-重要な機能
以下は、RESTのいくつかの重要な機能です。
ステートレス、クライアントサーバー、キャッシュ可能な通信プロトコルに依存しています。事実上すべての場合、HTTPが使用されます。
これは、SOAP-WSDLのようなWebServiceおよびRPC（リモートプロシージャコール）の軽量な代替手段です。
すべてを一意のIDまたはURIで表します。
GET、POST、PUT、DELETEなどの標準のHTTPメソッドを利用します。
ソースをリンクします。
RESTリソースは複数の表現を持つことができます。
名前付き情報はすべてリソースと見なされます。例：画像、人物、ドキュメント、すべてをリソースの例と見なし、一意のIDまたはURIとして表すことができます。
HTTPに基づくWorldWide Web自体は、RESTベースのアーキテクチャと見なすことができます。
RESTサービスは、プラットフォームと言語に依存しません。HTTP標準に基づいているため、ファイアウォールが存在する場合でも簡単に機能します。WebServicesと同様に、RESTは組み込みのセキュリティ、セッション管理、QoS保証を提供しませんが、これらはHTTPの上に構築することで追加できます。暗号化には、HTTPSの上にRESTを使用できます。
SoapUIは、機能テストと非機能テストの両方に使用できるツールです。これはWebサービスに限定されませんが、Webサービスのテストで使用される事実上のツールです。
SoapUI-重要な機能
以下は、SoapUIのいくつかの重要な機能です。
クライアントとサービスの両方の役割を果たすことができます。
これにより、ユーザーは単一の環境を使用して、機能テストと非機能テストを迅速かつ効率的に作成できます。
これは、GNU Leaser General Public License（LGPL）の条件に基づいてライセンスされています。
これは、JAVAプラットフォームを使用して純粋に実装されています。
Windows、Mac、複数のLinux方言をサポートしています。
これにより、テスターはさまざまなWeb APIで自動化された機能、回帰、コンプライアンス、および負荷テストを実行できます。
あらゆる種類のAPIをテストするためのすべての標準プロトコルとテクノロジーをサポートします。
SoapUIを使用して、完全なRESTfulAPIおよびSOAPWebサービスのテストをテストできます。機能テスト、パフォーマンステスト、相互運用性テスト、回帰テスト、負荷テストなどをサポートします。
ユーザーフレンドリーであるだけでなく、機能テストを負荷、ストレステストなどの非機能テストに簡単に変換できます。
SoapUIは、次の5つの側面に富んでいます-
- 機能テスト
- セキュリティテスト
- 負荷テスト
- プロトコルとテクノロジー
- 他のツールとの統合
これらの各機能について詳しく見ていきましょう。
機能テスト
SoapUIを使用すると、テスターはSoapUIで機能的なAPIテストを作成できます。
SoapUIは、スクリプト開発を加速するドラッグアンドドロップ機能をサポートしています。
SoapUIはテストのデバッグをサポートし、テスターがデータ駆動型テストを開発できるようにします。
SoapUIは複数の環境をサポートしているため、QA、Dev、およびProd環境を簡単に切り替えることができます。
SoapUIを使用すると、高度なスクリプトを作成できます（テスターはシナリオに応じてカスタムコードを開発できます）。
セキュリティテスト
SoapUIは、脆弱性スキャンの完全なセットを実行します。
SoapUIは、SQLインジェクションがデータベースを保護するのを防ぎます。
SoapUIは、膨大なサイズのドキュメントが原因で発生したスタックオーバーフローをスキャンします。
SoapUIは、クロスサイトスクリプティングをスキャンします。これは、サービスパラメーターがメッセージで公開されたときに発生します。
SoapUIは、ファジングスキャンとバウンダリスキャンを実行して、サービスの不安定な動作を回避します。
負荷テスト
SoapUIは、負荷テストをn個のLoadUIエージェントに分散します。
SoapUIは、大量の実際の負荷テストを簡単にシミュレートします。
SoapUIを使用すると、高度なカスタムレポートでパフォーマンスパラメータを取得できます。
SoapUIを使用すると、エンドツーエンドのシステムパフォーマンス監視が可能になります。
プロトコルとテクノロジー
SoapUIは幅広いプロトコルをサポートします-
- SOAP –シンプルオブジェクトアクセスプロトコル
- WSDL –Webサービス定義言語
- REST –代表的な状態転送
- HTTP –ハイパーテキスト伝送プロトコル
- HTTPS –保護されたハイパーテキスト送信プロトコル
- AMF –アクションメッセージ形式
- JDBC –Javaデータベースコネクティビティ
- JMS –Javaメッセージングサービス
他のツールとの統合
- ApacheMavenプロジェクト
- HUDSON
- JUnit
- Apache –Antなど…。
SoapUIは、テストの基本機能を備えたオープンソースの無料バージョンツールです。一方、SoapUI NG Proは、レポート機能、データ駆動機能などの高度な機能を備えた商用ツールです。
比較
次の表は、SoapUIとSoapUI NGProのさまざまな機能を比較対照しています。
| 特徴 | SoapUI | SoapUI NG Pro |
|---|---|---|
| Supported Technologies | ||
| 石鹸 | はい | はい |
| WSDL / WADL | はい | はい |
| 残り | はい | はい |
| JMS | はい | はい |
| AMF | はい | はい |
| JDBC | はい | はい |
| HTTP | はい | はい |
| General Features | ||
| スタンドアロンアプリケーション | はい | はい |
| マルチ環境サポート | 番号 | はい |
| フローティングライセンス | 番号 | はい |
| WSDLカバレッジ | 番号 | はい |
| 要求/応答カバレッジ | 番号 | はい |
| メッセージアサーション | はい | はい |
| テストリファクタリング | 番号 | はい |
| 複数のテストの実行 | はい | はい |
| データソース駆動型テスト | 番号 | はい |
| スクリプトライブラリ | 番号 | はい |
| ユニットレポート | 番号 | はい |
| 手動テスト手順 | はい | はい |
| Reporting | ||
| JUnitレポート | 番号 | はい |
| レポートデータのエクスポート | 番号 | はい |
| WSDLHTMLレポート | はい | はい |
| テストスイートのカバレッジ | 番号 | はい |
| テストケースカバレッジ | 番号 | はい |
| アサーションカバレッジ | 番号 | はい |
| メッセージ録音カバレッジ | 番号 | はい |
SoapUIはクロスプラットフォームツールです。Windows、Linux、およびMacオペレーティングシステムをサポートします。
前提条件
Processor −1GHz以上の32ビットまたは64ビットプロセッサ。
RAM −512MBのRAM。
Hard Disk Space −インストール用に最低200MBのハードディスク容量。
Operating System Version − Windows XP以降、MAC OS10.4以降。
JAVA − JAVA6以降。
ダウンロードプロセス
Step 1− www.soapui.orgにアクセスし、[SoapUIのダウンロード]をクリックします。
Step 2−「GetIt」をクリックしてSoapUIオープンソースをダウンロードします。システムに112MBの.exeファイルのダウンロードを開始します。ダウンロードプロセスが完了するまで待ちます。
インストールプロセス
Step 1 −ダウンロード後、「管理者として実行」として.exeファイルを実行します。
次のスクリーンショットに示すように、Windowsはセットアッププロセスを開始します。
Step 2 −設定が完了すると、プロセスウィンドウに次の画面が表示されます。[次へ]をクリックします。
Step 3 −使用許諾契約に同意し、[次へ]をクリックします。
Step 4−インストールディレクトリを選択するか、システムが選択するデフォルトパスとして保持します。[次へ]をクリックします。
Step 5−インストールするコンポーネントを選択します。[次へ]をクリックします。
Step 6 − HermesJMSの使用許諾契約に同意し、[次へ]をクリックします。
Step 7 −チュートリアルを保存するターゲットディレクトリを選択し、[次へ]をクリックします。
Step 8 −スタートメニューフォルダの場所を選択するか、デフォルトの場所をそのままにして、[次へ]をクリックします。
Step 9 −「デスクトップアイコンを作成する」チェックボックスを有効にして、「次へ」をクリックします。
これで、インストールが開始されます。完了するまでに数分かかります。
Step 10 −インストールが完了したら、次のウィザードで[完了]をクリックします。
[完了]をクリックすると、SoapUIが起動します。
- メニューバー
- ツールバー
- プロジェクトナビゲーションバー
- ワークスペースのプロパティ
- ログパネル
構成プロセス
最初のステップは、複数のプロジェクトを含むことができるワークスペースを作成することです。
Step 1 − [ファイル]→[新しいワークスペース]に移動します。
Step 2 −ワークスペースの名前を追加し、[OK]をクリックします。
Step 3 −ここで、ワークスペースxmlが保存されるパスを選択します。
Step 4 −パスを選択し、[保存]をクリックします。
次のスクリーンショットに示すように、ワークスペースが作成されます。ワークスペースのプロパティも表示されます。
WSDLはWebサービス記述言語の略です。これは、Webサービスを記述するための標準形式です。WSDLはMicrosoftとIBMが共同で開発しました。WSDLは「wiz-dull」と発音され、「WSD-L」と綴られます。
WSDL─簡単な歴史
WSDL 1.1は、2001年3月にXMLプロトコルでのW3C XMLアクティビティのサービスを説明するために、Ariba、IBM、およびMicrosoftによってW3Cノートとして提出されました。
WSDL 1.1は、World Wide Web Consortium（W3C）によって承認されていませんが、推奨（公式標準）となるバージョン2.0のドラフトをリリースしたばかりであるため、W3Cによって承認されています。
WSDL─注意点
WSDLは、分散型および分散型環境での情報交換のためのXMLベースのプロトコルです。WSDLの他の機能のいくつかは次のとおりです-
WSDL定義は、Webサービスにアクセスする方法とそれが実行する操作を記述します。
これは、XMLベースのサービスとのインターフェース方法を説明するための言語です。
これは、XMLベースの世界規模のビジネスレジストリであるUDDI（Universal Description、Discovery、and Integration）の不可欠な部分です。
WSDLは、UDDIが使用する言語です。
WSDLの使用法
WSDLは、インターネットを介してWebサービスを提供するために、SOAPおよびXMLスキーマと組み合わせて使用されることがよくあります。Webサービスに接続するクライアントプログラムは、WSDLを読み取って、サーバーで使用できる機能を判別できます。使用される特別なデータ型は、XMLスキーマの形式でWSDLファイルに埋め込まれます。その後、クライアントはSOAPを使用して、WSDLにリストされている関数の1つを実際に呼び出すことができます。
WSDLを理解する
WSDLは、Webサービスを3つの特定の識別可能な要素に分解します。これらの要素は、一度定義すると結合または再利用できます。
個別に定義できるWSDLの3つの主要な要素は次のとおりです。
- Types
- Operations
- Binding
WSDLドキュメントにはさまざまな要素がありますが、これらはこれら3つの主要な要素に含まれており、個別のドキュメントとして作成し、組み合わせたり再利用したりして、完全なWSDLファイルを形成できます。
このチュートリアルでは、CurrencyConverterWSDLをフォローしています。 http://www.webservicex.net
フォーマットと要素
CurrencyConverterWSDLは次のようになります-
WSDL─ポートタイプ
<portType>要素は、複数のメッセージ要素を組み合わせて、完全な一方向またはラウンドトリップ操作を形成します。たとえば、<portType>は、1つの要求と1つの応答メッセージを1つの要求/応答操作に組み合わせることができます。これは、SOAPサービスで最も一般的に使用されます。portTypeは、複数の操作を定義できます。
例
- portType要素は、ConversionRateと呼ばれる単一の操作を定義します。
- この操作は、単一の入力メッセージConversionRateHttpPostInで構成されます。
- 出力メッセージの操作はConversionRateHttpPostOutです。
操作のパターン
WSDLは4つの基本的な操作パターンをサポートします-
一方通行
サービスはメッセージを受信します。したがって、操作には単一の入力要素があります。一方向操作の文法は−です。
<wsdl:definitions .... >
<wsdl:portType .... > *
<wsdl:operation name = "nmtoken">
<wsdl:input name = "nmtoken"? message = "qname"/>
</wsdl:operation>
</wsdl:portType >
</wsdl:definitions>リクエスト─レスポンス
サービスはメッセージを受信し、応答を送信します。したがって、操作には1つの入力要素があり、その後に1つの出力要素が続きます。エラーをカプセル化するために、オプションの障害要素を指定することもできます。要求/応答操作の文法は次のとおりです。
<wsdl:definitions .... >
<wsdl:portType .... > *
<wsdl:operation name = "nmtoken" parameterOrder = "nmtokens">
<wsdl:input name = "nmtoken"? message = "qname"/>
<wsdl:output name = "nmtoken"? message = "qname"/>
<wsdl:fault name = "nmtoken" message = "qname"/>*
</wsdl:operation>
</wsdl:portType >
</wsdl:definitions>要請─応答
サービスはメッセージを送信し、応答を受信します。したがって、操作には1つの出力要素があり、その後に1つの入力要素が続きます。エラーをカプセル化するために、オプションの障害要素を指定することもできます。要請応答操作の文法は次のとおりです。
<wsdl:definitions .... >
<wsdl:portType .... > *
<wsdl:operation name = "nmtoken" parameterOrder = "nmtokens">
<wsdl:output name = "nmtoken"? message = "qname"/>
<wsdl:input name = "nmtoken"? message = "qname"/>
<wsdl:fault name = "nmtoken" message = "qname"/>*
</wsdl:operation>
</wsdl:portType >
</wsdl:definitions>通知
サービスはメッセージを送信します。したがって、操作には単一の出力要素があります。以下は、通知操作の文法です。
<wsdl:definitions .... >
<wsdl:portType .... > *
<wsdl:operation name = "nmtoken">
<wsdl:output name = "nmtoken"? message = "qname"/>
</wsdl:operation>
</wsdl:portType >
</wsdl:definitions>WSDL─バインディングとサービス
ザ・ <binding>elementは、portType操作が実際にネットワークを介して送信される方法に関する特定の詳細を提供します。
バインディングは、HTTP GET、HTTP POST、SOAPなどの複数のトランスポートを介して利用可能にすることができます。
バインディングは、portType操作の転送に使用されているプロトコルに関する具体的な情報を提供します。
バインディングは、サービスが配置されている場所に関する情報を提供します。
SOAPプロトコルの場合、バインディングは<soap：binding>であり、トランスポートはHTTPプロトコル上のSOAPメッセージです。
1つのportTypeに複数のバインディングを指定できます。
サービス
ザ・ <service>elementは、Webサービスでサポートされるポートを定義します。サポートされているプロトコルごとに、1つのポート要素があります。service要素は、ポートのコレクションです。
Webサービスクライアントは、サービス要素から次のことを学ぶことができます-
- サービスにアクセスする場所、
- Webサービスにアクセスするためのポート、および
- 通信メッセージの定義方法。
service要素には、人間が読める形式のドキュメントを提供するためのドキュメント要素が含まれています。
<wsdl:service name = "CurrencyConvertor">
<wsdl:port name = "CurrencyConvertorSoap" binding = "tns:CurrencyConvertorSoap">
<soap:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
</wsdl:port>
<wsdl:port name = "CurrencyConvertorSoap12"binding = "tns:CurrencyConvertorSoap12>
<soap12:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
</wsdl:port>
<wsdl:port name = "CurrencyConvertorHttpGet" binding = "tns:CurrencyConvertorHttpGet">
<http:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
</wsdl:port>
<wsdl:portname = "CurrencyConvertorHttpPost"binding = "tns:CurrencyConvertorHttpPost">
<http:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
</wsdl:port>
</wsdl:service>SoapUIプロジェクトは、すべてのSoapUIテストの中心点です。プロジェクトが作成されると、ユーザーは機能テストの作成と実行、テストのロード、モックサービスの作成などを行うことができます。
この章では、2つのことについて説明します。
- SOAPプロジェクトを作成する
- WSDLを追加する
SOAPプロジェクトを作成する
Step 1 −画面左側のナビゲーターで「プロジェクト」を右クリックし、「新規SOAPプロジェクト」を選択します。
または、[ファイル]に移動して、[新しい石鹸プロジェクト]を選択します。
選択すると、新しいポップアップウィンドウが開きます-新しい石鹸プロジェクト。
Step 2 − Project Name：プロジェクト名を入力します-これはユーザー入力フィールドです。 Initial WSDL：必須ではありません。ユーザーによって異なります。ユーザーはWSDLを提供するか、プロジェクトの作成後に追加できます。
この場合、プロジェクトを作成し、後でWSDLを追加します。
Step 3− [OK]をクリックします。新しいプロジェクトが作成され、左側のナビゲーションパネルに表示されます。
WSDLを追加する
SOAPプロジェクトはWSDLに基づいています。WSDLをインポートすることから始める必要はありませんが、WSDLには、要求と応答に関する情報、それらに含まれる情報など、Webサービスのテストに必要なすべての情報が含まれているため、テストが簡単になり、SoapUIテストが簡素化されます。
Step 1 − WSDLを追加するには、プロジェクト名（SOAP –例）を右クリックして、[WSDLの追加]を選択します。
選択すると、WSDLウィザードが表示されます。
Step 2 − WSDL Location：WSDLを次のように入力します http://www.webservicex.com またはコンピュータから閲覧します。
Step 3− WSDLが入力されるとすぐに、3つのチェックボックス–リクエストの作成、TestSuiteの作成、MockServicesの作成が有効になります。要件に基づいて、ユーザーは1つまたは複数のチェックボックスをオンにすることができます。
デフォルトでは、「リクエストの作成」のチェックボックスがオンになっています。
Step 4− [OK]をクリックします。WSDLがプロジェクトに正常に追加されました。左側のナビゲーションパネルを観察することで確認できます。プロジェクト内には複数の操作があり、WSDLに従ってリクエストが追加されます。
詳細ビュー
プロジェクトの詳細を取得するには、プロジェクト名をダブルクリックすると、さまざまな詳細を含む新しいウィンドウが開きます。
[概要]タブには、次のようなさまざまな情報が表示されます。
File Path −保存されたプロジェクトxmlの場所が表示されます。
Interface Summary −インターフェース名とそれに関連付けられたWSDL。
Test Summary −プロジェクトに追加されたテストスイート、テストケース、テストステップ、アサーションが表示されます。
ユーザーは、インターフェース名をダブルクリックして、インターフェースの詳細を取得できます。新しいウィンドウが開き、WSDL関連の情報が表示されます。これらは、WSDLの参照と調査に非常に役立ちます。
[概要]タブには、WSDL定義、定義部分、および操作の詳細が一覧表示されます。
同様に、サービスエンドポイントはエンドポイントの詳細を一覧表示します。
次のスクリーンショットに示すように、[WSDLコンテンツ]タブには、XML /スキーマ形式のWSDLのすべての詳細が表示されます。
TestSuite機能テストを論理ユニットにグループ化するために使用できるテストケースのコレクションです。大規模なテストシナリオをサポートするために、SoapUIプロジェクト内に任意の数のTestSuiteを作成できます。
TestSuiteの作成
Step 1 −プロジェクト内で、（プロジェクト名の横にある）インターフェイスを右クリックし、[テストスイートの生成]をクリックします。
ここで、SOAP – Exampleはプロジェクト名であり、CurrencyConvertorSoapとCurrencyConvertorSoap12はインターフェースです。
Step 2−新しいウィザードが開きます。要件に基づいて選択肢を選択します。
Step 3 −選択したら、[OK]をクリックします。
Step 4− [LoadTestを生成する]チェックボックスをオンにします。これにより、このTestSuiteで作成されたTestCaseごとにLoadTestが生成されます。
Step 5 −新しいウィザードにTestSuite名を入力し、[OK]をクリックします。
次のスクリーンショットに示すように、作成されたTestSuiteがナビゲーションパネルに表示されます。
Step 6− TestSuite名をダブルクリックすると、右側のパネルにTestSuiteウィンドウが開きます。TestCaseが追加されていないため、空白になっています。
TestSuiteのプロパティは、ナビゲーションパネルの下部に表示されます。TestSuiteレベルで新しいカスタムプロパティを追加できます。
TestCaseは、Webサービスの特定の側面をテストするために組み立てられたTestStepのコレクションです。ユーザーは、n個のTestCaseをTestSuiteに追加し、それらをモジュール化して、複雑なテストシナリオのために相互に呼び出すことができます。
TestCaseの作成
Step 1− TestSuite内で、ユーザーは複数のテストケースを追加できます。テストスイートを右クリックして、「新しいテストケース」を選択します。
Step 2 − TestCaseの名前を入力し、[OK]をクリックします。
作成されたTestCaseには、現時点ではテストステップがありません。TestCaseは、利用可能なすべての種類のテストに対してゼロのTestStepsで追加されます。TestStepsが追加されると、括弧内の数字は自動的に変更されます。機能的なTestStepは「TestSteps」に入り、パフォーマンスのTestStepは「LoadTest」に入り、セキュリティTestStepは「SecurityTests」に入ります。
Step 3− TestCase名をダブルクリックすると、右側のパネルにTestCaseウィンドウが開きます。TestStepsが追加されていないため、次のスクリーンショットに示すように空白になっています。
TestStepsは、SoapUIの機能テストの「構成要素」です。これらはTestCaseに追加され、実行のフローを制御し、テストするWebサービスの機能を検証するために使用されます。
TestStepの挿入
Step 1−TestStepsを右クリックします。ステップを追加し、リストから適切なTestStepを選択します。たとえば、ユーザーがREST Webサービスをテストする必要がある場合、ユーザーはRESTテスト要求を選択します。
Step 2 − TestSteps→AddStep→SOAPRequestを選択して、インポートされたSOAPリクエストを検証するTestStepを追加します。
Step 3 − TestStepの名前を入力し、ウィザードで[OK]をクリックします。
[OK]をクリックすると、呼び出す操作を選択するためのダイアログボックスが表示されます。すべての操作が一覧表示され、ユーザーは呼び出したい操作を選択できます。
リストされる2つの操作があります。使用するSOAPバージョンを除いて、両方の操作は同じです。CurrencyConvertorSoap SOAPバージョン1.1を使用しますが、 CurrencyConvertorSoap12 SOAPバージョン1.2を使用します。
Step 4 −最初の1つ– CurrencyConvertorSoapを選択し、[OK]をクリックします。
TestCaseを追加する際に、さまざまな標準アサーションを追加できます。アサーションは、SOAP要求/応答のチェックポイント/検証ポイントとも呼ばれます。
Step 5 −次の検証ポイントのいずれもなしでTestStepを作成することを意味するデフォルトオプションを使用してTestCaseを作成しましょう−
- テストの実行時に、応答メッセージがSOAPであるかどうかを確認します。
- 応答スキーマが有効かどうかを確認します。
- SOAP応答にFAULTが含まれているかどうかを確認します。
Step 6 − [OK]をクリックすると、次のリクエストXMLスクリーンショットがポップアップ表示されます。
機能的なTestStepが追加されると、テストステップ数が1に増加します。同様に、負荷とセキュリティのTestStepを追加すると、追加されたステップの数に基づいて、対応する数が自動的に増加します。
セットアップのリクエスト
ここでは、INRからUSDへの通貨の変換を実行します。
- FromCurrency – INR
- ToCurrency – USD
次に、リクエストXMLとして送信される疑問符の代わりにこれらの入力を入力します。これらの値を対応するXMLタグに配置した後、[リクエストの送信]ボタンをクリックして応答を確認します。
応答
リクエストを送信すると、次のスクリーンショットに示すように、WebサービスリクエストがWebサーバーによって処理され、応答が返されます。
回答を読むことにより、1単位のINR = 0.0147単位のUSDであると結論付けることができます。
HTTPリクエスト
SOAPメッセージはHTTPプロトコルによって転送されます。HTTPリクエストを表示するには、SoapUIリクエストウィンドウ（左側）でRAWをクリックします。
リクエストはウェブサーバーに投稿されます。したがって、HttpのPOSTメソッドが使用されます。
SOAP要求は、次のように示されているhttpメッセージの本文で転送されます。
POST http://www.webservicex.com/currencyconvertor.asmx HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: text/xml;charset = UTF-8
SOAPAction: "http://www.webserviceX.NET/ConversionRate"
Content-Length: 353
Host: www.webservicex.com
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)HTTP応答
SOAP-UI応答ウィンドウの「RAW」タブをクリックして、応答がHTTP経由でどのように送信されるかを理解します。
リクエストを処理した後、httpレスポンスコード（200）が表示されます。これは、成功したことを意味します。Webサーバーはそれを正常に処理しました。
SOAP応答は、HTTPメッセージの本文の一部としてクライアントに返送されます。
HTTP/1.1 200 OK
Cache-Control: private, max-age = 0
Content-Type: text/xml; charset = utf-8
Content-Encoding: gzip
Vary: Accept-Encoding
Server: Microsoft-IIS/7.0
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Sun, 22 Jan 2017 19:39:31 GMT
Content-Length: 316
次のHTTPコードは、Webサーバーによる応答の送信に使用され、デバッグに非常に役立ちます。
| HTTPコード | 説明 |
|---|---|
1xx: |
Informational −これは、リクエストが受信され、継続的なプロセスがあることを意味します。 |
2xx: |
Success −アクションは正常に受信され、理解され、受け入れられました。 |
3xx: |
Redirection −これは、リクエストを完了するためにさらにアクションを実行する必要があることを意味します。 |
4xx: |
Client Error −これは、要求に不正な構文が含まれているか、実行できないことを意味します。 |
5xx: |
Server Error −サーバーは明らかに有効な要求を実行できませんでした。 |
プロパティは、SoapUIを使用したより高度なテストの中心的な側面です。機能テストプロパティは、テストの実行と機能をパラメータ化するために使用されます。
プロパティを使用してサービスのエンドポイントを保持できるため、テストの実行中に使用される実際のエンドポイントを簡単に変更できます。
プロパティを使用して認証資格情報を保持できるため、これらを中央の場所または外部ファイルで簡単に管理できます。
プロパティを使用して、テストの実行中にセッションIDを転送および共有できるため、複数のテストステップまたはテストケースで同じセッションを共有できます。
プロパティの定義
プロパティは、プロジェクトのさまざまなレベルで定義できます。
プロジェクトレベルで共通のプロパティは、プロジェクトレベルで定義できます。
同様に、TestSuiteおよびTestCase固有のプロパティは、それぞれのレベルで定義できます。
プロジェクト固有のプロパティは、[カスタムプロパティ]タブで定義されます。
たとえば、プロパティ「ToCurrency」は、「+」記号をクリックしてプロパティ名と値を入力することにより、プロジェクトレベルで定義できます。
プロパティへのアクセス
プロパティ拡張を使用すると、プロジェクト内のどこからでもプロパティにアクセスできます。
構造は次のようになります-
$ {＃Project＃PropertyName} –プロジェクトレベルの場合
$ {＃TestSuite＃PropertyName} –テストスイートレベルの場合
$ {＃TestCase＃PropertyName} –テストケースレベルの場合
$ {TestStepName＃PropertyName} –テストステップレベルの場合
$ {＃MockService＃PropertyName} –MockServiceプロパティの場合
$ {＃Global＃PropertyName} –グローバルプロパティの場合、[ファイル]→[設定]→[グローバルプロパティ]タブにあります。このプロパティは、すべてのプロジェクトで使用できます
$ {＃System＃PropertyName} –システムプロパティの場合、ヘルプ→システムプロパティにあります
$ {＃Env＃PropertyName} –環境変数の場合
同じ構造をRequestXMLに配置して、実行時に特定の属性の値を取得できます。
プロパティは、コンピュータプログラムの変数と見なすこともできます。ユーザーが他の場所でも使用できるものを定義したい場合は、プロパティが非常に役立ちます。プロパティは動的に定義することもできますが、Groovyスクリプトに依存します。
応答メッセージから何らかの値を抽出し、それを後続の要求に含める必要がある場合があります。このような場合、指定された値を取得してプロジェクトの他の要素に転送するメカニズムが必要です。SoapUIは、Property TransferTestStepを通じてこのような機能をサポートします。
プロパティ転送の追加
Step 1 − TestCaseまたはTestStepを選択し、右クリック→[ステップの追加]→[プロパティの転送]を選択します。
Step 2 − TestStep名を入力し、[OK]をクリックします。
Step 3 − RateTransferステップが追加され、新しいウィザードが開きます。
Step 4−プロパティ転送ウィンドウの左上隅にある[新しいプロパティ転送の追加]アイコン+をクリックします。転送の名前を入力するように求められます。レートを入力し、[OK]をクリックします。
プロパティの譲渡
転送が作成されたら、 Source そして Target panesプロパティ値を抽出して置き換えるには、関連するXPath式を指定する必要があります。[ソース]の横のドロップダウンボックスに、プロパティ転送のソースとして使用できるさまざまなレベルのSoapUIプロジェクトが一覧表示されます。デフォルトでは、最も近いTestStepが表示されます。
この場合、それは Request – INR to USDTestStep。[プロパティ]の横のドロップダウンリストには、転送で使用されるソースプロパティが表示されます。これは、要求、応答、またはサービスエンドポイントのいずれかです。
Step 1− [応答]を選択し、[パス言語]に移動します。ユーザーは、XPath、Xquery、またはJasonを選択してプロパティを定義できます。この場合、XPathを選択します。
Step 2 −ソースxmlの宣言を取得するには、nsをクリックしてXPathを指定します。
Step 3−上記のXPath式から抽出した値を転送する対象を指定します。そのために、プロパティ転送ウィンドウの下部にあるターゲットペインが使用されます。
Step 4 −RequestINRtoUSDステップの応答からConversionRateResultの抽出値を転送します。
Target −プロパティ
Property − ConversionRate（新しいプロパティが追加されました。最初は値がありません）。
Step 5 −テストケースが正常に実行されると、プロパティ「ConversionRate」が応答に基づいて更新されます。
以下は最初のスクリーンショットです。
以下は、実行が成功した後のスクリーンショットです。
同様に、ターゲットは次のリクエストXMLである可能性があります。ターゲットがSOAPリクエストの場合、ターゲット属性を識別するためにXPathを提供する必要があります。
[ログ]ペインには、クライアントとサーバー間のトランザクションに関する完全な情報が格納されます。ユーザーは、ログペインのさまざまなタブを表示できます。この章では、SoapUIの操作中に最も一般的に使用されるログペインについて説明します。
SoapUIログ
SoapUIログには、Webサーバーからの応答情報が表示されます。同じ情報が、「bin」ディレクトリの下のSOAP-UIインストールフォルダのsoapui.logファイルに保存されます。
HTTPログ
HTTPログには、すべてのHTTPパケット転送が表示されます。'RAW'のすべての情報はHTTPログに表示されます。
エラーログ
エラーログには、プロジェクトセッション全体で発生したすべてのエラーが表示されます。同じ情報が、SoapUIのインストール場所の「bin」ディレクトリにある「soapui-errors.log」にあります。
メモリログ
このタブはメモリ消費量を監視し、次のスクリーンショットに示すようにグラフの形式で表示します。メモリを大量に消費する操作を実行する場合に非常に役立ちます。
アサーションは、チェックポイントまたは検証ポイントとして解釈できます。要求がWebサーバーに送信されると、応答が受信されます。期待どおりにデータを含む応答を検証する必要があります。応答を検証するために、SoapUIにはアサーション機能があります。
注意点
アサーションは、実行中にTestStepが受信したメッセージを検証するために使用されます。
メッセージの一部またはメッセージ全体を期待値と比較します。
TestStepには任意の数のアサーションを追加でき、それぞれが応答メッセージのさまざまな側面と内容を検証します。
TestStepが実行された後、そのすべてのアサーションが受信した応答に適用され、それらのいずれかが失敗した場合、TestStepはTestCaseビューで失敗としてマークされます。
失敗したエントリは、テスト実行ログに表示されます。
アサーションのタイプ
SoapUIは、それに応じて幅広いアサーションをサポートします。
以下は、SoapUIでサポートされているアサーションのリストです。
| アサーション | 説明 |
|---|---|
| Property Content | |
| 含まれています | 指定された文字列の存在を確認します。正規表現もサポートしています。 |
| 含まれていない | 指定された文字列が存在しないかどうかをチェックします。正規表現もサポートしています。 |
| XPath一致 | XPath式を使用して、ターゲットノードとその値を選択します。XPath式の結果を期待値と比較します。 |
| XQueryマッチ | Xquery式を使用して、ターゲットプロパティからコンテンツを選択します。XQuery式の結果を期待値と比較します。 |
| Compliance, Status, Standards | |
| HTTPダウンロードすべてのリソース | HTMLドキュメントと呼ばれるすべてのリソース（画像、スクリプトなど）をダウンロードし、それらがすべて利用可能であることを検証します。HTMLを含むすべてのプロパティに適用できます。 |
| 無効なHTTPステータスコード | ターゲットTestStepが、定義されたコードのリストにないステータスコードのHTTP結果を受信したことを確認します。HTTPメッセージを受信するすべてのTestStepに適用できます。 |
| SOAP障害ではない | 最後に受信したメッセージがSOAP障害ではないことを検証します。SOAPTestStepsに適用できます。 |
| スキーマコンプライアンス | 最後に受信したメッセージが、関連するWSDLまたはWADLスキーマ定義に準拠していることを検証します。SOAPおよびRESTテストステップに適用できます。スキーマ定義URLはプロパティ拡張をサポートします（例：$ {＃System＃my.wsdl.endpoint} / services / PortType？wsdl）。 |
| SOAP障害 | 最後に受信したメッセージがSOAP障害であることを検証します。SOAP TestStepsに適用可能SOAPリクエスト-最後に受信したリクエストが有効なSOAPリクエストであることを検証します。MockResponseテストステップにのみ適用されます。 |
| SOAP応答 | 最後に受信した応答が有効なSOAP応答であることを検証します。SOAPTestRequestステップにのみ適用されます。 |
| 有効なHTTPステータスコード | ターゲットTestStepが、定義されたコードのリストにステータスコードを含むHTTP結果を受信したことを確認します。HTTPメッセージを受信するすべてのTestStepに適用できます。 |
| WS-AddressingRequest | 最後に受信したリクエストに有効なWS-Addressingヘッダーが含まれていることを検証します。MockResponseTestStepsにのみ適用されます。 |
| WS-AddressingResponse | 最後に受信した応答に有効なWS-Addressingヘッダーが含まれていることを検証します。SOAPTestRequestステップにのみ適用されます。 |
| WS-Securityステータス | 最後に受信したメッセージに有効なWS-Securityヘッダーが含まれていることを検証します。SOAPテストステップに適用できます。 |
| Script | |
| スクリプトアサーション | ユーザーがカスタムスクリプトを実行して、ユーザー定義の検証を実行できるようにします。TestStepsにのみ適用可能（つまり、プロパティには適用されません） |
| SLA | |
| 応答SLA | 最後に受信した応答の応答時間が定義された制限内にあったかどうかを検証します。要求を送信し、応答を受信するスクリプトTestStepsおよびTestStepsに適用できます。 |
| JMS | |
| JMSステータス | ターゲットTestStepのJMS要求が正常に実行されたことを検証します。JMSエンドポイントを使用したRequestTestStepsに適用できます。 |
| JMSタイムアウト | ターゲットTestStepのJMSステートメントが指定された期間より長くかかっていないことを検証します。JMSエンドポイントを使用したRequestTestStepsに適用できます。 |
| Security | |
| 機密情報の公開 | 応答メッセージがターゲットシステムに関する機密情報を公開していないかどうかを確認します。このアサーションは、REST、SOAP、およびHTTPTestStepsに使用できます。 |
| JDBC | |
| JDBCステータス | ターゲットTestStepのJDBC要求が正常に実行されたことを検証します。JDBCTestStepsにのみ適用されます。 |
| JDBCタイムアウト | ターゲットTestStepのJDBCステートメントが指定された期間より長くかかっていないことを検証します。JDBCTestStepsにのみ適用されます。 |
SoapUIでは、ユーザーは、少し注意を払うことで解決できる多くの一般的な一般的な問題に直面します。これらの最も一般的な問題のいくつかは次のとおりです-
Issue−名前空間が誤って定義されています。正しい名前空間を使用してください。名前空間は、Webサービスが配置されているURLである必要があります。
Solution −スクリプトアサーションの開発中にエラーがスローされた場合は、「log.info」を使用して変数の内容を出力します。
Issue −応答XMLとして障害コードを受信した場合は、入力が無効である可能性があります。
Solution −リクエストXMLの入力を確認します。
Example −通貨コンバーターで、「FromCurrency」の入力が存在しない「123」の場合、出力は「SOAP-Client」として障害コードをスローします。これは、問題がから渡されているパラメーターにあることを意味します。クライアント側。
リクエスト
応答
Issue − XPathまたはXQueryを使用している場合、現在の応答に一致しません。
Solution −
- XPathまたはXQueryを定義するときは、正しい構文を使用してください。
- 名前空間を宣言するときに、ドットではなくコロンが使用されていることを確認します。
- XPathとXQueryが正しいことを確認してください。
パフォーマンステストは、Webサービステストで最も一般的な重要なチェックポイントの1つです。パフォーマンステストは、負荷を人為的に作成またはシミュレートし、環境が負荷をどのように処理するかを測定することとして定義されます。
これは、システムが高負荷でどのように動作するかである必要はなく、ベースロードまたは予想される負荷でどのように動作するかを示すこともできます。構造化、自動化、またはSoapUIなどのTestWareで作成する必要はありません。Webブラウザーを非常に高速に何度も更新するだけでも、負荷テストです。
パフォーマンステストの種類
パフォーマンステストの種類は次のとおりです-
Baseline Testing −システムが予想または通常の負荷の下でどのように動作するかを調べ、他のタイプのテストと比較できるベースラインを作成します。
Load Testing−負荷の増加を含み、より高い負荷の下でシステムがどのように動作するかを確認します。負荷テスト中、ユーザーは応答時間、スループット、サーバーの状態などを監視できます。負荷テストの目標は、ターゲット環境を破壊することではありません。
Soak Testing −テストの目標は、長期間にわたって不要な動作が発生しないことを確認することです。
Scalability Testing−スケーラビリティテストは負荷テストと非常によく似ていますが、リクエストの数を増やす代わりに、送信されるリクエストのサイズまたは複雑さを増やします。たとえば、大きなリクエスト、大きな添付ファイル、または深くネストされたリクエストの送信。
Webサービスの主な側面
Webサービスのパフォーマンスの独自の特性には、2つの側面が際立っています。
最初の側面
サーバー側では、XML / JSONの解析とシリアル化の両方で、XML / JSON処理が実行されています。最初に失敗することが多いのは、ペイロードの処理です。失敗の理由はさまざまです。プラットフォームやアプリケーションサーバーの弱点にある場合もあれば、不必要に複雑なWSDLの形をした実装の問題である場合もあります。また、コードが応答の遅いデータベースにリクエストを送信していることを意味している可能性もあります。
Testing Aspect− XML / JSONペイロードの解析は複雑であるため、スケーラビリティテストに特に重点を置く必要があります。また、WSDLを綿密に調査する必要があることも意味します。要求と応答が複雑または大きい場合、または大きな添付ファイルが含まれている場合は、複雑さを強調し、負荷がかかった状態でどのように動作するかを確認することに重点を置く必要があります。
第二の側面
頻繁に遭遇するもう1つの要因は、セキュリティです。HTTPSの背後にある安全なサイトのパフォーマンスは大幅に低下します。Webサービスのテストでは、HTTPセキュリティのレイヤーにWSSecurityのレイヤーを追加して、パフォーマンスをさらに低下させることができます。
Testing Aspect−セキュリティの問題は、安全なリクエストのテストの実行に焦点を当てる必要があることを意味します。Webサービス全体が安全である場合、特にWS-Securityとトークン処理が使用されている場合は、負荷テストがより重要であることを意味します。
Load testingは、特定の負荷の下でのシステムの動作を評価するために実施される特定の形式のパフォーマンステストです。SoapUIでは、通常、すべてのタイプの非機能テストに「負荷テスト」という用語を使用しますが、SoapUIは、負荷、ストレス、耐久性など、Webサービスのすべてのタイプのパフォーマンス評価をサポートします。
注意点
負荷テストはSoapUIでは非常にユニークです。パフォーマンステストをすばやく作成および変更できる機能テストケース。
主な差別化要因は、SoapUIのパフォーマンステストは通常、既存の機能テストから作成されることです。これにより、高度なパフォーマンステストをすばやく作成できます。
Webサービスのパフォーマンスは、さまざまな負荷シナリオで検証できます。機能検証を維持して、負荷がかかっても壊れないことを確認し、複数の負荷テストを同時に実行して、相互にどのように影響するかなどを確認します。
負荷テストの作成
Step 1 − [機能テストケース]を右クリックして、[新しい負荷テスト]を選択します。
Step 2 −負荷テストの名前を入力し、ダイアログウィザードで[OK]をクリックします。
次のスクリーンショットに示すように、負荷テストが開き、負荷テストが作成されます。
負荷テストの実行
新しい負荷テストが作成されると、単純な負荷戦略を使用して、5つのスレッドで60秒間（右上）実行するように事前構成されています。
要件に従ってこれらの値を変更し、実行します。 Note −ユーザーは、負荷テストの構成と概念を知っている必要があります。
ユーザーには、データの収集から始まり、60秒後にLoadTestが終了するはずの統計テーブルが中央に表示されます。
アサーションの追加
Step 1 − LoadTestエディターで、エディターの下部にあるLoadTestアサーションタブを選択します。
Step 2 − LoadTestアサーションメニューバーの[アサーションの追加]ボタンをクリックして、アサーションを追加します。
Step 3− [アサーションの追加]ダイアログが開きます。[最大ステップ]を選択します。[最大]を選択すると、応答に許可される最大時間がミリ秒単位で設定されます。設定した時間を超えると、テストは失敗します。[OK]をクリックします。
Step 4− TestStep MaxAssertionウィンドウが開きます。次のスクリーンショットに示されているように、最大応答は1秒、1000ミリ秒です。何も変更しないでください。[OK]をクリックします。
これで、ステップ最大アサーションが正常に追加されます。
Step 5−テストを再実行します。応答に時間がかかりすぎる場合は、err列の数値がすぐに加算されるはずです。
Webサービスは、アプリケーションまたはシステム間でデータを交換するために使用されるオープンなプロトコルと標準のコレクションです。さまざまなプログラミング言語で記述され、さまざまなプラットフォームで実行されるソフトウェアアプリケーションは、Webサービスを使用して、単一のコンピューターでのプロセス間通信と同様の方法で、インターネットなどのコンピューターネットワークを介してデータを交換できます。この相互運用性（たとえば、JavaとPythonの間、またはWindowsとLinuxアプリケーションの間）は、オープンスタンダードの使用によるものです。
RESTアーキテクチャに基づくWebサービスは、RESTfulWebサービスとして知られています。これらのWebサービスは、HTTPメソッドを使用してRESTアーキテクチャの概念を実装します。RESTful Webサービスは通常、URI（Uniform Resource Identifier）を定義します。これは、JSONや一連のHTTPメソッドなどのリソース表現を提供するサービスです。
SoapUIのすべてのRESTテスト機能は、RESTサービスと呼ばれる論理表現に基づいています。これをここでの「サービス」という用語と混同しないでください。これはサービスの実装ではなく、呼び出されるRESTfulサービスのマッピングであるためです。SoapUIプロジェクトにできるだけ多くのRESTサービスを追加できます。それぞれが特定のRESTfulサービスを表します。それらは次のとおりです-
REST-プロジェクトのセットアップ
REST-WADL
REST-リクエスト
REST-応答
REST-HTTPメソッド
SoapUIを使用すると、JDBC要求と呼ばれるTestStepを使用してデータベース操作を管理できます。
Step 1 − TestStepを右クリックし、「ステップの追加」→「JDBC要求」を選択します。
Step 2 −ステップ名を入力し、[OK]をクリックします。
JDBCステップが追加されました。ステップをダブルクリックすると、JDBCウィザードが開きます。
JDBC接続を作成するには、ユーザーは有効なドライバーと接続文字列を提供する必要があります。これらのパラメーターは、データベースのタイプを識別し、データベースを使用するための接続を作成するために使用されます。
MySQLの場合、データベースドライバは com.mysql.jdbc.Driver。同様に、他のデータベースの場合、データベースのドキュメントセクションで見つけることができる事前定義されたドライバーがあります。
Step 3 −接続文字列は次の形式である必要があります−
Jdbc:mysql://[host]:[port]/[database]?[property][=value]ここで、propertyは、データベースに接続するために必要な他のパラメーターとともに、ユーザー名とパスワードです。
例えば、
jdbc:mysql://localhost:8089/xxx_DB?user=root&password=rootStep 4− [接続のテスト]をクリックします。接続が成功すると、SUCCESSが表示されます。それ以外の場合は、失敗の詳細が表示されます。
JDBCには、SQLクエリで変数として使用できる独自のAddプロパティセクションがあります。
それがどのように動作するか見てみましょう-
JDBCステップで実行する必要のあるSQLクエリがSelect * from Currency where CurrencyCode = 'xxx'であるとします。
このシナリオでは、CurrencyCodeはリクエスト入力に基づいて変更できます。ユーザーがハードコードされた値を指定した場合、JDBCステップは要求で指定された通貨に対して実行されません。
このようなシナリオを克服するために、JDBCはaddプロパティをサポートしています。ここで、プロパティコードを定義でき、プロパティ転送ステップを使用して変更を続けます。
SQLクエリはプロパティコードの現在の値に基づいて実行され、SQLクエリはCurrencyCode =：Codeをパラメータ化します。
[プロパティの追加+]と名前を[コード]をクリックし、値を指定するか空白のままにして、プロパティの転送手順を使用して入力します。
JDBCリクエストは、SOAPリクエストのTestStepsでほとんどのアサーションを利用することもできます。SoapUIでは、これらのアサーションのほとんどはTestStepsから独立しています。したがって、ContainsやXPathMatchなどのアサーションはJDBCRequestTestStepで使用できます。
クリックすることにより Add an assertion JDBC Request TestStepのトップメニューにあるアイコンをクリックすると、ユーザーはTestStepでサポートされているアサーションを確認できます。
一般的なアサーションに加えて、2つのJDBC RequestTestStep固有のアサーションがあります-
JDBC Timeout −このアサーションを使用して、現在のSQLクエリが指定されたQueryTimeoutプロパティ値内で実行されているかどうかを確認できます。
JDBC Status − SQLステートメントが正常に実行されたかどうかを確認するために、JDBCステータスアサーションを使用できます。
クエリタイムアウトを設定するには、画面の左側にプロパティクエリタイムアウトのそれぞれの値を指定します。ミリ秒（ms）単位の値を受け入れることに注意してください。
