• Articles
• admin

In den beiden vorherigen Artikeln haben wir die Details von testspezifischen Assertions behandelt, die nur für eine bestimmte Art von TestFall oder WebService im Test anwendbar waren. Alle im Artikel „SoapUI Test Specific Assertions: REST Services“ genannten Assertionen gelten nur für REST-WebServices und alle im Artikel „SoapUI Test Specific Assertions: SOAP Services“ genannten Assertionen gelten nur für SOAP-WebServices. Jetzt bietet SoapUI auch einige andere Zusicherungen, die sowohl für SOAP- als auch für REST-Dienste gelten und als SoapUI Common Assertions bekannt sind. In diesem Artikel werden wir die Verwendung all dieser gängigen Behauptungen verstehen, indem wir die Details unter den folgenden Themen behandeln:

• Was sind die allgemeinen Inhaltszusicherungen für Eigenschaften in SoapUI?
  • Was ist eine Behauptung in SoapUI?
  • Was ist außerdem keine Behauptung in SoapUI?
  • Was ist XPath Assertion in SoapUI?
  • Was ist XQuery Match Assertion In SoapUI?
• Was sind in ähnlicher Weise die gängigen Compliance-, Status- und Standardzusicherungen in SoapUI?
  • Was sind HTTP-Statuscodes, die von SoapUI bereitgestellt werden?
  • Was sind außerdem die Schema-Compliance-Zusicherungen in SoapUI?
• Was sind die allgemeinen SLA-Behauptungen in SoapUI?

Da alle diese Zusicherungen sowohl für SOAP- als auch für REST-Dienste gelten, verwenden wir die folgenden Informationen zur Validierung all dieser Zusicherungen:

• Das REST-Projekt wurde mit URI erstellt: „http://bookstore.toolsqa.com/BookStore/v1/Books“ und das mit WSDL erstellte SOAP-Projekt: „http://bookstore.toolsqa.com/BookStoreService.wsdl“ gemäß den im Artikel „SoapUI: Arbeiten mit Projekten.“
• Sie können auf die Beispielausgabe des REST-Projekts aus dem Artikel „SoapUI Test Specific Assertions: REST Services“ und auf die Beispielausgabe des SOAP-Projekts aus dem Artikel „SoapUI Test Specific Assertions: SOAP Services“ verweisen.

Was sind die allgemeinen Inhaltszusicherungen für Eigenschaften in SoapUI?

Wie wir bereits wissen, validieren die Property Content Assertions den Inhalt der empfangenen Antwort. SoapUI bietet mehrere Inhaltszusicherungen, die sowohl für SOAP- als auch für REST-Anforderungen gelten. Lassen Sie uns in den folgenden Abschnitten sehen, wie wir diese Behauptungen verwenden können?

Was ist eine Behauptung in SoapUI?

Die Contains-Assertion sucht nach dem Vorhandensein eines Zeichenfolgentoken im Eigenschaftswert.

Stellen Sie sich ein Szenario vor, in dem wir im Buchhandelsdienst prüfen müssen, ob ein Buch mit dem Autorennamen „Richard E. Silverman“ existiert?Befolgen Sie die unten genannten Schritte, um dasselbe mit der Assertion „Contains“ zu validieren:

1. Navigieren Sie zunächst zum Dialogfeld Assertion hinzufügen. Klicken Sie anschließend auf die Assertion „Enthält“ in der Assertionskategorie „Eigenschaftsinhalt“, wie unten hervorgehoben:

1. Zweitens klicken Sie auf die Schaltfläche „Hinzufügen“, und es wird das Dialogfeld „Enthält Assertion“ angezeigt, wie unten gezeigt:

1. Drittens geben Sie im Abschnitt „Inhalt“ den Namen des Autors „Richard E. Silverman“ ein. Es ist die Suchzeichenfolge, die Sie in der Antwort des Webdienstes überprüfen möchten.

2. Viertens sehen Sie im obigen Dialogfeld auch zwei Kontrollkästchen. Sie sind:

