Wat is SIT? Systeemintegratietesten met een voorbeeld.

Wat is systeemintegratietesten?

Systeem Integratietesten 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. Er worden tests uitgevoerd op een compleet, geïntegreerd systeem om te beoordelen of het systeem voldoet aan de gespecificeerde vereisten.

Systeemintegratietesten (SIT) worden uitgevoerd om de interacties tussen de modules van een softwaresysteem te verifiëren. Het betreft de verificatie van de softwarevereisten op hoog en laag niveau, zoals gespecificeerd in de softwarevereistenspecificatie/data en het softwareontwerpdocument.

SIT verifieert ook de compatibiliteit van een softwaresysteem met andere systemen en test de interface tussen de modules van de softwareapplicatie. Bij dit type testen worden modules eerst afzonderlijk getest en vervolgens gecombineerd tot een systeem. Software- en/of hardwarecomponenten worden bijvoorbeeld stapsgewijs gecombineerd en getest totdat het volledige systeem is geïntegreerd.

Het bovenstaande diagram toont de voortgang die SIT definieert: afzonderlijk geverifieerde modules worden stap voor stap samengevoegd totdat er één geïntegreerd systeem overblijft dat getest wordt.

Waarom systeemintegratietesten?

Bij Software Engineering wordt systeemintegratietesten gedaan omdat:

• Het helpt bij het detecteren Defect vroeg
• Eerdere feedback over de aanvaardbaarheid van de individuele module zal beschikbaar zijn
• Het plannen van reparaties van defecten is flexibel en kan overlappend zijn met de ontwikkeling
• Correcte gegevensstroom
• Correcte controlestroom
• Correcte timing
• Correct geheugengebruik
• Correct met softwarevereisten

Systeemintegratietesten versus systeemtesten versus gebruikersacceptatietesten

Omdat deze drie niveaus direct op elkaar aansluiten, worden ze vaak door elkaar gehaald. Systeem testen SIT beoordeelt een voltooide constructie aan de hand van de vereisten, terwijl SIT de naden tussen constructies onderzoekt. Gebruikers Acceptatie Testen Het onderzoekt de geschiktheid van een bedrijf vanuit het perspectief van de klant. De onderstaande tabel maakt daar een onderscheid in.

Parameter	Systeemintegratietesten	Systeem testen	Gebruikers Acceptatie Testen
Primaire focus	Interfaces en gegevensstroom tussen geïntegreerde modules	Gedrag van het samengestelde geheel	Geschikt voor zakelijk gebruik in de praktijk
Testniveau	Niveau twee	Niveau drie	Laatste niveau vóór de livegang
Techniek	Zwarte doos	Zwarte doos, witte doos of grijze doos	Zwarte doos
Uitgevoerd door	Integratietesters en ontwikkelaars	Onafhankelijk testteam	Klanten of eindgebruikers
Typische defecten	Interface, timing, geheugen en datakaartping fouten	Functionele en niet-functionele systeemfouten	Mismatch tussen bruikbaarheid en vereisten
Loopt wanneer	Na Testen van een eenheid	Na SIT	Na systeemtesten

De volgorde is belangrijk. Modules doorstaan ​​de unit-tests, SIT bewijst de interfaces, systeemtests bewijzen het geassembleerde product en UAT bevestigt dat het product aan de zakelijke verwachtingen voldoet.ping SIT schuift interfacefouten door naar UAT, waar elke oplossing veel meer kost.

Systeemintegratietesten uitvoeren

Het is een systematische techniek voor het opbouwen van de programmastructuur, waarbij tests worden uitgevoerd om fouten in de interface op te sporen.

Alle modules zijn vooraf geïntegreerd en het hele programma wordt in zijn geheel getest. Maar tijdens dit proces zal er waarschijnlijk een reeks fouten optreden.

Het corrigeren van dergelijke fouten is moeilijk omdat isolatieoorzaken gecompliceerd worden door de enorme uitbreiding van het hele programma. Zodra deze fouten zijn verholpen en gecorrigeerd, zal er een nieuwe verschijnen en gaat het proces naadloos verder in een eindeloze lus. Om deze situatie te voorkomen, wordt een andere aanpak gebruikt: incrementele integratie. De incrementele aanpak wordt in de volgende sectie gedetailleerd uitgelegd.

