Påståenden i SoapUISkript, XQuery, XPath-typer

Vad är ett påstående?

Påstående betyder handling att bekräfta eller påstå något. Det kan också tolkas som en kontrollpunkt eller en valideringspunkt.

När en begäran skickas till en webbserver tas ett svar emot. Vi måste validera om svaret innehåller de data vi förväntar oss. För att validera svaret behöver vi använda påståenden. Utan ett påstående bevisar ett teststeg bara att tjänsten svarade, inte att den svarade korrekt, vilket är anledningen till att varje API-test bör bära minst en.

Typer av påstående

Det finns olika sätt att formulera ett svar, men vi kommer att fokusera på de vanligaste sätten. SoapUI påståendetyper vid validering av ett svar. Nedan följer de kategorier som är tillgängliga i Open Source-versionen av SoapUI.

1. Fastighetsinnehåll
2. Överensstämmelsestatusstandard
3. Script
4. SLA
5. Etc
6. Säkerhet

Dialogrutan grupperar varje påstående under dessa kategorier, som skärmdumpen nedan visar.

Förutom de som listas ovan har Pro-versionen även en inbyggd JDBC-assertion med vilken vi kan avgöra om webbtjänsten har uppdaterat databasen korrekt.

Versionsnotering: ström SoapUI dokumentationen listar också en JDBC kategori (JDBC-status och JDBC-timeout) bredvid kategorierna ovan, och en Meddelandeinnehåll påstående i egenskapsinnehåll för rikare XML-jämförelse. Den kommersiella utgåvan som här kallas "Pro" säljs nu som ReadyAPI av SmartBear, så menyetiketter i nyare versioner kan läsas annorlunda medan assertionbeteendet förblir detsamma.

Innehåller påstående

Söker efter förekomsten av den angivna strängen. Det stöder också reguljärt uttryck.

Vi kommer att fortsätta med samma exempel från föregående handledning med WSDL-förfrågan som http://www.dneonline.com/calculator.asmxOm du inte har byggt det projektet än, arbeta dig igenom skapa ett projekt, en testsvit och ett testfall först.

Steg 1: Som standard finns det inga påståenden.

1. Antalet påståenden visas på fliken påståenden.
2. För att lägga till ett nytt påstående, klicka på knappen "Lägg till nytt påstående".

Steg 2: Nu,

1. Välj påståendekategori.
2. Välj påståendetyp.
3. Klicka på "Lägg till"

Steg 3: Låt oss kontrollera om strängen '46' finns i svaret. Klicka på 'OK'

Obs: Vi kan också ignorera skiftläge och lägga till reguljärt uttryck.

Steg 4: När den läggs till körs assertionen omedelbart och visar om den är GILTIG eller OGILTIG.

Steg 5: Låt oss nu säga att vi ändrar innehållet i 'Innehåller påstående i SoapUI' till '47' och se vad som händer.

Steg 6: Assertionen körs och resultatet skickas till användaren. Eftersom vi inte har strängen '47' i svaret har assertionen misslyckats.

Innehåller inte påstående

Dess motsvarighet fungerar tvärtom. Söker efter att den angivna strängen inte existerar. Den stöder även reguljära uttryck.

Steg 1: Efter att ha klickat på knappen "Lägg till nya påståenden",

1. Välj påståendekategori.
2. Välj påståendetyp – I det här fallet "Intehåller"
3. Klicka på "Lägg till"

Steg 2: Låt oss validera om strängen 'intA' finns i svaret. Ange strängen 'FromCurrency' och klicka på 'OK'.

Steg 3: Så snart en assertion läggs till körs den och visar resultatet. Hittills har vi lagt till två assertions, så båda assertions körs och visar resultatet.

Steg 4: Nu ska vi ändra innehållet i 'Not Contains Assertion' och se vad som händer. Vi ska kontrollera om strängen "AddResult" inte finns.

Steg 5: Strängen 'AddResult' finns faktiskt i svaret, därför kommer 'NOT Contains'-kontrollen att misslyckas enligt nedan.

XPath Match Assertion

Strängmatchning är trubbig, så nästa assertion riktar sig istället mot en enda nod. Använder XPath-uttryck för att välja målnoden och dess värden. XPath, är ett XML-frågespråk för att välja noder från ett XML-dokument.

Steg 1: Efter att ha klickat på knappen "Lägg till nya påståenden",

