Vad är SOA-testning? Handledning med exempel

Vad är SOA-testning?

SOA (serviceorienterad Archistruktur) Testning är testning av SOA-arkitekturstilen, där applikationskomponenterna är utformade 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.

In Mjukvaruutveckling, SOA ger affärsprocesser flexibilitet och smidighet. En förändring av en process eller applikation kan riktas mot en viss komponent utan att påverka hela systemet.

Programvaruutvecklare som arbetar inom SOA utvecklar eller köper antingen programbitar som kallas tjänster.

Vad är service?

Diagrammet nedan visar en betalningsgateway publicerad som en tjänst som flera e-handelssajter kan anropa.

• En tjänst kan vara en funktionell enhet i en applikation eller en 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-handelswebbplats som helst. När en betalning behöver göras ringer eller begär e-handelswebbplatsen Payment Gateway-tjänsten. När betalningen är slutförd på gatewayen skickas ett svar tillbaka 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, och det är enkelt att lägga till eller ta bort dem från applikationen eller affärsprocessen.
• Tjänster definieras mer av den affärsfunktion de utför än som kodbitar.

Web Services

De flesta SOA-tjänster exponeras som webbtjänster, så mekaniken bakom ett webbtjänstanrop är värd att redogöra för före testlagren.

Webbtjänster är oberoende applikationskomponenter som är tillgängliga via webben.

De kan publiceras, hittas och användas på webben, och de kommunicerar via internet. Sekvensen nedan visar hur en leverantör, ett register och en konsument interagerar.

• Tjänsteleverantören publicerar tjänsten på internet.
• Klienten söker efter en specifik webbtjänst i webbtjänstregistret.
• A URL och wsdl för den erforderliga webbtjänsten returneras. Med hjälp av WSDL och URL, kommunikationen mellan tjänsteleverantören och den som begär det sker via SOAP-meddelanden.
• När en konsument anropar 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 som tas emot från leverantören är ett SOAP-meddelande som är inbäddat i HTTP-svaret. Detta HTTP-svar är det dataformat som konsumentapplikationen förstår.

Exempelvis

Skärmdumpen nedan visar en väderrapport från en extern tjänst som är inbäddad på en sökmotors hemsida.

Hemsidan för en webbplats och en sökmotor visar en daglig väderrapport. Istället för att koda väderrapportssektionen från grunden kan en väderrapportstjänst köpas från en leverantör och integreras i sidorna.

SOA-testlager

SOA består av olika teknologier, och applikationer byggda med SOA har olika tjänster som är löst kopplade till varandra. Diagrammet nedan kartlägger de tre lager som en testplan måste täcka.

SOA-testning bör fokusera på tre systemlager.

Tjänster lager

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

Tänk dig till exempel en hälsowebbplats som består av:

• Vikt Tracker
• Blodsocker Tracker
• Blood Pressure Tracker

Trackers visar respektive data och datumet de matades in. Tjänstelagret består av de tjänster som hämtar respektive data från databasen:

• Vikt Tracker-tjänst
• Blodsocker Tracker-tjänst
• Blood Pressure Tracker-tjänst
• Inloggningstjänst

Processlager

Processlagret består av processerna, samlingen av tjänster som ingår i en enda funktionalitet.

Processerna kan vara en del av ett användargränssnitt (till exempel en sökmotor) eller en del av ett ETL-verktyg som hämtar data från databasen.

Huvudfokus i detta lager ligger på användargränssnitt och processer. Viktens användargränssnitt tracker och dess integration med databasen är det primära fokuset.

Följande funktioner är av betydelse:

• Lägger till ny data
• Redigera befintliga data
• Skapa ett nytt tracker
• Raderar data

Konsumentlager

Detta lager består huvudsakligen av användargränssnitt, vilket skärmen nedan illustrerar.

Baserat på dessa lager är testningen av en SOA-applikation uppdelad i tre nivåer:

• Servicenivå
• Gränssnittsnivå
• End to End nivå

De två färdriktningarna skiljer sig åt: en top-down-metod används för testdesign, medan en bottom-up-metod används för testutförande.

Strategi för SOA-testning

Testplaneringsmetod

• SOA-testare bör förstå applikationens fullständiga arkitektur.
• Applikationen behöver delas upp i oberoende tjänster (en tjänst som har sin egen struktur för förfrågningar och svar och inte är beroende av någon annan tjänst för att skapa ett svar).
• Applikationsstrukturen behöver omorganiseras i tre komponenter – data, tjänster och frontend-applikationer.
• Alla komponenter måste analyseras noggrant och affärsscenarier bör kartläggas.
• Affärsscenarierna bör klassificeras som vanliga scenarier och applikationsspecifika scenarier.
• A Tracförmågasmatris bör förberedas, och alla testfall bör tracanpassad 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 den kompletta modellen bör göras för att validera dataflödet mellan frontend-applikationen och databasen.
• Prestandatester bör göras för finjustering och optimal prestanda.

SOA-testmetoder

1) Databaserad testning baserad på affärsscenarier

