Wat is integratietesten? (Voorbeeld)

Wat is integratietesten?

Integratietesten wordt gedefinieerd als een soort testen waarbij softwaremodules logisch worden geïntegreerd en als groep worden getest. Een typisch softwareproject bestaat uit meerdere softwaremodules, gecodeerd door verschillende programmeurs. Het doel van dit testniveau is om defecten in de interactie tussen deze softwaremodules bloot te leggen wanneer ze worden geïntegreerd

Integratietesten richt zich op het controleren van de datacommunicatie tussen deze modules. Daarom wordt het ook wel genoemd als 'HET' (Integratie en testen), 'Stringtesten' en soms 'Draad testen'.

Waarom integratietesten?

Hoewel elke softwaremodule unit-getest wordt, bestaan ​​er nog steeds defecten om verschillende redenen, zoals:

• Een module wordt over het algemeen ontworpen door een individuele softwareontwikkelaar wiens begrip en programmeerlogica kunnen verschillen van die van andere programmeurs. Integratietesten worden noodzakelijk om te verifiëren of de softwaremodules in eenheid werken
• Op het moment dat de module wordt ontwikkeld, is de kans groot dat de eisen van de klant veranderen. Deze nieuwe vereisten worden mogelijk niet per unit getest en daarom worden systeemintegratietesten noodzakelijk.
• Interfaces van de softwaremodules met de database kunnen foutief zijn
• Externe hardware-interfaces, indien aanwezig, kunnen onjuist zijn
• Ontoereikende afhandeling van uitzonderingen kan problemen veroorzaken.

Klik hier als de video niet toegankelijk is

Voorbeeld van een integratietestcase

Integratie Testgeval verschilt van andere testgevallen in die zin richt zich vooral op de interfaces en gegevens-/informatiestroom tussen de modules. Hier moet prioriteit worden gegeven aan de koppelingen integreren in plaats van de unitfuncties die al zijn getest.

Voorbeeldintegratietestcases voor het volgende scenario: De applicatie heeft 3 modules, bijvoorbeeld 'Inlogpagina', 'Mailbox' en 'E-mails verwijderen' en beide zijn logisch geïntegreerd.

Concentreer u hier niet veel op het testen van de inlogpagina, aangezien dit al is gedaan Testen van een eenheid. Maar kijk eens hoe het is gekoppeld aan de Mail Box Pagina.

evenzo Mail Box: Controleer de integratie ervan met Verwijderen Mails-module.

Testcase-ID	Doel van de testcase	Testgeval Description	verwacht resultaat
1	Controleer de interfacekoppeling tussen Login en Maildoosmodule	Voer de inloggegevens in en klik op de knop Inloggen	Te richten aan de Mail Box
2	Controleer de interfaceverbinding tussen de Mailbox en Verwijderen Mails-module	Vanaf MailSelecteer de e-mail in het vak en klik op de knop Verwijderen	De geselecteerde e-mail zou in de map Verwijderd/Prullenbak moeten verschijnen

Soorten integratietesten

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

• Big Bang-aanpak:
• Incrementele aanpak: die verder is onderverdeeld in de volgende
  • Top-down benadering
  • Bottom-up benadering
  • Sandwichaanpak – Combinatie van top-down en bottom-up

Hieronder staan ​​de verschillende strategieën, de manier waarop ze worden uitgevoerd en hun beperkingen en voordelen.

Big Bang-testen

Big Bang-testen is een integratietestaanpak waarbij alle componenten of modules in één keer worden geïntegreerd en vervolgens als een eenheid worden getest. Deze gecombineerde set componenten wordt tijdens het testen als één geheel beschouwd. Als niet alle componenten in de unit zijn voltooid, wordt het integratieproces niet uitgevoerd.

Voordelen:

• Handig voor kleine systemen.

Nadelen:

• Foutlokalisatie is moeilijk.
• Gezien het enorme aantal interfaces dat bij deze aanpak moet worden getest, kunnen sommige te testen interfaces gemakkelijk over het hoofd worden gezien.
• Omdat het integratietesten pas kan beginnen nadat “alle” modules zijn ontworpen, heeft het testteam minder tijd voor uitvoering in de testfase.
• Omdat alle modules tegelijk worden getest, worden kritische modules met een hoog risico niet geïsoleerd en met voorrang getest. Randmodules die zich bezighouden met gebruikersinterfaces zijn ook niet geïsoleerd en op prioriteit getest.

Incrementeel testen

In de Incrementeel testen aanpak wordt getest door het integreren van twee of meer modules die logisch aan elkaar gerelateerd zijn en vervolgens getest op het goed functioneren van de applicatie. Vervolgens worden de andere gerelateerde modules stapsgewijs geïntegreerd en gaat het proces door totdat alle logisch gerelateerde modules met succes zijn geïntegreerd en getest.

