Menu

Wat is integratietests (zelfstudie met voorbeeld van integratietests)

  • Hoofd
  • Testmethoden
  • Wat is integratietests (zelfstudie met voorbeeld van integratietests)

what is integration testing

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Wat is integratietests: leer met voorbeelden van integratietests

Integratietests worden gedaan om de modules / componenten te testen wanneer ze zijn geïntegreerd om te controleren of ze werken zoals verwacht, d.w.z. om de modules te testen die goed werken, levert dit geen problemen op bij integratie.

Wanneer we het hebben over het testen van grote applicaties met behulp van de black box-testtechniek, gaat het om de combinatie van vele modules die nauw met elkaar zijn gekoppeld. We kunnen de concepten van de integratietesttechniek toepassen om dit soort scenario's te testen.

Lijst met tutorials die in deze serie worden behandeld:

Tutorial # 1: Wat is integratietesten? (Deze tutorial)
Tutorial # 2: Wat is incrementeel testen
Tutorial # 3: Wat is componenttesten
Tutorial # 4: Continue integratie
Zelfstudie # 5 Verschil tussen unit-testen en integratie
Tutorial # 6: Top 10 integratietesttools

wat is integratietesten

Wat je leert:

Wat is integratietesten?

De betekenis van integratietesten is vrij eenvoudig: Integreer / combineer de unit-geteste module een voor een en test het gedrag als een gecombineerde unit.

De belangrijkste functie of het doel van deze test is het testen van de interfaces tussen de units / modules.

Normaal gesproken doen we integratietests na 'Unit testing'. Zodra alle individuele units zijn gemaakt en getest, beginnen we met het combineren van die 'Unit Tested' -modules en beginnen we met de geïntegreerde tests.

De belangrijkste functie of het doel van deze test is het testen van de interfaces tussen de units / modules.

De afzonderlijke modules worden eerst afzonderlijk getest. Nadat de modules zijn getest, worden ze één voor één geïntegreerd totdat alle modules zijn geïntegreerd, om het combinatiegedrag te controleren en te valideren of de vereisten correct zijn geïmplementeerd of niet.

Hier moeten we begrijpen dat integratietesten niet aan het einde van de cyclus plaatsvinden, maar tegelijkertijd met de ontwikkeling worden uitgevoerd. Dus in de meeste gevallen zijn niet alle modules beschikbaar om te testen en hier is de uitdaging om iets te testen dat niet bestaat!

Waarom integratietest?

We zijn van mening dat integratietesten complex zijn en enige ontwikkeling en logische vaardigheid vereisen. Dat is waar! Wat is dan het doel van het integreren van deze testen in onze teststrategie?

Hier zijn enkele redenen:

  1. In de echte wereld, wanneer applicaties worden ontwikkeld, wordt deze opgesplitst in kleinere modules en krijgen individuele ontwikkelaars 1 module toegewezen. De logica die door de ene ontwikkelaar wordt geïmplementeerd, is heel anders dan die van een andere ontwikkelaar, dus het wordt belangrijk om te controleren of de door een ontwikkelaar geïmplementeerde logica voldoet aan de verwachtingen en de juiste waarde weergeeft in overeenstemming met de voorgeschreven normen.
  2. Vaak verandert het gezicht of de structuur van gegevens wanneer ze van de ene module naar de andere gaan. Sommige waarden worden toegevoegd of verwijderd, wat problemen veroorzaakt in de latere modules.
  3. Modules werken ook samen met tools of API's van derden die ook moeten worden getest om te controleren of de gegevens die door die API / tool worden geaccepteerd, correct zijn en dat de gegenereerde respons ook is zoals verwacht.
  4. Een veel voorkomend probleem bij het testen - Regelmatige wijziging van vereisten! :) Vaak implementeert ontwikkelaar de wijzigingen zonder deze te testen. Integratietesten worden op dat moment belangrijk.

Voordelen

