Vad är SOA-testning? Handledning med exempel

Vad är SOA-testning?

SOA (serviceorienterad Architecture) Testing är en testning av SOA-arkitektonisk stil där applikationskomponenterna är designade för att kommunicera via kommunikationsprotokoll vanligtvis över ett nätverk.

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 ger SOA smidighet och flexibilitet till affärsprocesser. Ändringarna i processen eller applikationen kan riktas till en viss komponent utan att påverka hela systemet.

Mjukvaruutvecklarna i SOA antingen utvecklar eller köper bitar av program som kallas TJÄNSTER.

Vad är service?

• Tjänster kan vara en funktionell enhet av applikation eller affärsprocess, som kan återanvändas eller upprepas av vilken annan applikation eller process som helst. (Till exempel, i bilden ovan är Payment Gateway en tjänst som kan återanvändas av vilken e-handelsplats som helst. Närhelst en betalning behöver göras, ringer/begär e-handelswebbplatsen Payment Gateway-tjänsten. Efter att betalning har gjorts på en gateway skickas ett svar till e-handelswebbplatsen)
• Tjänsterna är lätta att montera och lätta att omkonfigurera komponenter.
• Tjänster kan jämföras med byggstenar. De kan konstruera vilken applikation som helst. Det är enkelt att lägga till och ta bort dem från applikationen eller affärsprocessen.
• Tjänster definieras mer av den affärsfunktion de utför snarare än som bitar av kod.

Web Services

Webbtjänster är oberoende applikationskomponenter som är tillgängliga över webben.

De kan publiceras, hittas och användas på webben. De kan kommunicera via internet.

1. Tjänsteleverantören publicerar tjänsten på internet.
2. Klienten söker efter en viss webbtjänst från webbtjänstregistret
3. En URL och WSDL för den nödvändiga webbtjänsten returneras. Med hjälp av WSDL och URL:n sker kommunikationen mellan tjänsteleverantören och begäranden genom SOAP-meddelanden.
4. 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.
5. Svaret som tas emot 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 av konsumentapplikationen.

Exempelvis

En hemsida för en webbplats och en sökmotor visar vardagliga väderrapporter. Istället för att koda väderrapportsektionen överallt, kan en Service of väderrapport köpas från en leverantör och integreras i sidorna.

SOA-testning

SOA består av olika teknologier. Applikationer byggda med SOA har olika tjänster som är löst kopplade.

SOA-testning bör fokusera på 3 systemlager

Tjänster lager

Detta lager består av tjänsterna, tjänster som exponeras av ett system som härrör från affärsfunktioner.

Till exempel -

Överväg en Wellness-webbplats som består av

1. Vikt Tracker
2. Spårare för blodsocker
3. Blodtrycksmätare

Spårare visar respektive data och datum för inmatning. Tjänsteskiktet består av tjänsterna som hämtar respektive data från databasen–

• Viktspårningstjänst
• Blodsockerspårningstjänst
• Blodtrycksmätningstjänst
• Inloggningstjänst

Processlager

Process Layer består av processer, samling av tjänster som är en del av en enda funktionalitet.

Processerna kan vara en del av användargränssnittet (till exempel – En sökmotor), en del av ett ETL-verktyg (för att hämta data från databasen).

Huvudfokus i detta lager kommer att ligga på användargränssnitt och process.

Användargränssnittet för viktspåraren och dess integration med databasen är det primära fokus.

Nedanstående funktioner kommer att beaktas

1. Lägger till ny data
2. Redigera befintliga data
3. Skapar ny tracker
4. Raderar data

Konsumentlager

Detta lager består huvudsakligen av användargränssnitt.

Baserat på lagret är testningen av en SOA-applikation uppdelad i tre nivåer.

1. Servicenivå
2. Gränssnittsnivå
3. End to End nivå

• Top Down-metoden används för testdesign.
• Bottom Up-metoden används för testkörning.

Strategi för SOA-testning

Testplaneringsmetod,

• Den fullständiga arkitekturen för applikationen bör förstås av SOA-testarna.
• Applikationen måste delas upp i oberoende tjänster (tjänst, som har sin egen förfrågnings- 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, Services och front-end-applikationer.
• Alla komponenter måste analyseras noggrant och affärsscenarier bör kritas ut.
• Affärsscenarierna bör klassificeras som vanliga scenarier och applikationsspecifika scenarier.
• A Spårbarhetsmatris bör förberedas och alla testfall bör spåras till affärsscenarier.

Metod för testexekvering

• Varje servicekomponent bör testas.
• Integrationstestning av tjänstekomponenterna bör göras för att validera dataflödet genom tjänsterna och dataintegriteten.
• Kravhantering av hela modellen bör göras för att validera dataflödet mellan front-end-applikation och databas.
• Prestandatester bör göras för finjustering och optimal prestanda.

SOA-testmetoder

1) Affärsscenariodriven databaserad testning,