Er zijn enkele incrementele methoden, zoals de integratietests die worden uitgevoerd op een systeem dat is gebaseerd op de doelprocessor. De gebruikte methodiek is Zwart Box Testen. Zowel bottom-up als top-down integratie kan worden toegepast.

Testgevallen worden uitsluitend 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 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 aan het licht brengen, zoals fouten bij het toewijzen en vrijgeven van geheugen. De praktische uitvoerbaarheid van software-integratie in de hostomgeving hangt af van de hoeveelheid doelspecifieke functionaliteit. Voor sommige embedded systemen is de koppeling met de doelomgeving zeer sterk, waardoor software-integratie in de hostomgeving onpraktisch is.

Grote softwareontwikkelingen zullen software-integratie in een aantal niveaus verdelen. De lagere niveaus van software-integratie kunnen voornamelijk gebaseerd zijn op de hostomgeving, waarbij latere niveaus van software-integratie afhankelijker worden van de doelomgeving.

Let op: Als er alleen software wordt getest, wordt dit Software Software Integration Testing [SSIT] genoemd en als zowel hardware als software worden getest, wordt dit Hardware Software Integration Testing [HSIT] genoemd.

Incrementele aanpak

Omdat het lastig is om defecten te isoleren als alles in één keer wordt geïntegreerd, volgen de meeste teams de hier beschreven stapsgewijze 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, vervolgens nog een module, enzovoort.

Incrementele integratie is het contrast met de big bang-aanpak. Het programma is opgebouwd en getest in kleine segmenten, waar fouten gemakkelijker te isoleren en te corrigeren zijn. Het is waarschijnlijker dat interfaces volledig worden 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 aanpak begint u individueel met het testen van alleen de gebruikersinterface, waarbij de onderliggende functionaliteit wordt gesimuleerd door stubs. 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 gaan in de besturingshiërarchie
• Submodules van de hoofdbesturingsmodule worden in de structuur opgenomen, hetzij in de breedte, hetzij in de diepte.
• Diepte-eerst integratie integreert alle modules op een belangrijk besturingspad van de structuur, zoals weergegeven in het volgende diagram:

Het module-integratieproces verloopt als volgt:

1. De hoofdbesturingsmodule wordt gebruikt als testdriver en de stubs vervangen alle modules die direct ondergeschikt zijn aan de hoofdbesturingsmodule.
2. De ondergeschikte stubs worden één voor één vervangen door daadwerkelijke modules, afhankelijk van de gekozen aanpak (eerst breedte of eerst diepte).
3. Tests worden uitgevoerd terwijl elke module is geïntegreerd.
4. Na voltooiing van elke reeks tests wordt na voltooiing van elke reeks tests een ander stub vervangen door een echte module
5. Om er zeker van te zijn dat er geen nieuwe fouten zijn geïntroduceerd Regressie Testing kan worden uitgevoerd.

Het proces gaat verder 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 hogere niveaus adequaat te testen.

Stubs vervangen modules op laag niveau aan het begin van top-down testen en daarom kunnen er geen significante gegevens naar boven stromen in de programmastructuur.

Uitdagingen waar Tester mee te maken kan krijgen:

• Stel veel tests uit totdat de stubs zijn vervangen door daadwerkelijke modules.
• Ontwikkel stubs die beperkte functies uitvoeren die de daadwerkelijke module simuleren.
• Integreer de software vanaf de onderkant van de hiërarchie naar boven.

Let op: De eerste benadering zorgt ervoor dat we enige controle verliezen over de correspondentie tussen specifieke tests en de integratie van specifieke modules. Dit kan tot gevolg hebben dat het moeilijk wordt de oorzaak van fouten vast te stellen, hetgeen de neiging heeft de zeer beperkte aard van de top-downbenadering te schenden.

De tweede aanpak is werkbaar, maar kan leiden tot aanzienlijke overheadkosten, omdat de stubs steeds complexer worden.

Bottom-up benadering

Bottom-up-integratie begint met het bouwen en testen van 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 noodzaak voor de stubs geëlimineerd.

Dit integratietestproces wordt uitgevoerd in een reeks van vier stappen

