H7 - Integratiefase Flashcards
Beknopt uitleggen wat testen is en wat het zeker niet is?
Testen is niet: “Aantonen dat het product correct werkt.” Dat kan geen enkele test aantonen, want er zijn veel te veel testgevallen.
Eén goed gekozen negatieve test kan echter wel een fout in het programma aantonen.
Testen is dus eigenlijk: “Fouten in het product vinden.”
Verschil tussen verification en validation uitleggen
Verificatie: Controleren of de gebouwde applicatie correct functioneert en voldoet aan alle specificaties en vereisten die in de definitiestudie werden vastgesteld.
Validation: Testen of de in de definitiestudie geformuleerde vereisten inderdaad overeenkomen met de verwachtingen van de gebruiker
Het belang van testen uitleggen.
Testen is belangrijk want:
- Testen verhoogt de kwaliteit van het product, omdat gevonden fouten zullen hersteld worden.
- Testen verhoogt vertrouwen van de klant in het product
- > Wanneer de klant weet welke onderdelen grondig getest worden en op welke manier dat gebeurt, zal zijn vertrouwen in het product groeien.
Een goed testproces kan processen en schadeclaims vermijden en potentiële hoge kosten uitsluiten.
Gevaar van slecht of te weinig testen beknopt uitleggen.
Weinig testen:
Uiteindelijke product zal in het begin waarschijnlijk heel veel onderhoud nodig hebben, omdat veel fouten die anders door testen gevonden zouden worden nu pas bij het gebruik opduiken.
Te veel testen:
Goede testers zullen altijd fouten blijven vinden, in dat geval kan teveel testen slecht zijn omdat we de kosten t.o.v. de baten moeten afwegen.
V-model tekenen.
*
Elk niveau in V-model kunnen uitleggen, met de relaties naar het hogerliggende en lagerliggende niveau.
Er bestaat geen aparte testfase: In alle fasen van de ontwikkeling wordt er op de een of andere manier getest.
- Men spreekt in dit verband over verschillende testniveau’s of V-model
- Met iedere fase komt een testniveau overeen die de resultaten van die fase test
Het V model toont ook wanneer elke test gepland wordt.
- Het precies plannen van een test kan aantonen dat er onduidelijkheden of onvolledigheden in een ontwerp/specificatie zijn.
o Een acceptatiefase kan je plannen en ontwerpen van zodra de analyse afgelopen is.
o Een systeemtest wordt gepland en uitgewerkt van zodra het architectuurontwerp afgelopen is, enz.
De verschillende testfases:
- Unit/moduletesten:
o De units (programma-eenheden) en modules (klassen, abstract datatype, pakket van procedures en functies, …) worden getest.
- Integratietesten:
o Wanneer alle individuele modules getest zijn. Moet getest worden of modules die samen een subsysteem vormen, in combinatie goed functioneren. - Systeemtesten:
o Laatste test die door systeembouwers wordt uitgevoerd.
Alle subsystemen worden samengevoegd om te komen tot één systeem. Dit systeem wordt nu grondig getest. - Acceptatietesten:
o Er wordt getest of het systeem voldoet aan de vereisten uit de analysefase.
Verschil tussen top-down-testing, bottom-up-testing en sandwich integration uitleggen
Term stub uitleggen en verband leggen met top-down-testing.
Top-down testing:
Men begint bij het geheel, en gaat dan stap voor stap de deelmodules testen
Er kan snel mee begonnen worden, nog voor de deelmodules ontwikkeld zijn.
Voor ontbrekende modules kunnen we gebruik maken van:
o Stubs: nepmodules die een vaste waarde retourneren
o Mocks: nepmodules die in staat zijn te controleren of ze correct gebruikt worden
o Fakes: nepmodules die alle of bijna alle functionaliteit hebben van de module die ze vervangen
Bottom-up testing:
Eerst worden de onderdelen getest, en die worden dan samengevoegd tot grotere gehelen die dan ook weer getest worden, tot het uiteindelijk systeem als geheel getest wordt.
Alle programmamodules moeten ontwikkeld zijn vooraleer deze test uitgevoerd kan worden.
Sandwich integration: Een bottom-upaanpak gecombineerd met een top-downaanpak.
Verschil tussen op uitvoering gebaseerde testen en niet op uitvoering gebaseerde testen uitleggen en een voorbeeld geven van elk type.
Op uitvoering gebaseerde testen: Testen door de programmamodule te compileren en effectief te runnen.
Niet op uitvoering gebaseerde testen:
Testen waarbij de code niet wordt uitgevoerd, maar grondig wordt onderzocht. (statisch testen)
Bv. Formele, wiskundige correctheidsbewijzen of formele inspecties/walkthroughs
Begrippen stresstest, regressietest (back-to-back-test) en bètatest uitleggen
Stresstest:
De bedoeling is om te testen onder een hogere werklast om uiteindelijk na te gaan of het systeem blokkeert of we een fail-soft situatie vaststellen?
(fail-soft = systeem functioneert, maar bv. onder verminderde snelheid)
Regressietest:
Kan uitgevoerd worden wanneer er al een bestaand systeem is.
Hier zal men dezelfde gegevens aanbieden aan beide systemen en nagaan of beide systemen inderdaad dezelfde output genereren. (= ook zelfde input)
Bètatesten:
Men stelt het product ter beschikking van een aantal potentiële gebruikers
Verschil tussen systeemtest en acceptatietest goed kunnen uitleggen.
Systeemtest:
- Wordt uitgevoerd door het projectteam.
- Na dat het projectteam zelf de overtuiging heeft gekregen dat het systeem correct functioneert vindt de acceptatietest plaats.
Acceptatietest:
- Gebeurt door de opdrachtgever, hij moet nu beslissen of de product klaar is, en of het aanvaard kan worden.
- Gebeurt in de technische en organisatorische omstandigheden waarin het product werkelijk gebruikt zal worden.
