Hva er SOA-testing? Opplæring med eksempel

Hva er SOA-testing?

SOA (tjenesteorientert Architekstur) Testing er testing av SOA-arkitekturstilen, der applikasjonskomponentene er designet for å kommunisere via kommunikasjonsprotokoller, vanligvis over et nettverk.

Hva er SOA?

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

In Engineering programvare, SOA gir smidighet og fleksibilitet til forretningsprosesser. En endring i en prosess eller applikasjon kan rettes mot en bestemt komponent uten å påvirke hele systemet.

Programvareutviklere som jobber i SOA utvikler eller kjøper enten deler av programmer som kalles tjenester.

Hva er service?

Diagrammet nedenfor viser en betalingsgateway publisert som en tjeneste som flere netthandelsnettsteder kan kalle.

• En tjeneste kan være en funksjonell enhet i en applikasjon eller en forretningsprosess, som kan gjenbrukes eller gjentas av enhver annen applikasjon eller prosess. (For eksempel, i bildet ovenfor, er Payment Gateway en tjeneste som kan gjenbrukes av ethvert e-handelsnettsted. Når en betaling må foretas, ringer eller ber e-handelsnettstedet om Payment Gateway-tjenesten. Etter at betalingen er fullført på gatewayen, sendes et svar tilbake til e-handelsnettstedet.)
• Tjenester er enkle å montere og enkle å rekonfigurere komponenter.
• Tjenester kan sammenlignes med byggeklosser. De kan konstruere enhver applikasjon som trengs, og det er enkelt å legge til eller fjerne dem fra applikasjonen eller forretningsprosessen.
• Tjenester defineres mer av forretningsfunksjonen de utfører enn som kodebiter.

Web Services

De fleste SOA-tjenester eksponeres som webtjenester, så mekanikken bak et webtjenestekall er verdt å legge frem før testlagene.

Webtjenester er uavhengige applikasjonskomponenter som er tilgjengelige over nettet.

De kan publiseres, finnes og brukes på nettet, og de kommuniserer via internett. Sekvensen nedenfor viser hvordan en leverandør, et register og en forbruker samhandler.

• Tjenesteleverandøren publiserer tjenesten på internett.
• Klienten søker etter en bestemt webtjeneste i webtjenesteregisteret.
• A URL og wsdl for den nødvendige webtjenesten returneres. Bruk av WSDL og URL, kommunikasjon mellom tjenesteleverandøren og forespørselen skjer via SOAP-meldinger.
• Når en forbruker kaller en webtjeneste, opprettes en HTTP-forbindelse til leverandøren.
• En SOAP-melding opprettes for å instruere leverandøren om å aktivere den nødvendige webtjenestelogikken.
• Svaret som mottas fra leverandøren er en SOAP-melding som er innebygd i HTTP-svaret. Dette HTTP-svaret er dataformatet som forstås av forbrukerapplikasjonen.

Eksempel

Skjermbildet nedenfor viser en værmelding levert av en ekstern tjeneste og innebygd på en søkemotors hjemmeside.

Hjemmesiden til et nettsted og en søkemotor viser en daglig værmelding. I stedet for å kode værmeldingsdelen fra bunnen av, kan en værmeldingstjeneste kjøpes fra en leverandør og integreres i sidene.

SOA-testingslag

SOA består av ulike teknologier, og applikasjoner bygget med SOA har ulike tjenester som er løst koblet sammen. Diagrammet nedenfor kartlegger de tre lagene en testplan må dekke.

SOA-testing bør fokusere på tre systemlag.

Tjenester lag

Dette laget består av tjenestene som eksponeres av et system, avledet fra forretningsfunksjoner.

For eksempel, tenk deg et velværenettsted som består av:

• Vekt Tracker
• Blodsukker Tracker
• Blood Pressure Tracker

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

• Vekt Tracker-tjeneste
• Blodsukker Tracker-tjeneste
• Blood Pressure Tracker-tjeneste
• Påloggingstjeneste

Prosesslag

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

Prosessene kan være en del av et brukergrensesnitt (for eksempel en søkemotor) eller en del av et ETL-verktøy som henter data fra databasen.

Hovedfokuset i dette laget er på brukergrensesnitt og prosesser. Brukergrensesnittet til vekten tracker og integrasjonen med databasen er hovedfokuset.

Følgende funksjoner er å vurdere:

• Legger til nye data
• Redigering av eksisterende data
• Å lage et nytt tracker
• Sletter data