Er zijn verschillende voordelen van deze tests en er worden er enkele hieronder opgesomd.

  • Deze test zorgt ervoor dat de geïntegreerde modules / componenten goed werken.
  • Integratietesten kunnen worden gestart zodra de te testen modules beschikbaar zijn. Het vereist niet dat de andere module wordt voltooid om te testen, omdat Stubs en Drivers hiervoor kunnen worden gebruikt.
  • Het detecteert de fouten met betrekking tot de interface.

Uitdagingen

Hieronder staan ​​enkele uitdagingen vermeld die bij Integratietest komen kijken.

# 1) Integratietesten zijn het testen van twee of meer geïntegreerde systemen om er zeker van te zijn dat het systeem goed werkt. Niet alleen de integratiekoppelingen moeten worden getest, maar er moet ook grondig worden getest, rekening houdend met de omgeving, om er zeker van te zijn dat het geïntegreerde systeem correct werkt.

Er kunnen verschillende paden en permutaties zijn die kunnen worden toegepast om het geïntegreerde systeem te testen.

#twee) Het beheren van integratietests wordt complex vanwege enkele factoren die daarbij betrokken zijn, zoals de database, het platform, de omgeving enz.

# 3) Hoewel het integreren van een nieuw systeem met het oude systeem, zijn er veel wijzigingen en testinspanningen nodig. Hetzelfde geldt voor de integratie van twee legacysystemen.

# 4) Het integreren van twee verschillende systemen die door twee verschillende bedrijven zijn ontwikkeld, is een grote uitdaging, aangezien het niet zeker is hoe een van de systemen het andere systeem zal beïnvloeden als er wijzigingen worden aangebracht in een van de systemen.

Om de impact tijdens het ontwikkelen van een systeem te minimaliseren, moet met een paar dingen rekening worden gehouden, zoals mogelijke integratie met andere systemen, enz.

Soorten integratietests

Hieronder wordt een type testintegratie gegeven, samen met de voor- en nadelen ervan.

Big Bang-benadering:

Big bang-benadering integreert alle modules in één keer, d.w.z. het gaat niet om de modules één voor één te integreren. Het controleert of het systeem werkt zoals verwacht of niet eenmaal geïntegreerd. Als er een probleem wordt gedetecteerd in de volledig geïntegreerde module, wordt het moeilijk om erachter te komen welke module het probleem heeft veroorzaakt.

De oerknalbenadering is een tijdrovend proces om een ​​module te vinden die zelf een defect heeft, aangezien dat tijd zou kosten en als het defect eenmaal is gedetecteerd, zou het repareren ervan hoog kosten, aangezien het defect in een later stadium wordt gedetecteerd.

Oerknal benadering

Voordelen van de Big Bang-benadering:

  • Het is een goede aanpak voor kleine systemen.

Nadelen van de Big Bang-benadering:

  • Het is moeilijk om de module te detecteren die een probleem veroorzaakt.
  • De Big Bang-benadering vereist alle modules bij elkaar om te testen, wat op zijn beurt leidt tot minder tijd voor het testen, aangezien het ontwerpen, ontwikkelen en integreren de meeste tijd in beslag zou nemen.
  • Het testen vindt slechts in één keer plaats, waardoor er geen tijd overblijft voor het afzonderlijk testen van kritische modules.

Integratieteststappen:

  1. Bereid de integratie voor Testplan.
  2. Bereid integratietestscenario's en testcases voor.
  3. Bereid testautomatiseringsscripts voor.
  4. Voer testcases uit.
  5. Meld de gebreken.
  6. Volg en test de defecten opnieuw.
  7. Het opnieuw testen en testen gaat door totdat de integratietest is voltooid.

Test integratiebenaderingen

Er zijn fundamenteel 2 benaderingen voor het doen van testintegratie:

  1. Bottom-up benadering
  2. Top-down benadering.

Laten we de onderstaande figuur eens bekijken om de benaderingen te testen:

Integratie 1

Bottom-up benadering:

Bottom-up testen, zoals de naam al doet vermoeden, beginnen bij de laagste of de binnenste eenheid van de applicatie en gaan geleidelijk omhoog. De integratietest begint bij de onderste module en gaat geleidelijk verder naar de bovenste modules van de applicatie. Deze integratie gaat door totdat alle modules zijn geïntegreerd en de volledige applicatie als een enkele eenheid is getest.

In dit geval zijn de modules B1C1, B1C2 & B2C1, B2C2 de laagste module die wordt getest. Module B1 & B2 zijn nog niet ontwikkeld. De functionaliteit van Module B1 en B2 is dat het de modules B1C1, B1C2 & B2C1, B2C2 aanroept. Aangezien B1 en B2 nog niet ontwikkeld zijn, hebben we een programma of een 'stimulator' nodig die de B1C1, B1C2 & B2C1, B2C2 modules zal noemen. Deze stimulatorprogramma's worden genoemd BESTUURDERS ​

In eenvoudige bewoordingen, BESTUURDERS zijn de dummy-programma's die worden gebruikt om de functies van de laagste module aan te roepen in het geval dat de aanroepfunctie niet bestaat. De bottom-up techniek vereist dat een modulestuurprogramma de input van de testcase naar de interface van de te testen module voert.

Het voordeel van deze aanpak is dat, als er een grote fout aanwezig is op de laagste eenheid van het programma, deze gemakkelijker te detecteren is en corrigerende maatregelen kunnen worden genomen.

Het nadeel is dat het hoofdprogramma eigenlijk pas bestaat als de laatste module is geïntegreerd en getest. Als gevolg hiervan zullen de ontwerpfouten op een hoger niveau pas aan het einde worden gedetecteerd.

Top-down benadering

Deze techniek begint bij de bovenste module en vordert geleidelijk naar de lagere modules. Alleen de bovenste module is afzonderlijk getest. Hierna worden de onderste modules één voor één geïntegreerd. Het proces wordt herhaald totdat alle modules zijn geïntegreerd en getest.

loadrunner interviewvragen en antwoorden voor ervaren

In de context van onze figuur begint het testen vanaf module A en worden de lagere modules B1 en B2 één voor één geïntegreerd. Nu zijn hier de onderste modules B1 en B2 eigenlijk niet beschikbaar voor integratie. Dus om de bovenste modules A te testen, ontwikkelen we “ STUBS ​

'Stubs' kan worden aangeduid als een codefragment dat de invoer / verzoeken van de bovenste module accepteert en de resultaten / respons retourneert. Op deze manier, ondanks dat de onderste modules niet bestaan, kunnen we de bovenste module testen.

In praktische scenario's is het gedrag van stubs niet zo eenvoudig als het lijkt. In dit tijdperk van complexe modules en architectuur, de zogenaamde module, gaat het meestal om complexe bedrijfslogica, zoals verbinding maken met een database. Als gevolg hiervan wordt het maken van stubs net zo complex en tijdrovend als de echte module. In sommige gevallen kan de Stub-module groter blijken te zijn dan de gestimuleerde module.

Zowel stubs als stuurprogramma's zijn een dummy stukje code dat wordt gebruikt voor het testen van de 'niet bestaande' modules. Ze activeren de functies / methode en geven het antwoord terug, dat wordt vergeleken met het verwachte gedrag

Laten we een verschil maken tussen Stubs en Driver ​

StompjesBestuurder
Gebruikt in Top-down benaderingGebruikt in een bottom-up benadering
De bovenste module wordt eerst getestDe laagste modules worden eerst getest.
Stimuleert het lagere niveau van componentenStimuleert het hogere niveau van componenten
Dummy-programma van componenten op een lager niveauDummy-programma voor component op hoger niveau

De enige verandering is constant in deze wereld, dus we hebben een andere benadering genaamd ' Sandwich testen ”Die de kenmerken van zowel een top-down- als een bottom-up-benadering combineert. Als we enorme programma's zoals besturingssystemen testen, hebben we wat meer technieken nodig die efficiënt zijn en meer vertrouwen wekken. Sandwich-testen spelen hier een zeer belangrijke rol, waarbij zowel de Top-down- als de bottom-up-testen tegelijkertijd worden gestart.

