Påstander i SoapUISkript, XQuery, XPath-typer

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 sendes til en webserver, mottas et svar. Vi må validere om svaret inneholder dataene vi forventer. For å validere svaret må vi bruke påstander. Uten en påstand beviser et testtrinn bare at tjenesten svarte, ikke at den svarte riktig, og det er derfor alle API-test bør ha med seg minst én.

Typer påstand

Det finnes ulike måter å formulere et svar på, men vi vil fokusere på de vanligste SoapUI påstandstyper under validering av et svar. Nedenfor finner du kategoriene som er tilgjengelige i åpen kildekode-versjonen av SoapUI.

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

Dialogboksen grupperer alle påstander under disse kategoriene, som skjermbildet nedenfor viser.

Bortsett fra de som er oppført ovenfor, har Pro-versjonen også en innebygd JDBC-påstand som vi bruker for å bekrefte om webtjenesten har oppdatert databasen riktig.

Versjonsmerknad: nåværende SoapUI dokumentasjonen viser også en JDBC kategori (JDBC-status og JDBC-tidsavbrudd) ved siden av kategoriene ovenfor, og en Meldingens innhold påstand i egenskapsinnhold for rikere XML-sammenligning. Den kommersielle utgaven som her omtales som «Pro» selges nå som ReadyAPI av SmartBear, så menyetiketter i nyere versjoner kan leses annerledes mens deklarasjonsoppførselen forblir den samme.

Inneholder påstand

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.asmxHvis du ikke har bygget det prosjektet ennå, jobb deg gjennom opprette et prosjekt, en testsuite og en testcase først.

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

1. Antall påstander vises i kategorien påstander.
2. 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 bekrefte om strengen '46' finnes i svaret. Klikk på 'OK'.

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

Trinn 4: Når den er lagt til, utføres deklarasjonen umiddelbart og viser om den er GYLDIG eller UGYLDIG.

Trinn 5: La oss nå si at vi endrer innholdet i «Inneholder påstand i» SoapUI' til '47' og se hva som skjer.

Trinn 6: Deklarasjonen utføres, og resultatet sendes til brukeren. Siden vi ikke har strengen '47' i svaret, har deklarasjonen mislyktes.

Inneholder ikke påstand

Motparten fungerer motsatt. Søker etter at den angitte strengen ikke eksisterer. Den støtter også regulært uttrykk.

Trinn 1: Etter å ha klikket på knappen «legg til nye påstander»,

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, utføres den og resultatet vises. Så langt har vi lagt til to påstander, derfor utføres begge påstandene og resultatet vises.

Trinn 4: La oss nå endre innholdet i «Ikke inneholder påstanden» og se hva som skjer. Vi skal sjekke om strengen «AddResult» ikke finnes.

Trinn 5: Strengen «AddResult» finnes faktisk i svaret, derfor vil «IKKE inneholder»-deklarasjonen mislykkes, som vist nedenfor.

XPath Match Assertion

Strengmatching er sløv, så den neste deklarasjonen er rettet mot en enkelt node i stedet. Bruker XPath-uttrykk for å velge målnoden og dens verdier. XPath, er et XML-spørrespråk for å velge noder fra et XML-dokument.

Trinn 1: Etter å ha klikket på knappen «Legg til nye påstander»,

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

Trinn 2: Vinduet Legg til XPath åpnes.

Før du legger til en SoapUI I XPath må vi deklarere navnerommet. Et XML-navnerom er en samling av navn, identifisert av en URI-referanse (Uniform Resource Identifier), som brukes i XML-dokumenter som element- og attributtnavn. Det samme brukes i SoapUI XPath-påstand.

For å deklarere et XML-navneområde trenger vi bare å klikke på «Deklarer»-knappen, som ville gjort jobben for oss. Ellers kan vi også deklarere et navneområde manuelt selv.

Etter at vi har deklarert navnerommet, må vi referere XPath-en ved å bruke det opprettede navnerommet.

Når du klikker på «Deklarer»-knappen, vil to navnerom dukke opp ettersom vi har to URI-er. En av dem er skjemaet. URL og den andre tilsvarer den faktiske webtjenesten URLVi må bruke det faktiske navnerommet der webtjenesten befinner seg, og IKKE skjemanavnerommet, når vi refererer til XPath. De deklarerte linjene vises øverst i XPath-boksen, som vist nedenfor.

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-en til XML-noden 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 tillagte påstanden i SoapUI vil bli vist som vist nedenfor.

Skriptpåstander

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

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

