Testen in de cloud (EIP) Introductie

Transcriptie

1 Testen in de cloud (EIP) Introductie Het Wielsem 10, 5231 BW s- Hertogenbosch, telefoon e- mail internet

2 1 Inhoudsopgave 1 Inhoudsopgave Inleiding Drie lagen Cloud architectuur Welke kwaliteitseisen zijn van belang voor de cloud service? ISO9126 [Quint2] Meest relevante attributen Testwerkwijze Welke Enterprise Integration Patterns zijn van belang voor de cloud service? Voorbeeld Document Management Systeem (DMS) Introductie Uitwerking EIP voor de test base van de DMS cloud services Pattern identificatie voor Adaptibility Pattern identificatie voor Availability Pattern identificatie voor Scalability Pattern identificatie voor Reliability Conclusie Bijlage Verklaring der toegepaste Enterprise Integration Patterns... 8 Versie 0.1, januari 2013 testwork.nl Pagina 2 / 8

3 2 Inleiding 2.1 Drie lagen De cloud is onderverdeeld in drie lagen, namelijk IaaS, PaaS en SaaS. Deze afkortingen staan resp. voor Infrastructure-, Platform-, en Software- as- a- Service. De laatste is de meest bekende. Het gaat hierbij om software die buiten de organisatiegrenzen wordt gehost bij een externe leverancier. In het cloud- paradigma wordt die externe leverancier aangeduid als de cloud provider. Indien die cloud provider ook nog platformvoorzieningen ter beschikking stelt om applicaties te ontwikkelen, dan spreken we van PaaS. Beperkt de behoefte zich tot het afnemen van netwerkdiensten en storage bij een provider dan spreken we van IaaS. Centraal gegeven is de term dienstverlening. In plaats van dat een organisatie zelf investeringen pleegt en zo eigenaar wordt van ICT- voorzieningen consumeert het diensten uit de cloud. En waarom dan ook niet de benodigde testfaciliteiten, ofwel TaaS, Testing- as- a- Service. In dit document wordt ingegaan op de providerkant van TaaS. Verbeeld jezelf dat je werkzaam bent als provider van testvoorzieningen. Cloud consumenten stellen cloud applicaties aan jou ter beschikking met de vraag die door te testen. Om te kunnen beoordelen wat dit voor jou als tester betekent is het van belang te kijken in hoeverre cloud applicaties verschillen van conventionele applicaties zoals we die uit het verleden kennen. Het merendeel van de cloud applicaties die worden ontwikkeld zijn ontsloten middels web technologie. Dat komt omdat web technologie het mogelijk maakt om op een relatief eenvoudige wijze autonome systemen met elkaar te koppelen. Voor testers biedt dit nieuwe uitdagingen. Immers applicatiesystemen worden niet meer begrensd door bedrijfsmuren, maar steeds vaker worden applicatiesystemen samengesteld uit onderdelen die bij externe bedrijven zijn ondergebracht. Het kan zelfs zo zijn dat je niet eens weet waar systeemonderdelen zich precies bevinden. Die externe systeemonderdelen worden als services geconsumeerd binnen het grotere geheel. Zie daar nog maar eens een sluitende test voor te bedenken. En toch zijn er mogelijkheden om hier als tester goed mee om te gaan. In de basis is het van belang om naast de cloud applicaties ook de cloud architectuur onder de loep te nemen. Eigenlijk moet je als TaaS provider verder kijken dan de cloud systemen zelf. Daarbij rijzen vragen zoals: Welke kwaliteitseisen zijn van belang voor de opdrachtgever? Stuurt een opdrachtgever voor een hoge beschikbaarheid of juist hoge een betrouwbaarheid? Kennis over kwaliteitseisen helpen je de juiste testmaatregelen toe te passen. Hoe is het te testen cloud systeem opgebouwd? Wat is de decompositie? Kennis van toegepaste integratie- patterns binnen de cloud helpen je om de structuur van het cloud systeem te begrijpen en de juiste testmaatregelen toe te passen. Door gevoel te krijgen voor deze vragen wordt het mogelijk om een oordeel te vormen over de kwaliteit en conditie van de gehele cloud architectuur. 2.2 Cloud architectuur Een goede cloud architectuur is rekbaar en kan met gemak allerlei klappen opvangen. Bovendien is een dergelijke architectuur transparant. Dus mocht er iets aan mankeren dan zou het niet moeilijk moeten zijn om de vinger op de zere plek te leggen. Maar voor zo n architectuur er is moet er wel wat gebeuren. Een cloud architectuur is opgebouwd rondom services die enorm veel berichtenverkeer genereert tussen service providers en service consumenten. Er daarbij kan van alles mis gaan. Niet alleen technisch maar ook organisatorisch. Dat komt omdat zoals eerder gesteld cloud systemen niet meer terug te herleiden zijn naar één autonome eigenaar maar bestaan uit verschillende systeemonderdelen in een keten met elk hun eigenaar. Als tester kun je het beste een cloud service in de cloud keten testen indien je de grillen van aangrenzende systeemonderdelen maar goed in de vingers hebt. Versie 0.1, januari 2013 testwork.nl Pagina 3 / 8

