Behauptungen in SoapUISkripte, XQuery, XPath-Typen
⚡ Intelligente Zusammenfassung
Behauptungen in SoapUI sind die Kontrollpunkte, die entscheiden, ob eine Webdienstantwort korrekt ist, und verwandeln eine Anfrage, die lediglich ausgeführt wird, in einen Test, der anhand realer, überprüfbarer Inhalte tatsächlich bestanden oder fehlgeschlagen ist.
Was ist eine Behauptung?
Unter Behauptung versteht man den Akt der Bestätigung oder Aussage. Es kann auch als Kontrollpunkt oder Validierungspunkt interpretiert werden.
Sobald eine Anfrage an einen Webserver gesendet wird, wird eine Antwort empfangen. Wir müssen überprüfen, ob die Antwort die erwarteten Daten enthält. Zur Überprüfung der Antwort benötigen wir Assertions. Ohne Assertions beweist ein Testschritt lediglich, dass der Dienst geantwortet hat, nicht aber, dass die Antwort korrekt war. API-Test sollte mindestens einen mitführen.
Arten von Behauptungen
Es gibt verschiedene Möglichkeiten, eine Antwort zu formulieren; wir werden uns jedoch auf die gebräuchlichste konzentrieren. SoapUI Assertionstypen bei der Validierung einer Antwort. Nachfolgend sind die Kategorien aufgeführt, die in der Open-Source-Version verfügbar sind. SoapUI.
- Eigenschaftsinhalt
- Compliance-Statusstandard
- Skript
- SLA
- JMS
- Sicherheit
Der Dialog gruppiert alle Aussagen in diese Kategorien, wie der untenstehende Screenshot zeigt.