• Groß-/Kleinschreibung ignorieren: Wenn Sie das Kontrollkästchen Groß-/Kleinschreibung ignorieren aktivieren, wird die Zeichenfolge überprüft, indem die Groß-/Kleinschreibung ignoriert wird. Angenommen, Sie geben „richARD E. SilVerMan“ in das Textfeld Inhalt ein und aktivieren das Kontrollkästchen „Groß- und Kleinschreibung im Vergleich ignorieren“. Darüber hinaus wird der Fall ignoriert und nur nach dem Wert der eingegebenen Zeichenfolge gesucht.

Die Assertion wird also übergeben, da die Zeichen in der Zeichenfolge identisch sind, wenn wir den Fall ignorieren.

• Regulärer Ausdruck: Wenn Sie die Ausgabe basierend auf einem regulären Ausdruck validieren möchten, können Sie dieses Kontrollkästchen aktivieren und dann Ihren regulären Ausdruck im Abschnitt Inhalt angeben. SoapUI folgt den regulären Ausdrucksmustern von Oracle Zum Beispiel angegeben, wenn wir überprüfen möchten, dass die Buch-Service-Antwort enthält „O’Reilly“ in der Antwort, Sie können angeben, „.O’Reilly.“ als RegEx im Inhaltsbereich, wie unten gezeigt:

Wir können also die Existenz einer Zeichenfolge in der Antwort des Webdienstes mithilfe der Contains Assertion überprüfen und diese sowohl für SOAP- als auch für REST-Webdienste verwenden.

Was ist keine Behauptung in SoapUI?

Im Gegensatz zur Contains-Assertion sucht die Not Contains-Assertion nach der Nichtexistenz einer Zeichenfolge im Eigenschaftswert. Darüber hinaus wird diese Assertion übergeben, wenn die Antwort nicht den angegebenen Wert enthält.

Nehmen wir an; Wir wollen validieren, dass es kein Buch mit dem Titel „Groovy Book“ in der Antwort des Bookstore-Dienstes gibt, wir können diese Behauptung verwenden, um die Antwort der BookStore-API zu validieren.

Folgen wir den unten genannten Schritten, um dasselbe mit der Assertion „Not Contains“ zu validieren:

1. Navigieren Sie zunächst zum Dialogfeld Assertion hinzufügen und klicken Sie auf die Assertion „Nicht enthält“ unter der Assertionskategorie „Eigenschaftsinhalt“, wie unten hervorgehoben:

1. Zweitens klicken Sie auf die Schaltfläche „Hinzufügen“, und es wird das Dialogfeld „NotContains Assertion“ angezeigt, wie unten gezeigt:

2. Drittens geben Sie im Abschnitt „Inhalt“ den Namen der Zeichenfolge “ Groo Book“ ein. Es ist die Suchzeichenfolge, die Sie überprüfen möchten, die in der Antwort des Webdienstes nicht vorhanden ist.

Hinweis: Die beiden Kontrollkästchen (Ignore Case & RegEx ) funktionieren hier genauso wie bei der Contains Assertion .

1. Viertens wird durch Klicken auf die Schaltfläche „OK“ die Assertion für die WebService-Antwort ausgeführt und das Ergebnis wie unten gezeigt angezeigt:

1. Solange die Zeichenfolge in der Antwort des Zieldienstes nicht vorhanden ist, wird die Assertion übergeben.

Was ist XPath Match Assertion in SoapUI?

Mit der XPath Match Assertion können Sie einen XPath-Ausdruck verwenden, um den Inhalt aus dem spezifischen Knoten der Zielantwort auszuwählen und mit dem erwarteten Wert zu vergleichen.

Angenommen, Sie möchten überprüfen, ob die ISBN des ersten in der Antwort der BookStore-API vorhandenen Buches nicht null ist. Wir können dasselbe schnell mit der XPath-Assertion validieren.

Folgen wir den unten genannten Schritten, um dasselbe mit der Assertion „XPath Match“ zu validieren:

1. Navigieren Sie zunächst zum Dialogfeld Assertion hinzufügen. Klicken Sie danach auf die Assertion „XPath Match“ unter der Assertionskategorie „Eigenschaftsinhalt“, wie unten hervorgehoben:

1. Zweitens klicken Sie auf die Schaltfläche „Hinzufügen“, und es wird das Dialogfeld „Xpath Match Configuration“ angezeigt, wie unten gezeigt:

Wobei,

• Deklarieren: Durch Klicken auf diese Schaltfläche wird der Namespace automatisch abgerufen und gefüllt. Wenn Sie sich der Details des Namespace sicher sind, können Sie ihn manuell eingeben, andernfalls klicken Sie einfach auf die Schaltfläche „Deklarieren“ und die Namespace-Details werden wie unten gezeigt ausgefüllt:

  • Der Namespace für den SOAP-Dienst wird wie unten gezeigt ausgefüllt:

• In ähnlicher Weise wird der Namespace für den REST-Dienst wie unten gezeigt ausgefüllt:

Nachdem wir den Namespace deklariert haben, können wir XPATH des gewünschten Knotens im Abschnitt XPath-Ausdruck angeben.

• Sie können einen Beispiel-XPATH „//ns1:BooksResult/ns1:Books/ns1:CustomBookModel/ns1:Isbn“ für den SOAP-Dienst angeben, wie unten gezeigt:

Ebenso können Sie einen Beispiel-XPATH „//ns1:books//ns1:e/ns1:isbn“ für den REST-Dienst angeben, wie unten gezeigt:

Beachten Sie die Verwendung des Namespace ns1 in beiden Fällen. Für den Zugriff auf die Knoten ist die Verwendung des Namespace obligatorisch.

• Select from current: Durch Klicken auf diese Schaltfläche wird automatisch der Wert des Knotens ausgewählt, wie oben im Abschnitt Erwartetes Ergebnis erwähnt, im obigen Fall isbn. Zusätzlich wird der Wert der ISBN als „9781449325862“ ausgewählt. Wenn Sie den Wert nicht automatisch auswählen möchten, indem Sie auf diese Schaltfläche klicken, können Sie das erwartete Ergebnis sogar manuell eingeben.
• Test: Durch Klicken auf die Schaltfläche „Test“ können Sie die Ausgabe testen. Wenn die Assertion bestanden ist, wird die folgende Erfolgswarnung angezeigt :

Oder wenn die Assertion fehlschlägt, wird ein Fehler ausgegeben und ein Dialogfeld angezeigt, wie unten gezeigt:

• Optionale Kontrollkästchen: Der Abschnitt Erwartetes Ergebnis enthält auch einige Kontrollkästchen, die zusätzliche Hilfe bei der Validierung der Assertion bieten. Lassen Sie uns die Details dieser Kontrollkästchen verstehen:
• Platzhalter zulassen Kontrollkästchen: Wenn sich der Wert, den wir validieren möchten, dynamisch in der Zielantwort ändert, können wir Platzhalter verwenden, um die Antwort zu validieren. Angenommen, wenn wir bedenken, dass die ISBN des 1. Buches immer mit „862“ endet, können wir den Platzhalter * „862“ verwenden, der bestätigt, dass die isbn immer mit „862“ endet. Es wird im Abschnitt Erwartetes Ergebnis als angezeigt:

• Kontrollkästchen Namespace-Präfix ignorieren: Wenn wir das Namespace-Präfix während der Validierung der Antwort ignorieren möchten, können wir dies tun, indem wir dieses Kontrollkästchen aktivieren.
• Kontrollkästchen XML-Kommentare ignorieren: Wenn wir die Kommentare in der Antwort ignorieren möchten, können wir dies erreichen, indem wir dieses Kontrollkästchen aktivieren.
• Nachdem Sie alle oben genannten Optionen untersucht haben, klicken Sie auf die Schaltfläche Speichern, um die Assertion zu speichern. Es wird als Behauptung übergeben und erhält die erwartete Isbn als „9781449325862“. Folglich wird die Beispielausgabe wie folgt angezeigt:

Was ist XQuery Match Assertionin SoapUI?

