Bijlage DO - i) Rapport Detailontwerp Secretariaat sportvereniging

Transcriptie

1 Bijlage DO - i) Rapport Detailontwerp Secretariaat sportvereniging a) Rapport toekomstige organisatie (uittreksel) Centrale rol van de secretaris Omdat met behulp van het informatiesysteem alle gegevens van de leden centraal zullen worden beheerd, zal het informatiesysteem een centrale rol gaan spelen in het verenigingsgebeuren. Zo zal bijvoorbeeld voor alle correspondentie aan de leden (uitnodigingen, berichten van het bestuur en verzending van het clubblad) gebruik gemaakt worden van de centraal opgeslagen adresgegevens. Daarmee wordt de secretaris die het informatiesysteem zal bedienen, een centrale persoon in het verenigingsgebeuren. Verantwoordelijkheid voor informatiesysteem De secretaris zal "verantwoordelijk" gesteld worden voor het goed functioneren van het informatiesysteem en ook voor het up to date houden van de gegevens. Daaronder valt ook het regelmatig maken van backups (veiligheidskopiën) van de gegevens. Deze backups worden bewaard door de voorzitter van de vereniging, zodat in geval van brand of diefstal bij de secretaris het verenigingssecretariaat niet geheel verloren zal zijn. Postale verzendingen Om ervoor te zorgen dat verzendadressen steeds up to date zijn zal de secretaris steeds vlak voor verzending de benodigde adresgegevens op etiketten afdrukken. De opdrachtgevers kunnen deze etiketten dan afhalen bij de secretaris en hun post daarmee versturen. Overzichten Trainers, aanvoerders, bestuursleden en commissieleden (in een later stadium misschien ook individuele leden) kunnen de secretaris verzoeken om overzichten van de opgeslagen gegevens op de printer af te drukken. Voor trainers en aanvoerders van een team zijn bijvoorbeeld steeds bijgewerkte adresgegevens van de spelers van dat team nodig. Clubblad De commissies en het clubblad zullen zelf geen printerpapier en etiketten aan hoeven te schaffen. De secretaris zal steeds zorgen voor voldoende printerpapier en etiketten. Op basis van schattingen zal bepaald worden met welk bedrag het budget van de secretaris daarom verhoogd moet worden. Tevens zal worden bekeken of en hoe deze extra lasten verdeeld moeten worden over de commissies en het clubblad. Adreswijzigingen zullen in het vervolg naar de secretaris gestuurd moeten worden. Voorheen hield het clubblad hiervoor zijn eigen administratie bij. Die administratie is nu niet meer nodig. DO-bijlagen B blz.1

2 b) Rapport functioneel ontwerp (uittreksel) Gedetailleerde gegevensstructuur Verenigingsadministratie: Het via de ORM-schematechniek weergegeven conceptuele datamodel is: { 'Jeugd1, Jeugd2,', 'Dames1, Dames2,', 'Heren1, Heren2, ', 'Heren3' } <= 6 met / aanvoerder van heeft / van P Voornaam overgangsreg zie c) * Team (teamnaam) heeft / van <= 2 <= 2 Speler heeft / van Achternaam Straat_nr speelt in / van zie b) * met / trainer van met met / van woont op Adres Datum met / van met / van P Plaatsnaam Klasse / van * zie a) is geboren op { '1, 2, 3, 4' } overgangsreg zie d) * Bondsnummer waarbij a), b), c) en d) naar de volgende aanvullende tekstueel (niet-grafisch) gegeven beperkingsregels verwijzen: a) Deze relatie is af te leiden: 'klasse van speler' = ' klasse van team met speler'. b) Deze relatie is af te leiden: 'klasse van team' = 'klasse van speler van team'. c) Er gelden de volgende overgangsregels voor Team: team Jeugd 1 Jeugd 2 Dames 1 Dames 2 Heren 1 Heren 2 Heren 3 Jeugd 1 Jeugd 2 Dames 1 Dames 2 Heren 1 Heren 2 Heren 3 d) Er gelden de volgende overgangsregels voor Klasse: klasse DO-bijlagen B blz.2

