Kas yra sistemos integravimo testavimas?
Sistemos integravimo testavimas apibrėžiamas kaip programinės įrangos testavimo tipas, atliekamas integruotoje aparatinės ir programinės įrangos aplinkoje, siekiant patikrinti visos sistemos veikimą. Tai bandymai, atliekami su visa integruota sistema, siekiant įvertinti sistemos atitiktį jos nurodytam reikalavimui.
Sistemos integracijos testavimas (SIT) atliekamas siekiant patikrinti programinės įrangos sistemos modulių sąveiką. Ji nagrinėja aukšto ir žemo lygio programinės įrangos reikalavimus, nurodytus programinės įrangos reikalavimų specifikacijoje / duomenyse ir programinės įrangos projektavimo dokumente.
Jis taip pat patikrina programinės įrangos sistemos sambūvį su kitais ir išbando sąsają tarp programinės įrangos modulių. Tokio tipo bandymuose moduliai pirmiausia išbandomi atskirai, o tada sujungiami, kad būtų sukurta sistema.
Pavyzdžiui, programinės ir (arba) aparatinės įrangos komponentai yra derinami ir išbandomi palaipsniui, kol bus integruota visa sistema.
Šioje pamokoje sužinosite
- Kas yra sistemos integravimo testavimas?
- Kodėl reikia atlikti sistemos integravimo testavimą
- Kaip atlikti sistemos integravimo testavimą
- Integracijos testavimo įėjimo ir išėjimo kriterijai
- Aparatinės ir programinės įrangos integravimo testavimas
- Programinė įranga programinės įrangos integravimo testavimui
- Metodas iš viršaus į apačią
- Metodas iš apačios į viršų
- Didžiojo sprogimo požiūris
Kodėl reikia atlikti sistemos integravimo testavimą
Programinės įrangos inžinerijos srityje sistemos integravimo bandymai atliekami, nes
- Tai padeda anksti aptikti defektą
- Bus galima gauti ankstesnį atsiliepimą apie individualaus modulio priimtinumą
- Defektų taisymų planavimas yra lankstus ir gali būti persidengęs su plėtra
- Teisingas duomenų srautas
- Teisingas valdymo srautas
- Teisingas laikas
- Teisingas atminties naudojimas
- Taisykite pagal programinės įrangos reikalavimus
Kaip atlikti sistemos integravimo testavimą
Tai sisteminga programos struktūros sukūrimo technika atliekant bandymus, siekiant atskleisti klaidas, susijusias su sąsaja.
Visi moduliai yra integruoti iš anksto, o visa programa yra išbandyta kaip visuma. Tačiau šio proceso metu greičiausiai susiduriama su klaidų rinkiniu.
Tokias klaidas sunku ištaisyti, nes izoliacijos priežastis apsunkina didžiulis visos programos išplėtimas. Kai šios klaidos bus ištaisytos ir ištaisytos, pasirodys nauja, o procesas tęsiasi sklandžiai nesibaigiančioje linijoje . Norėdami išvengti šios situacijos, naudojamas kitas metodas - „Inkrementinė integracija“. Išsamesnę informaciją apie laipsnišką požiūrį pamatysime vėliau pamokoje.
Yra keletas papildomų metodų, pavyzdžiui, integracijos bandymai atliekami sistemoje, pagrįstoje tiksliniu procesoriumi. Naudojama metodika yra juodosios dėžės testavimas. Galima naudoti integraciją iš apačios į viršų arba iš viršaus į apačią.
Testiniai atvejai apibrėžiami tik naudojant aukšto lygio programinės įrangos reikalavimus.
Programinės įrangos integracija taip pat gali būti pasiekta daugiausia pagrindinėje aplinkoje, o pagrindiniame kompiuteryje ir toliau imituojami tikslinei aplinkai būdingi vienetai. Norint patvirtinti, pakartoti bandymus tikslinėje aplinkoje vėl reikės.
Patvirtinimo testai šiame lygyje nustatys specifines aplinkai problemas, tokias kaip atminties paskirstymo ir paskirstymo panaikinimo klaidos. Programinės įrangos integravimo pagrindinėje aplinkoje praktiškumas priklausys nuo to, kiek yra tikslinių funkcijų. Kai kurioms įterptosioms sistemoms susiejimas su tiksline aplinka bus labai stiprus, todėl bus nepraktiška atlikti programinės įrangos integravimą pagrindinėje aplinkoje.
Didelė programinės įrangos plėtra padalins programinės įrangos integraciją į keletą lygių. Žemesni programinės įrangos integravimo lygiai galėtų būti pagrįsti pagrindinėje aplinkoje, o vėlesni programinės įrangos integravimo lygiai tampa labiau priklausomi nuo tikslinės aplinkos.
Pastaba: jei bandoma tik programinė įranga, ji vadinama programinės įrangos programinės įrangos integravimo testavimu [SSIT], o jei tikrinama ir aparatinė, ir programinė įranga, vadinama aparatinės įrangos programinės įrangos integravimo testavimu [HSIT].
Integracijos testavimo įėjimo ir išėjimo kriterijai
Paprastai atliekant integracijos testavimą naudojama ETVX (įėjimo kriterijų, užduočių, patvirtinimo ir išėjimo kriterijų) strategija.
Patekimo kriterijai:
- Vieneto bandymo pabaiga
Įėjimai:
- Reikalavimai programinei įrangai
- Programinės įrangos projektavimo dokumentas
- Programinės įrangos patikrinimo planas
- Programinės įrangos integravimo dokumentai
Veikla:
- Remdamiesi aukšto ir žemo lygio reikalavimais, sukurkite bandymų atvejus ir procedūras
- Sujunkite žemo lygio modulių konstrukcijas, kurios įgyvendina bendrą funkcionalumą
- Sukurkite bandymo diržus
- Išbandykite komponavimą
- Kai testas bus išlaikytas, versija bus sujungta su kitomis versijomis ir bandoma, kol sistema bus integruota kaip visuma.
- Pakartotinai atlikite visus bandymus tikslinėje procesoriaus platformoje ir gaukite rezultatus
Išėjimo kriterijai:
- Sėkmingai baigta programinės įrangos modulio integracija į tikslinę techninę įrangą
- Teisingas programinės įrangos veikimas pagal nurodytus reikalavimus
Rezultatai
- Integracijos bandymų ataskaitos
- Programinės įrangos bandymo atvejai ir procedūros [SVCP].
Aparatinės įrangos programinės įrangos integravimo testavimas
Aparatinės įrangos programinės įrangos integravimo testavimas yra kompiuterio programinės įrangos komponentų (CSC) aukšto lygio funkcijų tikrinimas tikslinės aparatinės įrangos aplinkoje. Aparatūros / programinės įrangos integravimo testavimo tikslas yra išbandyti sukurtos programinės įrangos, integruotos į aparatūros komponentą, veikimą.
Reikalavimais pagrįstas aparatinės ir programinės įrangos integravimo testavimas
Reikalavimais pagrįsto aparatūros / programinės įrangos integravimo testavimo tikslas yra įsitikinti, kad tikslinio kompiuterio programinė įranga atitiks aukšto lygio reikalavimus. Tipinės šio bandymo metodo klaidos apima:
- Aparatinės ir programinės įrangos sąsajų klaidos
- Programinės įrangos skaidymo pažeidimai.
- Nesugebėjimas nustatyti gedimų naudojant įmontuotą testą
- Neteisingas atsakas į aparatūros gedimus
- Klaida dėl sekos, trumpalaikės įėjimo apkrovos ir įėjimo galios pereinamojo laikotarpio
- Grįžtamasis ryšys sukelia neteisingą elgesį
- Neteisinga ar netinkama atminties valdymo aparatūros kontrolė
- Duomenų magistralės ginčo problema
- Netinkamas mechanizmo veikimas, siekiant patikrinti lauke įkeliamos programinės įrangos suderinamumą ir teisingumą
Aparatinės įrangos programinės įrangos integracija susijusi su aukšto lygio reikalavimų patikrinimu. Visi šio lygio bandymai atliekami su tiksline aparatine įranga.
- Juodosios dėžės testavimas yra pagrindinė bandymų metodika, naudojama šiame testavimo lygyje.
- Testinius atvejus apibrėžkite tik pagal aukšto lygio reikalavimus
- Turi būti atliktas standartinės gamybos aparatūros bandymas (taikinyje)
Dalykai, į kuriuos reikia atsižvelgti kuriant bandomuosius HW / SW integravimo atvejus
- Teisingas visų duomenų įgijimas programine įranga
- Duomenų mastelis ir diapazonas, kaip tikimasi, nuo aparatūros iki programinės įrangos
- Teisingas duomenų perdavimas iš programinės įrangos į aparatinę įrangą
- Duomenys pagal specifikacijas (įprastas diapazonas)
- Duomenys, neatitinkantys specifikacijų (nenormalus diapazonas)
- Ribiniai duomenys
- Pertraukia apdorojimą
- Laikas
- Teisingas atminties naudojimas (adresavimas, sutapimai ir kt.)
- Būsenos perėjimai
Pastaba: atliekant pertraukimo testavimą, visi pertraukimai bus tikrinami nepriklausomai nuo pradinės užklausos, atliekant visišką aptarnavimą, ir baigę. Bandymo atvejai bus specialiai sukurti tam, kad būtų tinkamai išbandyti pertraukimai.
Programinė įranga programinės įrangos integravimo testavimui
Tai kompiuterio programinės įrangos komponento, veikiančio pagrindiniame / tiksliniame kompiuteryje, testavimas
Aplinką, imituojant visą sistemą [kitus CSC] ir aukšto lygio funkcionalumą.
Jame daugiausia dėmesio skiriama CSC elgesiui imituojamoje priimančiosios / tikslinės aplinkos aplinkoje. Programinės įrangos integravimui naudojamas metodas gali būti laipsniškas (iš viršaus į apačią, iš apačios į viršų arba abiejų derinys).
Prieauginis požiūris
Inkrementiniai bandymai yra integravimo testavimo būdas. Taikant šio tipo bandymo metodą, pirmiausia išbandote kiekvieną programinės įrangos modulį atskirai, o tada tęsite testavimą, pridėdami prie jo kitus modulius, tada dar vieną ir pan.
Prieauginė integracija yra kontrastas su didžiojo sprogimo metodu. Programa yra sukurta ir išbandyta mažuose segmentuose, kur klaidas lengviau išskirti ir ištaisyti. Sąsajos labiau tikrinamos visiškai ir gali būti taikomas sisteminis bandymo metodas.
Yra du papildomų bandymų tipai
- Metodas iš viršaus į apačią
- Metodas iš apačios į viršų
Metodas iš viršaus į apačią
Taikant šį metodą, individualus asmuo pradeda testuoti tik vartotojo sąsają, o pagrindinę funkciją imituoja kamščiai, tada judate žemyn, integruodami apatinius ir apatinius sluoksnius, kaip parodyta žemiau esančiame paveikslėlyje.
- Pradedant nuo pagrindinio valdymo modulio, moduliai integruojami judant žemyn per valdymo hierarchiją
- Pagrindinio valdymo modulio submoduliai įtraukiami į struktūrą pirmiausia „plotis“ arba „gilumas“.
- Pirmoji gylio integracija integruoja visus modulius į pagrindinį struktūros valdymo kelią, kaip parodyta šioje diagramoje:
Modulių integravimo procesas atliekamas tokiu būdu:
- Pagrindinis valdymo modulis naudojamas kaip bandomoji tvarkyklė, o kaiščiai pakeičiami visais moduliais, tiesiogiai pavaldžiais pagrindiniam valdymo moduliui.
- Pavaldūs kamščiai keičiami po vieną faktiniais moduliais, atsižvelgiant į pasirinktą metodą (pirmiausia plotis arba gylis).
- Testai atliekami integruojant kiekvieną modulį.
- Užbaigus kiekvieną bandymų rinkinį, kitas testas pakeičiamas tikru moduliu
- Norint įsitikinti, kad nebuvo įdiegta naujų klaidų, gali būti atliekamas regresijos testavimas.
Procesas tęsiasi nuo 2 žingsnio, kol bus sukurta visa programos struktūra. „Iš viršaus į apačią“ strategija skamba gana nesudėtingai, tačiau praktiškai iškyla logistikos problemų.
Dažniausiai iš šių problemų iškyla, kai norint tinkamai išbandyti viršutinius lygius, reikalingas apdorojimas žemuose hierarchijos lygiuose.
Stubai pakeičia žemo lygio modulius bandymų iš viršaus į apačią pradžioje, todėl jokie reikšmingi duomenys programos struktūroje negali judėti aukštyn.
Su iššūkiais gali susidurti bandytojas:
- Atidėkite daug bandymų, kol karteliai bus pakeisti tikraisiais moduliais.
- Sukurkite kelius, kurie atlieka ribotas funkcijas, imituojančias tikrąjį modulį.
- Integruokite programinę įrangą nuo hierarchijos apačios į viršų.
Pastaba: Pirmasis požiūris lemia tam tikrą kontrolę dėl atitikties tarp konkrečių bandymų ir konkrečių modulių įtraukimo. Tai gali sukelti sunkumų nustatant klaidų, kurios paprastai pažeidžia labai suvaržytą „iš viršaus į apačią“ principą, priežastį.
Antrasis būdas yra veiksmingas, tačiau gali sukelti didelių išlaidų, nes kamščiai tampa vis sudėtingesni.
Metodas iš apačios į viršų
„Iš apačios į viršų“ integracija pradedama kurti ir bandyti naudojant žemiausio lygio programos struktūros modulius. Šiame procese moduliai integruojami iš apačios į viršų.
Taikant šį metodą, visada reikalingas tam tikram lygiui pavaldiems moduliams reikalingas apdorojimas ir pašalinamas kamienų poreikis.
Šis integravimo bandymo procesas atliekamas keturių žingsnių seka
- Žemo lygio moduliai sujungiami į grupes, atliekančias tam tikrą programinės įrangos subfunkciją.
- Vairuotojas yra parašytas koordinuoti bandymo atvejo įvestį ir išvestį.
- Tikrinamas klasteris arba komponavimas.
- Tvarkyklės pašalinamos ir grupės sujungiamos judant į viršų programos struktūroje.
Kai integracija juda aukštyn, reikia atskirų vairuotojų egzaminų pamokų. Tiesą sakant, jei du viršutiniai programos struktūros lygiai yra integruoti iš viršaus į apačią, tvarkyklių skaičių galima žymiai sumažinti ir klasterių integracija yra labai supaprastinta. Integracija vyksta pagal toliau pavaizduotą modelį. Kai integracija juda aukštyn, reikia atskirų vairuotojų egzaminų pamokų.
Pastaba: Jei integruoti du viršutiniai programos struktūros lygiai „iš viršaus į apačią“, tvarkyklių skaičių galima žymiai sumažinti, o versijų integravimas yra labai supaprastintas.
Didžiojo sprogimo požiūris
Taikant šį metodą, visi moduliai nėra integruoti, kol visi moduliai nebus paruošti. Kai jie bus paruošti, visi moduliai bus integruoti ir tada vykdomi, kad žinotų, ar visi integruoti moduliai veikia, ar ne.
Taikant šį požiūrį sunku žinoti pagrindinę nesėkmės priežastį, nes viskas integruojama vienu metu.
Taip pat bus didelė tikimybė, kad gamybos aplinkoje atsiras kritinių klaidų.
Šis metodas taikomas tik tada, kai integracijos bandymai turi būti atliekami vienu metu.
Santrauka:
- Integracija atliekama siekiant patikrinti programinės įrangos sistemos modulių sąveiką. Tai padeda anksti nustatyti defektą
- Integracijos bandymai gali būti atliekami aparatinės ir programinės įrangos arba aparatinės ir techninės įrangos integracijai
- Integracijos testavimas atliekamas dviem būdais
- Prieauginis požiūris
- Didžiojo sprogimo požiūris
- Atliekant integracijos testavimą paprastai naudojama ETVX (įėjimo kriterijų, užduočių, patvirtinimo ir išėjimo kriterijų) strategija.
