Påstande i SoapUIScripts, XQuery, XPath-typer

⚡ Smart opsummering

Påstande i SoapUI er de kontrolpunkter, der afgør, om et webtjenestesvar er korrekt, og som forvandler en anmodning, der blot udføres, til en test, der rent faktisk består eller fejler på reelt, verificerbart indhold.

  • 🔘 Kategorier: Ejendomsindhold, overholdelse/status/standarder, script, SLA, JMS og sikkerhed.
  • ☑️ Indeholder: Bekræfter, at der findes en streng i svaret, med understøttelse af regulære udtryk.
  • Indeholder ikke: Bekræfter, at en streng mangler, hvilket er nyttigt til fejltokens og lækkede felter.
  • 🧪 XPath-match: Deklarer navnerummet først, målret derefter én node og sammenlign dens værdi.
  • 🛠️ XQuery-match: Validerer gentagne nodesæt, der ellers ville kræve hundredvis af XPath-kontroller.
  • 📊 script: Groovy Assertions håndterer dynamiske svar og opsætnings- eller nedtagningslogik.
  • 🔍 Fejlfinding: Forkert navnerum og syntaks med punktum i stedet for kolon forårsager de fleste fejl.

Påstande i SoapUI

Hvad er en påstand?

Påstand betyder handling at bekræfte eller sige noget. Det kan også tolkes som et kontrolpunkt eller et valideringspunkt.

Når en anmodning er sendt til en webserver, modtages der et svar. Vi skal validere, om svaret indeholder de data, vi forventer. For at validere svaret skal vi bruge assertions (påstande). Uden en assertion beviser et testtrin kun, at tjenesten svarede, ikke at den svarede korrekt, hvilket er grunden til, at alle API-test skal bære mindst én.

Typer af påstande

Der er forskellige måder at give et svar på; vi vil dog fokusere på de almindeligt anvendte SoapUI påstandstyper under validering af et svar. Nedenfor er de kategorier, der er tilgængelige i Open Source-versionen af SoapUI.

  1. Ejendomsindhold
  2. Overholdelsesstatusstandard
  3. Script
  4. SLA
  5. etc
  6. Sikkerhed

Dialogboksen grupperer alle påstande under disse kategorier, som skærmbilledet nedenfor viser.

Påstandskategorier anført i SoapUI Tilføj påstandsdialog
Typer af påstande i SoapUI

Udover dem, der er anført ovenfor, har Pro-versionen også en indbygget JDBC-påstand, som vi bruger til at bekræfte, om webtjenesten har opdateret databasen korrekt.

Versionsnotat: strøm SoapUI dokumentationen nævner også en JDBC kategori (JDBC-status og JDBC-timeout) sammen med ovenstående kategorier, og en Meddelelsens indhold påstand i egenskabsindhold for mere omfattende XML-sammenligning. Den kommercielle udgave, der her omtales som "Pro", sælges nu som ReadyAPI af SmartBear, så menunavne i nyere builds kan læses anderledes, mens assertion-adfærden forbliver den samme.

Indeholder påstand

Søger efter eksistensen af ​​den angivne streng. Det understøtter også regulært udtryk.

Vi vil fortsætte med det samme eksempel fra den forrige tutorial med WSDL-anmodning som http://www.dneonline.com/calculator.asmxHvis du ikke har bygget det projekt endnu, så arbejd dig igennem oprettelse af et projekt, en testsuite og en testcase først.

Trin 1: Som standard er der ingen påstande.

  1. Antallet af påstande er vist på fanen påstande.
  2. For at tilføje en ny påstand skal du klikke på knappen 'Tilføj ny påstand'.

SoapUI Fanen Påstande viser ingen påstande og knappen Tilføj ny påstand

Trin 2: Nu,

  1. Vælg påstandskategorien.
  2. Vælg påstandstype.
  3. Klik på 'Tilføj'

Tilføj dialogboksen for påstand med den valgte påstandskategori og -type

Trin 3: Lad os validere om strengen '46' findes i svaret. Klik på 'OK'

