• Articles
• admin

i de to foregående artikler dækkede vi detaljerne i Testspecifikke påstande, som kun var gældende for en bestemt type TestCase eller hjemmesideservice under test. Alle de påstande, der er nævnt i artiklen “SoapUI Test specifikke påstande: REST-tjenester” gælder kun for REST-tjenester, og alle de påstande, der er nævnt i artiklen “SoapUI Test specifikke påstande: SOAP-tjenester” gælder kun for SOAP-tjenester. Nu, SoapUI giver få andre påstande også, som er gældende for både sæbe og hvile tjenester og er kendt som SoapUI fælles påstande. I denne artikel forstår vi brugen af alle disse almindelige påstande ved at dække detaljerne under følgende emner:

• Hvad er de fælles ejendom indhold påstande i SoapUI?
  • Hvad er Indeholder påstand i SoapUI?
  • derudover, hvad der ikke indeholder påstand i SoapUI?
  • Hvad er en påstand i SoapUI?
  • Hvad er Match Assertionin SoapUI?
• tilsvarende, hvad er de fælles overholdelse, Status, og Standard påstande i SoapUI?
  • Hvad er HTTP statuskoder påstande fra SoapUI?
  • derudover, hvad er Schema Compliance påstande i SoapUI?
• Hvad er de fælles SLA påstande i SoapUI?

da alle disse påstande gælder for både SOAP-og REST-tjenester, bruger vi følgende oplysninger til validering af alle disse påstande:

• REST-projektet oprettet ved hjælp af URI: “http://bookstore.toolsqa.com/BookStore/v1/Books “og SOAP-projektet oprettet ved hjælp af VSDL:” http://bookstore.toolsqa.com/BookStoreService.wsdl “i henhold til detaljerne nævnt i artiklen” SoapUI: arbejde med projekter.”
• du kan henvise til prøveudgangen fra REST-projektet fra artiklen” SoapUI Test Specific Assertions: REST Services “og prøveudgangen fra SOAP-projektet fra artiklen”SoapUI Test Specific Assertions: SOAP Services”.

Hvad er de fælles ejendom indhold påstande i SoapUI?

som vi allerede ved, validerer Ejendomsindholdets påstande indholdet af det modtagne svar. SoapUI giver flere indhold påstande, der gælder for både sæbe og hvile anmodninger. Lad os se i afsnittene nedenfor, hvordan vi kan bruge disse påstande?

Hvad er Indeholder påstand i SoapUI?

den indeholder påstand søger efter eksistensen af en streng token i egenskabsværdien.

overvej et scenario, der i boghandel Service, er vi nødt til at kontrollere, om en bog med forfatterens navn “Richard E. Silverman” eksisterer?Lad os følge nedenstående trin for at validere det samme ved hjælp af” Indeholder ” påstand:

1. Naviger først til dialogboksen Tilføj påstand. Klik derefter på påstanden” indeholder “under kategorien” Ejendomsindhold”, som fremhævet nedenfor:

1. for det andet skal du klikke på knappen “Tilføj”, og den viser dialogboksen “indeholder påstand”, som vist nedenfor:

1. for det tredje skal du indtaste navnet på forfatteren “Richard E. Silverman” i afsnittet “Indhold”. Det er den søgestreng, du vil validere som svar på hjemmesidens service.

2. for det fjerde vil du i ovenstående dialogboks også se to afkrydsningsfelter. De er:

• Ignorer sag: hvis du markerer afkrydsningsfeltet Ignorer sag, validerer den strengen ved at ignorere sagen. Antag, at du skriver “richARD E. SilVerMan” i tekstfeltet indhold og markerer afkrydsningsfeltet “Ignorer sag i sammenligning”. Derudover vil den ignorere sagen og vil kun kontrollere for værdien af den indtastede streng.

så påstanden vil passere, da tegnene i strengen er de samme, hvis vi ignorerer sagen.