1. Laagniveaumodules worden gecombineerd in clusters die een specifieke software-subfunctie uitvoeren.
2. Er is een stuurprogramma geschreven om de invoer en uitvoer van testgevallen te coördineren.
3. Het cluster of de build wordt getest.
4. Drivers worden verwijderd en clusters worden samengevoegd, waarbij ze steeds hoger in de programmastructuur komen.

Naarmate de integratie zich naar boven toe uitbreidt, neemt de behoefte aan aparte testrijders af. Sterker nog, als de twee hoogste niveaus van de programmastructuur van boven naar beneden worden geïntegreerd, kan het aantal testrijders aanzienlijk worden verminderd en wordt de integratie van clusters sterk vereenvoudigd. De integratie volgt het patroon dat hieronder wordt weergegeven.

Let op: 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 builds aanzienlijk vereenvoudigd.

Big Bang-aanpak

Bij deze aanpak worden alle modules pas geïntegreerd als alle modules gereed zijn. Zodra ze klaar zijn, worden alle modules geïntegreerd en vervolgens uitgevoerd om te weten of alle geïntegreerde modules werken of niet.

Bij deze benadering is het moeilijk om de hoofdoorzaak van de mislukking te achterhalen, omdat alles in één keer wordt geïntegreerd.

Ook is de kans groot dat de kritieke bugs in de productieomgeving optreden.

Deze aanpak wordt alleen toegepast als de integratietesten in één keer moeten worden uitgevoerd.

Hardware-software-integratietesten

Hardware-software-integratietesten is een proces waarbij computersoftwarecomponenten (CSC) worden getest op functionaliteit op hoog niveau in de doelhardwareomgeving. Het doel van het testen van hardware/software-integratie is het testen van het gedrag van ontwikkelde software die in de hardwarecomponent is geïntegreerd.

Op vereisten gebaseerde hardware-software-integratietesten

Het doel van op vereisten gebaseerde hardware-/software-integratietests is ervoor te zorgen dat de software op de doelcomputer aan de hoge eisen voldoet. Typische fouten die door deze testmethode aan het licht komen, zijn onder meer:

• Hardware-/software-interfacefouten
• Schendingen van softwarepartitionering.
• Onvermogen om fouten te detecteren door ingebouwde test
• Onjuiste reactie op hardwarestoringen
• Fout als gevolg van sequentiebepaling, transiënte ingangsbelastingen en transiënten van ingangsvermogen
• Feedback leidt tot onjuist gedrag
• Onjuiste of onjuiste controle van hardware voor geheugenbeheer
• Probleem met databusconflicten
• Onjuiste werking van het mechanisme om de compatibiliteit en correctheid van veldlaadbare software te verifiëren

Hardware Software Integratie 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 belangrijkste testmethodologie die op dit testniveau wordt gebruikt.
• Define testgevallen alleen van de vereisten op hoog niveau
• Er moet een test worden uitgevoerd op standaardproductiehardware (on target)

Dingen waarmee u rekening moet houden bij het ontwerpen van testcases voor HW/SW-integratie

• Correcte acquisitie van alle gegevens door de software
• Schaal 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.)
• Staatsovergangen

Let op: Bij het testen van interrupts worden alle interrupts onafhankelijk geverifieerd, vanaf het eerste verzoek tot en met het volledige onderhoud en tot aan de voltooiing. Testgevallen zullen specifiek worden ontworpen om interrupts adequaat te testen.

Software-naar-software-integratietesten