Integratie begint bij de middelste laag en beweegt tegelijkertijd naar boven en naar beneden. In het geval van onze figuur, zullen onze tests beginnen bij B1 en B2, waarbij een arm de bovenste module A test en een andere arm de onderste modules B1C1, B1C2 & B2C1, B2C2.

Aangezien beide benaderingen gelijktijdig starten, is deze techniek een beetje ingewikkeld en vereist meer mensen samen met specifieke vaardigheden, wat de kosten verhoogt.

GUI-applicatie-integratietest

Laten we het nu hebben over hoe we integratietesten in de Black box-techniek kunnen impliceren.

We begrijpen allemaal dat een webapplicatie een applicatie met meerdere lagen is. We hebben een front-end die zichtbaar is voor de gebruiker, we hebben een middelste laag met bedrijfslogica, we hebben wat meer middelste laag die enkele validaties uitvoert, een aantal API's van derden integreren enz., En dan hebben we de achterste laag die de database.

Voorbeeld van een integratietest:

Laten we het onderstaande voorbeeld eens bekijken​

Ik ben de eigenaar van een reclamebedrijf en ik plaats advertenties op verschillende websites. Aan het einde van de maand wil ik zien hoeveel mensen mijn advertenties hebben gezien en hoeveel mensen op mijn advertenties hebben geklikt. Ik heb een rapport nodig voor mijn weergegeven advertenties en breng dienovereenkomstig kosten in rekening bij mijn klanten.

GenNext-software ontwikkelde dit product voor mij en hieronder stond de architectuur:

Integratie 2

UI - Gebruikersinterfacemodule, die zichtbaar is voor de eindgebruiker, waar alle invoer wordt gegeven.
BL - Is de Business Logic-module, die alle berekeningen en bedrijfsspecifieke methoden bevat.
VAL - Is de Validatiemodule, die alle validaties van de juistheid van de invoer heeft.
CNT - Is de inhoudsmodule die alle statische inhoud bevat, specifiek voor de invoer die door de gebruiker is ingevoerd. Deze inhoud wordt weergegeven in de rapporten.
IN - Is de Engine-module, deze module leest alle gegevens die afkomstig zijn van de BL-, VAL- en CNT-module en extraheert de SQL-query en triggert deze naar de database.
Scheduler - Is een module die alle rapporten plant op basis van de gebruikersselectie (maandelijks, driemaandelijks, halfjaarlijks en jaarlijks)
DB - Is de database.

Nu we de architectuur van de hele webapplicatie als een enkele eenheid hebben gezien, zal integratietest zich in dit geval concentreren op de gegevensstroom tussen de modules.

De vragen hier zijn:

  1. Hoe zullen de BL, VAL en de CNT-module de gegevens die in de UI-module zijn ingevoerd, lezen en interpreteren?
  2. Ontvangt de BL-, VAL- en CNT-module de juiste gegevens van de gebruikersinterface?
  3. In welk formaat worden de gegevens van BL, VAL en CNT overgebracht naar de EQ-module?
  4. Hoe zal de EQ de gegevens lezen en de vraag extraheren?
  5. Is de vraag correct geëxtraheerd?
  6. Krijgt de Scheduler de juiste gegevens voor rapporten?
  7. Is de resultaatset ontvangen door de EN, uit de database, correct en zoals verwacht?
  8. Kan EN het antwoord terugsturen naar de BL-, VAL- en CNT-module?
  9. Is de UI-module in staat om de gegevens te lezen en op de juiste manier weer te geven aan de interface?

In de echte wereld gebeurt de communicatie van gegevens in een XML-indeling. Dus welke gegevens de gebruiker ook invoert in de gebruikersinterface, deze worden geconverteerd naar een XML-indeling.

