Hvad er SOA-testning? Tutorial med eksempel

Hvad er SOA-testning?

SOA (serviceorienteret Architecture) Test er en test af SOA-arkitektonisk stil, 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.

I Software Engineering giver SOA agilitet og fleksibilitet til forretningsprocesser. Ændringerne af processen eller applikationen kan rettes til en bestemt komponent uden at påvirke hele systemet.

Softwareudviklerne i SOA enten udvikler eller køber bidder af programmer kaldet TJENESTER.

Hvad er service?

• Tjenester kan være en funktionel enhed af applikationer eller forretningsprocesser, som kan genbruges eller gentages af enhver anden applikation eller proces. (På billedet ovenfor er Payment Gateway f.eks. en tjeneste, der kan genbruges af ethvert e-handelswebsted. Når en betaling skal udføres, ringer/anmoder e-handelssiden til Payment Gateway-tjenesten. Efter betaling er foretaget på en gateway, sendes et svar til e-handelswebstedet)
• Tjenester er nemme at samle og nemme at omkonfigurere komponenter.
• Tjenester kan sammenlignes med byggeklodser. De kan konstruere enhver applikation, der er nødvendig. Det er nemt at tilføje og fjerne dem fra applikationen eller forretningsprocessen.
• Tjenester defineres mere af den forretningsfunktion, de udfører, snarere end som kodestykker.

Web Services

Webtjenester er uafhængige applikationskomponenter, som er tilgængelige over internettet.

De kan publiceres, findes og kan bruges på nettet. De kan kommunikere via internettet.

1. Tjenesteudbyderen udgiver tjenesten på internettet.
2. Klienten søger efter en bestemt webtjeneste fra webtjenesteregistret
3. En URL og WSDL for den påkrævede webservice returneres. Ved at bruge WSDL og URL'en sker kommunikationen mellem tjenesteudbyderen og anmoderen gennem SOAP-meddelelser.
4. Når en forbruger ringer til en webservice, etableres en HTTP-forbindelse til udbyderen.
   En SOAP-meddelelse oprettes for at instruere udbyderen om at påkalde den nødvendige webservicelogik.
5. Svaret modtaget fra udbyderen er en SOAP-meddelelse, som vil blive indlejret i HTTP-svaret. Dette HTTP-svar er dataformatet, som er forståeligt af forbrugerapplikationen.

Eksempel

En hjemmeside for et websted og en søgemaskine viser daglige vejrrapporter. I stedet for at kode vejrrapportsektionen over det hele, kan en Service of vejrrapport købes fra en leverandør og integreres i siderne.

SOA test

SOA består af forskellige teknologier. Applikationer bygget ved hjælp af SOA har forskellige tjenester, som er løst koblede.

SOA-test skal fokusere på 3 systemlag

Tjenester lag

Dette lag består af tjenesterne, tjenester eksponeret af et system afledt af forretningsfunktioner.

For eksempel -

Overvej et wellness-websted, som består af

1. Vægt Tracker
2. Blodsukker tracker
3. Blodtryksmåler

Trackere viser de respektive data og dato, de er indtastet. Tjenestelaget består af de tjenester, som henter de respektive data fra databasen–

• Weight Tracker service
• Blood Sugar Tracker service
• Blodtryksmåler service
• Login service

Proceslag

Process Layer består af processer, samling af tjenester, som er en del af en enkelt funktionalitet.

Processerne kan være en del af brugergrænsefladen (f.eks. - En søgemaskine), en del af et ETL-værktøj (til at hente data fra databasen).

Hovedfokus i dette lag vil være i brugergrænseflader og proces.

Vægttrackerens brugergrænseflade og dens integration med databasen er det primære fokus.

Nedenstående funktioner vil komme i betragtning

1. Tilføjelse af nye data
2. Redigering af eksisterende data
3. Oprettelse af ny tracker
4. Sletning af data

Forbrugerlag

Dette lag består hovedsageligt af brugergrænseflader.

Baseret på laget er testen af ​​en SOA-applikation fordelt på tre niveauer.

1. Serviceniveau
2. Grænsefladeniveau
3. End to End niveau

• Top Down tilgang bruges til testdesign.
• Bottom Up-tilgangen bruges til testudførelse.

Strategi for SOA-testning

Testplanlægningstilgang,

