Vad är SOA-testning?
SOA (Service Oriented Architecture) Testing är en testning av SOA-arkitektonisk stil där applikationskomponenterna är utformade för att kommunicera via kommunikationsprotokoll typiskt över ett nätverk.
I den här handledningen lär du dig-
- Vad är SOA?
- Vad är service?
- SOA-testning
- Strategi för SOA-testning
- SOA-testmetoder
- Utmaningar i SOA-testning
- SOA-testverktyg
- Användningsfall för SOA-testning
Vad är SOA?
SOA är en metod för att integrera affärsapplikationer och processer tillsammans för att möta affärsbehoven.
Inom Software Engineering erbjuder SOA smidighet och flexibilitet i affärsprocesser. Ändringarna i processen eller applikationen kan riktas till en viss komponent utan att det påverkar hela systemet.
Programvaruutvecklarna i SOA antingen utvecklar eller köper bitar av program som kallas SERVICES.
Vad är service?
- Tjänster kan vara en funktionell applikationsenhet eller affärsprocess som kan återanvändas eller upprepas av någon annan applikation eller process.
(Till exempel, i ovanstående bild är Payment Gateway en tjänst som kan återanvändas av vilken e-handelssida som helst. När en betalning behöver gör ringer / begär e-handelssidan Payment Gateway-tjänsten. Efter betalning sker en gateway, ett svar skickas till e-handelswebbplatsen)
- Tjänsterna är lätta att montera och lätta att konfigurera om komponenter.
- Tjänster kan jämföras med byggstenar. De kan konstruera alla applikationer som behövs. Det är enkelt att lägga till och ta bort dem från applikationen eller affärsprocessen.
- Tjänster definieras mer av affärsfunktionen de utför snarare än som bitar av kod.
Webbservice
Webbtjänster är oberoende applikationskomponenter som finns tillgängliga via webben.
De kan publiceras, hittas och kan användas på webben. De kan kommunicera via internet.
- Tjänsteleverantören publicerar tjänsten på internet.
- Klienten söker efter en viss webbtjänst från webbtjänstregistret
- En URL och WSDL för den nödvändiga webbtjänsten returneras.
>> Med hjälp av WSDL och URL: en sker kommunikationen mellan tjänsteleverantören och den begärande via SOAP-meddelanden. <<
- När en konsument ringer en webbtjänst upprättas en HTTP-anslutning till leverantören.
Ett SOAP-meddelande skapas för att instruera leverantören att anropa den nödvändiga webbtjänstlogiken.
- Svaret från leverantören är ett SOAP-meddelande som kommer att bäddas in i HTTP-svaret. Detta HTTP-svar är det dataformat som är förståeligt för konsumentapplikationen.
Exempel
En hemsida på en webbplats och en sökmotor visar varje dagars väderrapport. Istället för att koda väderrapportdelen överallt kan en tjänst för väderrapport köpas från en leverantör och integreras i sidorna.
SOA-testning
SOA består av olika tekniker. Applikationer byggda med SOA har olika tjänster som är löst kopplade.
SOA-testning bör fokusera på tre systemlager
Tjänster lager
Detta lager består av tjänster, tjänster som exponeras av ett system som härrör från affärsfunktioner.
Till exempel -
Tänk på en wellnesswebbplats som består av
- Vikt Tracker
- Blodsockerspårare
- Blodtrycksspårare
Spårare visar respektive data och datum för inmatning. Tjänstelagret består av de tjänster som hämtar respektive data från databasen
- Weight Tracker-tjänst
- Service för blodsockerspårare
- Tjänsten för blodtrycksspårare
- Inloggningstjänst
Process Layer
Process Layer består av processer, insamling av tjänster som ingår i en enda funktionalitet.
Processerna kan vara en del av användargränssnittet (för ex - En sökmotor), en del av ett ETL-verktyg (för att hämta data från databasen).
Huvudfokus i detta lager kommer att vara i användargränssnitt och process.
Viktgränssnittets användargränssnitt och dess integration med databasen är det primära fokus.
Nedanstående funktioner kommer att övervägas
- Lägga till nya data
- Redigera befintlig data
- Skapa ny tracker
- Radera data
Konsumentskikt
Detta lager består huvudsakligen av användargränssnitt.
Baserat på skiktet fördelas testningen av en SOA-applikation i tre nivåer.
- Servicenivå
- Gränssnittsnivå
- Slut till slut-nivå
- Top Down-tillvägagångssätt används för testdesign.
- Bottom Up-metoden används för testutförande.
Strategi för SOA-testning
Testplaneringsmetod,
- Den fullständiga arkitekturen för applikationen bör förstås av SOA Testers.
- Applikationen måste delas upp i oberoende tjänster (Service, som har sin egen begäran och svarsstruktur och inte är beroende av någon annan tjänst för att bilda svar).
- Applikationsstrukturen måste omorganiseras i tre komponenter - Data, tjänster och front-end-applikationer.
- Alla komponenter måste analyseras noggrant, och affärsscenarierna bör kritiseras.
- Affärsscenarierna bör klassificeras som vanliga scenarier och applikationsspecifika scenarier.
- En spårbarhetsmatris bör utarbetas och alla testfall ska spåras till affärsscenarier.
Testkörningsmetod
- Varje servicekomponent bör testas.
- Integration Test av servicekomponenterna bör göras för att validera dataflödet genom tjänsterna och dataintegriteten.
- Systemtestning av hela modellen bör göras för att validera dataflödet mellan front-end-applikation och databas.
- Prestandatestning bör göras för finjustering och optimal prestanda.
SOA-testmetoder
1) Databaserad testning av affärsscenario,
- Olika affärsaspekter relaterade till systemet bör analyseras.
- Scenarier bör utvecklas baserat på integrationen av
- Olika webbtjänster i applikationen
- Webbtjänster och applikation.
- Datainställningen bör göras baserat på ovanstående scenarier.
- Datainställningar bör göras så att de också täcker scenarier från slut till slut.
2) Stubbar
- Dummy-gränssnitt kommer att skapas för att testa tjänster.
- Olika ingångar kan tillhandahållas via dessa gränssnitt och utgångarna kan valideras.
- När ett program använder ett gränssnitt till en extern tjänst, som inte testas (tredje parts tjänst), kan en stub skapas under Integration Testing.
3) Regressionstest
- Regressionstestning av applikationen bör göras när det finns flera versioner för att säkerställa systemens stabilitet och tillgänglighet.
- En omfattande regressionstestpaket kommer att skapas som täcker de tjänster som utgör en viktig del av applikationen.
- Denna testsvit kan återanvändas i flera versioner av projektet.
4) Test av servicenivå
Service Level Testing inkluderar testning av komponenten för funktionalitet, säkerhet, prestanda och interoperabilitet.
Varje tjänst måste testas först självständigt.
5) Funktionell testning
Funktionstestning bör göras på varje tjänst till
- Se till att tjänsten ger rätt svar på varje begäran.
- Rätt fel tas emot för förfrågningar med ogiltiga data, dåliga data etc.
- Kontrollera för varje begäran och svar för varje operation som tjänsten måste utföra under körning.
- Validera felmeddelandena när ett fel inträffar på server-, klient- eller nätverksnivå.
- Kontrollera att de mottagna svaren har rätt format.
- Verifiera att de mottagna uppgifterna om svaret motsvarar de begärda uppgifterna.
6) Säkerhetstestning
Säkerhetstestning av webbtjänsten är en viktig aspekt under testning av SOA-applikationen på servicenivå; detta säkerställer applikationens säkerhet.
Följande faktorer måste täckas under testningen:
- Branschstandard definierad av WS-säkerhetstestning bör följas av webbtjänsten.
- Säkerhetsåtgärder bör fungera felfritt.
- Kryptering av data och digitala signaturer på dokumenten
- Autentisering och auktorisering
- SQL Injection, Malware, XSS, CSRF, andra sårbarheter ska testas på XML.
- Denial of Service-attacker
7) Prestandatestning
Prestandatestning av tjänsten måste göras eftersom tjänsterna kan återanvändas och flera applikationer kan använda samma tjänst.
Följande faktorer beaktas under testningen:
- 8) Tjänstens prestanda och funktionalitet måste testas under tung belastning.
- Tjänstens prestanda måste jämföras när du arbetar individuellt och inom applikationen, det är kopplat till.
- Lasttestning av service bör utföras
- för att verifiera svarstiden
- för att kontrollera flaskhalsar
- för att verifiera användningen av CPU och minne
- att förutsäga skalbarhet
9) Integrationsnivåtestning
- Test av servicenivå säkerställer att endast tjänsterna fungerar korrekt individuellt, det garanterar inte att de kopplade komponenterna fungerar.
- Integrationstestning sker huvudsakligen med gränssnitt.
- Denna fas täcker alla möjliga affärsscenarier.
- Icke-funktionell testning av applikationen bör göras en gång till i denna fas. Säkerhet, efterlevnad och prestandatestning säkerställer systemets tillgänglighet och stabilitet i alla aspekter.
- Kommunikations- och nätverksprotokollen bör testas för att validera konsistensen av datakommunikationen mellan tjänsterna.
10) Testning från slut till slut
Denna fas säkerställer att applikationen bekräftar företagets krav både funktionellt och icke-funktionellt.
Nedanstående punkter säkerställs att testas under testning från slut till slut
- Alla tjänster fungerar som förväntat efter integrationen
- Undantagshantering
- Användargränssnitt för applikationen
- Korrekt dataflöde genom alla komponenter
- Affärsprocess
Utmaningar i SOA-testning
- Brist på gränssnitt för tjänster
- Testprocessen sträcker sig över flera system, vilket skapar komplexa databehov
- Applikationen är en samling av olika komponenter som tenderar att förändras. Behovet av regressionstest är oftare.
- På grund av flerskiktsarkitektur är det svårt att isolera defekter.
- Eftersom tjänsten kommer att användas i olika gränssnitt är det svårt att förutsäga belastning, vilket gör planering av prestandatest test.
- SOA är en samling heterogena tekniker. Testning av en SOA-applikation kräver personer med olika färdigheter som i sin tur ökar planering och genomförande.
- Eftersom applikationen är en integration av flera tjänster har säkerhetstester sin egen andel av elände. Validering av autentisering och auktorisering är ganska svårt.
SOA-testverktyg
Det finns många SOA-testverktyg tillgängliga på marknaden för att hjälpa testare att testa SOA-applikationer. Här är några av de populära SOA-testverktygen :
1) SOAP UI
"SOAP UI" är ett funktionellt testverktyg med öppen källkod för tjänster och API-testning.
- Desktop-applikation
- Stöder flera protokoll - SOAP, REST, HTTP, JMS, AMF, JDBC
- Webbtjänster kan utvecklas, inspekteras och åberopas.
- Kan också användas för belastningstestning, automatiseringstestning och säkerhetstestning
- Stubbar kan skapas av MockServices
- Webbtjänstförfrågningar och tester kan genereras automatiskt via dess webbtjänstklient.
- Ha inbyggda rapporteringsverktyg
- Utvecklat av SmartBear
2) iTKO LISA
"LISA" är en produktsvit som tillhandahåller en funktionell testlösning för distribuerade system som SOA.
- Kan också användas för regression, integration, belastning och prestandatestning.
- Utvecklat av iTKO (CA Technologies)
- Kan användas för att designa och utföra tester.
3) HP-servicetest
"Servicetest" är ett funktionellt testverktyg som stöder testning av både användargränssnitt och delade tjänster
- Både funktionella och prestanda test av tjänster kan göras med ett enda skript.
- Integrerad med HP QC.
- Den enorma mängden service och data kan hanteras.
- Stöder interoperabilitetstestning genom att simulera JEE-, AXIS- och DotNet-klientmiljöer.
- Utvecklat av HP.
4) Parasoft SOA-test
SOA Test är en test- och analysverktygssvit utvecklad för API- och API-applikationstestning.
- Stöder webbtjänster, REST, JSON, MQ, JMS, TIBCO, HTTP, XML-teknik.
- Funktionell, enhet, integration, regression, säkerhet, interoperabilitet, efterlevnad och prestandatestning är möjliga.
- Stubbar kan skapas med Parasoft Virtualize, som är intelligenta än SOAP UI.
- Utvecklat av ParaSoft
Användningsfall för SOA-testning
Tänk på en e-handelswebbplats som innehåller följande funktioner och underfunktioner:
Orderhantering
FAS 1
I den första fasen av SOA-testning, dvs. teststrategifas, delas applikationen upp i tjänster och affärsfunktioner.
Låt oss överväga nedan är tjänsterna i applikationen.
- Skapa order
- Kontrollera kundstatus
- Ändra orderstatus
- Kontrollera orderstatus
- Kontrollera lager
Affärsfunktioner är desamma som webbplatsens funktioner.
Obs! Teststrategidokumentet innehåller listan över tjänsten och de funktioner som måste testas.
FAS 2
Testplaneringsfas. Testfall skrivs för varje nivå.
- Slut till slut-nivå. Testfallet skrivs för varje affärsanvändningsfall och flöde.
Nedan följer exemplet med testfall
- Skapa en beställning med den aktiva användaren.
- Skapa en beställning med en inaktiv användare.
- Skapa en beställning med den tillgängliga produkten med orderkvantitet
- Skapa en beställning med tillgänglig produkt med orderkvantitet> tillgängligt antal.
- Skapa en beställning med flera artiklar
- Avbryt en beställning helt.
- Avbryt beställningen delvis.
- Integrationsnivå. Testfall skrivs för integration av databas och användargränssnitt.
Nedan följer exempel på testfall.
- Skapa en ny beställning med en enda artikel. Kontrollera att beställningen skapas i databasen.
- Skapa en ny beställning med en enda artikel. Kontrollera att det beräknade priset för beställningen är korrekt.
- Skapa en ny beställning med en enda artikel. Kontrollera att kvantiteten av den tillgängliga produkten är mindre med orderbeloppet.
- Kontrollera att statusen för ordern som visas i användargränssnittet är densamma som i databasen.
- Avbryt beställningen och verifiera att beställningens status ändras i databasen.
- För första gången betalning, kontrollera att betalningsinformationen som anges i användargränssnittet sparas i databasen.
- För att returnera betalningar, kontrollera att betalningsinformationen i databasen visas i användargränssnittet.
- Servicenivå. Varje tjänst testas för alla dataförhållanden.
Nedan följer några exempel.
Nej. | Orderdetaljer | Beställningsvillkor |
---|---|---|
1 | Skapa order. Antal artiklar = 1 | Antal på beställning |
2 | Skapa order. Antal artiklar> 1 | Antal på beställning |
3 | Skapa orderantal artiklar = 1 | Antal på beställning> Antal i databas |
4 | Kontrollera orderstatus | Status i databas = Aktiv |
5 | Kontrollera orderstatus | Status i databas = levereras |
6 | Kontrollera orderstatus | Status i databas = Avbruten |
7 | Kontrollera orderstatus | Order-id = Ogiltigt |
8 | Kontrollera tillgängligheten | Produktmängd> 0 |
9 | Kontrollera tillgängligheten | Mängd produkt = 0 |
10 | Kontrollera tillgängligheten | Produkt-id = ogiltigt |
FAS 3 - Testutförande
Testkörning använder bottom-up-tillvägagångssätt, dvs. testning av servicenivå görs först, sedan integrationsnivå och äntligen testning från slut till slut.
1) Servicenivå
Låt oss överväga att Soapui-verktyget övervägs för att testa applikationen.
WSDL och URL bläddras in i testfönstret i SOAP.
Begäran för varje tjänst kommer att visas i förfrågningsfönstret.
Genom att modifiera data enligt testfallet på servicenivå skapas förfrågningar för varje testfall.
Testfall |
Begäran |
Förväntat svar |
---|---|---|
Skapa order. Antal artiklar = 1 Antal på beställning |
|
|
Skapa beställning. av artiklar> 1Mängd på beställning |
|
|
Skapa OrderNr. av artiklar = 1 Antal på beställning> Antal på db |
|
|
Kontrollera orderstatus i databas = aktiv |
|
|
Kontrollera orderstatus i databas = levereras |
|
|
Kontrollera orderstatus Beställnings-id = Ogiltig |
|
|
Kontrollera produktens tillgänglighet Mängden produkt> 0 |
|
|
Kontrollera produktens tillgänglighet Mängden produkt = 0 |
|
|
Kontrollera produktens tillgänglighet Produkt-id = ogiltig |
|
|
2) Integrationsnivå
Integreringsnivå testfall utförs på användargränssnittet och databasen.
- Skapa en beställning med en enda artikel -
- En användare öppnar webbplatsen.
- Går att göra en beställning.
- Väljer en giltig produkt och kvantitet och sparar beställningen.
- Ett meddelande om att beställningen är framgångsrikt bör visas.
- En användare öppnar databasen och kontrollerar om detaljerna i ordern är desamma som de som anges på webbplatsen.
3) Avsluta till slutnivå
Affärsflöden och användningsfall utförs i användargränssnittet.
- Skapa en beställning med flera artiklar -
- En användare öppnar en webbplats.
- Går att göra en beställning.
- Frågar om en giltig produkt och kvantitet lägger till dem i kundvagnen.
- Andra giltiga produkter läggs till med giltiga kvantiteter och beställningen sparas. Betalning sker via en ny betalningsmetod och beställning görs.
- Ett meddelande som säger "Order beställt framgångsrikt" ska visas.
- En testare bör verifiera att hela flödet sker utan att data snedställs.
Slutsats:
Genom att skissa rätt strategi för testning, resurser, verktyg och efterlevnad för att ge bra service kan SOA-test leverera fullständigt och perfekt testad applikation.