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.
- Tjenesteudbyderen udgiver tjenesten på internettet.
- Klienten søger efter en bestemt webtjeneste fra webtjenesteregistret
- 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.
- 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. - 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
- Vægt Tracker
- Blodsukker tracker
- 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
- Tilføjelse af nye data
- Redigering af eksisterende data
- Oprettelse af ny tracker
- 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.
- Serviceniveau
- Grænsefladeniveau
- 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-testværktøjer
Der er mange SOA-testværktøjer tilgængelige 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-testning.
- 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, Test af automatisering, og sikkerhedstest
- Stubs kan oprettes af MockServices
- Webserviceanmodninger og -test kan genereres automatisk gennem dens webserviceklient.
- Har indbyggede rapporteringsværktøjer
- Udviklet af SmartBear
2) iTKO LISA
"LISA" er en produktsuite, som giver en funktionel testløsning til distribuerede systemer som SOA.
- Kan også bruges til regression, integration, belastning og præstationstest.
- Udviklet af iTKO (CA Technologies)
- Kan bruges til at designe og udføre tests.
3) HP Service Test
"Service Test" er et funktionelt testværktøj, som understøtter test af både brugergrænseflade og delte tjenester
- Både funktions- og ydeevnetest af tjenester kan udføres af et enkelt script.
- Integreret med HP QC.
- Den enorme mængde service og data kan administreres.
- 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øjspakke udviklet til test af API- og API-applikationer.
- Understøtter webtjenester, REST, JSON, MQ, JMS, TIBCO, HTTP, XML-teknologier.
- Funktionel, enhed, integration, regression, sikkerhed, interoperabilitet, compliance og ydeevnetest er mulige.
- Stubs kan oprettes ved hjælp af Parasoft Virtualize, som er intelligente end SOAP UI.
- Udviklet af ParaSoft
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.
- 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.
- 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.
- 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.