Hur man skapar en testsvit och ett testfall i SoapUI

⚡ Smart sammanfattning

Skapa ett SoapUI Projekt, Testsvit och Testfall möjliggör strukturerad SOAP-webbtjänsttestning. Denna genomgång förklarar grunderna i SOAP-protokollet, WSDL-import, exekvering av förfrågningar, konfiguration av assertioner och analys av svarsloggar för tillförlitlig funktionell testning och regressionstestning.

🧠 TVÅL Foundation: SOAP är ett XML-baserat, plattformsoberoende protokoll som transporteras via HTTP och som utbyter meddelanden mellan olika system.
📁 Projektskapande: Importera WSDL:en till en ny SoapUI SOAP-projekt för att automatiskt generera exempelförfrågningar för varje operation.
🗂️ Installation av testsvit: Högerklicka på projektroten för att lägga till en testsvit som grupperar relaterade testfall för organiserad körning.
🧪 Testfallssteg: Lägg till SOAP-förfrågningssteg, välj målåtgärd och konfigurera standardpåståenden som schemaöverensstämmelse och SOAP-felkontroller.
📊 Svarsinspektion: Använd RAW-fliken och loggrutorna (SoapUI Logg, HTTP-logg, fellogg, minneslogg) för att validera HTTP-statuskoder och felsöka förfrågningar.

Läs mer

Förstå SOAP-protokollet

Innan du skapar en SoapUI Testfall, det hjälper att återgå till grunderna i SOAP-protokollet. En tydlig förståelse för hur SOAP-förfrågningar och svar rör sig mellan system gör det enklare att använda. SoapUI för att testa dem effektivt.

SOAP står för Enkelt objektåtkomstprotokollNedan följer SOAP-protokollets kärnegenskaper:

Det är ett XML-baserat protokoll som används för att kommunicera mellan två olika system.
Det är plattforms- och språkoberoende. Ett system utvecklat med hjälp av Java kan kommunicera med en som är utvecklad i .NET.
SOAP-förfrågningar och svar transporteras via HTTP.

Lär dig SOAP-meddelandeformatet

Ett SOAP-meddelande är ett vanligt XML-dokument som innehåller följande element. Ett meddelande kan antingen vara en begäran eller ett svar.

Med SOAP-grunderna på plats är nästa steg att bygga SoapUI projektstruktur, testsviter och testfall som behövs för att validera en given webbtjänst. Genomgången nedan använder en SoapUI projektexempel för att skapa ett nytt SOAP-projekt.

Skapa ett SOAP-projekt i SoapUI

SOAP-projektet innehåller den importerade WSDL-definitionen tillsammans med alla genererade exempelförfrågningar för varje operation.

Steg 1: Beroende på projekttyp, importera SOAP- eller REST-protokollet. I det här exemplet skapar du ett nytt SOAP-projekt.

Steg 2: Använd följande SOAP-förfrågan URL: http://www.dneonline.com/calculator.asmx?wsdl

Ange projektnamnet.
Ange sökvägen för WSDL-begäran (i det här fallet http://www.dneonline.com/calculator.asmx?wsdl).
Klicka OK.

Obs:

Skapa exempelförfrågan för alla operationer: Genererar en exempelförfrågan för varje operation i WSDL. Aktiveras som standard när WSDL-adressen anges; kan vara avmarkerad om det inte krävs.
Skapa en testsvit för den importerade WSDL:n: Lägger till en SoapUI Testsvit inom projektet för den importerade WSDL:n.
Relativa sökvägar: Sparar alla filer i förhållande till projektfilen för enkel portabilitet.

Steg 3: Efter att SOAP-projektet har skapats med ovanstående WSDL kommer två operationer att importeras till projektet.

Steg 4: Expandera den första begäran, högerklicka Lägg till, Klicka sedan Ny förfrågan.

Klicka sedan på OKSOAP-begäran visas i XML-format.

Ange värden för intA och intB.
Klicka på Skicka knapp.
Svars-XML-filen visas i den högra rutan.

Varför skapa testfall istället för direkta förfrågningar?

Det är möjligt att skicka en begäran för en operation direkt, men den metoden når snabbt sina gränser när flera inmatningskombinationer måste testas. Till exempel kräver en övergång från 5+5 till 4+4 att begäran redigeras varje gång. En testsvit med testfall gör det möjligt att hålla varje scenario återanvändbart utan att ändra den ursprungliga operationen.

Hur man skapar en testsvit i SoapUI

En testsvit är en behållare som grupperar relaterade testfall. Följ stegen nedan för att skapa en.

Steg 1) Högerklicka på projektets rot.

