Integrationstest Fremtid eller kaos? Anders Dinsen Twitter: @andersdinsen Mail: ad@asym.dk IDA-IT Januar 2014
3/36
4/36
Struktur med komponenter Regnecentralen RC8000 vektorprocessor board fra ca 1972. Bygget til Geodætisk Institut. Elektroniske komponenter er veldefinerede og afgrænsede, forbindelser er ensartede. 5/36
Struktur, der understøtter funktionalitet? Pille-sluge-maskine af Robert Storm Pedersen 6/36
If you want to find out how something works - first figure out how to break it (Nassim Taleb) In testing: If you want to find out how something works - figure out how it's broken (Michael Bolton) 7/36
Testing in a Service Oriented Architecture Front end system Tester Backend systems System AA Subsystem A System AB Subsystem B System AC Service bus 8/36
Tre-trins raket Stage 1: Check all interfaces Stage 2: Check components' connections to each other Stage 3: Check functionality 10/36
Stage 1: Checking connectivity Tester System AA Subsystem A System AB Subsystem B System AC 11/36
Stage 1: Er alle mødt frem i klassen? Hallo?? Kan vi udveksle meningsfulde beskeder? Er definitioner på plads og korrekte? Er basal fejlhåndtering på plads? 12/36
Stage 2: Check each integration individually Tester System AA Subsystem A System AB Subsystem B System AC 13/36
Stage 2: Can we start working together? Will component A exchange information with component B? Will B understand all message types from A? Will A react on all response types from B? 14/36
Stage 3: Testing integrations functionally Tester System AA Subsystem A System AB Subsystem B System AC 15/36
Stage 3: Okay, so can we do stuff? Can we execute function X employing components A, B, C... Can we execute function Y employing components D, E, F Etc 16/36
Risikoanalyse for integrationer guidewords Faktor Guidewords Projekt Transparens i organisationen Hastearbeje Indlæringskurver Teknologi Kompleksitet Historik Robusthed Testbarhed Dokumentation Udeladte detaljer Krav i udvikling Svære at læse Menneskelige Samarbejdsevner Kompetencer Viden 17/36
Questioning structure... what more can we learn? Structure is a non-tangible thing Structure tends to be something we 'accept' not question The bottom-up approach is simple It's a static approach It's a detail focused approach Black swans very often root in the structure of systems Example: The Skype accident in 2010 18/36
Skype peer-to-peer network s Support servers for offline msg Supernode Supernode Supernode 19/36
Wednesday, December 22 2010 s Support servers for offline msg Supernode Supernode Supernode 20/36
Fu nc ty, bili Sta tio n Maintainability Holistic model ss tne us rob ility b a t s Te Performance Ana lyz abil ity 21/36
Focus-defocus heuristic 22/36
Is there a problem here? The green system has response times around 1s and never below 0.8s. Do we have a performance issue? What happened around 9 and 12, where system activity went away? The system was down from about 16 to 17 There seems to be some timeout issues on the yellow system with response times around 25 and 30 seconds. They are affected by user loading The 'blue system' sometimes have very high response times. It seems to be concentrated around 10:45, 13:30, 14:15 Activity on the green system appears to be firmly correlated with user activity The yellow system has a life of its own 23/36
27/36
The 'Allan McNish' heuristic Aka 'Turning up the heat' Basic principle: Odd things happen when systems are put under pressure Put the system under high load for a limited time Load the system for a long, long time Take chances Be aggressive Why regret? It won't change anything! 28/36
The 'Allan McNish' heuristic 29/36
Integrations test ifølge wikipedia: Wikipedia: Integration testing (sometimes called Integration and Testing, abbreviated "I&T") is the phase in software testing in which individual software modules are combined and tested as a group. It occurs after unit testing and before validation testing. 30/36
Integrationstest en definition Integrationstest finder egenskaber, udfordringer og fejl i systemets infrastruktur Infrastructur er en struktur, der består af integrationer mellem komponenter i systemet Componenter vedligeholdes og udvikles som uafhængige softwaremoduler Integrationer gør at komponenter kan gøre ting sammen. Dermed skabes mulighed for funktionalitet som den enkelte komponent ikke kan implementere alene 31/36
Et kig ind i fremtiden 32/36
Teknisk versus social kompleksitet 33/36
Et kig ind i fremtiden: What will we do with all that computing power of the future? Connectivity ^ 10? Complexity ^ 10? New business models? Imperfect/buggy systems? More fragility and black swans? Or organic resilience? Anti-fragility? and what will it mean for testing? 34/36
Eller skal vi søge tilbage til rødderne? 35/36