Wat is System Integration Testing (SIT): leer met voorbeelden

what is system integration testing

Wat is systeemintegratietesten?

System Integration Testing (SIT) is het algemene testen van het hele systeem dat is samengesteld uit vele subsystemen. Het belangrijkste doel van SIT is om ervoor te zorgen dat alle afhankelijkheden van softwaremodules correct werken en dat de gegevensintegriteit tussen verschillende modules van het hele systeem behouden blijft.

SUT (System Under Test) kan bestaan ​​uit hardware, database, software, een combinatie van hardware en software of een systeem dat menselijke interactie vereist (HITL - Human in the Loop Testing).

Vanuit de context van software engineering en softwaretests kan SIT worden beschouwd als een testproces dat controleert of het softwaresysteem samen met anderen voorkomt.

SIT heeft een voorwaarde waarin meerdere onderliggende geïntegreerde systemen al systeemtesten hebben ondergaan en doorstaan. SIT test vervolgens de vereiste interacties tussen deze systemen als geheel. De deliverables van SIT worden doorgegeven aan de UAT (User Acceptance Testing).

Wat je leert:

• Noodzaak van systeemintegratietest
• De granulariteit van SIT
• Hoe systeemintegratietests uitvoeren?
• Systeemtesten versus systeemintegratietesten
• Systeemintegratietesten versus gebruikersacceptatietesten
• SIT-voorbeeld
• SIT-technieken
  • # 1) Top-down benadering:
  • # 2) Bottom-up benadering:
  • # 3) Sandwich-aanpak:
  • # 4) Big Bang-benadering:
• Gevolgtrekking
• Aanbevolen literatuur

Noodzaak van systeemintegratietest

De belangrijkste functie van SIT is om testafhankelijkheden tussen verschillende systeemcomponenten uit te voeren en daarom is regressietesten een belangrijk onderdeel van SIT.

Voor samenwerkingsprojecten maakt SIT deel uit van STLC (Software Testing Lifecycle). Over het algemeen wordt een pre-SIT-ronde uitgevoerd door de softwareleverancier voordat de klant zijn eigen SIT-testcases uitvoert.

In de meeste organisaties die in IT-projecten werken volgens het Agile-sprintmodel, wordt vóór elke release een SIT-ronde uitgevoerd door het QA-team. De defecten die in de SIT zijn gevonden, worden teruggestuurd naar het ontwikkelteam en zij werken aan de fixes.

De MVP-release (Minimum Viable Product) van de sprint gaat alleen als deze door SIT wordt gehaald.

SIT is vereist om de fouten bloot te leggen die optreden wanneer interactie plaatsvindt tussen de geïntegreerde subsystemen.

Er worden verschillende componenten in het systeem gebruikt en deze kunnen niet afzonderlijk worden getest. Zelfs als de eenheid afzonderlijk wordt getest, is er ook een mogelijkheid dat deze kan falen wanneer deze in het systeem wordt gecombineerd, omdat er veel problemen optreden wanneer subsystemen met elkaar communiceren.

SIT is dus zeer vereist om de fouten bloot te leggen en op te lossen voordat het systeem aan de kant van de gebruiker wordt geïmplementeerd. SIT detecteert de defecten in een vroeg stadium en bespaart zo tijd en kosten om deze later te repareren. Het helpt je ook om eerder feedback te krijgen over de aanvaardbaarheid van de module.

De granulariteit van SIT

SIT kan worden uitgevoerd op drie verschillende granulariteitsniveaus:

(i) Intra-systeem testen: Dit is een laag niveau van integratietests die erop gericht zijn de modules samen te smelten om een ​​uniform systeem te bouwen.

(ii) Testen tussen systemen: Dit zijn testen op hoog niveau waarvoor onafhankelijk geteste systemen moeten worden gekoppeld.

(iii) Paarsgewijze testen: Hier worden slechts twee onderling verbonden subsystemen in het hele systeem tegelijk getest. Dit is bedoeld om ervoor te zorgen dat de twee subsystemen goed kunnen functioneren wanneer ze samen worden gecombineerd, ervan uitgaande dat de andere subsystemen al goed werken.

Hoe systeemintegratietests uitvoeren?

De eenvoudigste manier om SIT uit te voeren, is via een gegevensgestuurde methode. Het vereist minimaal gebruik van softwaretesttools.

