SEN1 Software Engineering 1 Pieter van den Hombergh Ferd van Odenhoven Fontys Hogeschool voor Techniek en Bedrijfsmanagement Software Engineering 6 maart 2008 FvO,PvdH/FHTBM SEN1 Software Engineering 1 6 maart 2008 1/27
1 Acceptatietest voor wie? Belangen Wat te testen? Inhoud Acceptatietest Uitvoering points 2 Inspection and review Review plan debugging 3 4 Testen schrijven en plannen Test scenarios Test tools 5 FvO,PvdH/FHTBM SEN1 Software Engineering 1 6 maart 2008 2/27
Hebben we wel het juiste gebouwd? Acceptatietest voor wie? Belangen Wat te testen? Inhoud Acceptatietest Uitvoering points Figuur: Communicatie tussen domeinafdeling en ontwikkeling Bij de communicatie tussen domeinafdeling en ontwikkeling vindt een overdracht van de ene in de andere vaktaal plaats. FvO,PvdH/FHTBM SEN1 Software Engineering 1 6 maart 2008 3/27
Overzicht Acceptatietest voor wie? Belangen Wat te testen? Inhoud Acceptatietest Uitvoering points waarom acceptatietesten? FvO,PvdH/FHTBM SEN1 Software Engineering 1 6 maart 2008 4/27
Wat is een acceptatietest? Acceptatietest voor wie? Belangen Wat te testen? Inhoud Acceptatietest Uitvoering points Bij oplevering van maatwerk-software vindt een acceptatietest plaats. Doel van de acceptatietest: Voldoet de software aan eisen en wensen van de opdrachtgever? Is de software geschikt is voor bedrijfsmatige ingebruikname? FvO,PvdH/FHTBM SEN1 Software Engineering 1 6 maart 2008 5/27
Belangen Opdrachtgever Acceptatietest voor wie? Belangen Wat te testen? Inhoud Acceptatietest Uitvoering points Garantiebepalingen De leverancier kan de kosten van herstel in rekening brengen indien de fouten bij het uitvoeren van de overeengekomen acceptatietest hadden kunnen worden vastgesteld. Na acceptatie is leverancier op grond van deze overeenkomst niet gehouden tot het herstel van gebreken in de software. FvO,PvdH/FHTBM SEN1 Software Engineering 1 6 maart 2008 6/27
Belangen Softwareontwikkelaar Acceptatietest voor wie? Belangen Wat te testen? Inhoud Acceptatietest Uitvoering points Kwaliteit en efficiëntie: Door een grondige acceptatietest uit te voeren worden mogelijk kosten voor herstelwerk bespaard. De testperiode biedt een goede gelegenheid om de kwaliteit en de betrouwbaarheid van de software te verbeteren. FvO,PvdH/FHTBM SEN1 Software Engineering 1 6 maart 2008 7/27
De onderhandeling Overzicht Acceptatietest voor wie? Belangen Wat te testen? Inhoud Acceptatietest Uitvoering points Onvolkomenheden zijn fouten en gebreken of het op andere wijze niet functioneren overeenkomstig de overeengekomen specificaties. Hoe preciezer die zijn, des te groter de kans dat de opdrachtgever onvolkomenheden kan vinden. De opdrachtgever zal toch zijn eisen zo nauwkeurig mogelijk willen omschrijven. FvO,PvdH/FHTBM SEN1 Software Engineering 1 6 maart 2008 8/27
Inhoud acceptatietest 1 Acceptatietest voor wie? Belangen Wat te testen? Inhoud Acceptatietest Uitvoering points De functionaliteit: alle aspecten van gedrag en resultaten volgens de overeengekomen specificaties. Robuustheid. Zinvol reageren op foute invoer, technische foutsituaties en gebruikersfouten. De conversieprocedure voor overzetten van gegevens op de nieuwe software. Koppelingen met uw andere informatiesystemen. FvO,PvdH/FHTBM SEN1 Software Engineering 1 6 maart 2008 9/27
Inhoud acceptatietest 2 Acceptatietest voor wie? Belangen Wat te testen? Inhoud Acceptatietest Uitvoering points De performance. De gebruiksvriendelijkheid. Voldoen aan kwaliteitsgaranties als overeengekomen. In de informatica algemeen aanvaarde uitgangspunten van kwaliteit en deugdelijkheid. De documentatie voor beheerders en gebruikers. De procedures voor handmatige werkzaamheden. FvO,PvdH/FHTBM SEN1 Software Engineering 1 6 maart 2008 10/27
Hoe de test uitvoeren? Acceptatietest voor wie? Belangen Wat te testen? Inhoud Acceptatietest Uitvoering points Richt tijdig de testomgeving in (hardware, software, documentatie, licenties en werkruimte). Bepaal wie de testen gaat(n) uitvoeren. Schrijf vooraf concrete test-scenario s. Mee beginnen zodra de functionele specificaties beschikbaar zijn. Zorg voor de tijdelijke administratieve organisatie in voor het verzamelen en administreren van testresultaten. FvO,PvdH/FHTBM SEN1 Software Engineering 1 6 maart 2008 11/27
Soorten V & V Overzicht Acceptatietest voor wie? Belangen Wat te testen? Inhoud Acceptatietest Uitvoering points Software Inspections Requirements specification High level design Formal specification Detailed design Program Prototype Program testing Figuur: Static and dynamic verification and validation. FvO,PvdH/FHTBM SEN1 Software Engineering 1 6 maart 2008 12/27
Het verschil Overzicht Inspection and review Review plan debugging Validation: maken we het juiste product? Is meer algemeen onderdeel. Maken we dat wat de klant wil? Verification: Maken we het product goed? Dynamisch testen is draaien van de software met testdata. V&V zijn statisch: inspecties en reviews tijdens alle fasen van het ontwikkelingsproces. Validatie testen: aantonen dat de software doet wat de klant wil. Zoals prestatie en betrouwbaarheid. Een scherpe grens is niet te trekken tussen al deze indelingen. FvO,PvdH/FHTBM SEN1 Software Engineering 1 6 maart 2008 13/27
Inspection and review Inspection and review Review plan debugging Inspectie en review zijn beide statische verificatie technieken, waardoor het systeem niet uitgevoerd hoeft te worden. Inspection is de preciezere variant. De zogenaamde Fagan inspectie volgt een strict protocol met verschillende rollen voor de deelnemers tijdens de inspectie. Reviewen is een minder strikte methode. Het dient evengoed volgens een plan met een doel te worden uitgevoerd. FvO,PvdH/FHTBM SEN1 Software Engineering 1 6 maart 2008 14/27
Doel van de review Overzicht Inspection and review Review plan debugging Net als de andere test technieken, kan reviewen hooguit fouten vaststellen. De soort inhoudelijke fouten waarnaar gezocht moet worden zijn: 1 Onvolledigheid of missende informatie. 2 Inconsistentie of tegenspraken. 3 Onduidelijkheden of vaagheden. Door deze gebreken zijn er keuzes mogelijk in de vervolgstappen, waardoor de onzekerheid toeneemt. FvO,PvdH/FHTBM SEN1 Software Engineering 1 6 maart 2008 15/27
Inspection and review Review plan debugging Test results Specification Test cases Locate error Design error repair Repair error Retest Program Figuur: Debugging process. FvO,PvdH/FHTBM SEN1 Software Engineering 1 6 maart 2008 16/27
V-model Overzicht Figuur: Uiteraard verwachten we dat coderen en testen hand in hand gaan. FvO,PvdH/FHTBM SEN1 Software Engineering 1 6 maart 2008 17/27
V-model als test en ontwikkelcyclus In moderne ontwikkelmethodology is het V-Model aan de winnende hand. Het V-model schrijft een balans voor tussen specificatie aan de linker zijde en verificatie/validatie aan de rechterzijde, op alle niveaus van de ontwikkeling Let op dat de stappen aan beide kanten van de V steeds gepaard gaan met documenten. FvO,PvdH/FHTBM SEN1 Software Engineering 1 6 maart 2008 18/27
Inhoud testplan Overzicht Testen schrijven en plannen Test scenarios Test tools Organisatie: beschrijving hoe de test is georganiseerd, waar liggen verantwoordelijkheden en wat zijn de gebruikte middelen. Communicatie en procedures: o.a. procedures rond herstel van fouten, versie beheer. : Overzicht van de test strategie, criteria voor acceptatie van de test en tot op welk nivo wordt er getest? FvO,PvdH/FHTBM SEN1 Software Engineering 1 6 maart 2008 19/27
Inhoud testplan 2 Overzicht Testen schrijven en plannen Test scenarios Test tools Test onderdelen: overzicht van de functies die getest gaan worden met hun prioriteiten. Test deliverables: beschrijving van de gebruikte producten: inputs, test-reporten, infrastructuur en voortgangsrapporten. Test activiteiten: installatie van de infrastructuur, schrijven van testscripts, de uitvoering van de test, de voortgangsmonitoringe en het maken van de testrapporten. Planning: de feitelijke planning van de software testactiviteiten en gebruikte middelen. FvO,PvdH/FHTBM SEN1 Software Engineering 1 6 maart 2008 20/27
Test scenario s Overzicht Testen schrijven en plannen Test scenarios Test tools Zijn in essentie de concrete scenario s behorende bij een use-case. Soms bedoelt met testscenario s een testprogramma, d.w.z.: welke testen en in welke volgorde worden uitgevoerd. Men gebruikt ook zogenaamde test scripts als er bij een testprocedure met een softwaretool automatisch een aantal testen uitgevoerd moet worden. FvO,PvdH/FHTBM SEN1 Software Engineering 1 6 maart 2008 21/27
Test tools Overzicht Testen schrijven en plannen Test scenarios Test tools Er zijn commerciële producten voor automatisch testen, maar er is ook ant in combinatie met JUnit. Een ander framework is Castor. Er is meer (http://java-source.net/open-source/testing-tools): JUnit, Cactus, Abbot (waar is Costello?), JUnitPerf, Jamelon, DbUnit, Mockrunner, dbmonster, The Grinder, XMLUnit, jfcunit, JTestCase, StrutsTestCase, jmock, EasyMock, MockEJB, MockCreator, SQLUnit, Marathon, TestNG, Surrogate Test framework, JTR Java Test Runner, TESTARE, MockLib, TagUnit, TestGen4J, UISpec4J, Jacareto, Jemmy, DDTUnit, Mocquer En de lijst is zeker niet volledig! Groovy van IBM. FvO,PvdH/FHTBM SEN1 Software Engineering 1 6 maart 2008 22/27
Hoe vinden we testdata? Men wil natuurlijk alles testen! Men kan niet alle waarden testen Er zijn nuttige technieken om een beperkte maar voor het testen complete verzameling van testdata te vinden Grenswaarden en extreme waarden. Bepalen van equivalentieklassen. FvO,PvdH/FHTBM SEN1 Software Engineering 1 6 maart 2008 23/27
In- en output partitions FvO,PvdH/FHTBM Figuur: De invoer ensen1 uitvoer Software Engineering kan men 1 verdelen in verschillende 6 maart 2008 klassen. 24/27 invalid valid invalid valid invalid valid invalid valid valid valid valid valid system output output output output output output output output
Voorbeeld equivalence partitioning 1 2 3 4 a b c Er is hier sprake van 4 partities: 1 x < a 2 a x < b 3 b x < c 4 x c Partitie equivalentie veronderstelt dat elke waarde in de partitie op gelijk manier behandeld moet worden. Kies bijvoorbeeld een waarde uit het midden. Maar ook de grenzen verdienen aandacht: Test of de grenswaarden door het programma behandeld worden volgens de regels bij de juiste partitie. Hier hoort a bijvoorbeeld bij partitie 2. FvO,PvdH/FHTBM SEN1 Software Engineering 1 6 maart 2008 25/27
Clock12 interface public interface Clock12 { void tick (); void settime ( boolean pm, int hrs, int min, int sec ); int gethour (); int getminutes (); int getseconds (); void sethour ( int hour ); void setminutes ( int minutes ); void setseconds ( int seconds ); boolean ispm (); void setpm ( boolean pm ); String gettime (); } FvO,PvdH/FHTBM SEN1 Software Engineering 1 6 maart 2008 26/27
Equivalence classes Equivalenc classes : sethour : 1 hour < 0 invalid data 2 0 <= hour <12 valid data 3 12 <= hour <= 24 valid data 4 hour > 24 invalid data input : hour =16 -> hour =4 && PM = true -7 -> exception " hour not negative " 5 -> hour =5 && PM = false 57 -> exception " hour not greater than 24" etc. FvO,PvdH/FHTBM SEN1 Software Engineering 1 6 maart 2008 27/27