Hva er SOA-testing? Opplæring med eksempel

Hva er SOA-testing?

SOA (tjenesteorientert Architecture) Testing er en testing av SOA-arkitektonisk stil der applikasjonskomponentene er designet for å kommunisere via kommunikasjonsprotokoller, typisk over et nettverk.

Hva er SOA?

SOA er en metode for å integrere forretningsapplikasjoner og prosesser sammen for å møte forretningsbehovene.

I Software Engineering gir SOA smidighet og fleksibilitet til forretningsprosesser. Endringene i prosessen eller applikasjonen kan rettes til en bestemt komponent uten å påvirke hele systemet.

Programvareutviklerne i SOA enten utvikler eller kjøper biter av programmer kalt TJENESTER.

Hva er service?

• Tjenester kan være en funksjonell enhet av applikasjoner eller forretningsprosesser, som kan gjenbrukes eller gjentas av en hvilken som helst annen applikasjon eller prosess.(I bildet ovenfor er Payment Gateway for eksempel en tjeneste som kan gjenbrukes av alle e-handelssider. Når en betaling må gjøres, ringer/berer e-handelssiden om betalingsgateway-tjenesten Etter at betalingen er utført på en gateway, sendes et svar til e-handelsnettstedet.
• Tjenester er enkle å montere og enkle å rekonfigurere komponenter.
• Tjenester kan sammenlignes med byggeklosser. De kan konstruere hvilken som helst applikasjon som trengs. Det er enkelt å legge til og fjerne dem fra applikasjonen eller forretningsprosessen.
• Tjenester defineres mer av forretningsfunksjonen de utfører i stedet for som kodebiter.

Web Services

Webtjenester er uavhengige applikasjonskomponenter som er tilgjengelige over nettet.

De kan publiseres, finnes og kan brukes på nettet. De kan kommunisere via internett.

1. Tjenesteleverandøren publiserer tjenesten på internett.
2. Klienten søker etter en bestemt webtjeneste fra webtjenesteregisteret
3. En URL og WSDL for den nødvendige webtjenesten returneres. Ved å bruke WSDL og URL-en, skjer kommunikasjonen mellom tjenesteleverandøren og rekvirenten gjennom SOAP-meldinger.
4. Når en forbruker ringer en nettjeneste, vil det opprettes en HTTP-forbindelse til leverandøren.
   En SOAP-melding opprettes for å instruere leverandøren om å påkalle den nødvendige webtjenestelogikken.
5. Svaret mottatt fra leverandøren er en SOAP-melding som vil bli innebygd i HTTP-svaret. Dette HTTP-svaret er dataformatet som er forståelig av forbrukerapplikasjonen.

Eksempel

En hjemmeside for et nettsted og en søkemotor viser daglig værmelding. I stedet for å kode værmeldingsseksjonen over alt, kan en værmeldingstjeneste kjøpes fra en leverandør og integreres i sidene.

SOA-testing

SOA består av ulike teknologier. Applikasjoner bygget ved hjelp av SOA har forskjellige tjenester som er løst koblet.

SOA-testing bør fokusere på 3 systemlag

Tjenester lag

Dette laget består av tjenestene, tjenester eksponert av et system avledet fra forretningsfunksjoner.

For eksempel -

Vurder et velværenettsted som består av

1. Vektsporer
2. Blodsukkersporer
3. Blood Pressure Tracker

Trackere viser de respektive dataene og datoen de er lagt inn. Tjenestelaget består av tjenestene som henter de respektive dataene fra databasen–

• Vektsporingstjeneste
• Blodsukkersporingstjeneste
• Blodtrykksmålertjeneste
• Påloggingstjeneste

Prosesslag

Process Layer består av prosessene, samlingen av tjenester som er en del av en enkelt funksjonalitet.

Prosessene kan være en del av brukergrensesnittet (for eksempel – En søkemotor), en del av et ETL-verktøy (for å hente data fra databasen).

Hovedfokus i dette laget vil være i brukergrensesnitt og prosess.

Brukergrensesnittet til vektmåleren og dens integrasjon med databasen er hovedfokuset.

Nedenstående funksjoner vil være av betydning

1. Legger til nye data
2. Redigering av eksisterende data
3. Oppretter ny tracker
4. Sletter data

Forbrukerlag

Dette laget består hovedsakelig av brukergrensesnitt.

Basert på laget er testingen av en SOA-applikasjon fordelt på tre nivåer.

1. Service nivå
2. Grensesnittnivå
3. End to End nivå

• Top Down-tilnærmingen brukes for testdesign.
• Bottom Up-tilnærming brukes for testutførelse.

Strategi for SOA-testing

Testplanleggingsmetode,

• Den komplette arkitekturen til applikasjonen bør forstås av SOA-testerne.
• Applikasjonen må deles opp i uavhengige tjenester (tjeneste, som har sin egen forespørsels- og svarstruktur og ikke er avhengig av noen annen tjeneste for å danne svar).
• Applikasjonsstrukturen må omorganiseres i tre komponenter – data, tjenester og front-end-applikasjoner.
• Alle komponentene må analyseres nøye, og forretningsscenarier bør kalkuleres.
• Forretningsscenariene bør klassifiseres som vanlige scenarier og applikasjonsspesifikke scenarier.
• A Sporbarhetsmatrise bør utarbeides, og alle testtilfeller bør spores til forretningsscenarier.

Tilnærming til testutførelse

• Hver servicekomponent bør testes.
• Integrasjonstesting av tjenestekomponentene bør gjøres for å validere dataflyten gjennom tjenestene og dataintegritet.
• Systemtesting av den komplette modellen bør gjøres for å validere dataflyten mellom front-end-applikasjon og database.
• Ytelsestesting bør gjøres for finjustering og optimal ytelse.

SOA-testmetoder

1) Forretningsscenariodrevet databasert testing,