1. Välj påståendekategori.
2. Välj påståendetyp – i det här fallet 'XPath Match'
3. Klicka på "Lägg till"

Steg 2: Fönstret Lägg till XPath öppnas.

Innan du lägger till en SoapUI XPath, vi måste deklarera namnrymden. Ett XML-namnrymd är en samling namn, identifierade av en URI-referens (Uniform Resource Identifier), som används i XML-dokument som element- och attributnamn. Detsamma används i SoapUI XPath-påstående.

För att deklarera ett XML-namnrymd behöver vi bara klicka på knappen "Deklarera" vilket skulle göra jobbet åt oss, annars kan vi också manuellt deklarera ett namnrymd själva.

Efter att ha deklarerat namnrymden måste vi referera XPath med hjälp av det skapade namnrymden.

När du klickar på knappen "Deklarera" dyker två namnrymder upp eftersom vi har två URI:er. En av dem är schemat. URL och den andra motsvarar den faktiska webbtjänsten URLVi behöver använda det faktiska namnutrymmet där webbtjänsten finns och INTE schemanamnutrymmet när vi refererar till XPath. De deklarerade raderna visas högst upp i XPath-rutan som visas nedan.

deklarera namnutrymme soap='http://schemas.xmlsoap.org/soap/envelope/';

deklarera namnutrymme ns1='http://tempuri.org/';

Steg 3: Nu behöver vi ange XPath för XML-noden som vi behöver validera.

//ns1:AddResult Ger oss värdet på noden som är innesluten mellan & och ns1 motsvarar det deklarerade namnutrymmet som pekar på 'http://tempuri.org/'

Efter att ha angett XML måste vi klicka på "Välj från aktuell" så att värdet från det aktuella svaret kan plockas upp för jämförelse framöver.

Steg 4: Hittills,

1. Efter att ha deklarerat namnområdena har vi angett XPath of XML-noden som vi behöver validera.
2. Vi måste klicka på "Välj från aktuell" för att göra det aktuella värdet som förväntat värde.
3. Det aktuella värdet visas för användaren som vi kan ändra vid behov.
4. Klicka på "Spara".

Steg 5: Det tillagda påståendet i SoapUI kommer att visas enligt nedan.

Skriptpåståenden

Denna påståendeteknik är den mest använda eftersom det är extremt svårt att hantera och underhålla hundratals påståenden.

SoapUI använder antingen Groovy Skript eller JavaScript för skriptbaserade påståenden. Skripttekniken används för utvecklingping ett ramverk för testning av SOAP. Skriptbaserade påståenden används under följande omständigheter.

• Skript tillåter användaren att utföra vissa operationer före och efter att ha kört ett testfall med hjälp av metoderna "set up" respektive "tear down". "Set up" är en procedur som körs innan en viss metod körs (exempel - objektskapande och initialisering) medan "tear down" är en procedur som körs efter att metoden körts (t.ex.: förstöra objekt och rensa upp). Denna funktion är inte tillgänglig i andra assertionstyper och kan endast göras genom kodning.
• Det låter användare öppna/stänga ett projekt för att initiera eller rensa projektrelaterade inställningar och även arbeta med miljövariabler vilket är mycket användbart under skriptning.
• Det hjälper oss att hävda ett dynamiskt svarsinnehåll.
• Skriptpåståenden används för att skapa användardefinierade påståenden som INTE är fördefinierade av SoapUI.

För att demonstrera ett skriptpåstående i SoapUI, vi kommer att använda kalkylatorn WSDL, testfallet 'Add' som vi skapade tidigare.

Steg 1: Stegen för att lägga till groovy-skript är desamma som för andra assertioner, förutom att assertionen inte är fördefinierad. Istället är det en användardefinierad assertion som erbjuder större flexibilitet än de inbyggda.

Välj det teststeg mot vilket påståendet ska läggas till.

Klicka på knappen "Lägg till påstående" som visas nedan.

Steg 2: Välj nu kategorin Påstående.

1. I det här fallet är det Script.
2. Välja SoapUI Skriptpåstående och det finns inga undertyper associerade med det.
3. Klicka på "Lägg till".

Steg 3: Skriptdialogrutan öppnas där användaren kan skriva ett användardefinierat skript för att validera svars-XML:en.