Forbrukerlag

Dette laget består hovedsakelig av brukergrensesnitt, som skjermbildet nedenfor illustrerer.

Basert på disse lagene er testingen av en SOA-applikasjon fordelt på tre nivåer:

• Service nivå
• Grensesnittnivå
• End to End nivå

De to reiseretningene er forskjellige: en ovenfra-og-ned-tilnærming brukes for testdesign, mens en nedenfra-og-opp-tilnærming brukes for testutførelse.

Strategi for SOA-testing

Tilnærming til testplanlegging

• SOA-testerne bør forstå hele applikasjonens arkitektur.
• Applikasjonen må deles opp i uavhengige tjenester (en tjeneste som har sin egen forespørsels- og svarstruktur og ikke er avhengig av noen annen tjeneste for å danne et svar).
• Applikasjonsstrukturen må omorganiseres til tre komponenter – data, tjenester og front-end-applikasjoner.
• Alle komponentene må analyseres nøye, og forretningsscenarier bør skisseres.
• Forretningsscenarioene bør klassifiseres som vanlige scenarier og applikasjonsspesifikke scenarier.
• A Tracevnematrise bør forberedes, og alle testtilfeller bør tractilpasset 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 frontend-applikasjonen og databasen.
• Ytelsestesting bør gjøres for finjustering og optimal ytelse.

SOA-testmetoder

1) Databasert testing drevet av forretningsscenarioer

• Ulike forretningsaspekter knyttet til systemet bør analyseres.
• Scenarier bør utvikles basert på integreringen av de ulike webtjenestene i applikasjonen, og av webtjenester med applikasjonen.
• Dataoppsettet bør gjøres basert på scenariene ovenfor.
• Dataoppsettet bør også dekke ende-til-ende-scenarier.

2) Stubber

• Dummy-grensesnitt er laget for å teste tjenester.
• Ulike innganger kan gis gjennom disse grensesnittene, og utgangene kan valideres.
• Når et program bruker et grensesnitt til en ekstern tjeneste som ikke er under testing (en tredjepartstjeneste), kan det opprettes en stub under integrasjonstesting.

3) Regresjonstesting

• Regresjonstesting på applikasjonen bør gjøres når det er flere utgivelser, for å sikre systemenes stabilitet og tilgjengelighet.
• Det vil bli laget en omfattende regresjonstestpakke som dekker tjenestene som utgjør en viktig del av applikasjonen.
• Denne testpakken kan brukes om igjen på tvers av flere versjoner av prosjektet.

4) Tjenestenivåtesting

Testing av tjenestenivå inkluderer testing av komponenten for funksjonalitet, sikkerhet, ytelse og interoperabilitet. Hver eneste tjeneste må først testes uavhengig.

5) Funksjonstesting

Funksjonell testing bør gjøres på hver tjeneste for å:

• Sørg for at tjenesten leverer riktig svar på hver forespørsel.
• Sørg for at de riktige feilmeldingene mottas for forespørsler med ugyldige eller dårlige data.
• Sjekk hver forespørsel og svar for hver operasjon tjenesten må utføre under kjøretid.
• 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 i svaret samsvarer med dataene som er forespurt.

6) Sikkerhetstesting

Sikkerhetstesting av webtjenesten er et viktig aspekt under tjenestenivåtesting av SOA-applikasjonen, fordi det sikrer applikasjonens sikkerhet.

Følgende faktorer må dekkes under testing:

• Bransjestandarden definert av WS-Security bør overholdes av webtjenesten.
• Sikkerhetstiltak skal fungere feilfritt.
• Kryptering av data og digitale signaturer på dokumentene.
• Autentisering og autorisasjon.
• SQL-injeksjon, skadelig programvare, XSS, CSRF og andre sårbarheter skal testes på XML.
• Denial of service angrep.

7) Ytelsestesting

Ytelsestesting av tjenesten må utføres fordi tjenester er gjenbrukbare og flere applikasjoner kan bruke den samme tjenesten.

Følgende faktorer vurderes under testing:

• Ytelse og funksjonalitet til tjenesten må testes under stor belastning.
• Tjenestens ytelse må sammenlignes når den fungerer individuelt og når den er koblet til applikasjonen.
• Lasttesting av tjenesten bør utføres for å verifisere responstid, sjekke for flaskehalser, verifisere utnyttelsen av CPU og minne, og forutsi skalerbarhet.

8) Testing av integrasjonsnivå