• Skripting lar brukeren utføre visse operasjoner før og etter utførelse av en testtilfelle ved hjelp av henholdsvis oppsett- og nedbrytningsmetoder. Oppsett er en prosedyre som utføres før en bestemt metode utføres (f.eks. objektoppretting og initialisering), mens nedbrytning er en prosedyre som utføres etter at metoden er utført (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 åpne/lukke 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.
• Skriptingpåstander brukes til å opprette brukerdefinerte påstander som IKKE er forhåndsdefinerte av SoapUI.

For å demonstrere en skriptpåstand i SoapUI, vil vi bruke kalkulatoren WSDL, testtilfellet 'Add' som vi opprettet tidligere.

Trinn 1: Fremgangsmåten for å legge til groovy-skript er den samme som for andre påstander, bortsett fra at påstanden ikke er forhåndsdefinert. I stedet er det en brukerdefinert påstand som tilbyr 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 Skriptpåstand, og det er ingen undertyper tilknyttet den.
3. Klikk "Legg til".

Trinn 3: Skriptdialogboksen åpnes, der brukeren kan skrive et brukerdefinert skript for å validere svar-XML-en.

Trinn 4: La oss nå skrive et kult 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 testsuiten med statusen for hver av disse.

Trinn 6: Nå

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

XQuery-samsvarspåstand

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 SoapUILa oss importere en annen WSDL som vist nedenfor: http://www.webservicex.net/medicareSupplier.asmx?WSDL

OBS: De offentlige webservicex.net-demoendepunktene som brukes i denne gjennomgangen er ikke lenger pålitelig tilgjengelige, så skjermbildene for forespørsler og svar nedenfor beholdes som referanseeksempel. Enhver WSDL som returnerer et gjentakende nodesett, vil utøve XQuery-deklarasjonen på nøyaktig samme måte.

Trinn 1: Høyreklikk på det eksisterende prosjektet og velg «Legg til WSDL».

Trinn 2: Dialogboksen Legg til WSDL åpnes. La andre alternativer være som standard og klikk på «OK»-knappen.

Trinn 3: Alle operasjonene er listet opp 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å testtilfellet og klikk på «OK»-knappen

Trinn 6: Testtilfellet opprettes som vist nedenfor.

Trinn 7: Legg til et nytt testtrinn av typen «SOAP Test Request» som vist nedenfor.

Trinn 8: Skriv inn navnet på testtrinnet. La oss si – Leverandør_etter_by, som ville vært mer meningsfullt. Klikk på «OK».

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

Trinn 10: Skriv inn navnet på testtilfellet og klikk på «OK».

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

Trinn 12: La oss nå finne all leverandørinformasjon for byen «New York».

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

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

<City>New York</City>

</GetSupplierByCity>

WSDL nedenfor URL – 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ørnumrene. Vi kan ikke bruke XPath-påstander, siden vi trenger hundrevis av XPath-påstander. Derfor er bruk 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-assersjon må vi deklarere navnerommet.

1. Klikk på «Erklær»-knappen for å tillate automatisk SoapUI for å deklarere navnerommet. Når du klikker på deklareringsknappen, vil et «POP-vindu» med meldingen «deklarer navnerommet fra skjemaet i stedet» vises for brukeren. Klikk på «Ja» for å fortsette som vist nedenfor.
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. Når du klikker på «Velg fra gjeldende», vises alle leverandørnumrene.
5. Klikk "Lagre".

Merk: Når du trykker på «Deklarer»-knappen, kan du ende opp med forskjellige URL's som navneområdedeklarasjon, er det imidlertid den faktiske navneplasseringen for webtjenesten som vil bli vurdert for koding.

Det ferdige XQuery-uttrykket, med navneromsdeklarasjonene, ser slik ut.

// 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-påstanden utføres og viser det endelige resultatet i «Påstand»-panelet som vist nedenfor. Nå har vi lagt til en XQuery-påstand som vi bruker for å validere all leverandørnummerinformasjon. Den samme vil bli sammenlignet med faktiske verdier 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?

Med både pek-og-klikk- og de skriptede alternativene dekket, er det praktiske spørsmålet hvilken man skal strekke seg etter.

• 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.

Alternativ	Tekniske beskrivelser
	Den valgte påstanden flytter opp i rekkefølgen.
	Den valgte påstanden flytter ned i rekkefølgen.
	Fjerner den valgte påstanden
	Konfigurer/rediger den valgte påstanden på nytt.

Nedenfor er funksjonene som er eksklusivt tilgjengelige i Pro-versjonen av SoapUI, nå sendt som ReadyAPIPro-versjonen hjelper oss også med å gruppere påstander, slik at vi kan legge til et ekstra lag med validering til de opprettede påstandene.

• OG: Alle påstander evalueres som GYLDIG påstand, noe som vil resultere i gruppebetingelsen BESTÅTT.
• ELLER: Minst én av påstandene i gruppen må være GYLDIG for å kunne hevde en gruppebetingelse BESTÅTT.
• Pro-versjonen tillater også Kloning av påstanderDette 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 deg deaktivere eller aktivere grupperte eller ugrupperte påstander. Hvis en påstand er deaktivert, er den nedtonet, og når en testtilfelle kjøres, vil ikke deaktiverte påstander bli utført.
• Opphev gruppering av påstander: Alle grupperte påstander kan oppheves hvis testerne bestemmer seg for å gjøre det.

Komplett liste over metoder tilgjengelig i ulike påstandstyper

Tabellen nedenfor samler alle påstandene som er omtalt ovenfor, gruppert etter kategorien de vises under i dialogboksen Legg til påstand.

LAST NED SOAPUI-PROSJEKTET SOM INNEHOLDER OVENFOR PÅSTAND

Vanlige feil og feilsøking

De fleste påstandsfeil trace tilbake til et lite sett med feil, så sjekk disse før du skriver et uttrykk om.

• Bruk riktig navneområde. Navneområdet skal være URL hvor webtjenesten befinner seg.
• Hvis det oppstår en feil under utviklingping en skriptpåstand, bruk 'log.info' til å skrive ut innholdet i variablene.
• Hvis du ikke har den ønskede utgangen, kontroller om en gyldig inngang er sendt i forespørselen.

Hvis du for eksempel i valutakalkulatoren skriver inn 'intA' som 'x', som ikke er et heltall, vil utdataene gi en feilkode som 'SOAP-Client', som betyr at problemet er med parameteren som sendes fra klientsiden. Forespørselen som inneholder den ugyldige verdien vises først.

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

Sørg for at du bruker riktig syntaks når du bruker XPath- og XQuery-deklarasjoner. Du bør IKKE bruke punktum(.) i stedet for kolon(:) når du bruker deklarasjonen ovenfor. Syntaksen er //navnerom:Tagnavn og IKKE //navnerom.tagnavn. Ved å gjøre det kan du ende opp med en melding som sier «INGEN treff i gjeldende svar» selv om tagnavnet er riktig.

Spørsmål og svar