Wat is SOA-testen? Tutorial met voorbeeld

Wat is SOA-testen?

SOA (Servicegericht ArchiTesten is het testen van een SOA-architectuurstijl waarbij de applicatiecomponenten zijn ontworpen om te communiceren via communicatieprotocollen, meestal via een netwerk.

Wat is SOA?

SOA is een methode om bedrijfsapplicaties en -processen met elkaar te integreren om aan de bedrijfsbehoeften te voldoen.

Bij Software Engineering biedt SOA wendbaarheid en flexibiliteit aan bedrijfsprocessen. De wijzigingen in het proces of de applicatie kunnen op een bepaald onderdeel worden gericht, zonder dat dit het hele systeem beïnvloedt.

De softwareontwikkelaars in SOA ontwikkelen of kopen stukjes programma, genaamd DIENSTEN.

Wat is Dienstverlening?

• Services kunnen een functionele eenheid van een applicatie of bedrijfsproces zijn, die kan worden hergebruikt of herhaald door elke andere applicatie of proces. (In de bovenstaande afbeelding is Payment Gateway bijvoorbeeld een service die kan worden hergebruikt door elke e-commercesite. Telkens wanneer een betaling moet worden uitgevoerd, roept/vraagt ​​de e-commercesite de Payment Gateway-service aan. Nadat de betaling via een gateway is voltooid, wordt een antwoord naar de e-commercewebsite verzonden)
• Services zijn eenvoudig te monteren en eenvoudig te herconfigureren van componenten.
• Diensten kun je vergelijken met bouwstenen. Ze kunnen elke gewenste applicatie bouwen. Het toevoegen en verwijderen ervan uit de applicatie of het bedrijfsproces is eenvoudig.
• Services worden meer gedefinieerd door de bedrijfsfunctie die ze uitvoeren dan door stukjes code.

Web Services

Webservices zijn onafhankelijke applicatiecomponenten die via internet beschikbaar zijn.

Ze kunnen worden gepubliceerd, gevonden en gebruikt op internet. Ze kunnen communiceren via internet.

1. De Dienstverlener publiceert de dienst op internet.
2. Klant zoekt naar een bepaalde webdienst vanuit het Webserviceregister
3. Er worden een URL en de WSDL voor de vereiste webservice geretourneerd. Met behulp van de WSDL en de URL vindt de communicatie tussen de serviceprovider en de aanvrager plaats via SOAP-berichten.
4. Wanneer een consument een webservice belt, wordt er een HTTP-verbinding met de provider tot stand gebracht.
   Er wordt een SOAP-bericht gemaakt om de provider te instrueren de vereiste webservicelogica aan te roepen.
5. Het antwoord dat van de provider wordt ontvangen, is een SOAP-bericht dat in het HTTP-antwoord wordt ingebed. Dit HTTP-antwoord is het gegevensformaat dat begrijpelijk is voor de consumententoepassing.

Voorbeeld

Een startpagina van een website en een zoekmachine toont het dagelijkse weerbericht. In plaats van de weerrapportsectie helemaal opnieuw te coderen, kan een service voor weerrapporten worden gekocht bij een leverancier en in de pagina's worden geïntegreerd.

SOA-testen

SOA bestaat uit verschillende technologieën. Applicaties die met SOA zijn gebouwd, hebben verschillende services die losjes met elkaar zijn gekoppeld.

SOA-testen moeten zich richten op 3 systeemlagen

Dienstenlaag

Deze laag bestaat uit de services, services die worden ontsloten door een systeem dat is afgeleid van bedrijfsfuncties.

Bijvoorbeeld -

Overweeg een welzijnswebsite die bestaat uit

1. Gewichtstracker
2. Bloedsuikertracker
3. Bloeddruk Tracker

Trackers geven de betreffende gegevens en de datum weer waarop ze zijn ingevoerd. De serviceslaag bestaat uit de services die de respectieve gegevens uit de database halen.

• Gewichtstracker-service
• Bloedsuikertracker-service
• Bloeddruktracker-service
• Login-service

Proceslaag

Process Layer bestaat uit de processen, een verzameling services die deel uitmaken van één functionaliteit.

De processen kunnen een onderdeel zijn van de gebruikersinterface (bijvoorbeeld een zoekmachine), een onderdeel van een ETL-tool (voor het verkrijgen van gegevens uit de database).

De nadruk in deze laag ligt vooral op gebruikersinterfaces en processen.

De gebruikersinterface van de gewichtstracker en de integratie ervan met de database staan ​​centraal.

Onderstaande functies zullen van belang zijn

1. Nieuwe gegevens toevoegen
2. Bestaande gegevens bewerken
3. Nieuwe tracker maken
4. Gegevens verwijderen

Consumentenlaag

Deze laag bestaat voornamelijk uit gebruikersinterfaces.

Op basis van de laag wordt het testen van een SOA-applicatie verdeeld over drie niveaus.

1. Service Level
2. Interface niveau
3. Eind-tot-eindniveau

• Bij het ontwerpen van tests wordt een Top Down-aanpak gebruikt.
• Bij de testuitvoering wordt een bottom-up-aanpak gebruikt.

Strategie voor SOA-testen

Testplanning aanpak,

• De SOA-testers moeten de volledige architectuur van de applicatie begrijpen.
• De applicatie moet worden opgesplitst in onafhankelijke services (Service, die zijn eigen verzoek- en antwoordstructuur heeft en niet afhankelijk is van een andere service om een ​​antwoord te vormen).
• De applicatiestructuur moet worden gereorganiseerd in drie componenten: data, services en front-endapplicaties.
• Alle componenten moeten zorgvuldig worden geanalyseerd en er moeten bedrijfsscenario's worden uitgewerkt.
• De bedrijfsscenario's moeten worden geclassificeerd als algemene scenario's en toepassingsspecifieke scenario's.
• A Traceerbaarheid Matrix moeten worden voorbereid en alle testgevallen moeten worden herleid tot bedrijfsscenario's.

Testuitvoeringsaanpak

• Elk serviceonderdeel moet worden getest.
• Integratietesten van de servicecomponenten moet worden gedaan om de gegevensstroom door de services en de gegevensintegriteit te valideren.
• Systeem testen van het volledige model moet worden gedaan om de gegevensstroom tussen front-endapplicatie en database te valideren.
• Performance Testing moet worden gedaan voor fijnafstemming en optimale prestaties.

SOA-testmethoden

1) Op bedrijfsscenario’s gebaseerd testen op basis van data,

