software test 2010 test i soa miljoer ioana mogensen

12.03.2010

Dansk IT

Software Test 2010

Test i SOA miljøer11.03.2010

Ioana Diana Mogensen

# 2

Agenda

Abstract

3-Lagsarkitekturen vs. SOA arkitekturen

SOA test set ud fra 4 perspektiver

V- Modellen og SOA

SOA test udfordringer set ud fra 4 perspektiver

Mulige løsninger

Yderligere Tests

SOA test afhængig af modenhedsgrad

Opsummering

Til Sidst

SOA i 4 perspektiver

Abstract

• Service Orienteret Arkitektur (SOA) er en paradigme som lover mange fordele for dagens virksomheder.

• SOA skal kunne støtte optimalt forretningens mål både påstrategisk, operationel og finansiel niveau.

• Samtidigt med SOA paradigmet er der kommet nye udfordringer i de anvendte metodologier for både IT -udvikling og test i SOA projekter.

Problemstillinger

• Hvordan adskiller Service Udvikling og test, sig fra det ellers kendte Software Udvikling?

• Test i SOA miljøer, indeholder alle kendte og traditionelle testudfordringer plus en række nye som skal håndteres hensigtsmæssigt.

• Hvorfor er det nødvendigt med mere test på serviceniveau i forhold til systemniveau ?

• Test af processer

SOAArkitektur

3-Lags Arkitektur

# 6

SOA set ud fra 4 perspektiver

Arkitekturperspektiv:

SOA er en arkitekturstil som understøtter service orientering

Forretningsperspektiv:

SOA er et sæt af forretnings services som understøtter forretningen

• Driftsperspektiv:• Service delivery management

• Service monitorering

• Sikring af teknologisk infrastruktur, - netværk, servere,m.m.

• Change management/deployment

Udviklingsperspektiv:

SOA er et samarbejdende indsats hvor flere grupper i en organisation er involveret i: service udvikler e, applikationsintegratorer, testere, forretningsanalyster for at nævne nogle.

I modsætning til ”traditionel” udvikling, udviklings -opgaverne bliver udført adskilt og ingen af parterne har komplet kontrol over ”byggeklodserne ”

Forretningsperspektiv:

SOA er et sæt af forretnings services som understøtter forretningen

Service begrebet

• En service er en aktivitet indenfor en proces der har til formål at løse et velafgrænset og veldefineret problem

• En software service er en komponent som formidler funktionalitet til andre software komponenter

• En service definerer en præcis grænseflade som kommer til at blive brugt af klienter. Hver service udstiller en eller flere indgangspunkter som definerer hvorfra en given funktionalitet kan blive udstillet fra.

• SOA services fungerer løskoblede i SOA arkitekturen


SOA er en arkitekturstil som understøtter service orientering

UdviklingsmiljøPræ-

produktions-miljø

Produktions – miljø

Systemfrigivelse

Overdragelse til IT Drift

samt Implementering

Release Release

Testmiljø

Backend systemerne bibeholder stort set deres eksisterende udviklingsproces


SOA er et samarbejdende indsats hvor flere grupper i en organisation er involveret i: service udviklere, applikationsintegratorer, testere, forretningsanaly sterm.m.

I modsætning til ”traditionel” udvikling, udviklings -opgaverne bliver udført adskilt og ingen af parterne har komplet kontrol over ”byggeklodserne ”

Udviklingsproces i SOA

SOA TEST – er Test af SOA Arkitekturen

Back End Applikationer

DB

Data Abstraktion

Workflows

DB

DB

Legacy

System 1

DB

Legacy

System 2

Legacy

System 3

DB

Forretnings

Services

Service Data transport

Front End Applikationer

Test af Legacy System service

Link test

Integrationstest

Komponent test

Servicetest

Workflowtest

Systemtest

SIKKERHED

GOVERNANCE

RP

TEST

# 13

SOA - test set ud fra 4 perspektiver

Arkitekturperspektiv:Forretningsperspektiv:

• Procesflows, • Forretningsprocesser, • Forretningsregler, • Forretningslogik• Forretningsservices

• Driftsperspektiv:

• Load test

• Stress test

• Performance test


• Test af alle typer services:• Forretningsservices• Databærende fysiske services • Transaktionsservices• Infrastruktur services

• Test af Services med og uden UI • Test af Sikkerhed• Test af Transaktionssporbarhed

V-model for SOA testBusiness Case

V-modellen understøtter test igennem hele udviklingscyklussen.

SOA services er løst koblet og det er især her en bottom-up teststrategi er anbefalet.

Beskrivelse af testtrin

•Service-niveau komponenter• Hvem: backend - udviklere• Formål: unittest som skal sikre at programmelet fungerer internt samt at basis funktionalitet fungerer som det skal.

• Testteknikker:•UNIT TEST•White-box test• Boundary test•Negativ test• Positiv test• Test i strategisk perspektiv- i f. eks. OOverdenen


• Service-niveau tests