Steg 4: Nu ska vi skriva ett smart skript för att validera konverteringsfrekvensen. Skriptet bifogas nedan med inbäddade kommentarer. Det rekommenderas att ha kunskap om Java Manus eller Groovy Skripta innan du försöker skriva 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. Klicka på "Execute"-knappen för att utlösa exekveringen.
2. Utdata från skriptet visas i rutan Utdata. Den har skrivit ut både konverteringsvärde och slutresultatet (Godkänd eller Underkänd)
3. Informationen visas att "Script Assertion Passed". Klicka på OK.

Obs: Den slutliga informations-popupen kommer alltid att visas med meddelandet "Script Assertion Passed" så länge som skriptet är syntaktisk korrekt. Det har inget samband med ditt påstående i manuset.

klicka på OK

Steg 5: Nu visar fliken Påståenden alla påståenden som vi har lagt till för den här testsviten med status för var och en av dem.

Steg 6: Nu

1. Välj Test Suite från Navigator-trädet
2. Klicka på knappen "Kör".
3. Resultaten skulle visas för hela testsviten.

XQuery Match-påstående

Den använder ett XQuery-uttryck för att välja innehåll från målegenskapen. Vi behöver en mycket större svars-XML för att bättre förstå XQuery-påståendet i SoapUILåt oss importera ytterligare en WSDL enligt nedan: http://www.webservicex.net/medicareSupplier.asmx?WSDL

Obs: De publika webservicex.net-demoslutpunkterna som används i den här genomgången är inte längre tillförlitligt nåbara, så skärmdumparna för begäran och svar nedan behålls som referensexempel. Alla WSDL som returnerar en upprepande noduppsättning kommer att utöva XQuery-assertionen på exakt samma sätt.

Steg 1: Högerklicka på det befintliga projektet och välj "Lägg till WSDL".

Steg 2: Dialogrutan Lägg till WSDL öppnas. Lämna andra alternativ som standard och klicka på "OK".

Steg 3: Alla operationer listas enligt nedan.

Steg 4: Nu lägger vi till en Testfall inom samma testsvit som vi hade skapat för Testning valutaomvandlaren.

Steg 5: Ange namnet på testfallet och klicka på "OK"-knappen

Steg 6: Testfallet skapas enligt nedan.

Steg 7: Lägg till ett nytt teststeg av typen 'Soap Test Request' enligt nedan.

Steg 8: Ange namnet på teststeget. Låt oss säga – Leverantör_efter_Stad, vilket skulle vara mer betydligt. Klicka på 'OK'.

Steg 9: Välj Operasom vi skulle vilja validera. I det här fallet är det 'MedicareSupplierSoap -> GetSupplierByCity'. Klicka på 'OK'.

Steg 10: Ange namnet på testfallet och klicka på "OK".

Steg 11: Begäran i XML-format visas enligt nedan.

Steg 12: Nu ska vi hitta all leverantörsinformation för 'New York'.

För att göra det, lägg till följande rader i din kod.

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

<City>New York</City>

</GetSupplierByCity>

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

Steg 13: När testet har utförts får vi svaret nedan

Steg 14: Låt oss säga att vi behöver validera alla leverantörsnummer. Vi kan inte använda XPath-assertioner eftersom vi behöver hundratals XPath-assertioner. Därför är användningen av XQuery oundviklig i det här fallet.

XQuery Assertion hjälper oss att validera en grupp av XML-svar som är repetitiva till sin natur.

Steg 15: Klicka nu på "Lägg till ett påstående",

1. Välj "Assertion Category" – Egendomsinnehåll i det här fallet.
2. Välj påståendetyp som "XQuery Assertion"
3. Klicka på "Lägg till".

Steg 16: I likhet med XPath-assertion måste vi deklarera namnrymden.

1. Klicka på knappen "Deklarera" för att automatiskt tillåta SoapUI för att deklarera namnrymden. När du klickar på deklareringsknappen visas ett popup-fönster med meddelandet "deklarera namnrymden från schemat istället" för användaren. Klicka på "Ja" för att fortsätta enligt nedan.
2. För att hämta alla leverantörsnummer måste vi skriva en XPath-fråga och vi placerar den inom < SupplierNumber> och Taggar.
3. Klicka på "Välj från den aktuella" som kommer att köras från det aktuella svaret.
4. När du klickar på "Välj från aktuell lista" visas alla leverantörsnummer.
5. Klicka på "Spara".

Obs: När du trycker på knappen "Deklarera" kan du få olika resultat. URLs som namnrymdsdeklaration, men det är den faktiska namnrymden för webbtjänstens plats som skulle beaktas för kodning.