Bemærk: Vi kan også ignorere store og små bogstaver og tilføje regulære udtryk.

Indeholder dialogboksen for påstandskonfiguration med den indtastede værdi 46

Trin 4: Når den tilføjes, udføres assertionen straks, og det vises, om den er GYLDIG eller UGYLDIG.

Fanen "Påstande" rapporterer "Indeholder"-påstanden som GYLDIG

Trin 5: Lad os nu sige, at vi ændrer indholdet af 'Indeholder påstand i SoapUI' til '47' og se hvad der sker.

Redigering af indholdet af "Indeholder påstand" fra 46 til 47

Trin 6: Påstanden udføres, og resultatet sendes til brugeren. Da vi ikke har strengen '47' i svaret, er påstanden mislykket.

Fanen "Assertions" rapporterer "Contains"-påstanden som mislykket

Indeholder ikke påstand

Dens modstykke fungerer omvendt. Søger efter den angivne strengs ikke-eksistens. Den understøtter også regulært udtryk.

Trin 1: Efter at have klikket på knappen 'Tilføj nye påstande',

  1. Vælg påstandskategorien.
  2. Vælg påstandstype – I dette tilfælde 'Ikke indeholder'
  3. Klik på 'Tilføj'

Tilføj påstandsdialog med IKKE indeholder det valgte

Trin 2: Lad os validere om strengen 'intA' findes i svaret. Indtast strengen 'FromCurrency' og klik på 'OK'

Indeholder ikke påstandsdialogboksen med strengen FromCurrency indtastet

Trin 3: Så snart en assertion er tilføjet, udføres den og viser resultatet. Indtil videre har vi tilføjet to assertions, så begge assertions udføres og viser resultatet.

Fanen "Påstande" viser resultaterne for både "Indeholder" og "Indeholder ikke".

Trin 4: Lad os nu ændre indholdet af 'Not Contains Assertion' og se, hvad der sker. Vi vil kontrollere, om strengen "AddResult" ikke eksisterer.

Indeholder ikke påstandsdialog, der kontrollerer for tokenet AddResult

Trin 5: Strengen 'AddResult' findes faktisk i svaret, derfor vil 'NOT Contains'-påstanden mislykkes som vist nedenfor.

Påstanden "Indeholder ikke" fejler, fordi AddResult er til stede.

XPath Match Assertion

Stringmatchning er sløv, så den næste assertion er i stedet rettet mod en enkelt node. Bruger XPath-udtryk til at vælge målnoden og dens værdier. XPath, er et XML-forespørgselssprog til at vælge noder fra et XML-dokument.

Trin 1: Efter at have klikket på knappen 'Tilføj nye påstande',

  1. Vælg påstandskategorien.
  2. Vælg påstandstype – i dette tilfælde 'XPath Match'
  3. Klik på 'Tilføj'

Tilføj påstandsdialog med XPath-match valgt

Trin 2: Vinduet Tilføj XPath åbnes.

Før du tilføjer en SoapUI I XPath skal vi deklarere navnerummet. Et XML-navnerum er en samling af navne, identificeret af en URI-reference (Uniform Resource Identifier), som bruges i XML-dokumenter som element- og attributnavne. Det samme bruges i SoapUI XPath-påstand.

For at deklarere et XML-navneområde skal vi blot klikke på knappen 'Deklarer', som ville gøre arbejdet for os, ellers kan vi også manuelt deklarere et navneområde selv.

Efter at have deklareret navnerummet, skal vi referere til XPath ved hjælp af det oprettede navnerum.

Når du klikker på knappen 'Deklarér', dukker der to navnerum op, da vi har to URI'er. En af dem er skemaet. URL og den anden svarer til den faktiske webtjeneste URLVi skal bruge det faktiske navneområde, hvor webtjenesten er placeret, og IKKE skemanavneområdet, når vi refererer til XPath. De deklarerede linjer vises øverst i XPath-boksen som vist nedenfor.

Deklarerede soap- og ns1-navnerum i XPath-deklarationsvinduet

