Inleiding en indeling. Inleiding en indeling. Software Engineering 1. Pieter van den Hombergh. 5 februari Pieter van den Hombergh

Transcriptie

1 Inleiding en indeling Pieter van den Hombergh Fontys Hogeschool voor Techniek en Logistiek Software Engineering 5 februari 2014 HOM/FHTeL Inleiding en indeling 5 februari /1 Inleiding en indeling Pieter van den Hombergh Fontys Hogeschool voor Techniek en Logistiek Software Engineering 5 februari 2014 HOM/FHTeL Inleiding en indeling 5 februari /1 Software Engineering 1 Literatuur vooral: testen! HOM/FHTeL Inleiding en indeling 5 februari /1 1

2 Book Literatuur Objectgeoriënteerd testen en testautomatisering in de praktijk Bij de lessen, in het praktikum en in het project gebruiken we: Schrijver Uwe Vigenschow, der Firma oose.de., speciaal jullie vertaald in het Nederlands. Uitgever, ISBN Fontys Venlo, ISBN , Verkrijgbaar bij de docent. Prijs 39 Euro. website Zelfstudie voor volgende week: Bestudeer hoofdstuk 1-4, Paginas 3-25 Volgende week mogelijk quiz over deze hoofdstukken. HOM/FHTeL Inleiding en indeling 5 februari /1 Mariner 1 In 1962 werd de draagraket van de Mariner 1- Venussonde 290 seconden na de start bewust vernietigd, omdat ze van de geplande vluchtbaan afweek. De schade beliep ca. 18,5 miljoen US Dollar. Wat ging er mis? De bedoelde code voor een lus over de waarden 1, 2 en 3: DO 5 K = 1, 3 staat als volgt in het programma: DO 5 K = 1. 3 Dit ziet de compiler als volgt: DO5K = 1.3 en dat is de declaratie van de variabele DO5K!! Kleine oorzaak met grote gevolgen! HOM/FHTeL Inleiding en indeling 5 februari /1 Code van de venussonde Mariner 1 IF ( TVAL.LT. 0.2E -2) GOTO 40 DO 40 M = 1, 3 W0 = (M -1)*0.5 X = H * E -2* W0 DO 20 N0 = 1, 8 EPS = 5.0*10.0**( N0-7) CALL BESJ (X, 0, B0, EPS, IER ) IF ( IER.EQ. 0) GOTO CONTINUE DO 5 K = 1. 3 T(K) = W0 Z = 1.0/( X **2)* B1 ** E -4* B0 **2 D(K) = 3.076E -2*2.0*(1.0/ X*B0*B E -4**( B0 **2 -X*B0*B1 ))/ Z E(K) = H **2* * W0/ SIN (W0 )*Z H = D(K)-E(K) 5 CONTINUE 10 CONTINUE Y = H/W CONTINUE HOM/FHTeL Inleiding en indeling 5 februari /1 2

3 Het ariane vuurwerk Neervallende brokstukken na zelfdestructie van de Ariane-501 raket, 4 juli De Ar-501 is ontploft door een softwarefout: de snelheid paste niet in de daartoe gereserveerde variabele grootte. Nieuwe technieken zijn nodig om dergelijke ongelukken te voorkomen. Bron Foto: ESA HOM/FHTeL Inleiding en indeling 5 februari /1 Ariane code declare vertical_veloc_sensor : float ; horizontal_veloc_sensor : float ; vertical_veloc_bias : integer ; horizontal_veloc_bias : integer ; begin declare pragma suppress ( numeric_error, horizontal_veloc_bias ); begin sensor_get ( vertical_veloc_sensor ); sensor_get ( horizontal_veloc_sensor ); vertical_veloc_bias := integer ( vertical_veloc_sensor ); horizontal_veloc_bias := integer ( horizontal_veloc_sensor ); exception when numeric_error => calculate_vertical_veloc (); when others => use_irs1 (); end ; end irs2 ; HOM/FHTeL Inleiding en indeling 5 februari /1 Wat is er mis gegaan? Standaard worden de waardenbereiken getest op geldigheid. Dit kan echter onderdrukt worden en dat gebeurt in volgend fragment: declare pragma suppress(numeric_error,horizontal_veloc_bias); De van de snelheidssensor afkomstige data voor de horizontale snelheidsbepaling worden in intern gebruikte eenheden aan de besturingssoftware doorgegeven. Dit gebeurt met de volgende coderegel, waarbij dit omgezet wordt in een integer: horizontal_veloc_bias := integer(horizontal_veloc_sensor); HOM/FHTeL Inleiding en indeling 5 februari /1 3