Det färdiga XQuery-uttrycket, med dess namnrymdsdeklarationer, ser ut så här.

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

Steg 17: XQuery-assertionen körs och visar det slutliga resultatet i panelen 'Assertion' som visas nedan. Nu har vi lagt till en XQuery-assertion med vilken vi har validerat all leverantörsnummerinformation. Densamma jämförs med de faktiska siffrorna varje gång begäran skickas till webbservern.

Obs: De faktiska värdena kommer inte att visas. Om alla faktiska värden är desamma som de förväntade värdena, visar den GILTIGT annars visas "Failed".

När ska man använda inbyggd påstående?

Med både peka-och-klicka- och de skriptade alternativen täckta är den praktiska frågan vilken man ska välja.

• När ett svar är kort så att det kan valideras med en av dessa inbyggda påståenden.
• Vi kan också använda Inbuilt Assertion om svaret som skickas från webbservern alltid är statiskt till sin natur. Om det är dynamiskt kommer vi inte att kunna hävda det med inbyggda påståenden.
• När användning av inbyggda påståenden som Time-out-påståenden och säkerhetspåståenden blir oundviklig.
• Inbyggda påståenden håller ganska bra för engångsanvändning där tester inte behöver upprepas.

Påstående alternativ

De skapade påståendena kan bäst kontrolleras med hjälp av kontrollpanelen som är markerad nedan.

De skapade påståendena tillåter testare att konfigurera följande saker från påståendens verktygslådan.

Alternativet	BESKRIVNING
	Det valda påståendet flyttar uppåt i ordningen.
	Det valda påståendet flyttas ner i ordningen.
	Tar bort det valda påståendet
	Konfigurera om/redigera det valda påståendet.

Nedan följer funktionerna som exklusivt finns i Pro-versionen av SoapUI, nu levererad som ReadyAPIPro-versionen hjälper oss också att gruppera påståenden så att vi kan lägga till ytterligare ett lager av validering till de skapade påståendena.

• OCH: Alla påståenden utvärderas som GILTIGA påståenden vilket resulterar i gruppvillkoret GODKÄNT.
• ELLER: Minst ett av påståendena inom gruppen måste vara GILTIG för att ett gruppvillkor GODKÄNT ska kunna hävdas.
• Pro-versionen tillåter också Kloning av påståendenDet här alternativet låter testare kopiera ett påstående till ett annat teststeg i samma eller ett annat projekt.
• Inaktivera/Aktivera påståenden: Det här alternativet gör att alla grupperade eller ogrupperade påståenden kan inaktiveras eller aktiveras. Om ett påstående är inaktiverat är det nedtonat och när ett testfall körs kommer inaktiverade påståenden inte att köras.
• Dela upp påståenden: Alla grupperade påståenden kan delas upp om testare väljer att göra det.

Komplett lista över metoder tillgängliga i olika påståendetyper

Tabellen nedan samlar alla påståenden som diskuterats ovan, grupperade efter den kategori de visas under i dialogrutan Lägg till påstående.

LADDA NED SOAPUI-PROJEKTET SOM INNEHÅLLER Ovanstående påståenden

Vanliga fel och felsökning

De flesta påståenden som misslyckades trace tillbaka till en liten uppsättning misstag, så kontrollera dessa innan du skriver om ett uttryck.

• Använd rätt namnrymd. Namnrymden ska vara URL var webbtjänsten finns.
• Om ett fel uppstår under utvecklingping en skriptpåstående, använd 'log.info' för att skriva ut innehållet i variablerna.
• Om du inte har den önskade utgången, kontrollera om en giltig inmatning har skickats i begäran.

Om du till exempel i valutaomvandlaren matar in 'intA' som 'x', vilket inte är ett heltal, genererar utdata felkoden 'SOAP-Client', vilket betyder att problemet ligger i parametern som skickas från klientsidan. Begäran som innehåller det ogiltiga värdet visas först.

Svaret returnerar felkoden istället för ett resultat, som visas nedan.

Se till att du använder rätt syntax när du använder XPath- och XQuery-assertioner. Du bör INTE använda punkt(.) istället för kolon(:) när du använder ovanstående assertion. Syntaxen är //namnrymd:Tagnamn och INTE //namnrymd.tagnamn. Om du gör det kan du få meddelandet "INGEN matchning i aktuellt svar" trots att taggnamnet är korrekt.

Vanliga frågor