Skapa en testsvit i projektet genom att högerklicka på projektroten.

Steg 2) Ange informationen om testsviten.

Ange testsvitens namn och klicka på OK.

Steg 3) Verifiera den skapade testsviten.

Den nya testsviten visas i navigeringsfönstret som visas nedan.

Steg 4) Öppna testsviten.

Fönstret Testsvit öppnas i den högra rutan. Eftersom inga testfall finns ännu förblir alla åtgärdsalternativ inaktiverade.

Hur man skapar ett testfall i SoapUI

Testfall finns inuti en testsvit och grupperar de enskilda teststeg som utför en webbtjänst.

Steg 1: Skapa flera tester i en testsvit genom att högerklicka på testsviten och välja Nytt testfall.

Steg 2: Ange namnet på Testfall och klicka OK.

Steg 3: Det skapade testfallet har initialt noll steg, som visas nedan.

Obs: Testfallet läggs till med noll teststeg för varje testtyp. Allt eftersom steg läggs till uppdateras siffrorna inom parentes automatiskt.

Funktionsteststeg hör hemma i Teststeg, prestandasteg går in i Lasttest, och säkerhetskontrollerna lever under Säkerhetstest.

Steg 4: Infoga olika typer av teststeg genom att högerklicka Teststeg och välja lämpligt alternativ. För en REST-webbtjänst, välj REST-testförfrågan istället för en SOAP-förfrågan.

Lägga till ett teststeg i SoapUI

Lägg till ett teststeg för att validera den importerade SOAP-begäran i testfallet.

Steg 1: Lägg till ett nytt steg av typen SOAP-förfrågan som visas nedan.

Steg 2: Ange stegnamnet och klicka på OK.

Steg 3: En dialogruta visas där du kan välja vilken åtgärd som ska anropas. Alla tillgängliga åtgärder listas för val.

Många operationer visas här. Operationerna är identiska förutom SOAP-versionen: CalculatorSoap använder SOAP version 1.1, medan CalculatorSoap12 använder SOAP version 1.2.
Versionen spelar ingen roll i det här scenariot, så endera kan väljas.
När du har valt åtgärden klickar du på OK.

Steg 4: När man lägger till ett testfall kan standardpåståenden tillämpas. Påståenden, även kallade kontrollpunkter eller valideringspunkter, behandlas i nästa handledning.

Följande kontrollpunkter kan läggas till när ett testfall skapas. Exemplet nedan skapar ett testfall utan aktiverade valideringspunkter.

Verifierar om svarsmeddelandet är SOAP efter testkörningarna.
Verifierar om svarsschemat är giltigt.
Verifierar om SOAP-svaret innehåller ett FAULT-element.

Steg 5: När testfallet skapas visas begäran-XML:en enligt nedan. Strukturen för XML:en förklaras i ögonblicksbilden.

Steg 6: Teststegsantalet ökas nu till ett eftersom ett steg har lagts till. Om man lägger till belastnings- och säkerhetsteststeg ökas deras respektive räknare automatiskt.

Skicka en förfrågan manuellt och läsa svaret i SoapUI

Steg 1: Exemplet nedan adderar två heltal.

intA — 5
intB — 5

Nästa:

Ange dessa indata istället för frågetecknen i begärans XML.
När du har uppdaterat motsvarande XML-taggar klickar du på Skicka ansökan för att kontrollera svaret.

Steg 2: Efter att begäran har skickats in bearbetas webbtjänsten av webbservern och svaret returneras, som visas nedan.

Svaret bekräftar att 5 plus 5 är lika med 10.

Förstå SOAP-svars- och loggpanelerna