• Regulært udtryk: hvis du vil validere output baseret på et Regeks, kan du markere dette afkrydsningsfelt og derefter angive dit regulære udtryk i afsnittet Indhold. SoapUI følger de regulære udtryksmønstre, der er specificeret af Oracle, hvis vi for eksempel vil validere, at bogtjenestesvaret indeholder “O ‘ Reilly” i svaret, kan du specificere “.O ‘ Reilly.”som en Regeks i indholdsafsnittet, som vist nedenfor:

så vi kan validere eksistensen af en streng i svar fra hjemmesiden ved at bruge indeholder påstand, og vi kan bruge dette til både sæbe og hvile hjemmesider.

Hvad er ikke indeholder påstand i SoapUI?

i modsætning til indeholder påstand, den ikke indeholder påstand søger efter manglende eksistens af en streng i egenskabsværdien. Desuden vil denne påstand passere, hvis svaret ikke indeholder den angivne værdi.

lad os antage; vi ønsker at validere, at der ikke er nogen bog med titlen “Groovy Book” i svaret fra book store-tjenesten, vi kan bruge denne påstand til at validere svaret fra BookStore API.

lad os følge nedenstående trin for at validere det samme ved hjælp af” ikke indeholder “påstand:

1. for det første skal du navigere for at tilføje Assertion dialog boks og klik på” ikke indeholder “påstand under kategorien” Property Content ” assertion, som fremhævet nedenfor:

1. for det andet skal du klikke på knappen “Tilføj”, og den vil vise dialogboksen “NotContains Assertion”, som vist nedenfor:

2. for det tredje skal du indtaste navnet på strengen “Groo Book” i afsnittet “Indhold”. Det er den søgestreng, du vil validere, der ikke findes i svaret fra hjemmesiden.

Bemærk: de to afkrydsningsfelter(Ignorer sag & Regeks) fungerer her på samme måde, som de var med påstanden indeholder.

1. for det fjerde vil klik på “OK” – knappen udføre påstanden mod Hjemmesideservicesvaret og vise resultatet som vist nedenfor:

1. så længe strengen ikke er til stede i måltjenestens svar, vil påstanden passere.

Hvad er det?

kravet om Match giver dig mulighed for at bruge et udtryk til at vælge indholdet fra målresponsens specifikke node og sammenligne det med den værdi, du forventer.

Antag, at du vil validere, at ISBN i den første bog, der er til stede i svaret fra BookStore API, ikke er null. Vi kan hurtigt validere det samme ved hjælp af Ksv-påstanden.

lad os følge nedenstående trin for at validere det samme ved hjælp af “path Match” påstand:

1. for det første skal du navigere for at tilføje Assertion dialogboks. Klik derefter på påstanden “Property Content” under kategorien “Property Content”, som fremhævet nedenfor:

1. for det andet skal du klikke på knappen” Tilføj”, og den viser dialogboksen “Matchkonfiguration” som vist nedenfor:

hvor,

• erklære: ved at klikke på denne knap hentes og udfyldes navneområdet automatisk. Hvis du er sikker på detaljerne i navneområdet, kan du skrive det manuelt, ellers skal du bare klikke på knappen “erklære”, og det udfylder navneområdets detaljer som vist nedenfor:

  • navneområdet for SOAP-tjenesten vil blive befolket, som vist nedenfor:

• tilsvarende, navneområdet for REST-tjenesten vil blive befolket, som vist nedenfor:

når du har erklæret navneområdet, kan vi angive stien til den ønskede node i afsnittet.sti-udtryk.

• du kan angive en prøvesti “//ns1:Booksresultat/ns1:Books/ns1:CustomBookModel/ns1:Isbn” til SÆBETJENESTEN som vist nedenfor:

Tilsvarende kan du angive en prøvevej “//ns1:books//ns1:e/ns1:isbn” for RESTTJENESTEN som vist nedenfor:

Bemærk brugen af navneområde ns1 i begge tilfælde. For at få adgang til noderne er brug af navneområdet obligatorisk.