Het betreft het testen van de computersoftwarecomponent die functioneert binnen de host-/doelcomputeromgeving, terwijl het gehele systeem [andere CSC's] en de functionaliteit op hoog niveau worden gesimuleerd.

Het richt zich op het gedrag van een CSC in een gesimuleerde host/target-omgeving. De aanpak die wordt gebruikt voor software-integratie kan een incrementele aanpak zijn (top-down, bottom-up of een combinatie van beide, ook wel de sandwich- of hybride aanpak genoemd).

Ingangs- en uitgangscriteria voor integratietesten

Zodra de aanpak en de twee integratievarianten vaststaan, is de resterende vraag wanneer een team kan beginnen en wanneer het kan stoppen. Bij het uitvoeren van integratietesten wordt doorgaans de ETVX-strategie (Entry Criteria, Task, Validation en Exit Criteria) gebruikt.

Toelatingscriteria:

• Voltooiing van Testen van een eenheid

Ingangen:

• Gegevens over softwarevereisten
• Document voor softwareontwerp
• Softwareverificatieplan
• Software-integratiedocumenten

Activiteiten:

• Op basis van de High en Low-level eisen creëer je testcases en procedures
• Combineer modules op laag niveau die een gemeenschappelijke functionaliteit implementeren
• Ontwikkel een testharnas
• Test de constructie
• 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

Exitcriteria:

• Succesvolle afronding van de integratie van de softwaremodule op de doelhardware
• Correcte werking van de software volgens de gestelde eisen

Resultaten

• Integratietestrapporten
• Softwaretestgevallen en -procedures [SVCP].

Veelvoorkomende uitdagingen bij systeemintegratietesten

Zelfs met een degelijke aanpak en duidelijke exitcriteria creëren geïntegreerde omgevingen problemen die tijdens unit-testen nooit aan het licht komen. Door deze problemen vroegtijdig te herkennen, blijft de planning realistisch.

• Omgevingsmismatch: de geïntegreerde test omgeving Het productieproces komt zelden overeen met de werkelijke situatie, waardoor timing- en configuratiefouten pas in een zeer laat stadium aan het licht komen.
• Bereidheid tot afhankelijkheid: Interfaces van derden en verouderde interfaces zijn vaak onafgewerkt, waardoor testers veel langer dan gepland gebruik moeten maken van stubs en simulatoren.
• Inconsistentie in gegevens: Twee modules kunnen hetzelfde record op verschillende manieren weergeven, waardoor er stille inconsistenties ontstaan ​​in plaats van zichtbare fouten.
• Eigendom van defecten: Wanneer een storing twee teams treft, is een oorzaakanalyse nodig. defectbeheer Vertraag merkbaar.
• Regressiekosten: elke nieuwe interface vergroot de regressietesten suite, waardoor handmatige heruitvoering al snel onhoudbaar wordt.

De meeste van deze problemen betreffen planningsrisico's in plaats van technische doodlopende wegen. Door de gereedheidsdata van de interfaces, de reikwijdte van de simulator en de verantwoordelijkheid voor de afhandeling van defecten vast te leggen vóór de eerste integratie, worden de meeste problemen voorkomen. Voor interfaces die eigendom zijn van de leverancier, is het ook belangrijk om het overeengekomen berichtformaat en een escalatiecontact vast te leggen, omdat een ontbrekende verantwoordelijke de oplossing langer vertraagt ​​dan de aard van het defect rechtvaardigt.

Beste werkwijzen voor systeemintegratietesten

Een herhaalbare SIT-cyclus hangt minder af van de gebruikte tools dan van de discipline rondom interfaces, data en bewijsmateriaal. De vijf onderstaande werkwijzen zijn even geschikt voor een kleine embedded build als voor een grote omgeving met meerdere leveranciers, en elk ervan vermindert de hoeveelheid herwerk die nodig is voor latere testfasen.

1. Breng eerst alle interfaces in kaart. Voordat je ook maar één testcase schrijft, moet je elke gegevensuitwisseling, de richting ervan, het protocol en de eigenaar in kaart brengen.
2. Prioriteer op basis van risico. Controleer eerst de interfaces die geld, identiteitsgegevens of vertrouwelijke informatie verwerken, voordat u de cosmetische interfaces controleert.
3. Ontwerp realistische testgegevens. Bestrijk normale, grens- en afwijkende bereiken, zodat schaal- en afrondingsfouten vroegtijdig aan het licht komen.
4. Automatiseer de stabiele paden. Draadinterface controleert in een continue integratie pipeline zodat elke build ze opnieuw controleert.
5. Bewaar bewijs traceetbaar. Koppel elk resultaat aan een vereiste via een tracgeschiktheidsmatrix De exitcriteria kunnen dus worden bewezen, in plaats van slechts te worden beweerd.

⚠ Tip: Leg de interfacespecificaties vast voordat de integratie begint. Een late wijziging van een berichtformaat maakt testgevallen aan beide zijden van de interface ongeldig en is de meest voorkomende oorzaak van herwerk aan de systeemintegratietests (SIT).

Veelgestelde vragen