Hvad er SOA-test?
SOA (Service Oriented Architecture) Testing er en test af SOA-arkitektonisk stil, hvor applikationskomponenterne er designet til at kommunikere via kommunikationsprotokoller typisk over et netværk.
I denne vejledning lærer du-
- Hvad er SOA?
- Hvad er service?
- SOA-test
- Strategi til SOA-test
- SOA testmetoder
- Udfordringer i SOA-test
- SOA testværktøjer
- SOA-test brugssager
Hvad er SOA?
SOA er en metode til at integrere forretningsapplikationer og processer sammen for at imødekomme forretningsbehovene.
I softwareteknik giver SOA smidighed og fleksibilitet i forretningsprocesser. Ændringerne i processen eller applikationen kan rettes til en bestemt komponent uden at påvirke hele systemet.
Softwareudviklerne i SOA udvikler eller køber enten stykker af programmer kaldet SERVICES.
Hvad er service?
- Tjenester kan være en funktionel applikationsenhed eller forretningsproces, som kan genbruges eller gentages af enhver anden applikation eller proces.
(For eksempel er Payment Gateway i ovenstående billede en tjeneste, der kan genbruges af ethvert e-handelswebsted. Når en betaling skal foretages, ringer / anmoder e-handelswebstedet om betaling Gateway-tjenesten. Efter betaling er foretaget den en gateway, et svar sendes til e-handelswebstedet)
- Services er nemme at samle og nemme at konfigurere komponenter igen.
- Tjenester kan sammenlignes med byggesten. De kan konstruere enhver applikation, der er nødvendig. Det er let at tilføje og fjerne dem fra applikationen eller forretningsprocessen.
- Tjenester defineres mere af den forretningsfunktion, de udfører snarere end som kodestykker.
Webtjenester
Webtjenester er uafhængige applikationskomponenter, som er tilgængelige over internettet.
De kan offentliggøres, findes og kan bruges på internettet. De kan kommunikere via internettet.
- Tjenesteudbyderen offentliggør tjenesten på Internettet.
- Klienten søger efter en bestemt webtjeneste fra Web Service Registry
- En URL og WSDL for den krævede webservice returneres.
>> Ved hjælp af WSDL og URL'en foregår kommunikationen mellem tjenesteudbyderen og anmoderen via SOAP-meddelelser. <<
- Når en forbruger ringer til en webservice, oprettes en HTTP-forbindelse til udbyderen.
En SOAP-besked oprettes for at instruere udbyderen om at påkalde den krævede webservicelogik.
- Svaret, der modtages fra udbyderen, er en SOAP-besked, som vil blive integreret i HTTP-svaret. Dette HTTP-svar er det dataformat, der er forståeligt af forbrugerapplikationen.
Eksempel
En hjemmeside på et websted og en søgemaskine viser hverdagsrapport. I stedet for at kode vejrrapportafsnittet overalt kan en service af 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, der er løst koblet.
SOA Testing skal fokusere på 3 systemlag
Tjenestelag
Dette lag består af tjenesterne, tjenester eksponeret af et system afledt af forretningsfunktioner.
For eksempel -
Overvej et wellness-websted, der består af
- Vægt Tracker
- Blodsukker Tracker
- Blodtryksmåler
Trackere viser de respektive data og dato for indtastning. Services-laget består af de tjenester, der henter de respektive data fra databasen-
- Vægt Tracker service
- Blodsukker Tracker service
- Blodtrykssporingstjeneste
- Login-service
Process Layer
Process Layer består af processer, samling af tjenester, der 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ægt trackerens brugergrænseflade og dens integration med databasen er det primære fokus.
Nedenstående funktioner vil være af overvejelse
- Tilføjelse af nye data
- Redigering af eksisterende data
- Opretter ny tracker
- Sletning af data
Forbrugerlag
Dette lag består hovedsageligt af brugergrænseflader.
Baseret på laget fordeles testningen af en SOA-applikation i tre niveauer.
- Serviceniveau
- Grænsefladeniveau
- Slut til slutniveau
- Top Down-tilgang bruges til testdesign.
- Bottom Up tilgang bruges til testudførelse.
Strategi til SOA-test
Testplanlægningsmetode,
- Den komplette arkitektur af applikationen skal forstås af SOA-testere.
- Applikationen skal opdeles i uafhængige tjenester (Service, som har deres egen anmodning og svarstruktur og ikke afhænger 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 kritiseres.
- Forretningsscenarierne skal klassificeres som almindelige scenarier og applikationsspecifikke scenarier.
- Der skal udarbejdes en sporbarhedsmatrix, og alle testsager skal spores til forretningsscenarier.
Testudførelsesmetode
- Hver servicekomponent skal testes.
- Integration Test af servicekomponenterne skal udføres for at validere datastrømmen gennem tjenesterne og dataintegriteten.
- Systemtest af den komplette model skal udføres for at validere datastrømmen mellem front-end-applikation og database.
- Ydelsestestning skal udføres for finjustering og optimal ydelse.
SOA-testmetoder
1) Databaseret test baseret på forretningsscenarier,
- Forskellige forretningsaspekter relateret til systemet bør analyseres.
- Scenarier bør udvikles baseret på integrationen af
- Forskellige webtjenester i applikationen
- Webtjenester og applikationer.
- Opsætning af data skal ske på baggrund af ovenstående scenarier.
- Opsætning af data skal udføres for også at dække slut-til-slut-scenarier.
2) Stubbe
- Dummy-grænseflader oprettes for at teste tjenester.
- Forskellige indgange kan leveres gennem disse grænseflader, og udgangene kan valideres.
- Når et program bruger en grænseflade til en ekstern tjeneste, som ikke er under test (tredjepartstjeneste), kan der oprettes en stub under integrationstest.
3) Regressionstest
- Regression Test af applikationen skal 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, der udgør en vigtig del af applikationen.
- Denne testpakke kan genbruges i flere udgivelser af projektet.
4) Test af serviceniveau
Service Level Testing inkluderer test af komponenten for funktionalitet, sikkerhed, ydeevne og interoperabilitet.
Hver eneste tjeneste skal først testes uafhængigt.
5) Funktionstest
Funktionstest skal udføres på hver service til
- Sørg for, at tjenesten leverer det rigtige svar på hver anmodning.
- Der modtages korrekte fejl for anmodninger med ugyldige data, dårlige data osv.
- Kontroller for hver anmodning og svar for hver 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 om svaret svarer til de anmodede data.
6) Sikkerhedstest
Sikkerhedstest af webservicen er et vigtigt aspekt under test af serviceniveau af SOA-applikationen; dette sikrer applikationens sikkerhed.
Følgende faktorer skal dækkes under testen:
- Industristandard defineret ved WS-sikkerhedstest skal overholdes af webservicen.
- Sikkerhedsforanstaltninger skal fungere perfekt.
- Kryptering af data og digitale signaturer på dokumenterne
- Godkendelse og godkendelse
- SQL Injection, Malware, XSS, CSRF, andre sårbarheder skal testes på XML.
- Denial of Service-angreb
7) Performance Testing
Ydelsestest af tjenesten skal udføres, da tjenesterne kan genbruges, og flere applikationer muligvis bruger den samme service.
Følgende faktorer overvejes under testningen:
- 8) Tjenestens ydelse og funktionalitet skal testes under tung belastning.
- Tjenestens ydeevne skal sammenlignes, mens du arbejder individuelt og inden for applikationen, det er forbundet med.
- Belastningstest af service skal udføres
- for at kontrollere svartiden
- for at kontrollere flaskehalse
- for at kontrollere brugen af CPU og hukommelse
- at forudsige skalerbarhed
9) Integrationsniveau test
- Test af serviceniveau sikrer korrekt funktion af kun tjenesterne individuelt, det garanterer ikke, at de koblede komponenter fungerer.
- Integrationstest udføres primært med fokus på grænsefladerne.
- Denne fase dækker alle mulige forretningsscenarier.
- Den ikke-funktionelle test af applikationen skal udføres endnu en gang i denne fase. Sikkerhed, overholdelse og ydelsestest sikrer systemets tilgængelighed og stabilitet i alle aspekter.
- Kommunikations- og netværksprotokollerne skal testes for at validere konsistensen af datakommunikationen mellem tjenesterne.
10) Test til ende til slut
Denne fase sikrer, at applikationen bekræfter forretningskravene både funktionelt og ikke-funktionelt.
Nedenstående punkter er sikret, at de testes under test til slut til slut
- Alle tjenester fungerer som forventet efter integrationen
- Undtagelse håndtering
- Applikationens brugergrænseflade
- Korrekt datastrøm gennem alle komponenterne
- Forretningsproces
Udfordringer i SOA-test
- Manglende grænseflader til tjenester
- Testprocessen spænder over flere systemer og skaber således komplekse databehov
- Ansøgningen er en samling af forskellige komponenter, der har tendens til at ændre sig. Behovet for regressionstest er hyppigere.
- På grund af flerlagsarkitektur er det svært at isolere defekter.
- Da tjenesten vil blive brugt i forskellige grænseflader, er det vanskeligt at forudsige belastning, hvilket gør præstationsprøveplanlægning 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 er en integration af flere tjenester, har sikkerhedstest sin egen andel af elendigheder. Validering af godkendelse og godkendelse er temmelig svært.
SOA testværktøjer
Der er mange SOA-testværktøjer til rådighed på markedet for at hjælpe testere med at teste SOA-applikationer. Her er nogle af de populære SOA-testværktøjer :
1) SOAP UI
"SOAP UI" 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 påberåbes.
- Kan også bruges til belastningstest, automatiseringstest og sikkerhedstest
- Stubs kan oprettes af MockServices
- Webtjenesteanmodninger og -tests kan genereres automatisk gennem dens webserviceklient.
- Har indbyggede rapporteringsværktøjer
- Udviklet af SmartBear
2) iTKO LISA
"LISA" er en produktsuite, der giver en funktionel testløsning til distribuerede systemer som SOA.
- Kan også bruges til regression, integration, belastning og ydelsestest.
- Udviklet af iTKO (CA Technologies)
- Kan bruges til at designe og udføre tests.
3) HP servicetest
"Service Test" er et funktionelt testværktøj, der understøtter test af både brugergrænseflade og delte tjenester
- Både funktionel og ydelsestest af tjenester kan udføres med et enkelt script.
- Integreret med HP QC.
- Den enorme mængde service og data kan styres.
- Understøtter interoperabilitetstest ved at simulere JEE-, AXIS- og DotNet-klientmiljøer.
- Udviklet af HP.
4) Parasoft SOA-test
SOA Test er en test- og analyseværktøjssuite udviklet til API- og API-applikationstest.
- Understøtter webservices, REST, JSON, MQ, JMS, TIBCO, HTTP, XML-teknologier.
- Funktionel, enhed, integration, regression, sikkerhed, interoperabilitet, overholdelse og præstationstest er mulige.
- Stubs kan oprettes ved hjælp af Parasoft Virtualize, som er intelligente end SOAP UI.
- Udviklet af ParaSoft
SOA-test brugssager
Overvej et e-handelswebsted, der indeholder nedenstående funktioner og underfunktioner:
Ordrebehandling
FASE 1
I den første fase af SOA-test, dvs. teststrategifase, er applikationen opdelt i tjenester og forretningsfunktioner.
Lad os overveje nedenfor er tjenesterne i applikationen.
- Opret ordre
- Kontroller kundestatus
- Skift ordrestatus
- Kontroller ordrestatus
- Tjek beholdning
Forretningsfunktioner er de samme som funktionerne på hjemmesiden.
Bemærk: Teststrategidokumentet indeholder listen over tjenesten og de funktioner, der skal testes.
FASE 2
Testplanlægningsfase. Testcases skrives for hvert niveau.
- Slut til slutniveau. Testcases er skrevet for hver forretningsbrugssag og flow.
Nedenfor er eksemplet på testsager
- Opret en ordre med den aktive bruger.
- Opret en ordre med en inaktiv bruger.
- Opret en ordre med det tilgængelige produkt med ordremængde
- Opret en ordre med det tilgængelige produkt med ordremængde> tilgængelig mængde.
- Opret en ordre med flere varer
- Annuller en ordre fuldstændigt.
- Annuller ordren delvist.
- Integrationsniveau. Testcases er skrevet til integration af database og brugergrænseflade.
Nedenfor er eksempler på testtilfælde.
- Opret en ny ordre med en enkelt vare. Kontroller, at ordren oprettes i databasen.
- Opret en ny ordre med en enkelt vare. Kontroller, at prisen beregnet for ordren er korrekt.
- Opret en ny ordre med en enkelt vare. Kontroller, at mængden af det tilgængelige produkt er mindre med ordrebeløbet.
- Kontroller, at status for ordren, der vises på brugergrænsefladen, er den samme som i databasen.
- Annuller ordren, og kontroller, at status for ordren er ændret i databasen.
- For første gang skal du kontrollere, at de betalingsoplysninger, der er angivet i brugergrænsefladen, er gemt i databasen.
- For at returnere betalinger skal du kontrollere, at betalingsoplysningerne i databasen vises i brugergrænsefladen.
- Serviceniveau. Hver tjeneste testes for alle dataforhold.
Nedenfor er et par eksempler.
Ingen. | Ordre detaljer | Bestillingsbetingelse |
---|---|---|
1 | Opret ordre. Antal varer = 1 | Mængde på bestilling |
2 | Opret ordre. Antal varer> 1 | Mængde på bestilling |
3 | Opret ordrenr. Varer = 1 | Mængde på bestilling> Mængde på database |
4 | Kontroller ordrestatus | Status i database = Aktiv |
5 | Kontroller ordrestatus | Status i database = afsendt |
6 | Kontroller ordrestatus | Status i database = Annulleret |
7 | Kontroller ordrestatus | Ordre-id = ugyldig |
8 | Tjek produktets tilgængelighed | Mængde af produkt> 0 |
9 | Tjek produktets tilgængelighed | Mængde produkt = 0 |
10 | Tjek produktets tilgængelighed | Produkt-id = ugyldig |
FASE 3 - Testudførelse
Testudførelse bruger bottom-up-tilgang, dvs. testniveau på serviceniveau udføres først, derefter integrationsniveau og til sidst End to End-test.
1) Serviceniveau
Lad os overveje, at Soapui-værktøjet overvejes til test af applikationen.
WSDL og URL gennemses i testvinduet i SOAP.
Anmodningen om hver tjeneste vises i anmodningsvinduet.
Ved at ændre dataene i henhold til serviceniveau-testtilfælde oprettes anmodninger for hver testsag.
Test sag |
Anmodning |
Forventet svar |
---|---|---|
Opret ordre. Antal varer = 1Mængde på ordre |
|
|
Opret ordre. Nr. af varer> 1Mængde på ordre |
|
|
Opret ordrenr. af varer = 1Mængde på ordre> Mængde på db |
|
|
Kontroller ordrestatus i database = aktiv |
|
|
Kontroller ordrestatus i database = afsendt |
|
|
Kontroller ordrestatus Bestillings-id = ugyldig |
|
|
Kontroller produktets tilgængelighedMængde af produkt> 0 |
|
|
Kontroller produktets tilgængelighedMængde af produkt = 0 |
|
|
Kontroller produktets tilgængelighed Produkt-id = ugyldig |
|
|
2) Integrationsniveau
Integrationsniveauet testcases 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 et gyldigt antal og gemmer ordren.
- En meddelelse om, at ordren er placeret, skal vises.
- En bruger åbner database og kontrollerer, om detaljerne i ordren er de samme som dem, der er indtastet på hjemmesiden.
3) Slut til slutniveau
Forretningsstrømme og brugssager udføres på brugergrænsefladen.
- Opret en ordre med flere varer -
- En bruger åbner et websted.
- Går for at afgive en ordre.
- Forespørger om et gyldigt produkt, og mængden føjer dem til indkøbskurven.
- Andre gyldige produkter tilføjes med gyldige mængder, og ordren gemmes. Betaling sker via en ny betalingsmetode, og ordre placeres.
- En meddelelse, der siger "Ordre afgivet med succes", skal vises.
- En tester skal validere, at hele flowet sker uden skævhed af data.
Konklusion:
Ved at skitsere den rigtige strategi for test, ressourcer, værktøjer og overholdelse for at levere god service kan SOA-test levere en fuldstændig og perfekt testet applikation.