3 Bovendien geldt binnen de vereniging: Speler met jaartal huidige datum - jaartal Geboortedatum < 16 is speler van Team 'Jeugd 1' OF is speler van Team 'Jeugd 2' Identificatie van de nog niet via een primary reference code geïdentificeerde entiteit-objecten: Object Identificatie Speler 'voornaam' + 'achternaam' Adres 'straatnaam + huisnummer' + 'plaatsnaam' Detaillering van de gegevens: Gegevensnaam Soort Eventuele beperkingen 'teamnaam' string[7] Jeugd 1, of 2, Dames 1 of 2, Heren 1 t/m 3 'klassenummer' numeriek[1] 1 t/m 4 'voornaam' string[10] 'achternaam' string[15] 'bondscode' string[8] 'datum' datum-type 'straatnaam + huisnummer' string[20] 'plaatsnaam' string[15] c) Rapport technisch ontwerp (uittreksel) Detailontwerp opslagstructuur Verenigingsadministratie TABEL trainers SLEUTEL voornaam + achternaam (van trainer) + teamnaam VELDEN voornaam (van trainer) string[10] achternaam (van trainer) string[15] teamnaam string[7] Tabel trainers voornaam achternaam teamnaam TABEL spelers SLEUTEL voornaam + achternaam VELDEN voornaam string[10] achternaam string[15] teamnaam string[7] straatnaam + huisnummer string[20] plaatsnaam string[15] geboortedatum datum-type bondscode string[8] DO-bijlagen B blz.3

4 Tabel spelers voornaam achternaam teamnaam straatnaam + huisnummer plaatsnaam geboortedatum bondscode 1..6 N.B. 1) N.B. 2) bondscode is geen (alternatieve) sleutel, want de rol is niet totaal (wel uniek) klassenummer is niet opgenomen in spelers-, maar in team-tabel. Als de klasse in de spelers-tabel is opgeslagen, zou, wanneer een team van klasse verandert (degraderen/promoveren team) de klasse van alle spelers van dat team moeten veranderen. Als de klasse in de spelers-tabel is opgeslagen, zou, wanneer een speler van team verandert, eerst opgezocht moeten worden in welke klasse het team speelt, voordat de juiste klasse van de speler kan worden ingevuld. N.B. 3) aanvoerder niet opgenomen in spelers-, maar in team-tabel. Dat geen veld aanvoerder in de spelers-tabel wordt opgenomen is een kwestie van ruimtebesparing, want in de spelers-tabel is dit veld optioneel (dat wil zeggen dat het niet altijd zal zijn ingevuld, omdat niet elke speler aanvoerder is), maar in de teamtabel is het veld niet optioneel. Om snel zoeken op bondscode mogelijk te maken wordt op de spelers-tabel [ook] een index gemaakt op bondscode. Evenzo zullen we op deze tabel een andere index maken op plaatsnaam. TABEL team SLEUTEL teamnaam PRIMAIR (aanvoerders)voornaam + achternaam ALTERNATIEF VELDEN teamnaam string[7] voornaam (van aanvoerder) string[10] achternaam (van aanvoerder) string[15] klassenummer numeriek[1] Tabel team teamnaam voornaam achternaam klassenummer P DO-bijlagen B blz.4