• Verschillende zakelijke aspecten die verband houden met het systeem moeten worden geanalyseerd.
• Scenario's moeten worden ontwikkeld op basis van de integratie van
• Diverse Web services van de aanvraag
• Webservices en applicatie.
• Het instellen van de gegevens moet gebeuren op basis van de bovenstaande scenario's.
• Het opzetten van de gegevens moet zo gebeuren dat ook end-to-end-scenario's worden gedekt.

2) Stompen

• Er zullen dummy-interfaces worden gemaakt om services te testen.
• Via deze interfaces kunnen verschillende inputs worden geleverd en de outputs kunnen worden gevalideerd.
• Wanneer een applicatie een interface gebruikt met een externe service, die niet wordt getest (service van derden), kan tijdens de integratietest een stub worden gemaakt.

3) Regressietesten

• Regressie Testing over de applicatie moet worden gedaan als er meerdere releases zijn om de stabiliteit en beschikbaarheid van de systemen te garanderen.
• Er zal een uitgebreide regressietestsuite worden gecreëerd die de diensten omvat die een belangrijk onderdeel van de applicatie vormen.
• Deze testsuite kan in meerdere releases van het project worden hergebruikt.

4) Testen van het serviceniveau

Bij Service Level Testing worden componenten getest op functionaliteit, beveiliging, prestaties en interoperabiliteit.

Elke service moet eerst onafhankelijk worden getest.

5) Functioneel testen

Voor elke service moeten functionele tests worden uitgevoerd

• Zorg ervoor dat de service op elk verzoek het juiste antwoord geeft.
• Er worden juiste fouten ontvangen voor verzoeken met ongeldige gegevens, slechte gegevens, enz.
• Controleer voor elke aanvraag en elk antwoord elke bewerking die de service tijdens runtime moet uitvoeren.
• Valideer de foutmeldingen wanneer er een fout optreedt op server-, client- of netwerkniveau.
• Controleer of de ontvangen antwoorden de juiste indeling hebben.
• Valideer dat de ontvangen gegevens op het antwoord overeenkomen met de gevraagde gegevens.

6) Beveiligingstesten

Het testen van de beveiliging van de webservice is een belangrijk aspect tijdens het testen van het serviceniveau van de SOA-applicatie; dit garandeert de veiligheid van de applicatie.

Tijdens het testen moeten de volgende factoren in acht worden genomen:

• De industriestandaard die is gedefinieerd door WS-Security-tests moet door de webservice worden nageleefd.
• Beveiligingsmaatregelen moeten feilloos werken.
• Versleuteling van gegevens en Digihandtekeningen op de documenten
• Authenticatie en authorisatie
• SQL Injection, Malware, XSS, CSRF en andere kwetsbaarheden moeten op de XML worden getest.
• Denial of Service-aanvallen

7) Prestatietesten

