Mis on SIT? Süsteemide integreerimise testimine näitega

Mis on süsteemiintegratsiooni testimine?

süsteem Integratsiooni testimine on määratletud kui tarkvara testimise tüüp, mis viiakse läbi integreeritud riist- ja tarkvarakeskkonnas, et kontrollida kogu süsteemi käitumist. Seda testitakse tervikliku integreeritud süsteemiga, et hinnata süsteemi vastavust selle kindlaksmääratud nõuetele.

Süsteemide integreerimise testimine (SIT) teostatakse tarkvarasüsteemi moodulite vahelise interaktsiooni kontrollimiseks. See tegeleb tarkvaranõuete spetsifikatsioonis/andmetes ja tarkvara projekteerimisdokumendis määratletud kõrge ja madala taseme tarkvaranõuete kontrollimisega.

SIT kontrollib ka tarkvarasüsteemi kooseksisteerimist teistega ja testib tarkvararakenduse moodulite vahelist liidest. Seda tüüpi testimisel testitakse mooduleid esmalt eraldi ja seejärel ühendatakse süsteemiks. Näiteks tarkvara- ja/või riistvarakomponente kombineeritakse ja testitakse järk-järgult, kuni kogu süsteem on integreeritud.

Ülaltoodud diagramm näitab SIT-i määratlevat progresseerumist: eraldi verifitseeritud mooduleid ühendatakse samm-sammult, kuni testimiseks jääb alles üks integreeritud süsteem.

Miks süsteemiintegratsiooni testida?

Tarkvaratehnikas tehakse süsteemiintegratsiooni testimine, kuna

• See aitab tuvastada Defekt varajane
• Saadaval on varasem tagasiside üksiku mooduli vastuvõetavuse kohta
• Defektide parandamise ajastamine on paindlik ja seda saab arendusega kattuda
• Õige andmevoog
• Õige juhtvool
• Õige ajastus
• Õige mälukasutus
• Tarkvaranõuetega korrektne

Süsteemiintegratsiooni testimine vs süsteemitestimine vs kasutaja aktsepteerimistestimine

Kuna need kolm tasandit kulgevad omavahel tihedalt koos, aetakse neid sageli segi. Süsteemi testimine uurib ühe valmis ehitise vastavust selle nõuetele, SIT uurib ehitistevahelisi õmblusi ja Vastuvõtu test uurib ettevõtte sobivust kliendi vaatenurgast. Allolev tabel eristab neid.

Parameeter	Süsteemiintegratsiooni testimine	Süsteemi testimine	Vastuvõtu test
Esmane fookus	Liidesed ja andmevoog integreeritud moodulite vahel	Kokkupandud konstruktsiooni käitumine tervikuna	Äriline sobivus reaalseks kasutamiseks
Testimise tase	Teine tase	Kolmas tase	Lõplik tase enne avaldamist
Tehnika	Must kast	Must kast, valge kast või hall kast	Must kast
Esitab	Integratsioonitestijad ja arendajad	Sõltumatu testimismeeskond	Klient või lõppkasutajad
Tüüpilised defektid	Liides, ajastus, mälu ja andmekaartping vigu	Funktsionaalsed ja mittefunktsionaalsed süsteemivead	Kasutatavuse ja nõuete mittevastavus
Töötab siis, kui	pärast Üksuse testimine	Pärast SIT-i	Pärast süsteemi testimist

Järjekord on oluline. Moodulid läbivad ühiktestimise, SIT kinnitab liideste toimimist, süsteemitestimine kinnitab kokkupandud toote toimimist ja UAT kinnitab, et toode vastab äriootustele.ping SIT lükkab liidesevead UAT-i, kus iga paranduse tegemine maksab palju rohkem.

Kuidas teha süsteemiintegratsiooni testimist

See on süstemaatiline tehnika programmi struktuuri konstrueerimiseks, tehes samal ajal teste liidestusega seotud vigade avastamiseks.

Kõik moodulid on eelnevalt integreeritud ja kogu programmi testitakse tervikuna. Kuid selle protsessi käigus ilmneb tõenäoliselt rida vigu.

