Mi az SIT? Rendszerintegrációs tesztelés példákkal

Mi az a rendszerintegrációs tesztelés?

rendszer Integrációs tesztelés A szoftverteszt egy olyan típusa, amelyet integrált hardver- és szoftverkörnyezetben hajtanak végre a teljes rendszer viselkedésének ellenőrzésére. A tesztelést egy teljes, integrált rendszeren végzik annak értékelésére, hogy a rendszer megfelel-e a meghatározott követelménynek.

A rendszerintegrációs tesztelést (SIT) egy szoftverrendszer moduljai közötti interakciók ellenőrzésére végzik. A szoftverkövetelmény-specifikációban/adatokban és a szoftvertervezési dokumentumban meghatározott magas és alacsony szintű szoftverkövetelmények ellenőrzésével foglalkozik.

Az SIT egy szoftverrendszer másokkal való együttélését is ellenőrzi, és teszteli a szoftveralkalmazás moduljai közötti interfészt. Az ilyen típusú tesztelés során a modulokat először egyenként tesztelik, majd kombinálják egy rendszer létrehozásához. Például a szoftver- és/vagy hardverkomponenseket fokozatosan kombinálják és tesztelik, amíg a teljes rendszer integrálva nem lesz.

A fenti ábra a SIT-et meghatározó folyamatot mutatja: a külön-külön ellenőrzött modulokat lépésről lépésre egyesítik, amíg egyetlen integrált rendszer marad tesztelés alatt.

Miért kell rendszerintegrációs tesztelést végezni?

A szoftverfejlesztésben a rendszerintegrációs tesztelést azért végzik el, mert

• Segít felismerni Disszidál korai
• Korábbi visszajelzések lesznek elérhetők az egyes modulok elfogadhatóságáról
• A hibajavítások ütemezése rugalmas, és átfedhető a fejlesztéssel
• Korrekt adatáramlás
• Megfelelő szabályozási áramlás
• Helyes időzítés
• Megfelelő memóriahasználat
• A szoftverkövetelményeknek megfelelően

Rendszerintegrációs tesztelés vs. rendszertesztelés vs. felhasználói elfogadási tesztelés

Mivel ez a három szint egymás után következik, gyakran összekeverik őket. Rendszer tesztelés egy kész szerkezetet megvizsgál a követelményei alapján, az SIT megvizsgálja a szerkezetek közötti illesztéseket, és Felhasználói elfogadási tesztelés az üzleti fittséget az ügyfél szemszögéből vizsgálja. Az alábbi táblázat elkülöníti őket.

Vizsgált paraméter	Rendszerintegrációs tesztelés	Rendszer tesztelés	Felhasználói elfogadási tesztelés
Elsődleges hangsúly	Integrált modulok közötti interfészek és adatáramlás	Az összeszerelt build viselkedése egészében	Üzleti alkalmasság valós használatra
Tesztelési szint	Második szint	Harmadik szint	Végső szint az éles indulás előtt
Technika	Fekete doboz	Fekete doboz, fehér doboz vagy szürke doboz	Fekete doboz
Előadja	Integrációs tesztelők és fejlesztők	Független tesztcsapat	Ügyfél vagy végfelhasználók
Tipikus hibák	Interfész, időzítés, memória és adattérképping hibákat	Funkcionális és nem funkcionális rendszerhibák	Használhatósági és követelménybeli eltérések
Fut, amikor	Után Egység tesztelése	SIT után	Rendszertesztelés után

A sorrend számít. A modulok sikeresen teljesítik az egységtesztelést, az SIT ellenőrzi az interfészeket, a rendszertesztelés az összeszerelt terméket, az UAT pedig megerősíti, hogy a termék megfelel az üzleti elvárásoknak.ping A SIT az interfészhibákat az UAT-ba tolja, ahol minden javítás sokkal többe kerül.

Hogyan kell elvégezni a rendszerintegrációs tesztelést

Ez egy szisztematikus technika a programstruktúra felépítésére, miközben teszteket végeznek az interfészekkel kapcsolatos hibák feltárására.