4 3 Welke kwaliteitseisen zijn van belang voor de cloud service? 3.1 ISO9126 [Quint2] Als eerste kan de tester zich bij cloud gerelateerde opdrachten het beste concentreren op kwaliteitseisen. Bij het bespreken van kwaliteit draait voornamelijk om het expliciet maken van de meest belangrijke kwaliteitsattributen. Een sluitend overzicht van kwaliteitsattributen binnen de ICT- wereld zijn beschikbaar binnen de kwaliteitsstandaard ISO9126 [Quint2]. 3.2 Meest relevante attributen De ISO9126 norm veel kwaliteitsattributen waar tegen je de cloud architectuur kunt testen. De meest relevante attributen zijn: Kwaliteitsattribuut Testmethode (TMap Next) Randvoorwaarde Scalability Load test Enterprise Integration Patterns Availability Plug/Unplug FOLB (Fail Over Load Balancing) Patterns Reliability Negative Testing Enterprise Integration Patterns Adaptability Real Life Test Enterprise Integration Patterns Security Multi Tenant Proof Hacker like tests 3.3 Testwerkwijze De werkwijze voor het testen onder architectuur in de cloud is als volgt: Middels inzicht in een uitgewerkte Randvoorwaarde kan de genoemde Testmethode gericht worden toegepast om een Kwaliteitsattribuut te kunnen testen. Dus om bijvoorbeeld Reliability te beoordelen kan inzicht in de gebruikte Enterprise Integration Patterns [EIP] de basis leggen om de juiste Negative Testing Testmethode op te stellen. Afgezien van het testen van Security en Availability blijken Enterprise Integration Patterns een goed startpunt te zijn om de kwaliteit van de onderliggende architectuur te beproeven. Dit artikel beperkt zich tot de toepassing van Enterprise Integration Patterns in relatie tot de gestelde kwaliteitsattributen. Alle genoemde TMapNEXT - testmethodieken staan uitgebreid beschreven in [TMAP]. Versie 0.1, januari 2013 testwork.nl Pagina 4 / 8

5 4 Welke Enterprise Integration Patterns zijn van belang voor de cloud service? Het testproces is nauw verweven met alle andere activiteiten in het ontwikkelproces van systemen. Onderstaande afbeelding, het zogenaamde V- model, toont een grafische weergave van verschillende stadia in het software ontwikkelproces. De positie van Enterprise Integration Patterns vormt een belangrijke uitbreiding van de test base voor het testen van cloud systemen. Het is dus belangrijk voor testers om in een zo vroeg mogelijk stadium de toegepaste architectuurpatronen eigen te maken voor de specifieke cloud oplossing. Hoe dat precies in zijn werk gaat wordt in onderstaand voorbeeld beschreven. 5 Voorbeeld 5.1 Document Management Systeem (DMS) Introductie Als voorbeeld nemen we een Document Management Systeem (DMS) welke beschikbaar wordt gesteld als een cloud service. Maar wat is een DMS? Veel organisaties nemen tegenwoordig afscheid van werkprocessen waar het papier rijkelijk vloeit en stappen over op geautomatiseerde werkprocessen onder het mom van digitalisering. Naast argumenten zoals het invoeren van Lean Business Principes [LEAN] is het milieu aspect vaak leidend. Digitalisering leidt immers tot minder papierverbruik. Centraal binnen digitalisering is het plaatsen van een DMS waar digitale werkprocessen documenten in kunnen opslaan en doorzoeken. Er zijn ook legio cloud partijen die momenteel DMS- diensten aanbieden. Achterliggende reden is dat het verschaffen en beheren van een corporate DMS steeds minder rendabel wordt. Immers naast voldoende storage worden ook hoge eisen gesteld aan het beschikbaar kunnen stellen van veel verschillende documentsoorten. Vroeger kon men volstaan met office documenten echter tegenwoordig wordt ook rich media niet geschuwd zoals geluidsfragmenten en video Uitwerking EIP voor de test base van de DMS cloud services Versie 0.1, januari 2013 testwork.nl Pagina 5 / 8