Selliste vigade parandamine on keeruline, kuna põhjuste eraldamist raskendab kogu programmi ulatuslik laienemine. Kui need vead on parandatud ja parandatud, ilmub uus viga ja protsess jätkub sujuvalt lõputus tsüklis. Selle olukorra vältimiseks kasutatakse teist lähenemisviisi – astmelist integreerimist. Järkjärgulist lähenemisviisi selgitatakse üksikasjalikumalt järgmises osas.

On mõned järkjärgulised meetodid, näiteks integratsioonitestid viiakse läbi sihtprotsessoril põhinevas süsteemis. Kasutatud metoodika on Must Box Testimine. Kasutada saab kas alt-üles või ülalt-alla integreerimist.

Testjuhtumite määratlemisel kasutatakse ainult kõrgetasemelisi tarkvaranõudeid.

Tarkvara integreerimine võib toimuda suures osas ka hostkeskkonnas, kusjuures sihtkeskkonnale omaseid üksusi simuleeritakse jätkuvalt hostis. Kinnituse saamiseks on vaja uuesti testida sihtkeskkonnas.

Sellel tasemel tehtavad kinnitustestid tuvastavad keskkonnaspetsiifilisi probleeme, näiteks mälu eraldamise ja vabastamise vigu. Tarkvara integreerimise praktilisus peremeeskeskkonnas sõltub sellest, kui palju sihtkeskkonnale omast funktsionaalsust on. Mõnede manussüsteemide puhul on seos sihtkeskkonnaga väga tugev, mistõttu on tarkvara integreerimine peremeeskeskkonnas ebapraktiline.

Suured tarkvaraarendused jagavad tarkvara integreerimise mitmeks tasandiks. Tarkvara integreerimise madalamad tasemed võiksid põhineda valdavalt hostkeskkonnal, kusjuures hilisemad tarkvaraintegratsiooni tasemed muutuvad sihtkeskkonnast enam sõltuvaks.

Märge: Kui testitakse ainult tarkvara, nimetatakse seda tarkvara tarkvara integratsiooni testimiseks [SSIT] ja kui testitakse nii riistvara kui ka tarkvara, nimetatakse seda riistvara tarkvara integratsiooni testimiseks [HSIT].

Inkrementaalne lähenemine

Kuna kõige korraga integreerimine muudab defektide isoleerimise raskeks, järgivad enamik meeskondi siin kirjeldatud järkjärgulist teed.

Inkrementaalne testimine on integratsioonitestimise viis. Seda tüüpi testimismeetodi puhul testite esmalt iga tarkvara moodulit eraldi ja seejärel jätkate testimist, lisades sellele teised moodulid, seejärel veel ühe ja nii edasi.

Inkrementaalne integratsioon on kontrast suure paugu lähenemisviisile. Programm on üles ehitatud ja testitud väikestes segmentides, kus vigu on lihtsam eraldada ja parandada. Suure tõenäosusega testitakse liideseid täielikult ja võib kasutada süstemaatilist testimisviisi.

Inkrementaalset testimist on kahte tüüpi

• Ülevalt alla lähenemine
• Alt-üles lähenemine

Ülalt-alla lähenemine

Seda tüüpi lähenemisviisi puhul alustatakse individuaalselt ainult kasutajaliidese testimisega, mille aluseks olevad funktsioonid on simuleeritud tünnidega, seejärel liigute allapoole, integreerides madalamad ja madalamad kihid, nagu on näidatud alloleval pildil.

• Alustades peamisest juhtimismoodulist, integreeritakse moodulid juhthierarhias allapoole liikudes
• Põhijuhtmooduli alammoodulid on konstruktsiooni integreeritud kas laiuse-eelis- või sügavuspõhimõttel.
• Sügavus-esimene integreerimine integreerib kõik moodulid struktuuri peamises juhtrajas, nagu on näidatud järgmisel diagrammil:

Mooduli integreerimise protsess toimub järgmisel viisil:

1. Peamist juhtmoodulit kasutatakse testdraiverina ja tünnid asendatakse kõigi põhijuhtimismoodulile vahetult alluvate moodulitega.
2. Alluvad tünnid asendatakse ükshaaval tegelike moodulitega olenevalt valitud lähenemisest (laius enne või sügavus enne).
3. Testid teostatakse iga mooduli integreerimisel.
4. Iga testikomplekti lõpetamisel asendatakse iga testikomplekti lõpetamisel veel üks tünn pärismooduliga
5. Veendumaks, et uusi vigu pole sisse toodud Regressioonitestimine võib läbi viia.

Protsess jätkub etapist 2 kuni kogu programmistruktuuri loomiseni. Ülalt-alla strateegia tundub suhteliselt lihtne, kuid praktikas tekivad logistilised probleemid.

Kõige levinumad neist probleemidest ilmnevad siis, kui hierarhia madalatel tasanditel on vaja töötlemist, et ülemiste tasemete adekvaatseks testimiseks.

Stubid asendavad madala taseme mooduleid ülalt-alla testimise alguses ja seetõttu ei saa programmi struktuuris olulisi andmeid ülespoole voolata.

Väljakutsed, millega testija võib silmitsi seista:

• Viivitage paljud testid, kuni tünnid asendatakse tegelike moodulitega.
• Töötage välja tünnid, mis täidavad piiratud funktsioone, mis simuleerivad tegelikku moodulit.
• Integreerige tarkvara hierarhia alt ülespoole.

Märge: Esimese lähenemisviisi korral kaotame teatud kontrolli konkreetsete testide vastavuse ja konkreetsete moodulite lisamise üle. See võib põhjustada raskusi vigade põhjuste kindlaksmääramisel, mis kipub rikkuma ülalt-alla lähenemisviisi väga piiratud olemust.

Teine lähenemisviis on toimiv, kuid võib tuua kaasa märkimisväärseid üldkulusid, kuna tünnid muutuvad üha keerukamaks.

Alt-üles lähenemine

Alt-üles integreerimine alustab ehitamist ja testimist programmi struktuuri madalaimal tasemel moodulitega. Selle protsessi käigus integreeritakse moodulid alt üles.

Selle lähenemisviisi korral on antud tasemele alluvate moodulite jaoks vajalik töötlemine alati saadaval ja stubide vajadus on välistatud.

See integratsioonitesti protsess viiakse läbi nelja etapina

1. Madala taseme moodulid ühendatakse klastriteks, mis täidavad kindlat tarkvara alamfunktsiooni.
2. Draiver on kirjutatud testjuhtumi sisendi ja väljundi koordineerimiseks.
3. Klastrit või ehitust testitakse.
4. Draiverid eemaldatakse ja klastrid kombineeritakse programmi struktuuris ülespoole liikudes.

Integratsiooni ülespoole liikudes on vaja eraldi testidraiverite tunde. Tegelikult, kui programmi struktuuri kaks ülemist taset integreerida ülalt-alla, saab draiverite arvu oluliselt vähendada ja klastrite integreerimine lihtsustub oluliselt. Integratsioon järgib allpool illustreeritud mustrit.

Märge: Kui programmistruktuuri kaks ülemist taset on integreeritud ülalt alla, saab draiverite arvu oluliselt vähendada ja järgu integreerimine on oluliselt lihtsustatud.

Suure Paugu lähenemine

Selle lähenemisviisi puhul ei integreerita kõiki mooduleid enne, kui kõik moodulid on valmis. Kui need on valmis, integreeritakse kõik moodulid ja seejärel käivitatakse see, et teada saada, kas kõik integreeritud moodulid töötavad või mitte.

Selle lähenemisviisi puhul on kõike korraga integreerimise tõttu raske teada tõrke algpõhjust.

Samuti on tootmiskeskkonnas kriitiliste vigade esinemise tõenäosus suur.

Seda lähenemisviisi kasutatakse ainult siis, kui integratsiooni testimine tuleb läbi viia korraga.

Riistvara tarkvara integratsiooni testimine