erklær namespace soap='http://schemas.xmlsoap.org/soap/envelope/';

erklær navneområde ns1='http://tempuri.org/';

XPath-deklarationsvindue umiddelbart efter klik på Erklær

Trin 3: Nu skal vi indtaste XPath'en for den XML-node, som vi skal validere.

//ns1:AddResult Giver os værdien af ​​den node, der er indesluttet mellem & og ns1 svarer til det erklærede navneområde, som peger på 'http://tempuri.org/'

Efter at have indtastet XML, skal vi klikke på 'Vælg fra aktuel', så værdien fra det aktuelle svar vil blive samlet op til sammenligning fremover.

XPath-udtryk indtastet med Vælg fra aktuelt fremhævet

Trin 4: Indtil videre,

  1. Efter at have erklæret navneområderne, har vi indtastet den XPath of XML-knude, som vi skal validere.
  2. Vi er nødt til at klikke på 'Vælg fra nuværende' for at gøre den aktuelle værdi som den forventede værdi.
  3. Den aktuelle værdi vises for brugeren, som vi kan ændre efter behov.
  4. Klik på 'Gem'.

XPath Match-konfigurationen, der viser den forventede værdi og knappen Gem

Trin 5: Den tilføjede påstand i SoapUI vil blive vist som vist nedenfor.

Fanen Påstande viser den tilføjede XPath Match-påstand

Scripting påstande

Denne påstandsteknik er den mest udbredte, da det er ekstremt vanskeligt at administrere og vedligeholde hundredvis af påstande.

SoapUI bruger enten Groovy Scripting eller JavaScript til scripting af assertions. Scriptingteknikken er anvendt til udviklingping et framework til test af SOAP. Scripting-assertions bruges under følgende omstændigheder.

  • Scripting giver brugeren mulighed for at udføre visse handlinger før og efter udførelse af en testcase ved hjælp af henholdsvis opsætnings- og nedtagningsmetoder. Opsætning er en procedure, der udføres før en bestemt metode udføres (f.eks. objektoprettelse og initialisering), mens nedtagning er en procedure, der udføres efter metoden er udført (f.eks. ødelæggelse af objekter og oprydning). Denne funktion er ikke tilgængelig i andre assertiontyper og kan kun udføres via kodning.
  • Det giver brugerne mulighed for at åbne/lukke et projekt for at initialisere eller rydde op i projektrelaterede indstillinger og også for at arbejde med miljøvariabler, hvilket er meget nyttigt under scripting.
  • Det hjælper os med at hævde et dynamisk responsindhold.
  • Scripting-påstande bruges til at oprette brugerdefinerede påstande, der IKKE er foruddefinerede af SoapUI.

For at demonstrere en script-påstand i SoapUI, vil vi bruge lommeregneren WSDL, testcasen 'Add', som vi oprettede tidligere.

Trin 1: Trinene til at tilføje groovy script er de samme som for andre assertions, bortset fra at assertionen ikke er foruddefineret. I stedet er det en brugerdefineret assertion, der tilbyder større fleksibilitet end de indbyggede.

Vælg det testtrin, som påstanden skal tilføjes mod.

Testtrin valgt i SoapUI navigator før tilføjelse af en påstand

Klik på knappen 'Tilføj påstand' som vist nedenfor.

Tilføj knappen "Assertion" på værktøjslinjen for testtrin-assertioner

Trin 2: Vælg nu kategorien Påstand.

  1. I dette tilfælde er det Script.
  2. Type SoapUI Scriptpåstand, og der er ingen undertyper tilknyttet den.
  3. Klik på 'Tilføj'.

Tilføj dialogboksen for påstand med den valgte scriptkategori

Trin 3: Dialogboksen Scripting åbnes, hvor brugeren kan skrive et brugerdefineret script for at validere svar-XML'en.

Tom SoapUI dialogboksen editor for scriptpåstande

Trin 4: Lad os nu skrive et smart script til at validere konverteringsraten. Scriptet er vedhæftet nedenfor med indlejrede kommentarer. Det anbefales at have kendskab til Java Script eller Groovy Script før du forsøger at skrive dit eget script.