Minden modul előre integrálva van, és a teljes program egészét tesztelik. Ám e folyamat során valószínűleg hibák lépnek fel.

Az ilyen hibák kijavítása nehéz, mert az okok elkülönítését bonyolítja a teljes program hatalmas bővítése. Miután ezeket a hibákat kijavították és kijavították, egy új jelenik meg, és a folyamat zökkenőmentesen folytatódik egy végtelen körben. Ennek a helyzetnek az elkerülése érdekében egy másik megközelítést alkalmaznak, az inkrementális integrációt. Az inkrementális megközelítést a következő szakasz részletesen ismerteti.

Létezik néhány növekményes módszer, például az integrációs teszteket a célprocesszoron alapuló rendszeren végzik. Az alkalmazott módszertan az Fekete Box Tesztelés. Alulról felfelé és felülről lefelé történő integráció is használható.

A tesztesetek meghatározása csak a magas szintű szoftverkövetelmények alapján történik.

A szoftverintegráció nagyrészt a gazdagép környezetben is megvalósítható, és a célkörnyezetre jellemző egységeket továbbra is a gazdagépben szimulálják. A megerősítéshez ismételten meg kell ismételni a teszteket a célkörnyezetben.

Az ezen a szinten végzett megerősítő tesztek környezetspecifikus problémákat azonosítanak, például a memória-elosztás és -felszabadítás hibáit. A szoftverintegráció gazdakörnyezetben történő végrehajtásának praktikussága attól függ, hogy mennyi célspecifikus funkcionalitás van jelen. Egyes beágyazott rendszerek esetében a célkörnyezettel való kapcsolat nagyon erős lesz, ami miatt a szoftverintegráció gazdakörnyezetben történő végrehajtása nem praktikus.

A nagy szoftverfejlesztések a szoftverintegrációt több szintre osztják majd. A szoftverintegráció alacsonyabb szintjei túlnyomórészt a gazdakörnyezeten alapulhatnak, a szoftverintegráció későbbi szintjei pedig egyre inkább a célkörnyezettől függenek.

Jegyzet: Ha csak szoftvert tesztelnek, akkor azt szoftverszoftver-integrációs tesztelésnek [SSIT] nevezik, ha pedig hardvert és szoftvert is tesztelnek, akkor azt Hardver szoftverintegrációs tesztelésnek [HSIT] nevezik.

Inkrementális megközelítés

Mivel mindent egyszerre integrálva nehéz a hibákat izolálni, a legtöbb csapat az itt leírt inkrementális utat követi.

A növekményes tesztelés az integrációs tesztelés egyik módja. Az ilyen típusú tesztelési módszernél először a szoftver minden modulját külön-külön teszteljük, majd folytatjuk a tesztelést úgy, hogy más modulokat csatolunk hozzá, majd egy másikat és így tovább.

Az inkrementális integráció az ősrobbanás megközelítésének ellentéte. A program felépítése és tesztelése kis szegmensekben történik, ahol a hibákat könnyebb elkülöníteni és javítani. Az interfészek nagyobb valószínűséggel teljes mértékben tesztelhetők, és szisztematikus tesztelési megközelítés alkalmazható.

A növekményes tesztelésnek két típusa van

• Felülről lefelé irányuló megközelítés
• Alulról felfelé építkező megközelítés

Felülről lefelé irányuló megközelítés

Az ilyen típusú megközelítésben egyénileg csak a felhasználói felület tesztelésével kell kezdeni, a mögöttes funkcionalitást csonkok szimulálásával, majd lefelé haladva az alsó és alsó rétegek integrálásával az alábbi képen látható módon.

• A fő vezérlőmodultól kezdve a modulok a vezérlési hierarchiában lefelé haladva integrálódnak
• A fő vezérlőmodul almoduljai vagy szélesség-első, vagy mélység-első módon vannak beépítve a szerkezetbe.
• A mélységi integráció integrálja az összes modult a struktúra fő vezérlési útvonalán, amint az a következő diagramon látható:

A modulintegrációs folyamat a következő módon történik:

1. A fő vezérlőmodult teszt-illesztőprogramként használják, és a csonkok helyettesítik a fő vezérlőmodulnak közvetlenül alárendelt összes modult.
2. Az alárendelt csonkok egyenként cserélődnek tényleges modulokra a választott megközelítéstől függően (előbb a szélesség vagy a mélység).
3. A tesztek végrehajtása az egyes modulok integrálásakor történik.
4. Minden tesztsorozat befejezésekor egy másik csonkot egy valódi modulra cserélnek az egyes tesztsorozatok befejezésekor
5. Győződjön meg arról, hogy nem vezettek be új hibákat Regressziós teszt elvégezhetők.

A folyamat a 2. lépéstől a teljes programstruktúra felépítéséig folytatódik. A felülről lefelé irányuló stratégia viszonylag egyszerűnek hangzik, de a gyakorlatban logisztikai problémák merülnek fel.

A leggyakoribb ilyen problémák akkor fordulnak elő, ha a hierarchia alacsony szintjein történő feldolgozás szükséges a felső szintek megfelelő teszteléséhez.

A csonkok helyettesítik az alacsony szintű modulokat a felülről lefelé irányuló tesztelés kezdetén, ezért nem áramolhatnak jelentős adatok felfelé a programstruktúrában.

Kihívások, amelyekkel a tesztelő szembesülhet:

• Sok tesztet késleltessen, amíg a csonkokat tényleges modulokra cserélik.
• Olyan csonkok fejlesztése, amelyek korlátozott funkciókat hajtanak végre, amelyek szimulálják a tényleges modult.
• Integrálja a szoftvert a hierarchia aljáról felfelé.

Jegyzet: Az első megközelítés azt eredményezi, hogy elveszítjük az ellenőrzést az egyes tesztek és az egyes modulok beépítése közötti megfelelés felett. Ez nehézségeket okozhat a hibák okának meghatározásában, ami sérti a felülről lefelé irányuló megközelítés erősen korlátozott természetét.

A második megközelítés működőképes, de jelentős többletköltséggel járhat, mivel a csonkok egyre összetettebbé válnak.

Alulról felfelé építkező megközelítés

Az alulról felfelé irányuló integráció megkezdi az építkezést és a tesztelést a programszerkezet legalacsonyabb szintjén lévő modulokkal. Ebben a folyamatban a modulokat alulról felfelé integrálják.

Ebben a megközelítésben az adott szintnek alárendelt modulokhoz szükséges feldolgozás mindig elérhető, és megszűnik a csonkok szükségessége.

Ezt az integrációs tesztfolyamatot négy lépésből álló sorozatban hajtják végre

1. Az alacsony szintű modulokat fürtökké egyesítik, amelyek egy adott szoftver-alfunkciót hajtanak végre.
2. A teszteset bemenetének és kimenetének összehangolására egy illesztőprogramot írnak.
3. A fürt vagy build tesztelve.
4. Az illesztőprogramok eltávolításra kerülnek, és a fürtök kombinálódnak a programstruktúrában felfelé haladva.

Ahogy az integráció felfelé halad, úgy válik szükségessé a különálló tesztvezérlő leckék. Valójában, ha a programstruktúra két legfelső szintjét felülről lefelé integráljuk, a meghajtóprogramok száma jelentősen csökkenthető, és a klaszterek integrációja nagymértékben leegyszerűsödik. Az integráció az alább látható mintát követi.

Jegyzet: Ha a programstruktúra felső két szintjét felülről lefelé integráljuk, akkor az illesztőprogramok száma jelentősen csökkenthető, és a buildek integrálása is jelentősen leegyszerűsödik.

Ősrobbanás megközelítés

Ebben a megközelítésben az összes modul nem integrálódik mindaddig, amíg az összes modul készen nem áll. Ha készen vannak, az összes modult integrálja, majd végrehajtja, hogy megtudja, az összes integrált modul működik-e vagy sem.

Ebben a megközelítésben nehéz megismerni a hiba kiváltó okát, mivel mindent egyszerre kell integrálni.

Emellett nagy az esélye a kritikus hibák előfordulásának az éles környezetben.

Ezt a megközelítést csak akkor alkalmazzák, ha az integrációs tesztelést egyszerre kell elvégezni.