4 Wat is er mis gegaan?, Cont. Precies hier vindt ongeveer 30 seconden na de start een integer-overflow plaats, die niet afgevangen wordt, aangezien de test daartoe eerder in de code werd uitgeschakeld! Bij de Ariane 4 gaf dit nooit problemen; de Ariane 5 echter bereikt op hetzelfde moment een vijfmaal hogere horizontale snelheid! Het risicomanagement was ervan overtuigd dat er alleen hardware en geen softwarefouten konden optreden! [Meer details in Objectgeoriënteerd testen en testautomatisering in de prakijk. Objektorientiertes und Testautomatisierung in der Praxis van Uwe Vigenschow ( HOM/FHTeL Inleiding en indeling 5 februari /1 Is een robuustere taal de oplossing? Een komma in plaats van een punt leidt in C++ tot een oneindige lus: while (x > 0,1)... In Java niet, daar wordt 1 niet automatisch in true omgezet. In dit geval zou de compiler mopperen. Dus altijd Java? Geen oplossing! De momentele oplossing: Vroegtijdig testen opstellen (taalonafhankelijk) en geregeld uitvoeren. HOM/FHTeL Inleiding en indeling 5 februari /1 Inleiding testen Waarom testen? Productstandpunt Het programma moet correct zijn, doen wat de opdrachtgever wil. De software moet betrouwbaar zijn, niet crashen. robuustheid: de software moet tegen een stootje kunnen als de gebruiker er op de verkeerde manier mee omgaat. Processtandpunt van software draagt ook bij tot een verbetering van het software proces. Communicatie met collega s Uitwisselen van code die voorzien is van een test. HOM/FHTeL Inleiding en indeling 5 februari /1 4

5 Wat is testen? Een definitie: is de activiteit van het uitvoeren van een (deel van een) programma met als doel het vinden van fouten. Een volwaardige activiteit die deel uitmaakt van het ontwikkelingsproces. Wat testen kan en niet kan: Aantonen (bewijzen) dat een programma géén fouten bevat. Alleen het omkeerde kan: bewijzen dat een programma fouten bevat. HOM/FHTeL Inleiding en indeling 5 februari /1 Soorten van testen Een unit test test op die manier 1 (of een heel klein aantal) klassen. Een integration test gebruik je op het moment dat je 2 of meer (kleine) delen wil samenvoegen. Een regression test daarentegen moet (op een geautomatiseerde manier) het hele programma testen. HOM/FHTeL Inleiding en indeling 5 februari /1 Unit testen Black-box testing Software test zonder kennis over de exacte interne werking van de module. voorbeeld: testen van MyStack White-box testing structureel testen basic path testing: alle mogelijke controlelijnen in een programma nagaan en daaruit de testen opbouwen HOM/FHTeL Inleiding en indeling 5 februari /1 5

6 Hoe maak ik een unit test? Simpel voorbeeld, een Stack: Methoden: push. pop. peek. isempty. HOM/FHTeL Inleiding en indeling 5 februari /1 Java contract class MyStack implements Stack; Methoden Stack interface: p u b l i c i n t e r f a c e Stack { v o i d push ( O bject ) ; // put e l e m e n t O b ject peek ( ) ; // r e t u r n top e l e m e n t O b ject pop ( ) ; // remove and r e t u r n top e l e m e n t boolean isempty ( ) ; // s t a c k empty } Dit contract is niet voldoende waterdicht gespecificeerd. Waar is verbetering op zijn plaats. HOM/FHTeL Inleiding en indeling 5 februari /1 Hoe maak ik een unit test? 2 schrijf: class StackTest Geannoteerde setup () stack = new MyStack( teardown( ) stack = public final void atestpush() testmethoden toevoegen,zoals p u b l i c v o i d t e s t P u s h ( ) { S t r i n g t= H a l l o ; s t a c k. push ( t ) ; a s s e r t E q u a l s ( t, ( S t r i n g ) s t a c k. peek ( ) ) ; } Een methode is een testmethode als ze annotatie heeft. HOM/FHTeL Inleiding en indeling 5 februari /1 6

7 Klassendiagram TestCase <<interface>> Stack TestRunner StackTest MyStack HOM/FHTeL Inleiding en indeling 5 februari /1 Stubs, drivers en mock Stubs Vaak heeft men ook aantal andere klassen nodig de klasse onder test te kunnen laten werken. Die zijn nog niet klaar! Of te omslachtig voor de test (database verbinding e.d.). Speciale klassen die het gedrag van de toekomstige klassen simuleren. Heten ook wel mock-objects. HOM/FHTeL Inleiding en indeling 5 februari /1 Belang van unit testen Unit testing is belangrijk omdat het je toelaat om kleine stukjes software te testen: Je weet altijd dat eventuele fouten in het kleine stukje software zitten en je moet dus niet uren liggen zoeken naar waar de fout precies ontstaat. HOM/FHTeL Inleiding en indeling 5 februari /1 7

8 Integratietests Goede unittesten uitgevoerd, toch problemen als 2 of meer klassen ineens moeten samenwerken. Oorzaken kunnen zijn: Meerdere personen schrijven software samen. Hoe duidelijk deze afspraken ook zijn, altijd wel onstaan er kleine misverstanden. Dat kan overigens ook gebeuren als je alleen werkt! HOM/FHTeL Inleiding en indeling 5 februari /1 Belang van Waarom is integration testing belangrijk? Zo vroeg mogelijk testen beperkt de zoektocht naar de bug. Geen big-bang waagstuk. Daarom goed idee om incrementeel te werk te gaan Elke keer als je 1 of 2 klassen af hebt, voer je een integration test uit. HOM/FHTeL Inleiding en indeling 5 februari /1 Wat is een regression test? Een test die het gehele programma test. Bij voorkeur volledig geautomatiseerd: door één commando uit te voeren weet de gebruiker van de test weet of het programma goed werkt (voor wat betreft de tests), of dat er nog ergens een bug in zit. Is een verzameling van afzonderlijke tests. bestaat uit een aantal scenarios. Bevat simulatie van normale en abnormale situaties. HOM/FHTeL Inleiding en indeling 5 februari /1 8

9 , 2 Normale situaties. Alle handelingen en alle inputs (gebruiker, externe input en configuratie files) die een normale werking van het programma als gevolg zouden moeten hebben. Abnormale situaties. (Exceptions) Foutieve input van de gebruiker of foutieve input via configuratie en input files. Abnormaal werkend systeem, bv. het aanmaken van een nieuwe outputfile die niet werkt... HOM/FHTeL Inleiding en indeling 5 februari /1 3 Link use-cases en voorgestelde scenarios: Zijn een kernachtige beschrijving van hoe de software gebruikt kan worden. Meerdere gebruiksscenario s voor 1 use-case, dus per use-case een of meerdere scenarios in de regression test! Andersom: Uit de unit en integration tests die je schrijft, scenarios voor de regression test distilleren. (Gooi nooit een goede test weg!) HOM/FHTeL Inleiding en indeling 5 februari /1 Hoe bouwen we een regression test op? Scenario Expected / Actual 1: Completely correct inputfile Output1 Output1 2: Completely correct inputfile Output2 Output2 3: Missing XML closing tag Error msg 1 Error msg 1 4: Non matching open and closing Error msg 2 Error msg 2 tag 3: XML file with unknown tag Error msg 3 Output5 Tabel : Scenario 5 in abnormal situation Deze tabel is een slechts voorbeeld uit een applicatie met xml files. HOM/FHTeL Inleiding en indeling 5 februari /1 9

10 , waarom belangrijk? Iedereen kan de test laten runnen zonder grote voorkennis van het systeem: er moet immers maar één commando worden uitgevoerd om in één oogopslag te zien of het programma juist werkt of niet. Als eenmaal je een basisversie van de software werkend hebt, is het eenvoudig om te zien of bv. een bepaalde (functionele) aanpassing of een refactoringoperatie geen nadelig gevolg heeft gehad door de regression test te laten lopen. HOM/FHTeL Inleiding en indeling 5 februari /1 Testing framework Wat is een framework? Een soort geraamte: het geeft vorm en richting aan het stuk software dat je aan het schrijven bent. Stukken software hebben min of meer dezelfde structuur. Elk framework bevat herbruikbare delen basisfunctionaliteit. Specifiek gericht op probleem dat je probeert op te lossen. Een aantal voordelen : Tijdwinst Zelfde structuur maakt begrijpen makkelijker HOM/FHTeL Inleiding en indeling 5 februari /1 Voorbeelden van test- JUnit, Mother 1 of all unit. Open source, zoals de meesten. Frameworks in andere talen CppUnit voor C++. Nunit voor de.net wereld (in C#). PyUnit voor Python XMLUnit SQLunit PHPUnit Etc. 1 Actually smalltalk was earlier HOM/FHTeL Inleiding en indeling 5 februari /1 10

11 Wat kost dat? Een prettige bijkomstigheid van de is dat de meeste open source zijn en wijd verbreid. Junit en de daarop bouwende testtools zijn de standaard in de java wereld. Maar, afhankelijk van het type product (samenhangend met de risico s) kunnen de testkosten toch behoorlijk in de papieren lopen. In het typische geval tussen de 20 en 40% de totale software ontwikkelkosten. In sommige kritische gevallen zelfs boven de 50%. Het zijn voornamelijk loonkosten. HOM/FHTeL Inleiding en indeling 5 februari /1 Tips Schrijf je testen vóór je het programma zelf begint te schrijven. Test vanaf het begin. Test grondig, kijk ook goed uit voor randgevallen. Maak voor elke use-case minstens een test. Wanneer ben je klaar met testen? Eigenlijk nooit... HOM/FHTeL Inleiding en indeling 5 februari /1 11