5 Bijlage DO - j) Functioneel testplan opstellen Inleiding Om te testen of een ontwikkeld programma voldoet aan de er aan te stellen eisen zijn een aantal testtechnieken beschikbaar waarvan de belangrijkste zijn: - de opgestelde programma-code zorgvuldig laten lezen door derden en laten controleren op fouten (deze mogelijkheid wordt minder toepasbaar indien gebruik gemaakt wordt van code-generatoren) - programma door de maker laten presenteren in een groep en de groep laten controleren op fouten en nalatigheden - de correctheid van een programma formeel (wiskundig) bewijzen - het gebruik van het programma simuleren, dat wil zeggen het programma op testgegevens laten werken. In de projectgroepen kan met vrucht van de eerste twee technieken gebruik gemaakt worden. Bedenk je daarbij dat voorkomen beter is dan genezen, het opsporen van een fout kost vaak veel meer tijd en moeite dan het voorkomen van de fout. De vierde techniek is hier het onderwerp van bespreking. Testen door simulatie Wij stellen ons voor dat wij de functies van het informatiesysteem willen testen door simulatie. Het basisstramien is dan: - leg de beginsituatie vóór simulatie vast - simuleer de activiteiten van het informatiesysteem (een denkproces!) - leg de eindsituatie na simulatie vast. Eerst simuleren wij de activiteiten van het informatiesysteem, daarna laten wij het systeem daadwerkelijk de activiteiten uitvoeren: - breng het systeem in de beginsituatie. controleer deze beginsituatie door hem zichtbaar te maken - laat het systeem zijn activiteiten uitvoeren - maak de eindsituatie van het systeem zichtbaar. Vergelijking van de eindsituatie na simulatie (in gedachten of op papier!) met die na werkelijke uitvoering door het gebouwde systeem maakt duidelijk of het systeem dit testgeval goed heeft afgewerkt. Zo ja, dan zijn wij blij; zo nee, dan zal de fout gezocht en verbeterd moeten worden. Opstellen van een testplan Wij moeten alle functies van het informatiesysteem testen op hun goede werking. Wij moeten daarvoor eerst de volgorde kiezen waarin wij die functies willen testen. Dit kan op twee manieren: Top-Down en Bottom-Up. Wij zullen bij het testen Bottom Up werken, dat wil zeggen dat wij eerst de basisfuncties van het informatiesysteem testen, daarna de functies en de hoofdfuncties en tot slot het systeem als geheel. Elke test - of het nu gaat om een basisfunctie, een functie, een hoofdfunctie of het systeem als geheel - moet vastliggen in een testplan dat in activiteit 3.13 van de detailontwerp-fase gemaakt wordt. Het testplan vermeldt om welke functie het gaat en specificeert welke testgevallen moeten worden afgewerkt. Mocht nu blijken dat dat testplan onvolledig is, dan kun je het bij activiteit 4.2 (en desnoods nog 4.4 en 4.7) aanvullen. Gemakkelijk is om in het testplan meteen ruimte te reserveren om ook de bevindingen bij het testen in te noteren, dan staat alles bij elkaar en heb je meteen een testrapport. Iedereen die in de realisatiefase een functie realiseert, is verplicht de gespecificeerde testgevallen op die (afzonderlijke) functie uit te testen. Gegevens bij testgevallen bedenken Om de basisfuncties, functies en hoofdfuncties van het informatiesysteem te testen moet je testgevallen kiezen. Misschien denk je dat je alle mogelijkheden die zich zouden kunnen voordoen uitputtend kunt testen; die DO-bijlagen B blz.5

6 gedachte moet je dan maar snel laten varen: in de meeste gevallen is uitputtend testen onmogelijk omdat er gewoon teveel mogelijkheden zijn. Wij vallen daarom terug op selectief testen; wij proberen testgevallen te vinden die representatief zijn voor klassen van mogelijkheden. Dat wil zeggen dat je redelijk zeker bent dat als de functie in het testgeval goed werkt deze ook in de andere gevallen die binnen de klasse mogelijk zijn, goed zal werken. Daarnaast probeer je die testgevallen te vinden die met een extreem geval samenvallen. In activiteit 3.13 van het Detailontwerp bedenken we de testgevallen, die in SDM-fase 4 bij activiteiten 4.4 en 4.7 getest moeten worden. Bij elk van de testgevallen horen concrete testgegevens die op de functie worden uitgeprobeerd. Die testgegevens moeten we nu alvast bedenken en vastleggen. A) acceptatietest (om pas uit te voeren bij activiteit 4.9) In de praktijk zal de acceptatietest vaak door de opdrachtgever worden opgesteld (in samenspraak met de ontwikkelaar van het systeem). In deze test probeert men zoveel mogelijk de realiteit van het gebruik van het informatiesysteem te benaderen. Er wordt niet met verzonnen maar met praktijkgegevens getest; er wordt zoveel mogelijk gewerkt met het informatiesysteem zoals dat in de praktijk ook zal gebeuren. Voor de acceptatietest moet je dus proberen een testgegevens te krijgen die zo nauw mogelijk bij de praktijksituatie aansluiten. In dit project wordt de acceptatietest door de cursusleiding opgesteld en uitgevoerd. Jij hoeft je daarmee niet bezig te houden. B) systeemtest (om uit te voeren bij activiteit 4.7) De systeemtest is de tegenhanger van de acceptatietest; deze wordt door de ontwikkelaars van het systeem uitgevoerd om na te gaan of het systeem naar behoren functioneert en of het opgeleverd kan worden aan de klant voor de acceptatietest. In de systeemtest gaat het er om te testen of de hoofdfuncties en de functies die uit reeds geteste basisfuncties zijn samengesteld, naar behoren functioneren. Bij het bedenken van de gegevens voor deze test gaat het er dus om gegevens te verzinnen bij de testgevallen die straks duidelijkheid geven of het totale systeem naar behoren functioneert. C) basisfuncties testen In het detailontwerp ontwerpen we de basisfuncties in detail. Daar bedenken we ook de testgevallen. In de realisatiefase moeten de testgevallen voor de basisfuncties van te testen gegevens voorzien worden. Je weet wat de testgevallen voor de basisfuncties zijn en je verzint er de testgegevens bij. De testgevallen met de bijbehorende testgegevens worden opgenomen in het testplan of testscenario. Het testplan wordt in activiteit 4.4 Programmeer en test door de programmeurs van de betreffende (basis-) functies uitgevoerd. Het vooraf (door de ontwerpers) bedenken van de uit te voeren testen werkt daarbij aanzienlijk beter dan het maar aan de programmeur overlaten van het bedenken van testgevallen en testgegevens; programmeurs blijken vaak uiterst selectief te testen en daarbij belangrijke problemen over het hoofd te zien. We gaan (in omgekeerde volgorde; dus bottom up) nu verder in op deze drie test-onderdelen. Testen van de invoerfuncties Om de invoerfuncties goed te kunnen testen zullen we eerst moeten weten wat en hoe we willen testen. Uitgaande van het detailontwerp weten we welke soorten gegevens ingevoerd gaan worden in de gegevensbank. Ook kunnen we hieruit destilleren van welk type de gegevens moeten zijn en welke verdere beperkingen aan deze gegevens verbonden zijn. Aan de hand van de gegevens over de in acht te nemen beperkingsregels zijn de invoerfuncties geïmplementeerd. Met de geïmplementeerde invoerfuncties kunnen we de in te voeren gegevens een voor een gaan testen. Hiermee bedoelen we dat voor ieder gegeven afzonderlijk moet gelden dat: a) de gegevens die geaccepteerd moeten worden ook daadwerkelijk geaccepteerd worden. b) de gegevens die geweigerd moeten worden moeten ook daadwerkelijk geweigerd worden, en als een gegeven geweigerd wordt moet er een toepasselijke foutmelding gegenereerd worden en op het beeldscherm verschijnen. (Denk hierbij o.a. aan de beperkingsregels.) Om dit te kunnen testen moeten we dus zowel een aantal voorbeelden verzinnen die geaccepteerd als voorbeelden die geweigerd moeten worden door het systeem. DO-bijlagen B blz.6