//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"}
  1. Klik på knappen 'Udfør' for at udløse udførelsen.
  2. Outputtet af Scriptet vises i Output-ruden. Den har udskrevet både konverteringsværdi og slutresultatet (Bestået eller Ikke bestået)
  3. Informationen vises, at 'Script Assertion Passed'. Klik på OK.

Bemærk: Den endelige informations-pop op vises altid med meddelelsen 'Script Assertion Passed', så længe scriptet er syntaktisk korrekt. Det har ingen sammenhæng med din påstand i scriptet.

Script-deklarationsoutputruden udskriver resultatværdien og bestået

klik på OK

Trin 5: Nu viser fanen "Assertions" alle de assertioner, vi har tilføjet til denne testsuite, med status for hver enkelt af dem.

Fanen "Påstande" viser alle påstande, der er tilføjet til testpakken.

Trin 6: Nu

  1. Vælg Test Suite fra Navigator-træet
  2. Klik på knappen 'Kør'
  3. Resultaterne vil blive vist for hele testpakken.

Resultater af kørsel af testsuite efter udførelse af alle assertions

XQuery Match-påstand

Den bruger et XQuery-udtryk til at vælge indhold fra målegenskaben. Vi har brug for en meget større respons-XML for bedre at forstå XQuery-påstanden i SoapUILad os importere endnu en WSDL som vist nedenfor: http://www.webservicex.net/medicareSupplier.asmx?WSDL

Bemærk: De offentlige webservicex.net-demoslutpunkter, der bruges i denne gennemgang, kan ikke længere nås pålideligt, så skærmbillederne af anmodninger og svar nedenfor bevares som referenceeksempel. Enhver WSDL, der returnerer et gentagende nodesæt, vil udføre XQuery-påstanden på nøjagtig samme måde.

Trin 1: Højreklik på det eksisterende projekt, og vælg 'Tilføj WSDL'.

Højreklikmenuen på SoapUI projekt der viser Tilføj WSDL

Trin 2: Dialogboksen Tilføj WSDL åbnes. Lad andre indstillinger være som standard, og klik på knappen 'OK'.

Tilføj WSDL-dialogboks med standard importindstillinger

Trin 3: Alle operationerne er angivet som vist nedenfor.

Medicare-leverandørens WSDL-operationer angivet i navigatortræet

Trin 4: Lad os nu tilføje en Test sag inden for samme testsuite, som vi havde lavet til Test valutaomregneren.

Ny TestCase-mulighed på den eksisterende testsuite

Trin 5: Indtast navnet på testcasen, og klik på knappen 'OK'

Indtastning af testcasenavnet i dialogboksen Ny testcase

Trin 6: Testcasen oprettes som vist nedenfor.

Nyoprettet testcase i SoapUI navigator træ

Trin 7: Tilføj et nyt testtrin af typen 'SOAP Test Request' som vist nedenfor.

Tilføj trin-menu med SOAP-testanmodning valgt

Trin 8: Indtast navnet på testtrinnet. Lad os sige – Leverandør_efter_By, hvilket ville være mere meningsfuldt. Klik på 'OK'.

Navngivning af det nye testtrin Leverandør_efter_By

Trin 9: Vælg den Operation, som vi gerne vil validere. I dette tilfælde er det 'MedicareSupplierSoap -> GetSupplierByCity'. Klik på 'OK'.

Valg af GetSupplierByCity-operationen til testtrinnet

Trin 10: Indtast navnet på testcasen, og klik på 'OK'.

Bekræftelse af navnet på SOAP-testanmodningen

Trin 11: XML-oversigten over anmodningen vises som vist nedenfor.

Genereret GetSupplierByCity-anmodnings-XML-disposition

Trin 12: Lad os nu finde alle leverandøroplysninger for 'New York' City.

For at gøre det skal du tilføje følgende linjer til din kode.

<GetSupplierByCity xmlns="http://www.webservicex.net/">

<City>New York</City>

</GetSupplierByCity>

