Påstander i SoapUI: Scripts, XQuery, XPath Types Tutorial

Hva er en påstand?

Påstand betyr handling for å bekrefte eller si noe. Det kan også tolkes som et sjekkpunkt eller et valideringspunkt.

Når en forespørsel er sendt til en webserver, mottas et svar. Vi må validere om svaret inneholder dataene vi forventer. For å validere svaret må vi bruke påstander.

Typer påstand

Det er ulike måter å hevde et svar på; Vi vil imidlertid fokusere på de vanligste SoapUI Assertions-typene mens vi validerer et svar. Nedenfor er de som er tilgjengelige i Open Source-versjonen av SoapUI.

1. Eiendomsinnhold
2. Samsvarsstatusstandard
3. Script
4. SLA
5. JMS
6. Trygghet

Bortsett fra de som er oppført ovenfor, har PRO-versjonen også en innebygd JDBC Assertion som vi kan hevde om nettjenesten har oppdatert databasen riktig.

INNEHOLDER PÅSTÅELSE

Søker etter eksistensen av den angitte strengen. Den støtter også regulært uttrykk.

Vi vil fortsette med det samme eksempelet fra forrige opplæring med WSDL-forespørsel som http://www.dneonline.com/calculator.asmx.

Trinn 1: Som standard er det ingen påstander.

• Antall påstander vises i kategorien påstander.
• For å legge til en ny påstand, klikk på 'Legg til ny påstand'-knappen.

Trinn 2: Nå,

1. Velg påstandskategorien.
2. Velg påstandstype.
3. Klikk "Legg til"

Trinn 3: La oss validere om strengen '46' finnes i svaret. Klikk "OK"

Merk: Vi kan også ignorere store og små bokstaver og legge til regulære uttrykk.

Trinn 4: Når den legges til, utføres påstanden umiddelbart og viser om GYLDIG eller UGYLDIG.

Trinn 5: La oss nå si at vi endrer innholdet i 'Contains Assertion in SoapUI' til '47' og ser hva som skjer.

Trinn 6: Påstanden utføres og resultatet sendes til brukeren. Siden vi ikke har strengen '47' i svaret, har påstanden mislyktes.

INNEHOLDER IKKE PÅSTAND

Søker etter ikke-eksistens av den angitte strengen. Den støtter også regulært uttrykk.

Trinn 1: Nå etter å ha klikket på 'legg til nye påstander'-knappen,

1. Velg påstandskategorien.
2. Velg påstandstype – I dette tilfellet 'Ikke inneholder'
3. Klikk "Legg til"

Trinn 2: La oss validere om strengen 'intA' finnes i svaret. Skriv inn strengen "FromCurrency" og klikk "OK"

Trinn 3: Så snart en påstand er lagt til, kjører den og viser resultatet. Så langt har vi lagt til to påstander, derfor blir både påstandene utført og vist resultatet.

Trinn 4: La oss nå endre innholdet i 'Ikke inneholder påstanden' og se hva som skjer. Vi vil se etter at strengen "AddResult" ikke eksisterer.

Trinn 5: Strengen 'AddResult' er faktisk til stede i svaret, derfor vil påstanden 'NOT Contains' mislykkes som vist nedenfor.

XPATH MATCH PÅSTAND

Bruker XPath uttrykk for å velge målnoden og dens verdier. XPath, er et XML-spørringsspråk for å velge noder fra et XML-dokument.

Trinn 1: Nå etter å ha klikket på 'Legg til nye påstander'-knappen,

1. Velg påstandskategorien.
2. Velg påstandstype – i dette tilfellet 'XPath Match'
3. Klikk "Legg til"

Trinn 2: Legg til XPath-vinduet åpnes.

Før vi legger til SoapUI XPath, må vi deklarere NameSpace. Et XML-navneområde er en samling navn, identifisert av en Uniform Resource Identifier (URI)-referanse, som brukes i XML-dokumenter som element- og attributtnavn. Det samme brukes i SOAP UI XPath Assertion.