• Den komplette arkitektur af applikationen skal forstås af SOA-testerne.
• Ansøgningen skal opdeles i uafhængige tjenester (tjeneste, som har deres egen anmodnings- og svarstruktur og ikke er afhængig af nogen anden tjeneste for at danne svar).
• Applikationsstrukturen skal omorganiseres i tre komponenter – Data, Services og front-end-applikationer.
• Alle komponenter skal analyseres omhyggeligt, og forretningsscenarier skal udskrives.
• Forretningsscenarierne bør klassificeres som almindelige scenarier og applikationsspecifikke scenarier.
• A Sporbarhedsmatrix bør forberedes, og alle testcases bør spores til 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 gøres for at validere datastrømmen mellem front-end applikation og database.
• Test af ydeevne bør gøres for finjustering og optimal ydeevne.

SOA-testmetoder

1) Forretningsscenariedrevet databaseret test,

• Forskellige forretningsaspekter relateret til systemet bør analyseres.
• Scenarier bør udvikles baseret på integration af
• Various Webtjenester af ansøgningen
• Webtjenester og applikation.
• Opsætning af data bør udføres ud fra ovenstående scenarier.
• Opsætning af data bør også udføres, så de dækker ende-til-ende scenarier.

2) Stubber

• Dummy-grænseflader vil blive oprettet for 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, som ikke er under test (tredjepartstjeneste), kan der oprettes en stub under Integrationstest.

3) Regressionstest

• Regressionstest på applikationen bør gøres, når der er flere udgivelser for at sikre stabiliteten og tilgængeligheden af ​​systemerne.
• Der vil blive oprettet en omfattende regressionstestsuite, der dækker de tjenester, som udgør en vigtig del af applikationen.
• Denne testpakke kan genbruges i flere udgivelser af projektet.

4) Test af serviceniveau

Serviceniveautest omfatter test af komponenten for funktionalitet, sikkerhed, ydeevne og interoperabilitet.

Hver eneste service skal først testes uafhængigt.

5) Funktionstest

Funktionel test skal udføres på hver service til

• Sørg for, at tjenesten giver det rigtige svar på hver anmodning.
• Der modtages rigtige fejl for anmodninger med ugyldige data, dårlige data osv.
• Tjek for hver anmodning og svar for hver eneste operation, som tjenesten skal udføre i løbetid.
• 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 på svaret svarer til de anmodede data.

6) Sikkerhedstest

Sikkerhedstest af webservicen er et vigtigt aspekt under serviceniveautest af SOA-applikationen; dette sikrer applikationens sikkerhed.

Følgende faktorer skal dækkes under test:

• Branchestandarden defineret af WS-Security-test skal overholdes af webtjenesten.
• Sikkerhedsforanstaltninger bør fungere upåklageligt.
• Kryptering af data og Digital underskrifter på dokumenterne
• Godkendelse og godkendelse
• SQL Injection, Malware, XSS, CSRF, andre sårbarheder skal testes på XML.
• Denial of Service-angreb

7) Ydelsestest

Ydelsestest af tjenesten skal udføres, da tjenesterne 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.
• Ydelsen af ​​tjenesten skal sammenlignes, mens du arbejder individuelt og inden for den applikation, den er koblet sammen med.
• Belastningstest af service skal udføres
• for at verificere responstiden
• at tjekke for flaskehalse
• for at verificere udnyttelsen af ​​CPU og hukommelse
• at forudsige skalerbarhed

8) Test af integrationsniveau

• Test af serviceniveau sikrer, at kun tjenesterne fungerer korrekt, det garanterer ikke, at de koblede komponenter fungerer.
• Integrationstest udføres primært med fokus på grænseflader.
• Denne fase dækker alle mulige forretningsscenarier.
• Den ikke-funktionelle test af applikationen bør udføres en gang til i denne fase. Sikkerhed, compliance og præstationstest sikrer tilgængeligheden og stabiliteten af ​​systemet 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 bekræfter forretningskravene både funktionelt og ikke-funktionelt.

Nedenstående punkter er sikret at blive testet under ende til ende test

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

Udfordringer i SOA-test

• Mangel på grænseflader til tjenester
• Testprocesser spænder over flere systemer, hvilket skaber komplekse databehov
• Applikationen er en samling af forskellige komponenter, som har en tendens til at ændre sig. Behovet for regressionstest er mere hyppigt.
• På grund af flerlagsarkitektur er det svært at isolere defekter.
• Da tjenesten vil blive brugt i forskellige grænseflader, er det svært at forudsige belastning, hvilket gør planlægning af præstationstest 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 eksekveringsomkostningerne.
• Da applikationen er en integration af flere tjenester, har sikkerhedstest sin egen andel af problemer. Validering af godkendelse og godkendelse er ret meget vanskelig.