• Olika affärsaspekter relaterade till systemet bör analyseras.
• Scenarier bör utvecklas baserat på integration av
• Övrigt Webbtjänster av ansökan
• Webbtjänster och applikation.
• Datainställning bör göras baserat på ovanstående scenarier.
• Datainställningen bör göras så att den även täcker scenarier från början till slut.

2) Stubbar

• Dummy-gränssnitt kommer att skapas för att testa tjänster.
• Olika ingångar kan tillhandahållas genom dessa gränssnitt, och utgångarna kan valideras.
• När en applikation använder ett gränssnitt till en extern tjänst, som inte testas (tredjepartstjänst), kan en stubb skapas under Integrationstestning.

3) Regressionstestning

• Regressionstestning på applikationen bör göras när det finns flera utgåvor för att säkerställa stabiliteten och tillgängligheten för systemen.
• En omfattande regressionstestsvit 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 först testas oberoende.

5) Funktionstestning

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 ogiltig data, dålig 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 uppstår på server-, klient- eller nätverksnivå.
• Bekräfta att de inkomna svaren är i rätt format.
• Verifiera att uppgifterna som mottagits på svaret motsvarar de begärda uppgifterna.

6) Säkerhetstestning

Säkerhetstestning av webbtjänsten är en viktig aspekt under servicenivåtestning av SOA-applikationen; detta garanterar applikationens säkerhet.

Följande faktorer måste täckas under testet:

• Branschstandard som definieras av WS-Security-testning bör följas av webbtjänsten.
• Säkerhetsåtgärder bör fungera felfritt.
• Kryptering av data och Digital 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 är återanvändbara och flera applikationer kan använda samma tjänst.

Följande faktorer beaktas under testningen:

• Tjänstens prestanda och funktionalitet måste testas under hög belastning.
• Tjänstens prestanda måste jämföras samtidigt som man arbetar individuellt och inom applikationen, den är kopplad till.
• Belastningstestning av service bör utföras
• för att verifiera svarstiden
• för att se efter flaskhalsar
• för att verifiera användningen av CPU och minne
• för att förutsäga skalbarhet

8) Integrationsnivåtestning

• Servicenivåtestning säkerställer att endast tjänsterna fungerar korrekt, det garanterar inte att de kopplade komponenterna fungerar.
• Integrationstestning görs med fokus främst på gränssnitten.
• Denna fas täcker alla möjliga affärsscenarier.
• Den icke-funktionella testningen 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 överensstämmelsen i datakommunikationen mellan tjänsterna.

9) Slut till slut-testning

Denna fas säkerställer att applikationen bekräftar affärskraven både funktionellt och icke-funktionellt.

Nedanstående artiklar är säkerställda att testas under slut-till-änd-testning

• Alla tjänster fungerar som förväntat efter integration
• 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 regressionstestning är mer frekvent.
• På grund av flerskiktsarkitekturen ä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 belastningen, vilket gör att planeringen av prestandatest blir besvärlig.
• SOA är en samling heterogena teknologier. Att testa en SOA-applikation kräver personer med olika kompetenser vilket i sin tur ökar planerings- och genomförandekostnaderna.
• Eftersom applikationen är en integration av flera tjänster har säkerhetstester sin egen del av elände. Validering av autentisering och auktorisering är ganska svårt.

Användningsfall för SOA-testning

Överväg en e-handelswebbplats som innehåller följande funktioner och underfunktioner:

Orderhantering

FASE 1

I den första fasen av SOA-testning, dvs. teststrategifasen, är applikationen uppdelad i tjänster och affärsfunktioner.

Låt oss överväga nedan är tjänsterna i ansökan.

• Skapa ordning
• Kontrollera kundstatus
• Ändra orderstatus
• Kontrollera Order Status
• Kontrollera lager

Affärsfunktioner är desamma som funktionerna på webbplatsen.

Notera: Teststrategidokumentet skulle innehålla listan över tjänsten och de funktioner som måste testas.

FASE 2

Testplaneringsfas. Testfall skrivs för varje nivå.

1. End to End nivå. Testfallen skrivs för varje affärsanvändningsfall och flöde. Nedan visas exempel på 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 beställningskvantitet < tillgänglig kvantitet.
   • Skapa en beställning med den tillgängliga produkten med beställningskvantitet > tillgänglig kvantitet.
   • Skapa en beställning med flera artiklar
   • Avbryt en beställning helt.
   • Avbryt beställningen delvis.