Formål: at sikre at servicenopfylder både kravspecifikationenog det behov andre processer harfor at bruge den pågældendeservice.

Tests:1. Funktionel test

2. Test af forretningsregler

3. Test af servicegrænseflade

4. Test af serviceoperationer

5. Test af sikkerhed

6. Sporbarhedstest – især for de services som ændrer data

7. Test af dataregler som sikrerdatakonsistens

8. Exception tests og fejlhåndtering


• Integration-niveau test

• Formål at finde ud af om servicegrænseflade opførsel samtinformationsdeling imellem services arbejder som ønsket.Fokuser lagt på service grænseflader.

• Testteamet skal sikre at ALLE services som er afleverede tildenne testtrin opfylder grænsefladekravene I form af:• Standarder• Format• Data validering

• Testscenariene skal designes på tværs afkommunikationslagene.

• Hvis eksternt-udviklede services bruges skal disse også testes• Yderligere Testteknikker:

• High-order test (black-box test udført på ændrede services)• Integrations test – ved kodeintegration – er især relevant for distribuerede applikationer.


• Process/Orkestrerings-niveau test

• Formål: Process/Orkestrering test sikrer at samlingen af orkestreredeservices samarbejder som specificeret.

• Testdækning inkluderer:• Forretningslogik

• Exception handling – valideringer

• Forretningsproces dekomposition

• Procesgenbrug

• Servicegenbrug

Delproces A Delproces B Delproces C

Forretningsproces 1

Aktivitet 1 Aktivitet 2 Aktivitet 3 Aktivitet 4 Aktivitet 5 Aktivitet 6

Aktivitetsgruppe Aktivitetsgruppe Aktivitetsgruppe med deleaktiviteter

Forretnings Services

Tid

Fysiske Services

Workflows/

Procesorkestrering

Forretningsproces 2

En Domæne

Domæner


• System-niveau test

• Formål: - at teste at den SOA tekniske løsning opfylder forretningenskravspecifikationer. Forretningsscenarier bliver testede.

• Målgruppe: • løsningens forretnigsscenarie flows

• Forretningsinteressenter samt testere som har fuld kendskab tiltestdækning samt kvalitetskrav og mål.

• Testteknikker:• Dybe funktionelle tests

• Let funktionelle tests af forretnings processflows

• Black-box

go sh

allow

& wide

,

then de

ep & na

rrow,

then de

ep & wide

# 20

SOA – test udfordringer - set ud fra 4 perspektiver


Alle kendte testudfordringer PLUS:Dynamik og tilpashed & Manglende kontrol

I traditionelle systemer er det altid muligt at afgøre hvilken komponent og hvorfra denne bliver kaldt.

I SOA, er ”systemet” beskrevet som workflows af abstrakte services som bindes til fysiske services, som hentes fra flere systemer under udførelsen af en workflowinstans.

Forretningsperspektiv:Alle kendte testudfordringer PLUS:Manglende mulighed for at observere service kode og struktur:

For brugertestere og systemintegratorer er servicene grænseflader

Det forhindrer white–box test som kræver kendskab til koden samt dataflowet.

Driftsperspektiv:

Alle kendte testudfordringer PLUS:

- Tilgængelighed

- Robusthed

- Reliability

- Ukomplete eller manglende test kan føre til større omkostning i forbindelse med problemundersøgelser og debugging når servicene er blevet sat i produktion.


Alle kendte testudfordringer PLUS:- Ingen synlighed og sporbarhed under UI for at isolere og

finde fejl. Svært at teste services og komponenter som ikke har tilgængelig UI.

-Siden servicekomponenter har deres livscyklus er det sværere at teste og validere applikationsfunktonalietkontinuert.

- Svært at teste composite/agregerede services pga. begrænset dataadgang eller data kan være direkte afhængig af andre services.

- Manglende samarbejde imellem udvikling og kvalitetssikring – herunder tænkes manglende genbrug af testcases imellem de forskellige typer tests: unit test, funktionel test, regressionstest og performance test.

# 21

SOA – løsninger test udfordringer


Løsninger for Dynamik og tilpashed:

- Design tests til formålet og det specifikke virkefelt

- Beskriv servicenes opførsel samt testinformation

-Systematisk inspektion og test for alle services som er berørte af ændringer

- Systematisk inspektion af servicenesopførsel

Forretningsperspektiv:Løsninger for Manglende mulighed for at

observere service kode og struktur:

- Brug teknikker som black-box test- Test på workflow niveau og

forretningsservice niveau- Back-end service output kan testes for at

sikkre at de databærende services leverer korrekt

Driftsperspektiv:

Løsninger for- Tilgængelighed

- Robusthed

- Reliability

- Run-time monitorering af configurationer samt serviceudførsel. Monitorering er ikke test.


Løsninger for -

Servicelivscyklus:- Regressionstestautomatisering – hvor det kan lade

sig gøre

Svært at teste composite/agregerede services-Begræns agregering hvor muligt- Design servicegranularitetten således at det hverken