• Ulike forretningsaspekter knyttet til systemet bør analyseres.
• Scenarier bør utvikles basert på integrering av
• Diverse Webtjenester av søknaden
• Webtjenester og applikasjon.
• Dataoppsett bør gjøres basert på scenariene ovenfor.
• Dataoppsett bør gjøres for å dekke ende til ende scenarier også.

2) Stubber

• Dummy-grensesnitt vil bli opprettet for å teste tjenester.
• Ulike innganger kan gis gjennom disse grensesnittene, og utgangene kan valideres.
• Når en applikasjon bruker et grensesnitt til en ekstern tjeneste, som ikke er under test (tredjepartstjeneste), kan en stubb opprettes under integrasjonstesting.

3) Regresjonstesting

• Regresjonstesting på applikasjonen bør gjøres når det er flere utgivelser for å sikre stabiliteten og tilgjengeligheten til systemene.
• Det vil bli laget en omfattende regresjonstestpakke som dekker tjenestene som utgjør en viktig del av applikasjonen.
• Denne testpakken kan gjenbrukes i flere utgivelser av prosjektet.

4) Tjenestenivåtesting

Tjenestenivåtesting inkluderer testing av komponenten for funksjonalitet, sikkerhet, ytelse og interoperabilitet.

Hver eneste tjeneste må først testes uavhengig.

5) Funksjonstesting

Funksjonstesting bør gjøres på hver tjeneste til

• Sørg for at tjenesten gir riktig svar på hver forespørsel.
• Riktige feil mottas for forespørsler med ugyldige data, dårlige data osv.
• Sjekk for hver forespørsel og svar for hver operasjon tjenesten må utføre i løpet av kjøretiden.
• Valider feilmeldingene når det oppstår en feil på server-, klient- eller nettverksnivå.
• Bekreft at de mottatte svarene er i riktig format.
• Bekreft at dataene mottatt på svaret tilsvarer de forespurte dataene.

6) Sikkerhetstesting

Sikkerhetstesting av webtjenesten er et viktig aspekt under testing av tjenestenivå av SOA-applikasjonen; dette sikrer sikkerheten til applikasjonen.

Følgende faktorer må dekkes under testing:

• Bransjestandard definert av WS-Security-testing skal følges av nettjenesten.
• Sikkerhetstiltak skal fungere feilfritt.
• Kryptering av data og Digital signaturer på dokumentene
• Autentisering og autorisasjon
• SQL Injection, Malware, XSS, CSRF, andre sårbarheter skal testes på XML.
• Denial of Service-angrep

7) Ytelsestesting

Ytelsestesting av tjenesten må gjøres siden tjenestene kan gjenbrukes og flere applikasjoner kan bruke samme tjeneste.

