Wat is SOA-testen? Tutorial met voorbeeld

Wat is SOA-testen?

SOA (Servicegericht Architecture) Testen is het testen van SOA archistructuurstijl waarin de applicatiecomponenten zijn ontworpen om te communiceren via communicatieprotocollen, doorgaans via een netwerk.

In deze tutorial leer je-

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?

Leer SOA-testen

  • 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.

Leer SOA-testen

Leer SOA-testen

  1. De Dienstverlener publiceert de dienst op internet.
  2. Klant zoekt naar een bepaalde webdienst vanuit het Webserviceregister
  3. Er wordt 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 om 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.

Leer SOA-testen

SOA-testen

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

Leer SOA-testen

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.

Leer SOA-testen

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 integrale archiDe SOA-testers moeten de structuur 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

Service Level Testing omvat het testen van de component 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 elk verzoek en antwoord voor 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.

De following factoren waarmee tijdens het testen rekening moet worden gehouden:

  • De industriestandaard die is gedefinieerd door WS-Security-tests moet door de webservice worden nageleefd.
  • Beveiligingsmaatregelen moeten feilloos werken.
  • Versleuteling van gegevens en digitale handtekeningen 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.

De following Tijdens het testen wordt rekening gehouden met 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 omvat meerdere systemen, waardoor complex gegevensbehoeften
  • De applicatie is een verzameling van verschillende componenten die de neiging hebben te veranderen. De behoefte aan regressietesten komt vaker voor.
  • Dankzij meerlagen archituur 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 heterogeneneoons technologieën. Voor het testen van een SOA-applicatie zijn mensen met verschillende vaardigheden nodig, 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.

SOA-testtools

Er zijn veel SOA-testtools op de markt beschikbaar om testers te helpen bij het testen van SOA-applicaties. Hier zijn enkele van de populaire SOA-testtools:

1) SOAP-gebruikersinterface

“SOAP UI” is een open source functionele testtool voor services en API-testen.

  • Desktop applicatie
  • Ondersteunt meerdere protocollen – SOAP, REST, HTTP, JMS, AMF, JDBC
  • Webservices kunnen worden ontwikkeld, geïnspecteerd en opgeroepen.
  • Kan ook worden gebruikt voor belastingtests, Automatisering testenen beveiligingstests
  • Stubs kunnen worden gemaakt door MockServices
  • Webserviceverzoeken en -tests kunnen automatisch worden gegenereerd via de webserviceclient.
  • Zorg voor ingebouwde rapportagetools
  • Ontwikkeld door SmartBear

2) iTKO LISA

“LISA” is een productsuite die een functionele testoplossing biedt voor gedistribueerde systemen zoals SOA.

  • Kan ook worden gebruikt voor regressie-, integratie-, belasting- en prestatietests.
  • Ontwikkeld door iTKO (CA Technologies)
  • Kan worden gebruikt voor het ontwerpen en uitvoeren van tests.

3) HP-servicetest

“Service Test” is een functionele testtool, die zowel het testen van de UI als het testen van gedeelde services ondersteunt

  • Zowel functionele als prestatietests van services kunnen met één enkel script worden uitgevoerd.
  • Geïntegreerd met HP QC.
  • De enorme hoeveelheid service en gegevens kan worden beheerd.
  • Ondersteunt interoperabiliteitstests door JEE-, AXIS- en DotNet-clientomgevingen te simuleren.
  • Ontwikkeld door HP.

4) Parasoft SOA-test

SOA Test is een test- en analysetoolsuite ontwikkeld voor het testen van API- en API-applicaties.

  • Ondersteunt webservices, REST, JSON, MQ, JMS, TIBCO, HTTP, XML-technologieën.
  • Functioneel, Unit, Integratie, Regressie, Beveiliging, Interoperabiliteit, Compliance en Performance Testing zijn mogelijk.
  • Stubs kunnen worden gemaakt met behulp van Parasoft Virtualize, die intelligenter zijn dan de SOAP UI.
  • Ontwikkeld door ParaSoft

Gebruiksscenario's voor SOA-testen

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

Orderverwerking

Leer SOA-testen

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 zijn geschreven voor elke business use case en flow. Hieronder staan ​​voorbeelden van testcases
    • 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 staan ​​voorbeeldtestcases.
    • 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, dezelfde is als 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 betaling details ingevoerd op de gebruikersinterface wordt opgeslagen in de database.
    • Voor het retourneren van betalingen dient u te verifiëren dat de betaling details 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.

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

Het verzoek voor elke dienst wordt weergegeven in het verzoekvenster.

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 details van de bestelling zijn dezelfde als die ingevoerd op de website.
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 hele stroom zonder ske wordt uitgevoerdwing Van de gegevens.

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.