Wat is integratietesten en waarom doen we het?

Integratietesten definiëren we als een type test waarbij we softwaremodules logisch integreren en testen als een groep.

Een applicatie bestaat meestal uit meerdere softwaremodules. Deze modules worden door verschillende programmeurs gecodeerd. Maar hoe weten we of de modules goed samenwerken? Integratietesten richt zich echter op het controleren van de datacommunicatie tussen deze modules.

Waarom voeren we integratietesten uit?

Tijdens de levenscyclus van een softwareproject zijn er vier momenten waarop we testen. De eerste drie testen voert IT zelf uit en bepalen feitelijk of de software ook testbaar is voor de klant. De meeste fouten zijn al uit de software gehaald voordat een klant aan de Acceptatietest begint. Dit zijn de vier testmomenten:

1. Unittest (soms ook module test genoemd).
2. Integratietest.
3. Systeemtest (ook End to End test genoemd).
4. Acceptatietest.

Hoewel elke softwaremodule een unittest doormaakt, kunnen er nog steeds fouten in zitten:

• Een module is dus in het algemeen geprogrammeerd door een individuele programmeur. Zijn begrip en programmeerlogica kan echter verschillen van de andere programmeurs. Daarom is integratietesten nodig om de softwaremodules samen aan het werk te zien.
• Op het moment dat we de module ontwikkelen kunnen de behoeften van de klant bovendien veranderen. Deze nieuwe requirements hebben mogelijk nog geen unittest doorstaan. Ook daarom is integratietesten noodzakelijk.
• De interfaces van de softwaremodules met de database kunnen onjuist zijn.
• Externe API-interfaces kunnen onjuist zijn.
• En tenslotte kan een ontoereikende afhandeling van uitzonderingen problemen veroorzaken.

Strategieën voor integratietesten

Software Engineering definieert verschillende strategieën om een integratietest uit te voeren, namelijk:

•  Big Bang aanpak.
• Incrementele aanpak. Die is verder onderverdeeld in de volgende:
  • Top-down benadering.
  • Bottom-up benadering.
  • Incrementele aanpak – combinatie van top-down en bottom-up.

Big Bang aanpak:

Alle units en andere componenten integreren gelijktijdig en testen we daarom in een keer.

Voordelen:

• Handig voor kleine systemen.
• We weten tevens zeker dat het geïntegreerde geheel is getest.

Nadelen:

• Het lokaliseren van fouten is echter moeilijk.
• Door het grote aantal interfaces dat we in deze benadering moeten testen, kunnen we ook sommige koppelingen gemakkelijk missen.
• Omdat we pas met integratietesten kunnen beginnen als alle modules gecodeerd zijn, kost het meer moeite om deze test op het juiste moment te plannen.
• Vaak gaat de tijd van het integratietesten af van de acceptatietest.
• Omdat alle modules tegelijk worden getest, worden kritieke modules met een hoog risico niet geïsoleerd en niet extra zwaar getest.
• Randapparaten die met de modules te maken hebben kunnen niet geïsoleerd getest worden.

Incrementele aanpak

In deze benadering testen we door twee of meer modules samen te voegen die logisch gerelateerd zijn. Vervolgens voegen we de andere gerelateerde modules aan de test toe. Zo ontstaat dus een keten die we testen op een juiste werking. Dit proces gaat bovendien door totdat we alle modules hebben samengevoegd en getest.

De incrementele aanpak wordt op zijn beurt uitgevoerd door middel van twee verschillende methoden:

• Bottum up.
• Top down.

Wat is Stub en wat is Driver?

Tijdens de incrementele aanpak gebruiken we dummy-programma’s genaamd Stubs en Drivers. Stubs en Drivers bevatten niet de volledige programmalogica van de softwaremodule maar simuleren slechts de datacommunicatie met de te testen modules.

Stub: Aangeroepen van andere modules door de module die we testen.