WSDL nedenfor URL – http://www.webservicex.net/medicareSupplier.asmx?op=GetSupplierByCity

Anmodning om XML redigeret med New York som byværdi

Trin 13: Når testen er udført, modtager vi nedenstående svar

GetSupplierByCity-svar, der indeholder gentagne leverandørposter

Trin 14: Lad os sige, at vi skal validere alle leverandørnumre. Vi kan ikke bruge XPath-assertioner, da vi skal have hundredvis af XPath-assertioner. Derfor er brugen af ​​XQuery uundgåelig i dette tilfælde.

XQuery Assertion hjælper os med at validere en gruppe XML-svar, som er gentagne.

Gentagne SupplierData-noder, som XQuery itererer over

Trin 15: Klik nu på 'Tilføj en påstand',

  1. Vælg 'Assertion Category' – Ejendomsindhold i dette tilfælde.
  2. Vælg påstandstypen som 'XQuery Assertion'
  3. Klik på 'Tilføj'.

XQuery-påstand valgt i kategorien Egenskabsindhold

Trin 16: Ligesom med XPath-assertion skal vi deklarere navnerummet.

  1. Klik på knappen 'Erklær' for automatisk at tillade SoapUI at deklarere navnerummet. Når du klikker på deklareringsknappen, vises en 'POP-op' med beskeden 'deklarer navnerummet fra skemaet i stedet' for brugeren. Klik på 'Ja' for at fortsætte som vist nedenfor.
  2. For at hente hele leverandørnummeret skal vi skrive en XPath-forespørgsel, og vi placerer den inden for < SupplierNumber> og Tags.
  3. Klik på 'Vælg fra den aktuelle', som udføres fra det aktuelle svar.
  4. Når du klikker på 'Vælg fra den nuværende', vises alle leverandørnumre.
  5. Klik på 'Gem'.

Deklarer navneområde fra pop op-vinduet til skemabekræftelse

Bemærk: Når du trykker på 'Anmeld'-knappen, kan du ende med forskellige URL's som navneområdedeklaration, er det dog den faktiske navneplads for webtjenestens placering, der vil blive betragtet som kodning.

Det færdige XQuery-udtryk, med dets navneområdedeklarationer, ser sådan ud.

// 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)}
}

XQuery-udtryksvindue, der viser alle leverandørnumre

Trin 17: XQuery-påstanden udføres og viser det endelige resultat i panelet 'Påstand' som vist nedenfor. Nu har vi tilføjet en XQuery-påstand, som vi bruger til at validere alle leverandørnummeroplysninger. Disse vil blive sammenlignet med de faktiske tal, hver gang anmodningen sendes til webserveren.

Bemærk: De faktiske værdier vil ikke blive vist. Hvis alle faktiske værdier er de samme som de forventede værdier, så viser den GYLDIG, ellers vil den vise 'Failed'.

Påstandspanel, der viser XQuery-påstandsresultatet

Hvornår skal man bruge indbygget påstand?

Med både peg-og-klik- og de scriptede muligheder dækket, er det praktiske spørgsmål, hvilken man skal række ud efter.

  • Når et svar er kort, så det kan valideres ved hjælp af en af ​​disse indbyggede påstande.
  • Vi kan også bruge Inbuilt Assertion, hvis svaret sendt fra webserveren altid er statisk. Hvis det er dynamisk, vil vi ikke være i stand til at hævde det ved hjælp af indbyggede påstande.
  • Når brugen af ​​indbyggede påstande såsom Time-out-påstande og sikkerhedspåstande bliver uundgåelig.
  • Indbyggede påstande holder ret godt til engangsbrug, hvor test ikke behøver at blive gentaget.

Påstandsmuligheder

De oprettede påstande kan bedst kontrolleres ved hjælp af kontrolpanelet, der er fremhævet nedenfor.

Kontrolpanel til værktøjskasse for påstande i SoapUI

De oprettede påstande giver testere mulighed for at konfigurere følgende ting fra påstandsværktøjskassen.

