Bijlage R-a) Het maken van de testomgeving en het uitvoeren van het testproces

Transcriptie

1 Bijlage R-a) Het maken van de testomgeving en het uitvoeren van het testproces Inleiding 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 is opgesteld. 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. Dat testplan wordt in activiteit 4.4 Programmeer en test door de programmeurs van de betreffende (basis-) functies uitgevoerd. Het vooraf (door de ontwerpers tijdens de Detailontwerpfase) 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. Uitvoeren van het testplan - Testen Zo gauw basisfuncties als programma(deel) beschikbaar zijn in activiteit 4.4 Programmeer en test worden deze door de programmeur getest volgens het testplan (testscenario). Als je een functie samenstelt uit basisfuncties waar fouten inzitten, dan kun je er gerust van uitgaan dat het vinden van die fouten veel meer tijd en moeite kost dan wanneer je de betreffende basisfuncties apart had gedebugged. Als je functies uit onderdelen samenstelt, zorg dan dat die onderdelen getest zijn en naar behoren functioneren. De [uiteindelijke] testbevindingen worden vastgelegd en vormen het testrapport. N.B. Als in het testplan toentertijd ruimte gereserveerd is om ook de bevindingen bij het testen in te noteren, dan staat alles bij elkaar en heb je meteen een testrapport. Na tenslotte de systeemtest te hebben gedaan en eventuele veranderingen te hebben aangebracht vindt als laatste de acceptatietest plaats: de opdrachtgever accepteert het ontwikkelde informatiesysteem (of niet). Het testproces De ontwikkelaars van het informatiesysteem voeren in de fase Realisatie in activiteit 4.7 de systeemtest uit. In deze test wordt het complete informatiesysteem getest. De onderdelen zijn al wel eerder in de testketen afzonderlijk getest, maar nu bij de systeemtest ligt vooral de nadruk op het testen of de onderdelen ook in hun onderlinge samenhang van het grotere geheel goed functioneren. Omdat er besloten is om Bottom-Up te testen is deze 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 er 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. In het onderdeel van het testscenario over het testen van de basisfuncties komen de testgevallen voor de menu's, de testgevallen voor de beperkingsregels en de testgevallen voor de correcte (ver)werking te staan met daarbij de NIII School voor Informatica R.1 KU-Nijmegen