Driver: Werk andersom en roept dus de module die we testen op.

Bottom-up integratietest

In de bottom-up-strategie testen we elke module op lagere niveaus met de bovenliggende modules totdat we alle modules hebben getest. Daarom hebben we hulp van drivers nodig voor deze testen.

Voordelen:

• Het lokaliseren van fouten is eenvoudiger.
• We verspillen geen tijd met wachten tot dat alle modules zijn gecodeerd.

Nadelen:

• Kritieke modules (op het hoogste niveau van de software-architectuur) die de flow van de applicatie regelen, testen we als laatste en kunnen gevoelig zijn voor defecten.
• Een vroeg prototype is niet mogelijk.

Top-down integratietest

Bij Top-Down-benadering vindt het testen van boven naar beneden plaats, afhankelijk van de flow van de applicatie.

Maakt gebruik van stubs om te kunnen testen.

Voordelen:

• Het lokaliseren van fouten is eenvoudiger.
• Het is tevens mogelijkheid om een ​​vroeg prototype te verkrijgen.
• Kritieke modules testen we met prioriteit; ontwerpfouten vinden we dus eerder en kunnen we oplossen voor we tijd verdoen aan het testen van andere modules.

Nadelen:

• We zijn veel stubs nodig.
• Modules op een lager niveau testen we onvoldoende.

De Hybride integratietest

De hybride strategie is een combinatie van de Top down en de Bottom up benaderingen. We testen de topmodules en de lagere modules tegelijkertijd en geïntegreerd. Bij deze strategie maken we van zowel stubs als drivers gebruik.

Hoe voeren we integratietesten uit?

Ongeacht de software teststrategieën ziet het testproces er als volgt uit:

1. Maken van het integratietestplan.
2. Ontwerp de testscenario’s, testcases en testscripts.
3. Het uitvoeren van de testgevallen.
4. Feedback geven door het melden van de gevonden defecten.
5. Het opnieuw testen van de herstelde defecten.
6. Stappen 3, 4 en 5 herhalen totdat de integratie volledig is vastgesteld.

Opzet van het integratietestplan

Het plan bevat de volgende onderdelen:

• De gekozen teststrategie en aanpak (zoals hierboven besproken).
• De scope integratietests: Welke naastliggende systemen testen we eveneens mee?
• Rollen en verantwoordelijkheden van de testers.
• Requirements voor de integratietesten.
• Testomgeving met betrekking tot plek in OTAP.
• Risico’s en maatregelen.

Criteria voor het integratietesten

Start- en stopcriteria voor integratietesten in ieder softwareontwikkelingsmodel.

Startcriteria:

• Componenten / modules hebben een unittest ondergaan.
• Al de defecten met een hoge prioriteit zijn opgelost en afgesloten.
• Al de modules zijn af en kunnen worden geïntegreerd.
• Integratietestplan, testscenario’s en testcases zijn bovendien gereed en gevalideerd.
• De testomgeving is tevens klaar voor de integratietesten.

Stopcriteria:

• De geïntegreerde applicatie is succesvol getest.
• Alle uitgevoerde testgevallen zijn gedocumenteerd.
• Alle defecten met een hoge prioriteit zijn opgelost en afgesloten.
• De technische documentatie is opgeleverd, inclusief de release-opmerkingen.

Best Practices en richtlijnen voor integratietesten

• Bepaal eerst de teststrategie voor je begint met het maken van de testdata, testscenario’s en testcases.
• Identificeer de kritieke modules. Deze moeten we als eerste testen.
• Verkrijg de functioneel-ontwerp en maak tevens testcases voor alle interfaces naar schermen, de database, randapparatuur, applicaties en API’s.
• Naast de testcases speelt de testdata een cruciale rol. Bereid dit goed voor.

Zorg er dus voor dat de testdata altijd is voorbereid. Maak daarom geen testdata tijdens het uitvoeren van de testcases.

Discussieer mee op LinkedIn.