7 Enkelvoudige gegevens testen (voorbeelden): Het type char/string/tekst Gegevens van het 'tekst'type brengen meestal niet zoveel beperkingen met zich mee; vaak beperkt zich dat tot het afdwingen van een totaliteitsregel (verplichte rol), maar ook kunnen er expliciete waarderegels gelden. Het kan bijvoorbeeld echter zijn, dat er binnen zo'n gegeven géén cijfers mogen voorkomen of dat een gegeven uit minstens 'n' (een bepaald aantal) karakters moet bestaan. Voor dit soort beperkingen kunnen we vrij simpel tegenvoorbeelden verzinnen en die dan proberen in te voeren: Stel: - een string moet uit minstens 3 karakters bestaan en maximaal 15 en mag geen cijfers bevatten -- probeer een string in te voeren met minder dan 3 karakters -- probeer een string in te voeren met 3 karakters (randgeval) -- probeer een string in te voeren met meer dan 15 karakters -- probeer een string in te voeren met 15 karakters (randgeval) -- probeer een string in te voeren waarin een cijfer voorkomt Hiermee hebben we alle voorkomende enkelvoudige fouten gehad maar daarmee zijn we er nog niet. Het zal namelijk niet de eerste keer zijn dat enkelvoudige fouten wél gedetecteerd worden, maar een combinatie van fouten niet. Voeg daarom de volgende aanvullende tegenvoorbeelden toe: -- probeer een string in te voeren waarin een cijfer voorkomt en die minder dan 3 karakters bevat. -- probeer een string in te voeren waarin een cijfer voorkomt en die meer dan 15 karakters bevat. -- probeer de voorgaande combinaties met de randgevallen Let vooral ook op het al dan niet accepteren (resp. mogen worden) van randgevallen. Vaak voorkomende randgevallen voor het werken met teksten zijn: - de lege tekst (""), - een tekst met één spatie (" "), - een tekst van maximale lengte (afhankelijk van bijvoorbeeld de veldlengte die je hebt opgegeven) en - een tekst van maximale lengte + 1. Een complex voorbeeld is ook dat van een postcode-string; die moet bestaan uit een reeks van 4 cijfers (waarvan het eerste cijfer niet 0 mag zijn), gevolgd door een spatie en tot slot 2 hoofdletters. Een paar waarden die níet toegestaan zijn, zijn o.a.: '0123 AV', '123 DD', '12', '1234AA', '1234 A', etc. Het type integer/getal/numeriek Gegevens van een getals-type hebben meestal alleen beperkingen op de waarden die ingevoerd mogen worden. Bijvoorbeeld: Stel: - een integer waarde moet tussen 0 en 10 liggen -- probeer een getal dat kleiner is dan 0 -- probeer een getal dat groter is dan probeer 0 (een randgeval dat geaccepteerd moet worden) -- probeer probeer een string Vaak voorkomende randgevallen voor het werken met getallen zijn: -- de hoogste toegestane waarde, -- de hoogst toegestane waarde + 1, -- de laagste toegestane waarde, -- de laagste toegestane waarde - 1 en: levert vaak problemen op wanneer je in het programma delingen gebruikt. Delen door 0 mag namelijk niet. Het type datum Bij datumgegevens kunnen we een aantal wél en níet bestaande data verzinnen en die proberen in te voeren. Stel: - een datumwaarde moet altijd na een bepaalde datum liggen -- probeer een niet bestaande datum {13/13/13} -- probeer een datum die vóór die bepaalde datum ligt -- probeer die bepaalde datum zélf (randgeval) DO-bijlagen B blz.7