• Testing av tjenestenivå sikrer at tjenestene fungerer som de skal individuelt; den garanterer ikke at de koblede komponentene fungerer som de skal.
• Integrasjonstesting utføres med hovedfokus på grensesnitt.
• Denne fasen dekker alle mulige forretningsscenarier.
• Ikke-funksjonell testing av applikasjonen bør gjøres på nytt i denne fasen. Sikkerhet, samsvar og ytelsestesting sikrer systemets tilgjengelighet og stabilitet 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 applikasjonen samsvarer med forretningskravene, både funksjonelt og ikke-funksjonelt.

Elementene nedenfor er garantert testet underveis ende-til-ende testing:

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

Utfordringer i SOA-testing

Det er sjelden enkelt å bruke disse metodene, og vanskelighetene nedenfor går tilbake i nesten alle SOA-programmer.

• Mangel på grensesnitt for tjenester.
• Testprosessen omfatter flere systemer, noe som skaper komplekse databehov.
• Applikasjonen er en samling av ulike komponenter som har en tendens til å endre seg, så behovet for regresjonstesting er hyppigere.
• På grunn av flerlagsarkitekturen er det vanskelig å isolere feil.
• Siden en tjeneste brukes av forskjellige grensesnitt, er belastningen vanskelig å forutsi, noe som gjør planleggingen av ytelsestester tungvint.
• SOA er en samling av heterogene teknologier. Testing av en SOA-applikasjon krever folk med ulike ferdigheter, noe som igjen øker planleggings- og utførelseskostnader.
• Siden applikasjonen integrerer flere tjenester, har sikkerhetstesting sine egne problemer. Validering av autentisering og autorisasjon er vanskelig.

SOA-testverktøy

Det finnes mange SOA-testverktøy på markedet som kan hjelpe testere med å teste SOA-applikasjoner. Her er noen av de populære SOA-testverktøyene.

1) SoapUI

SoapUI er et åpen kildekode-verktøy for funksjonstesting for tjenester og API-testing.

• Desktop-applikasjon
• Støtter flere protokoller – SOAP, REST, HTTP, JMS, AMF, JDBC
• Webtjenester kan utvikles, inspiseres og påkalles.
• Kan også brukes til belastningstesting, Automatiseringstesting, og sikkerhetstesting
• Stubber kan lages av MockServices
• Webtjenesteforespørsler og tester kan genereres automatisk gjennom webtjenesteklienten.
• Har innebygde rapporteringsverktøy
• Utviklet av SmartBear, som sender både åpen kildekode SoapUI distribusjon og det kommersielle ReadyAPI utgave

2) Broadcom Service Virtualization (tidligere iTKO LISA)

LISA er en produktpakke som tilbyr en funksjonell testløsning for distribuerte systemer som SOA. Produktet ble overført fra iTKO til CA Technologies og selges i dag som Broadcom Service Virtualization.

• Kan også brukes til regresjon, integrasjon, belastning og ytelsestesting.
• Kan brukes til å designe og utføre tester.

3) UFT En (tidligere HP Service Test)

Service Test er et funksjonelt testverktøy som støtter både UI- og delte tjenester-testing. API-testfunksjonaliteten ble integrert i Unified Functional Testing, som nå selges av OpenText as UFT One.

• Både funksjonstester og ytelsestester av tjenester kan utføres med et enkelt skript.
• Integrert med kvalitetssenteret, selges nå som OpenText ALM / Kvalitetssenter.
• En enorm mengde tjenester og data kan administreres.
• Støtter interoperabilitetstesting ved å simulere JEE-, AXIS- og DotNet-klientmiljøer.

4) Parasoft SOAtest

Parasoft SOAtest er en test- og analyseverktøypakke utviklet for API- og API-drevet applikasjonstesting.

• Støtter webtjenester, REST, JSON, MQ, JMS, TIBCO, HTTP og XML-teknologier.
• Funksjonell, enhets-, integrasjons-, regresjons-, sikkerhets-, interoperabilitets-, samsvars- og ytelsestesting er mulig.
• Stubber kan opprettes ved hjelp av Parasoft Virtualize, som er dyktigere enn SoapUI MockServices.

Brukstilfeller for SOA-testing

Det utarbeidede eksemplet nedenfor anvender strategien, metodene og verktøyene ovenfor på et enkelt e-handelsnettsted, fase for fase.

Tenk deg et nettsted for e-handel som inneholder funksjonene og underfunksjonene nedenfor.

Ordrebehandling