gratis download van de tijdkloksoftware voor werknemers

Eerst vindt gegevensuitwisseling (data-import en data-export) plaats tussen de systeemcomponenten en vervolgens wordt het gedrag van elk dataveld binnen de individuele laag bekeken.

Zodra de software is geïntegreerd, zijn er drie hoofdstatussen van de gegevensstroom, zoals hieronder vermeld:

# 1) Gegevensstatus binnen de integratielaag

De integratielaag fungeert als een interface tussen het importeren en exporteren van gegevens. Het uitvoeren van SIT op deze laag vereist enige basiskennis van bepaalde technologie zoals schema (XSD), XML, WSDL, DTD en EDI.

De prestaties van gegevensuitwisseling kunnen op deze laag worden onderzocht door de onderstaande stappen:

• Valideer de gegevenseigenschappen binnen deze laag aan de hand van BRD / FRD / TRD (document met zakelijke vereisten / document met functionele vereisten / document met technische vereisten).
• Controleer het webserviceverzoek met XSD en WSDL.
• Voer enkele unit tests uit en valideer de gegevenstoewijzingen en verzoeken.
• Bekijk de middlewarelogboeken.

# 2) Gegevensstatus binnen de databaselaag

Het uitvoeren van SIT op deze laag vereist een basiskennis van SQL en opgeslagen procedures.

De prestaties van gegevensuitwisseling op deze laag kunnen worden onderzocht door de onderstaande stappen:

• Controleer of alle gegevens van de integratielaag met succes zijn bereikt op de databaselaag en zijn vastgelegd.
• Valideer de tabel- en kolomeigenschappen tegen BRD / FRD / TRD.
• Valideer de beperkingen en gegevensvalidatieregels die in de database zijn toegepast volgens de bedrijfsspecificaties.
• Controleer opgeslagen procedures voor eventuele verwerkingsgegevens.
• Bekijk de serverlogboeken.

# 3) Gegevensstatus binnen de toepassingslaag

SIT kan op deze laag worden uitgevoerd via de onderstaande stappen:

• Controleer of alle verplichte velden zichtbaar zijn in de gebruikersinterface.
• Voer enkele positieve en negatieve testgevallen uit en valideer de gegevenseigenschappen.

Opmerking: Er kunnen veel combinaties zijn die overeenkomen met gegevensimport en gegevensexport. U moet SIT uitvoeren voor de beste combinaties, rekening houdend met de beschikbare tijd.

Systeemtesten versus systeemintegratietesten

Verschillen tussen systeemtesten en SIT:

Systeemintegratietesten versus gebruikersacceptatietesten

Hier is het verschil tussen SIT en UAT:

De onderstaande afbeelding over de testniveaus zou de stroom van Unit-testen naar UAT duidelijk maken:

SIT-voorbeeld

Laten we aannemen dat een bedrijf software gebruikt om de klantgegevens op te slaan.

Deze software heeft twee schermen in de gebruikersinterface - scherm 1 en scherm 2, en het heeft een database. De gegevens die in Scherm 1 en Scherm 2 zijn ingevoerd, worden in de database ingevoerd. Vanaf nu is het bedrijf tevreden met deze software.

Een paar jaar later constateert het bedrijf echter dat de software niet aan de eisen voldoet en dat er behoefte is aan verbetering. Daarom ontwikkelden ze een Screen 3 en een database. Nu is dit systeem met scherm 3 en een database geïntegreerd met de oudere / bestaande software.

world of warcraft beste privéserver

Nu wordt het testen op het hele systeem na de integratie System Integration-test genoemd. Hier wordt het naast elkaar bestaan ​​van een nieuw systeem met een bestaand systeem getest om er zeker van te zijn dat het hele geïntegreerde systeem goed werkt.

SIT-technieken

Er zijn voornamelijk 4 benaderingen om SIT te doen:

1. Top-down benadering
2. Bottom-up benadering
3. Sandwich-aanpak
4. Big Bang-benadering

De top-down benadering en de bottom-up benadering zijn een soort incrementele benadering. Laten we de discussie eerst beginnen met een Top-down-benadering.

# 1) Top-down benadering:

Hieronder begint het testen met alleen de bovenste module van een applicatie, d.w.z. de gebruikersinterface die we als testdriver noemen.

