Hva er SOA-testing?
SOA (Service Oriented Architecture) Testing er en testing av SOA-arkitektonisk stil der applikasjonskomponentene er designet for å kommunisere via kommunikasjonsprotokoller vanligvis over et nettverk.
I denne veiledningen vil du lære-
- Hva er SOA?
- Hva er service?
- SOA-testing
- Strategi for SOA-testing
- SOA-testmetoder
- Utfordringer i SOA-testing
- SOA-testverktøy
- Brukstilfeller for SOA-testing
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 i forretningsprosesser. Endringene i prosessen eller applikasjonen kan rettes til en bestemt komponent uten å påvirke hele systemet.
Programvareutviklerne i SOA utvikler eller kjøper biter av programmer kalt SERVICES.
Hva er service?
- Tjenester kan være en funksjonell applikasjonsenhet eller forretningsprosess, som kan gjenbrukes eller gjentas av andre applikasjoner eller prosesser.
(For eksempel, i bildet ovenfor, er Payment Gateway en tjeneste som kan brukes på nytt av et hvilket som helst e-handelssted. Når en betaling trenger å gjøre, ringer / ber e-handelssiden om betaling Gateway-tjenesten. Etter at betalingen er gjort på en gateway, et svar sendes til e-handelsnettstedet)
- Tjenester er enkle å montere og enkle å konfigurere komponenter.
- Tjenester kan sammenlignes med byggesteiner. De kan konstruere alle applikasjoner 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 biter av kode.
Nettjenester
Webtjenester er uavhengige applikasjonskomponenter, som er tilgjengelige over nettet.
De kan publiseres, finnes og kan brukes på nettet. De kan kommunisere via internett.
- Tjenesteleverandøren publiserer tjenesten på internett.
- Klienten søker etter en bestemt webtjeneste fra Web Service Registry
- En URL og WSDL for den nødvendige nettjenesten returneres.
>> Ved bruk av WSDL og URL-en skjer kommunikasjonen mellom tjenesteleverandøren og forespørselen gjennom SOAP-meldinger. <<
- Når en forbruker ringer til en webtjeneste, opprettes en HTTP-forbindelse til leverandøren.
Det opprettes en SOAP-melding for å instruere leverandøren om å påkalle den nødvendige weblogistikken.
- Svaret mottatt fra leverandøren er en SOAP-melding som vil bli innebygd i HTTP-responsen. Dette HTTP-svaret er dataformatet som er forståelig av forbrukerapplikasjonen.
Eksempel
En hjemmeside på et nettsted og en søkemotor viser hverdagsrapporter. I stedet for å kode værmeldingsseksjonen overalt, kan en tjeneste for værrapport kjøpes fra en leverandør og integreres i sidene.
SOA-testing
SOA består av ulike teknologier. Applikasjoner bygget med 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
- Vekt tracker
- Blood Sugar Tracker
- Blodtrykksmåler
Sporere viser de respektive dataene og datoen de er angitt. Services-laget består av tjenestene som får de respektive dataene fra databasen
- Weight Tracker-tjeneste
- Blood Sugar Tracker-tjeneste
- Tjeneste for blodtrykkssporing
- Påloggingstjeneste
Prosesslag
Process Layer består av prosesser, samling 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).
Hovedfokuset i dette laget vil være i brukergrensesnitt og prosess.
Vektmålerens brukergrensesnitt og integrering med databasen er det primære fokuset.
Nedenfor vil funksjonene være viktig
- Legge til nye data
- Redigere eksisterende data
- Opprette ny tracker
- Slette data
Forbrukerlag
Dette laget består hovedsakelig av brukergrensesnitt.
Basert på laget er testingen av en SOA-applikasjon fordelt på tre nivåer.
- Service nivå
- Grensesnittnivå
- End to End level
- Top Down-tilnærming brukes til testdesign.
- Bottom Up-tilnærming brukes til testutførelse.
Strategi for SOA-testing
Testplanleggingsmetode,
- Den komplette arkitekturen til applikasjonen skal forstås av SOA Testers.
- Søknaden må deles inn i uavhengige tjenester (Service, som har sin egen forespørsel og responsstruktur og ikke er avhengig av noen annen tjeneste for å danne svar).
- Applikasjonsstrukturen må omorganiseres i tre komponenter - Data, Services og front-end applikasjoner.
- Alle komponentene må analyseres nøye, og forretningsscenarier bør kritiseres.
- Virksomhetsscenariene bør klassifiseres som vanlige scenarier og applikasjonsspesifikke scenarier.
- En sporbarhetsmatrise bør utarbeides, og alle testtilfeller skal spores til forretningsscenarier.
Testutførelsesmetode
- Hver servicekomponent bør testes.
- Integrasjon Testing av tjenestekomponentene bør gjøres for å validere dataflyten gjennom tjenestene og dataintegriteten.
- Systemtesting av den komplette modellen skal gjøres for å validere dataflyten mellom front-end-applikasjon og database.
- Ytelsestesting bør gjøres for finjustering og optimal ytelse.
SOA-testmetoder
1) forretningsscenadrevet databasert testing,
- Ulike forretningsaspekter knyttet til systemet bør analyseres.
- Scenarier bør utvikles basert på integrering av
- Ulike nettjenester av applikasjonen
- Webtjenester og applikasjoner.
- Datasett skal gjøres basert på scenariene ovenfor.
- Datasett skal gjøres slik at det også dekker slutt-til-slutt-scenarier.
2) Stubber
- Dummy-grensesnitt vil bli opprettet for å teste tjenester.
- Ulike innganger kan leveres gjennom disse grensesnittene, og utgangene kan valideres.
- Når et program bruker et grensesnitt til en ekstern tjeneste, som ikke er under test (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 stabiliteten og tilgjengeligheten til systemene.
- Det vil bli opprettet en omfattende regresjonstestpakke som dekker tjenestene som utgjør en viktig del av applikasjonen.
- Denne testpakken kan brukes på nytt i flere utgivelser av prosjektet.
4) Testing av servicenivå
Service Level Testing inkluderer testing av komponenten for funksjonalitet, sikkerhet, ytelse og interoperabilitet.
Hver 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.
- Rett feil mottas for forespørsler med ugyldige data, dårlige data osv.
- Se etter hver forespørsel og svar for hver operasjon tjenesten må utføre i løpetid.
- Valider feilmeldingene når det oppstår en feil på server-, klient- eller nettverksnivå.
- Bekreft at mottatte svar er i riktig format.
- Bekreft at dataene som er mottatt på svaret tilsvarer de forespurte dataene.
6) Sikkerhetstesting
Sikkerhetstesting av nettjenesten er et viktig aspekt under testing av SOA-applikasjonen på servicenivå; Dette sikrer applikasjonens sikkerhet.
Følgende faktorer må dekkes under testing:
- Industristandard definert av WS-sikkerhetstesting bør overholdes av nettjenesten.
- Sikkerhetstiltak skal fungere feilfritt.
- Kryptering av data og digitale 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 er gjenbrukbare og flere applikasjoner kan bruke den samme tjenesten.
Følgende faktorer vurderes under testingen:
- 8) Ytelsen og funksjonaliteten til tjenesten må testes under tung 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 å verifisere responstid
- for å se etter flaskehalser
- for å verifisere bruken av CPU og minne
- å forutsi skalerbarhet
9) Integrering nivå testing
- Testing av servicenivå sikrer at bare tjenestene fungerer korrekt hver for seg, og det garanterer ikke at de koblede komponentene fungerer.
- Integrasjonstesting gjøres med hovedvekt på grensesnittene.
- Denne fasen dekker alle mulige forretningsscenarier.
- Den ikke-funksjonelle testen 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.
10) Test til slutt til slutt
Denne fasen sørger for at applikasjonen bekrefter virksomhetens krav både funksjonelt og ikke-funksjonelt.
Elementene nedenfor er sikret å bli testet under test til slutt
- Alle tjenester fungerer som forventet etter integrering
- Avvikshåndtering
- Brukergrensesnitt for applikasjonen
- Riktig datastrøm gjennom alle komponentene
- Forretningsprosess
Utfordringer i SOA-testing
- Mangel på grensesnitt for tjenester
- Testprosessen spenner over flere systemer og skaper dermed komplekse behov for data
- Søknaden er en samling av forskjellige komponenter som har en tendens til å endres. Behovet for regresjonstesting er hyppigere.
- På grunn av flerlagsarkitektur er det vanskelig å isolere feil.
- Siden tjenesten vil bli brukt i forskjellige grensesnitt, er det vanskelig å forutsi belastning, og dermed gjør planlegging av ytelsestest tungvint.
- SOA er en samling av heterogene teknologier. Testing av en SOA-applikasjon krever mennesker med forskjellige ferdighetssett som igjen øker planleggings- og gjennomføringskostnadene.
- Siden applikasjonen er en integrasjon av flere tjenester, har sikkerhetstesting sin egen andel av elendighet. Validering av autentisering og autorisasjon er ganske vanskelig.
SOA-testverktøy
Det er mange SOA-testverktøy tilgjengelig i markedet for å hjelpe testere med å teste SOA-applikasjoner. Her er noen av de populære SOA-testverktøyene :
1) SOAP UI
"SOAP UI" er et funksjonelt testverktøy med åpen kildekode for tjenester og API-testing.
- Desktop-applikasjon
- Støtter flere protokoller - SOAP, REST, HTTP, JMS, AMF, JDBC
- Webtjenester kan utvikles, inspiseres og påberopes.
- Kan også brukes til belastningstesting, automatiseringstesting og sikkerhetstesting
- Stubber kan opprettes av MockServices
- Webtjenesteforespørsler og tester kan genereres automatisk gjennom webtjenesteklienten.
- Ha innebygde rapporteringsverktøy
- Utviklet av SmartBear
2) iTKO LISA
"LISA" er en produktserie som gir en funksjonell testløsning for distribuerte systemer som SOA.
- Kan også brukes til regresjon, integrering, belastning og ytelsestesting.
- Utviklet av iTKO (CA Technologies)
- Kan brukes til å designe og utføre tester.
3) HP servicetest
"Service Test" er et funksjonelt testverktøy, som støtter både UI og testing av delte tjenester
- Både funksjonell og ytelsestest av tjenester kan gjøres med ett enkelt skript.
- Integrert med HP QC.
- Den enorme mengden service og data kan administreres.
- Støtter interoperabilitetstesting ved å simulere JEE, AXIS og DotNet klientmiljøer.
- Utviklet av HP.
4) Parasoft SOA-test
SOA Test er en test- og analyseverktøysuite utviklet for testing av API- og API-applikasjoner.
- Støtter webtjenester, REST, JSON, MQ, JMS, TIBCO, HTTP, XML-teknologier.
- Funksjonell, enhet, integrering, regresjon, sikkerhet, interoperabilitet, samsvar og ytelsestesting er mulig.
- Stubber kan opprettes ved hjelp av Parasoft Virtualize, som er intelligente enn SOAP UI.
- Utviklet av ParaSoft
Brukstilfeller for SOA-testing
Vurder et netthandelsnettsted som inneholder funksjonene nedenfor og underfunksjoner:
Ordrebehandling
FASE 1
I den første fasen av SOA-testing, dvs. teststrategifase, er applikasjonen delt inn i tjenester og forretningsfunksjoner.
La oss vurdere nedenfor er tjenestene i applikasjonen.
- Opprett ordre
- Sjekk kundestatus
- Endre ordrestatus
- Sjekk ordrestatus
- Sjekk varelager
Forretningsfunksjoner er de samme som funksjonene til nettstedet.
Merk: Teststrategidokumentet inneholder listen over tjenesten og funksjonene som må testes.
FASE 2
Testplanleggingsfase. Prøvesaker skrives for hvert nivå.
- End to End level. Testsakene er skrevet for hver forretningsbrukssak og flyt.
Nedenfor er eksemplet med testsaker
- Lag en ordre med den aktive brukeren.
- Opprett en ordre med en inaktiv bruker.
- Opprett en ordre med tilgjengelig produkt med bestillingsmengde
- Opprett en ordre med det tilgjengelige produktet med ordremengde> tilgjengelig antall.
- Lag en ordre med flere varer
- Avbryt en bestilling helt.
- Avbryt bestillingen delvis.
- Integreringsnivå. Test tilfeller er skrevet for integrering av database og brukergrensesnitt.
Nedenfor er eksempler på testtilfeller.
- Opprett en ny ordre med en enkelt vare. Bekreft at bestillingen er opprettet i databasen.
- Opprett en ny ordre med en enkelt vare. Bekreft 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 for bestillingen som vises i brukergrensesnittet, er den samme som i databasen.
- Avbryt bestillingen og bekreft at statusen for bestillingen er endret i databasen.
- For første gangs betaling må du kontrollere at betalingsdetaljene som er angitt i brukergrensesnittet, er lagret i databasen.
- For å returnere betalinger må du kontrollere at betalingsdetaljene i databasen vises i brukergrensesnittet.
- Service nivå. Hver tjeneste testes for alle dataforholdene.
Nedenfor er noen eksempler.
| Nei. | Ordre detaljer | Bestillingsbetingelse |
|---|---|---|
| 1 | Opprett ordre. Antall gjenstander = 1 | Mengde på bestilling |
| 2 | Opprett ordre. Antall gjenstander> 1 | Mengde på bestilling |
| 3 | Opprett bestillingsnummer = 1 | Mengde på bestilling> Mengde 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 | Bestillings-id = ugyldig |
| 8 | Sjekk tilgjengeligheten av produktet | Mengde produkt> 0 |
| 9 | Sjekk tilgjengeligheten av produktet | Mengde produkt = 0 |
| 10 | Sjekk tilgjengeligheten av produktet | Produkt-id = ugyldig |
FASE 3 - Testutførelse
Testutførelse bruker bottom-up-tilnærming, dvs. testnivå på tjenesten utføres først, deretter integreringsnivå og til slutt test til slutt til slutt.
1) Servicenivå
La oss vurdere at Soapui-verktøy vurderes for å teste applikasjonen.
WSDL og URL er gjennomsøkt i testvinduet til SOAP.
Forespørselen for hver tjeneste vises i forespørselsvinduet.
Ved å endre dataene i henhold til testnivåene i tjenestenivå, opprettes forespørsler for hver testsak.
|
Testforsøk |
Be om |
Forventet svar |
|---|---|---|
|
Opprett ordre. Antall varer = 1 Antall på bestilling |
|
|
|
Opprett ordre. av varer> 1Mengde på bestilling |
|
|
|
Opprett ordrenr. av varer = 1Antall på bestilling> Mengde på db |
|
|
|
Kontroller ordrestatus i databasen = aktiv |
|
|
|
Sjekk ordrestatus i databasen = sendt |
|
|
|
Sjekk ordrestatus Bestillings-id = ugyldig |
|
|
|
Sjekk produkttilgjengelighet Mengde produkt> 0 |
|
|
|
Sjekk produkttilgjengelighet Mengde produkt = 0 |
|
|
|
Sjekk tilgjengeligheten av produktet Produkt-id = ugyldig |
|
|
2) Integreringsnivå
Integreringsnivå testtilfeller utføres på brukergrensesnittet og databasen.
- Opprett en ordre med en enkelt vare -
- En bruker åpner nettstedet.
- Går for å bestille.
- Velger et gyldig produkt og antall og lagrer bestillingen.
- En melding som sier at bestillingen er vellykket, skal vises.
- En bruker åpner database og sjekker om detaljene i bestillingen er de samme som de som er angitt på nettstedet.
3) End to End level
Forretningsflyter og brukssaker kjøres på brukergrensesnittet.
- Lag en ordre med flere varer -
- En bruker åpner et nettsted.
- Går for å bestille.
- 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 via en ny betalingsmåte og bestilling blir plassert.
- En melding som sier "Bestilling vellykket" skal vises.
- En tester bør validere at hele flyten er gjort uten skjevhet av data.
Konklusjon:
Ved å skisse den riktige strategien for testing, ressurser, verktøy og samsvar for å gi god service, kan SOA-testing levere fullstendig og perfekt testet applikasjon.