Integratietest

De integratietest is een softwaretest waarbij individuele softwaremodules verbonden worden en als een geheel getest worden. Deze fase komt na de ontwikkeltest met de unittest en voor de systeemtest. Voor de integratietest worden modules gebruikt die door de unittest gekomen zijn. Deze goedgekeurde modules worden aan elkaar gekoppeld en hier worden tests op losgelaten die in het integratie-testplan zijn beschreven. Als op deze manier alle submodules in een geheel zijn getest kunnen ze vervolgens door naar de systeemtest, of de acceptatietest waar weer andere testvormen worden toegepast.

Doel

Het doel van de integratietest is zekerheid te krijgen over de functionaliteit, performantie en betrouwbaarheid die van de submodulen gevraagd wordt. Deze submodules worden getest via hun interfaces waarbij gebruikgemaakt wordt van een blackboxtest. Testscripts worden afgespeeld met allerlei invoer en gekeken wordt of het geheel volgens verwachting reageert. Testcases worden gemaakt waarmee getest wordt of alle componenten binnen het geheel goed samenwerken, bijvoorbeeld bij een remote procedure call. Het geheel wordt opgebouwd uit goedgekeurde bouwstenen.

Soorten

Er zijn verschillende soorten integratietests, namelijk de Big Bang, top-down en bottom-up.

Big Bang

Bij deze aanpak worden alle (of zo veel mogelijk) modules aan elkaar gekoppeld tot een compleet systeem, dat dan in z’n geheel getest wordt. De Big Bang-methode is bijzonder effectief in het besparen van tijd. Voorwaarde is wel dat de testcases met hun bevindingen goed worden bijgehouden.

Bij een bepaald soort Big Bang (Usage Model testing) worden normale (dagelijkse) werkzaamheden van gebruikers nagespeeld. Door op deze manier te testen wordt de testomgeving getest inclusief (impliciet) de individuele componenten. Bij Usage Model testing gaat men er optimistisch van uit dat de individuele componenten weinig problemen opleveren. Het is een afrondende test, die ervan uitgaat dat de ontwikkelaars hun unittests goed hebben uitgevoerd. Het doel is te voorkomen dat de unittests overgedaan moeten worden. De test concentreert zich meer op de interactie van de componenten onderling en met hun omgeving. Het is van belang een realistisch testscenario samen te stellen van de dagelijkse werkzaamheden, dus zich te concentreren op de normale processen en niet meteen op alle uitzonderingen. Hierdoor krijgt men en goede risico-inschatting van het systeem voor de dagelijkse werkzaamheden. Als de bevindingen ook nog eens zijn verwerkt, werkt uiteindelijk de geïntegreerde omgeving goed voor de gebruikersdoelgroep wiens dagelijkse werk als voorbeeld heeft gediend voor de test.

Top-down en bottom-up

Bij bottom-up testen worden de kleinste eenheden het eerst getest en daarna worden deze gebruikt voor het testen van grotere geïntegreerde eenheden. Dit proces wordt herhaald totdat het geheel is getest. In het voorbeeld van een fiets wordt eerst het ventiel getest en de fietsbel, vervolgens de binnenband, de buitenband, de band als geheel en tot slot de fiets als geheel.

Deze aanpak is alleen nuttig als alle of de meeste onderdelen op hetzelfde moment klaar zijn, anders moet er te veel gewacht worden. Met deze methode kan goed in een percentage worden aangegeven en gerapporteerd hoeveel van de software geprogrammeerd, getest en goedgekeurd is.

Bij de Top Down-aanpak wordt begonnen met het hoogste niveau: het hoofdmenu, waarna het van boven naar beneden wordt afgelopen totdat alles met alle zijtakken aan bod gekomen is.

Bij de sandwich-test wordt de top-down-aanpak met de bottom-up-aanpak gecombineerd.

Het belangrijkste voordeel van de bottom-up-aanpak is dat fouten met hun oorzaken eerder gevonden worden, omdat het om kleinere testobjecten gaat. Bij de top-down-aanpak heb je meer overzicht en zie je sneller wat er nog ontbreekt.