Diagrammet nedenfor deler ordrebehandlingen inn i underfunksjonene som blir tjenester.

FASE 1

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

La oss se på tjenestene nedenfor i søknaden.

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

Forretningsfunksjonene er de samme som nettstedets funksjoner.

Merk: Teststrategidokumentet vil inneholde en liste over tjenestene og funksjonene som må testes.

FASE 2

Dette er testplanleggingsfasen. Testtilfeller er skrevet for hvert nivå.

Ende til ende-nivå. Testtilfellene er skrevet for hvert forretningsbrukstilfelle og flyt. Nedenfor finner du eksempler på testtilfeller.

• Opprett en bestilling med en aktiv bruker.
• Opprett en ordre med en inaktiv bruker.
• Opprett en bestilling med et tilgjengelig produkt med bestillingskvantitet < tilgjengelig kvantitet.
• Opprett en bestilling med et tilgjengelig produkt med bestillingskvantum > tilgjengelig kvantum.
• Opprett en bestilling med flere varer.
• Kanseller en ordre helt.
• Avbryte en bestilling delvis.

Integrasjonsnivå. Testtilfeller er skrevet for integrering 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 bestilling med én enkelt vare. Bekreft at mengden av det tilgjengelige produktet reduseres med bestillingsbeløpet.
• Kontroller at statusen til ordren som vises i brukergrensesnittet er den samme som i databasen.
• Kanseller bestillingen og kontroller at statusen til bestillingen er endret i databasen.
• For en førstegangsbetaling, kontroller at betalingsdetaljene som er angitt i brukergrensesnittet er lagret i databasen.
• For å returnere betalinger, kontroller at betalingsdetaljene i databasen vises i brukergrensesnittet.

Servicenivå. Hver tjeneste testes 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 i databasen
3	Opprett ordre. Antall 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

Testutførelse bruker en bottom-up-tilnærming: testing på tjenestenivå gjøres først, deretter integrasjonsnivå og til slutt ende-til-ende-testing.

1) Servicenivå

La oss vurdere at SoapUI Verktøyet brukes til å teste applikasjonen. WSDL og URL blar inn i testvinduet til SoapUI, og forespørselen for hver tjeneste vises i forespørselsvinduet. Ved å endre dataene i henhold til testtilfellene på tjenestenivå, opprettes det forespørsler for hver testtilfelle.

Testsak	Be	Forventet respons
Opprett ordre. Antall varer = 1, Antall på ordre < Antall på databasen	x2 2	o3251 Vellykket
Opprett ordre. Antall varer > 1, Antall på ordre < Antall på database	y1 1 y2 3	o3251 Vellykket
Opprett ordre. Antall varer = 1, Antall på ordre > Antall på databasen	x23 200	null Mislykket
Sjekk ordrestatus. Status i databasen = Aktiv	o9876	Aktiv Vellykket
Sjekk ordrestatus. Status i databasen = Sendt	o9656	Sendt Vellykket
Sjekk ordrestatus. Ordre-ID = Ugyldig	y5686	null Mislykket
Sjekk produkttilgjengelighet. Antall produkter >0	d34	34 ja Vellykket
Sjekk produkttilgjengelighet. Antall produkter = 0	y34	0 ingen Vellykket
Sjekk produkttilgjengelighet. Produkt-ID = ugyldig	sder	Mislykket

2) Integrasjonsnivå

Testtilfellene på integrasjonsnivå kjøres på brukergrensesnittet og databasen. Opprett en ordre med ett enkelt element:

• En bruker åpner nettstedet.
• Brukeren går for å legge inn en bestilling.
• Brukeren velger et gyldig produkt og antall og lagrer bestillingen.
• En melding om at bestillingen er lagt inn skal vises.
• Brukeren åpner databasen og sjekker om bestillingsdetaljene er de samme som de som er lagt inn på nettsiden.

3) End to End-nivå

Forretningsflytene og brukstilfellene kjøres i brukergrensesnittet. Opprett en ordre med flere elementer:

• En bruker åpner nettstedet.
• Brukeren går for å legge inn en bestilling.
• Brukeren spør om et gyldig produkt og antall og legger dem til i handlekurven.
• Andre gyldige produkter legges til med gyldige antall, og bestillingen lagres. Betaling skjer via en ny betalingsmåte, og bestillingen legges inn.
• En melding som sier "Ordre plassert vellykket" skal vises.
• En tester bør validere at hele flyten fullføres uten dataforskyvning.

Spørsmål og svar