SoapUI - Kurzanleitung

SOAP ist die Abkürzung für Simple Object Access Protocol. Es wird vom World Wide Web Consortium (W3C) unter definierthttps://www.w3.org/TR/2000/NOTE-SOAP-20000508 wie folgt -

SOAP ist ein leichtes Protokoll für den Informationsaustausch in einer dezentralen, verteilten Umgebung. Es ist ein XML-basiertes Protokoll, das aus drei Teilen besteht: einem Umschlag, der ein Framework definiert, um zu beschreiben, was in einer Nachricht enthalten ist und wie sie verarbeitet wird; einen Satz von Codierungsregeln zum Ausdrücken von Instanzen anwendungsdefinierter Datentypen; und eine Konvention zum Darstellen von Remoteprozeduraufrufen und -antworten.

SOAP - Wichtige Funktionen

Im Folgenden sind einige wichtige Funktionen von SOAP aufgeführt.

• Es ist ein Kommunikationsprotokoll für die Kommunikation über das Internet.

• Es kann HTTP für XML-Messaging erweitern.

• Es bietet Datentransport für Webdienste.

• Es kann vollständige Dokumente austauschen oder eine Remote-Prozedur aufrufen.

• Es kann zum Senden einer Nachricht verwendet werden.

• Es ist sowohl plattform- als auch sprachunabhängig.

• Es ist die XML-Methode, um zu definieren, welche Informationen wie gesendet werden.

• Es ermöglicht Clientanwendungen, einfach eine Verbindung zu Remotediensten herzustellen und Remotemethoden aufzurufen.

Obwohl SOAP in einer Vielzahl von Nachrichtensystemen verwendet und über eine Vielzahl von Transportprotokollen bereitgestellt werden kann, liegt der anfängliche Fokus von SOAP auf Remoteprozeduraufrufen, die über HTTP transportiert werden. Andere Frameworks wie CORBA, DCOM und Java RMI bieten ähnliche Funktionen wie SOAP, SOAP-Nachrichten sind jedoch vollständig in XML geschrieben und daher eindeutig plattform- und sprachunabhängig.

Eine SOAP-Nachricht ist ein gewöhnliches XML-Dokument, das die folgenden Elemente enthält:

• Envelope- Definiert den Anfang und das Ende der Nachricht. Es ist ein obligatorisches Element.

• Header- Enthält alle optionalen Attribute der Nachricht, die bei der Verarbeitung der Nachricht verwendet werden, entweder an einem Zwischenpunkt oder am endgültigen Endpunkt. Es ist ein optionales Element.

• Body- Enthält die XML-Daten der gesendeten Nachricht. Es ist ein obligatorisches Element.

• Fault - Ein optionales Fehlerelement, das Informationen zu Fehlern enthält, die während der Verarbeitung der Nachricht auftreten.

Alle diese Elemente werden im Standard-Namespace für den SOAP-Umschlag deklariert.

https://www.w3.org/2001/12/soap-envelope

Der Standard-Namespace für SOAP-Codierung und Datentypen lautet -

https://www.w3.org/2001/12/soap-encoding

Note- Alle diese Spezifikationen können sich ändern. Aktualisieren Sie sich daher ständig mit den neuesten Spezifikationen, die auf der W3-Website verfügbar sind.

SOAP - Nachrichtenstruktur

Der folgende Block zeigt die allgemeine Struktur einer SOAP-Nachricht -

<?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 ist die Abkürzung für Representational State Transfer. Es kann als architektonischer Stil für die Gestaltung von Software definiert werden. REST ist keine Spezifikation oder W3C-Standard. Daher ist es einfacher, mit RESTful Services zu arbeiten. Es ist kein Middleware-Spezifikationsframework erforderlich.

REST - Wichtige Funktionen

Im Folgenden sind einige wichtige Funktionen von REST aufgeführt.

• Es basiert auf einem zustandslosen, Client-Server-zwischenspeicherbaren Kommunikationsprotokoll - praktisch in allen Fällen wird HTTP verwendet.

• Es ist eine leichte Alternative zu WebService und RPC (Remote Procedure Call) wie SOAP-WSDL.

• Es repräsentiert alles in eindeutigen IDs oder URIs.

• Es werden Standard-HTTP-Methoden wie GET, POST, PUT, DELETE verwendet.

• Es verknüpft Quellen miteinander.

• REST-Ressourcen können mehrere Darstellungen haben.

• Alle benannten Informationen werden als Ressource betrachtet. Beispiel: Ein Bild, eine Person oder ein Dokument können als Beispiel für eine Ressource betrachtet und als eindeutige ID oder URI dargestellt werden.

• Das auf HTTP basierende World Wide Web selbst kann als REST-basierte Architektur angesehen werden.

REST-Services sind plattform- und sprachunabhängig. Da es auf HTTP-Standards basiert, kann es problemlos bei Vorhandensein von Firewalls verwendet werden. Wie WebServices bietet REST keine integrierte Sicherheit, Sitzungsverwaltung und QoS-Garantie. Diese können jedoch hinzugefügt werden, indem auf HTTP aufgebaut wird. Für die Verschlüsselung kann REST zusätzlich zu HTTPS verwendet werden.

SoapUI ist ein Tool, das sowohl für funktionale als auch für nicht funktionale Tests verwendet werden kann. Es ist nicht auf Webdienste beschränkt, obwohl es das De-facto-Tool ist, das beim Testen von Webdiensten verwendet wird.

SoapUI - Wichtige Funktionen

Im Folgenden sind einige wichtige Funktionen von SoapUI aufgeführt.

• Es ist in der Lage, sowohl die Rolle des Kunden als auch des Dienstes zu übernehmen.

• Es ermöglicht den Benutzern, funktionale und nicht funktionale Tests schnell und effizient in einer einzigen Umgebung zu erstellen.

• Es ist unter den Bedingungen der GNU Leaser General Public License (LGPL) lizenziert.

• Es wird ausschließlich mit der JAVA-Plattform implementiert.

• Es unterstützt Windows, Mac und mehrere Linux-Dialekte.

• Es ermöglicht Testern, automatisierte Funktions-, Regressions-, Compliance- und Lasttests auf verschiedenen Web-APIs auszuführen.

• Es unterstützt alle Standardprotokolle und -technologien zum Testen aller Arten von APIs.

SoapUI kann verwendet werden, um vollständige RESTful API- und SOAP Web Service-Tests zu testen. Es unterstützt Funktionstests, Leistungstests, Interoperabilitätstests, Regressionstests, Lasttests und vieles mehr.

Es ist benutzerfreundlich und es ist einfach, Funktionstests in nichtfunktionale Tests wie Last- und Stresstests umzuwandeln.

SoapUI ist reich an den folgenden fünf Aspekten:

• Funktionsprüfung
• Sicherheitstests
• Lasttest
• Protokolle und Technologien
• Integration mit anderen Tools

Erfahren Sie mehr über jede dieser Funktionen.

Funktionsprüfung

• Mit SoapUI können die Tester funktionale API-Tests in SoapUI schreiben.

• SoapUI unterstützt die Drag-Drop-Funktion, die die Skriptentwicklung beschleunigt.

• SoapUI unterstützt das Debuggen von Tests und ermöglicht es Testern, datengesteuerte Tests zu entwickeln.

• SoapUI unterstützt mehrere Umgebungen, sodass Sie problemlos zwischen QS-, Dev- und Prod-Umgebungen wechseln können.

• SoapUI ermöglicht erweitertes Scripting (der Tester kann seinen benutzerdefinierten Code abhängig von den Szenarien entwickeln).

Sicherheitstests

• SoapUI führt einen vollständigen Satz von Schwachstellen-Scans durch.