Riistvara tarkvara integratsiooni testimine on arvutitarkvara komponentide (CSC) testimise protsess sihtriistvarakeskkonna kõrgetasemeliste funktsionaalsuste jaoks. Riistvara/tarkvara integratsiooni testimise eesmärk on testida riistvarakomponendile integreeritud arendatud tarkvara käitumist.

Nõuetepõhine riistvara-tarkvara integratsiooni testimine

Nõudepõhise riistvara/tarkvara integratsiooni testimise eesmärk on veenduda, et sihtarvutis olev tarkvara vastab kõrgetasemelistele nõuetele. Selle testimismeetodiga leitud tüüpilised vead hõlmavad järgmist:

• Riistvara/tarkvara liideste vead
• Tarkvara partitsioonide rikkumised.
• Suutmatus tuvastada rikkeid sisseehitatud testiga
• Vale reageerimine riistvaratõrgetele
• Viga, mis on tingitud järjestamisest, mööduvatest sisendkoormustest ja sisendvõimsuse siirdehäiretest
• Tagasiside loob vale käitumise
• Mäluhaldusriistvara vale või vale juhtimine
• Andmesiini konkurentsiprobleem
• Väljalaaditava tarkvara ühilduvuse ja õigsuse kontrollimise mehhanismi vale töö

Riistvaratarkvara integratsioon tegeleb kõrgetasemeliste nõuete kontrollimisega. Kõik selle taseme testid viiakse läbi sihtriistvaraga.

• Musta kasti testimine on sellel testimise tasemel kasutatav esmane testimismetoodika.
• Määratle testjuhtumid ainult kõrgetasemeliste nõuete järgi
• Test tuleb läbi viia standardse tootmisriistvaraga (sihtkohal)

Asjad, mida tuleb HW/SW integratsiooni testjuhtumite kavandamisel arvestada

• Kõigi andmete õige hankimine tarkvara poolt
• Andmete skaleerimine ja ulatus vastavalt ootustele riistvarast tarkvarani
• Andmete korrektne väljastamine tarkvarast riistvarasse
• Andmed spetsifikatsioonide piires (tavaline vahemik)
• Andmed väljaspool tehnilisi andmeid (ebanormaalne vahemik)
• Piiriandmed
• Katkestab töötlemist
• Ajastamine
• Õige mälukasutus (adresseerimine, kattuvused jne)
• Olekute üleminekud

Märge: Katkestuste testimiseks kontrollitakse kõiki katkestusi sõltumatult alates esialgsest taotlusest kuni täieliku teeninduse ja lõpetamiseni. Katkestuste adekvaatseks testimiseks kavandatakse katsejuhtumid spetsiaalselt.

Tarkvara integratsiooni testimine

See on arvutitarkvara komponendi testimine host-/sihtarvuti keskkonnas, simuleerides samal ajal kogu süsteemi [teiste CSC-de] ja selle kõrgetasemelist funktsionaalsust.

See keskendub tarkvarakeskse keskseadme käitumisele simuleeritud host/sihtkeskkonnas. Tarkvara integreerimiseks kasutatav lähenemisviis võib olla astmeline lähenemisviis (ülalt-alla, alt-üles lähenemisviis või mõlema kombinatsioon, mida nimetatakse ka võileiva- või hübriidlähenemiseks).

Integratsioonitesti sisenemise ja väljumise kriteeriumid

Kui lähenemisviis ja kaks integratsioonivarianti on paigas, jääb alles küsimus, millal meeskond võib alustada ja millal lõpetada. Tavaliselt kasutatakse integratsioonitestimise ajal ETVX-strateegiat (Entry Criteria, Task, Validation ja Exit Criteria).

Sisenemise kriteeriumid:

• Lõpetamine Üksuse testimine

Sisendid:

• Tarkvaranõuete andmed
• Tarkvara disaini dokument
• Tarkvara kinnitamise plaan
• Tarkvara integreerimise dokumendid

Tegevus:

• Kõrge ja madala taseme nõuete alusel looge testjuhtumid ja -protseduurid
• Kombineerige madala taseme mooduleid, mis rakendavad ühist funktsiooni
• Töötage välja testrihmad
• Testige ehitust
• Kui test on läbitud, kombineeritakse järg teiste järgudega ja testitakse, kuni süsteem on tervikuna integreeritud.
• Käivitage kõik testid sihtprotsessoripõhisel platvormil uuesti ja hankige tulemused

Väljumiskriteeriumid:

• Tarkvaramooduli sihtriistvaraga integreerimise edukas lõpuleviimine
• Tarkvara õige toimimine vastavalt määratud nõuetele

Väljundid

• Integratsioonitesti aruanded
• Tarkvara testimise juhtumid ja protseduurid [SVCP].

Süsteemide integreerimise testimise tavalised väljakutsed

Isegi hea lähenemisviisi ja selgete väljumiskriteeriumide korral tekitavad integreeritud keskkonnad probleeme, mis ühiktestimise käigus esile ei tule. Nende varajane äratundmine hoiab ajakava realistliku.

• Keskkonna mittevastavus: integreeritud testimiskeskkond peegeldab harva tootmist, seega ajastus- ja konfiguratsioonivead ilmnevad väga hilja.
• Sõltuvusvalmidus: Kolmandate osapoolte ja pärandliidesed on sageli lõpetamata, sundides testijaid lootma tüvedele ja simulaatoritele palju kauem kui plaanitud.
• Andmete ebajärjekindlus: Kaks moodulit võivad sama kirjet erinevalt esitada, tekitades nähtavate tõrgete asemel vaikseid mittevastavusi.
• Defekti omandiõigus: Kui ebaõnnestumine hõlmab kahte meeskonda, tehakse algpõhjuse analüüs ja defektide haldamine märgatavalt aeglustada.
• Regressioonikulu: iga uus liides suurendab regressioonitest komplekt, seega muutub käsitsi uuesti käivitamine kiiresti jätkusuutmatuks.

Enamik neist on pigem ajakavaga seotud riskid kui tehnilised ummikteed. Liidese valmimiskuupäevade, simulaatori ulatuse ja defektide triaaži omaniku kokkuleppimine enne esimese versiooni integreerimist kõrvaldab enamiku neist. Tarnija omanduses olevate liideste puhul registreerige ka kokkulepitud sõnumivorming ja eskalatsioonikontakt, sest puuduv omanik lükkab parandust kauem kui defekt ette näeb.

Süsteemide integreerimise testimise parimad tavad

Korduv SIT-tsükkel sõltub vähem tööriistadest kui liideste, andmete ja tõenditega seotud distsipliinist. Allpool toodud viis tava sobivad võrdselt nii väikesele manussüsteemile kui ka suurele mitme müüjaga maastikule ning igaüks neist vähendab hilisemate testimistasemete saavutamiseks vajalikku ümbertöötamist.

1. Kaardista iga liides kõigepealt. Enne ühe testi kirjutamist loetlege iga andmevahetus, selle suund, protokoll ja omanik.
2. Prioriseeri riski järgi. Enne kosmeetiliste liideste kontrollimist kontrollige raha, identiteedi või reguleeritud andmeid edastavaid liideseid.
3. Kujunda realistlikud testandmed. Kata normaal-, piir- ja ebanormaalsed vahemikud, et skaleerimis- ja ümardamisvead varakult esile kerkiksid.
4. Automatiseerige stabiilsed teed. Juhtmeline liides kontrollib a-d pidev integratsioon torujuhe, seega iga ehitus kontrollib neid uuesti.
5. Hoidke tõendeid tracsuutlikkust Seo iga tulemus nõudega läbi tracvõimekusmaatriks Seega saab väljumiskriteeriume tõestada, mitte väita.

⚠ Näpunäide: Külmuta liidese spetsifikatsioonid enne integreerimise algust. Sõnumivormingu hiline muutmine muudab testid liidese mõlemal poolel kehtetuks ja on SIT-i ümbertöötamise kõige levinum põhjus.

KKK