8 Als alle foutieve gegevens netjes geweigerd zijn en alle correcte gegevens geaccepteerd is er niets aan de hand. Maar meestal zijn er wel een paar foutjes die eerst gecorrigeerd moeten worden. Na de correctie van de invoerfuncties zullen we de testen opnieuw uit moeten voeren en opnieuw moeten bekijken of de invoerfuncties correct zijn. Door deze werkwijze zullen er in de meeste gevallen een aantal gegevens in de gegevensbank terecht komen die daar eigenlijk niet in thuis horen en die zullen we voor we verder kunnen gaan eerst moeten verwijderen, zodat we verder gaan met een consistente database-inhoud. Combinaties van gegevens testen Nu alle enkelvoudige invoerfuncties correct zijn kunnen we combinaties van gegevens gaan testen. Bijvoorbeeld als de acceptatie van een in te voeren gegeven afhangt van al eerder ingevoerde gegevens. Ook bij dit soort beperkingen zullen we weer na moeten gaan wat er allemaal fout kan gaan en voor iedere fout een voorbeeld verzinnen denk hierbij ook weer aan de randgevallen. Met name randgevallen kunnen nogal eens problemen opleveren. Al de combinaties die geweigerd moeten worden, zullen weer moeten worden ingevoerd totdat het systeem alleen nog correcte gegevens accepteert. Nadat we hiervan overtuigd zijn kunnen we de gegevensbank weer ontdoen van incorrecte gegevens en kunnen we de gegevensbank gaan vullen of laten vullen, liefst door iemand die het systeem nog niet kent, zodat het echt 'idiotensicher'/'foolproof'/katbestendig kan worden. Het programma mag onder geen voorwaarde crashen op foutieve gebruikers-invoer. Randgevallen voor tabellen Bij het gebruiken van een gegevenstabel moet je altijd een aantal gevallen onderscheiden: -- de tabel zou leeg kunnen zijn -- een gezochte waarde komt niet voor in de tabel -- de gezochte waarde komt wél voor in de tabel, en wel: -- op de eerste regel van de tabel -- ergens tussen de eerste en de laatste regel van de tabel -- op de laatste regel van de tabel -- de gezochte waarde komt meerdere keren in de tabel voor. Een aantal van de hier boven beschreven gevallen zijn 'randgevallen' voor het werken met tabellen. Randgevallen komen in de praktijk zelden voor, maar blijken vaak een bron van fouten te zijn. Programma's die jarenlang goed werken kunnen opeens 'kuren' gaan vertonen. Het is daarom belangrijk extra aandacht te besteden aan randgevallen. Functioneel (systeem/acceptatie-) testplan opstellen In deze activiteit wordt het functionele deel van het testplan opgesteld. De acceptatietest wordt bij B3 door de cursusleiding gedaan. Activiteit 3.13 houdt echter meer in dan zomaar plannen maken voor het testen van de functies in de acceptatietest. In deze activiteit worden immers ook de testen voorbereid die in activiteit 4.4 Vervaardig en test programmatuur van het de realisatiefase moeten worden uitgevoerd. Het is goed de zaken voor wat betreft het testen nog eens op rij te zetten: In de definitiestudie wordt het raamwerk (procedure) van de acceptatietest vastgelegd in activiteit 1.8. In het geval van B3 is de procedure reeds bekend: de acceptatietest wordt volledig door de cursusleiding uitgevoerd. In het basisontwerp is in onze cursus ook de menustructuur ontworpen: de menuschermen liggen vast en in de menuboom is de dialoog met de gebruiker vastgelegd. Dit betekent dat dan meteen het testplan voor de menu's gemaakt kan worden. DO-bijlagen B blz.8