Følgende faktorer vurderes under testing:

• Ytelse og funksjonalitet til tjenesten må testes under stor belastning.
• Ytelsen til tjenesten må sammenlignes mens du arbeider individuelt og innenfor applikasjonen, den er kombinert med.
• Lasttesting av service bør utføres
• for å bekrefte responstiden
• for å se etter flaskehalser
• for å verifisere bruken av CPU og minne
• å forutsi skalerbarhet

8) Testing av integrasjonsnivå

• Tjenestenivåtesting sikrer at bare tjenestene fungerer som de skal, det garanterer ikke at de koblede komponentene fungerer.
• Integrasjonstesting utføres med fokus hovedsakelig på grensesnittene.
• Denne fasen dekker alle mulige forretningsscenarier.
• Den ikke-funksjonelle testingen av applikasjonen bør gjøres en gang til i denne fasen. Sikkerhet, samsvar og ytelsestesting sikrer tilgjengeligheten og stabiliteten til systemet i alle aspekter.
• Kommunikasjons- og nettverksprotokollene bør testes for å validere konsistensen av datakommunikasjonen mellom tjenestene.

9) End-to-end-testing

Denne fasen sikrer at søknaden bekrefter forretningskravene både funksjonelt og ikke-funksjonelt.

Elementene nedenfor er sikret å bli testet under ende-til-ende-testing

• Alle tjenester fungerer som forventet etter integrering
• Avvikshåndtering
• Brukergrensesnitt for applikasjonen
• Riktig dataflyt gjennom alle komponentene
• Forretningsprosess

Utfordringer i SOA-testing

• Mangel på grensesnitt for tjenester
• Testprosessen spenner over flere systemer og skaper dermed komplekse databehov
• Applikasjonen er en samling av ulike komponenter som har en tendens til å endre seg. Behovet for regresjonstesting er hyppigere.
• På grunn av flerlagsarkitektur er det vanskelig å isolere defekter.
• Siden tjenesten vil bli brukt i forskjellige grensesnitt, er det vanskelig å forutsi belastning, noe som gjør planlegging av ytelsestest tungvint.
• SOA er en samling av heterogene teknologier. Testing av en SOA-applikasjon krever folk med ulike ferdighetssett som igjen øker planleggings- og utførelseskostnadene.
• Siden applikasjonen er en integrasjon av flere tjenester, har sikkerhetstesting sin egen andel av problemer. Validering av autentisering og autorisasjon er ganske vanskelig.

Brukstilfeller for SOA-testing

Vurder et e-handelsnettsted som inneholder følgende funksjoner og underfunksjoner:

Ordrebehandling

FASE 1

I den første fasen av SOA-testing, dvs. teststrategifasen, er applikasjonen delt inn i tjenester og forretningsfunksjoner.

La oss vurdere nedenfor er tjenestene i applikasjonen.

• Opprett bestilling
• Sjekk kundestatus
• Endre ordrestatus
• Sjekk ordrestatus
• Sjekk varelager

Forretningsfunksjoner er de samme som funksjonene til nettstedet.

OBS: Teststrategidokumentet vil inneholde listen over tjenesten og funksjonene som må testes.

FASE 2

Testplanleggingsfase. Testcases skrives for hvert nivå.

1. End to End nivå. Testtilfellene er skrevet for hver forretningsbrukscase og flyt. Nedenfor er eksemplet på testtilfeller
   • Opprett en ordre med den aktive brukeren.
   • Opprett en ordre med en inaktiv bruker.
   • Opprett en bestilling med tilgjengelig produkt med bestillingsmengde < tilgjengelig mengde.
   • Opprett en bestilling med tilgjengelig produkt med bestillingsmengde > tilgjengelig mengde.
   • Opprett en bestilling med flere varer
   • Kanseller en ordre helt.
   • Kanseller bestillingen delvis.