De functionaliteit van de onderliggende modules wordt gesimuleerd met stubs. De bovenste module wordt één voor één geïntegreerd met de onderste modulestomp en later wordt de functionaliteit getest.

Nadat elke test is voltooid, wordt de stub vervangen door de echte module. De modules kunnen ofwel in de breedte eerst of in de diepte eerst worden geïntegreerd. De test gaat door totdat de hele applicatie is gebouwd.

Het voordeel van deze aanpak is dat er geen drivers nodig zijn en dat de testcases gespecificeerd kunnen worden in termen van functionaliteit van het systeem.

De belangrijkste uitdaging bij dit type benadering is de afhankelijkheid van de beschikbaarheid van modulefunctionaliteit op een lager niveau. Er kan een vertraging optreden in tests totdat de echte modules zijn vervangen door stubs. Het schrijven van stompjes is ook moeilijk.

# 2) Bottom-up benadering:

Het elimineert de beperkingen van de top-down benadering.

Bij deze methode worden eerst de modules van het laagste niveau samengesteld om clusters te vormen. Deze clusters dienen als een subfunctie van de applicatie. Vervolgens wordt een stuurprogramma gemaakt om de invoer en uitvoer van de testcase te beheren. Hierna wordt het cluster getest.

Nadat het cluster is getest, wordt de driver verwijderd en wordt het cluster gecombineerd met het volgende bovenste niveau. Dit proces gaat door totdat de hele applicatiestructuur is bereikt.

Bij deze benadering zijn geen stubs nodig. Het wordt vereenvoudigd naarmate de verwerking omhoog gaat en de behoefte aan stuurprogramma's wordt verminderd. Deze benadering is aan te raden voor het doen van SIT voor objectgeoriënteerde systemen, real-time systemen en systemen met strikte prestatie-eisen.

basisvragen voor probleemoplossing die in een interview worden gesteld

De beperking van deze benadering is echter het belangrijkste subsysteem, d.w.z. de gebruikersinterface wordt als laatste getest.

# 3) Sandwich-aanpak:

Hier worden de hierboven besproken benaderingen van bovenaf en van onderaf met elkaar gecombineerd.

Het systeem wordt gezien als drie lagen: de middelste laag is de doellaag, een laag boven het doel en een laag onder het doel. Het testen gebeurt in beide richtingen en komt samen op de doellaag die zich in het midden bevindt en dit wordt geïllustreerd in de onderstaande afbeelding.

Strategie voor het testen van sandwiches

Een voordeel van deze aanpak is dat de bovenlaag en de onderlaag van het systeem parallel kunnen worden getest. De beperking van deze benadering is echter dat de afzonderlijke subsystemen vóór integratie niet uitputtend worden getest.

Om deze beperking te elimineren, hebben we aangepaste sandwich-testen waarbij de integratie van de bovenste, middelste en onderste lagen parallel wordt getest met behulp van stubs en stuurprogramma's.

# 4) Big Bang-benadering:

Bij deze aanpak vindt integratie plaats zodra alle modules van de applicatie volledig gereed zijn. Er wordt getest na de integratie van alle modules om te controleren of het geïntegreerde systeem werkt of niet.

Het is een uitdaging om in deze benadering de oorzaak van het probleem te achterhalen, aangezien alles in één keer wordt geïntegreerd in plaats van incrementeel testen. Deze benadering wordt over het algemeen toegepast wanneer slechts één ronde van SIT vereist is.

Gevolgtrekking

In dit artikel hebben we geleerd wat System Integration Testing (SIT) is en waarom het belangrijk is om het uit te voeren.

We begrepen de kernconcepten, technieken, benaderingen en de methoden die betrokken zijn bij het uitvoeren van SIT. We hebben ook doorgenomen hoe SIT verschilt van UAT en systeemtesten.

Ik hoop dat je genoten hebt van dit uitstekende artikel !!

Aanbevolen literatuur

• Wat is componenttesten of moduletesten (leer met voorbeelden)
• Wat is vergelijkingstesten (leren met voorbeelden)
• Wat is integratietesten (zelfstudie met voorbeeld van integratietesten)
• Beste softwaretesttools 2021 (QA Test Automation Tools)
• De verschillen tussen unit-tests, integratietests en functionele tests
• Functioneel testen versus niet-functioneel testen
• Integratie van selenium met JMeter
• Spock voor integratie en functioneel testen met selenium