For å deklarere XML-navneområde, trenger vi bare å klikke på 'Declare'-knappen som ville gjøre jobben for oss, ellers kan vi også manuelt erklære et navneområde selv.

Etter å ha erklært navneområdet, må vi henvise til XPath ved å bruke det opprettede navnerommet.

Når du klikker på 'Erklær'-knappen, vil to navneområder dukke opp ettersom vi har to URI-er. En av dem er skjema-URLen og den andre tilsvarer den faktiske netttjenestens URL. Vi må bruke det faktiske navneområdet der webtjenesten er plassert og IKKE skjemanavneområdet mens vi refererer til XPath.

erklær navneområdet soap='http://schemas.xmlsoap.org/soap/envelope/';

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

Trinn 3: Nå må vi angi XPath til XML-noden som vi må validere.

//ns1:AddResult Gir oss verdien til noden som ligger mellom & og ns1 tilsvarer det deklarerte navnerommet som peker til 'http://tempuri.org/'

Etter å ha lagt inn XML, må vi klikke på "Velg fra gjeldende" slik at verdien fra det gjeldende svaret vil bli plukket opp for sammenligning fremover.

Trinn 4: Så langt,

1. Etter å ha erklært navneområdene, har vi angitt XPath of XML-noden som vi trenger å validere.
2. Vi må klikke "Velg fra gjeldende" for å gjøre gjeldende verdi som forventet verdi.
3. Gjeldende verdi vises til brukeren som vi kan endre om nødvendig.
4. Klikk "Lagre".

Trinn 5: Den ekstra påstanden i SoapUI vil vises som vist nedenfor.

Skriptpåstander

Denne påstandsteknikken er den mest brukte siden det er ekstremt vanskelig å administrere og vedlikeholde hundrevis av påstander.

SOAP UI bruker enten Groovy Skript eller JavaScript for skriptpåstander. Skriptteknikken er tatt i bruk for å utvikle et rammeverk for testing av SOAP. Skriptpåstander brukes under følgende omstendigheter.

Skripting lar brukeren utføre enkelte operasjoner før og etter utføring av en TestCase ved å bruke henholdsvis oppsett- og rivemetoder. Oppsett er en prosedyre som utføres før utførelse av en bestemt metode (eksempel - Objektoppretting og initialisering) mens rive er en prosedyre som utføres etter utføring av metoden (f.eks.: ødelegge objekter og rydde opp). Denne funksjonen er ikke tilgjengelig i andre påstandstyper og kan bare gjøres gjennom koding.

Det lar brukere utføre åpning/lukking av et prosjekt, for å initialisere eller rydde opp i prosjektrelaterte innstillinger og også å jobbe med miljøvariabler, noe som er veldig nyttig under skripting.

Det hjelper oss med å hevde et dynamisk responsinnhold.

Skriptpåstander brukes til å lage brukerdefinerte påstander som IKKE er forhåndsdefinert av SOAP UI.

For å demonstrere skriptpåstand i SoapUI, vil vi bruke kalkulatoren WSDL, testsaken 'Add' som vi hadde laget tidligere.

Trinn 1: Trinnene for å legge til groovy skript er de samme som for andre påstander, bortsett fra at påstanden ikke er forhåndsdefinert. I stedet er det en brukerdefinert påstand som gir større fleksibilitet enn de innebygde.

Velg testtrinnet som påstanden skal legges til.

Klikk "Legg til påstand"-knappen som vist nedenfor.

Trinn 2: Velg nå kategorien påstand.

1. I dette tilfellet er det Script.
2. Velg SoapUI Script Assertion og det er ingen undertyper knyttet til den.
3. Klikk "Legg til".

Trinn 3: Skriptdialogen åpnes der brukeren vil kunne skrive brukerdefinert skript for å validere responsen XML.

Trinn 4: La oss nå skrive et groovy skript for å validere konverteringsfrekvensen. Skriptet er vedlagt nedenfor med kommentarene innebygd. Det anbefales å ha kunnskap om Java Manus eller Groovy Skript før du prøver å skrive ditt eget manus.