9 In het detailontwerp functioneel deel worden naast de basisfuncties ook de interacties met de gebruikers (beeldschermen) en de beperkingsregels beschreven. Dat betekent dat je in de fase detailontwerp technisch deel, in activiteit 3.13 ook kunt beschrijven hoe je gaat testen of basisfuncties correct functioneren, of de beeldschermen voldoen aan de gestelde eisen en of beperkingsregels niet worden overtreden. In de realisatie-fase worden in activiteit 4.4 niet alleen de afzonderlijke procedures en programma's in concreto gemaakt, maar ook getest. In de realisatie-fase wordt tijdens activiteit 4.7 de systeemtest uitgevoerd. De ontwikkelaars van het informatiesysteem voeren deze systeemtest uit. In deze test wordt het complete systeem getest. De onderdelen zijn al wel eerder in de testketen afzonderlijk getest, maar hier ligt vooral de nadruk op het testen of de onderdelen ook in het grotere geheel goed functioneren. In de praktijk komt daar nog bij: In de realisatie-fase wordt tijdens activiteit 4.9 de acceptatietest uitgevoerd door (/namens) de opdrachtgever. Als er is besloten om Bottom-Up te testen, is de systeemtest het laatste onderdeel in de testketen: het testen van hoofdfuncties en hun onderlinge samenhang. Alle functies, opgebouwd uit de basisfuncties die we in onderdeel 2.4 van het basisontwerp boven water hebben gekregen, zijn samengevoegd tot de hoofdfuncties. We gaan er bij het testen van de hoofdfuncties van uit dat de functies en basisfuncties reeds getest en correct bevonden zijn in het voorgaande deel van het testproces. Bij het testen van deze hoofdfuncties onderling en de functies als onderdeel van zo'n hoofdfunctie kunnen onder andere dezelfde testgegevens gebruikt worden als bij het testen van de functies en basisfuncties eerder in de testketen gebruikt zijn. De testen worden uitgevoerd om te controleren of de verschillende hoofdfuncties op de juiste wijze met elkaar samenwerken en geen ongewenste invloed op elkaar uitoefenen. Let er echter wel op dat eventuele inconsistentie in de testgegevens, ontstaan door een eerder in de testketen mislukte test, verwijderd wordt voordat doorgegaan wordt met testen. Anders zou je, door de aanwezigheid van deze inconsistentie, ten onrechte tot de conclusie kunnen komen dat er een test mislukt is en er iets mis is met de functies. SDM-activiteit 3.13 : vervaardig gedetailleerd testplan: In deze activiteit moeten de testgevallen geïdentificeerd worden. Hierna staan voorbeelden van testgevallen. A) Testgevallen voor de menustructuur Menu's moeten met twee soorten invoer worden getest: met correcte invoer en incorrecte invoer. De correcte invoer bestaat uit de keuzes zoals die in het menu worden aangegeven. Als deze keuzes worden gemaakt moeten de functies behorende bij deze keuzes ook werkelijk uitgevoerd worden en geen andere, en als deze functies uitgevoerd zijn moet er na afloop ook weer teruggekeerd worden naar dit menu. Als je gebruik maakt van een pull down menustructuur, dan is het meestal overbodig te testen op incorrecte invoer; die bestaat uit keuzes die niet in het menu staat aangegeven. Als zo'n keuze wordt gemaakt moet daarvan een melding gegeven worden en de mogelijkheid geboden worden om opnieuw een (correcte) keuze te maken. B) Testgevallen voor basisfuncties In deze activiteit (activiteit 3.13) moeten we alvast testgevallen verzinnen voor het testen van de basisfuncties in activiteiten 4.4, 4.7 en 4.9. Dit doen we aan de hand van de in activiteit 3.3 gevonden beperkingsregels (worden ze wel gecontroleerd en afgedwongen?), de algoritmische detailuitwerking van de basisfuncties (gedraagt het systeem zich wel zoals afgesproken?) en de schermen en menu's zoals uitgewerkt (zien ze eruit zoals gespecificeerd?). B.1) Testgevallen voor de beperkingsregels Iedere beperkingsregel uit het conceptueel model moet getest worden! Bij elke beperkingsregel hoort een foutmelding die getoond moet worden als die beperkingsregel overtreden wordt. Omdat op dit niveau alleen de testgevallen voor de basisfuncties afzonderlijk opgesteld worden, is het niet altijd mogelijk om met de testgevallen van de ene functie de correcte werking van een andere daarmee samenhangende te controleren. Beide functies zouden immers nog niet correct bevonden kunnen zijn. De correcte werking is tijdens het testen in de realisatiefase vaak alleen te controleren door na afloop van een test rechtstreeks in de gegevenstabel te kijken met behulp van commando's van de taal waarin geprogrammeerd gaat worden. DO-bijlagen B blz.9