6 Het dataverkeer tussen cloud consumer en cloud provider draait dus om het versturen en ontvangen van berichten. Tussen vertrek en ontvangst kan met een bericht veel gebeuren. Het is interessant om de vinger te krijgen achter dit proces omdat er hier legio zaken zijn die de tester kan beproeven. In ons voorbeeld voert de tester een aantal gesprekken met domeindeskundigen en daaruit voortvloeiend wil hij voor de test base onder andere de onderstaande scenario s beproeven. Scenario 1 Voordat een document wordt verstuurd naar de DMS cloud service provider wordt het document bij de cloud service consument verpakt in een bericht en ondergaat het een aantal transformaties. Daaruit destilleert de cloud tester vervolgens de volgende decompositie middels EIP: Scenario 2 Het is voor de DMS cloud service consument mogelijk om een veelvoud aan verschillende documentsoorten te verpakken in een bericht en vervolgens te verzenden naar de DMS cloud service provider. De cloud tester heeft hieruit middels EIP de volgende decompositie kunnen herleiden: Aan de hand van de kwaliteitsattributen uit de eerdere tabel met de meest relevante kwaliteitsattributen wordt door de cloud tester op een gestructureerde manier een decompositie gemaakt van mogelijke EIP patterns waardoor bovenbeschreven twee testscenario s beproefd (assessment) kunnen worden. Eigenlijk draait het bij zo n decompositie om het identificeren van de juiste EIP patterns uit [EIP] waarmee de kwaliteitsattribuut wordt uitgetest (assessed). De geïdentificeerde EIP patterns en bijbehorende assessments worden onderdeel van de test base Pattern identificatie voor Adaptibility Pattern: Datatype Channel Assessment: De benodigde processtappen voordat het bericht wordt verzonden leiden tot mogelijk fouten op de respectievelijke koppelvlakken. Pattern: Content Enricher Assessment: Er is mogelijk een probleem met het verrijken van de berichten. Denk hierbij dat bijvoorbeeld een bericht verrijkt wordt met een document. Versie 0.1, januari 2013 testwork.nl Pagina 6 / 8

7 5.1.4 Pattern identificatie voor Availability Pattern: Dead Letter Channel Assessment: Er is mogelijk een probleem waarbij berichten kwijtraken. Pattern: Aggregator Assessment: Er is mogelijk een probleem waarbij berichten niet worden opgespaard indien de connectiviteit naar de DMS cloud partij wegvalt. Dergelijke berichten zouden opgespaard moeten worden Pattern identificatie voor Scalability Naast FOLB kan ook hier de Aggregator assessment helpen. Immers bij een hoge load zal er opgespaard moeten worden (file- vorming). Het systeem dient hier goed mee om te gaan Pattern identificatie voor Reliability Pattern: Claim Check Assessment: Wordt tijdens het verpakken en versleutelen de integriteit van de verpakte informatie geschonden? Pattern: Content Based Router Assessment: Worden de verschillende type documenten uit scenario 2 op een verschillende manier opgepakt en verwerkt? 6 Conclusie Cloudsystemen zijn gedistribueerd over bedrijfsgrenzen heen. Daardoor wordt het van belang extra testaandacht te besteden aan het koppelvlak tussen de cloud service consumer en cloud service provider. Het uitvoeren van een decompositie van dergelijke cloud systemen middels Enterprise Integration Patterns helpt om de test base te voorzien van assessments voor het beproeven van cloud specifieke kwaliteitsattributen binnen een TMapNEXT testsystematiek. Versie 0.1, januari 2013 testwork.nl Pagina 7 / 8

8 7 Bijlage Verklaring der toegepaste Enterprise Integration Patterns Aggregator Werking: Afzonderlijke berichten worden geaggregeerd tot één berichtenpackage. Belang: Hoe zijn de afzonderlijke berichten zodanig te combineren. Dat ze geaggregeerd verwerkt kunnen worden als één geheel? Claim Check Werking: De inhoud van het bericht wordt verpakt en versleuteld. Belang: Hoe kan het verpakte bericht verstuurd Command Message Werking: Communicatie tussen systemen middels berichtenverkeer. Belang: Hoe kan berichtenverkeer worden ingezet om meerdere systemen logisch één gezamenlijke functie te laten uitvoeren? Competing Consumers Werking: Het gelijktijdig verwerken van meerdere berichten. Belang: Kan de cloud service provider/consumer meerdere berichten gelijktijdig verwerken? Content- Based Router: Werking: Een logische functie is geïmplementeerd over meerdere externe systeemonderdelen. Belang: Wordt een cloud bericht waarvan de content verschilt wel even snel verwerkt? Het kan voorkomen dat afhankelijk van de inhoud van het cloud bericht verschillende systemen de respectievelijke inhoud verwerken. Content Enricher Werking: Het oorspronkelijke cloud bericht wordt onderweg verrijkt. Belang: Hoe geschiedt het verrijkingsproces en welke maatregelen bestaan indien dit proces niet goed functioneert? Datatype Channel Werking: De cloud service provider weet precies hoe het berichten van de cloud service consumer moet verwerken. Belang: Weet het ontvangende systeem precies hoe het berichten met verschillende content moet verwerken? Dead Letter Channel Werking: Borgen van cloud berichten die niet goed kunnen worden verwerkt door de cloud service provider of consumer. Belang: Wat doet het cloud systeem met cloud berichten die niet verwerkt kunnen worden? Document Message Werking: Een cloud bericht bevat een document attachment. Belang: Is het transparant wat de begrenzingen voor het document attachment mag zijn en hoe is dit geborgd binnen he cloud systeem? Denk bijvoorbeeld aan grootte en hoeveelheid documenten binnen een cloud bericht. Pipes and Filters Werking: Cloudberichten ondergaan een complex proces. Belang: Hoe wordt kwaliteit van de cloud service geborgd door het toepassen van complexe processen op cloud berichten? Versie 0.1, januari 2013 testwork.nl Pagina 8 / 8