Hvad er SOA-testning? Tutorial med eksempel

Hvad er SOA-testning?

SOA (serviceorienteret Architekstur) Testning er testning af SOA-arkitekturstilen, hvor applikationskomponenterne er designet til at kommunikere via kommunikationsprotokoller, typisk over et netværk.

Hvad er SOA?

SOA er en metode til at integrere forretningsapplikationer og processer sammen for at imødekomme forretningsbehovene.

In Software EngineeringSOA giver forretningsprocesser smidighed og fleksibilitet. En ændring af en proces eller applikation kan rettes mod en bestemt komponent uden at påvirke hele systemet.

Softwareudviklere, der arbejder i SOA, udvikler eller køber enten programstykker kaldet tjenester.

Hvad er service?

Diagrammet nedenfor viser en betalingsgateway, der er udgivet som en tjeneste, som flere e-handelssider kan kalde.

• En tjeneste kan være en funktionel enhed i en applikation eller en forretningsproces, som kan genbruges eller gentages af enhver anden applikation eller proces. (For eksempel, på billedet ovenfor, er Payment Gateway en tjeneste, der kan genbruges af enhver e-handelsside. Når en betaling skal foretages, ringer eller anmoder e-handelssiden om Payment Gateway-tjenesten. Når betalingen er gennemført på gatewayen, sendes et svar tilbage til e-handelssiden.)
• Tjenester er nemme at samle og nemme at omkonfigurere komponenter.
• Tjenester kan sammenlignes med byggeklodser. De kan konstruere enhver applikation, der er nødvendig, og det er nemt at tilføje eller fjerne dem fra applikationen eller forretningsprocessen.
• Tjenester defineres mere ud fra den forretningsfunktion, de udfører, end som kodestykker.

Web Services

De fleste SOA-tjenester eksponeres som webtjenester, så det er værd at forklare mekanikken bag et webtjenestekald inden testlagene.

Webtjenester er uafhængige applikationskomponenter, der er tilgængelige via internettet.

De kan offentliggøres, findes og bruges på nettet, og de kommunikerer via internettet. Sekvensen nedenfor viser, hvordan en udbyder, et register og en forbruger interagerer.

• Tjenesteudbyderen udgiver tjenesten på internettet.
• Klienten søger efter en bestemt webtjeneste i webtjenesteregistret.
• A URL og wsdl for den nødvendige webtjeneste returneres. Brug af WSDL og URL, kommunikationen mellem tjenesteudbyderen og anmoderen sker via SOAP-meddelelser.
• Når en forbruger kalder en webtjeneste, etableres der en HTTP-forbindelse til udbyderen.
• En SOAP-meddelelse oprettes for at instruere udbyderen i at aktivere den nødvendige webtjenestelogik.
• Svaret modtaget fra udbyderen er en SOAP-meddelelse, der er integreret i HTTP-svaret. Dette HTTP-svar er det dataformat, som forbrugerapplikationen forstår.

Eksempel

Skærmbilledet nedenfor viser en vejrudsigt leveret af en ekstern tjeneste og integreret på en søgemaskines hjemmeside.

Hjemmesiden på et websted og en søgemaskine viser en daglig vejrudsigt. I stedet for at kode vejrudsigtssektionen fra bunden, kan en vejrudsigtstjeneste købes fra en leverandør og integreres i siderne.

SOA-testlag

SOA består af forskellige teknologier, og applikationer bygget med SOA har forskellige tjenester, der er løst forbundet. Diagrammet nedenfor kortlægger de tre lag, som en testplan skal dække.

SOA-testning bør fokusere på 3 systemlag.

Tjenester lag

Dette lag består af de tjenester, der eksponeres af et system, og som er afledt af forretningsfunktioner.

For eksempel, overvej en wellness-hjemmeside, der består af:

• Vægt Tracker
• Blodsukker Tracker
• Blood Pressure Tracker

Trackers viser de respektive data og datoen, de blev indtastet. Servicelaget består af de tjenester, der henter de respektive data fra databasen:

• Vægt Tracker-service
• Blodsukker Tracker-service
• Blood Pressure Tracker-service
• Login service

Proceslag

Proceslaget består af processerne, samlingen af ​​tjenester, der er en del af en enkelt funktionalitet.

Processerne kan være en del af en brugergrænseflade (f.eks. en søgemaskine) eller en del af et ETL-værktøj, der henter data fra databasen.

Hovedfokus i dette lag er på brugergrænseflader og processer. Brugergrænsefladen for vægten tracker og dens integration med databasen er det primære fokus.

Følgende funktioner er i betragtning:

• Tilføjelse af nye data
• Redigering af eksisterende data
• Oprettelse af et nyt tracker
• Sletning af data

Forbrugerlag

Dette lag omfatter primært brugergrænseflader, som skærmbilledet nedenfor illustrerer.

Baseret på disse lag er testningen af ​​en SOA-applikation opdelt i tre niveauer:

• Serviceniveau
• Grænsefladeniveau
• End to End niveau

De to bevægelsesretninger er forskellige: en top-down-tilgang anvendes til testdesign, mens en bottom-up-tilgang anvendes til testudførelse.

Strategi for SOA-testning

Testplanlægningsmetode

• SOA-testerne bør forstå applikationens komplette arkitektur.
• Applikationen skal opdeles i uafhængige tjenester (en tjeneste, der har sin egen anmodnings- og svarstruktur og ikke er afhængig af nogen anden tjeneste for at danne et svar).
• Applikationsstrukturen skal omorganiseres i tre komponenter – data, tjenester og frontend-applikationer.
• Alle komponenter skal analyseres omhyggeligt, og forretningsscenarier bør udarbejdes.
• Forretningsscenarierne bør klassificeres som almindelige scenarier og applikationsspecifikke scenarier.
• A Tracevnematrix skal forberedes, og alle testcases skal være tractil forretningsscenarier.

Testudførelsesmetode

• Hver servicekomponent skal testes.
• Integrationstest af servicekomponenterne bør gøres for at validere datastrømmen gennem tjenesterne og dataintegriteten.
• Systemtest af den komplette model bør udføres for at validere dataflowet mellem frontend-applikationen og databasen.
• Test af ydeevne bør gøres for finjustering og optimal ydeevne.

SOA-testmetoder

1) Databaseret testning drevet af forretningsscenarier

• Forskellige forretningsmæssige aspekter relateret til systemet bør analyseres.
• Scenarier bør udvikles baseret på integrationen af ​​applikationens forskellige webtjenester og af webtjenester med applikationen.
• Dataopsætningen bør udføres baseret på ovenstående scenarier.
• Dataopsætningen bør også dække end-to-end-scenarier.

2) Stubber

• Dummy-grænseflader er oprettet til at teste tjenester.
• Forskellige input kan leveres gennem disse grænseflader, og udgangene kan valideres.
• Når en applikation bruger en grænseflade til en ekstern tjeneste, der ikke er under test (en tredjepartstjeneste), kan der oprettes en stub under integrationstestning.

3) Regressionstest

• Regressionstest på applikationen bør udføres, når der er flere udgivelser, for at sikre systemernes stabilitet og tilgængelighed.
• Der vil blive oprettet en omfattende regressionstestsuite, der dækker de tjenester, som udgør en vigtig del af applikationen.
• Denne testsuite kan genbruges på tværs af flere udgivelser af projektet.

4) Test af serviceniveau

Serviceniveautestning omfatter test af komponenten for funktionalitet, sikkerhed, ydeevne og interoperabilitet. Hver eneste tjeneste skal først testes uafhængigt.

5) Funktionstest

Funktionstest skal gøres ved hver service for at:

• Sørg for, at tjenesten leverer det rette svar på hver anmodning.
• Sørg for, at de korrekte fejl modtages for anmodninger med ugyldige eller forkerte data.
• Kontroller hver anmodning og hvert svar for hver handling, som tjenesten skal udføre under kørsel.
• Valider fejlmeddelelserne, når der opstår en fejl på server-, klient- eller netværksniveau.
• Bekræft, at de modtagne svar er i det rigtige format.
• Bekræft, at de modtagne data i svaret stemmer overens med de anmodede data.

