Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Software Test 2010 Test I SOA Miljoer Ioana Mogensen

1,490 views

Published on

Praesentation ved Dansk IT´s konference Software test 2010.

Published in: Technology, Education
  • Be the first to comment

  • Be the first to like this

Software Test 2010 Test I SOA Miljoer Ioana Mogensen

  1. 1. 12.03.2010 Dansk IT Software Test 2010 Test i SOA miljøer 11.03.2010 Ioana Diana Mogensen
  2. 2. #2 Agenda Abstract 3-Lagsarkitekturen vs. SOA arkitekturen SOA i 4 perspektiver 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
  3. 3. 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.
  4. 4. 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
  5. 5. 3-Lags Arkitektur SOA Arkitektur
  6. 6. #6 SOA set ud fra 4 perspektiver Forretningsperspektiv: Arkitekturperspektiv: SOA er et sæt af forretnings services som understøtter forretningen SOA er en arkitekturstil som understøtter service orientering Udviklingsperspektiv: • Driftsperspektiv: SOA er et samarbejdende indsats hvor flere grupper • Service delivery management i en organisation er involveret i: service udviklere, • Service monitorering applikationsintegratorer, testere, forretningsanalyster for at nævne nogle. • Sikring af teknologisk infrastruktur, - netværk, servere,m.m. I modsætning til ”traditionel” udvikling, udviklings- opgaverne bliver udført adskilt og ingen af • Change management/deployment parterne har komplet kontrol over ”byggeklodserne”
  7. 7. Forretningsperspektiv: SOA er et sæt af forretnings services som understøtter forretningen
  8. 8. 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
  9. 9. Arkitekturperspektiv: SOA er en arkitekturstil som understøtter service orientering
  10. 10. Udviklingsproces i SOA Backend systemerne bibeholder stort set deres eksisterende udviklingsproces Systemfrigivelse Overdragelse til IT Drift samt Implementering Udviklingsmiljø Præ- Produktions produktions Testmiljø – miljø -miljø Udviklingsperspektiv: SOA er et samarbejdende indsats hvor flere grupper i en organisation er involveret i: service udviklere, Release Release applikationsintegratorer, testere, forretningsanalyster m.m. I modsætning til ”traditionel” udvikling, udviklings- opgaverne bliver udført adskilt og ingen af parterne har komplet kontrol over ”byggeklodserne”
  11. 11. SOA TEST – er Test af SOA Arkitekturen TEST Front End Applikationer Systemtest Workflows Workflowtest Forretnings Servicetest Services Komponent test Integrationstest GOVERNANCE Service Data transport Link test SIKKERHED Data Abstraktion Test af Legacy System service Legacy Legacy Legacy System 1 System 2 System 3 Back End Applikationer DB DB DB DB DB RP
  12. 12. # 13 SOA - test set ud fra 4 perspektiver Forretningsperspektiv: Arkitekturperspektiv: • Procesflows, • Forretningsprocesser, • Forretningsregler, • Forretningslogik • Forretningsservices Udviklingsperspektiv: • Driftsperspektiv: • Test af alle typer services: • Load test • Forretningsservices • Databærende fysiske services • Stress test • Transaktionsservices • Performance test • Infrastruktur services • Test af Services med og uden UI • Test af Sikkerhed • Test af Transaktionssporbarhed
  13. 13. Business Case V-model for SOA test 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.
  14. 14. 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
  15. 15. Beskrivelse af testtrin • Service-niveau tests Formål: at sikre at servicen opfylder både kravspecifikationen og det behov andre processer har for at bruge den pågældende service. 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 sikrer datakonsistens 8. Exception tests og fejlhåndtering
  16. 16. Beskrivelse af testtrin • Integration-niveau test • Formål at finde ud af om servicegrænseflade opførsel samt informationsdeling imellem services arbejder som ønsket.Fokus er lagt på service grænseflader. • Testteamet skal sikre at ALLE services som er afleverede til denne testtrin opfylder grænsefladekravene I form af: • Standarder • Format • Data validering • Testscenariene skal designes på tværs af kommunikationslagene. • 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.
  17. 17. Beskrivelse af testtrin • Process/Orkestrerings-niveau test • Formål: Process/Orkestrering test sikrer at samlingen af orkestrerede services samarbejder som specificeret. • Testdækning inkluderer: • Forretningslogik • Exception handling – valideringer • Forretningsproces dekomposition • Procesgenbrug Domæner • Servicegenbrug En Domæne Forretningsproces 1 Forretningsproces 2 Workflows/ Procesorkestrering Delproces A Delproces B Delproces C Aktivitet 1 Aktivitet 2 Aktivitet 3 Aktivitet 4 Aktivitet 5 Aktivitet 6 Aktivitetsgruppe Aktivitetsgruppe Aktivitetsgruppe med deleaktiviteter Tid Forretnings Services Fysiske Services
  18. 18. Beskrivelse af testtrin • System-niveau test • Formål: - at teste at den SOA tekniske løsning opfylder forretningens kravspecifikationer. Forretningsscenarier bliver testede. • Målgruppe: • løsningens forretnigsscenarie flows • Forretningsinteressenter samt testere som har fuld kendskab til testdækning samt kvalitetskrav og mål. • Testteknikker: • Dybe funktionelle tests , • Let funktionelle tests af forretnings processflows w ide & w , w • Black-box llo rro h a na os ep & g de w ide n & t he p d ee en th
  19. 19. # 20 SOA – test udfordringer - set ud fra 4 perspektiver Forretningsperspektiv: Arkitekturperspektiv: Alle kendte testudfordringer PLUS: Alle kendte testudfordringer PLUS: Manglende mulighed for at observere service kode og struktur: Dynamik og tilpashed & Manglende kontrol For brugertestere og systemintegratorer er I traditionelle systemer er det altid muligt at afgøre servicene grænseflader hvilken komponent og hvorfra denne bliver kaldt. Det forhindrer white–box test som kræver kendskab I SOA, er ”systemet” beskrevet som workflows af til koden samt dataflowet. abstrakte services som bindes til fysiske services, som hentes fra flere systemer under udførelsen af en workflowinstans. Udviklingsperspektiv: Driftsperspektiv: Alle kendte testudfordringer PLUS: Alle kendte testudfordringer - Ingen synlighed og sporbarhed under UI for at isolere og PLUS: finde fejl. Svært at teste services og komponenter som - Tilgængelighed ikke har tilgængelig UI. - Robusthed -Siden servicekomponenter har deres livscyklus er det sværere at teste og validere applikationsfunktonaliet - Reliability kontinuert. - Ukomplete eller manglende test kan føre til større - Svært at teste composite/agregerede services pga. omkostning i forbindelse med begrænset dataadgang eller data kan være direkte problemundersøgelser og debugging når afhængig af andre services. servicene er blevet sat i produktion. - 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.
  20. 20. # 21 SOA – løsninger test udfordringer Forretningsperspektiv: Arkitekturperspektiv: Løsninger for Manglende mulighed for at Løsninger for Dynamik og tilpashed: observere service kode og struktur: - Design tests til formålet og det specifikke virkefelt - Brug teknikker som black-box test - Beskriv servicenes opførsel samt - Test på workflow niveau og testinformation forretningsservice niveau -Systematisk inspektion og test for alle - Back-end service output kan testes for at services som er berørte af ændringer sikkre at de databærende services leverer - Systematisk inspektion af servicenes korrekt opførsel Udviklingsperspektiv: Driftsperspektiv: Løsninger for - Løsninger for - Tilgængelighed Servicelivscyklus: - Regressionstestautomatisering – hvor det kan lade - Robusthed sig gøre - Reliability Svært at teste composite/agregerede services -Begræns agregering hvor muligt - Run-time monitorering af configurationer samt - Design servicegranularitetten således at det hverken serviceudførsel. Monitorering er ikke test. 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
  21. 21. 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
  22. 22. 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
  23. 23. 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 w ide & , ow rr ow all • Undersøg, undersøg, undersøg sh na & go ep de • Husk reglen: de wi en & th eep e nd • Store fejl findes ofte ved et tilfælde th • 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
  24. 24. 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
  25. 25. 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.
  26. 26. Opsummering
  27. 27. Test automatisering a f • Muligheder d el e • Eliminerer en del af det manuelle led m ! gentagende arbejde – ideel til sa ne v e r n e regressionstest de a l gr a t til å st i ge • Giver mulighed for at lave testdata ke ke ll æ r t ik he d m o lu den •U sts abs at hu ! • Begrænsninger te an tro et! g! om •K kke var erin ed •I lbe ion n m ve ers de • Nemt at blive påvirket af ændringer •V rug (kravændringer, designændringer, •B æ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
  28. 28. 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- Testaktivitet Forberedelse Udførelse Evaluering fastlæggelse Dokumentation: Strategi Projektevaluering WBS Testværktøjer Rapport Testplaner Defects Testscenarier Rapportering Testcases Statusmøder Testdata Rapportering Statusmøder
  29. 29. # 30 TAK! Ioana Diana Mogensen imo@appension.dk

×