2 volgorde waarin deze uitgevoerd worden. Het testproces in deze fase is het eerste in de testketen en is in die zin bepalend voor het verdere verloop van het testen. Zolang niet alle testgevallen voor de basisfuncties met een positief resultaat zijn afgesloten kun je niet verder gaan met de overige testprocessen. Aangezien alles wat hierna getest gaat worden, opgebouwd is uit de hier geteste basisfuncties, is het duidelijk dat dit testen van de basisfuncties erg belangrijk is en dat je hier veel aandacht aan moet besteden: een goed begin is het halve werk. Nog niet genoemd in het voorgaande verhaal is het testen van procedures (die je op meerdere plaatsen in je programma kunt gebruiken en daarom vaak algemeen geschreven zijn). Omdat ze vaak zo algemeen geschreven zijn kan het voorkomen, dat ze in eerste instantie bij bepaalde aanroepen correct functioneren, maar dat ze later bij aanroepen in andere situaties toch fout blijken te zijn en verbeterd moeten worden. Vergeet na zo' n correctie niet opnieuw te testen of ze in de eerdere situaties (waar ze in hun oude vorm correct leken te functioneren) nog steeds doen wat van hen verlangd wordt. Zij-effecten Nadat alle basisfuncties en procedures afzonderlijk getest (en goed bevonden) zijn kun je testen of deze onderdelen ook in onderlinge samenhang goed functioneren. Het zou bijvoorbeeld kunnen zijn dat een procedure onbedoelde ' zij -effecten' heeft. Veel voorkomende onbedoelde zij-effecten zijn: - in een procedure wordt de waarde van een globale variabele per ongeluk veranderd (wanneer je in al je programma' s de variabele ' mkeuze' gebruikt, dan zou er wel eens iets onbedoeld fout kunnen gaan). De aangewezen oplossing hiervoor is het lokaal declareren van alle variabelen die alleen in de procedure gebruikt worden. - in een procedure wordt met SELECT een werkgebied geselecteerd maar wordt verzuimd aan het einde van de procedure weer terug te keren naar het originele werkgebied. De oplossing is uiteraard om na afloop wel terug te keren naar het originele werkgebied. - in een procedure wordt de recordwijzer verplaatst zonder dat het programma dat de procedure aanroept daar weet van heeft. Het is over het algemeen ondoenlijk (of zelfs onmogelijk) om alle procedures en programmadelen in samenhang te testen. Wanneer je echter in ieder geval op de bovenstaande ongewenste zij-effecten let, dan ben je al een heel eind. Je kunt trouwens met testen alleen maar aantonen dat er fouten in een programma zitten, je kunt met testen nooit aantonen dat er geen fouten in het programma zitten! Na het testen van procedures en programmadelen in samenhang, kun je de functies op het laagste niveau stuk voor stuk testen, daarna in samenhang met andere functies op het laagste niveau en zo verder, tot je het gehele programma getest hebt. Zoals je ziet gaat dit testen helemaal bottom-up. Al het bottom-up testen bij elkaar heet de ' systeemtest'. Het top-down gedeelte van het testen gebeurt in de ' acceptatietest'. Degene die de acceptatietest doet (meestal de toekomstige gebruiker) zal eerst wat globale tests uitvoeren (kan ik door de menuboom wandelen, kan ik een persoon toevoegen, kan ik die persoon later weer terugvinden, zijn de foutmeldingen begrijpelijk) om daarna steeds specifieker te gaan testen (kan ik alle functies bereiken door door de menuboom te wandelen, wat gebeurt er als ik iets verkeerds intyp, welke foutmeldingen kan ik krijgen, worden fouten goed afgewerkt, kan ik een persoon toevoegen die er al in zit). Voor het project-informatiesysteem hoeven jullie niet zelf een acceptatietest te maken; de cursusleiding zal dit voor elke groep doen. Deze acceptatietest is dan meteen de afsluiting van het B3-project. Voordat de acceptatietest van het project-informatiesysteem kan worden gedaan, moet de systeemtest dan al (met goed gevolg!) afgelegd zijn. Hiermee moet je rekening houden met je tijdsplanning. Naast het testen van je procedures met randgevallen moet je ook testen met ' normale gevallen' Daarvoor. kan je het beste ' echte' gegevens gebruiken, voor het zakboekinformatiesysteem bijvoorbeeld echte namen, adressen en telefoonnummers. Dan zie je meteen of de gekozen veldlengtes voor ' echte' gegevens voldoende zijn. Het maken van een testomgeving Wanneer je een procedure of een stukje programma aan het testen bent en je komt een fout tegen, dan moet je na het verbeteren van die fout weer (helemaal) overnieuw beginnen met testen. Het gebeurt namelijk vaak dat zo' n ' verbetering' weer nieuwe foute n introduceert. Om te voorkomen dat je alle testen weer opnieuw in moet typen, NIII School voor Informatica R.2 KU-Nijmegen

