Påstande i SoapUI: Scripts, XQuery, XPath Types Tutorial
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 et svar. Vi skal validere, om svaret indeholder de data, vi forventer. For at validere svaret skal vi bruge påstande.
Typer af påstande
Der er forskellige måder at hævde et svar på; dog vil vi fokusere på de almindeligt anvendte SoapUI Assertions-typer, mens vi validerer et svar. Nedenfor er dem, der er tilgængelige i Open Source-versionen af SoapUI.
- Ejendomsindhold
- Overholdelsesstatusstandard
- Script
- SLA
- etc
- Sikkerhed
Udover dem, der er anført ovenfor, har PRO-versionen også en indbygget JDBC Assertion, som vi kan påstå, om webtjenesten har opdateret databasen korrekt.
INDEHOLDER PÅSTÅELSE
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.asmx.
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 en påstand med det samme og viser om GYLDIG eller UGYLDIG.
Trin 5: Lad os nu sige, at vi ændrer indholdet af 'Contains Assertion in 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
Søger efter ikke-eksistens af den angivne streng. Det understøtter også regulært udtryk.
Trin 1: Nu 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 påstand er tilføjet, udføres den og viser resultatet. Indtil videre har vi tilføjet to påstande, så begge påstande udføres og viser resultatet.
Trin 4: Lad os nu ændre indholdet af 'Not Contains Assertion' og se, hvad der sker. Vi vil tjekke for ikke-eksistensen af strengen "AddResult".
Trin 5: Strengen 'AddResult' er faktisk til stede i svaret, derfor vil 'NOT Contains'-påstanden mislykkes som vist nedenfor.
XPATH MATCH PÅSTAND
Du bruger XPath udtryk for at vælge målknuden og dens værdier. XPath, er et XML-forespørgselssprog til at vælge noder fra et XML-dokument.
Trin 1: Nu 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 vi tilføjer SoapUI XPath, skal vi erklære NameSpace. Et XML-navneområde er en samling af navne, identificeret af en Uniform Resource Identifier (URI) reference, som bruges i XML-dokumenter som element- og attributnavne. Det samme bruges i SOAP UI XPath Assertion.
For at erklære XML-navneområde skal vi blot klikke på 'Declarer'-knappen, hvilket ville gøre jobbet for os, ellers kan vi også manuelt erklære et navneområde selv.
Efter at have erklæret navneområdet, skal vi henvise til XPath ved hjælp af det oprettede navneområde.
Når du klikker på knappen 'Erklær', vil to navneområder dukke op, da vi har to URI'er. En af dem er skema-URL'en, og den anden svarer til den faktiske webservice-URL. Vi skal bruge det faktiske navneområde, hvor webtjenesten er placeret, og IKKE skemanavnerummet, mens vi refererer til XPath.
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 XML-noden, 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: Hidtil
- 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.
SOAP UI bruger enten Groovy Scripting eller JavaScript til scripting påstande. Scripting-teknikken er brugt til at udvikle en ramme til test af SOAP. Scripting-påstande bruges under følgende omstændigheder.
Scripting giver brugeren mulighed for at udføre nogle operationer før og efter eksekvering af en TestCase ved hjælp af henholdsvis opsætnings- og rivningsmetoder. Opsætning er en procedure, der udføres før udførelse af en bestemt metode (eksempel - Objektoprettelse og -initialisering), mens tear down er en procedure, der udføres efter udførelse af metoden (f.eks.: Ødelæggelse af objekter og oprydning). Denne funktion er ikke tilgængelig i andre Assertion-typer og kan kun udføres gennem kodning.
Det giver brugerne mulighed for at åbne/lukke et projekt, for at initialisere eller rydde op i projektrelaterede indstillinger og også 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 skabe brugerdefinerede påstande, der IKKE er foruddefineret af SOAP UI.
Til demonstration af script-påstand i SoapUI vil vi gøre brug af lommeregneren WSDL, testcasen 'Add', som vi havde oprettet tidligere.
Trin 1: Trin til at tilføje groovy script er det samme som for andre påstande, bortset fra at påstanden ikke er en foruddefineret. I stedet er det en brugerdefineret påstand, som giver 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.
- Vælg SoapUI Script Assertion, og der er ingen undertyper forbundet med det.
- Klik på 'Tilføj'.
Trin 3: Scripting-dialogen åbner, hvor brugeren vil være i stand til at skrive brugerdefineret script for at validere svar-XML.
Trin 4: Lad os nu skrive et groovy script for at validere konverteringsraten. Scriptet er vedhæftet nedenfor med kommentarerne indlejret. Det anbefales at have viden om 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 påstandsfanen alle de påstande, som vi havde tilføjet for denne testpakke med status mod hver 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 Assertion
Den bruger et Xquery-udtryk til at vælge indhold fra målegenskaben. Vi har brug for en meget større XML-respons for bedre at forstå XQuery-påstanden i SoapUI. Lad os importere en anden WSDL som vist nedenfor: http://www.webservicex.net/medicareSupplier.asmx?WSDL
Trin 1: Udfør et højreklik på det eksisterende projekt og vælg 'Tilføj WSDL'.
Trin 2: Udfør et højreklik på det eksisterende projekt og vælg 'Tilføj WSDL'. Lad andre indstillinger være standard, og klik på 'OK'-knappen.
Trin 3: Alle operationer 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å 'OK'-knappen
Trin 6: Testcasen oprettes som vist nedenfor.
Trin 7: Tilføj
et nyt testtrin af Type 'Sæbetestanmodning' som vist nedenfor.
Trin 8: Indtast navnet på testtrinnet. Lad os sige – Supplier_by_City, hvilket ville være mere meningsfuldt Klik på 'OK'.
Trin 9: Vælg 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: Request XML Outline vil blive vist 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 i nedenstående URL – http://www.webservicex.net/medicareSupplier.asmx?op=GetSupplierByCity
Trin 13: Ved udførelse af testen modtager vi nedenstående svar
Trin 14: Lad os sige, at vi skal validere alle leverandørnummeret. Vi kan ikke bruge XPath Assertion, da vi skal have hundredvis af XPath Assertion. 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: I lighed med XPath Assertion skal vi erklære navneområdet.
-
Klik på knappen 'Declare' for automatisk at tillade SOAP UI at erklære navneområdet. Når du klikker på erklærer knappen, vil en 'POP up' med beskeden 'erklær navneområde fra skema i stedet' blive vist for brugeren. Klik på 'Ja' for at fortsætte som vist nedenfor.
Bemærk: Når du trykker på 'Declarer-knappen', kan du ende med forskellige URL'er som navneområdeerklæring, men det faktiske webserviceplaceringsnavneområde er det, der vil blive overvejet til kodning.
- 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 aktuelle', vises alle leverandørnumre.
- Klik på 'Gem'.
// 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 Assertion udføres og viser det endelige resultat i 'Assertion'-panelet som vist nedenfor. Nu har vi tilføjet en Xquery-påstand, hvor vi har valideret alle oplysninger om leverandørnummer. Det samme ville blive sammenlignet med de faktiske værdier, 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?
- 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 | Description |
---|---|
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 SOAP UI. PRO-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.
- Pro-versionen tillader også Kloning af påstande: Denne indstilling giver testere mulighed for at tillade kopiering af en påstand til et andet testtrin i det samme eller et andet projekt.
- Deaktiver/Aktiver påstande: Denne indstilling tillader enhver grupperet eller ugrupperet påstand at blive deaktiveret eller aktiveret. Hvis en påstand er deaktiveret, er den nedtonet, og når en testsag udføres, vil deaktiverede påstande ikke blive udført.
- Ophæv gruppering af påstande: Alle grupperede påstande kan ophæves, hvis testere beslutter at gøre det.
OG: Alle påstande vurderes som GYLDIGE påstande, hvilket vil resultere i bestået gruppebetingelse. ELLER: Mindst én af påstandene i gruppen skal være GYLDIG for at hævde en gruppebestået betingelse.
Komplet liste over metoder tilgængelige i forskellige påstandstyper
Påstandsmekanisme |
Description |
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. |
Ugyldige HTTP-statuskoder | 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. |
Gyldige HTTP-statuskoder | Bekræfter, om HTML-svaret indeholder en statuskode, der er på listen over definerede koder. Det er det omvendte af 'Ugyldige HTTP-statuskoder' 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
Brug det korrekte navneområde. Navnerummet skal være den URL, hvor webtjenesten er placeret.
Hvis der opstår en fejl under udvikling af en scripting-påstand, skal du bruge '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.
For eksempel, i valutaomregner, hvis du indtaster 'intA' som 'x', som ikke er heltal, udsender output en fejlkode som 'SOAP-Client', hvilket betyder, at problemet er med den parameter, der sendes fra klientsiden.
Sørg for, at du bruger den korrekte syntaks, mens du bruger XPATH og XQuery påstand. Du bør IKKE bruge prik(.) i stedet for kolon(:), mens du bruger ovenstående påstand. Syntaksen er //namespace:Tagname og IKKE //namespace.tagname. Ved at gøre det kan du ende med at få en besked, der "NO match in current response", selvom tagnavnet er korrekt.