Prestatietests van de service moeten worden uitgevoerd, omdat de services herbruikbaar zijn en meerdere applicaties mogelijk dezelfde service gebruiken.

Tijdens het testen wordt rekening gehouden met de volgende factoren:

• Prestaties en functionaliteit van de dienst moeten onder zware belasting worden getest.
• De prestaties van de dienst moeten zowel individueel als binnen de applicatie worden vergeleken.
• Er moeten belastingtests van de service worden uitgevoerd
• om de responstijd te verifiëren
• om te controleren op knelpunten
• om het gebruik van CPU en geheugen te verifiëren
• schaalbaarheid te voorspellen

8) Testen op integratieniveau

• Service level testen garanderen alleen de goede werking van de services afzonderlijk, maar garanderen niet de werking van de gekoppelde componenten.
• Integratietesten worden voornamelijk gedaan op de interfaces.
• Deze fase omvat alle mogelijke bedrijfsscenario's.
• In deze fase dient het Niet-Functioneel testen van de applicatie nog een keer te worden uitgevoerd. Beveiliging, compliance en prestatietests garanderen de beschikbaarheid en stabiliteit van het systeem in alle aspecten.
• De communicatie- en netwerkprotocollen moeten worden getest om de consistentie van de datacommunicatie tussen de diensten te valideren.

9) End-to-end-testen

Deze fase zorgt ervoor dat de applicatie zowel functioneel als niet-functioneel voldoet aan de bedrijfsvereisten.

Er wordt gegarandeerd dat de onderstaande items worden getest tijdens de end-to-end-tests

• Alle services werken zoals verwacht na integratie
• Afhandeling van uitzonderingen
• Gebruikersinterface van de applicatie
• Een goede gegevensstroom door alle componenten
• Bedrijfsproces

Uitdagingen bij SOA-testen

• Gebrek aan interfaces voor services
• Het testproces beslaat meerdere systemen, waardoor complexe databehoeften ontstaan
• De applicatie is een verzameling van verschillende componenten die de neiging hebben te veranderen. De behoefte aan regressietesten komt vaker voor.
• Vanwege de meerlaagse architectuur is het moeilijk om defecten te isoleren.
• Omdat de dienst in verschillende interfaces zal worden gebruikt, is het moeilijk om de belasting te voorspellen, waardoor het plannen van prestatietests lastig wordt.
• SOA is een verzameling heterogene technologieën. Het testen van een SOA-applicatie vereist mensen met verschillende vaardigheden, wat op zijn beurt de plannings- en uitvoeringskosten verhoogt.
• Omdat de applicatie een integratie is van meerdere services, brengt het testen van de beveiliging zijn eigen problemen met zich mee. Validatie van authenticatie en autorisatie is behoorlijk lastig.

Gebruiksscenario's voor SOA-testen

Overweeg een e-commercewebsite, die de onderstaande functies en subfuncties bevat:

Orderverwerking

FASE 1

In de eerste fase van SOA-testen, dat wil zeggen de teststrategiefase, wordt de applicatie opgesplitst in services en bedrijfsfuncties.

Laten we hieronder eens kijken naar de services in de applicatie.

• Maak een bestelling
• Controleer de klantstatus
• Bestelstatus wijzigen
• Controleer de bestelstatus
• Controleer inventaris

Bedrijfsfuncties zijn dezelfde als de functies van de Website.

Opmerking: Het teststrategiedocument zou de lijst bevatten van de dienst en de functies die moeten worden getest.

FASE 2

Fase van testplanning. Voor elk niveau worden testgevallen geschreven.

1. Eind-tot-eindniveau. De testcases worden voor elke business use case en flow geschreven. Hieronder staan ​​voorbeelden van testgevallen
   • Maak een bestelling aan met de actieve gebruiker.
   • Maak een bestelling aan met een inactieve gebruiker.
   • Maak een bestelling aan met het beschikbare product met bestelhoeveelheid < beschikbare hoeveelheid.
   • Maak een bestelling aan met het beschikbare product met bestelhoeveelheid > beschikbare hoeveelheid.
   • Maak een bestelling aan met meerdere artikelen
   • Een bestelling volledig annuleren.
   • Bestelling gedeeltelijk annuleren.