3 is het verstandig om (indien het gebruikte DBMS dat toestaat) ' testprogramma' s' te maken. Hierin zet je dan precies die xbase-commando' s die je anders steeds opnieuw in zou typen. Als voorbeeld dient een ' minizakboek-systeem' dat de gebruiker de mogelijkheid biedt namen, adressen en telefoonnummers van relaties bij te houden. De functies van het minizakboek zijn: toevoegen, verwijderen en tonen van de gegevens van een bepaalde persoon. Een persoon wordt in het minizakboek geïdentificeerd door een naam (combinatie van voornaam en achternaam). De structuur van de gebruikte xbase-tabel Adressen.dbf is als volgt: Naam Teken 20 Adres Teken 40 Telefoon Teken 12 Merk op dat in dit geval for the sake of simplicity geen onderscheid is gemaakt tussen voornaam en achternaam, straat en huisnummer en woonplaats, netnummer en abonneenummer. In ons ' minizakboek-systeem' /programma maken we gebruik van allerlei(zelfgemaakt) gereedschap: de procedures in de gereedschapskist. Bij het testen controleren we eerst deze procedures. Pas wanneer afdoende is getest of deze procedures goed functioneren heeft het zin om functies te testen die gebruik maken van deze procedures. De voornoemde procedures (toon, voegtoe, verwijder) zijn hier niet uitgewerkt. Van de procedure ' toon' weten we, dat hij de gegevens moet tonen van alle personen uit de tabel ' adressen' waarvan de opgeslagen naam gelijk is aan de als parameterwaarde meegegeven naam. Daarvoor moet in de procedure de hele tabel doorlopen worden. N.B. Voor het testen van de procedure 'toon' zou zo' n testprogramma er in xbase-taal als volgt uit kunnen zien: * testtoon.prg * maak het adressenbestand leeg USE adressen ZAP && ZAP: maakt een gegevenstabel helemaal leeg * test procedure met leeg bestand? " 'toon' met een leeg bestand" DO toon WITH "Ruud Wiersma" * voeg een drietal personen toe APPEND BLANK REPLACE naam WITH "Annet Aalbers", adres WITH ; "Eikenlaan 10, NIJMEGEN", telefoon WITH " " APPEND BLANK REPLACE naam WITH "Frans de Boer", adres WITH ; "Bredeweg 5a, GROESBEEK", telefoon WITH " " APPEND BLANK REPLACE naam WITH "Joke Wiersma", adres WITH ; "Parkweg 155, ARNHEM", telefoon WITH " " * test procedure met naam die niet voorkomt in tabel? " 'toon' met onbekende naam" DO toon WITH "Ruud Wiersma" * test procedure met randgeval eerste in tabel? " 'toon' met randgeval eerste in tabel" DO toon WITH "Annet Aalbers" * test procedure met randgeval laatste in tabel? " 'toon' met randgeval laatste in tabel " DO toon WITH "Joke Wiersma" * test procedure met normaal geval? " 'toon' met 'normaal' geval" DO toon WITH "Frans de Boer"? "EINDE TEST van procedure 'toon' RETURN Voor procedures ' voegtoe' en ' verwijder' kun je analoog een testprogrammaatje maken. De van toepassing zijnde beperkingsregels geven je echter ook aanwijzingen over gevallen die je moet testen. Bij het toevoegen heb je bijvoorbeeld te maken met een extra randgeval: een persoon toevoegen waarvan de naam al voorkomt in het Minizakboek is immers niet toegestaan. Omdat testen in het algemeen zo arbeidsintensief is (tot ca. 50% van alle ontwikkeltijd), wordt in de praktijk geprobeerd om zoveel mogelijk test-onderdelen te automatiseren (al dan niet met gebruik van speciaal daarvoor ontwikkelde test-tools). NIII School voor Informatica R.3 KU-Nijmegen

4 Bijlage R-b) Rapport Realisatie Factureringsafdeling (uittreksel) Deeluitwerking van activiteit 4.3: Bepaal (interne) programmastructuur 0) Woord vooraf Op speciaal verzoek van de opdrachtgever is op het laatste moment besloten een de implementatie in FoxPro uit te voeren. Omdat bij analyse van het bestaande systeemontwerp bleek, dat deze verandering zonder al te veel problemen (/extra werk) kon worden uitgevoerd, zal de implementatie inderdaad in FoxPro worden uitgevoerd. Ook is bij de bespreking van het Detailontwerp gebleken, dat het inderdaad efficiënter is om géén aparte adresgegevenstabel te gebruiken, maar om de gegevens uit de adrestabel te combineren met die van de klanttabel. 1) Hoofdprogramma In het te gebruiken aansturende hoofdprogramma admini.prg worden een aantal systeem variabelen (zoals BELL, TALK, etc.. ) gezet worden; ook wordt het hoofdmenu (factmenu.mpr) aangeroepen. Na de hoofdmenu-optie ' Einde' worden, de systeem variabelen weer terug gezet worden op hun oorspronkelijke waarde. Het hoofdprogramma is dan opgezet volgens het onderstaande sjabloon: SET TALK OFF SET PROCEDURE TO ADMIPROC.PRG SET STATUS OFF SET BELL OFF * roep het hoofdmenu aan: DO factmenu.mpr CLOSE PROCEDURE SET TALK ON SET BELL ON SET STATUS ON 2) Procedures/Functions in het procedure-bestand ( module ) admiproc.prg: 2.a) FUNCTION uniekvolg && voor het genereren van een opklimmende unieke, numerieke waarde && met gebruikmaking van macro-substitutie en een name expression PARAMETERS mbestandstr, mkolomstr PRIVATE mrij DIMENSION mrij(1) SELECT MAX(&mkolomstr) ; FROM ( mbestandstr ) ; INTO ARRAY mrij && alternatief: &mbestandstr i.p.v. (mbestandstr) RETURN ( mrij(1) + 1 ) && 1 groter dan MAX(...). 2.b) FUNCTION aantalkeer && levert het aantal keren dat een waarde in een kolom- && veld van een bestand voorkomt PARAMETERS mwaarde, mkolomstr, mbestandstr etc. 2.c) FUNCTION komtvoorin && bepaalt of een waarde al dan niet al voor komt in een && kolom-veld van een bestand PARAMETERS mwaarde, mkolomstr, mbestandstr etc. NIII School voor Informatica R.4 KU-Nijmegen