6) Sikkerhedstest

Sikkerhedstestning af webtjenesten er et vigtigt aspekt under serviceniveautestning af SOA-applikationen, fordi det sikrer applikationens sikkerhed.

Følgende faktorer skal dækkes under test:

• Webtjenesten skal overholde den branchestandard, der er defineret af WS-Security.
• Sikkerhedsforanstaltninger bør fungere upåklageligt.
• Kryptering af data og digitale signaturer på dokumenterne.
• Godkendelse og autorisation.
• SQL-injektion, malware, XSS, CSRF og andre sårbarheder skal testes på XML.
• Denial of service-angreb.

7) Ydelsestest

Der skal udføres ydeevnetest af tjenesten, fordi tjenester kan genbruges, og flere applikationer kan bruge den samme tjeneste.

Følgende faktorer tages i betragtning under testen:

• Ydeevne og funktionalitet af tjenesten skal testes under stor belastning.
• Tjenestens ydeevne skal sammenlignes, når den fungerer individuelt, og når den er koblet til applikationen.
• Belastningstest af tjenesten bør udføres for at verificere svartid, kontrollere for flaskehalse, verificere udnyttelsen af ​​CPU og hukommelse og forudsige skalerbarhed.

8) Test af integrationsniveau

• Serviceniveautestning sikrer, at tjenesterne fungerer korrekt individuelt; den garanterer ikke, at de koblede komponenter fungerer korrekt.
• Integrationstestning udføres med fokus primært på grænseflader.
• Denne fase dækker alle mulige forretningsscenarier.
• Ikke-funktionel testning af applikationen bør udføres endnu en gang i denne fase. Sikkerheds-, compliance- og performancetestning sikrer systemets tilgængelighed og stabilitet i alle aspekter.
• Kommunikations- og netværksprotokollerne bør testes for at validere sammenhængen i datakommunikationen mellem tjenesterne.

9) End-to-End-test

Denne fase sikrer, at applikationen overholder forretningskravene, både funktionelt og ikke-funktionelt.

Det er sikret, at nedenstående punkter bliver testet under ende-til-ende test:

• Alle tjenester fungerer som forventet efter integration
• Undtagelse håndtering
• Applikationens brugergrænseflade
• Korrekt dataflow gennem alle komponenterne
• Forretningsproces

Udfordringer i SOA-testning

Det er sjældent ligetil at anvende disse metoder, og vanskelighederne nedenfor gentager sig i næsten alle SOA-programmer.

• Mangel på grænseflader til tjenester.
• Testprocessen spænder over flere systemer, hvilket skaber komplekse databehov.
• Applikationen er en samling af forskellige komponenter, som har tendens til at ændre sig, så behovet for regressionstest er hyppigere.
• På grund af den flerlagede arkitektur er det vanskeligt at isolere defekter.
• Da en tjeneste bruges af forskellige grænseflader, er belastningen vanskelig at forudsige, hvilket gør planlægningen af ​​performancetest besværlig.
• SOA er en samling af heterogene teknologier. Test af en SOA-applikation kræver folk med forskellige færdigheder, hvilket igen øger planlægnings- og udførelsesomkostningerne.
• Da applikationen integrerer flere tjenester, har sikkerhedstestning sine egne problemer. Validering af godkendelse og autorisation er vanskelig.

SOA-testværktøjer

Der findes mange SOA-testværktøjer på markedet, der kan hjælpe testere med at teste SOA-applikationer. Her er nogle af de populære SOA-testværktøjer.

1) SoapUI

SoapUI er et open source funktionelt testværktøj til tjenester og API-test.

