Wat is Systeem Integratie Testen?
Systeem Integratie Testen (SIT) is het testen van het gehele systeem dat is opgebouwd uit vele subsystemen. Het belangrijkste doel van SIT is om ervoor te zorgen dat alle afhankelijkheden tussen de softwaremodules goed functioneren en dat de data-integriteit tussen de 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 het testen van software kan SIT worden beschouwd als een testproces waarbij de samenhang van het softwaresysteem met andere systemen wordt gecontroleerd.
SIT heeft als randvoorwaarde dat meerdere onderliggende geïntegreerde systemen al systeemtesten hebben ondergaan en doorstaan. SIT test vervolgens de vereiste interacties tussen deze systemen als geheel. De resultaten van SIT worden doorgegeven aan de UAT (User acceptance testing).
Noodzaak van Systeem Integratie Test
De belangrijkste functie van SIT is het testen van afhankelijkheden tussen verschillende systeemcomponenten en daarom is regressietesten een belangrijk onderdeel van SIT.
Voor samenwerkingsprojecten is SIT een onderdeel van STLC (Software Testing Lifecycle). Over het algemeen wordt een pre-SIT ronde uitgevoerd door de softwareleverancier voordat de klant zijn eigen SIT testgevallen uitvoert.
In de meeste organisaties die werken in IT-projecten volgens het Agile sprint-model, wordt een ronde van SIT uitgevoerd door het QA-team voor elke release. De defecten die in de SIT worden gevonden, worden teruggestuurd naar het ontwikkelingsteam en zij werken aan de fixes.
De MVP (Minimum Viable Product) release van de sprint gaat pas als het door SIT wordt gehaald.
SIT is nodig 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 ze kunnen niet individueel op de unit worden getest. Zelfs als de eenheid individueel wordt getest, dan is er ook een mogelijkheid dat het kan mislukken wanneer gecombineerd in het systeem als er veel problemen die zich voordoen wanneer subsystemen met elkaar interageren.
Dus, SIT is zeer nodig om bloot te leggen en de storingen te verhelpen voordat het systeem aan de gebruiker eind. SIT detecteert de defecten in een vroeg stadium en bespaart dus tijd en kosten om ze later te herstellen. Het helpt u ook om eerder feedback te krijgen over de aanvaardbaarheid van de module.
De granulariteit van SIT
SIT kan op drie verschillende granulariteitsniveaus worden uitgevoerd:
(i) Intra-Systeem Testen: Dit is een laag niveau van integratietesten dat gericht is op het samensmelten van de modules om een verenigd systeem te bouwen.
(ii) Inter-System Testing: Dit is testen op hoog niveau waarbij onafhankelijk geteste systemen met elkaar moeten worden verbonden.
(iii) Pairwise Testing: Hier worden slechts twee met elkaar verbonden subsystemen in het gehele systeem tegelijk getest. Het doel hiervan is ervoor te zorgen dat de twee subsystemen goed kunnen functioneren wanneer ze worden gecombineerd, ervan uitgaande dat de andere subsystemen al goed werken.
Hoe kunnen systeemintegratietests worden uitgevoerd?
De eenvoudigste manier om SIT uit te voeren is met behulp van een datagestuurde methode. Deze methode vereist een minimaal gebruik van software testing tools.
Eerst vindt gegevensuitwisseling (gegevensimport en -export) plaats tussen de systeemcomponenten en vervolgens wordt het gedrag van elk gegevensveld binnen de afzonderlijke laag onderzocht.
Als de software eenmaal is geïntegreerd, zijn er drie hoofdtoestanden van de gegevensstroom, zoals hieronder vermeld:
1) Toestand van de gegevens binnen de integratielaag
De integratielaag fungeert als een interface tussen de gegevensimport en -export. Het uitvoeren van SIT in deze laag vereist enige basiskennis van bepaalde technologie zoals schema (XSD), XML, WSDL, DTD en EDI.
De prestaties van de gegevensuitwisseling kunnen in deze laag worden onderzocht aan de hand van de volgende stappen:
- Valideer de gegevenseigenschappen in deze laag tegen BRD/ FRD/ TRD (document met bedrijfsvereisten/ document met functionele vereisten/ document met technische vereisten).
- Cross check het webservice verzoek met behulp van XSD en WSDL.
- Run enkele unit tests en valideer de data mappings en requests.
- Bekijk de middleware logs.
#2) Data state binnen de Database laag
Het uitvoeren van SIT op deze laag vereist een basiskennis van SQL en stored procedures.
De prestaties van de gegevensuitwisseling in deze laag kunnen worden onderzocht aan de hand van de volgende stappen:
- Controleer of alle gegevens uit de integratielaag met succes de databaselaag hebben bereikt en zijn gecommit.
- Valideer de tabel- en kolomeigenschappen tegen BRD/ FRD/ TRD.
- Valideer de constraints en gegevensvalidatieregels die in de database zijn toegepast volgens de bedrijfsspecificaties.
- Controleer stored procedures op verwerkingsgegevens.
- Bekijk serverlogs.
#3) Datastatus binnen de applicatielaag
SIT kan op deze laag worden uitgevoerd door middel van de volgende stappen:
- Controleer of alle vereiste velden zichtbaar zijn in de UI.
- Voer een aantal positieve en negatieve test cases uit en valideer de data properties.
Note: Er kunnen veel combinaties zijn die overeenkomen met data import en data export. U zult SIT moeten uitvoeren voor de beste combinaties, rekening houdend met de tijd die u ter beschikking staat.
Systeemtesten vs Systeemintegratietesten
Verschillen tussen Systeemtesten en SIT:
| SIT (Systeem Integratie Testen) | Systeem Testen |
|---|---|
| SIT wordt vooral gedaan om te controleren hoe afzonderlijke modules op elkaar inwerken als ze in een systeem als geheel zijn geïntegreerd. | Systeemtesten wordt vooral gedaan om te controleren of het hele systeem werkt zoals verwacht met verwijzing naar de gespecificeerde eisen. |
| Het wordt uitgevoerd op het laatste niveau dwz.d.w.z. na de voltooiing van de integratietests en vlak voor de oplevering van het systeem voor UAT. | |
| Het is een test op hoog niveau. | |
| Testgevallen, in dit geval, richten zich op het simuleren van de real-life scenario’s. |
System Integration Testing Vs User Acceptance Testing
Hier volgt het verschil tussen SIT en UAT:
| SIT (Systeem Integratie Testen) | UAT (Gebruikers Acceptatie Testing) |
|---|---|
| Dit testen is vanuit het perspectief van interfacing tussen modules. | Dit testen gebeurt vanuit het perspectief van gebruikerseisen. |
| UAT wordt gedaan door klanten en eindgebruikers. | |
| Doet na unit testing en voor systeem testing. | Dit is het laatste niveau van testen en wordt gedaan na systeem testing. |
| In het algemeen hebben de problemen die bij SIT worden gevonden betrekking op de gegevensstroom, de besturingsstroom, enz. | De problemen die in UAT worden gevonden, hebben in het algemeen te maken met de functies die niet werken volgens de vereisten van de gebruiker. |
De afbeelding hieronder over de niveaus van testen 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 UI – scherm 1 & scherm 2, en het heeft een database. De gegevens die in scherm 1 en scherm 2 worden ingevoerd, worden in de database ingevoerd. Het bedrijf is tevreden over deze software
Na een paar jaar komt het bedrijf er echter achter dat de software niet aan de eisen voldoet en dat er behoefte is aan verbetering. Daarom heeft men een scherm 3 en een database ontwikkeld. Nu is dit systeem met scherm 3 en een database geïntegreerd met de oudere/bestaande software.
Nu, het testen van het gehele systeem na de integratie wordt Systeem Integratie test genoemd. Hier wordt getest of een nieuw systeem en een bestaand systeem naast elkaar bestaan, om er zeker van te zijn dat het hele geïntegreerde systeem goed werkt.
SIT Technieken
In hoofdzaak zijn er 4 benaderingen voor het doen van SIT:
- Top-Down Benadering
- Bottom-up Benadering
- Sandwich Benadering
- Big Bang Benadering
De top-down benadering en de bottom-up benadering zijn een soort incrementele benaderingen. Laten we eerst beginnen met de Top-down benadering.
#1) Top-Down benadering:
Hierbij begint het testen met alleen de bovenste module van een applicatie, dat wil zeggen de UI, die we een testdriver noemen.
De functionaliteit van de onderliggende modules wordt gesimuleerd met stubs. De bovenste module wordt een voor een geïntegreerd met de stub modules van een lager niveau en later wordt de functionaliteit getest.
Als elke test is voltooid, wordt de stub vervangen door de echte module. De modules kunnen worden geïntegreerd op een breadth-first manier of op een depth-first manier. Het testen gaat door totdat de hele applicatie is gebouwd.
Het voordeel van deze aanpak is dat er geen drivers nodig zijn en dat de testgevallen kunnen worden gespecificeerd in termen van de functionaliteit van het systeem.
De grootste uitdaging bij dit type aanpak is de afhankelijkheid van de beschikbaarheid van functionaliteit van modules op een lager niveau. Er kan een vertraging in de tests optreden totdat de echte modules zijn vervangen door stubs. Het schrijven van stubs is ook moeilijk.
#2) Bottom-up benadering:
Het elimineert de beperkingen van de top-down benadering.
In deze methode worden eerst de laagste niveau modules geassembleerd om clusters te vormen. Deze clusters dienen als sub-functie van de toepassing. Vervolgens wordt een driver gemaakt om de input en output van de testcases te beheren. Hierna wordt het cluster getest.
Als het cluster is getest, wordt de driver verwijderd, en wordt het cluster gecombineerd met het volgende hogere niveau. Dit proces gaat door totdat de hele applicatiestructuur is bereikt.
Er is geen noodzaak voor stubs in deze aanpak. Het wordt eenvoudiger naarmate de verwerking naar boven gaat en de behoefte aan drivers afneemt. Deze aanpak is aan te raden voor het doen van SIT voor object-georiënteerde systemen, real-time systemen, en systemen met strikte prestatie-eisen.
De beperking van deze aanpak is echter dat het belangrijkste subsysteem, d.w.z. de UI, pas als laatste wordt getest.
#3) Sandwich-benadering:
Hier worden de hierboven besproken top-down- en bottom-upbenaderingen gecombineerd.
Het systeem wordt gezien als bestaande uit drie lagen – de middelste laag die de doellaag is, een laag boven het doel en een laag onder het doel. Het testen gebeurt in beide richtingen en komt samen in de doellaag, die zich in het midden bevindt.
Sandwich-teststrategie
Een voordeel van deze aanpak is dat de bovenste laag en de onderste laag van het systeem parallel kunnen worden getest. De beperking van deze aanpak is echter dat de afzonderlijke subsystemen niet uitputtend worden getest voordat ze worden geïntegreerd.
Om deze beperking op te heffen, hebben we sandwich-testen aangepast, waarbij de integratie van de bovenste, middelste en onderste lagen parallel worden getest met behulp van stubs en drivers.
#4) Big Bang-aanpak:
In deze aanpak wordt de integratie uitgevoerd zodra alle modules van de applicatie volledig gereed zijn. Na de integratie van alle modules wordt getest of het geïntegreerde systeem werkt of niet.
Het is bij deze aanpak een uitdaging om de hoofdoorzaak van het probleem te vinden, omdat alles in één keer wordt geïntegreerd, in tegenstelling tot incrementeel testen. Deze aanpak wordt over het algemeen gevolgd als er maar één SIT-ronde nodig is.
Conclusie
In dit artikel hebben we geleerd wat System Integration Testing (SIT) is en waarom het belangrijk is om het uit te voeren.
We hebben meer geleerd over de kernconcepten, technieken, benaderingen en de methoden die bij het uitvoeren van SIT komen kijken. We hebben ook doorgenomen hoe SIT verschilt van UAT en systeemtesten.
Hoop dat je genoten hebt van dit uitstekende artikel!!