10 Uiteraard hoeft het naleven van beperkingsregels alleen in de gaten te worden gehouden bij basisfuncties die gegevens in de database kunnen veranderen (dus: invoer/mutatie/verwijder-functies). Wel zullen we (o.a.) bij opvragingsfuncties, voor wat het gedrag naar de gebruiker toe betreft, een onderscheid moeten maken tussen wél en níet aanwezige opgegeven (selectie-) waarden. Het vereiste gedrag hierbij is bij activiteit 3.3 vastgelegd. Het is het handigst om per basisfunctie de testgevallen op te sommen en als uitgangspunten de bij activiteit 3.9 gespecificeerde beeldschermindelingen te gebruiken en die te houden naast enerzijds het conceptuele schema (3.4) en anderzijds het (bij 3.3) vastgelegde gewenste gedrag van de functies. Voorbeelden: I) de invoerfunctie: voeg factuur toe Stel dat we bij activiteit 3.9 voor deze basisfunctie de volgende user interface hebben vastgelegd: Factuur toevoegen Factuurnummer: Klantnummer: Artikelnummer: Factuurbedrag: Datum: Klantnaam: Bewaren Afbreken We gaan voor dit scherm nu systematisch alle velden aflopen en de testgevallen vastleggen: 1 Het programma zélf moet een uniek factuurnummer genereren, door steeds een waarde één hoger te nemen dan het grootste reeds voorkomende factuurnummer. Test: - gebeurt dit bij een nog lege gegevenstabel? - gebeurt dit bij een reeds gedeeltelijk gevulde gegevenstabel? 2 Het mag niet mogelijk zijn het gegenereerde factuurnummer handmatig te veranderen. 3 Zolang niet alle velden zijn ingevuld, moet de push button <Bewaren> gedeactiveerd zijn. De <Afbreken> push button moet altijd actief zijn. Test dit uit, met een of meer velden (roulerend) níet ingevuld. Het volgende is steeds van toepassing op een toestand met een geactiveerd <Bewaren> (dus met alle velden ingevuld): 4 In het datum-invoerveld moet een mogelijke datumwaarde worden ingevuld. Test uit: moet een foutmelding geven moet een foutmelding geven (de vijftiende maand...) moet een foutmelding geven moet geaccepteerd worden 5 Bij een ingevoerd niet-bestaand klantnummer, moet een foutboodschap worden gegenereerd. 6 Bij een ingevoerd wél-bestaand klantnummer, moet de bijbehorende klantnaam (correct) worden getoond. Het mag niet mogelijk zijn om deze klantnaam in dit scherm te wijzigen (het moet dus een 'read only'-veld zijn). 7 N.B. wij hebben het daar niet over gehad, maar bij een wat uitgebreider systeem zou hier zeker staan, dat alleen een wél-bestaand artikelnummer geaccepteerd mag worden 8 Het factuurbedrag moet een positief getal zijn. Test uit: moet een foutmelding geven moet een foutmelding geven DO-bijlagen B blz.10