Die XQuery-Übereinstimmung ist der XPath-Assertion sehr ähnlich, mit dem einzigen Unterschied, dass sie einen XQuery-Ausdruck verwendet und ihn mit dem erwarteten Ergebnis vergleicht.

Betrachten Sie ein Szenario, in dem Sie alle „Titel“ der in der Antwort verfügbaren Bücher validieren möchten, unabhängig von der Reihenfolge, in der sie vorhanden sind. Sie können eine einfache XQuery schreiben und dann können Sie loslegen.

Folgen wir den unten genannten Schritten, um dasselbe mit der Assertion „XQueryMatch“ zu validieren:

1. Navigieren Sie zunächst zum Dialogfeld Assertion hinzufügen. Klicken Sie anschließend auf die Assertion „XQuery Match“ in der Assertionskategorie „Eigenschaftsinhalt“, wie unten hervorgehoben:

1. Zweitens klicken Sie auf die Schaltfläche „Hinzufügen“, und es wird das Dialogfeld „XQuery Match Configuration“ angezeigt, wie unten gezeigt:

Where,

• XQuery-Ausdruck: Dies ist der XQuery-Ausdruck, den Sie angeben müssen, um den Wert aus der Antwort des Webservices zu extrahieren. Um beispielsweise den Titel aller Bücher zu erhalten, können wir den XQuery-Ausdruck wie folgt angeben:

<Result>{for$z in //*:CustomBookModelreturn (<Title>{data($z/*:Title)}</Title>)}</Result>

Im obigen Code-Snippet:

• <Result> ist das Tag, in dem das Ergebnis basierend auf der XQuery-Antwort gespeichert wird. Darüber hinaus kann es sich um ein beliebiges Tag handeln, das auf der Auswahl des Benutzers basiert.
• Zusätzlich iterieren wir die Antwort mit der for-Schleife, und $z ist eine beliebige Variable, die den Wert von <CustomBookModel> erhält.
• //. sie können auch mit Namespace navigieren und dann den Namespace anstelle von **“// angeben.“.***
• Zusätzlich zu den oben genannten gibt die Funktion „return“ den Wert des <Title> -Tags zurück.
• Außerdem gibt die Funktion „Daten“ die Daten jedes Titel-Tags im <CustomBookModel> -Tag zurück.

2) Wählen Sie aus dem aktuellen: Klicken Sie auf die Schaltfläche, um den aktuellen Wert aus der Antwort gemäß der genannten XQuery auszuwählen.

3) Erwartetes Ergebnis: Nach dem Klicken auf die Schaltfläche „Aus aktuellem Auswählen“ werden alle Titel aus der Antwort des Dienstes zurückgegeben. Sie können das erwartete Ergebnis auch manuell angeben.

4) Wenn Sie auf die Schaltfläche „Test“ klicken, wird die Erfolgsantwort wie unten gezeigt angezeigt:

1. Durch Klicken auf die Schaltfläche „OK“ wird die gültige Ausführung der Assertion angezeigt.

Was sind die allgemeinen Compliance-, Status- und Standardzusicherungen in SoapUI?

Wie die von SoapUI im Abschnitt „Eigenschaftsinhalt“ bereitgestellten allgemeinen Zusicherungen enthält es auch einige Zusicherungen in der Kategorie „Compliance, Status und Standard“, die sowohl für SOAP- als auch für REST-Webdienste üblich sind. Lassen Sie uns die Details all dieser Behauptungen in den folgenden Abschnitten verstehen:

Was sind HTTP-Statuscode-Behauptungen, die von SoapUI bereitgestellt werden?

Wie wir alle wissen, geben die HTTP-Statuscodes an, ob eine HTTP-Anforderung abgeschlossen wurde oder nicht. Alle diese Antwortcodes sind im Allgemeinen in die folgenden Kategorien unterteilt:

1	1xx: Informativ: Diese Statuscodes stellen den Eingang der Anfrage und deren Bearbeitung dar.
2	2xx: Erfolg: Diese Statuscodes zeigen an, dass die Aktion erfolgreich empfangen, verarbeitet und akzeptiert wurde.
3	3xx: Umleitung: Diese Statuscodes stellen dar, dass weitere Aktionen erforderlich sind, um die Anforderung abzuschließen.
4	4xx: Clientfehler: Diese Statuscodes stellen dar, dass die Anforderung eine falsche Syntax enthält oder dass mit unserer Anforderung etwas nicht stimmt.
5	5xx: Serverfehler: Diese Statuscodes stellen dar, dass ein serverseitiger Fehler vorliegt, was bedeutet, dass der Server eine gültige Anforderung nicht erfüllen konnte.

Zur Validierung dieser Statuscodes bietet SoapUI einige Zusicherungen. Lassen Sie uns die Details dieser Behauptungen in den folgenden Abschnitten verstehen:

Was ist eine gültige HTTP-Statuscode-Assertion in SoapUI?

Diese Assertion validiert, dass der vom Webservice zurückgegebene HTTP-Antwortcode in der Liste der erwarteten HTTP-Codes liegt.

Betrachten Sie ein Szenario, in dem wir für die BookStore-API überprüfen möchten, ob der zurückgegebene Antwortcode immer entweder 200 oder 201 ist. Wir können die Behauptung „Gültige HTTP-Statuscodes“ verwenden, um dasselbe zu validieren.

Folgen wir den unten genannten Schritten, um dasselbe mit der Assertion „Gültige HTTP-Statuscodes“ zu validieren:

1. Navigieren Sie zum Dialogfeld Assertion hinzufügen und klicken Sie auf die Assertion „Gültige HTTP-Statuscodes“ in der Assertionskategorie „Compliance, Status und Standard“, wie unten hervorgehoben:

1. Klicken Sie auf die Schaltfläche „Hinzufügen“, und es wird das Dialogfeld „Gültige HTTP-Statuscodes für die Konfiguration“ angezeigt, wie unten gezeigt:

1. Geben Sie im Abschnitt „Codes angeben“ die Werte 200, 201 ein. Sie können entweder einen einzelnen Code oder eine Liste kommagetrennter Codes angeben. Durch Klicken auf die Schaltfläche „OK“ werden die HTTP-Statuscodes anhand der letzten Antwort des Dienstes überprüft.

Was ist eine ungültige HTTP-Statuscode-Assertion in SoapUI?

Im Gegensatz zur Assertion „Gültige HTTP-Statuscodes“ validiert die Assertion „Ungültige HTTP-Statuscodes“, dass die Liste „Erwartete Codes“ nicht den vom Webservice zurückgegebenen HTTP-Statuscode enthält.

Betrachten Sie ein Szenario, in dem wir für die BookStore-API überprüfen möchten, ob der zurückgegebene Antwortcode nicht 401 ist. Wir können die Behauptung „Ungültige HTTP-Statuscodes“ verwenden, um dasselbe zu validieren.

Folgen wir den unten genannten Schritten, um dasselbe mit der Assertion „Ungültige HTTP-Statuscodes“ zu validieren:

1. Navigieren Sie zum Dialogfeld Assertion hinzufügen und klicken Sie auf die Assertion „Ungültige HTTP-Statuscodes“ in der Assertionskategorie „Compliance, Status und Standard“, wie unten hervorgehoben:

1. Klicken Sie auf die Schaltfläche „Hinzufügen“, und es wird das Dialogfeld „Ungültige HTTP-Statuscodes Assertion Configuration“ angezeigt, wie unten gezeigt:

1. Geben Sie im Abschnitt „Codes angeben“ die Werte 401 ein. Sie können entweder einen einzelnen Code oder eine Liste kommagetrennter Codes angeben. Durch Klicken auf die Schaltfläche „OK“ wird das Nichtvorhandensein von HTTP-Statuscodes anhand der letzten Antwort des Dienstes überprüft.

Hinweis: Wir können diese Zusicherungen sowohl auf SOAP- als auch auf REST-Endpunkte anwenden.

Was sind die Schema-Compliance-Zusicherungen in SoapUI?

Neben den Statuscodes können wir in SoapUI auch die Antwortnachricht anhand der Definition in der WSDL (SOAP) oder WADL(REST) des zu testenden Zieldienstes validieren.