• Desktop-applikation
• Understøtter flere protokoller — SOAP, REST, HTTP, JMS, AMF, JDBC
• Webtjenester kan udvikles, inspiceres og aktiveres.
• Kan også bruges til belastningstest, Test af automatisering, og sikkerhedstest
• Stubs kan oprettes af MockServices
• Webtjenesteanmodninger og -tests kan genereres automatisk via dens webtjenesteklient.
• Har indbyggede rapporteringsværktøjer
• Udviklet af SmartBear, som leverer både open source SoapUI distribution og kommerciel ReadyAPI udgave

2) Broadcom Service Virtualization (tidligere iTKO LISA)

LISA er en produktsuite, der leverer en funktionel testløsning til distribuerede systemer såsom SOA. Produktet blev overført fra iTKO til CA Technologies og sælges i dag som Broadcom Service Virtualization.

• Kan også bruges til regression, integration, belastning og performancetestning.
• Kan bruges til at designe og udføre tests.

3) UFT En (tidligere HP Service Test)

Service Test er et funktionelt testværktøj, der understøtter både UI- og shared services-testning. Dets API-testfunktionalitet blev integreret i Unified Functional Testing, som nu sælges af OpenText as UFT En.

• Både funktionelle og ydeevnetests af tjenester kan udføres med et enkelt script.
• Integreret med Quality Center, nu solgt som OpenText ALM / Kvalitetscenter.
• En enorm mængde tjenester og data kan administreres.
• Understøtter interoperabilitetstest ved at simulere JEE-, AXIS- og DotNet-klientmiljøer.

4) Parasoft SOAtest

Parasoft SOAtest er en test- og analyseværktøjspakke udviklet til API- og API-drevet applikationstest.

• Understøtter webtjenester, REST, JSON, MQ, JMS, TIBCO, HTTP og XML-teknologier.
• Funktionel, enheds-, integrations-, regressions-, sikkerheds-, interoperabilitets-, compliance- og performancetestning er mulige.
• Stubbe kan oprettes ved hjælp af Parasoft Virtualize, som er mere dygtige end SoapUI MockServices.

SOA-testbrug

Det anvendte eksempel nedenfor anvender ovenstående strategi, metoder og værktøjer på et enkelt e-handelswebsted, fase for fase.

Overvej en e-handelshjemmeside, der indeholder funktionerne og underfunktionerne nedenfor.

Ordrebehandling

Diagrammet nedenfor opdeler ordrebehandling i de underfunktioner, der bliver til tjenester.

1 FASE

I den første fase af SOA-testning, teststrategifasen, opdeles applikationen i tjenester og forretningsfunktioner.

Lad os se på tjenesterne nedenfor i ansøgningen.

• Opret ordre
• Tjek kundestatus
• Skift ordrestatus
• Tjek ordrestatus
• Tjek beholdning

Forretningsfunktionerne er de samme som hjemmesidens funktioner.

Bemærk: Teststrategidokumentet vil indeholde en liste over de tjenester og funktioner, der skal testes.

2 FASE

Dette er testplanlægningsfasen. Test tilfælde er skrevet for hvert niveau.

End-to-End niveau. Testcases er skrevet til hver forretningsanvendelsescase og flow. Nedenfor er eksempler på testcases.

• Opret en ordre med en aktiv bruger.
• Opret en ordre med en inaktiv bruger.
• Opret en ordre med et tilgængeligt produkt med ordreantal < tilgængelig mængde.
• Opret en ordre med et tilgængeligt produkt med ordreantal > tilgængelig mængde.
• Opret en ordre med flere varer.
• Annuller en ordre helt.
• Annuller en ordre delvist.

Integrationsniveau. Testcases er skrevet til integration af database og brugergrænseflade. Nedenfor er eksempler på testcases.

