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.
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.
- Ejendomsindhold
- Overholdelsesstatusstandard
- Script
- SLA
- etc
- Sikkerhed
Dialogboksen grupperer alle påstande under disse kategorier, som skærmbilledet nedenfor viser.

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.
- Antallet af påstande er vist på fanen påstande.
- For at tilføje en ny påstand skal du klikke på knappen 'Tilføj ny påstand'.
Trin 2: Nu,
- Vælg påstandskategorien.
- Vælg påstandstype.
- Klik på 'Tilføj'
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.
Trin 4: Når den tilføjes, udføres assertionen straks, og det vises, om den er GYLDIG eller UGYLDIG.
Trin 5: Lad os nu sige, at vi ændrer indholdet af 'Indeholder påstand i SoapUI' til '47' og se hvad der sker.
Trin 6: Påstanden udføres, og resultatet sendes til brugeren. Da vi ikke har strengen '47' i svaret, er påstanden 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',
- Vælg påstandskategorien.
- Vælg påstandstype – I dette tilfælde 'Ikke indeholder'
- Klik på 'Tilføj'
Trin 2: Lad os validere om strengen 'intA' findes i svaret. Indtast strengen 'FromCurrency' og klik på 'OK'
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.
Trin 4: Lad os nu ændre indholdet af 'Not Contains Assertion' og se, hvad der sker. Vi vil kontrollere, om strengen "AddResult" ikke eksisterer.
Trin 5: Strengen 'AddResult' findes faktisk i svaret, derfor vil 'NOT Contains'-påstanden mislykkes som vist nedenfor.
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',
- Vælg påstandskategorien.
- Vælg påstandstype – i dette tilfælde 'XPath Match'
- Klik på 'Tilføj'
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.
erklær namespace soap='http://schemas.xmlsoap.org/soap/envelope/';
erklær navneområde ns1='http://tempuri.org/';
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.
Trin 4: Indtil videre,
- Efter at have erklæret navneområderne, har vi indtastet den XPath of XML-knude, som vi skal validere.
- 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.
- Den aktuelle værdi vises for brugeren, som vi kan ændre efter behov.
- Klik på 'Gem'.
Trin 5: Den tilføjede påstand i SoapUI vil blive vist som vist nedenfor.
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.
Klik på knappen 'Tilføj påstand' som vist nedenfor.
Trin 2: Vælg nu kategorien Påstand.
- I dette tilfælde er det Script.
- Type SoapUI Scriptpåstand, og der er ingen undertyper tilknyttet den.
- Klik på 'Tilføj'.
Trin 3: Dialogboksen Scripting åbnes, hvor brugeren kan skrive et brugerdefineret script for at validere svar-XML'en.
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"}
- Klik på knappen 'Udfør' for at udløse udførelsen.
- Outputtet af Scriptet vises i Output-ruden. Den har udskrevet både konverteringsværdi og slutresultatet (Bestået eller Ikke bestået)
- 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.
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.
Trin 6: Nu
- Vælg Test Suite fra Navigator-træet
- Klik på knappen 'Kør'
- Resultaterne vil blive vist for hele testpakken.
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'.
Trin 2: Dialogboksen Tilføj WSDL åbnes. Lad andre indstillinger være som standard, og klik på knappen 'OK'.
Trin 3: Alle operationerne er angivet som vist nedenfor.
Trin 4: Lad os nu tilføje en Test sag inden for samme testsuite, som vi havde lavet til Test valutaomregneren.
Trin 5: Indtast navnet på testcasen, og klik på knappen 'OK'
Trin 6: Testcasen oprettes som vist nedenfor.
Trin 7: Tilføj et nyt testtrin af typen 'SOAP Test Request' som vist nedenfor.
Trin 8: Indtast navnet på testtrinnet. Lad os sige – Leverandør_efter_By, hvilket ville være mere meningsfuldt. Klik på 'OK'.
Trin 9: Vælg den Operation, som vi gerne vil validere. I dette tilfælde er det 'MedicareSupplierSoap -> GetSupplierByCity'. Klik på 'OK'.
Trin 10: Indtast navnet på testcasen, og klik på 'OK'.
Trin 11: XML-oversigten over anmodningen vises som vist nedenfor.
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
Trin 13: Når testen er udført, modtager vi nedenstående svar
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.
Trin 15: Klik nu på 'Tilføj en påstand',
- Vælg 'Assertion Category' – Ejendomsindhold i dette tilfælde.
- Vælg påstandstypen som 'XQuery Assertion'
- Klik på 'Tilføj'.
Trin 16: Ligesom med XPath-assertion skal vi deklarere navnerummet.
- 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.
- For at hente hele leverandørnummeret skal vi skrive en XPath-forespørgsel, og vi placerer den inden for < SupplierNumber> og Tags.
- Klik på 'Vælg fra den aktuelle', som udføres fra det aktuelle svar.
- Når du klikker på 'Vælg fra den nuværende', vises alle leverandørnumre.
- Klik på 'Gem'.
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)} }
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'.
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.
De oprettede påstande giver testere mulighed for at konfigurere følgende ting fra påstandsværktøjskassen.
| Option | Beskrivelse |
| Den valgte påstand flytter rækkefølgen op. | |
| Den valgte påstand flytter ned i rækkefølgen. | |
| Fjerner den valgte 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.
Svaret returnerer fejlkoden i stedet for et resultat, som vist nedenfor.
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.














