In ons scenario worden de gegevens die in de UI-module zijn ingevoerd, omgezet in een XML-bestand dat wordt geïnterpreteerd door de 3 modules BL, VAL en CNT. De EN-module leest het resulterende XML-bestand dat door de 3 modules is gegenereerd en haalt de SQL eruit en voert zoekopdrachten uit in de database. De EN-module ontvangt ook de resultatenset en converteert deze naar een XML-bestand en stuurt deze terug naar de UI-module die de resultaten omzet in door de gebruiker leesbare vorm en deze weergeeft.

In het midden hebben we de scheduler-module die de resultatenset van de EN-module ontvangt, de rapporten aanmaakt en plant.

Dus waar komt integratietesten in beeld?

Nou, testen of de informatie / data correct stroomt of niet, zal je integratietest zijn, wat in dit geval de XML-bestanden zou valideren. Zijn de XML-bestanden correct gegenereerd? Hebben ze de juiste gegevens? Worden de gegevens correct overgedragen van de ene module naar de andere? Al deze dingen zullen worden getest als onderdeel van integratietests.

Probeer de XML-bestanden te genereren of op te halen en werk de tags bij en controleer het gedrag. Dit is iets heel anders dan het gebruikelijke testen dat testers normaal doen, maar dit zal waarde toevoegen aan de kennis en het begrip van de tester over de applicatie.

Er zijn maar weinig andere testomstandigheden voor monsters kunnen als volgt zijn:

  • Genereren de menu-opties het juiste venster?
  • Kunnen de vensters het te testen venster oproepen?
  • Identificeer voor elk venster de functieaanroepen voor het venster dat de toepassing zou moeten toestaan.
  • Identificeer alle oproepen vanuit het venster naar andere functies die de applicatie zou moeten toestaan
  • Identificeer omkeerbare oproepen: als u een opgeroepen venster sluit, moet u terugkeren naar het oproepvenster.
  • Identificeer onomkeerbare oproepen: aanroepvensters worden gesloten voordat het opgeroepen venster verschijnt.
  • Test de verschillende manieren om oproepen naar een ander venster uit te voeren, bijv. - menu's, knoppen, trefwoorden.

Stappen om integratietests te starten

  1. Begrijp de architectuur van uw applicatie.
  2. Identificeer de modules
  3. Begrijp wat elke module doet
  4. Begrijp hoe de gegevens worden overgedragen van de ene module naar de andere.
  5. Begrijpen hoe de gegevens worden ingevoerd en ontvangen in het systeem (ingangspunt en uitgangspunt van de applicatie)
  6. Scheid de applicatie om aan uw testbehoeften te voldoen.
  7. Identificeer en creëer de testcondities
  8. Neem een ​​voorwaarde tegelijk en schrijf de testcases op.

Criteria voor binnenkomst / vertrek voor integratietests

Toelatingscriteria:

  • Het integratietestplan-document wordt afgetekend en goedgekeurd.
  • Er zijn integratietestcases voorbereid.
  • Er zijn testgegevens gemaakt.
  • Testen van een eenheid van ontwikkelde modules / componenten is voltooid.
  • Alle kritieke defecten en defecten met hoge prioriteit zijn gesloten.
  • De testomgeving is ingericht voor integratie.

Exit Criteria:

  • Alle integratietestgevallen zijn uitgevoerd.
  • Er worden geen kritieke en Prioritaire P1- en P2-defecten geopend.
  • Testrapport is opgesteld.

Integratietestcases

Integratietestcases richten zich voornamelijk op de interface tussen de modules, geïntegreerde koppelingen, gegevensoverdracht tussen de modules als modules / componenten die al unit-getest zijn, d.w.z. de functionaliteit en de andere testaspecten zijn al gedekt.

Het belangrijkste idee is dus om te testen of de integratie van twee werkende modules werkt zoals verwacht wanneer ze worden geïntegreerd.