2. Integrationsnivå. Testfall är skrivna för integration av databas och användargränssnitt. Nedan finns exempel på testfall.
   • Skapa en ny beställning med en enda vara. Kontrollera att beställningen är skapad i databasen.
   • Skapa en ny beställning med en enda vara. Kontrollera att priset som beräknats för beställningen är korrekt.
   • Skapa en ny beställning med en enda vara. Kontrollera att kvantiteten av den tillgängliga produkten är mindre med beställningsbeloppet.
   • Kontrollera att statusen för beställningen som visas i användargränssnittet är densamma som i databasen.
   • Avbryt beställningen och kontrollera att beställningens status har ändrats i databasen.
   • För första gången du betalar, verifiera att betalningsinformationen som anges i användargränssnittet är sparad i databasen.
   • För att returnera betalningar, kontrollera att betalningsinformationen i databasen visas i användargränssnittet.
3. Servicenivå. Varje tjänst testas för alla dataförhållanden.

Nedan följer några exempel.

Nej.	Beställningsuppgifter	Beställningsskick
1	Skapa beställning. Antal artiklar = 1	Antal på beställning < Antal på databas
2	Skapa beställning. Antal artiklar > 1	Kvantitet på beställning < Kvantitet på databas.
3	Skapa ordernummer för artiklar = 1	Kvantitet på beställning > Kvantitet på databas
4	Kontrollera orderstatus	Status på databas = Aktiv
5	Kontrollera orderstatus	Status på databas = Skickas
6	Kontrollera orderstatus	Status på databas = Avbruten
7	Kontrollera orderstatus	Order-id = Ogiltigt
8	Kontrollera produktens tillgänglighet	Produktkvantitet >0
9	Kontrollera produktens tillgänglighet	Produktens kvantitet =0
10	Kontrollera produktens tillgänglighet	Produkt-id = ogiltigt

FAS 3 – Testexekvering

Testexekvering använder en bottom-up-metod, dvs. servicenivåtestning görs först, sedan integrationsnivå och till sist Slut till slut-testning.

1) Servicenivå

Låt oss överväga det Soapui verktyget övervägs för att testa applikationen.

Smakämnen wsdl och URL bläddras in i SOAPs testfönster.

Begäran för varje tjänst kommer att visas i beställningsfönstret.

Genom att modifiera data enligt testfallen på servicenivå skapas förfrågningar för varje testfall.

Testfall	FÖRFRÅGAN	Förväntat svar
Skapa beställning. Antal artiklar = 1Antal på beställning < Antal på db	x2 2	o3251 Framgångsrik
Skapa order.nr. av artiklar > 1Antal på beställning < Antal på db	y1 1 y2 3	o3251 Framgångsrik
Skapa ordernr. av artiklar = 1Antal på beställning > Antal på db	x23 200	null Misslyckad
Kontrollera OrderstatusStatus på databas = Aktiv	o9876	Aktiva Framgångsrik
Kontrollera orderstatusStatus på databas = Skickat	o9656	Skickas Framgångsrik
Kontrollera orderstatusOrder-id = Ogiltigt	y5686	null Misslyckad
Kontrollera produktens tillgänglighet Antal produkt >0	d34	34 ja Framgångsrik
Kontrollera produktens tillgänglighet Antal produkt =0	y34	0 Nej Framgångsrik
Kontrollera produkttillgänglighet Produkt-id = ogiltigt	sder	Misslyckad

2) Integrationsnivå

Testfallen på integrationsnivån exekveras på användargränssnittet och databasen.

• Skapa en beställning med en enda vara –
• En användare öppnar webbplatsen.
• Går för att lägga en beställning.
• Väljer en giltig produkt och kvantitet och sparar beställningen.
• Ett meddelande som säger att beställningen har genomförts ska visas.
• En användare öppnar databas och kontrollerar om detaljerna för beställningen är desamma som de som anges på webbplatsen.

3) End to End nivå

Affärsflöden och användningsfall exekveras på användargränssnittet.

• Skapa en beställning med flera artiklar –
• En användare öppnar en webbplats.
• Går för att lägga en beställning.
• Frågar om en giltig produkt och antal lägger dem i kundvagnen.
• Övriga giltiga produkter läggs till med giltiga kvantiteter och beställningen sparas. Betalning sker genom ett nytt betalningssätt och beställning görs.
• Ett meddelande som säger "Beställningen har gjorts framgångsrikt" ska visas.
• En testare bör validera att hela flödet görs utan skevhet av data.

Slutsats

Genom att skissa på rätt strategi för testning, resurser, verktyg och efterlevnad för att ge bra service kan SOA-testning leverera en fullständigt och perfekt testad applikation.