//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. Klikk "Utfør"-knappen for å utløse kjøringen.
2. Utdataene fra skriptet vises i utdataruten. Den har skrevet ut både konverteringsverdi og sluttresultatet (bestått eller ikke bestått)
3. Informasjonen vises som 'Script Assertion Passed'. Klikk OK.

Merk: Den endelige informasjonspop-upen vil alltid vises med meldingen 'Script Assertion Passed' så lenge skriptet er syntaktisk korrekt. Det har ingen sammenheng med påstanden din i manuset.

klikk OK

Trinn 5: Nå viser påstandsfanen alle påstandene vi har lagt til for denne testpakken med statusen mot hver av dem.

Trinn 6: Nå

1. Velg Test Suite fra Navigator-treet
2. Klikk "Kjør"-knappen
3. Resultatene vil bli vist for hele testpakken.

Xquery Match Assertion

Den bruker et Xquery-uttrykk for å velge innhold fra målegenskapen. Vi trenger en mye større respons-XML for bedre å forstå XQuery-påstanden i SoapUI. La oss importere en annen WSDL som vist nedenfor: http://www.webservicex.net/medicareSupplier.asmx?WSDL

Trinn 1: Utfør et høyreklikk på det eksisterende prosjektet og velg 'Legg til WSDL'.

Trinn 2: Utfør et høyreklikk på det eksisterende prosjektet og velg 'Legg til WSDL'. La andre alternativer være standard og klikk "OK"-knappen.

Trinn 3: Alle operasjonene er oppført som vist nedenfor.

Trinn 4: La oss nå legge til en Testsak innenfor samme testsuite som vi hadde laget for Testing valutaomregneren.

Trinn 5: Skriv inn navnet på testsaken og klikk "OK"-knappen

Trinn 6: Testtilfellet opprettes som vist nedenfor.

Trinn 7: Legg til
et nytt testtrinn av Type 'Såpetestforespørsel' som vist nedenfor.

Trinn 8: Skriv inn navnet på testtrinnet. La oss si - Supplier_by_City som ville være mer meningsfylt Klikk 'OK'.

Trinn 9: Velg Operasom vi ønsker å validere. I dette tilfellet er det 'MedicareSupplierSoap -> GetSupplierByCity'. Klikk 'OK'.

Trinn 10: Skriv inn navnet på testsaken og klikk "OK".

Trinn 11: Forespørsels-XML-oversikten vil bli vist som vist nedenfor.

Trinn 12: La oss nå finne all leverandørinformasjon for 'New York' City.

For å gjøre det, legg til følgende linjer i koden.

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

<City>New York</City>

</GetSupplierByCity>

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

Trinn 13: Når testen er utført, mottar vi svaret nedenfor

Trinn 14: La oss si at vi må validere alle leverandørnummer. Vi kan ikke bruke XPath Assertion da vi må ha hundrevis av XPath Assertion. Derfor er bruken av XQuery uunngåelig i dette tilfellet.

XQuery Assertion hjelper oss med å validere en gruppe XML-svar som er repeterende.

Trinn 15: Klikk nå på "Legg til en påstand",

1. Velg 'påstandskategorien' – eiendomsinnhold i dette tilfellet.
2. Velg påstandstype som 'XQuery påstand'
3. Klikk "Legg til".

Trinn 16: I likhet med XPath Assertion må vi deklarere navneområdet.

1. Klikk på 'Declare'-knappen for automatisk å la SOAP UI erklære navneområdet. Ved å klikke på erklærer-knappen vil en 'POP-opp' med meldingen 'erklær navneområde fra skjema i stedet' bli vist til brukeren. Klikk "Ja" for å fortsette som vist nedenfor.

   OBS: Når du trykker på "Declare-knappen" kan du ende opp med forskjellige URL-er som navneområdedeklarasjon, men det faktiske nettjenestens plasseringsnavneområdet er det som vil bli vurdert for koding.

   