11 - 3A moet niet mogelijk zijn en een 'beep'-foutmelding geven moet geaccepteerd worden 9 Na het opslaan (via <Bewaren>) van correcte factuurgegevens, moeten deze gegevens in de factuur-gegevenstabel terug te vinden zijn. II) de verwijderfunctie: verwijder klant Stel weer, dat we bij activiteit 3.9 voor deze basisfunctie de volgende user interface hebben vastgelegd: Klant verwijderen Klantnummer: Klantnaam: Straatnaam: Postcode: Huisnummer: Woonplaats: Verwijder Afbreken 10 Bij een ingevoerd wél-bestaand klantnummer, moet de bijbehorende klantgegevens (correct) worden getoond. Het mag niet mogelijk zijn om deze gegevens in dit scherm te wijzigen (het moeten dus 'read only'-velden zijn). 11 Bij een ingevoerd niet-bestaand klantnummer, moet een foutboodschap worden gegenereerd. 12 Je mag een klant alleen kunnen verwijderen als er geen facturen van aanwezig zijn. Test uit: - verwijder klant zonder factuur: moet kunnen - verwijder klant mét factuur: moet foutmelding genereren etcetera. Om te voorkomen dat de toekomstige database vervuild zal raken (dat er gegevens in zitten die er niet in zouden mogen zitten!) is afdwingen van beperkingsregels die te maken hebben met het handhaven van de integriteit van de database het allerbelangrijkste. Dit kan zich voordoen bij toevoeg-, muteer- en verwijder-opdrachten. B.2) Testgevallen voor de werking van basisfuncties Los van een controle op de beperkingsregels moeten de basisfuncties gewoon doen wat er van ze verlangd wordt. Toevoegfunctie Als ik met een basisfunctie bijvoorbeeld gegevens verwijder van een bepaalde relatie dan moeten al deze gegevens na uitvoering van de basisfunctie ook verwijderd zijn. Voorbeeld: 14 Als ik alle gegevens van een persoon verwijder dan mag die persoon daarna in geen enkele relatie in een tabel meer voorkomen. Informatiefunctie Als ik een overzicht vraag van een relatie dan moet dat overzicht ook gegeven worden (in de gewenste volgorde). Zo'n soort functie test je ook op randgevallen. Voorbeeld: 15 Gaat het goed als ik een overzicht opvraag van een lege tabel? 16 Gaat het goed als ik een overzicht opvraag van een tabel en dat overzicht past niet op het beeldscherm? DO-bijlagen B blz.11

12 C) Testgevallen voor de systeemtest Voorbeelden van testgevallen die betrekking hebben op het zakboekinformatiesysteem als geheel (deze worden dus getest in de systeemtest): Voorbeelden : 1 Als ik een persoon en het adres van die persoon toevoeg en ik maak een afspraak met die persoon, dan moet dit daarna zichtbaar zijn in het resultaat van de basisfunctie die de relatie tussen afspraken en adressen betreft. 2 Als ik met een persoon een afspraak maak op een datum, en een persoon met de verjaardag op diezelfde datum toevoeg, dan moet dat daarna zichtbaar zijn in het resultaat van de basisfunctie die de relatie tussen afspraken en verjaardagen betreft. 3 Als ik een persoon, de verjaardag en het adres van die persoon toevoeg, dan moet dat daarna zichtbaar zijn in het resultaat van de basisfunctie betreffende de relatie tussen adressen en verjaardagen. 4 Als ik van een persoon waarmee ik een afspraak heb gemaakt de adresgegevens aanpas, dan moet dit daarna zichtbaar zijn in het resultaat van de basisfunctie die de relatie tussen afspraken en adressen betreft. Test uit: - adres wijzigen - adres verwijderen 5 Als ik een persoon verwijder, dan moeten er daarna geen gegevens van die persoon meer voorkomen in de overzichten etcetera. Sommige van deze testgevallen zijn straks in de realisatiefase in combinatie te testen: je voert testgeval 2 uit met dezelfde persoon als in testgeval 1, je voert testgeval 3 uit met dezelfde persoon als in testgeval 2,... etc., in de wetenschap dat je daarvoor de benodigde gegevens voor die test al zult hebben toegevoegd en die testen dus op elkaar aansluiten. Deze combinatie is mogelijk, maar je moet het zeker niet voor alle testgevallen doen. Testgevallen worden hierdoor afhankelijk van elkaar, dus minder algemeen, en zijn niet meer in een willekeurige volgorde uit te voeren. Zorg dan ook dat de testgevallen zo algemeen mogelijk zijn en let er op dat ze in een willekeurig volgorde kunnen worden uitgevoerd. Bij een bepaalde volgorde van testen zouden namelijk ongewenste invloeden van de hoofdfuncties op elkaar wel eens niet aan het licht kunnen komen. Ook voor deze ongewenste invloeden worden testgevallen bedacht. Voorbeelden: 7 Als ik van een persoon met wie ik een afspraak heb de verjaardag verwijder, dan moet daarna zichtbaar zijn in het overzicht van afspraakgegevens dat ik nog steeds een afspraak heb met die persoon. 8 Als ik van een persoon met wie ik een afspraak heb de verjaardag verander, dan moet het daarna zichtbaar zijn in het overzicht van afspraakgegevens dat ik nog steeds een afspraak heb met die persoon etcetera. Voor de systeemtest is dit dus een opsomming van testgevallen; de volgorde waarin deze testgevallen zullen worden uitgevoerd en een opsomming van alle bij dit testen te gebruiken testgegevens liggen hier nog niet vast. DO-bijlagen B blz.12