De incrementele aanpak wordt op zijn beurt uitgevoerd via twee verschillende methoden:

• Onderkant boven
• Top down

Stubs en stuurprogramma's

Stubs en stuurprogramma's zijn de dummyprogramma's in Integratietesten die worden gebruikt om de software testen activiteit. Deze programma's fungeren als vervanging voor de ontbrekende modellen bij het testen. Ze implementeren niet de volledige programmeerlogica van de softwaremodule, maar simuleren tijdens het testen de datacommunicatie met de oproepende module.

Stomp: Wordt aangeroepen door de module onder Test.

bestuurder: Roept de te testen module op.

Bottom-up integratietesten

Bottom-up integratietesten is een strategie waarbij eerst de modules op een lager niveau worden getest. Deze geteste modules worden vervolgens verder gebruikt om het testen van modules van een hoger niveau te vergemakkelijken. Het proces gaat door totdat alle modules op topniveau zijn getest. Zodra de modules op een lager niveau zijn getest en geïntegreerd, wordt het volgende niveau van modules gevormd.

Schematische weergave:

Voordelen:

• Het lokaliseren van fouten is eenvoudiger.
• Er wordt geen tijd verspild met wachten tot alle modules zijn ontwikkeld, in tegenstelling tot de Big-bang-aanpak

Nadelen:

• Kritieke modules (op het hoogste niveau van de softwarearchitectuur) die de applicatiestroom regelen, worden als laatste getest en kunnen gevoelig zijn voor defecten.
• Een vroeg prototype is niet mogelijk

Top-down integratietesten

Top-down integratietesten is een methode waarbij integratietesten van boven naar beneden plaatsvinden volgens de besturingsstroom van het softwaresysteem. De modules op een hoger niveau worden eerst getest en vervolgens worden de modules op een lager niveau getest en geïntegreerd om de functionaliteit van de software te controleren. Stubs worden gebruikt voor testen als sommige modules niet gereed zijn.

Schematische weergave:

Voordelen:

• Foutlokalisatie is eenvoudiger.
• Mogelijkheid om een ​​vroeg prototype te verkrijgen.
• Kritieke modules worden op prioriteit getest; Grote ontwerpfouten konden als eerste worden opgespoord en verholpen.

Nadelen:

• Heeft veel Stubs nodig.
• Modules op een lager niveau worden onvoldoende getoetst.

Hoe integratietesten uitvoeren?

De integratietestprocedure, ongeacht de softwareteststrategieën (hierboven besproken):

1. Bereid de integratie voor Testplan
2. Ontwerp de testscenario's, cases en scripts.
3. Uitvoeren van de testgevallen gevolgd door het melden van de gebreken.
4. Het volgen en opnieuw testen van de defecten.
5. Stappen 3 en 4 worden herhaald totdat de integratie succesvol is afgerond.

Slips Description van integratietestplannen

Het omvat de volgende kenmerken:

• Methoden/benaderingen van testen (zoals hierboven besproken).
• Scopes en out-of-scopes-items van integratietests.
• Rollen en verantwoordelijkheden.
• Vereisten voor integratietesten.
• Testomgeving.
• Risico- en mitigatieplannen.

Ingangs- en uitgangscriteria voor integratietesten

Entry- en exitcriteria voor de integratietestfase in elk softwareontwikkelingsmodel

Toelatingscriteria:

• Op unit geteste componenten/modules
• Alle bugs met hoge prioriteit zijn opgelost en gesloten
• Alle modules moeten met succes worden voltooid en geïntegreerd.
• Integratietesten Plan, testcase, af te tekenen en gedocumenteerde scenario's.
• Nodig Test omgeving in te stellen voor integratietesten

Exitcriteria:

• Succesvol testen van geïntegreerde applicatie.
• Uitgevoerde testgevallen worden gedocumenteerd
• Alle bugs met hoge prioriteit zijn opgelost en gesloten
• In te dienen technische documenten, gevolgd door release notes.

Best practices/richtlijnen voor integratietesten

• Bepaal eerst de integratie Teststrategie die konden worden overgenomen en later de testgevallen en testgegevens dienovereenkomstig konden voorbereiden.
• Bestudeer de Archiontwerp van de applicatie en identificeer de kritieke modules. Deze moeten op prioriteit worden getest.
• Verkrijg de interfaceontwerpen van de Architechnisch team en maak testcases om alle interfaces in detail te verifiëren. De interface met de database/externe hardware/softwareapplicatie moet in detail worden getest.
• Na de testgevallen zijn het de testgegevens die de cruciale rol spelen.
• Zorg ervoor dat u altijd de proefgegevens voorbereidt voordat u deze uitvoert. Selecteer geen testgegevens tijdens het uitvoeren van de testgevallen.