• vælg fra current: ved at klikke på denne knap vælger den automatisk værdien af noden som nævnt ovenfor i afsnittet forventet resultat, hvilket er isbn i ovenstående tilfælde. Derudover vælger den værdien af node isbn som “9781449325862”. Hvis du ikke ønsker at auto-vælge værdien ved at klikke på denne knap, kan du endda skrive det forventede resultat manuelt også.
• Test: ved at klikke på knappen” Test ” kan du teste output, hvis påstanden passerer, vil den vise nedenstående succesalarm :

eller hvis påstanden mislykkes, kaster den fejl og viser en dialogboks, som vist nedenfor:

• valgfri afkrydsningsfelter: afsnittet forventet resultat indeholder også nogle afkrydsningsfelter, som giver yderligere hjælp til validering af påstanden. Lad os forstå detaljerne i disse afkrydsningsfelter:
• Tillad jokertegn afkrydsningsfelt: hvis den værdi, vi vil validere, ændres dynamisk i målresponsen, kan vi bruge jokertegn til at validere svaret. Antag, at hvis vi overvejer, at isbn i 1.bog altid slutter med “862”, så kan vi bruge jokertegnet *”862″, som vil validere, at isbn altid slutter med “862”. Det vises i afsnittet forventet resultat som:

• Ignorer afkrydsningsfeltet navneområde præfiks: Hvis vi vil ignorere navneområdets præfiks, mens vi validerer svaret, kan vi gøre det ved at markere dette afkrydsningsfelt.
• hvis vi vil ignorere kommentarerne i svaret, kan vi opnå dette ved at markere dette afkrydsningsfelt.
• når du har udforsket alle ovenstående muligheder, skal du klikke på knappen Gem for at gemme påstanden. Det skal passere som påstanden og vil få det forventede Isbn som “9781449325862”. Derfor vil det vise prøveudgangen som følger:

Hvad er SoapUI?

kampen er meget lig påstanden, med den eneste forskel, at den bruger et udtryk og sammenligner det med det resultat, du forventer.

overvej et scenarie Antag, at du vil validere alle “titler” på de bøger, der er tilgængelige i svaret, uanset i hvilken rækkefølge de findes. Du kan skrive et simpelt spørgsmål, og så er du god til at gå.

lad os følge nedenstående trin for at validere det samme ved hjælp af “:

1. Naviger først til dialogboksen Tilføj påstand. Klik derefter på påstanden” testkamp “under kategorien” Ejendomsindhold”, som fremhævet nedenfor:

1. for det andet skal du klikke på knappen” Tilføj”, og den viser dialogboksen “konfiguration af Match”, som vist nedenfor:

hvor,

• dette er det udtryk, du skal angive for at udtrække værdien fra svar fra hjemmesiden. For eksempel for at få titlen på alle bøgerne, kan vi angive udtrykket som følger:

<Result>{for$z in //*:CustomBookModelreturn (<Title>{data($z/*:Title)}</Title>)}</Result>

i ovenstående kodestykke:

• <Result> er det tag, der gemmer resultatet baseret på Forespørgselsresponset. Desuden kan det være ethvert tag baseret på brugerens valg.
• derudover gentager vi svaret ved hjælp af for-sløjfen, og $Å er en hvilken som helst variabel, som får værdien fra <CustomBookModel>.
• //. angiver roden til Custombookmodellen, du kan også navigere ved hjælp af navneområde og derefter angive navneområdet i stedet for **”//.”.***
• ud over ovenstående returnerer funktionen “return” værdien af <Title> tagget.
• funktionen “data” returnerer også dataene for hvert titeltag i tagget <CustomBookModel>.

2) Vælg fra nuværende: Klik på knappen for at vælge den aktuelle værdi fra svaret i henhold til det nævnte spørgsmål.

3) forventet resultat: når du har klikket på knappen “Vælg fra nuværende”, returnerer den alle titlerne fra tjenestens svar. Du kan også angive det forventede resultat manuelt.