2. Integrasjonsnivå. Testcases er skrevet for integrasjon av database og brukergrensesnitt. Nedenfor er eksempler på testtilfeller.
   • Opprett en ny ordre med en enkelt vare. Kontroller at bestillingen er opprettet i databasen.
   • Opprett en ny ordre med en enkelt vare. Kontroller at prisen som er beregnet for bestillingen er riktig.
   • Opprett en ny ordre med en enkelt vare. Bekreft at mengden av det tilgjengelige produktet er mindre med bestillingsbeløpet.
   • Kontroller at statusen til bestillingen som vises på brukergrensesnittet er den samme som i databasen.
   • Kanseller bestillingen og kontroller at statusen til bestillingen er endret i databasen.
   • For første gangs betaling, kontroller at betalingsdetaljene som er angitt i brukergrensesnittet er lagret i databasen.
   • For å returnere betalinger, kontroller at betalingsdetaljene i databasen vises i brukergrensesnittet.
3. Servicenivå. Hver tjeneste er testet for alle dataforholdene.

Nedenfor er noen eksempler.

Nei.	Ordre detaljer	Bestillingstilstand
1	Opprett ordre. Antall varer = 1	Antall på bestilling < Antall på database
2	Opprett ordre. Antall varer > 1	Antall på bestilling < Antall på database.
3	Opprett ordrenummer av varer = 1	Antall på bestilling > Antall på database
4	Sjekk ordrestatus	Status på database = Aktiv
5	Sjekk ordrestatus	Status på database = Sendt
6	Sjekk ordrestatus	Status på database = Avbrutt
7	Sjekk ordrestatus	Ordre-ID = Ugyldig
8	Sjekk produkttilgjengeligheten	Antall produkt >0
9	Sjekk produkttilgjengeligheten	Antall produkt =0
10	Sjekk produkttilgjengeligheten	Produkt-ID = ugyldig

FASE 3 – Testutførelse

Testkjøring bruker nedenfra-og-opp-tilnærming, dvs. testing av tjenestenivå utføres først, deretter integrasjonsnivå og til slutt End-to-end-testing.

1) Servicenivå

La oss vurdere det Soapui verktøyet vurderes for testing av applikasjonen.

Ocuco wsdl og URL bla gjennom i testvinduet til SOAP.

Forespørselen for hver tjeneste vil vises i forespørselsvinduet.

Ved å endre dataene i henhold til testtilfellene på tjenestenivå, opprettes forespørsler for hvert testtilfelle.

Testsak	Be	Forventet respons
Opprett ordre. Antall varer = 1Antall på bestilling < Antall på db	x2 2	o3251 Vellykket
Opprett ordrenr. av varer > 1Antall på bestilling < Antall på db	y1 1 y2 3	o3251 Vellykket
Opprett ordrenr. av varer = 1Antall på bestilling > Antall på db	x23 200	null Mislykket
Sjekk ordrestatusStatus på database = Aktiv	o9876	Aktiv Vellykket
Sjekk ordrestatusStatus på database = Sendt	o9656	Sendes Vellykket
Sjekk ordrestatusOrder-id = Ugyldig	y5686	null Mislykket
Sjekk produkttilgjengelighet Antall produkt >0	d34	34 ja Vellykket
Sjekk produkttilgjengelighet Antall produkt =0	y34	0 ingen Vellykket
Sjekk produkttilgjengelighet Produkt-ID = ugyldig	sder	Mislykket

2) Integrasjonsnivå

Testtilfellene på integrasjonsnivået utføres på brukergrensesnittet og databasen.

• Opprett en bestilling med en enkelt vare –
• En bruker åpner nettstedet.
• Går for å legge inn en bestilling.
• Velger et gyldig produkt og antall og lagrer bestillingen.
• En melding som sier at bestillingen er plassert skal vises.
• En bruker åpner databasen og sjekker om detaljene for bestillingen er de samme som den som er angitt på nettstedet.

3) End to End-nivå

Forretningsflytene og brukstilfellene utføres på brukergrensesnittet.

• Opprett en bestilling med flere varer –
• En bruker åpner et nettsted.
• Går for å legge inn en bestilling.
• Forespørsler om et gyldig produkt og antall legger dem i handlekurven.
• Andre gyldige produkter legges til med gyldige mengder og bestillingen lagres. Betaling skjer gjennom en ny betalingsmåte og bestillingen er lagt inn.
• En melding som sier "Ordre plassert vellykket" skal vises.
• En tester bør validere at hele flyten er utført uten skjevheter av data.

Konklusjon

Ved å skissere riktig strategi for testing, ressurser, verktøy og compliance for å yte god service, kan SOA-testing levere fullstendig og perfekt testet applikasjon.