5 3) In acht te nemen beperkingsregels bij de diverse (basis)functies Let op: het gaat ons hier vooral om ten behoeve van een correcte interpretatie door de programmeurs heel duidelijk de beperkingsregels aan te geven zoals die gelden tussen de tabellen. Zo zal bij het toevoegen van een factuur (aan de facturen-tabel) het ingevoerde klantnummer al in de klanten-tabel moeten vóórkomen en mag een klant niet uit de klanten-tabel verwijderd worden als zijn/haar klantnummer nog in de facturen-tabel staat! Beperkingsregels zoals die gelden binnen een bepaalde tabel (zoals vorm en wel/niet verplicht zijn van een bepaalde waarde) staan meestal al zeer goed vermeld bij enerzijds de in het Detailontwerp bepaalde gewenste functionaliteit van een scherm en anderzijds het voor dat onderdeel gemaakte testplan. Maar: het hier (nog eens) opnemen van deze tweede categorie beperkingsregels màg uiteraard wel... Ook het hier door de ontwerpers opnemen van complexe SQL-queries (de ontwerpers zijn hier vaak beter in geschoold en hebben nogmaals een beter inzicht in de relaties tussen de gegevenstabellen) is hier zeker aan te bevelen. 3.a) klant toevoegen: klnttoev.prg - het unieke klantnummer wordt automatisch ' opklimmend' gegeneree rd en als uitvoerveld gepresenteerd (is alleen uitvoerveld) - in alle invoervelden moet een geldige waarde worden ingevuld (verplichte rollen) waarbij hoort, dat de postcode moet bestaan uit 4 cijfers + 1 spatie + 2 hoofdletters 3.b) klant muteren: klntmut.prg - het unieke klantnummer mag niet kunnen worden gewijzigd (is alleen uitvoerveld) - in alle invoervelden moet een geldige waarde worden ingevuld (verplichte rollen) waarbij hoort, dat de postcode moet bestaan uit 4 cijfers + 1 spatie + 2 hoofdletters 3.c) klant verwijderen: klntverw.prg - Een klant mag niet verwijderd worden als er een factuur van hem/haar bestaat (!). N.B. Een probleem hierbij is, dat ons NIAM-schema beperkt is tot deze factureringsafdeling. Indien ook de afdeling ' betalingen' bij de informatieanalyse betrokken was geweest, dan zou hier ongetwijfeld uitgekomen zijn, dat een klant niet verwijderd zou mogen worden als er nog onbetaalde rekeningen open staan. 3.d) factuur toevoegen: facttoev.prg - het unieke factuurnummer wordt automatisch ' opklimmend' gegenereerd - in alle invoervelden moet een geldige waarde worden ingevuld (verplichte rollen) hierbij hoort, dat het factuurbedrag positief moet zijn! - het ingevoerde klantnummer moet voorkomen in de klant-gegevenstabel (!) N.B. bij een ' meeromvattend' IS zou hier ongetwijfeld bij gehoord hebben: - het ingevoerde artikelnummer moet voorkomen in een artikel-gegevenstabel (!) 3.e) adres tonen van klant met factuur - bij een informatiefunctie hoeven géén beperkingsregels te worden afgedwongen - SQL-query: SELECT * FROM klant ; WHERE klantnummer = ( SELECT klantnummer ; FROM factuur ; WHERE factuurnummer = < ingetikte waarde>); INTO ARRAY... 3.f) etc., etc.... (van alle basisfuncties moeten de af te dwingen beperkingsregels worden aangegeven) NIII School voor Informatica R.5 KU-Nijmegen