• Opret en ny ordre med en enkelt vare. Kontroller, at ordren er oprettet i databasen.
• Opret en ny ordre med en enkelt vare. Kontroller, at den beregnede pris for ordren er korrekt.
• Opret en ny ordre med en enkelt vare. Bekræft, at mængden af ​​det tilgængelige produkt reduceres med ordrebeløbet.
• Bekræft, at status for den ordre, der vises i brugergrænsefladen, er den samme som i databasen.
• Annuller ordren og bekræft, at status for ordren er ændret i databasen.
• Ved førstegangsbetaling skal du kontrollere, at de betalingsoplysninger, der er indtastet i brugergrænsefladen, er gemt i databasen.
• For at returnere betalinger skal du kontrollere, at betalingsoplysningerne i databasen vises på brugergrænsefladen.

Serviceniveau. Hver tjeneste testes for alle databetingelser. Nedenfor er et par eksempler.

Nej.	Ordre detaljer	Ordretilstand
1	Opret ordre. Antal varer = 1	Antal på bestilling < Antal på database
2	Opret ordre. Antal varer > 1	Antal på ordre < Antal i databasen
3	Opret ordre. Antal varer = 1	Antal på ordre > Antal på database
4	Tjek ordrestatus	Status på database = Aktiv
5	Tjek ordrestatus	Status på database = Sendt
6	Tjek ordrestatus	Status på database = Annulleret
7	Tjek ordrestatus	Ordre-id = Ugyldig
8	Tjek produktets tilgængelighed	Produktmængde >0
9	Tjek produktets tilgængelighed	Mængde af produkt =0
10	Tjek produktets tilgængelighed	Produkt-id = ugyldig

FASE 3 — Testudførelse

Testudførelse bruger en bottom-up-tilgang: serviceniveautestning udføres først, derefter integrationsniveau og til sidst end-to-end-testning.

1) Serviceniveau

Lad os overveje, at SoapUI Værktøjet bruges til at teste applikationen. WSDL og URL gennemses i testvinduet for SoapUI, og anmodningen for hver tjeneste vises i anmodningsvinduet. Ved at ændre dataene i henhold til testcases på serviceniveau oprettes anmodninger for hver testcase.

Test sag	Anmod om	Forventet respons
Opret ordre. Antal varer = 1, Antal på ordre < Antal på databasen	x2 2	o3251 Vellykket
Opret ordre. Antal varer > 1, Antal på ordre < Antal på database	y1 1 y2 3	o3251 Vellykket
Opret ordre. Antal varer = 1, Antal på ordre > Antal på databasen	x23 200	nul Mislykket
Tjek ordrestatus. Status i databasen = Aktiv	o9876	Aktiv Vellykket
Tjek ordrestatus. Status i databasen = Afsendt	o9656	Sendt Vellykket
Tjek ordrestatus. Ordre-id = Ugyldigt	y5686	nul Mislykket
Tjek produkttilgængelighed. Produktmængde >0	d34	34 Ja Vellykket
Tjek produkttilgængelighed. Produktmængde = 0	y34	0 ingen Vellykket
Tjek produkttilgængelighed. Produkt-id = ugyldigt	sder	Mislykket

2) Integrationsniveau

Testcases på integrationsniveau udføres på brugergrænsefladen og databasen. Opret en ordre med et enkelt element:

• En bruger åbner hjemmesiden.
• Brugeren går hen for at afgive en ordre.
• Brugeren vælger et gyldigt produkt og en gyldig mængde og gemmer ordren.
• Der bør vises en besked om, at ordren er afgivet.
• Brugeren åbner databasen og kontrollerer, om ordreoplysningerne stemmer overens med dem, der er indtastet på hjemmesiden.

3) End to End niveau

Forretningsflowene og use cases udføres på brugergrænsefladen. Opret en ordre med flere elementer:

• En bruger åbner hjemmesiden.
• Brugeren går hen for at afgive en ordre.
• Brugeren forespørger om et gyldigt produkt og en gyldig mængde og tilføjer dem til kurven.
• Andre gyldige produkter tilføjes med gyldige mængder, og ordren gemmes. Betaling foretages via en ny betalingsmetode, og ordren afgives.
• En meddelelse, der siger "Ordre placeret med succes" skal vises.
• En tester skal validere, at hele flowet gennemføres uden dataforvrængning.

Ofte Stillede Spørgsmål