Voorbeelden van integratietestcases voor Linkedin-toepassingen zijn:

  • Het verifiëren van de interfacekoppeling tussen de aanmeldingspagina en de startpagina, d.w.z. wanneer een gebruiker de inloggegevens en logs invoert, moet deze naar de startpagina worden geleid.
  • Het verifiëren van de interfacekoppeling tussen de startpagina en de profielpagina, d.w.z. de profielpagina zou moeten openen.
  • Controleer de interfacekoppeling tussen de netwerkpagina en uw verbindingspagina's, d.w.z. als u op de knop Accepteren klikt op Uitnodigingen van de netwerkpagina, moet de geaccepteerde uitnodiging op uw verbindingspagina worden weergegeven zodra erop is geklikt.
  • Controleer de interfacekoppeling tussen de meldingspagina's en de knop Gefeliciteerd zeggen, d.w.z. als u op de knop Gefeliciteerd klikt, moet u naar het nieuwe berichtvenster leiden.

Voor deze specifieke site kunnen veel integratietestcases worden geschreven. De bovenstaande vier punten zijn slechts een voorbeeld om te begrijpen welke integratietestcases bij het testen zijn inbegrepen.

Is integratie een white box- of black box-techniek?

Integratietesttechniek kan zowel in zwarte dozen als in white box-techniek ​ Black box-techniek is waar een tester geen interne kennis van het systeem hoeft te hebben, d.w.z. codeerkennis is niet vereist, terwijl de white box-techniek interne kennis van de applicatie vereist.

Tijdens het uitvoeren van integratietests zou het kunnen bestaan ​​uit het testen van de twee geïntegreerde webservices die de gegevens uit de database halen en de gegevens leveren zoals vereist, wat betekent dat het kan worden getest met behulp van de white box-testtechniek, terwijl de integratie van een nieuwe functie in de website kan worden getest met behulp van de black box-techniek.

Het is dus niet specifiek dat integratietests een black box- of white box-techniek zijn.

Integratietesttools

Er zijn verschillende tools beschikbaar voor dit testen.

Hieronder vindt u een lijst met tools:

  • Rationele integratie-tester
  • Gradenboog
  • Stoom
  • TESSY

Raadpleeg deze tutorial voor meer informatie over de bovenstaande tools:

Top 10 integratietesttools om integratietests te schrijven

Systeemintegratietesten

Systeemintegratietest wordt gedaan om het compleet geïntegreerd systeem ​

Modules of componenten worden afzonderlijk getest in unit-tests voordat de componenten worden geïntegreerd.

Nadat alle modules zijn getest, wordt de systeemintegratietest uitgevoerd door alle modules te integreren en wordt het systeem als geheel getest.

Verschil tussen integratietesten en systeemtesten

Integratietest is een test waarbij een of twee modules die zijn getest, worden geïntegreerd om te testen en verificatie wordt uitgevoerd om te controleren of de geïntegreerde modules werken zoals verwacht of niet.

Systeemtesten is een testen waarbij de systeem als geheel wordt getest, d.w.z. alle modules / componenten zijn samen geïntegreerd om te controleren of het systeem werkt zoals verwacht en dat er geen problemen optreden vanwege de geïntegreerde modules.

Gevolgtrekking

Dit gaat allemaal over integratietests en de implementatie ervan in zowel de White box- als de Black box-techniek. Ik hoop dat we het duidelijk hebben uitgelegd met relevante voorbeelden.

Testintegratie is een belangrijk onderdeel van de testcyclus, omdat het het gemakkelijker maakt om het defect te vinden wanneer twee of meer modules zijn geïntegreerd om alle modules allemaal samen te integreren in de eerste stap zelf.

Het helpt om de defecten in een vroeg stadium op te sporen, wat op zijn beurt ook weer moeite en kosten bespaart. Het zorgt ervoor dat de geïntegreerde modules naar behoren werken zoals verwacht.

Ik hoop dat deze informatieve tutorial over integratietesten je kennis van het concept zou hebben verrijkt.

Aanbevolen literatuur

^