Som tidigare nämnts transporteras SOAP-meddelanden via HTTP. Att granska RAW-meddelandena hjälper till att klargöra hur SOAP-begäran och -svaret överförs över HTTP.

Steg 1: Klicka på RAW fliken i SoapUI förfrågningsfönstret.

Begäran skickas till webbservern, så HTTP POST-metoden används.
SOAP-begäran färdas i HTTP-meddelandets brödtext.

Steg 2: Klicka nu på RAW fliken i SoapUI svarsfönstret för att förstå hur svaret levereras via HTTP.

När begäran har bearbetats visas HTTP-svarskoden (200), vilket indikerar att den har bearbetats.
SOAP-svaret returneras till klienten inuti HTTP-meddelandets brödtext.

Tabellen nedan sammanfattar vanliga HTTP-svarskoder för snabb felsökning.

HTTP Code	BESKRIVNING
1xx	Informations: Begäran mottagen, handläggningen fortsätter.
2xx	Framgång: Åtgärd mottagen, förstådd och accepterad.
3xx	Omdirigering: Ytterligare åtgärder krävs för att slutföra begäran.
4xx	Klientfel: Begäran innehåller felaktig syntax eller kan inte uppfyllas.
5xx	Serverfel: Servern misslyckades med att uppfylla en till synes giltig begäran.

Steg 3: Fönstret Testfall visar även ytterligare metadata för begäran och svaret.

Indikerar att det INGEN header finns i den begäran som skickas.
Indikerar att det inte finns några bilagor i begäran som skickas till webbservern.
Indikerar 10 rubrikobjekt i svaret, synliga vid klick.
Indikerar att inga bilagor finns i svarsmeddelandet.

Loggrutan

Loggfönstret visar all information som utväxlats mellan klienten och servern. De vanligaste loggflikarna beskrivs nedan.

SoapUI Logga: Visar svarsinformation från webbservern. Samma data lagras i soapui.log-filen inuti SoapUI bin-katalogen.

HTTP-logg: Visar alla HTTP-paketöverföringar. All information som är synlig i RAW-vyn registreras också i HTTP-loggen.

Fellogg: Visar alla fel som uppstått under hela projektsessionen. Samma information lagras i soapui-errors.log inuti SoapUI bin-katalogen.

Minneslogg: Övervakar minnesförbrukningen och visar den som ett diagram. Detta är användbart när du kör minnesintensiva operationer.

Med en testsvit, ett testfall och ett teststeg på plats och ett lyckat svar mottaget, är nästa steg att validera svaret. Påståendetyper behandlas i nästa handledning.

Vanliga frågor

En testsvit är en behållare som grupperar relaterade testfall inom en SoapUI Projekt. Ett testfall är ett enda scenario som innehåller ett eller flera teststeg, såsom SOAP-förfrågningar, REST-förfrågningar eller påståenden.

Ja. SoapUI stöder både SOAP- och REST-testning. När du skapar ett nytt projekt väljer du Nytt SOAP-projekt för WSDL-baserade tjänster eller Nytt REST-projekt för REST API:er. Teststegen inkluderar REST-testförfrågan, JDBC-förfrågan och Groovy Manus.

Öppna testsviten och klicka på den gröna uppspelningsknappen. SoapUI kör alla testfall i den ordning de visas. Du kan också konfigurera parallell eller sekventiell körning under fliken Test Suite Properties.

Ja. Använd Egenskapssteget, Egenskapsöverföringssteget eller ett Datakälla-steg (SoapUI Pro) för att köra flera ingångar genom samma testfall. Detta är användbart för datadriven testning över många ingångskombinationer.

AI-assistenter kan läsa en WSDL- eller OpenAPI-specifikation och föreslå realistiska inmatningskombinationer, kantfall och påståendemönster. Dessa förslag kan exporteras som SoapUI XML eller Groovy skript, vilket minskar manuell ansträngning vid byggande av stora testsviter.

Ja. AI-verktyg kan analysera SoapUI Logg- och HTTP-loggposter, klustrar upprepade fel och markerar sannolika grundorsaker som schemaavvikelser eller autentiseringsfel. Detta snabbar upp triage under regressionscykler och stora nattliga körningar.