Neben den oben aufgeführten Funktionen verfügt die Pro-Version auch über eine integrierte JDBC-Assertion, mit der wir überprüfen können, ob der Webdienst die Datenbank korrekt aktualisiert hat.
Versionshinweis: Strom SoapUI Die Dokumentation listet auch eine auf JDBC Kategorie (JDBC-Status und JDBC-Timeout) neben den oben genannten Kategorien und ein Nachrichteninhalt Assertions innerhalb von Property Content für einen umfassenderen XML-Vergleich. Die hier als „Pro“ bezeichnete kommerzielle Edition wird nun verkauft als ReadyAPI von SmartBear, daher können Menübezeichnungen in neueren Versionen anders aussehen, während das Verhalten der Assertions gleich bleibt.
Enthält Behauptung
Sucht nach der Existenz der angegebenen Zeichenfolge. Es unterstützt auch reguläre Ausdrücke.
Wir werden mit dem gleichen Beispiel aus dem vorherigen Tutorial mit WSDL-Anfrage fortfahren http://www.dneonline.com/calculator.asmxFalls Sie dieses Projekt noch nicht erstellt haben, arbeiten Sie es durch Erstellung eines Projekts, einer Testsuite und eines Testfalls zuerst.
Schritt 1: Standardmäßig gibt es keine Zusicherungen.
- Die Anzahl der Behauptungen wird auf der Registerkarte „Behauptungen“ angezeigt.
- Um eine neue Behauptung hinzuzufügen, klicken Sie auf die Schaltfläche „Neue Behauptung hinzufügen“.
Schritt 2: Nun
- Wählen Sie die Behauptungskategorie aus.
- Wählen Sie den Behauptungstyp aus.
- Klicken Sie auf "Hinzufügen".
Schritt 3: Wir prüfen nun, ob die Zeichenkette „46“ in der Antwort enthalten ist. Klicken Sie auf „OK“.
Hinweis: Wir können die Groß-/Kleinschreibung auch ignorieren und einen regulären Ausdruck hinzufügen.
Schritt 4: Nach dem Hinzufügen wird sofort eine Assertion ausgeführt, die anzeigt, ob GÜLTIG oder UNGÜLTIG ist.
Schritt 5: Nehmen wir nun an, wir ändern den Inhalt der 'Contains Assertion in' SoapUI' bis '47 und schau, was passiert.
Schritt 6: Die Assertion wird ausgeführt und das Ergebnis an den Benutzer zurückgegeben. Da die Zeichenkette „47“ in der Antwort nicht enthalten ist, ist die Assertion fehlgeschlagen.
Enthält keine Behauptung
Das Gegenstück funktioniert umgekehrt. Es sucht nach dem Nichtvorhandensein der angegebenen Zeichenkette. Es unterstützt auch reguläre Ausdrücke.
Schritt 1: Nachdem Sie nun auf die Schaltfläche „Neue Assertions hinzufügen“ geklickt haben,
- Wählen Sie die Behauptungskategorie aus.
- Wählen Sie den Behauptungstyp aus – in diesem Fall „NICHT enthält“.
- Klicken Sie auf "Hinzufügen".
Schritt 2: Wir prüfen, ob die Zeichenkette „intA“ in der Antwort enthalten ist. Geben Sie die Zeichenkette „FromCurrency“ ein und klicken Sie auf „OK“.
Schritt 3: Sobald eine Assertion hinzugefügt wird, wird sie ausgeführt und das Ergebnis angezeigt. Bisher haben wir zwei Assertions hinzugefügt; daher werden beide ausgeführt und das Ergebnis angezeigt.
Schritt 4: Nun ändern wir den Inhalt der „Nicht enthalten“-Assertion und beobachten das Ergebnis. Wir prüfen, ob die Zeichenkette „AddResult“ nicht vorhanden ist.
Schritt 5: Die Zeichenkette 'AddResult' ist tatsächlich in der Antwort vorhanden, daher schlägt die 'NOT Contains'-Assertion wie unten gezeigt fehl.
XPath-Match-Assertion
Da der Vergleich von Zeichenketten zu ungenau ist, zielt die nächste Assertion stattdessen auf einen einzelnen Knoten ab. Mithilfe eines XPath-Ausdrucks werden der Zielknoten und seine Werte ausgewählt. XPath, ist eine XML-Abfragesprache zum Auswählen von Knoten aus einem XML-Dokument.
Schritt 1: Nachdem Sie nun auf die Schaltfläche „Neue Assertions hinzufügen“ geklickt haben,
- Wählen Sie die Behauptungskategorie aus.
- Wählen Sie den Assertionstyp – in diesem Fall „XPath Match“.
- Klicken Sie auf "Hinzufügen".
Schritt 2: XPath hinzufügen. Das Fenster wird geöffnet.
Vor dem Hinzufügen eines SoapUI Für XPath müssen wir den Namensraum deklarieren. Ein XML-Namensraum ist eine Sammlung von Namen, die durch eine URI-Referenz (Uniform Resource Identifier) identifiziert werden und in XML-Dokumenten als Element- und Attributnamen verwendet werden. Dasselbe gilt für … SoapUI XPath-Assertion.
Zum Deklarieren eines XML-Namensraums müssen wir nur auf die Schaltfläche „Deklarieren“ klicken, was die Arbeit für uns erledigt; alternativ können wir den Namensraum auch manuell deklarieren.
Nach der Deklaration des Namespace müssen wir den XPath mithilfe des erstellten Namespace referenzieren.
Nach dem Klicken auf die Schaltfläche „Deklarieren“ werden zwei Namensräume angezeigt, da wir zwei URIs haben. Einer davon ist das Schema. URL und die andere entspricht dem eigentlichen Webdienst. URLWir müssen beim Verweisen auf XPath den tatsächlichen Namespace des Webdienstes und NICHT den Schema-Namespace verwenden. Die deklarierten Zeilen erscheinen wie unten dargestellt oben im XPath-Feld.
Deklarieren Sie den Namensraum Soap='http://schemas.xmlsoap.org/soap/envelope/';
Namensraum deklarieren ns1='http://tempuri.org/';
Schritt 3: Jetzt müssen wir den XPath des XML-Knotens eingeben, den wir validieren möchten.
//ns1:AddResult Gibt uns den Wert des dazwischen eingeschlossenen Knotens & und ns1 entspricht dem deklarierten Namespace, der auf „http://tempuri.org/“ verweist.
Nachdem wir das XML eingegeben haben, müssen wir auf „Aus aktueller Antwort auswählen“ klicken, damit der Wert aus der aktuellen Antwort zum künftigen Vergleich übernommen wird.
Schritt 4: Bis jetzt
- Nachdem wir die Namespaces deklariert haben, haben wir den XPath des XML-Knotens eingegeben, den wir validieren müssen.
- Wir müssen auf „Aus aktuellem Wert auswählen“ klicken, um den aktuellen Wert als erwarteten Wert festzulegen.
- Dem Benutzer wird der aktuelle Wert angezeigt, den wir bei Bedarf ändern können.
- Klicken Sie auf „Speichern“.
Schritt 5: Die hinzugefügte Assertion in SoapUI wird wie unten dargestellt angezeigt.
Skript-Assertions
Diese Behauptungstechnik ist die am weitesten verbreitete Technik, da es äußerst schwierig ist, Hunderte von Behauptungen zu verwalten und aufrechtzuerhalten.
SoapUI verwendet entweder Groovy Scripting oder JavaSkript für Skript-Assertions. Die Skripttechnik wird für die Entwicklung verwendet.ping Ein Framework zum Testen von SOAP. Skriptbasierte Assertions werden unter folgenden Umständen verwendet.
- Mithilfe von Skripten können Benutzer vor und nach der Ausführung eines Testfalls Operationen durchführen, indem sie die Methoden `setup` bzw. `teardown` verwenden. `setup` ist eine Prozedur, die vor der Ausführung einer bestimmten Methode ausgeführt wird (z. B. Objekterstellung und -initialisierung), während `teardown` eine Prozedur ist, die nach der Ausführung der Methode ausgeführt wird (z. B. Objektlöschung und Aufräumarbeiten). Diese Funktion ist bei anderen Assertionstypen nicht verfügbar und kann nur durch Programmierung realisiert werden.
- Es ermöglicht Benutzern, ein Projekt zu öffnen/schließen, um projektbezogene Einstellungen zu initialisieren oder zu bereinigen, und auch, um mit Umgebungsvariablen zu arbeiten, was beim Skripten sehr hilfreich ist.
- Es hilft uns bei der Durchsetzung eines dynamischen Antwortinhalts.
- Skriptbasierte Assertions werden verwendet, um benutzerdefinierte Assertions zu erstellen, die NICHT vordefiniert sind von SoapUI.
Zum Demonstrieren einer Skript-Assertion in SoapUIWir werden die Taschenrechner-WSDL und den Testfall „Add“, den wir zuvor erstellt hatten, verwenden.
Schritt 1: Die Schritte zum Hinzufügen eines Groovy-Skripts sind dieselben wie bei anderen Assertions, mit dem Unterschied, dass es sich nicht um eine vordefinierte, sondern um eine benutzerdefinierte Assertion handelt, die mehr Flexibilität als die integrierten Assertions bietet.
Wählen Sie den Testschritt aus, zu dem die Behauptung hinzugefügt werden soll.
Klicken Sie wie unten gezeigt auf die Schaltfläche „Behauptung hinzufügen“.
Schritt 2: Wählen Sie nun die Kategorie „Assertion“ aus.
- In diesem Fall handelt es sich um Script.
- Auswählen SoapUI Script Assertion und es gibt keine zugehörigen Untertypen.
- Klicken Sie auf „Hinzufügen“.
Schritt 3: Es öffnet sich der Skriptdialog, in dem der Benutzer ein benutzerdefiniertes Skript schreiben kann, um die Antwort-XML zu validieren.
Schritt 4: Nun schreiben wir ein Groovy-Skript zur Validierung der Konversionsrate. Das Skript mit den eingebetteten Kommentaren ist unten angehängt. Kenntnisse in diesem Bereich werden empfohlen. Java Skript oder Groovy Skript, bevor Sie versuchen, Ihr eigenes Skript zu schreiben.
//Define Groovy Utils and holder for validating the XML reponse content def groovyUtils = new com.eviware.soapui.support.GroovyUtils(context) def holder = groovyUtils.getXmlHolder(messageExchange.responseContent) //Define the NameSpace holder.namespaces["ns1"] = "http://tempuri.org/" //Get the Value of the Node 'AddResult' and assign to a variable def addResult = holder.getNodeValue("//ns1:AddResult") //print the value of the result in the Output panel log.info "The result value for integers is " + addResult //Comparing the value to print 'Pass' or 'Fail' if(addResult=="46") { log.info "Pass" } else { log.info "fail"}
- Klicken Sie auf die Schaltfläche „Ausführen“, um die Ausführung auszulösen.
- Die Ausgabe des Skripts wird im Ausgabebereich angezeigt. Es wurden sowohl der Conversion-Wert als auch das Endergebnis (Bestanden oder Nicht bestanden) gedruckt.
- Es wird die Information angezeigt, dass die Skript-Assertion erfolgreich war. Klicken Sie auf „OK“.
Hinweis: Das endgültige Informations-Popup wird immer mit der Meldung „Skript-Assertion bestanden“ angezeigt, solange das Skript syntaktisch korrekt ist. Es hat keinen Zusammenhang mit Ihrer Aussage im Skript.
klicken Sie auf OK
Schritt 5: Auf der Registerkarte „Assertions“ werden nun alle Assertions angezeigt, die wir für diese Testsuite hinzugefügt haben, zusammen mit dem Status jeder einzelnen Assertion.
Schritt 6: Jetzt
- Wählen Sie die Testsuite aus der Navigatorstruktur aus
- Klicken Sie auf die Schaltfläche „Ausführen“.
- Die Ergebnisse werden für die gesamte Testsuite angezeigt.
XQuery-Übereinstimmungs-Assertion
Es verwendet einen XQuery-Ausdruck, um Inhalte aus der Zieleigenschaft auszuwählen. Wir benötigen eine deutlich größere Antwort-XML, um die XQuery-Assertion besser zu verstehen. SoapUIImportieren wir nun eine weitere WSDL-Datei, wie unten gezeigt: http://www.webservicex.net/medicareSupplier.asmx?WSDL
Hinweis: Die in dieser Anleitung verwendeten öffentlichen Demo-Endpunkte von webservicex.net sind nicht mehr zuverlässig erreichbar. Daher dienen die untenstehenden Screenshots von Anfrage und Antwort weiterhin als Referenzbeispiel. Jede WSDL-Datei, die eine Menge sich wiederholender Knoten zurückgibt, führt die XQuery-Assertion auf genau dieselbe Weise aus.
Schritt 1: Klicken Sie mit der rechten Maustaste auf das bestehende Projekt und wählen Sie „WSDL hinzufügen“.
Schritt 2: Der Dialog „WSDL hinzufügen“ wird geöffnet. Belassen Sie die anderen Optionen auf den Standardeinstellungen und klicken Sie auf „OK“.
Schritt 3: Alle Arbeitsschritte sind wie folgt aufgelistet.
Schritt 4: Nun fügen wir ein Testfall innerhalb derselben Testsuite, für die wir erstellt hatten Tests der Währungsumrechner.
Schritt 5: Geben Sie den Namen des Testfalls ein und klicken Sie auf die Schaltfläche „OK“.
Schritt 6: Der Testfall wird wie unten dargestellt erstellt.
Schritt 7: Fügen Sie einen neuen Testschritt vom Typ „SOAP-Testanforderung“ hinzu, wie unten dargestellt.
Schritt 8: Geben Sie den Namen des Testschritts ein. Nehmen wir an, es handelt sich um „Lieferant_nach_Stadt“, was aussagekräftiger wäre. Klicken Sie auf „OK“.
Schritt 9: Wählen Sie die Operation, die wir validieren möchten. In diesem Fall ist es „MedicareSupplierSoap -> GetSupplierByCity“. Klicken Sie auf „OK“.
Schritt 10: Geben Sie den Namen des Testfalls ein und klicken Sie auf „OK“.
Schritt 11: Die XML-Anforderungsstruktur würde wie unten dargestellt angezeigt werden.
Schritt 12: Nun suchen wir alle Lieferanteninformationen für die Stadt „New York“.
Fügen Sie dazu Ihrem Code die folgenden Zeilen hinzu.
<GetSupplierByCity xmlns="http://www.webservicex.net/"> <City>New York</City> </GetSupplierByCity>
WSDL im folgenden URL – http://www.webservicex.net/medicareSupplier.asmx?op=GetSupplierByCity
Schritt 13: Nach Ausführung des Tests erhalten wir die folgende Antwort
Schritt 14: Angenommen, wir müssen alle Lieferantennummern validieren. Da wir Hunderte von XPath-Assertions benötigen, können wir diese nicht verwenden. Daher ist die Verwendung von XQuery in diesem Fall unumgänglich.
XQuery Assertion hilft uns, eine Gruppe von XML-Antworten zu validieren, die sich wiederholender Natur sind.
Schritt 15: Klicken Sie nun auf „Assertion hinzufügen“.
- Wählen Sie in diesem Fall die „Assertionskategorie“ – Eigenschaftsinhalt.
- Wählen Sie den Assertionstyp als „XQuery Assertion“ aus.
- Klicken Sie auf „Hinzufügen“.
Schritt 16: Ähnlich wie bei der XPath-Assertion müssen wir den Namespace deklarieren.
- Klicken Sie auf die Schaltfläche „Deklarieren“, um dies automatisch zu erlauben. SoapUI Um den Namespace zu deklarieren, wird nach dem Klicken auf die Schaltfläche „Deklarieren“ ein Popup mit der Meldung „Namespace stattdessen aus dem Schema deklarieren“ angezeigt. Klicken Sie auf „Ja“, um fortzufahren (siehe unten).
- Um die gesamte Lieferantennummer abzurufen, müssen wir eine XPath-Abfrage schreiben und diese innerhalb von <SupplierNumber> und platzieren Stichworte.
- Klicken Sie auf „Aus aktueller Antwort auswählen“, um die Ausführung anhand der aktuellen Antwort durchzuführen.
- Nach dem Klicken auf „Aus den aktuellen auswählen“ werden alle Lieferantennummern aufgelistet.
- Klicken Sie auf „Speichern“.
Hinweis: Nach dem Klicken auf die Schaltfläche „Deklarieren“ können unterschiedliche Ergebnisse auftreten. URLBei der Deklaration eines Namespace ist jedoch der Namespace des tatsächlichen Webdienstes für die Codierung maßgeblich.
Der fertige XQuery-Ausdruck mit seinen Namespace-Deklarationen sieht folgendermaßen aus.
// Namespace declaration declare namespace soap='http://schemas.xmlsoap.org/soap/envelope/'; declare namespace ns1='http://www.webservicex.net/'; declare namespace x = ''; // Placing the result in Myresult Tags{ // Iterating through all the supplier number for $x in //ns1:GetSupplierByCityResponse/ns1:SupplierDataLists/ns1:SupplierDatas/ns1:SupplierData //Return all the Supplier number within ‘SupplierNumber’ Tags. return {data($x/ns1:SupplierNumber)} }
Schritt 17: Die XQuery-Assertion wird ausgeführt und das Endergebnis im „Assertion“-Panel angezeigt (siehe unten). Wir haben nun erfolgreich eine XQuery-Assertion hinzugefügt, mit der wir alle Lieferantennummerninformationen validiert haben. Diese werden bei jeder Anfrage an den Webserver mit den tatsächlichen Werten verglichen.
Hinweis: Die tatsächlichen Werte werden nicht angezeigt. Wenn alle tatsächlichen Werte mit den erwarteten Werten übereinstimmen, wird „VALID“ angezeigt, andernfalls „Failed“.
Wann sollte die integrierte Behauptung verwendet werden?
Nachdem sowohl die Point-and-Click- als auch die skriptgesteuerten Optionen behandelt wurden, stellt sich in der Praxis die Frage, welche man wählen sollte.
- Wenn eine Antwort so kurz ist, dass sie mithilfe einer dieser integrierten Behauptungen validiert werden kann.
- Wir können Inbuilt Assertion auch verwenden, wenn die vom Webserver gesendete Antwort immer statischer Natur ist. Wenn es dynamisch ist, können wir es nicht mithilfe integrierter Behauptungen behaupten.
- Wenn die Verwendung integrierter Zusicherungen wie Timeout-Zusicherungen und Sicherheitszusicherungen unumgänglich wird.
- Eingebaute Behauptungen eignen sich ziemlich gut für den einmaligen Gebrauch, bei dem Tests nicht wiederholt werden müssen.
Behauptungsoptionen
Die erstellten Behauptungen können am besten mit Hilfe des unten hervorgehobenen Kontrollfelds gesteuert werden.
Die erstellten Behauptungen ermöglichen es Testern, folgende Dinge aus der Behauptungs-Toolbox zu konfigurieren.
| Option | Beschreibung |
| Die ausgewählte Behauptung rückt in der Reihenfolge nach oben. | |
| Die ausgewählte Behauptung wird in der Reihenfolge nach unten verschoben. | |
| Entfernt die ausgewählte Behauptung | |
| Konfigurieren/bearbeiten Sie die ausgewählte Behauptung neu. |
Nachfolgend sind die Funktionen aufgeführt, die exklusiv in der Pro-Version verfügbar sind. SoapUI, wird jetzt versendet als ReadyAPIDie Pro-Version hilft uns außerdem dabei, Assertions zu gruppieren, sodass wir den erstellten Assertions eine weitere Validierungsebene hinzufügen können.
- UND: Alle Assertions werden als gültige Assertions ausgewertet, was zur Bedingung „Bestanden“ der Gruppe führt.
- ODER: Mindestens eine der Aussagen innerhalb der Gruppe muss gültig sein, damit die Gruppe als bestanden gilt.
- Pro-Version erlaubt auch Klonen von BehauptungenDiese Option ermöglicht es Testern, das Kopieren einer Assertion in einen anderen Testschritt im selben oder in einem anderen Projekt zu erlauben.
- Assertions deaktivieren/aktivieren: Mit dieser Option können gruppierte und ungruppierte Assertions deaktiviert oder aktiviert werden. Deaktivierte Assertions werden ausgegraut dargestellt und bei der Ausführung eines Testfalls nicht berücksichtigt.
- Assertions gruppieren: Gruppierte Assertions können aufgehoben werden, wenn die Tester dies wünschen.
Vollständige Liste der Methoden, die in verschiedenen Behauptungstypen verfügbar sind
Die folgende Tabelle enthält alle oben besprochenen Aussagen, gruppiert nach der Kategorie, unter der sie im Dialogfeld „Aussage hinzufügen“ erscheinen.
| Durchsetzungsmechanismus | Beschreibung |
| EIGENTUMSINHALT | |
| Enthält | Sucht nach der Existenz der angegebenen Zeichenfolge. Es unterstützt auch reguläre Ausdrücke. |
| Nicht enthält | Sucht nach der Nichtexistenz der angegebenen Zeichenfolge. Es unterstützt auch reguläre Ausdrücke. |
| XPath-Match | Verwendet den XPath-Ausdruck, um den Zielknoten und seine Werte auszuwählen. |
| XQuery-Match | Verwendet einen XQuery-Ausdruck, um Inhalte aus der Zieleigenschaft auszuwählen. |
| Konformität, Status, Standards | |
| HTTP Alle Ressourcen herunterladen | Validiert das HTML-Dokument nach dem Herunterladen und behält alle Eigenschaften bei, die HTML enthalten. |
| Ungültiger HTTP-Status Codes | Überprüft, ob die HTML-Antwort einen Statuscode enthält, der nicht in der Liste der definierten Codes enthalten ist. |
| Kein SOAP-Fehler | Überprüft, ob die zuletzt empfangene Nachricht kein SOAP-Fehler ist. Es ist sehr offensichtlich, dass es nur für SOAP-Testschritte anwendbar ist. |
| Schemakonformität | Überprüft, ob die zuletzt empfangene Nachricht mit der WSDL- oder WADL-Standardschemadefinition kompatibel ist. Gilt für SOAP- und REST-Testschritte. |
| SOAP-Fehler | Überprüft, ob die zuletzt empfangene Nachricht ein SOAP-Fehler ist. Es ist das Gegenteil von „NOT SOAP“-Fehlerbehauptungen. |
| SOAP-Antwort | Überprüft, ob die zuletzt empfangene Antwort eine gültige SOAP-Antwort ist und gilt nur für SOAP-Testanforderungsschritte. |
| Gültiger HTTP-Status Codes | Prüft, ob die HTML-Antwort einen Statuscode enthält, der in der Liste der definierten Codes enthalten ist. Es ist das Gegenteil von „Ungültiger HTTP-Status“. Codes' Behauptung. |
| WS-Adressierungsanfrage | Überprüft, ob die zuletzt empfangene Anfrage geeignete WS-Addressing-Header enthält. |
| WS-Adressierungsantwort | Überprüft, ob die zuletzt empfangene Antwort geeignete WS-Addressing-Header enthält. |
| WS-Sicherheitsstatus | Überprüft, ob die zuletzt empfangene Nachricht gültige WS-Security-Header enthält und gilt nur für SOAP-Anfragen. |
| Skript | |
| Skript-Behauptung | Ermöglicht Benutzern die Ausführung eines benutzerdefinierten Skripts zur Durchführung benutzerdefinierter Validierungen. |
| SLA | |
| Reaktions-SLA | Überprüft, ob die Antwortzeit der zuletzt empfangenen Antwort innerhalb des definierten Grenzwerts lag. |
| JMS | |
| JMS-Status | Überprüft, ob die JMS-Anfrage des Testschritts erfolgreich ausgeführt wurde und gilt für Testschritte mit einem JMS-Endpunkt. |
| JMS-Zeitüberschreitung | Überprüft, ob die JMS-Antwort eines Testschritts nicht länger als die angegebene Dauer gedauert hat. |
| Sicherheit | |
| Offenlegung sensibler Informationen | Überprüft, ob die Antwortnachricht keine vertraulichen Informationen über das Zielsystem offenlegt. Wir können diese Behauptung für REST-, SOAP- und HTTP-Testschritte verwenden. |
Laden Sie das SOAPUI-Projekt herunter, das die oben genannten Behauptungen enthält
Häufige Fehler und Fehlerbehebung
Die meisten Assertionsfehler tracEs handelt sich um eine kleine Reihe von Fehlern; überprüfen Sie diese daher, bevor Sie einen Ausdruck neu schreiben.
- Verwenden Sie den korrekten Namespace. Der Namespace sollte lauten: URL wo sich der Webdienst befindet.
- Wenn während der Entwicklung ein Fehler auftrittping Bei einer Skript-Assertion verwenden Sie 'log.info', um den Inhalt der Variablen auszugeben.
- Wenn Sie nicht die gewünschte Ausgabe erhalten, überprüfen Sie, ob in der Anforderung eine gültige Eingabe übergeben wird.
Wenn Sie beispielsweise im Währungsrechner den Wert 'intA' als 'x' eingeben, was keine ganze Zahl ist, wird der Fehlercode 'SOAP-Client' ausgegeben. Dies bedeutet, dass das Problem mit dem vom Client übergebenen Parameter zusammenhängt. Die Anfrage mit dem ungültigen Wert wird zuerst angezeigt.
Die Antwort liefert den Fehlercode anstelle eines Ergebnisses, wie unten dargestellt.
Achten Sie darauf, die korrekte Syntax für XPath- und XQuery-Assertions zu verwenden. Verwenden Sie NICHT den Punkt (.) anstelle des Doppelpunkts (:). Die Syntax lautet //namespace:Tagname und NICHT //namespace.tagname. Andernfalls erhalten Sie möglicherweise die Meldung „Keine Übereinstimmung in der aktuellen Antwort“, obwohl der Tag-Name korrekt ist.














