er for fin eller for grov.

Manglende samarbejde imellem udvikling og kvalitetssikring –

Indfør kvalitetssikring tiltag og standarder som

understøtter test practices, herunder vedligeholdbar

dokumentationsniveau af testcases

Yderligere tests på tværs af SOA- udviklingslivscyklus

• Test af forretningsregler• Procesregler

• Beskriver aktivitetssekvenser – workflow.

• Er typisk brugte til at koordinere menneskernes arbejde påtværs af processer, aktiviteter og systemer

• Bliver brugt sammen med de andre typer regler

• Transaktionsregler

• Relaterer sig til opførsel af features fælles for de komponenter, objekter brugt til automatiseringen af forretningstransaktioner.

• Repræsenterer betingelser, valideringer og aktioner

• Dataregler

• Sikrer dataintegritet ved opdateringer

• Sikrer konsistens og optimering

• CRUD matricer kan stilles op på UC- niveau/ service operationsniveau

Yderligere tests på tværs af SOA- udviklingslivscyklus

• Sikkerhedstest• Sikkerhedstest baseres på de formulerede sikkerhedspolitikker

• Specielle tests bør afdækkes- f.eks. adgang, autorisation m.m.

• Tag i betragtning hvordan sikkerhedsinfrastrukturen interagerer med de forskellige applikationer og de anvendte teknologier.

• Vigtige test case betragtninger:

• 1 -1 service kald udløst af én procesbruger

• 1-* servicekald udløst af én og samme procesbruger

• Test af transaktionssporbarhed• Audit trail på forretningskritiske transaktioner

Testerfaringer• Test designes med henblik på at finde svar til specifikke spørgsmål vedr. programmel,

systemer, services eller processer

• Interessenterne har spørgsmålene

• Testerne har svarene

• Hast er ikke fremskridt !

• Test forskelligt alt afhængigt af domæne og kontekst

• Undersøg, undersøg, undersøg

• Husk reglen:

• Store fejl findes ofte ved et tilfælde• Fejl kan være gamle fejl !

• Fejl har en tendens til at klynge sig i bestemte områder – og ikke nødvendigvis i de domæner som er ændret for nyligt.

• Varier parametre og variabler:• Testsekvenser, testscenarier, konfigurationer og data

go sh

allow

& wide

,

then de

ep & na

rrow,

then de

ep & wide

SOA test afhængig af SOA modenheds-graden

• 0 punktet – 1 gang SOA udvikling: SOA applikationen benytter (legacy / heritage) services. De oprindelige systemer er stabile og kører stadig i produktionsmiljøer.

• Vigtigt! Stil test scope, testplaner, testscenarier og testcases samt test således at ALLE end-to-end scenarier er dækket for samtlige services som bruges i SOA applikationen.

• SOA modenhedsgraden er under udvikling: Der bliver udviklet nye services som skal bruges i nye SOA applikationer.

• Vigtigt:• Bestem hvordan disse services skal bruges i fremtiden samt hvem og hvorfra disse services må blive kaldt fra

• Testplaner, testscenarier, test cases udtænkes med henblik pågenbrugelighed

Opsummering

• End-to-End Test i SOA miljøer adskiller sig fra den traditionelle (Ikke service baseret) applikationsudvikling.

• I den traditionelle SW udvikling er endepunkterne veldefinerede og forventningerne er klart definerede.

• For SOA applikationer gælder det at servicerne er genbrugelige i en applikation og på tværs af applikationer.

• Test i SOA miljøer indebærer både test på serviceniveau og tests af workflows og forretningsprocesser som er orkestreret sæt af services.

Opsummering

Test automatisering

• Muligheder• Eliminerer en del af det manuelle

gentagende arbejde – ideel til regressionstest

• Giver mulighed for at lave testdata

• Begrænsninger

• Nemt at blive påvirket af ændringer (kravændringer, designændringer, ændringer til GUI etc.)

• Kan ikke nødvendigvis finde mange fejl.

• Direkte afhængigt af kvaliteten for det system som testes.

• Kan ikke eliminere menneskets viden

• Test cases skal vedligeholdes konstant

•Udm

ærket til den samlede del af

tests

•Kan absolut ikke ståalene!

•Ikke tro

at den hellige grav er

velbevaret!

•Versio

nering!

•Brug den med omhu!

Til sidst : TG

• Test Governance (TG)

• ” Best practices” skal sikre at test sker altid efter veldefinerede forskrifter. Alle ” best practices” skal kunne forefindes i nedfaldet form af strategier, politikker og checklister.

Strategi-fastlæggelse

Forberedelse Udførelse

Dokumentation:

Evaluering

StrategiWBSTestplanerTestscenarierTestcasesTestdataRapporteringStatusmøder

TestværktøjerDefectsRapporteringStatusmøder

ProjektevalueringRapport

Testaktivitet

# 30

TAK!

Ioana Diana [email protected]

software test 2010 test i soa miljoer ioana mogensen

Technology