2. Integratie niveau. Testcases zijn geschreven voor integratie van database en gebruikersinterface. Hieronder vindt u voorbeeldtestgevallen.
   • Maak een nieuwe bestelling aan met één artikel. Controleer of de bestelling in de database is aangemaakt.
   • Maak een nieuwe bestelling aan met één artikel. Controleer of de berekende prijs voor de bestelling correct is.
   • Maak een nieuwe bestelling aan met één artikel. Controleer of de hoeveelheid van het beschikbare product kleiner is dan het bestelbedrag.
   • Controleer of de status van de bestelling die in de gebruikersinterface wordt weergegeven, overeenkomt met die in de database.
   • Annuleer de bestelling en controleer of de status van de bestelling in de database is gewijzigd.
   • Controleer bij de eerste betaling of de betalingsgegevens die u in de gebruikersinterface invoert, in de database zijn opgeslagen.
   • Controleer bij het retourneren van betalingen of de betalingsgegevens in de database worden weergegeven in de gebruikersinterface.
3. Service Level. Elke service wordt getest op alle gegevensomstandigheden.

Hieronder vindt u enkele voorbeelden.

Nr.	Bestel Details	Bestelconditie
1	Orde creëren. Aantal artikelen = 1	Aantal op bestelling < Aantal op database
2	Orde creëren. Aantal artikelen > 1	Aantal op bestelling < Aantal in database.
3	Bestelnummer van artikelen aanmaken = 1	Aantal op bestelling > Aantal in database
4	Controleer de bestelstatus	Status op database = Actief
5	Controleer de bestelstatus	Status in database = Verzonden
6	Controleer de bestelstatus	Status op database = Geannuleerd
7	Controleer de bestelstatus	Bestellings-ID = Ongeldig
8	Controleer de beschikbaarheid van het product	Hoeveelheid product >0
9	Controleer de beschikbaarheid van het product	Hoeveelheid product =0
10	Controleer de beschikbaarheid van het product	Product-ID = ongeldig

FASE 3 – Testuitvoering

Testuitvoering maakt gebruik van een bottom-up aanpak, dat wil zeggen dat eerst het testen van het serviceniveau wordt uitgevoerd, daarna op integratieniveau en als laatste End-to-end testen.

1) Serviceniveau

Laten we dat overwegen Zeep tool wordt overwogen voor het testen van de applicatie.

De wsdl en URL worden in het testvenster van SOAP gebladerd.

De aanvraag voor elke service wordt weergegeven in het aanvraagvenster.

Door de gegevens aan te passen volgens de serviceniveau-testgevallen, worden er voor elke testgeval verzoeken aangemaakt.

Testgeval	Aanvraag	Verwachte reactie
Orde creëren. Aantal artikelen = 1Aantal op bestelling < Aantal op db	x2 2	o3251 Succesvol
Bestelnr. aanmaken Aantal artikelen > 1Aantal op bestelling < Aantal op db	j1 1 j2 3	o3251 Succesvol
Bestelnr. aanmaken aantal artikelen = 1Aantal op bestelling > Aantal op db	x23 200	nul Mislukt
Controleer de bestelstatusStatus op database = Actief	o9876	Actief Succesvol
Controleer de bestelstatusStatus in de database = Verzonden	o9656	Verzonden Succesvol
Controleer de status van de bestellingBestellings-id = Ongeldig	y5686	nul Mislukt
Controleer de productbeschikbaarheidAantal product >0	d34	34 Ja Succesvol
Controleer de productbeschikbaarheidAantal product =0	j34	0 Nee Succesvol
Controleer de productbeschikbaarheidProduct-ID = ongeldig	sder	Mislukt

2) Integratieniveau

De testgevallen op integratieniveau worden uitgevoerd op de gebruikersinterface en database.

• Creëer een bestelling met één enkel artikel –
• Een gebruiker opent de website.
• Gaat een bestelling plaatsen.
• Selecteert een geldig product en aantal en slaat de bestelling op.
• Er zou een bericht moeten verschijnen dat de bestelling succesvol is geplaatst.
• Een gebruiker opent de database en controleert of de gegevens van de bestelling overeenkomen met de gegevens die op de website zijn ingevoerd.

3) Eind-tot-eindniveau

De bedrijfsstromen en use cases worden uitgevoerd op de gebruikersinterface.

• Maak een bestelling aan met meerdere artikelen –
• Een gebruiker opent een website.
• Gaat een bestelling plaatsen.
• Vraagt ​​naar een geldig product en de hoeveelheid, voegt deze toe aan de winkelwagen.
• Andere geldige producten worden toegevoegd met geldige hoeveelheden en de bestelling wordt opgeslagen. De betaling gebeurt via een nieuwe betaalmethode en de bestelling is geplaatst.
• Er zou een bericht moeten verschijnen met de tekst “Bestelling succesvol geplaatst”.
• Een tester moet valideren dat de gehele stroom wordt uitgevoerd zonder dat de gegevens worden vertekent.

Conclusie

Door de juiste strategie voor testen, middelen, tools en compliance te schetsen om goede service te bieden, kan SOA-testen een volledig en perfect geteste applicatie opleveren.