• Olika affärsaspekter relaterade till systemet bör analyseras.
• Scenarier bör utvecklas baserat på integrationen av applikationens olika webbtjänster, och av webbtjänster med applikationen.
• Datauppsättningen bör göras baserat på ovanstående scenarier.
• Datauppsättningen bör också täcka scenarier från början till slut.

2) Stubbar

• Dummy-gränssnitt 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 (en tredjepartstjänst) kan en stub 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 systemens stabilitet och tillgänglighet.
• 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å

Servicenivåtestning inkluderar testning av komponenten för funktionalitet, säkerhet, prestanda och interoperabilitet. Varje tjänst måste först testas oberoende av varandra.

5) Funktionstestning

funktions~~POS=TRUNC bör göras vid varje tjänst för att:

• Säkerställ att tjänsten levererar rätt svar på varje förfrågan.
• Säkerställ att rätt fel tas emot för förfrågningar med ogiltiga eller felaktiga data.
• Kontrollera varje begäran och svar för varje åtgärd som tjänsten måste utföra vid 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.
• Kontrollera att de data som mottagits i svaret motsvarar de begärda uppgifterna.

6) Säkerhetstestning

Säkerhetstestning av webbtjänsten är en viktig aspekt vid servicenivåtestning av SOA-applikationen, eftersom det säkerställer applikationens säkerhet.

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

• Webbtjänsten bör följa den branschstandard som definieras av WS-Security.
• Säkerhetsåtgärder bör fungera felfritt.
• Kryptering av data och digitala signaturer på dokumenten.
• Autentisering och auktorisering.
• SQL-injektion, skadlig kod, XSS, CSRF och andra sårbarheter ska testas på XML.
• Denial of service-attacker.

7) Prestandatestning

Prestandatestning av tjänsten behöver göras eftersom tjänster ä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 behöver jämföras när den fungerar individuellt och när den är kopplad inom applikationen.
• Lasttestning av tjänsten bör utföras för att verifiera svarstid, kontrollera flaskhalsar, verifiera utnyttjandet av CPU och minne samt förutsäga skalbarhet.

8) Integrationsnivåtestning

• Servicenivåtestning säkerställer att tjänsterna fungerar korrekt individuellt; det garanterar inte att de kopplade komponenterna fungerar.
• Integrationstestning utförs med huvudsaklig fokus på gränssnitt.
• Denna fas täcker alla möjliga affärsscenarier.
• Icke-funktionell testning av applikationen bör göras ytterligare en gång i denna fas. Säkerhets-, efterlevnads- 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 uppfyller affärskraven, både funktionellt och icke-funktionellt.

Nedanstående punkter garanteras att testas under test från slut till slut:

• Alla tjänster fungerar som förväntat efter integration
• Undantagshantering
• Applikationens användargränssnitt
• Korrekt dataflöde genom alla komponenter
• Affärsprocess

Utmaningar inom SOA-testning

Att tillämpa dessa metoder är sällan enkelt, och svårigheterna nedan återkommer i nästan alla SOA-program.

• Brist på gränssnitt för tjänster.
• Testprocessen omfattar flera system, vilket skapar komplexa databehov.
• Applikationen är en samling av olika komponenter som tenderar att förändras, så behovet av regressionstestning är mer frekvent.
• På grund av flerskiktsarkitekturen är det svårt att isolera defekter.
• Eftersom en tjänst används av olika gränssnitt är belastningen svår att förutsäga, vilket gör planeringen av prestandatester 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 integrerar flera tjänster har säkerhetstestning sin beskärda del av problem. Validering av autentisering och auktorisering är svårt.

SOA-testverktyg

Det finns många SOA-testverktyg tillgängliga på marknaden som kan hjälpa testare att testa SOA-applikationer. Här är några av de populära SOA-testverktygen.

1) SoapUI

SoapUI är ett verktyg för funktionstestning med öppen källkod för tjänster och API-testning.

• Skrivbordsapplikation
• Stöder flera protokoll — SOAP, REST, HTTP, JMS, AMF, JDBC
• Webbtjänster kan utvecklas, inspekteras och anropas.
• Kan även användas för belastningstestning, Automationstestningoch säkerhetstestning
• Stubbar kan skapas av MockServices
• Webbtjänstförfrågningar och tester kan genereras automatiskt via dess webbtjänstklient.
• Har inbyggda rapporteringsverktyg
• Utvecklad av SmartBear, som levererar både öppen källkod SoapUI distribution och kommersiell ReadyAPI edition

2) Broadcom Service Virtualization (tidigare iTKO LISA)

LISA är en produktsvit som tillhandahåller en funktionell testlösning för distribuerade system som SOA. Produkten överfördes från iTKO till CA Technologies och säljs idag som Broadcom Service Virtualization.

• Kan även användas för regressions-, integrations-, belastnings- och prestandatestning.
• Kan användas för att designa och utföra tester.

3) UFT Ett (tidigare HP Service Test)

Service Test är ett funktionellt testverktyg som stöder både UI- och delade tjänster-testning. Dess API-testfunktion integrerades i Unified Functional Testing, som nu säljs av OpenText as UFT En.