SOA-testbrug

Overvej et e-handelswebsted, som indeholder nedenstående funktioner og underfunktioner:

Ordrebehandling

1 FASE

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

Lad os overveje nedenfor er tjenesterne i applikationen.

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

Forretningsfunktioner er de samme som funktionerne på hjemmesiden.

Bemærk: Teststrategidokumentet ville indeholde listen over tjenesten og de funktioner, der skal testes.

2 FASE

Test Planlægningsfase. Der skrives testcases for hvert niveau.

1. End to End niveau. Testcaserne er skrevet for hver business use case og flow. Nedenfor er eksempler på testcases
   • Opret en ordre hos den aktive bruger.
   • Opret en ordre med en inaktiv bruger.
   • Opret en ordre med det tilgængelige produkt med ordremængde < tilgængelig mængde.
   • Opret en ordre med det tilgængelige produkt med ordremængde > tilgængeligt antal.
   • Opret en ordre med flere varer
   • Annuller en ordre helt.
   • Annuller ordre delvist.
2. 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 er mindre med ordrebeløbet.
   • Bekræft, at status for ordren, der vises på brugergrænsefladen, er den samme som i databasen.
   • Annuller ordren og bekræft, at status for ordren er ændret i databasen.
   • For første gangs betaling skal du kontrollere, at betalingsoplysningerne, 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.
3. Serviceniveau. Hver tjeneste er testet 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 på database.
3	Opret ordrenummer af 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 bottom-up tilgang, dvs. test af serviceniveau udføres først, derefter integrationsniveau og til sidst End to End test.

1) Serviceniveau

Lad os overveje det Soapui værktøj overvejes til test af applikationen.

wsdl og URL gennemses i SOAPs testvindue.

Anmodningen for hver tjeneste vil blive vist i anmodningsvinduet.

Ved at ændre dataene i henhold til serviceniveauets testcases, oprettes anmodninger for hver testcase.

Test sag	Anmod om	Forventet respons
Opret ordre. Antal varer = 1Antal på ordre < Antal på db	x2 2	o3251 Vellykket
Opret ordrenr. af varer > 1Antal på ordre < Antal på db	y1 1 y2 3	o3251 Vellykket
Opret ordrenr. af varer = 1Antal på ordre > Antal på db	x23 200	nul Mislykket
Tjek ordrestatusStatus på database = Aktiv	o9876	Aktiv Vellykket
Tjek ordrestatusStatus på database = afsendt	o9656	Sendes Vellykket
Tjek ordrestatusOrdre-id = Ugyldig	y5686	nul Mislykket
Tjek produkttilgængelighed Produktmængde >0	d34	34 Ja Vellykket
Tjek produkttilgængelighed Mængde af produkt =0	y34	0 ingen Vellykket
Tjek produkttilgængelighed Produkt-id = ugyldig	sder	Mislykket

2) Integrationsniveau

Testcases på integrationsniveau udføres på brugergrænsefladen og databasen.

• Opret en ordre med en enkelt vare –
• En bruger åbner hjemmesiden.
• Går for at afgive en ordre.
• Vælger et gyldigt produkt og antal og gemmer ordren.
• Der skal vises en meddelelse om, at ordren er afgivet korrekt.
• En bruger åbner databasen og tjekker, om detaljerne i ordren er de samme som dem, der er indtastet på hjemmesiden.

3) End to End niveau

Forretningsstrømmene og use cases udføres på brugergrænsefladen.

• Opret en ordre med flere varer –
• En bruger åbner en hjemmeside.
• Går for at afgive en ordre.
• Forespørgsler om et gyldigt produkt og antal tilføjer dem til indkøbskurven.
• Andre gyldige produkter tilføjes med gyldige mængder, og ordren gemmes. Betaling sker via en ny betalingsmetode og ordren afgives.
• En meddelelse, der siger "Ordre placeret med succes" skal vises.
• En tester bør validere, at hele flowet er udført uden skævvridning af data.

Konklusion

Ved at skitsere den rigtige strategi for test, ressourcer, værktøjer og compliance for at yde god service, kan SOA-test levere en fuldstændig og perfekt testet applikation.