6 Bijlage R-c) De systeemdocumentatie (Naar aanleiding van activiteit 4.8 : Voltooi documentatie) Inleiding Wij zullen in ons project deze activiteit benutten om de gebruikershandleiding te maken voor het ontwikkelde systeem. Deze handleiding speelt een cruciale rol in de opleiding van de gebruikers en dient na deze opleiding als naslagwerk voor de gebruikers bij vragen over de functies of het gedrag van het informatiesysteem. Tijdens het ontwikkelen van het informatiesysteem ontstaat allerlei documentatie: - de mijlpaalproducten die door de ontwikkelaars bij hun activiteiten gebruikt worden, - de rapporten die de opdrachtgever/gebruiker inzicht geven in wat er ontwikkeld wordt. Om er voor te zorgen dat straks de gebruikers goed met het ontwikkelde informatiesysteem overweg kunnen, is er echter nog een derde soort documentatie nodig: de gebruikershandleidingen. De gebruikershandleidingen moeten op voor de gebruiker begrijpelijke wijze beschrijven welke functies het informatiesysteem kan vervullen, welk gedrag het informatiesysteem zal vertonen naar de gebruiker toe (gebruikersinterface) en hoe je als gebruiker te werk moet gaan, zowel in het geval dat alles goed gaat als in het geval van problemen. Ook de aanwijzingen voor systeembeheer (maken van back up' se.d.) plaatsen we hierbij. Indeling van de gebruikershandleiding Veel voorwerk voor de te maken gebruikershandleidingen wordt gedaan in de fasen definitiestudie, basisontwerp en detailontwerp. De daar vervaardigde producten moeten - mogelijk met enige aanpassing - in het raamwerk van de gebruikershandleiding worden opgenomen. Tijdens de realisatiefase wordt de gebruikershandleiding gecompleteerd. Het raamwerk van de gebruikershandleiding is eigenlijk al ontstaan tijdens het ontwerp. Immers, het ligt erg voor de hand om de gebruikershandleiding een indeling te geven die nauw aansluit bij het systeemconcept dat in de fase definitiestudie is opgesteld en in het basisontwerp nader is uitgewerkt. Zo gauw je de menustructuur hebt vastgelegd en een menuboom hebt gevonden heb je de indeling (inhoudsopgave) van de gebruikershandleiding eigenlijk klaar. Deze indeling loopt grotendeels via de lijnen van het systeemconcept waarin mogelijk wat verschuivingen zijn aangebracht. De hoofdindeling wordt dan iets als volgt: Inhoudsopgave, Opstarten van het informatiesysteem, daarna een indeling conform systeemconcept (zie de opmerking hierboven) Afsluiten van het informatiesysteem, Gebruik en onderhoud, Bijlagen. overzicht functies. overzicht foutmeldingen en hun bronnen. overzicht van de gebruikte gegevenstabellen en indexen Over wat er over gebruik en onderhoud opgeschreven moet worden kun je het een en ander vinden in de beschrijving van de SDM-fase 6: Gebruik en Beheer. Invulling van de gebruikershandleiding De gebruikershandleiding geeft een functionele beschrijving van het informatiesysteem (de handleiding beschrijft de functies van het systeem) en geen technische beschrijving. NIII School voor Informatica R.6 KU-Nijmegen

7 Bij de invulling van de gebruikershandleiding kun je het beste een Top-Down-aanpak kiezen. Begin steeds met globaal een hoofdfunctie, deelfunctie of basisfunctie te omschrijven en voeg daarna naar behoefte details toe. Bij de beschrijving van de functies moet je in de gaten blijven houden dat je de beschrijving voor de gebruiker maakt. Sluit nauw aan bij haar/zijn belevingswereld. Dit kan gebeuren door gebruik te maken van de begrippen uit het conceptueel model en door gebruik te maken van ervaringen die de gebruiker met het informatiesysteem opdoet (die grotendeels bepaald worden door de interactie die de gebruiker met het informatiesysteem heeft). Als je dus een gedetailleerdere beschrijving van een functie geeft doe dat dan in termen van objecten uit het conceptueel model en met gebruikmaking van schermbeelden die in de interactie met de gebruiker een rol spelen. Soms kun je misschien (bij een ingewikkelde functie) met vrucht een hiërarchische opsplitsing in kleinere blokken gebruiken om de details van de werking te beschrijven. Uit het voorgaande kun je wel opmaken dat het materiaal voor de gebruikerhandleiding reeds grotendeels voorhanden is in het functioneel ontwerp van het informatiesysteem (afgezien van de details die in de realisatiefase nog boven water komen). Het gaat er voornamelijk om dit materiaal te ordenen in een voor de gebruiker handzame vorm en zo aan te passen dat de beschrijvingen van de functies de gebruiker niet doen verzuipen in de details terwijl toch de werking van het informatiesysteem adequaat beschreven wordt. Wanneer je bij het maken van de mijlpaalproducten in de verschillende SDM-fasen gebruik hebt gemaakt van een tekstverwerker heb je het helemaal gemakkelijk bij het maken van de gebruikershandleiding: je kunt naar behoefte uit eerder vervaardigd materiaal putten en dit ook nog gemakkelijk aanpassen. Bedenk je wel dat de realisatie-fase nog wel eens aanleiding wil geven tot veranderingen. NIII School voor Informatica R.7 KU-Nijmegen