• Både funktionella och prestandatester av tjänster kan utföras med ett enda skript.
• Integrerat med Quality Center, säljs nu som OpenText ALM / Kvalitetscenter.
• En enorm mängd tjänster och data kan hanteras.
• Stöder interoperabilitetstestning genom att simulera JEE-, AXIS- och DotNet-klientmiljöer.

4) Parasoft SOAtest

Parasoft SOAtest är en test- och analysverktygssvit utvecklad för API- och API-driven applikationstestning.

• Stöder webbtjänster, REST, JSON, MQ, JMS, TIBCO, HTTP och XML-teknik.
• Funktionstestning, enhetstestning, integrationstestning, regressionstestning, säkerhetstestning, interoperabilitetstestning, efterlevnadstestning och prestandatestning är möjliga.
• Stubbar kan skapas med hjälp av Parasoft Virtualize, som är mer kapabla än SoapUI MockServices.

Användningsfall för SOA-testning

Det bearbetade exemplet nedan tillämpar strategin, metoderna och verktygen ovan på en enda e-handelswebbplats, fas för fas.

Tänk dig en e-handelswebbplats som innehåller funktionerna och delfunktionerna nedan.

Orderhantering

Diagrammet nedan delar upp orderhanteringen i de delfunktioner som blir tjänster.

FASE 1

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

Låt oss titta på tjänsterna nedan i applikationen.

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

Affärsfunktionerna är desamma som webbplatsens funktioner.

Obs: Teststrategidokumentet skulle innehålla en lista över de tjänster och funktioner som måste testas.

FASE 2

Detta är testplaneringsfasen. Testfall är skrivna för varje nivå.

Nivå från början till slut. Testfallen är skrivna för varje affärsanvändningsfall och flöde. Nedan följer exempel på testfall.

• Skapa en order med en aktiv användare.
• Skapa en beställning med en inaktiv användare.
• Skapa en order med en tillgänglig produkt med orderkvantitet < tillgänglig kvantitet.
• Skapa en order med en tillgänglig produkt med orderkvantitet > tillgänglig kvantitet.
• Skapa en beställning med flera artiklar.
• Avbryt en beställning helt.
• Avbryta en beställning 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 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 artikel. Kontrollera att kvantiteten av den tillgängliga produkten minskas med orderbeloppet.
• Kontrollera att statusen för ordern 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 en förstagångsbetalning, kontrollera att betalningsuppgifterna 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.	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	Antal på order < Antal i databasen
3	Skapa beställning. Antal 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 — Testkörning

Testkörning använder en bottom-up-metod: servicenivåtestning görs först, sedan integrationsnivå och slutligen end-to-end-testning.

1) Servicenivå

Låt oss betrakta att SoapUI verktyget används för att testa applikationen. WSDL och URL bläddras in i testfönstret för SoapUI, och begäran för varje tjänst visas i begäranfönstret. Genom att modifiera data enligt testfallen på servicenivå skapas begäranden för varje testfall.

Testfall	FÖRFRÅGAN	Förväntat svar
Skapa order. Antal artiklar = 1, Antal på order < Antal på databas	x2 2	o3251 Framgångsrik
Skapa order. Antal artiklar > 1, Antal på order < Antal på databas	y1 1 y2 3	o3251 Framgångsrik
Skapa order. Antal artiklar = 1, Antal på order > Antal på databas	x23 200	null Misslyckad
Kontrollera orderstatus. Status i databasen = Aktiv	o9876	Aktiv Framgångsrik
Kontrollera orderstatus. Status i databasen = Levererad	o9656	Skickat Framgångsrik
Kontrollera orderstatus. Order-ID = Ogiltigt	y5686	null Misslyckad
Kontrollera produkttillgänglighet. Produktkvantitet >0	d34	34 ja Framgångsrik
Kontrollera produkttillgänglighet. Produktens kvantitet = 0	y34	0 Nej Framgångsrik
Kontrollera produkttillgänglighet. Produkt-ID = ogiltigt	sder	Misslyckad

2) Integrationsnivå

Testfallen på integrationsnivå körs på användargränssnittet och databasen. Skapa en order med ett enda objekt:

• En användare öppnar webbplatsen.
• Användaren går för att lägga en beställning.
• Användaren väljer en giltig produkt och kvantitet och sparar beställningen.
• Ett meddelande om att beställningen har lagts bör visas.
• Användaren öppnar databasen och kontrollerar om beställningsuppgifterna stämmer överens med de som angetts på webbplatsen.

3) End to End nivå

Affärsflödena och användningsfallen körs i användargränssnittet. Skapa en order med flera artiklar:

• En användare öppnar webbplatsen.
• Användaren går för att lägga en beställning.
• Användaren frågar om en giltig produkt och kvantitet och lägger till den i varukorgen.
• Andra giltiga produkter läggs till med giltiga kvantiteter och beställningen sparas. Betalning sker via en ny betalningsmetod och beställningen görs.
• Ett meddelande som säger "Beställningen har gjorts framgångsrikt" ska visas.
• En testare bör validera att hela flödet slutförs utan att data förvrängs.

Vanliga frågor