Hardver szoftver integráció tesztelése

Hardver szoftver integráció tesztelése a számítógépes szoftverösszetevők (CSC) tesztelésének folyamata a cél hardverkörnyezet magas szintű funkcionalitása érdekében. A hardver/szoftver integrációs tesztelés célja a hardverkomponensbe integrált fejlesztett szoftver viselkedésének tesztelése.

Követelmény alapú hardver-szoftver integrációs tesztelés

A követelmény alapú hardver/szoftver integrációs tesztelés célja, hogy megbizonyosodjon arról, hogy a célszámítógépen található szoftverek megfelelnek a magas szintű követelményeknek. Az ezzel a vizsgálati módszerrel feltárt tipikus hibák a következők:

• Hardver/szoftver interfész hibák
• A szoftverparticionálás megsértése.
• Képtelenség észlelni a hibákat a beépített teszttel
• Helytelen válasz hardverhibákra
• Szekvenálás, tranziens bemeneti terhelések és bemeneti teljesítmény tranziensek miatti hiba
• A visszacsatolási hurkok helytelen viselkedést mutatnak
• A memóriakezelő hardver helytelen vagy nem megfelelő vezérlése
• Adatbusz-verseny probléma
• A helyszínen betölthető szoftverek kompatibilitását és helyességét ellenőrző mechanizmus helytelen működése

A Hardware Software Integration a magas szintű követelmények ellenőrzésével foglalkozik. Ezen a szinten minden tesztet a célhardveren hajtanak végre.

• A fekete doboz tesztelése az elsődleges tesztelési módszertan ezen a tesztelési szinten.
• Határozza teszt esetek csak a magas szintű követelményektől
• A tesztet gyártási szabványos hardveren kell végrehajtani (a célon)

A HW/SW integráció teszteseteinek tervezésekor figyelembe veendő dolgok

• Az összes adat helyes begyűjtése a szoftver által
• Az elvárásoknak megfelelő méretezés és adattartomány a hardvertől a szoftverig
• Az adatok helyes kimenete a szoftverről a hardverre
• Adatok a specifikáción belül (normál tartomány)
• A specifikációkon kívüli adatok (abnormális tartomány)
• Határadatok
• Megszakítja a feldolgozást
• Időzítés
• Megfelelő memóriahasználat (címzés, átfedések stb.)
• Állapotátmenetek

Jegyzet: A megszakítások teszteléséhez minden megszakítást függetlenül ellenőriznek a kezdeti kéréstől a teljes körű szervizelésig és a befejezésig. A teszteseteket kifejezetten a megszakítások megfelelő tesztelésére tervezik.

Szoftver-szoftverintegrációs tesztelés

Ez a Számítógépes Szoftver Komponens tesztelése a gazda/cél számítógépes környezetben, a teljes rendszer [más CSC-k] szimulációja és a magas szintű funkcionalitás vizsgálata közben.

Egy CSC viselkedésére összpontosít egy szimulált gazda/cél környezetben. A szoftverintegrációhoz használt megközelítés lehet inkrementális megközelítés (felülről lefelé, alulról felfelé vagy a kettő kombinációja, más néven szendvics vagy hibrid megközelítés).

Belépési és kilépési kritériumok az integrációs teszteléshez

Miután a megközelítést és a két integrációs változatot eldöntötték, a fennmaradó kérdés az, hogy mikor kezdheti el és mikor fejezheti be egy csapat a tesztelést. Az integrációs tesztelés során általában az ETVX (belépési kritériumok, feladat, validálás és kilépési kritériumok) stratégiát alkalmazzák.

Belépési kritériumok:

• Befejezése Egység tesztelése

Bemenetek:

• Szoftverkövetelmények adatai
• Szoftver tervezési dokumentum
• Szoftver-ellenőrzési terv
• Szoftverintegrációs dokumentumok

Tevékenységek:

• A Magas és Alacsony szintű követelmények alapján teszteseteket és eljárásokat hoz létre
• Kombinálja az alacsony szintű modulokat, amelyek közös funkcionalitást valósítanak meg
• Készítsen próbaköteget
• Tesztelje az összeállítást
• Miután a teszt sikeresen lezajlott, a buildet kombinálják más buildekkel, és addig tesztelik, amíg a rendszert teljes egészében integrálják.
• Végezze el újra az összes tesztet a célprocesszor-alapú platformon, és szerezze meg az eredményeket

Kilépési kritériumok:

• A Szoftver modul integrációja sikeresen befejeződött a célhardveren
• A szoftver megfelelő működése a megadott követelményeknek megfelelően

Kimenetek

• Integrációs teszt jelentések
• Szoftverteszt-esetek és -eljárások [SVCP].

Gyakori kihívások a rendszerintegrációs tesztelésben

Még egy jól átgondolt megközelítés és egyértelmű kilépési kritériumok esetén is az integrált környezetek olyan problémákat okozhatnak, amelyek az egységtesztelés során soha nem kerülnek felszínre. Ezek korai felismerése reális ütemtervet biztosít.

• Környezeti eltérés: az integrált tesztkörnyezet ritkán tükrözi a gyártási folyamatot, így az időzítési és konfigurációs hibák csak nagyon későn jelentkeznek.
• Függőségi felkészültség: A harmadik féltől származó és a korábbi interfészek gyakran befejezetlenek, így a tesztelők kénytelenek a tervezettnél sokkal tovább támaszkodni a csonkokra és szimulátorokra.
• Adatinkonzisztencia: Két modul ugyanazt a rekordot eltérően ábrázolhatja, ami látható hibák helyett csendes eltéréseket eredményezhet.
• Hiba tulajdonjoga: amikor egy hiba két csapatot érint, a kiváltó ok elemzése és hibakezelés érezhetően lassuljon.
• Regressziós költség: minden új interfész növeli a regressziós teszt csomag, így a manuális újbóli végrehajtás gyorsan fenntarthatatlanná válik.

Ezek többnyire ütemezési kockázatok, nem pedig technikai zsákutcák. Az interfész készültségi dátumainak, a szimulátor hatókörének és a hibák triázsának tulajdonjogának egyeztetése az első build integrálása előtt kiküszöböli ezek nagy részét. A szállító tulajdonában lévő interfészek esetében rögzítse a megállapodott üzenetformátumot és az eszkalációs kapcsolattartót is, mert a hiányzó tulajdonos tovább késlelteti a javítást, mint amennyit a hiba indokolna.

Rendszerintegrációs tesztelés legjobb gyakorlatai

Egy megismételhető SIT ciklus kevésbé függ az eszközöktől, mint inkább a felületek, az adatok és a bizonyítékok körüli fegyelemtől. Az alábbi öt gyakorlat egyformán alkalmas mind a kis beágyazott rendszerek, mind a nagy, több gyártót tartalmazó környezetek számára, és mindegyik csökkenti a későbbi tesztelési szintek eléréséhez szükséges átdolgozást.

1. Először minden interfészt térképezzen fel. Egyetlen teszteset megírása előtt sorold fel az összes adatcserét, azok irányát, protokollját és tulajdonosát.
2. Kockázat szerint rangsoroljon. A kozmetikai jellegű interfészek előtt ellenőrizze a pénzt, személyazonosságot vagy szabályozott adatokat hordozó interfészeket.
3. Tervezzen valósághű tesztadatokat. Fedje le a normál, a határ- és az abnormális tartományokat, hogy a skálázási és kerekítési hibák korán felszínre kerüljenek.
4. Automatizálja a stabil útvonalakat. Vezetékes interfész be- és kikapcsol egy folyamatos integráció folyamat, így minden build újra ellenőrzi őket.
5. Őrizd meg a bizonyítékokat tracehető. Kapcsolja össze az egyes eredményeket egy követelménysel egy tracteljesítőképességi mátrix Tehát a kilépési kritériumok bizonyíthatók, nem állíthatók.

⚠ Tipp: Az integráció megkezdése előtt fagyassza le az interfész specifikációit. Az üzenetformátum késői módosítása érvényteleníti a teszteseteket az interfész mindkét oldalán, és ez a SIT átdolgozásának leggyakoribb oka.

GYIK