Wat is systeemintegratietesten?
System Integration Testing wordt gedefinieerd als een soort softwaretest die wordt uitgevoerd in een geïntegreerde hardware- en softwareomgeving om het gedrag van het volledige systeem te verifiëren. Het zijn tests uitgevoerd op een compleet, geïntegreerd systeem om te beoordelen of het systeem voldoet aan de gespecificeerde vereisten.
System Integration Testing (SIT) wordt uitgevoerd om de interacties tussen de modules van een softwaresysteem te verifiëren. Het behandelt de verificatie van de softwarevereisten op hoog en laag niveau die zijn gespecificeerd in de Software Requirements Specification / Data en het Software Design Document.
Het controleert ook de coëxistentie van een softwaresysteem met anderen en test de interface tussen modules van de softwaretoepassing. Bij dit type testen worden modules eerst afzonderlijk getest en vervolgens gecombineerd om een systeem te maken.
Zo worden software- en / of hardwarecomponenten gecombineerd en progressief getest totdat het hele systeem is geïntegreerd.
In deze tutorial leer je-
- Wat is systeemintegratietesten?
- Waarom systeemintegratietests uitvoeren
- Hoe u een systeemintegratietest uitvoert
- In- en uitstapcriteria voor integratietests
- Testen van hardware naar software-integratie
- Testen van software naar software-integratie
- Top-down benadering
- Bottom-up benadering
- Big Bang-benadering
Waarom systeemintegratietests uitvoeren
In Software Engineering wordt systeemintegratietest gedaan omdat,
- Het helpt om een defect vroegtijdig op te sporen
- Eerdere feedback over de aanvaardbaarheid van de individuele module zal beschikbaar zijn
- Het plannen van foutoplossingen is flexibel en kan worden overlapt met ontwikkeling
- Correcte gegevensstroom
- Correcte stuurstroom
- Juiste timing
- Correct geheugengebruik
- Corrigeer met softwarevereisten
Hoe u een systeemintegratietest uitvoert
Het is een systematische techniek voor het construeren van de programmastructuur tijdens het uitvoeren van tests om fouten te ontdekken die verband houden met interfacing.
Alle modules zijn vooraf geïntegreerd en het hele programma wordt als geheel getest. Maar tijdens dit proces zal er waarschijnlijk een reeks fouten optreden.
Het corrigeren van dergelijke fouten is moeilijk omdat isolerende oorzaken worden bemoeilijkt door de enorme uitbreiding van het hele programma. Zodra deze fouten zijn verholpen en gecorrigeerd, verschijnt er een nieuwe en gaat het proces naadloos verder in een eindeloze lus . Om deze situatie te vermijden, wordt een andere benadering gebruikt, incrementele integratie. We zullen later in de tutorial meer details zien over een incrementele benadering.
Er zijn enkele incrementele methoden, zoals de integratietests die worden uitgevoerd op een systeem dat is gebaseerd op de doelprocessor. De gebruikte methodiek is Black Box Testing. Zowel bottom-up als top-down integratie kan worden gebruikt.
Testgevallen worden alleen gedefinieerd met behulp van de softwarevereisten op hoog niveau.
Software-integratie kan ook grotendeels in de hostomgeving worden bereikt, waarbij eenheden die specifiek zijn voor de doelomgeving nog steeds in de host worden gesimuleerd. Het herhalen van tests in de doelomgeving ter bevestiging zal opnieuw nodig zijn.
Bevestigingstests op dit niveau zullen omgevingsspecifieke problemen identificeren, zoals fouten bij de geheugentoewijzing en de-toewijzing. Of het uitvoeren van software-integratie in de hostomgeving praktisch is, hangt af van de hoeveelheid doelspecifieke functionaliteit die er is. Voor sommige embedded systemen zal de koppeling met de doelomgeving erg sterk zijn, waardoor het onpraktisch wordt om software-integratie in de hostomgeving uit te voeren.
Grote softwareontwikkelingen zullen de software-integratie in een aantal niveaus verdelen. De lagere niveaus van software-integratie zouden voornamelijk in de hostomgeving kunnen worden gebaseerd, waarbij latere niveaus van software-integratie meer afhankelijk worden van de doelomgeving.
Opmerking: als alleen software wordt getest, wordt het Software Software Integration Testing [SSIT] genoemd en als zowel hardware als software wordt getest, wordt het Hardware Software Integration Testing [HSIT] genoemd.
In- en uitstapcriteria voor integratietests
Gewoonlijk wordt tijdens het uitvoeren van integratietests de ETVX-strategie (Entry Criteria, Task, Validation and Exit Criteria) gebruikt.
Toelatingscriteria:
- Afronding van het testen van eenheden
Ingangen:
- Gegevens over softwarevereisten
- Software ontwerpdocument
- Softwareverificatieplan
- Software-integratiedocumenten
Activiteiten:
- Maak op basis van de vereisten op hoog en laag niveau testcases en procedures
- Combineer low-level modules builds die een gemeenschappelijke functionaliteit implementeren
- Ontwikkel een testharnas
- Test de build
- Zodra de test is geslaagd, wordt de build gecombineerd met andere builds en getest totdat het systeem als geheel is geïntegreerd.
- Voer alle tests opnieuw uit op het op de doelprocessor gebaseerde platform en verkrijg de resultaten
Uitgangscriteria:
- Succesvolle afronding van de integratie van de softwaremodule op de doelhardware
- Correcte prestaties van de software volgens de gespecificeerde vereisten
Uitgangen
- Integratie testrapporten
- Software Test Cases en Procedures [SVCP].
Testen van hardware-software-integratie
Hardware Software Integration Testing is een proces waarbij computersoftwarecomponenten (CSC) worden getest op functies op hoog niveau in de doelhardwareomgeving. Het doel van het testen van hardware / software-integratie is om het gedrag te testen van ontwikkelde software die is geïntegreerd in de hardwarecomponent.
Op vereisten gebaseerde hardware-software-integratietests
Het doel van op vereisten gebaseerde hardware / software-integratietests is om ervoor te zorgen dat de software in de doelcomputer voldoet aan de hoge eisen. Typische fouten die door deze testmethode worden onthuld, zijn onder meer:
- Fouten in hardware / software-interfaces
- Overtredingen van softwarepartitionering.
- Onvermogen om fouten te detecteren door een ingebouwde test
- Onjuiste reactie op hardwarestoringen
- Fout als gevolg van sequencing, transiënte ingangsbelastingen en ingangsvermogenstransiënten
- Feedback lussen onjuist gedrag
- Onjuiste of onjuiste controle van geheugenbeheerhardware
- Probleem met gegevensbusconflict
- Onjuiste werking van het mechanisme om de compatibiliteit en juistheid van in het veld laadbare software te verifiëren
Hardware Software Integration houdt zich bezig met de verificatie van de vereisten op hoog niveau. Alle tests op dit niveau worden uitgevoerd op de doelhardware.
- Black box-testen is de primaire testmethodologie die op dit testniveau wordt gebruikt.
- Definieer testcases alleen op basis van de vereisten op hoog niveau
- Er moet een test worden uitgevoerd op standaard productiehardware (on target)
Dingen om te overwegen bij het ontwerpen van testcases voor HW / SW-integratie
- Correcte acquisitie van alle gegevens door de software
- Schalen en bereik van gegevens zoals verwacht van hardware tot software
- Correcte uitvoer van gegevens van software naar hardware
- Gegevens binnen specificaties (normaal bereik)
- Gegevens buiten specificaties (abnormaal bereik)
- Grensgegevens
- Onderbreekt de verwerking
- Timing
- Correct geheugengebruik (adressering, overlappingen, etc.)
- Overgangen van staten
Opmerking: voor het testen van onderbrekingen worden alle onderbrekingen onafhankelijk van het eerste verzoek tot volledig onderhoud en na voltooiing geverifieerd. Testcases worden specifiek ontworpen om interrupts adequaat te testen.
Testen van software naar software-integratie
Het is het testen van de computersoftwarecomponent die binnen de host- / doelcomputer werkt
Omgeving, terwijl het hele systeem [andere CSC's] wordt gesimuleerd, en op hoog niveau.
Het richt zich op het gedrag van een CSC in een gesimuleerde host / doelomgeving. De benadering die wordt gebruikt voor software-integratie kan een incrementele benadering zijn (top-down, een bottom-up benadering of een combinatie van beide).
Incrementele aanpak
Incrementeel testen is een manier van integratietesten. Bij dit type testmethode test u eerst elke module van de software afzonderlijk en gaat u vervolgens verder met testen door er andere modules aan toe te voegen, dan nog een, enzovoort.
Incrementele integratie is het contrast met de oerknalbenadering. Het programma is opgebouwd en getest in kleine segmenten, waar fouten gemakkelijker te isoleren en corrigeren zijn. Interfaces worden eerder volledig getest en er kan een systematische testaanpak worden toegepast.
Er zijn twee soorten incrementele tests
- Top-down benadering
- Bottom-up benadering
Top-down benadering
Bij dit type benadering begint de persoon met het testen van alleen de gebruikersinterface, waarbij de onderliggende functionaliteit wordt gesimuleerd door stubs, en vervolgens gaat u naar beneden en integreert u lagere en lagere lagen, zoals weergegeven in de onderstaande afbeelding.
- Beginnend met de hoofdbesturingsmodule, worden de modules geïntegreerd door naar beneden te bewegen door de besturingshiërarchie
- Submodules van de hoofdbesturingsmodule zijn ofwel in de breedte eerst ofwel op de diepte eerst in de structuur opgenomen.
- Diepte-eerst integratie integreert alle modules op een belangrijk controlepad van de structuur, zoals weergegeven in het volgende diagram:
Het module-integratieproces verloopt op de volgende manier:
- De hoofdbesturingsmodule wordt gebruikt als teststuurprogramma en de stubs worden vervangen door alle modules die direct ondergeschikt zijn aan de hoofdbesturingsmodule.
- De ondergeschikte stompjes worden één voor één vervangen door daadwerkelijke modules, afhankelijk van de gekozen benadering (breedte eerst of diepte eerst).
- Er worden tests uitgevoerd terwijl elke module is geïntegreerd.
- Na voltooiing van elke reeks tests, wordt een andere stomp vervangen door een echte module na voltooiing van elke reeks tests
- Om er zeker van te zijn dat er geen nieuwe fouten zijn geïntroduceerd, kan regressietest worden uitgevoerd.
Het proces gaat door vanaf stap 2 totdat de volledige programmastructuur is opgebouwd. De top-down strategie klinkt relatief ongecompliceerd, maar in de praktijk doen zich logistieke problemen voor.
De meest voorkomende van deze problemen doen zich voor wanneer verwerking op lage niveaus in de hiërarchie vereist is om de bovenste niveaus adequaat te testen.
Stubs vervangen low-level modules aan het begin van top-down testen en daarom kunnen er geen significante gegevens naar boven stromen in de programmastructuur.
Uitdagingen waarmee de tester te maken kan krijgen:
- Stel veel tests uit totdat stubs zijn vervangen door daadwerkelijke modules.
- Ontwikkel stubs die beperkte functies uitvoeren die de feitelijke module simuleren.
- Integreer de software vanaf de onderkant van de hiërarchie naar boven.
Opmerking: de eerste benadering zorgt ervoor dat we enige controle verliezen over de correspondentie tussen specifieke tests en het opnemen van specifieke modules. Dit kan resulteren in het moeilijk bepalen van de oorzaak van fouten die de zeer beperkte aard van de top-down benadering schenden.
De tweede benadering is werkbaar, maar kan tot aanzienlijke overhead leiden, aangezien stubs steeds complexer worden.
Bottom-up benadering
Bottom-up integratie begint met bouwen en testen met modules op het laagste niveau in de programmastructuur. Hierbij worden de modules van onder naar boven geïntegreerd.
Bij deze benadering is de verwerking die vereist is voor de modules die ondergeschikt zijn aan een bepaald niveau altijd beschikbaar en wordt de behoefte aan stubs geëlimineerd.
Dit integratietestproces wordt uitgevoerd in een reeks van vier stappen
- Low-level modules worden gecombineerd tot clusters die een specifieke softwaresubfunctie vervullen.
- Er wordt een driver geschreven om de invoer en uitvoer van testgevallen te coördineren.
- Het cluster of build wordt getest.
- Drivers worden verwijderd en clusters worden gecombineerd naar boven in de programmastructuur.
Naarmate de integratie toeneemt, is de behoefte aan afzonderlijke lessen voor testrijders. Als de bovenste twee niveaus van de programmastructuur van bovenaf worden geïntegreerd, kan het aantal drijfveren aanzienlijk worden verminderd en wordt de integratie van clusters aanzienlijk vereenvoudigd. De integratie volgt het hieronder geïllustreerde patroon. Naarmate de integratie toeneemt, is de behoefte aan aparte lessen voor testrijders.
Opmerking: als de bovenste twee niveaus van de programmastructuur Top-down zijn geïntegreerd, kan het aantal stuurprogramma's aanzienlijk worden verminderd en wordt de integratie van builds aanzienlijk vereenvoudigd.
Big Bang-benadering
Bij deze benadering worden pas alle modules geïntegreerd als alle modules gereed zijn. Zodra ze klaar zijn, worden alle modules geïntegreerd en vervolgens wordt het uitgevoerd om te weten of alle geïntegreerde modules werken of niet.
Bij deze benadering is het moeilijk om de hoofdoorzaak van de storing te achterhalen doordat alles in één keer wordt geïntegreerd.
Ook is er een grote kans op het optreden van de kritieke bugs in de productieomgeving.
Deze benadering wordt alleen toegepast als integratietests in één keer moeten worden uitgevoerd.
Overzicht:
- Integratie wordt uitgevoerd om de interacties tussen de modules van een softwaresysteem te verifiëren. Het helpt om een defect vroegtijdig op te sporen
- Integratietesten kunnen worden gedaan voor hardware-software of hardware-hardware-integratie
- Integratietesten worden op twee manieren gedaan
- Incrementele aanpak
- Oerknal benadering
- Bij het uitvoeren van integratietests wordt over het algemeen de ETVX-strategie (Entry Criteria, Task, Validation and Exit Criteria) gebruikt.