Betrachten Sie ein Szenario, in dem wir schnell überprüfen möchten, ob die SOAP-Antwort, die wir erhalten, mit der WSDL kompatibel ist oder nicht?

Folgen wir den unten genannten Schritten, um dasselbe mit der Assertion „Schema Compliance“ zu validieren:

1. Navigieren Sie zum Dialogfeld Assertion hinzufügen und klicken Sie auf die Assertion „Schema Compliance“ unter der Assertionskategorie „Compliance, Status und Standard“, wie unten hervorgehoben:

1. Klicken Sie auf die Schaltfläche „Hinzufügen“, und es wird das Dialogfeld „Schema Compliance Assertion Configuration“ angezeigt, wie unten gezeigt:

2. Wenn Sie jedoch eine andere WSDL angeben möchten, können Sie sie auch aktualisieren. Klicken Sie auf OK, um fortzufahren.

1. Wenn die Antwort gemäß dem genannten Schema kompatibel ist, wird die Erfolgsantwort wie oben gezeigt angezeigt. Sie sehen den Fehler immer dann, wenn die letzte Antwort nicht dem WSDL-Schema entspricht.

Hinweis: Ebenso können Sie die Antwort des REST-Dienstes anhand einer angegebenen WADL validieren.

Was sind die üblichen SLA-Behauptungen in SoapUI?

Wie wir alle wissen, wird ein Service Level Agreement (SLA) im Allgemeinen als Vereinbarung zwischen einem Dienstanbieter und einem Kunden bezeichnet. Die Vereinbarung kann nach verschiedenen vereinbarten Merkmalen wie Verfügbarkeit, Qualität, Reaktionszeit usw. klassifiziert werden. SoapUI bietet die Funktionalität, die Antwortzeit eines bestimmten Dienstes zu validieren.

Betrachten Sie ein hypothetisches Szenario, in dem die vereinbarte Antwortzeit für den BookStore-WebService weniger als 4 Sekunden beträgt. Wir können dasselbe in SoapUI mithilfe der Assertionskategorien „SLA“ validieren.

Folgen wir den unten genannten Schritten, um dasselbe mit der Assertion „Response SLA“ zu validieren:

1. Navigieren Sie zum Dialogfeld Assertion hinzufügen und klicken Sie auf die Assertion „Response SLA“ unter der Assertionskategorie „SLA“, wie unten hervorgehoben:

1. Klicken Sie auf die Schaltfläche „Hinzufügen“, und es wird das Dialogfeld „Response SLA Assertion configuration“ angezeigt, wie unten gezeigt:

1. Geben Sie die maximale Zeit (in ms) an, in der der Dienst erwartet, dass die Antwort zurückgegeben wird. Für unser Szenario haben wir 4000 ms angegeben. Klicken Sie auf die Schaltfläche OK, um die Assertion hinzuzufügen. Es wird das Testergebnis zeigen, wie unten gezeigt:

1. Wie wir im obigen Screenshot sehen können, da die Antwortzeit des Dienstes 1374 ms betrug, lag sie unter dem genannten SLA von 4000 ms und führte zu einer erfolgreichen Behauptung.

Wichtige Erkenntnisse

• SoapUI bietet eine breite Palette von Assertionen, die sowohl auf SOAP- als auch auf REST-Webdienste angewendet werden können.
• Darüber hinaus sind einige der gängigen Zusicherungen Contain , Not Contain , Xpath und XQuery Match , die für die Validierung der Antwort des Inhalts des Webdienstes verwendet werden.
• Darüber hinaus wird ein weiterer von SoapUI bereitgestellter Satz allgemeiner Assertionen zur Validierung der HTTP-Statuscodes und des Schemas der Antwort der Webdienste verwendet.
• Außerdem bietet SoapUI eine SLA-Assertion, die zur Validierung der Antwortzeit von SOAP- und REST-Diensten verwendet werden kann.

Gehen wir zum nächsten Artikel, in dem wir tiefer eintauchen werden, um zu verstehen, wie wir einige erweiterte Assertionen mit „Script Assertions“ in SoapUI implementieren können.