4) ved at klikke på knappen” Test “vises succesresponsen som vist nedenfor:

1. ved at klikke på knappen” OK ” vises den gyldige udførelse af påstanden.

hvad er den fælles overholdelse, Status og Standard påstande i SoapUI?

ligesom de almindelige påstande, der leveres af SoapUI under afsnittet “Ejendomsindhold”, giver det også nogle påstande under kategorien “overholdelse, Status og Standard” påstande, som er almindelige for både SOAP-og REST-tjenester. Lad os forstå detaljerne i alle disse påstande i de følgende afsnit:

Hvad er http-statuskoder påstande fra SoapUI?

som vi alle ved, repræsenterer HTTP-Statuskoderne, om en HTTP-anmodning er afsluttet eller ej. Alle disse responskoder opdeles generelt i følgende kategorier:

1	1: Information: disse statuskoder repræsenterer modtagelsen af anmodningen og dens behandling.
2	2: succes: disse statuskoder repræsenterer, at handlingen blev modtaget, behandlet og accepteret.
3	3: omdirigering: disse statuskoder repræsenterer, at der er yderligere handling, der kræves for at fuldføre anmodningen.
4	4: klientfejl: disse statuskoder repræsenterer, at anmodningen indeholder forkert syntaks, eller at der er noget galt med vores anmodning.
5	5: serverfejl: disse statuskoder repræsenterer, at der er en Server-side-fejl, hvilket betyder, at serveren ikke opfyldte en gyldig anmodning.

til validering af disse statuskoder giver SoapUI et par påstande. Lad os forstå detaljerne i disse påstande i de følgende afsnit:

Hvad er en gyldig HTTP statuskoder påstand i SoapUI?

denne påstand bekræfter, at HTTP-svarkoden, der returneres af Hjemmesidetjenesten, ligger på listen over forventede HTTP-koder.

overvej et scenario, at vi for BookStore API ønsker at validere, at den returnerede svarkode altid er enten 200 eller 201. Vi kan bruge påstanden “gyldige HTTP-statuskoder” til at validere det samme.

lad os følge nedenstående trin for at validere det samme ved hjælp af” gyldige HTTP-statuskoder ” påstand:

1. Naviger for at tilføje Assertion dialog boks og klik på” gyldige HTTP statuskoder “påstand under” Compliance, Status og Standard “assertion kategori, som fremhævet nedenfor:

1. Klik på knappen” Tilføj”, og den viser dialogboksen “gyldig HTTP-statuskoder Assertion Configuration”, som vist nedenfor:

1. i afsnittet” Angiv koder ” skal du sætte værdier 200, 201. Du kan angive enten en enkelt kode eller en liste over kommaseparerede koder. Ved at klikke på knappen” OK ” valideres HTTP-statuskoderne mod det sidste svar fra tjenesten.

Hvad er en ugyldig HTTP-statuskoder påstand i SoapUI?

i modsætning til påstanden “gyldige HTTP-statuskoder” validerer påstanden “ugyldige HTTP-statuskoder”, at listen “forventede koder” ikke indeholder HTTP-statuskoden, der returneres af hjemmesiden.

overvej et scenario, at vi for BookStore API ønsker at validere, at den returnerede svarkode ikke er 401. Vi kan bruge påstanden “ugyldige HTTP-statuskoder” til at validere det samme.

lad os følge nedenstående trin for at validere det samme ved hjælp af” ugyldige HTTP-statuskoder ” påstand:

1. Naviger for at tilføje Assertion dialog boks og klik på” ugyldige HTTP statuskoder “påstand under” Compliance, Status og Standard “påstand kategori, som fremhævet nedenfor:

1. Klik på knappen” Tilføj”, og den vil vise dialogboksen “ugyldig HTTP status codes Assertion Configuration”, som vist nedenfor:

1. i afsnittet” Angiv koder ” skal du sætte værdier 401. Du kan angive enten en enkelt kode eller en liste over kommaseparerede koder. Ved at klikke på knappen” OK ” valideres ikke-eksistensen af HTTP-statuskoder mod det sidste svar fra tjenesten.

Bemærk: Vi kan anvende disse påstande på både SOAP og REST endpoints.

Hvad er Schema Compliance-påstandene i SoapUI?

bortset fra statuskoder, i SoapUI, kan vi også validere svarmeddelelsen mod definitionen i VSDL(sæbe) eller VADL(resten) af måltjenesten under test.

overvej et scenario, som vi hurtigt vil kontrollere, om SOAP-svaret, som vi får, er i overensstemmelse med VSDL eller ej?

lad os følge nedenstående trin for at validere det samme ved hjælp af “Schema Compliance” – påstand:

1. Naviger for at tilføje Assertion dialog boks og klik på” Schema Compliance “påstand under” Compliance, Status og Standard “påstand kategori, som fremhævet nedenfor:

1. Klik på knappen” Tilføj”, og den viser dialogboksen “Schema Compliance Assertion Configuration”, som vist nedenfor:

2. i konfigurationsdialogboksen udfylder den automatisk VSDL, som oprettede projektet, men hvis du vil angive et andet VSDL, kan du også opdatere det. Klik på OK for at fortsætte.

1. hvis svaret er kompatibelt i henhold til det nævnte skema, vil du se succesresponsen, som vist ovenfor. Du vil se fejlen, når det sidste svar ikke er i overensstemmelse med VSDL-skemaet.

Bemærk: På samme måde kan du validere svaret fra REST-tjenesten mod en bestemt VAT.

Hvad er de fælles SLA påstande i SoapUI?

som vi alle ved, kaldes en serviceniveauaftale(SLA) generelt aftalen mellem en tjenesteudbyder og en klient. Aftalen kan klassificeres efter forskellige aftalte egenskaber såsom tilgængelighed, kvalitet, responstid osv. SoapUI giver funktionaliteten til at validere responstiden for en bestemt tjeneste.

overvej et hypotetisk scenario, at den aftalte responstid for Boghandlens Internetservice er mindre end 4 sekunder. Vi kan validere det samme i SoapUI ved hjælp af kategorierne “SLA”.

lad os følge nedenstående trin for at validere det samme ved hjælp af” Response SLA “- påstand:

1. Naviger for at tilføje Assertion dialogboks og klik på” Response SLA “påstand under kategorien” SLA ” påstand, som fremhævet nedenfor:

1. Klik på knappen” Tilføj”, og det vil vise dialogboksen “Response SLA Assertion configuration”, som vist nedenfor:

1. Angiv den maksimale tid (i ms), hvor tjenesten forventer at returnere svaret. For vores scenario har vi angivet 4000 ms. Klik på OK-knappen for at tilføje påstanden. Det vil vise testresultatet, som vist nedenfor:

1. som vi kan se i ovenstående skærmbillede, da svartiden for tjenesten var 1374 ms, så det var under den nævnte SLA på 4000 ms og resulterede i en vellykket påstand.

nøgle grillbarer

• SoapUI tilbyder en bred vifte af påstande, der kan anvendes på både SOAP og REST internettjenester.
• derudover er få af de almindelige påstande indeholder, ikke indeholder, Ksv, og Ksv Match, som bruges til validering af svaret på indholdet af Hjemmesidetjenesten.
• desuden bruges et andet sæt fælles påstande fra SoapUI til validering af HTTP-Statuskoderne og skemaet for svar fra hjemmesiderne.
• SoapUI giver også en SLA-påstand, der kan bruges til validering af responstiden for både SOAP-og REST-tjenester.

lad os gå videre til den næste artikel, hvor vi vil dybe dykke yderligere for at forstå, hvordan vi kan implementere nogle forhåndskrav ved hjælp af “Script Assertions” i SoapUI.