SoapUI Common Assertions
前の二つの記事では、テスト対象の特定の種類のテストケースまたはWebServiceにのみ適用されるテスト固有のアサーションの詳細を説明しました。 記事”SoapUI Test Specific Assertions:REST Services”に記載されているすべてのアサーションはREST WebServicesにのみ適用され、記事”SoapUI Test Specific Assertions:SOAP Services”に記載されているすべてのアサーションはSOAP WebServicesにのみ適用 現在、SoapUIはSOAPサービスとRESTサービスの両方に適用可能であり、SoapUI共通アサーションとして知られている他のアサーションもほとんど提供していません。 この記事では、次のトピックの下で詳細をカバーすることによって、これらすべての一般的なアサーションの使用法を理解します:
- SoapUIの一般的なプロパティコンテンツアサーションとは何ですか?
- ソープには何が含まれているのでしょうか?
- さらに、SoapUIにアサーションが含まれていないものは何ですか?
- SoapUIのXPathアサーションとは何ですか?
- SoapUIでのXQueryマッチアサーションとは何ですか?
- 同様に、SoapUIの一般的なコンプライアンス、ステータス、および標準アサーションは何ですか?
- SoapUIによって提供されるHTTPステータスコードアサーションとは何ですか?
- さらに、SoapUIのスキーマコンプライアンスアサーションとは何ですか?
- SoapUIの一般的なSLAアサーションは何ですか?
これらのアサーションはすべてSOAPサービスとRESTサービスの両方に適用されるため、これらすべてのアサーションの検証には次の情報を使用します:
- URIを使用して作成されたRESTプロジェクト: 記事「SoapUI:Working With Projects」に記載されている詳細に従って、WSDLを使用して作成されたSOAPプロジェクト:「http://bookstore.toolsqa.com/BookStoreService.wsdl」。”SoapUI Test Specific Assertions:REST Services”の記事からRESTプロジェクトのサンプル出力を参照し、”SoapUI Test Specific Assertions:SOAP Services”の記事からSOAPプロジェクトのサンプル出力を参照できます。
SoapUIの一般的なプロパティコンテンツアサーションとは何ですか?
既に知っているように、プロパティコンテンツアサーションは受信した応答の内容を検証します。 SoapUIは、SOAP要求とREST要求の両方に適用可能な複数のコンテンツアサーションを提供します。 以下のセクションで、これらのアサーションをどのように使用できるかを見てみましょう。
SoapUIにアサーションが含まれているとは何ですか?
Containsアサーションは、プロパティ値に文字列トークンが存在するかどうかを検索します。
書店サービスで、著者名が”Richard E.Silverman”の本が存在するかどうかを確認する必要があるというシナリオを考えてみましょうか?”Contains”アサーションを使用して同じことを検証するには、以下の手順に従います:
- まず、アサーションの追加ダイアログボックスに移動します。 その後、下に強調表示されているように、”プロパティコンテンツ”アサーションカテゴリの下にある”Contains”アサーションをク:
- 次に、”追加”ボタンをクリックすると、以下に示すように”アサーションを含む”ダイアログボックスが表示されます:
-
第三に、”コンテンツ”セクションに著者”Richard E.Silverman”の名前を入力します。 これは、Webサービスの応答で検証する検索文字列です。
-
第四に、上記のダイアログボックスには、二つのチェックボックスも表示されます。 彼らは:
- 大文字と小文字を無視:大文字と小文字を無視チェックボックスを選択すると、大文字と小文字を無視して文字列を検証します。 コンテンツテキストボックスに”richARD E.SilVerMan”と入力し、”比較で大文字と小文字を無視”チェックボックスにチェックを入れたとします。 さらに、大文字と小文字の区別は無視され、入力された文字列の値のみがチェックされます。
にアサーションが含まれているため、大文字と小文字を無視すると文字列内の文字が同じであるため、アサーションは渡されます。
- 正規表現:正規表現に基づいて出力を検証する場合は、このチェックボックスをオンにして、コンテンツセクションで正規表現を指定できます。 たとえば、book serviceの応答に「O’Reilly」が応答に含まれていることを検証する場合は、「」を指定できます。オライリー”コンテンツセクションの正規表現として、以下に示すように:
したがって、Containsアサーションを使用してWebサービスの応答に文字列が存在するかどうかを検証でき、SOAPとREST Webサービスの両方でこれを使用できます。
SoapUIにアサーションが含まれていないものは何ですか?
Contains assertionとは対照的に、Not Contains assertionはプロパティ値に文字列が存在しないことを検索します。 さらに、このアサーションは、応答に指定された値が含まれていない場合に渡されます。Book storeサービスの応答に”Groovy Book”というタイトルの本がないことを検証したい場合は、このアサーションを使用してBookStore APIの応答を検証できます。
以下の手順に従って、”Not Contains”アサーションを使用して同じことを検証しましょう:
- まず、アサーションの追加ダイアログボックスに移動し、以下で強調表示されているように、”プロパティコンテンツ”アサーションカテゴリの下にある”Not Contains”:
-
次に、”追加”ボタンをクリックすると、以下に示すように”NotContains Assertion”ダイアログボックスが表示されます:
-
第三に、”コンテンツ”セクションに文字列”Groo Book”の名前を入力します。 これは、Webサービスの応答に存在しない検証する検索文字列です。
注:ここでの2つのチェックボックス(Ignore Case&RegEx)は、Containsアサーションと同じように機能します。
- 第四に、”OK”ボタンをクリックすると、WebService応答に対してアサーションが実行され、以下に示すように結果が表示されます:
- そのため、ターゲットサービスの応答に文字列が存在しない限り、アサーションは渡されます。
SoapUIのXPath Match Assertionとは何ですか?
XPath Matchアサーションを使用すると、XPath式を使用してターゲットレスポンスの特定のノードからコンテンツを選択し、期待する値と比較することができます。BookStore APIの応答に存在する最初の本のISBNがnullではないことを検証したいとします。 XPathアサーションを使用して、同じものをすばやく検証できます。
以下の手順に従って、”XPath Match”アサーションを使用して同じことを検証しましょう:
- まず、アサーションの追加ダイアログボックスに移動します。 その後、下に強調表示されているように、”プロパティコンテンツ”アサーションカテゴリの下にある”XPath Match”アサーションをクリッ:
- 次に、”追加”ボタンをクリックすると、以下に示すように”Xpath Match Configuration”ダイアログボックスが表示されます:
でSOAPとRESTの両方のXpath Match Assertion ConfigurationsCommonがあります。,
-
Declare:このボタンをクリックすると、名前空間が自動的に取得され、設定されます。 名前空間の詳細に自信がある場合は、手動で入力し、そうでない場合は「宣言」ボタンをクリックすると、以下に示すように名前空間の詳細が入力されま:
- SOAPサービスの名前空間は、以下に示すように設定されます:
- 同様に、以下に示すように、RESTサービスの名前空間が設定されます:
のXPATH match assertionでRESTサービスの名前空間を宣言する名前空間を宣言した後、セクションXPath式で目的のノードのXPATHを指定できます。以下に示すように、SOAPサービスのサンプルXPATH”//ns1:BooksResult/ns1:Books/ns1:CustomBookModel/ns1:Isbn”を指定できます:
でのSOAPサービスのXPathの指定同様に、以下に示すように、RESTサービスのサンプルXPATH”//ns1:books//ns1:e/ns1:isbn”を指定できます:
どちらの場合も名前空間ns1の使用に注意してください。 ノードにアクセスするには、名前空間の使用が必須です。
- Select from current:このボタンをクリックすると、上記の場合のisbnであるExpected Resultセクションで前述したように、ノードの値が自動的に選択されます。 さらに、ノードisbnの値を”9781449325862″として選択します。 このボタンをクリックして値を自動選択したくない場合は、期待される結果を手動で入力することもできます。
- テスト:”テスト”ボタンをクリックすると、出力をテストすることができ、アサーションが合格した場合、以下の成功アラートが表示されます:
またはアサーションが失敗した場合、エラーがスローされ、以下に示すようにダイアログボックスが表示されます:
- オプションのチェックボックス:期待される結果セクションには、アサーションを検証する際の追加のヘルプを提供する これらのチェックボックスの詳細を理解しましょう:
- ワイルドカードを許可するチェックボックス:検証する値がターゲット応答で動的に変更された場合、ワイルドカードを使用して応答を検証できます。 1st bookのisbnが常に”862″で終わると考えると、ワイルドカード*”862″を使用することができ、isbnが常に”862″で終わることを検証するとします。 期待される結果セクションには、次のように表示されます:
- 名前空間接頭辞を無視するチェックボックス: 応答の検証中に名前空間接頭辞を無視したい場合は、このチェックボックスをオンにすることでそれを行うことができます。
- Ignore XML Commentsチェックボックス:レスポンス内のコメントを無視する場合は、このチェックボックスを選択することでこれを実現できます。
- 上記のすべてのオプションを調べた後、保存ボタンをクリックしてアサーションを保存します。 それはアサーションとして渡され、期待されるIsbnを「9781449325862」として取得します。 その結果、次のようにサンプル出力が表示されます:
のSOAPとRESToutputビューの両方のXpath Match AssertionCommon SoapUIのXQuery Match Assertionとは何ですか?
XQueryの一致はXPathアサーションと非常によく似ていますが、XQuery式を使用して期待する結果と比較する唯一の違いがあります。
シナリオを検討する応答で使用可能な書籍のすべての”タイトル”を、存在する順序に関係なく検証したいとします。 あなたは簡単なXQueryを書くことができますし、あなたは行ってもいいです。
以下の手順に従って、”XQueryMatch”アサーションを使用して同じことを検証しましょう:
- まず、アサーションの追加ダイアログボックスに移動します。 その後、以下で強調表示されているように、”プロパティコンテンツ”アサーションカテゴリの下にある”XQuery Match”アサーションをクリックします:
- 次に、「追加」ボタンをクリックすると、以下に示すように「XQuery Match Configuration」ダイアログボックスが表示されます:
では、SOAPとRESTの両方に共通のXquery一致アサーション構成が使用されています。,
- XQuery式:これは、Webサービスの応答から値を抽出するために指定する必要があるXQuery式です。 たとえば、すべての書籍のタイトルを取得するには、次のようにXQuery式を指定します:
<Result>{for$z in //*:CustomBookModelreturn (<Title>{data($z/*:Title)}</Title>)}</Result>
上記のコードスニペットでは:
-
<Result>
XQuery応答に基づいて結果を格納するタグです。 さらに、ユーザーの選択に基づいて任意のタグにすることができます。 - さらに、forループを使用して応答を反復処理しており、z zは任意の変数であり、
<CustomBookModel>
から値を取得します。 - //. CustomBookModelのルートを指定し、名前空間を使用してナビゲートし、**”//の代わりに名前空間を指定することもできます。”.***
- 上記に加えて、”return”関数は
<Title>
タグの値を返します。 - また、”data”関数は、
<CustomBookModel>
タグ内のすべてのtitleタグのデータを返します。
2) 現在から選択: ボタンをクリックして、前述のXQueryに従って応答から現在の値を選択します。
3)期待される結果:”現在から選択”ボタンをクリックすると、サービスの応答からすべてのタイトルが返されます。 予想される結果を手動で指定することもできます。
4)”テスト”ボタンをクリックすると、以下に示すように成功応答が表示されます:
- “OK”ボタンをクリックすると、アサーションの有効な実行が表示されます。
SoapUIの一般的なコンプライアンス、ステータス、および標準アサーションは何ですか?
SoapUIが”プロパティの内容”セクションの下で提供する一般的なアサーションと同様に、SOAPとRESTの両方のWebサービスに共通する”コンプライアンス、ステータス、標準” 次のセクションで、これらすべてのアサーションの詳細を理解してみましょう。
SoapUIによって提供されるHTTPステータスコードアサーションとは何ですか?
ご存知のように、HTTPステータスコードは、HTTP要求が完了したかどうかを表します。 これらの応答コードはすべて、一般的に次のカテゴリに分割されます:
1 | 1xx:情報:これらのステータスコードは、要求の受信とその処理を表します。 |
2 | 2xx:Success:これらのステータスコードは、アクションが正常に受信、処理、および承認されたことを表します。 |
3 | 3xx:リダイレクト:これらのステータスコードは、要求を完了するために必要なその他のアクションがあることを表します。 |
4 | 4xx:クライアントエラー:これらのステータスコードは、要求に誤った構文が含まれているか、要求に何か問題があることを表します。 |
5 | 5xx:サーバーエラー:これらのステータスコードは、サーバー側のエラーがあることを表します。 |
これらのステータスコードの検証のために、SoapUIはいくつかのアサーションを提供します。 次のセクションでは、これらのアサーションの詳細を理解してみましょう:
SoapUIの有効なHTTPステータスコードアサーションとは何ですか?
このアサーションは、Webserviceによって返されるHTTP応答コードが予想されるHTTPコードのリストにあることを検証します。
BookStore APIの場合、返される応答コードが常に200または201のいずれかであることを検証するシナリオを考えてみましょう。 “Valid HTTP Status Codes”アサーションを使用して、同じものを検証できます。
“有効なHTTPステータスコード”アサーションを使用して同じことを検証するには、以下の手順に従います:
- アサーションの追加ダイアログボックスに移動し、以下に強調表示されているように、”コンプライアンス、ステータス、および標準”アサーションカテゴリの下にある”有効なHTTPステータスコード”アサーションをクリックします:
- “追加”ボタンをクリックすると、以下に示すように、”有効なHTTPステータスコードアサーション構成”ダイアログボックスが表示されます:
- “コードの指定”セクションで、値200、201を入力します。 単一のコードまたはコンマ区切りのコードのリストを指定できます。 “OK”ボタンをクリックすると、サービスの最後の応答に対してHTTPステータスコードが検証されます。
SoapUIで無効なHTTPステータスコードのアサーションとは何ですか?
“有効なHTTPステータスコード”アサーションとは対照的に、”無効なHTTPステータスコード”アサーションは、”期待されるコード”リストにWebserviceによって返されるHTTPステータスコードが含まれていないことを検証します。
BookStore APIの場合、返された応答コードが401ではないことを検証するシナリオを考えてみましょう。 “Invalid HTTP Status Codes”アサーションを使用して、同じものを検証できます。
以下の手順に従って、”無効なHTTPステータスコード”アサーションを使用して同じことを検証しましょう:
- アサーションの追加ダイアログボックスに移動し、以下に強調表示されているように、”コンプライアンス、ステータス、および標準”アサーションカテゴリの下にある”無効なHTTPステータスコード”アサーションをクリックします:
- “Add”ボタンをクリックすると、以下に示すように”Invalid HTTP status codes Assertion Configuration”ダイアログボックスが表示されます:
- “コードの指定”セクションで、値401を入力します。 単一のコードまたはコンマ区切りのコードのリストを指定できます。 “OK”ボタンをクリックすると、サービスの最後の応答に対してHTTPステータスコードが存在しないことが検証されます。
注:これらのアサーションをSOAPエンドポイントとRESTエンドポイントの両方に適用できます。
SoapUIのスキーマコンプライアンスアサーションとは何ですか?ステータスコードとは別に、SoapUIでは、テスト対象のターゲットサービスのWSDL(SOAP)またはWADL(REST)の定義に対して応答メッセージを検証することもできます。
取得しているSOAP応答がWSDLに準拠しているかどうかをすばやく確認したいシナリオを考えてみましょうか?
“スキーマコンプライアンス”アサーションを使用して同じことを検証するには、以下の手順に従います:
- アサーションの追加ダイアログボックスに移動し、以下に強調表示されているように、”コンプライアンス、ステータス、および標準”アサーションカテゴリの下にある”スキーマコンプライアンス”アサーションをクリックします:
-
“Add”ボタンをクリックすると、以下に示すように”Schema Compliance Assertion Configuration”ダイアログボックスが表示されます:
-
構成ダイアログボックスでは、プロジェクトを作成したWSDLが自動入力されますが、他のWSDLを指定する場合は、それを更新することもできます。 [OK]をクリックして続行します。
- 応答が上記のスキーマに従って準拠している場合は、上記のように成功応答が表示されます。 最後の応答がWSDLスキーマに準拠していない場合は常にエラーが表示されます。
注: 同様に、指定されたWADLに対するRESTサービスの応答を検証できます。
SoapUIの一般的なSLAアサーションは何ですか?
ご存知のように、サービスレベル契約(SLA)は、一般に、サービスプロバイダとクライアントとの間の契約と呼ばれます。 契約は、可用性、品質、応答時間などのさまざまな合意された特性によって分類することができます。 SoapUIは、特定のサービスの応答時間を検証する機能を提供します。
BookStore WebServiceの合意された応答時間が4秒未満であるという仮説的なシナリオを考えてみましょう。 SoapUIでは、”SLA”アサーションカテゴリを使用して同じことを検証できます。
以下の手順に従って、”応答SLA”アサーションを使用して同じことを検証しましょう:
- アサーションの追加ダイアログボックスに移動し、以下に強調表示されているように、”SLA”アサーションカテゴリの下にある”応答SLA”アサーションをク:
- 「Add」ボタンをクリックすると、以下に示すように「Response SLA Assertion configuration」ダイアログボックスが表示されます:
- サービスが応答を返すことを期待する最大時間(ミリ秒単位)を指定します。 このシナリオでは、4000ミリ秒を指定しました。OKボタンをクリックしてアサーションを追加します。 以下に示すように、テスト結果が表示されます:
- 上記のスクリーンショットでわかるように、サービスの応答時間は1374msであったため、前述のSLAの4000msの下にあり、アサーションが成功しました。
主要な注意事項
- SoapUIは、SOAPとRESTの両方のwebサービスに適用できる幅広いアサーションを提供します。
- さらに、一般的なアサーションのいくつかは、Contain、Not Contain、Xpath、およびXQuery Matchであり、これらはWebserviceのコンテンツの応答の検証に使用されます。
- さらに、SOAPUIによって提供される共通のアサーションの別のセットは、HTTPステータスコードとWebServicesの応答のスキーマの検証に使用されます。
- また、SoapUIはSOAPサービスとRESTサービスの両方の応答時間の検証に使用できるSLAアサーションも提供します。
次の記事に移動して、SoapUIの”Script Assertions”を使用していくつかの事前アサーションを実装する方法を理解するために、さらに深く掘り下げてみましょう。