Option Beskrivelse
Flyt påstand op-ikon Den valgte påstand flytter rækkefølgen op.
Flyt påstand ned-ikon Den valgte påstand flytter ned i rækkefølgen.
Fjern påstandsikon Fjerner den valgte påstand
Ikon for konfiguration eller redigering af påstand Genkonfigurer/rediger den valgte påstand.

Nedenfor er de funktioner, der udelukkende er tilgængelige i Pro-versionen af SoapUI, nu sendt som ReadyAPIPro-versionen hjælper os også med at gruppere påstande, så vi kan tilføje endnu et lag af validering til de oprettede påstande.

  • OG: Alle påstande evalueres som GYLDIGE påstande, hvilket vil resultere i gruppebetingelsen BESTÅET.
  • ELLER: Mindst én af påstandene i gruppen skal være GYLDIG for at en gruppebetingelse BESTÅET kan hævdes.
  • Pro-versionen tillader også Kloning af påstandeDenne indstilling giver testere mulighed for at kopiere en assertion til et andet testtrin i det samme eller et andet projekt.
  • Deaktiver/aktiver påstande: Denne indstilling gør det muligt at deaktivere eller aktivere enhver grupperet eller ugrupperet påstand. Hvis en påstand er deaktiveret, er den nedtonet, og når en testcase udføres, udføres deaktiverede påstande ikke.
  • Opdel grupper af påstande: Alle grupperede påstande kan opdeles, hvis testerne beslutter sig for det.

Komplet liste over metoder tilgængelige i forskellige påstandstyper

Tabellen nedenfor samler alle de ovenfor omtalte påstande, grupperet efter den kategori, de vises under i dialogboksen Tilføj påstand.

Påstandsmekanisme Beskrivelse
EJENDOMSINDHOLD
Indeholder Søger efter eksistensen af ​​den angivne streng. Det understøtter også regulært udtryk.
Indeholder ikke Søger efter ikke-eksistens af den angivne streng. Det understøtter også regulært udtryk.
XPath Match Bruger XPath-udtryk til at vælge målknuden og dens værdier.
XQuery Match Bruger et XQuery-udtryk til at vælge indhold fra målegenskaben.
Overholdelse, status, standarder
HTTP Download alle ressourcer Validerer HTML-dokumentet efter download, og det gælder for enhver ejendom, der indeholder HTML.
Ugyldig HTTP-status Codes Bekræfter, om HTML-svaret indeholder en statuskode, der ikke er på listen over definerede koder.
Ikke SOAP Fejl Bekræfter, om den sidst modtagne besked ikke er en SOAP-fejl. Det er meget indlysende, at det kun gælder for SOAP-testtrin.
Overholdelse af skema Bekræfter, om den sidst modtagne meddelelse er kompatibel med WSDL- eller WADL-standardskemadefinitionen. Holder godt til SÆBE- og HVILE-testtrin.
SÆBE fejl Bekræfter, om den sidst modtagne besked er en SOAP-fejl. Det er det omvendte af 'IKKE SOAP' fejlpåstande.
SOAP Response Verificerer, om det sidst modtagne svar er et gyldigt SOAP-svar og kun gælder for SOAP-testanmodningstrin.
Gyldig HTTP-status Codes Bekræfter, om HTML-svaret indeholder en statuskode, der er på listen over definerede koder. Det er det modsatte af 'Ugyldig HTTP-status'. Codes' påstand.
WS-adresseringsanmodning Bekræfter, om den sidst modtagne anmodning indeholder passende WS-adresseringsoverskrifter.
WS-adresseringssvar Bekræfter, om det sidst modtagne svar indeholder passende WS-adresseringsoverskrifter.
WS-Sikkerhedsstatus Validerer, hvis den sidst modtagne besked indeholder gyldige WS-Security-headers og kun gælder for SOAP-anmodninger.
Script
Skriftpåstand Tillader brugere at udføre et brugerdefineret script for at udføre brugerdefinerede valideringer.
SLA
Svar SLA Validerer, om responstiden for det sidst modtagne svar var inden for den definerede grænse.
etc
JMS status Verificerer, om JMS-anmodningen for testtrinnet er udført med succes og gælder for testtrin med et JMS-slutpunkt.
JMS timeout Verificerer, om JMS-svaret for et testtrin ikke tog længere tid end den angivne varighed.
Sikkerhed
Eksponering for følsom information Bekræfter, om svarmeddelelsen ikke afslører følsomme oplysninger om målsystemet. Vi kan bruge denne påstand til REST-, SOAP- og HTTP-testtrin.