• SoapUI verhindert, dass SQL Injection die Datenbanken schützt.

• SoapUI sucht nach Stapelüberläufen, die durch große Dokumente verursacht werden.

• SoapUI sucht nach standortübergreifendem Scripting, das auftritt, wenn Dienstparameter in Nachrichten verfügbar gemacht werden.

• SoapUI führt einen Fuzzing-Scan und einen Boundary-Scan durch, um ein fehlerhaftes Verhalten der Dienste zu vermeiden.

Lasttest

• SoapUI verteilt die Auslastungstests auf n LoadUI-Agenten.

• SoapUI simuliert mühelos Tests mit hohem Volumen und realer Last.

• Mit SoapUI können erweiterte benutzerdefinierte Berichte Leistungsparameter erfassen.

• SoapUI ermöglicht eine durchgängige Überwachung der Systemleistung.

Protokolle und Technologien

SoapUI unterstützt eine Vielzahl von Protokollen -

• SOAP - Simple Object Access Protocol
• WSDL - Web Service Definition Language
• REST - Repräsentativer Staatstransfer
• HTTP - Hyper Text Transmission Protocol
• HTTPS - Hyper Text Transmission Protocol gesichert
• AMF - Aktionsnachrichtenformat
• JDBC - Java-Datenbankkonnektivität
• JMS - Java Messaging Service

Integration mit anderen Tools

• Apache Maven-Projekt
• HUDSON
• JUnit
• Apache - Ameise und mehr….

SoapUI ist ein Open Source-Tool für kostenlose Versionen mit grundlegenden Testfunktionen, während SoapUI NG Pro ein kommerzialisiertes Tool mit erweiterten Funktionen für Berichterstellung, datengesteuerte Funktionen und vielem mehr ist.

Vergleich

In der folgenden Tabelle werden die verschiedenen Funktionen von SoapUI und SoapUI NG Pro verglichen und gegenübergestellt.

Eigenschaften	SoapUI	SoapUI NG Pro
Supported Technologies
SEIFE	Ja	Ja
WSDL / WADL	Ja	Ja
SICH AUSRUHEN	Ja	Ja
JMS	Ja	Ja
AMF	Ja	Ja
JDBC	Ja	Ja
HTTP	Ja	Ja
General Features
Eigenständige Anwendung	Ja	Ja
Unterstützung für mehrere Umgebungen	Nein	Ja
Floating License	Nein	Ja
WSDL-Abdeckung	Nein	Ja
Anforderungs- / Antwortabdeckung	Nein	Ja
Nachrichtensicherung	Ja	Ja
Refactoring testen	Nein	Ja
Mehrere Tests ausführen	Ja	Ja
Datenquellengesteuerter Test	Nein	Ja
Skriptbibliotheken	Nein	Ja
Unit Reporting	Nein	Ja
Manuelle Testschritte	Ja	Ja
Reporting
Junit-Berichte	Nein	Ja
Export von Berichtsdaten	Nein	Ja
WSDL-HTML-Bericht	Ja	Ja
Test Suite-Abdeckung	Nein	Ja
Testfallabdeckung	Nein	Ja
Assertion Coverage	Nein	Ja
Berichterstattung über die Aufzeichnung von Nachrichten	Nein	Ja

SoapUI ist ein plattformübergreifendes Tool. Es unterstützt Windows-, Linux- und Mac-Betriebssysteme.

Voraussetzungen

• Processor - 32-Bit- oder 64-Bit-Prozessor mit 1 GHz oder höher.

• RAM - 512 MB RAM.

• Hard Disk Space - Mindestens 200 MB Festplattenspeicher für die Installation.

• Operating System Version - Windows XP oder höher, MAC OS 10.4 oder höher.

• JAVA - JAVA 6 oder höher.

Download-Prozess

Step 1- Gehen Sie zu www.soapui.org und klicken Sie auf SoapUI herunterladen.

Step 2- Klicken Sie auf "Get It", um SoapUI Open Source herunterzuladen. Der Download der 112 MB EXE-Datei im System wird gestartet. Warten Sie, bis der Downloadvorgang abgeschlossen ist.

Installationsprozess

Step 1 - Führen Sie nach dem Herunterladen die EXE-Datei als "Als Administrator ausführen" aus.

Windows startet den Einrichtungsvorgang wie im folgenden Screenshot gezeigt.

Step 2 - Nach dem Einrichten wird im Prozessfenster der folgende Bildschirm angezeigt. Klicken Sie auf Weiter.

Step 3 - Akzeptieren Sie die Lizenzvereinbarung und klicken Sie auf Weiter.

Step 4- Wählen Sie das Installationsverzeichnis oder behalten Sie es als vom System ausgewählten Standardpfad bei. Weiter klicken.

Step 5- Wählen Sie die Komponenten aus, die Sie installieren möchten. Weiter klicken.

Step 6 - Akzeptieren Sie die Lizenzvereinbarung für HermesJMS und klicken Sie auf Weiter.

Step 7 - Wählen Sie das Zielverzeichnis zum Speichern der Tutorials aus und klicken Sie auf Weiter.

Step 8 - Wählen Sie den Speicherort des Startmenüordners oder lassen Sie den Standardspeicherort unverändert und klicken Sie auf "Weiter".

Step 9 - Aktivieren Sie das Kontrollkästchen "Desktop-Symbol erstellen" und klicken Sie auf "Weiter".

Nun beginnt die Installation. Der Vorgang dauert einige Minuten.

Step 10 - Klicken Sie nach Abschluss der Installation im folgenden Assistenten auf Fertig stellen.

Wenn Sie auf Fertig stellen klicken, wird SoapUI gestartet.

• Menüleiste
• Symbolleiste
• Projektnavigationsleiste
• Arbeitsbereichseigenschaften
• Protokollfenster

Konfigurationsprozess

Der erste Schritt besteht darin, einen Arbeitsbereich zu erstellen, der mehrere Projekte enthalten kann.

Step 1 - Gehen Sie zu Datei → Neuer Arbeitsbereich.

Step 2 - Fügen Sie den Namen des Arbeitsbereichs hinzu und klicken Sie auf OK.

Step 3 - Wählen Sie nun den Pfad aus, in dem die Arbeitsbereich-XML gespeichert wird.

Step 4 - Wählen Sie den Pfad aus und klicken Sie auf Speichern.

Der Arbeitsbereich wird wie im folgenden Screenshot gezeigt erstellt. Arbeitsbereichseigenschaften werden ebenfalls ausgestellt.

WSDL steht für Web Services Description Language. Es ist ein Standardformat zur Beschreibung eines Webdienstes. WSDL wurde gemeinsam von Microsoft und IBM entwickelt. WSDL wird als "wiz-langweilig" ausgesprochen und als "WSD-L" geschrieben.

WSDL ─ Eine kurze Geschichte

WSDL 1.1 wurde von Ariba, IBM und Microsoft als W3C-Hinweis zur Beschreibung der Dienste für die W3C-XML-Aktivität für XML-Protokolle im März 2001 eingereicht.

WSDL 1.1 wurde vom World Wide Web Consortium (W3C) nicht gebilligt, hat jedoch gerade einen Entwurf für Version 2.0 veröffentlicht, der eine Empfehlung (ein offizieller Standard) darstellt und daher vom W3C gebilligt wird.

WSDL ─ Zu beachtende Punkte

WSDL ist ein XML-basiertes Protokoll für den Informationsaustausch in einer dezentralen und verteilten Umgebung. Einige der anderen Funktionen von WSDL sind wie folgt:

• WSDL-Definitionen beschreiben, wie auf einen Webdienst zugegriffen wird und welche Vorgänge ausgeführt werden.

• In dieser Sprache wird beschrieben, wie eine Schnittstelle zu XML-basierten Diensten hergestellt wird.

• Es ist ein wesentlicher Bestandteil von Universal Description, Discovery and Integration (UDDI), einer XML-basierten weltweiten Unternehmensregistrierung.

• WSDL ist die Sprache, die UDDI verwendet.

WSDL-Verwendung

WSDL wird häufig in Kombination mit SOAP und XML Schema verwendet, um Webdienste über das Internet bereitzustellen. Ein Client-Programm, das eine Verbindung zu einem Webdienst herstellt, kann die WSDL lesen, um festzustellen, welche Funktionen auf dem Server verfügbar sind. Alle verwendeten speziellen Datentypen werden in Form eines XML-Schemas in die WSDL-Datei eingebettet. Der Client kann dann SOAP verwenden, um tatsächlich eine der in der WSDL aufgelisteten Funktionen aufzurufen.

Grundlegendes zu WSDL

WSDL unterteilt die Webdienste in drei spezifische, identifizierbare Elemente, die nach ihrer Definition kombiniert oder wiederverwendet werden können.

Die drei Hauptelemente von WSDL, die separat definiert werden können, sind:

• Types
• Operations
• Binding

Ein WSDL-Dokument enthält verschiedene Elemente, die jedoch in diesen drei Hauptelementen enthalten sind. Diese können als separate Dokumente entwickelt und dann kombiniert oder wiederverwendet werden, um vollständige WSDL-Dateien zu bilden.

In diesem Tutorial folgen wir der WSDL von CurrencyConverter: http://www.webservicex.net

Format und Elemente

Die WSDL von CurrencyConverter sieht folgendermaßen aus:

WSDL ─ Porttyp

Das <portType> -Element kombiniert mehrere Nachrichtenelemente, um einen vollständigen Einweg- oder Roundtrip-Vorgang zu bilden. Beispielsweise kann ein <portType> eine Anforderungs- und eine Antwortnachricht zu einer einzigen Anforderungs- / Antwortoperation kombinieren. Dies wird am häufigsten in SOAP-Diensten verwendet. Ein portType kann mehrere Operationen definieren.

Beispiel

• Das portType-Element definiert eine einzelne Operation namens ConversionRate.
• Die Operation besteht aus einer einzelnen Eingabenachricht ConversionRateHttpPostIn.
• Die Operation für die Ausgabenachricht lautet ConversionRateHttpPostOut.

Betriebsmuster

WSDL unterstützt vier grundlegende Betriebsmuster:

Einweg

Der Dienst erhält eine Nachricht. Die Operation hat daher ein einziges Eingabeelement. Die Grammatik für den Einwegbetrieb lautet -

<wsdl:definitions .... >  
   <wsdl:portType .... > * 
      <wsdl:operation name = "nmtoken"> 
         <wsdl:input name = "nmtoken"? message = "qname"/> 
      </wsdl:operation> 
   </wsdl:portType > 
</wsdl:definitions>

Anfrage ─ Antwort

Der Dienst empfängt eine Nachricht und sendet eine Antwort. Die Operation hat daher ein Eingabeelement, gefolgt von einem Ausgabeelement. Um Fehler zu kapseln, kann auch ein optionales Fehlerelement angegeben werden. Die Grammatik für eine Anfrage-Antwort-Operation lautet -

<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>

Bitte ─ Antwort

Der Dienst sendet eine Nachricht und empfängt eine Antwort. Die Operation hat daher ein Ausgabeelement, gefolgt von einem Eingabeelement. Um Fehler zu kapseln, kann auch ein optionales Fehlerelement angegeben werden. Die Grammatik für eine Solicit-Response-Operation lautet -

<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>

Benachrichtigungen

Der Dienst sendet eine Nachricht. Die Operation hat daher ein einzelnes Ausgabeelement. Es folgt die Grammatik für eine Benachrichtigungsoperation -

<wsdl:definitions .... > 
   <wsdl:portType .... > * 
      <wsdl:operation name = "nmtoken"> 
         <wsdl:output name = "nmtoken"? message = "qname"/> 
      </wsdl:operation> 
   </wsdl:portType > 
</wsdl:definitions>

WSDL ─ Bindung & Service

Das <binding>element bietet spezifische Details darüber, wie eine portType- Operation tatsächlich über die Leitung übertragen wird.

• Die Bindungen können über mehrere Transporte einschließlich HTTP GET, HTTP POST oder SOAP verfügbar gemacht werden.

• Die Bindungen enthalten konkrete Informationen darüber, welches Protokoll zum Übertragen von portType-Vorgängen verwendet wird.

• Die Bindungen geben Auskunft darüber, wo sich der Dienst befindet.

• Für das SOAP-Protokoll lautet die Bindung <soap: binding>, und der Transport besteht aus SOAP-Nachrichten über dem HTTP-Protokoll.

• Sie können mehrere Bindungen für einen einzelnen Porttyp angeben.

Bedienung

Das <service>Element definiert die vom Webdienst unterstützten Ports. Für jedes der unterstützten Protokolle gibt es ein Portelement. Das Serviceelement ist eine Sammlung von Ports.

Webdienst-Clients können Folgendes aus dem Dienstelement lernen:

• Wo kann man auf den Dienst zugreifen?
• Über welchen Port soll auf den Webdienst zugegriffen werden, und
• Wie die Kommunikationsnachrichten definiert sind.

Das Serviceelement enthält ein Dokumentationselement zur Bereitstellung einer für Menschen lesbaren Dokumentation.

<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>

Das SoapUI-Projekt ist der zentrale Punkt bei allen SoapUI-Tests. Sobald das Projekt erstellt wurde, kann der Benutzer Funktionstests erstellen und ausführen, Tests laden, Mock-Services erstellen und vieles mehr.

In diesem Kapitel werden wir zwei Dinge diskutieren - wie man -

• Erstellen Sie ein SOAP-Projekt
• Fügen Sie eine WSDL hinzu

Erstellen Sie ein SOAP-Projekt

Step 1 - Klicken Sie im Navigator auf der linken Seite des Bildschirms mit der rechten Maustaste auf "Projekt" und wählen Sie "Neues SOAP-Projekt".

Oder gehen Sie zu Datei und wählen Sie Neues Seifenprojekt.

Bei Auswahl öffnet sich ein neues Popup-Fenster - Neues Seifenprojekt.

Step 2 - - Project Name: Geben Sie einen Projektnamen ein - dies ist das Benutzereingabefeld. Initial WSDL: Es ist nicht zwingend erforderlich. Das hängt vom Benutzer ab. Der Benutzer kann WSDL bereitstellen oder nach der Erstellung des Projekts hinzufügen.

In diesem Fall erstellen wir ein Projekt und fügen die WSDL später hinzu.

Step 3- Klicken Sie auf OK. Es wird ein neues Projekt erstellt und im linken Navigationsbereich angezeigt.

Fügen Sie eine WSDL hinzu

SOAP-Projekte basieren auf WSDL. Es ist nicht erforderlich, zunächst eine WSDL zu importieren, dies erleichtert jedoch das Testen, da die WSDL alle Informationen enthält, die zum Testen eines Webservices erforderlich sind, z. B. Informationen zu den Anforderungen und Antworten, deren Inhalt und vieles mehr, was das Testen von SoapUI vereinfacht.

Step 1 - Um eine WSDL hinzuzufügen, klicken Sie mit der rechten Maustaste auf den Projektnamen (SOAP - Beispiel) und wählen Sie WSDL hinzufügen.

Bei der Auswahl wird der WSDL-Assistent angezeigt.

Step 2 - - WSDL Location: Geben Sie eine WSDL als ein http://www.webservicex.com oder durchsuchen Sie es vom Computer aus.

Step 3- Sobald WSDL eingegeben wurde, werden 3 Kontrollkästchen aktiviert - Anforderungen erstellen, TestSuite erstellen, MockServices erstellen. Je nach Anforderung kann der Benutzer ein oder mehrere Kontrollkästchen aktivieren.

Standardmäßig ist das Kontrollkästchen Anforderungen erstellen aktiviert.

Step 4- Klicken Sie auf OK. WSDL wurde erfolgreich im Projekt hinzugefügt. Dies kann durch Beobachtung des linken Navigationsbereichs überprüft werden. Innerhalb des Projekts gibt es mehrere Vorgänge, und Anforderungen werden gemäß WSDL hinzugefügt.

Detailansicht

Um weitere Details zum Projekt zu erhalten, doppelklicken Sie auf den Projektnamen. Daraufhin wird ein neues Fenster mit verschiedenen Details geöffnet.

Auf der Registerkarte Übersicht werden verschiedene Informationen bereitgestellt, z.

• File Path - Es zeigt den Speicherort der gespeicherten Projekt-XML an.

• Interface Summary - Schnittstellenname und damit verbundene WSDL.

• Test Summary - Es werden Testsuiten, Testfälle, Testschritte und dem Projekt hinzugefügte Zusicherungen angezeigt.

Der Benutzer kann auf den Schnittstellennamen doppelklicken, um die Schnittstellendetails abzurufen. Es wird ein neues Fenster geöffnet und die WSDL-bezogenen Informationen angezeigt. Diese sind sehr nützlich zum Durchsuchen und Untersuchen einer WSDL.

Auf der Registerkarte Übersicht werden WSDL-Definitionen, Definitionsteile und Operationsdetails aufgelistet.

In ähnlicher Weise listet Service-Endpunkte die Details der Endpunkte auf.

Auf der Registerkarte WSDL-Inhalt werden alle Details der WSDL im XML- / Schema-Format bereitgestellt, wie im folgenden Screenshot gezeigt.

TestSuiteist eine Sammlung von Testfällen, mit denen Funktionstests in logische Einheiten gruppiert werden können. Innerhalb eines SoapUI-Projekts können beliebig viele TestSuites erstellt werden, um umfangreiche Testszenarien zu unterstützen.

Erstellung von TestSuite

Step 1 - Klicken Sie innerhalb eines Projekts mit der rechten Maustaste auf die Benutzeroberfläche (neben dem Projektnamen) und klicken Sie dann auf "TestSuite generieren".

Hier ist SOAP - Beispiel ein Projektname, während CurrencyConvertorSoap und CurrencyConvertorSoap12 Schnittstellen sind.

Step 2- Ein neuer Assistent wird geöffnet. Wählen Sie die Auswahl basierend auf der Anforderung.

Step 3 - Klicken Sie nach Auswahl auf OK.

Step 4- Aktivieren Sie das Kontrollkästchen LoadTest generieren. Dadurch wird für jeden in dieser TestSuite erstellten TestCase ein LoadTest generiert.

Step 5 - Geben Sie den Namen der TestSuite in den neuen Assistenten ein und klicken Sie auf OK.

Die erstellte TestSuite wird im Navigationsbereich angezeigt (siehe folgenden Screenshot).

Step 6- Doppelklicken Sie auf den TestSuite-Namen. Das TestSuite-Fenster wird im rechten Bereich geöffnet. Da dort keine Testfälle hinzugefügt werden, ist es leer.

Die TestSuite-Eigenschaften werden unten im Navigationsbereich angezeigt. Neue benutzerdefinierte Eigenschaften können auf TestSuite-Ebene hinzugefügt werden.

Ein TestCase ist eine Sammlung von TestSteps, die zusammengestellt wurden, um bestimmte Aspekte von Webdiensten zu testen. Der Benutzer kann einer TestSuite n TestCuites hinzufügen und diese sogar modularisieren, um sich für komplexe Testszenarien gegenseitig aufzurufen.

Erstellung von TestCase

Step 1- Innerhalb einer TestSuite kann der Benutzer mehrere Testfälle hinzufügen. Klicken Sie mit der rechten Maustaste auf die Testsuite und wählen Sie "Neuer Testfall".

Step 2 - Geben Sie den Namen des Testfalls ein und klicken Sie auf OK.

Der erstellte TestCase hat ab sofort keine Testschritte mehr. TestCase wird mit null TestSteps für alle verfügbaren Testarten hinzugefügt. Sobald die TestSteps hinzugefügt wurden, ändern sich die Zahlen in der Klammer automatisch. Der funktionale TestStep sollte in 'Testschritte' gehen, während ein LeistungstestStep in 'Lasttest' und ein SicherheitstestStep in 'Sicherheitstests' gehen sollte.

Step 3- Doppelklicken Sie auf den TestCase-Namen. Auf der rechten Seite wird ein TestCase-Fenster geöffnet. Da keine TestSteps hinzugefügt wurden, ist sie leer, wie im folgenden Screenshot gezeigt.

TestSteps sind die "Bausteine" von Funktionstests in SoapUI. Diese werden einem TestCase hinzugefügt und zur Steuerung des Ausführungsflusses und zur Überprüfung der Funktionalität der zu testenden Webdienste verwendet.

Einfügen von TestStep

Step 1- Klicken Sie mit der rechten Maustaste auf TestSteps. Fügen Sie Step hinzu und wählen Sie einen geeigneten TestStep aus der Liste aus. Wenn der Benutzer beispielsweise einen REST-WebService testen muss, wählt er die REST-Testanforderung aus.

Step 2 - Fügen Sie einen TestStep hinzu, um die importierte SOAP-Anforderung zu validieren, indem Sie TestSteps → Schritt hinzufügen → SOAP-Anforderung auswählen.

Step 3 - Geben Sie den Namen des TestStep ein und klicken Sie im Assistenten auf OK.

Wenn Sie auf "OK" klicken, wird ein Dialogfeld angezeigt, in dem Sie den aufzurufenden Vorgang auswählen können. Alle Vorgänge werden aufgelistet, und die Benutzer können den Vorgang auswählen, den sie aufrufen möchten.

Es gibt zwei Operationen, die aufgelistet werden. Beide Operationen sind bis auf die verwendete SOAP-Version identisch.CurrencyConvertorSoap verwendet SOAP Version 1.1, während CurrencyConvertorSoap12 verwendet SOAP Version 1.2.

Step 4 - Wählen Sie die erste aus - CurrencyConvertorSoap und klicken Sie auf OK.

Beim Hinzufügen eines Testfalls können verschiedene Standardzusicherungen hinzugefügt werden. Zusicherungen werden auch als Prüfpunkte / Validierungspunkte der SOAP-Anforderung / Antwort bezeichnet.

Step 5 - Lassen Sie uns einen TestCase mit einer Standardoption erstellen, dh einen TestStep OHNE einen der folgenden Validierungspunkte erstellen. -

• Überprüft beim Ausführen des Tests, ob die Antwortnachricht SOAP ist.
• Überprüft, ob das Antwortschema gültig ist.
• Überprüft, ob die SOAP-Antwort FAULT enthält.

Step 6 - Wenn Sie auf OK klicken, wird der folgende XML-Screenshot der Anforderung angezeigt.

Die Anzahl der Testschritte wird jetzt als funktionaler Testschritt auf eins erhöht. In ähnlicher Weise erhöht sich beim Hinzufügen von Last- und Sicherheitstestschritten die entsprechende Anzahl automatisch basierend auf der Anzahl der hinzugefügten Schritte.

Setup anfordern

Hier führen wir die Umrechnung der Währung von INR in USD durch.

• FromCurrency - INR
• ToCurrency - USD

Geben Sie als Nächstes diese Eingaben anstelle des Fragezeichens ein, das als Anforderungs-XML gesendet wird. Nachdem Sie diese Werte in die entsprechenden XML-Tags eingefügt haben, klicken Sie auf die Schaltfläche "Anfrage senden", um die Antwort zu überprüfen.

Antwort

Beim Senden einer Anfrage wird die Webdienstanforderung vom Webserver verarbeitet und sendet eine Antwort zurück, wie im folgenden Screenshot gezeigt.

Durch Lesen der Antwort kann geschlossen werden, dass 1 Einheit INR = 0,0147 Einheiten USD.

HTTP-Anfrage

SOAP-Nachrichten werden per HTTP-Protokoll transportiert. Klicken Sie zum Anzeigen der HTTP-Anforderung im SoapUI-Anforderungsfenster (linke Seite) auf RAW.

Die Anfrage wird an den Webserver gesendet. Daher wird die POST-Methode von Http verwendet.

Die SOAP-Anforderung wird im Hauptteil der http-Nachricht transportiert, die wie folgt angezeigt wird.

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-Antwort

Klicken Sie im SOAP-UI-Antwortfenster auf die Registerkarte 'RAW', um zu verstehen, wie die Antwort über HTTP gesendet wird.

Nach der Verarbeitung der Anforderung wird der http-Antwortcode (200) angezeigt, was bedeutet, dass er erfolgreich ist. Der Webserver hat es erfolgreich verarbeitet.

Die SOAP-Antwort wird als Teil des Hauptteils der HTTP-Nachricht an den Client zurückgesendet.

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

Die folgenden HTTP-Codes werden zum Senden von Antworten vom Webserver verwendet und sind sehr nützlich für das Debuggen.

HTTP-Code	Beschreibung
1xx:	Informational - Dies bedeutet, dass eine Anfrage eingegangen ist und ein fortlaufender Prozess stattfindet.
2xx:	Success - Die Aktion wurde erfolgreich empfangen, verstanden und akzeptiert.
3xx:	Redirection - Dies bedeutet, dass weitere Maßnahmen ergriffen werden müssen, um die Anforderung abzuschließen.
4xx:	Client Error - Dies bedeutet, dass die Anforderung eine schlechte Syntax enthält oder nicht erfüllt werden kann.
5xx:	Server Error - Der Server konnte eine scheinbar gültige Anfrage nicht erfüllen.

Eigenschaften sind ein zentraler Aspekt fortgeschrittener Tests mit SoapUI. Funktionstest-Eigenschaften werden verwendet, um die Ausführung und Funktionalität von Tests zu parametrisieren.

• Mithilfe von Eigenschaften können die Endpunkte von Diensten gespeichert werden, sodass die während der Testausführung tatsächlich verwendeten Endpunkte leicht geändert werden können.

• Mithilfe von Eigenschaften können Authentifizierungsdaten gespeichert werden, sodass diese einfach an einem zentralen Ort oder in einer externen Datei verwaltet werden können.

• Mithilfe von Eigenschaften können Sitzungs-IDs während der Testausführung übertragen und freigegeben werden, sodass mehrere Testschritte oder Testfälle dieselben Sitzungen gemeinsam nutzen können.

Eigenschaften definieren

Eigenschaften können in einem Projekt auf vielen Ebenen definiert werden.

• Auf Projektebene übliche Eigenschaften können auf Projektebene definiert werden.

• Ebenso können TestSuite- und TestCase-spezifische Eigenschaften auf ihren jeweiligen Ebenen definiert werden.

• Projektspezifische Eigenschaften werden auf der Registerkarte Benutzerdefinierte Eigenschaften definiert.

Beispielsweise kann eine Eigenschaft "ToCurrency" auf Projektebene definiert werden, indem Sie auf das Symbol "+" klicken und den Namen und den Wert der Eigenschaft eingeben.

Zugriff auf Eigentum

Auf eine Eigenschaft kann mithilfe der Eigenschaftserweiterung an einer beliebigen Stelle im Projekt zugegriffen werden.

Struktur wäre wie -

• $ {# Project # PropertyName} - Für Projektebene

• $ {# TestSuite # PropertyName} - Für die Test Suite-Ebene

• $ {# TestCase # PropertyName} - Für Testfallstufe

• $ {TestStepName # PropertyName} - Für die Testschrittstufe

• $ {# MockService # PropertyName} - Für die MockService-Eigenschaft

• $ {# Global # PropertyName} - Informationen zu globalen Eigenschaften finden Sie unter Datei → Einstellungen → Registerkarte Globale Eigenschaften. Diese Eigenschaft kann für alle Projekte verwendet werden

• $ {# System # PropertyName} - Informationen zur Systemeigenschaft finden Sie unter Hilfe → Systemeigenschaften

• $ {# Env # PropertyName} - Für Umgebungsvariable

Dieselbe Struktur kann bei Request XML platziert werden, um den Wert eines bestimmten Attributs zur Laufzeit abzurufen.

Eine Eigenschaft kann auch als Variable in einem Computerprogramm betrachtet werden. Wenn der Benutzer etwas definieren möchte, das auch woanders verwendet werden kann, sind Eigenschaften sehr nützlich. Eigenschaften können auch dynamisch definiert werden, hängen jedoch vom Groovy-Skript ab.

Manchmal ist es erforderlich, einen Wert aus einer Antwortnachricht zu extrahieren und ihn in die nachfolgenden Anforderungen aufzunehmen. In einem solchen Fall benötigen wir einen Mechanismus, um einen bestimmten Wert abzurufen und auf die anderen Elemente des Projekts zu übertragen. SoapUI unterstützt solche Funktionen über den Property Transfer TestStep.

Eigentumsübertragung hinzufügen

Step 1 - Wählen Sie TestCase oder TestStep aus und klicken Sie mit der rechten Maustaste → Schritte hinzufügen → Eigenschaftsübertragung.

Step 2 - Geben Sie den TestStep-Namen ein und klicken Sie auf OK.

Step 3 - Der RateTransfer-Schritt wird hinzugefügt und ein neuer Assistent wird geöffnet.

Step 4- Klicken Sie oben links im Fenster für die Eigentumsübertragung auf das Symbol Neue Eigentumsübertragung hinzufügen +. Sie werden aufgefordert, einen Namen für die Übertragung einzugeben. Geben Sie Rate ein und klicken Sie auf OK.

Übertragung einer Immobilie

Sobald die Übertragung erstellt wurde, Source und Target panesSie müssen die relevanten XPath-Ausdrücke angeben, um die Eigenschaftswerte zu extrahieren und zu ersetzen. Im Dropdown-Feld neben Quelle werden verschiedene Ebenen von SoapUI-Projekten aufgelistet, die als Quelle für Eigentumsübertragungen verwendet werden können. Standardmäßig wird der nächstgelegene TestStep angezeigt.

In diesem Fall ist es das Request – INR to USDTestStep. In der Dropdown-Liste neben Eigenschaft wird die Quelleigenschaft angezeigt, die bei der Übertragung verwendet wird. Dies kann entweder ein Anforderungs-, Antwort- oder Dienstendpunkt sein.

Step 1- Wählen Sie Antwort und gehen Sie zur Pfadsprache. Der Benutzer kann XPath, Xquery oder Jason auswählen, um die Eigenschaft zu definieren. Wählen Sie in diesem Fall XPath.

Step 2 - Um die Deklaration der Quell-XML zu erhalten, klicken Sie auf ns und geben Sie XPath an.

Step 3- Geben Sie das Ziel an, an das der aus dem obigen XPath-Ausdruck extrahierte Wert übertragen werden soll. Das Zielfenster wird dafür am unteren Rand des Eigenschaftsübertragungsfensters verwendet.

Step 4 - Übertragen Sie den extrahierten Wert von ConversionRateResult aus der Antwort des RequestINRtoUSD-Schritts.

Target - Eigenschaften

Property - ConversionRate (eine neue Eigenschaft wurde hinzugefügt, die anfangs keinen Wert hat).

Step 5 - Sobald der Testfall erfolgreich ausgeführt wurde, wird die Eigenschaft "ConversionRate" basierend auf der Antwort aktualisiert.

Es folgt zunächst der Screenshot.

Es folgt der Screenshot nach einem erfolgreichen Lauf.

In ähnlicher Weise kann Target eine nächste Anforderungs-XML sein. Wenn Ziel eine SOAP-Anforderung ist, müssen wir XPath bereitstellen, um das Zielattribut zu identifizieren.

Im Protokollbereich werden die vollständigen Informationen zur Transaktion zwischen dem Client und dem Server gespeichert. Benutzer können die verschiedenen Registerkarten des Protokollbereichs anzeigen. In diesem Kapitel werden die am häufigsten verwendeten Protokollfenster bei der Arbeit mit SoapUI erläutert.

SoapUI-Protokoll

Das SoapUI-Protokoll zeigt die Antwortinformationen vom Webserver an. Die gleichen Informationen werden in der Datei soapui.log des installierten SOAP-UI-Ordners im Verzeichnis 'bin' gespeichert.

HTTP-Protokoll

Das HTTP-Protokoll zeigt die gesamte HTTP-Paketübertragung an. Alle Informationen in 'RAW' werden im HTTP-Protokoll angezeigt.

Fehlerprotokoll

Das Fehlerprotokoll zeigt alle Fehler an, die während der gesamten Projektsitzung aufgetreten sind. Die gleichen Informationen finden Sie in 'soapui-Errors.log' im Verzeichnis 'bin' des installierten SoapUI-Speicherorts.

Speicherprotokoll

Diese Registerkarte überwacht den Speicherverbrauch und zeigt ihn in Form eines Diagramms an, wie im folgenden Screenshot gezeigt. Es ist sehr hilfreich, wenn eine speicherintensive Operation ausgeführt wird.

Die Behauptung kann als Prüfpunkt oder Validierungspunkt interpretiert werden. Sobald eine Anfrage an einen Webserver gesendet wurde, wird eine Antwort empfangen. Es ist erforderlich, die Antwort, die die Daten enthält, wie erwartet oder nicht zu validieren. Um die Antwort zu validieren, verfügt SoapUI über eine Assertionsfunktion.

Zu beachtende Punkte

• Assertions werden verwendet, um die von einem TestStep während der Ausführung empfangene Nachricht zu validieren.

• Es vergleicht den Teil der Nachricht oder die gesamte Nachricht mit einem erwarteten Wert.

• Zu einem TestStep können beliebig viele Zusicherungen hinzugefügt werden, die jeweils einen anderen Aspekt und Inhalt der Antwortnachricht validieren.

• Nachdem ein TestStep ausgeführt wurde, werden alle seine Zusicherungen auf die empfangene Antwort angewendet. Wenn eine davon fehlschlägt, wird der TestStep in der TestCase-Ansicht als fehlgeschlagen markiert.

• Der fehlgeschlagene Eintrag wird im Testausführungsprotokoll angezeigt.

Art der Behauptungen

SoapUI unterstützt eine Vielzahl von Behauptungen als Antwort.

Im Folgenden finden Sie eine Liste der von SoapUI unterstützten Zusicherungen.

Behauptung	Beschreibung
Property Content
Enthält	Überprüft, ob die angegebene Zeichenfolge vorhanden ist. Es unterstützt auch reguläre Ausdrücke.
Enthält nicht	Überprüft, ob die angegebene Zeichenfolge nicht vorhanden ist. Es unterstützt auch reguläre Ausdrücke.
XPath Match	Verwendet den XPath-Ausdruck, um den Zielknoten und seine Werte auszuwählen. Vergleicht das Ergebnis eines XPath-Ausdrucks mit einem erwarteten Wert.
XQuery Match	Verwendet einen Xquery-Ausdruck, um den Inhalt aus der Zieleigenschaft auszuwählen. Vergleicht das Ergebnis eines XQuery-Ausdrucks mit einem erwarteten Wert.
Compliance, Status, Standards
HTTP Laden Sie alle Ressourcen herunter	Lädt alle Ressourcen herunter, die als HTML-Dokument bezeichnet werden (Bilder, Skripte usw.), und überprüft, ob sie alle verfügbar sind. Anwendbar auf alle Eigenschaften, die HTML enthalten.
Ungültige HTTP-Statuscodes	Überprüft, ob der Ziel-TestStep ein HTTP-Ergebnis mit einem Statuscode empfangen hat, der nicht in der Liste der definierten Codes enthalten ist. Anwendbar auf jeden TestStep, der HTTP-Nachrichten empfängt.
Kein SOAP-Fehler	Überprüft, ob die zuletzt empfangene Nachricht kein SOAP-Fehler ist. Anwendbar auf SOAP TestSteps.
Schema-Konformität	Überprüft, ob die zuletzt empfangene Nachricht mit der zugehörigen WSDL- oder WADL-Schemadefinition kompatibel ist. Anwendbar auf SOAP- und REST-Testschritte. Die Schema-Definitions-URL unterstützt Eigenschaftserweiterungen (z. B. $ {# System # my.wsdl.endpoint} / services / PortType? Wsdl).
SOAP-Fehler	Überprüft, ob die zuletzt empfangene Nachricht ein SOAP-Fehler ist. Anwendbar auf SOAP TestSteps SOAP-Anforderung - Überprüft, ob die zuletzt empfangene Anforderung eine gültige SOAP-Anforderung ist. Gilt nur für MockResponse-Testschritte.
SOAP-Antwort	Überprüft, ob die zuletzt empfangene Antwort eine gültige SOAP-Antwort ist. Gilt nur für SOAP TestRequest-Schritte.
Gültige HTTP-Statuscodes	Überprüft, ob der Ziel-TestStep ein HTTP-Ergebnis mit einem Statuscode in der Liste der definierten Codes erhalten hat. Anwendbar auf jeden TestStep, der HTTP-Nachrichten empfängt.
WS-Adressierungsanfrage	Überprüft, ob die zuletzt empfangene Anforderung gültige WS-Adressierungsheader enthält. Gilt nur für MockResponse TestSteps.
WS-Adressierungsantwort	Überprüft, ob die zuletzt empfangene Antwort gültige WS-Adressierungsheader enthält. Gilt nur für SOAP TestRequest-Schritte.
WS-Sicherheitsstatus	Überprüft, ob die zuletzt empfangene Nachricht gültige WS-Security-Header enthält. Anwendbar auf SOAP-Testschritte.
Script
Skript-Behauptung	Ermöglicht den Benutzern die Ausführung eines benutzerdefinierten Skripts zur Durchführung benutzerdefinierter Überprüfungen. Gilt nur für TestSteps (dh nicht für Eigenschaften)
SLA
Antwort SLA	Überprüft, ob die Antwortzeit der zuletzt empfangenen Antwort innerhalb des definierten Grenzwerts lag. Anwendbar auf Skript-TestSteps und TestSteps, die Anforderungen senden und Antworten empfangen.
JMS
JMS-Status	Überprüft, ob die JMS-Anforderung des Ziel-TestStep erfolgreich ausgeführt wurde. Anwendbar zum Anfordern von TestSteps mit einem JMS-Endpunkt.
JMS-Zeitüberschreitung	Überprüft, ob die JMS-Anweisung des Ziel-TestStep nicht länger als die angegebene Dauer gedauert hat. Anwendbar zum Anfordern von TestSteps mit einem JMS-Endpunkt.
Security
Exposition gegenüber sensiblen Informationen	Überprüft, ob die Antwortnachricht keine vertraulichen Informationen zum Zielsystem enthält. Wir können diese Behauptung für REST-, SOAP- und HTTP-TestSteps verwenden.
JDBC
JDBC-Status	Überprüft, ob die JDBC-Anforderung des Ziel-TestStep erfolgreich ausgeführt wurde. Gilt nur für JDBC TestSteps.
JDBC-Zeitüberschreitung	Überprüft, ob die JDBC-Anweisung des Ziel-TestStep nicht länger als die angegebene Dauer gedauert hat. Gilt nur für JDBC TestSteps.

In SoapUI sind die Benutzer mit vielen allgemeinen Problemen konfrontiert, die mit ein wenig Wachsamkeit behoben werden können. Einige dieser häufigsten Probleme sind die folgenden:

Issue- Der Namespace ist falsch definiert. Verwenden Sie den richtigen Namespace. Der Namespace sollte die URL sein, unter der sich der Webdienst befindet.

Solution - Wenn beim Entwickeln einer Scripting-Zusicherung ein Fehler ausgegeben wird, drucken Sie den Inhalt der Variablen mit 'log.info'.

Issue - Wenn ein Fehlercode als Antwort-XML empfangen wird, kann dies an der ungültigen Eingabe liegen.

Solution - Überprüfen Sie die Eingabe von Anforderungs-XML.

Example - Wenn im Währungsumrechner die Eingabe der 'FromCurrency' '123' ist, die nicht vorhanden ist, gibt die Ausgabe einen Fehlercode als 'SOAP-Client' aus, was bedeutet, dass das Problem mit dem Parameter liegt, der von der übergeben wird Client-Seite.

Anfrage

Antwort

Issue - Keine Übereinstimmung in der aktuellen Antwort bei Verwendung von XPath oder XQuery.

Solution - -

• Verwenden Sie beim Definieren von XPath oder XQuery die richtige Syntax.
• Stellen Sie sicher, dass beim Deklarieren des Namespace ein Doppelpunkt und kein Punkt verwendet wird.
• Stellen Sie sicher, dass XPath und XQuery korrekt sind.

Leistungstests sind einer der häufigsten wichtigen Kontrollpunkte beim Testen von Webdiensten. Leistungstests sind definiert als künstliches Erstellen oder Simulieren der Last und Messen, wie die Umgebung damit umgeht.

Dies bedeutet, dass es nicht unbedingt die Leistung eines Systems unter hoher Last sein muss, sondern auch die Leistung unter Grundlast oder erwarteter Last. Es muss nicht einmal in TestWare wie SoapUI strukturiert, automatisiert oder erstellt werden. Es ist auch ein Lasttest, den Webbrowser einfach immer wieder sehr schnell zu aktualisieren.

Arten von Leistungstests

Im Folgenden sind die Arten von Leistungstests aufgeführt:

• Baseline Testing - Untersucht die Leistung eines Systems unter erwarteter oder normaler Last und erstellt eine Basislinie, mit der die anderen Testarten verglichen werden können.

• Load Testing- Beinhaltet das Erhöhen der Last und das Verhalten des Systems bei höherer Last. Während der Auslastungstests kann der Benutzer die Antwortzeiten, den Durchsatz, den Serverzustand und vieles mehr überwachen. Das Ziel von Lasttests besteht nicht darin, die Zielumgebung zu beschädigen.

• Soak Testing - Ziel des Testens ist es sicherzustellen, dass über einen längeren Zeitraum kein unerwünschtes Verhalten auftritt.

• Scalability Testing- Skalierbarkeitstests ähneln stark dem Lasttest, erhöhen jedoch nicht die Anzahl der Anforderungen, sondern die Größe oder Komplexität der gesendeten Anforderungen. Zum Beispiel das Senden großer Anforderungen, großer Anhänge oder tief verschachtelter Anforderungen.

Schlüsselaspekte im Webdienst

Zwei Aspekte zeichnen sich durch die einzigartigen Merkmale der Webdienstleistung aus.

Erster Aspekt

Auf der Serverseite wird XML / JSON verarbeitet, sowohl XML / JSON-Analyse als auch Serialisierung . Was zuerst oft fehlschlägt, ist die Verarbeitung der Nutzdaten. Die Fehlerursachen können vielfältig sein. Dies kann auf der Plattform liegen, auf den Schwachstellen des Anwendungsservers oder auf einem Implementierungsproblem in Form unnötig komplexer WSDLs. Dies kann auch bedeuten, dass der Code eine Anforderung an eine Datenbank sendet, die nur langsam reagiert.

Testing Aspect- Aufgrund der Komplexität des Parsens der XML / JSON-Nutzdaten muss der Schwerpunkt auf Skalierbarkeitstests gelegt werden. Dies bedeutet auch, dass WSDLs genau untersucht werden sollten. Wenn die Anforderungen und Antworten entweder komplex oder größer sind oder große Anhänge enthalten, sollte der Schwerpunkt darauf liegen, die Komplexität zu betonen und zu sehen, wie sie sich unter Last verhält.

Zweiter Aspekt

Ein weiterer häufig anzutreffender Faktor ist die Sicherheit. Sichere Sites hinter HTTPS weisen eine erheblich geringere Leistung auf. Beim Testen von Webdiensten können wir der HTTP-Sicherheitsebene eine Schicht WSSecurity hinzufügen, wodurch die Leistung noch weiter verringert wird.

Testing Aspect- Das Problem der Sicherheit bedeutet, dass der Schwerpunkt auf dem Testen sicherer Anforderungen liegen muss. Wenn der gesamte Webdienst sicher ist, bedeutet dies, dass Lasttests wichtiger sind, insbesondere wenn WS-Sicherheit und Token-Behandlung verwendet werden.

Load testingist eine spezielle Form von Leistungstests, die durchgeführt wird, um das Verhalten des Systems unter einer bestimmten Last zu bewerten. In SoapUI wird der Begriff "Lasttest" im Allgemeinen für alle Arten von nicht funktionalen Tests verwendet. SoapUI unterstützt jedoch alle Arten von Leistungsbewertungen von Webdiensten wie Last, Stress und Ausdauer.

Zu beachtende Punkte

• Lasttests sind in SoapUI einzigartig. Ein Funktionstestfall, mit dem Leistungstests schnell erstellt und geändert werden können.

• Das Hauptunterscheidungsmerkmal ist, dass Leistungstests in SoapUI im Allgemeinen aus den vorhandenen Funktionstests erstellt werden. Auf diese Weise können schnell erweiterte Leistungstests erstellt werden.

• Die Leistung des Webdienstes kann unter verschiedenen Lastszenarien überprüft werden. Behalten Sie Funktionsvalidierungen bei, um sicherzustellen, dass sie unter Last nicht brechen. Führen Sie mehrere Lasttests gleichzeitig durch, um festzustellen, wie sie sich gegenseitig beeinflussen und vieles mehr.

Erstellung eines Belastungstests

Step 1 - Klicken Sie mit der rechten Maustaste auf Funktionstestfall und wählen Sie Neuer Belastungstest.

Step 2 - Geben Sie den Namen des Lasttests ein und klicken Sie im Dialogassistenten auf OK.

Der Lasttest wird geöffnet und der Lasttest wird wie im folgenden Screenshot gezeigt erstellt.

Durchführung des Lasttests

Wenn ein neuer Auslastungstest erstellt wird, ist dieser vorkonfiguriert, um 60 Sekunden lang (oben rechts) mit 5 Threads unter Verwendung der Strategie zum einfachen Laden ausgeführt zu werden.

Ändern Sie diese Werte gemäß Anforderung und Ausführen. Note - Der Benutzer sollte die Konfiguration und Konzepte des Lasttests kennen.

Der Benutzer sieht die Statistiktabelle in der Mitte, beginnend mit dem Sammeln von Daten, und nach 60 Sekunden sollte ein LoadTest abgeschlossen sein.

Hinzufügen einer Behauptung

Step 1 - Wählen Sie im LoadTest-Editor die Registerkarte LoadTest Assertion am unteren Rand des Editors.

Step 2 - Klicken Sie in der Menüleiste von LoadTest Assertion auf die Schaltfläche Assertion hinzufügen, um eine Assertion hinzuzufügen.

Step 3- Das Dialogfeld "Bestätigung hinzufügen" wird geöffnet. Wählen Sie Schrittmaximum. Mit Maximum auswählen wird eine maximale Zeit in Millisekunden festgelegt, die die Antworten benötigen. Wenn die Zeit die von uns festgelegte Zeit überschreitet, schlägt der Test fehl. OK klicken.

Step 4- Das Fenster TestStep Max Assertion wird geöffnet. Wie im folgenden Screenshot zu sehen ist, erlauben wir eine maximale Antwort von einer Sekunde, 1000 Millisekunden. Lassen Sie uns nichts ändern. OK klicken.

Die Step Maximum-Zusicherung wird nun erfolgreich hinzugefügt.

Step 5- Führen Sie nun den Test erneut aus. Wenn die Antworten zu lange dauern, sollten sich die Zahlen in der Spalte err schnell summieren.

Ein Webdienst ist eine Sammlung offener Protokolle und Standards, die für den Datenaustausch zwischen Anwendungen oder Systemen verwendet werden. Softwareanwendungen, die in verschiedenen Programmiersprachen geschrieben sind und auf verschiedenen Plattformen ausgeführt werden, können mithilfe von Webdiensten Daten über Computernetzwerke wie das Internet austauschen, ähnlich wie bei der Kommunikation zwischen Prozessen auf einem einzelnen Computer. Diese Interoperabilität (z. B. zwischen Java und Python oder Windows- und Linux-Anwendungen) ist auf die Verwendung offener Standards zurückzuführen.

Auf REST-Architektur basierende Webdienste werden als RESTful Web Services bezeichnet. Diese Webdienste verwenden HTTP-Methoden, um das Konzept der REST-Architektur zu implementieren. Ein RESTful-Webdienst definiert normalerweise einen URI (Uniform Resource Identifier), einen Dienst, der eine Ressourcendarstellung wie JSON und eine Reihe von HTTP-Methoden bereitstellt.

Alle REST-Testfunktionen von SoapUI basieren auf einer logischen Darstellung, die als REST-Service bezeichnet wird. Wir sollten dies hier nicht mit dem Begriff "Service" verwechseln, da es sich nicht um eine Service-Implementierung handelt, sondern um eine Zuordnung des aufgerufenen RESTful-Service. Wir können so viele REST-Services wie möglich in einem SoapUI-Projekt hinzufügen. Jedes repräsentiert einen bestimmten RESTful-Service. Sie sind wie folgt -

• REST - Projekteinrichtung

• REST - WADL

• REST - Anfrage

• REST - Antwort

• REST - HTTP-Methoden

SoapUI ermöglicht die Verwaltung des Datenbankbetriebs mit einem TestStep namens JDBC Request.

Step 1 - Klicken Sie mit der rechten Maustaste auf TestStep und wählen Sie Schritt hinzufügen → JDBC-Anforderung.

Step 2 - Geben Sie den Schrittnamen ein und klicken Sie auf OK.

JDBC-Schritt wird hinzugefügt. Doppelklicken Sie auf Schritt, und der JDBC-Assistent wird geöffnet.

Um eine JDBC-Verbindung herzustellen, muss der Benutzer einen gültigen Treiber und eine gültige Verbindungszeichenfolge angeben. Diese Parameter werden verwendet, um den Datenbanktyp zu identifizieren und eine Verbindung zur Verwendung der Datenbank herzustellen.

Für MySQL kann der Datenbanktreiber sein com.mysql.jdbc.Driver. In ähnlicher Weise gibt es für andere Datenbanken einen vordefinierten Treiber, der im Dokumentabschnitt der Datenbank gefunden werden kann.

Step 3 - Die Verbindungszeichenfolge sollte das folgende Format haben: -

Jdbc:mysql://[host]:[port]/[database]?[property][=value]

Hier ist Eigenschaft der Benutzername und das Kennwort sowie andere Parameter, die für die Verbindung mit einer Datenbank erforderlich sind.

Zum Beispiel,

jdbc:mysql://localhost:8089/xxx_DB?user=root&password=root

Step 4- Klicken Sie auf Verbindung testen. Bei erfolgreicher Verbindung wird SUCCESS angezeigt, andernfalls werden die Details des Fehlers angezeigt.

JDBC verfügt über einen eigenen Abschnitt mit der Eigenschaft Add, der als Variable in SQL Query verwendet werden kann.

Mal sehen, wie es sich verhält -

Angenommen, die SQL-Abfrage, die im JDBC-Schritt ausgeführt werden muss, lautet Select * from Currency, wobei CurrencyCode = 'xxx'.

In diesem Szenario kann CurrencyCode basierend auf der Anforderungseingabe geändert werden. Wenn der Benutzer einen fest codierten Wert angibt, wird der JDBC-Schritt für die in der Anforderung angegebene Währung nicht ausgeführt.

Um solche Szenarien zu überwinden, unterstützt JDBC die Eigenschaft add, in der ein Eigenschaftscode definiert werden kann, der sich mithilfe des Eigenschaftsübertragungsschritts ständig ändert.

SQL Query wird basierend auf dem aktuellen Wert von Property Code ausgeführt und SQL Query parametrisiert den CurrencyCode =: Code.

Klicken Sie auf Eigenschaft + hinzufügen und den Namen als Code und geben Sie einen Wert an oder lassen Sie das Feld leer, um den Schritt zur Übertragung von Eigenschaften zu verwenden.

JDBC Request kann auch die meisten Zusicherungen mit SOAP Request TestSteps verwenden. In SoapUI sind die meisten dieser Aussagen unabhängig von TestSteps. Daher können die Zusicherungen wie Contains und XPath Match mit JDBC Request TestStep verwendet werden.

Durch Klicken auf die Add an assertion Mit dem Symbol im oberen Menü von JDBC Request TestStep kann der Benutzer herausfinden, welche Zusicherungen von TestStep unterstützt werden.

Zusätzlich zu den generischen Zusicherungen gibt es zwei JDBC Request TestStep-spezifische Zusicherungen -

JDBC Timeout - Mit dieser Zusicherung kann überprüft werden, ob die aktuelle SQL-Abfrage innerhalb des angegebenen Eigenschaftswerts für das Abfragezeitlimit ausgeführt wird.

JDBC Status - Um zu überprüfen, ob die SQL-Anweisung erfolgreich ausgeführt wurde, können wir die JDBC-Statuszusicherung verwenden.

Geben Sie zum Festlegen des Abfragezeitlimits den Wert für das Eigenschaftsabfragezeitlimit auf der linken Seite des Bildschirms an. Bitte beachten Sie, dass der Wert in Millisekunden (ms) akzeptiert wird.