2. For å hente alle leverandørnummeret, må vi skrive en XPath-forespørsel, og vi vil plassere den innenfor < SupplierNumber> og Tagger.
3. Klikk "Velg fra gjeldende" som vil utføres fra gjeldende svar.
4. Ved å klikke på "Velg fra gjeldende", vises alle leverandørnummer.
5. Klikk "Lagre".

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

Trinn 17: XQuery Assertion utføres og viser det endelige resultatet i 'Assertion'-panelet som vist nedenfor. Nå har vi lagt til en Xquery-påstand som vi har validert all informasjon om leverandørnummeret. Det samme vil bli sammenlignet med de faktiske, hver gang forespørselen sendes til webserveren.

Merk: De faktiske verdiene vises ikke. Hvis alle faktiske verdier er de samme som de forventede verdiene, viser den GYLDIG, ellers vil den vise 'Failed'.

Når skal man bruke innebygd påstand?

• Når et svar er kort slik at det kan valideres ved hjelp av en av de innebygde påstandene.
• Vi kan også bruke Inbuilt Assertion hvis svaret som sendes fra webserveren alltid er statisk. Hvis det er dynamisk, vil vi ikke kunne hevde det ved hjelp av innebygde påstander.
• Når bruk av innebygde påstander som Time-out-påstander og sikkerhetspåstander blir uunngåelig.
• Inbuilt Assertions holder ganske bra for engangsbruk der tester ikke trenger å gjentas.

Påstandsalternativer

De opprettede påstandene kan best kontrolleres ved hjelp av kontrollpanelet som er uthevet nedenfor.

De opprettede påstandene lar testere konfigurere følgende ting fra påstandsverktøykassen.

• Nedenfor er funksjonene tilgjengelig eksklusivt i PRO-versjonen av SOAP UI. PRO-versjonen hjelper oss også med å gruppere påstander slik at vi kan legge til ett lag med validering til de opprettede påstandene.

OG: Alle påstander vurderes som GYLDIG påstand som vil resultere i PASSED gruppebetingelse. ELLER: Minst én av påstandene i gruppen må være GYLDIG for å hevde en gruppe PASSED betingelse.

• Pro-versjonen tillater også Kloning av påstander: Dette alternativet lar testere tillate kopiering av en påstand til et annet testtrinn i samme eller et annet prosjekt.
• Deaktiver/aktiver påstander: Dette alternativet lar alle grupperte eller ugrupperte påstander deaktiveres eller aktiveres. Hvis en påstand er deaktivert, er den nedtonet, og når en testsak utføres, vil ikke deaktiverte påstander bli utført.
• Dele opp påstander: Alle grupperte påstander kan oppheves hvis testere bestemmer seg for å gjøre det.

Komplett liste over metoder tilgjengelig i ulike påstandstyper

LAST NED SOAPUI-PROSJEKTET SOM INNEHOLDER OVENFOR PÅSTAND

Vanlige feil og feilsøking

Bruk riktig navneområde. Navneområdet skal være URL-en der nettjenesten er plassert.

Hvis det oppstår en feil under utvikling av en skriptpåstand, bruk 'log.info' for å skrive ut innholdet i variablene

Hvis du ikke har den ønskede utgangen, kontroller om en gyldig inngang er sendt i forespørselen.

For eksempel, i valutaomregner, hvis du legger inn 'intA' som 'x' som ikke er heltall, sender utgangen en feilkode som 'SOAP-Client' som betyr at problemet er med parameteren som sendes fra klientsiden.

Sørg for at du bruker riktig syntaks mens du bruker XPATH og XQuery-påstand. Du bør IKKE bruke punkt(.) i stedet for kolon(:) mens du bruker påstanden ovenfor. Syntaksen er //namespace:Tagname og IKKE //namespace.tagname. Ved å gjøre det kan du ende opp med å få en melding som 'INGEN samsvarer i gjeldende svar' selv om tagnavnet er riktig.