DOWNLOAD SOAPUI-PROJEKTET, DER INDEHOLDER OVENSTÅENDE PÅSTAND

Almindelige fejl og fejlfinding

De fleste påstandsfejl trace tilbage til et lille sæt fejl, så tjek disse, før du omskriver et udtryk.

  • Brug det korrekte navnerum. Navnerummet skal være URL hvor webtjenesten er placeret.
  • Hvis der opstår en fejl under udviklingping en scripting-assertion, brug 'log.info' til at udskrive indholdet af variablerne.
  • Hvis du ikke har fået det ønskede output, skal du kontrollere, om et gyldigt input er bestået i anmodningen.

Hvis du for eksempel i valutaomregneren indtaster 'intA' som 'x', hvilket ikke er et heltal, udløser outputtet en fejlkode som 'SOAP-Client', hvilket betyder, at problemet er med den parameter, der sendes fra klientsiden. Anmodningen med den ugyldige værdi vises først.

SoapUI anmodning om at sende en ugyldig ikke-heltalværdi for intA

Svaret returnerer fejlkoden i stedet for et resultat, som vist nedenfor.

SOAP-klientfejlkode returneret i SoapUI svarredigeringsprogram

Sørg for at bruge den korrekte syntaks, når du bruger XPath- og XQuery-assertioner. Du bør IKKE bruge punktum(.) i stedet for kolon(:), når du bruger ovenstående assertion. Syntaksen er //namespace:Tagname og IKKE //namespace.tagname. Hvis du gør det, kan du ende med at få en besked om, at 'INGEN match i nuværende svar', selvom tagnavnet er korrekt.

INGEN match i det aktuelle svar, fejl forårsaget af forkert XPath-syntaks

Ofte Stillede Spørgsmål

Ethvert tal. SoapUI anvender alle påstande, der er knyttet til et sampler-testtrin, efter det er udført, og trinnet markeres som mislykket i testcase-visningen, hvis bare én af disse påstande mislykkes.

Den sammenligner en XML-meddelelse med et forventet dokument node for node, så udvalgte felter kan ignoreres eller matches løst i stedet for at behandle hele nyttelasten som én almindelig streng.

Open source SoapUI dækker ejendomsindhold, compliance, script, SLA, JMS og sikkerhed. ReadyAPI tilføjer groupping, kloning, JDBC-tjek og aktivering eller deaktivering af kontrol.

AI-modeller læser et eksempelsvar og foreslår XPath- eller XQuery-udtryk, foreslår grænseværdier og markerer felter, der ændres ved hver kørsel – hvilket reducerer det håndskrevne navneområde- og udtryksarbejde betydeligt.

Ja. CoPilot autofuldførelser GroovyStandardversioner af Utils og XmlHolder. Kør altid scriptet først, da et syntaktisk gyldigt script rapporterer Script Assertion Passed uanset din sammenligning.

Ja. Felter til påstandsindhold understøtter egenskabsudvidelse, så den forventede værdi kan hentes fra en projekt- eller testcaseegenskab i stedet for en literal, hvilket holder én påstand genbrugelig på tværs af miljøer.

En mislykket assertion markerer sit testtrin som mislykket i testcase-visningen og skriver en matchende FAILED-post med fejldetaljerne i testudførelsesloggen nederst i vinduet.

Indeholder, Indeholder ikke, XPath-match, XQuery-match, svar-SLA, script, gyldige og ugyldige HTTP-statuskoder, eksponering af følsomme oplysninger og skemaoverholdelse mod et WADL eller et udledt skema.

Opsummer dette indlæg med: