Što je SIT? Testiranje integracije sustava s primjerom

Što je testiranje integracije sustava?

sistem Ispitivanje integracije definira se kao vrsta softverskog testiranja koje se provodi u integriranom hardverskom i softverskom okruženju kako bi se provjerilo ponašanje cijelog sustava. To je testiranje koje se provodi na cjelovitom, integriranom sustavu kako bi se procijenila usklađenost sustava s njegovim specificiranim zahtjevima.

Testiranje integracije sustava (SIT) provodi se kako bi se provjerile interakcije između modula softverskog sustava. Bavi se provjerom softverskih zahtjeva visoke i niske razine navedenih u Specifikaciji/podacima o softverskim zahtjevima i Dokumentu dizajna softvera.

SIT također provjerava koegzistenciju softverskog sustava s drugima i testira sučelje između modula softverske aplikacije. U ovoj vrsti testiranja, moduli se prvo testiraju pojedinačno, a zatim se kombiniraju kako bi se stvorio sustav. Na primjer, softverske i/ili hardverske komponente se kombiniraju i testiraju postupno sve dok se cijeli sustav ne integrira.

Gornji dijagram prikazuje progresiju koja definira SIT: zasebno verificirani moduli se spajaju korak po korak sve dok se ne dobije jedan integrirani sustav koji se testira.

Zašto testirati integraciju sustava?

U softverskom inženjerstvu, testiranje integracije sustava provodi se jer,

• Pomaže u otkrivanju Mana rano
• Ranije povratne informacije o prihvatljivosti pojedinog modula bit će dostupne
• Raspored popravka nedostataka je fleksibilan i može se preklapati s razvojem
• Ispravan protok podataka
• Ispravan protok kontrole
• Točno vrijeme
• Ispravna upotreba memorije
• Ispravno sa zahtjevima softvera

Testiranje integracije sustava u odnosu na testiranje sustava u odnosu na testiranje prihvaćanja od strane korisnika

Budući da se ove tri razine isprepliću, često se brkaju. Ispitivanje sustava ispituje jednu gotovu konstrukciju u odnosu na njezine zahtjeve, SIT ispituje spojeve između konstrukcija i Testiranje prihvatljivosti korisnika ispituje poslovnu sposobnost s gledišta kupca. Tablica u nastavku ih razdvaja.

Parametar	Testiranje integracije sustava	Ispitivanje sustava	Testiranje prihvatljivosti korisnika
Primarni fokus	Sučelja i protok podataka između integriranih modula	Ponašanje sastavljene konstrukcije kao cjeline	Poslovna prikladnost za stvarnu upotrebu
Razina testiranja	Druga razina	Treća razina	Završna razina prije puštanja u rad
Tehnika	Crna kutija	Crna kutija, bijela kutija ili siva kutija	Crna kutija
Izvođeno od	Testeri i programeri integracije	Neovisni tim za testiranje	Kupac ili krajnji korisnici
Tipični nedostaci	Sučelje, vrijeme, memorija i mapa podatakaping pogreške	Funkcionalne i nefunkcionalne pogreške sustava	Neusklađenost upotrebljivosti i zahtjeva
Pokreće se kada	nakon Ispitivanje jedinice	Nakon SIT-a	Nakon testiranja sustava

Slijed je važan. Moduli prolaze jedinično testiranje, SIT dokazuje sučelja, sistemsko testiranje dokazuje sastavljeni proizvod, a UAT potvrđuje da proizvod odgovara poslovnim očekivanjima. Preskoči.ping SIT gura nedostatke sučelja u UAT, gdje svaki popravak košta puno više.

Kako napraviti testiranje integracije sustava

To je sustavna tehnika za izgradnju programske strukture tijekom provođenja testova za otkrivanje pogrešaka povezanih s povezivanjem.

Svi moduli su unaprijed integrirani, a cijeli program se testira kao cjelina. Ali tijekom ovog procesa vjerojatno će se naići na niz pogrešaka.

Ispravljanje takvih pogrešaka je teško jer je uzrok izolacije kompliciran golemom ekspanzijom cijelog programa. Nakon što se te pogreške isprave i isprave, pojavit će se nova, a proces se neprimjetno nastavlja u beskrajnoj petlji. Kako bi se izbjegla ova situacija, koristi se drugi pristup, inkrementalna integracija. Inkrementalni pristup detaljno je objašnjen u sljedećem odjeljku.

Postoje neke inkrementalne metode poput integracijskih testova koji se provode na sustavu temeljenom na ciljnom procesoru. Korištena metodologija je Crna Box Ispitivanje. Može se koristiti integracija odozdo prema gore ili odozgo prema dolje.

Testni slučajevi definirani su samo pomoću softverskih zahtjeva visoke razine.

Softverska integracija također se može postići uglavnom u glavnom okruženju, s jedinicama specifičnim za ciljno okruženje koje se nastavljaju simulirati u glavnom računalu. Ponovno će biti potrebno ponavljanje testova u ciljnom okruženju za potvrdu.

Potvrdni testovi na ovoj razini identificirat će probleme specifične za okruženje, kao što su pogreške u alokaciji i dealokaciji memorije. Praktičnost provođenja integracije softvera u host okruženju ovisit će o tome koliko funkcionalnosti specifičnih za cilj postoji. Za neke ugrađene sustave veza s ciljnim okruženjem bit će vrlo jaka, što će učiniti nepraktičnim provođenje integracije softvera u host okruženju.

Veliki razvoj softvera podijelit će integraciju softvera na više razina. Niže razine integracije softvera mogle bi se pretežno temeljiti na okruženju domaćina, dok bi kasnije razine integracije softvera postale više ovisne o ciljnom okruženju.

Bilješka: Ako se testira samo softver, to se naziva testiranje integracije softvera i softvera [SSIT], a ako se testiraju i hardver i softver, onda se to naziva testiranje integracije softvera i hardvera [HSIT].

Inkrementalni pristup

Budući da integriranje svega odjednom otežava izolaciju nedostataka, većina timova slijedi ovdje opisani inkrementalni put.

Inkrementalno testiranje je način integracijskog testiranja. U ovoj vrsti metode testiranja, prvo testirate svaki modul softvera pojedinačno, a zatim nastavite s testiranjem dodavanjem drugih modula, zatim još jednog i tako dalje.

Inkrementalna integracija je suprotnost pristupu velikog praska. Program je konstruiran i testiran u malim segmentima, gdje je greške lakše izolirati i ispraviti. Vjerojatnije je da će sučelja biti potpuno testirana, a može se primijeniti i sustavni pristup testiranju.

Postoje dvije vrste inkrementalnog testiranja

• Pristup odozgo prema dolje
• Pristup odozdo prema gore

Pristup odozgo prema dolje

U ovoj vrsti pristupa, pojedinac počinje testiranjem samo korisničkog sučelja, s temeljnom funkcionalnošću simuliranom pomoću stubova, a zatim idete prema dolje integrirajući sve niže slojeve kao što je prikazano na slici ispod.

• Počevši od glavnog upravljačkog modula, moduli se integriraju pomicanjem prema dolje kroz upravljačku hijerarhiju
• Podmoduli glavnog upravljačkog modula ugrađeni su u strukturu bilo u širinu ili u dubinu.
• Integracija u dubinu integrira sve module na glavnom kontrolnom putu strukture kao što je prikazano na sljedećem dijagramu:

Proces integracije modula odvija se na sljedeći način:

1. Glavni upravljački modul koristi se kao testni upravljački program, a spojnice se zamjenjuju za sve module koji su izravno podređeni glavnom upravljačkom modulu.
2. Podređeni dijelovi zamjenjuju se jedan po jedan stvarnim modulima, ovisno o odabranom pristupu (prvo širina ili dubina).
3. Testovi se provode kako je svaki modul integriran.
4. Po završetku svakog skupa testova, drugi klinac se zamjenjuje pravim modulom po završetku svakog skupa testova
5. Kako biste bili sigurni da nisu uvedene nove pogreške Ispitivanje regresije može se izvršiti.

Proces se nastavlja od koraka 2 dok se ne izgradi cijela struktura programa. Strategija odozgo prema dolje zvuči relativno nekomplicirano, ali u praksi se javljaju logistički problemi.

Najčešći od ovih problema javljaju se kada je obrada na niskim razinama u hijerarhiji potrebna za adekvatno testiranje viših razina.

Stubovi zamjenjuju module niske razine na početku testiranja odozgo prema dolje i stoga nikakvi značajni podaci ne mogu teći prema gore u strukturi programa.

Izazovi s kojima bi se ispitivač mogao suočiti:

• Odgodite mnoge testove dok se dionice ne zamijene stvarnim modulima.
• Razvijte dopune koje izvode ograničene funkcije koje simuliraju stvarni modul.
• Integrirajte softver od dna hijerarhije prema gore.

Bilješka: Prvi pristup dovodi do gubitka kontrole nad korespondencijom između specifičnih testova i ugradnjom specifičnih modula. To može rezultirati poteškoćama u određivanju uzroka pogrešaka što narušava visoko ograničenu prirodu pristupa odozgo prema dolje.

Drugi pristup je izvediv, ali može dovesti do značajnih dodatnih troškova, jer zaglavci postaju sve složeniji.

Pristup odozdo prema gore

Integracija odozdo prema gore započinje konstrukciju i testiranje s modulima na najnižoj razini u strukturi programa. U ovom procesu, moduli su integrirani od dna prema vrhu.

U ovom pristupu obrada potrebna za module podređene određenoj razini uvijek je dostupna i potreba za dopunama je eliminirana.

Ovaj postupak testiranja integracije izvodi se u nizu od četiri koraka

1. Moduli niske razine kombiniraju se u klastere koji izvode određenu softversku podfunkciju.
2. Upravljački program je napisan za koordinaciju ulaza i izlaza testnog slučaja.
3. Klaster ili gradnja se testiraju.
4. Upravljački programi se uklanjaju, a klasteri se kombiniraju prema gore u strukturi programa.

Kako integracija napreduje, raste potreba za odvojenim lekcijama testnih vozača. Zapravo, ako se dvije gornje razine programske strukture integriraju od vrha prema dolje, broj vozača može se znatno smanjiti, a integracija klastera je uvelike pojednostavljena. Integracija slijedi obrazac prikazan u nastavku.

Bilješka: Ako su gornje dvije razine programske strukture integrirane odozgo prema dolje, broj upravljačkih programa može se znatno smanjiti, a integracija nadogradnji uvelike je pojednostavljena.

Pristup Velikog praska

U ovom pristupu, svi moduli nisu integrirani dok i osim ako svi moduli nisu spremni. Nakon što su spremni, svi moduli se integriraju i zatim se izvršavaju kako bi se znalo rade li svi integrirani moduli ili ne.

U ovom pristupu, teško je znati glavni uzrok neuspjeha zbog integriranja svega odjednom.

Također, postojat će velika vjerojatnost pojave kritičnih grešaka u proizvodnom okruženju.

Ovaj pristup se usvaja samo kada se testiranje integracije mora obaviti odjednom.

Testiranje integracije hardvera i softvera

Testiranje integracije hardvera i softvera je proces testiranja komponenti računalnog softvera (CSC) za funkcionalnost visoke razine na ciljanom hardverskom okruženju. Cilj testiranja integracije hardvera/softvera je ispitati ponašanje razvijenog softvera integriranog na hardverskoj komponenti.

Testiranje integracije hardvera i softvera temeljeno na zahtjevima

Cilj testiranja integracije hardvera/softvera temeljenog na zahtjevima je osigurati da softver u ciljnom računalu zadovolji zahtjeve visoke razine. Tipične pogreške otkrivene ovom metodom testiranja uključuju:

• Greške hardversko/softverskih sučelja
• Povrede particioniranja softvera.
• Nemogućnost otkrivanja kvarova pomoću ugrađenog testa
• Neispravan odgovor na kvarove hardvera
• Pogreška zbog sekvenciranja, prijelaznih ulaznih opterećenja i prijelaznih pojava ulazne snage
• Neispravno ponašanje povratnih petlji
• Netočna ili nepravilna kontrola hardvera za upravljanje memorijom
• Problem sukoba podatkovne sabirnice
• Neispravan rad mehanizma za provjeru kompatibilnosti i ispravnosti softvera koji se može učitavati na terenu

Hardverska softverska integracija bavi se provjerom zahtjeva visoke razine. Svi testovi na ovoj razini provode se na ciljnom hardveru.

• Testiranje crne kutije primarna je metodologija testiranja koja se koristi na ovoj razini testiranja.
• Definirati test slučajevi samo od zahtjeva visoke razine
• Test se mora izvršiti na proizvodnom standardnom hardveru (na cilju)

Stvari koje treba uzeti u obzir prilikom dizajniranja testnih slučajeva za HW/SW integraciju

• Ispravno prikupljanje svih podataka od strane softvera
• Skaliranje i raspon podataka prema očekivanjima od hardvera do softvera
• Ispravan izlaz podataka iz softvera u hardver
• Podaci unutar specifikacija (normalni raspon)
• Podaci izvan specifikacija (nenormalan raspon)
• Podaci o granici
• Prekida obradu
• Termin
• Ispravna upotreba memorije (adresiranje, preklapanja, itd.)
• Prijelazi stanja

Bilješka: Za testiranje prekida, svi prekidi bit će provjereni neovisno od početnog zahtjeva preko potpunog servisiranja do završetka. Test slučajevi će biti posebno dizajnirani kako bi se prekidi adekvatno testirali.

Testiranje integracije softvera u softver

To je testiranje softverske komponente računala koja radi unutar okruženja glavnog/ciljnog računala, simulirajući cijeli sustav [druge CSC-ove] i na visokoj razini funkcionalnosti.

Fokusira se na ponašanje CSC-a u simuliranom okruženju host/cilj. Pristup koji se koristi za integraciju softvera može biti inkrementalni pristup (od vrha prema dolje, od dna prema vrhu ili kombinacija oba, također nazvan sendvič ili hibridni pristup).

Ulazni i izlazni kriteriji za integracijsko testiranje

Nakon što se utvrdi pristup i dvije varijante integracije, preostalo je pitanje kada tim može započeti, a kada stati. Obično se pri izvođenju integracijskog testiranja koristi strategija ETVX (kriterij ulaska, zadatak, validacija i kriterij izlaska).

Kriteriji ulaska:

• Završetak Ispitivanje jedinice

Ulazi:

• Podaci o softverskim zahtjevima
• Dokument dizajna softvera
• Plan verifikacije softvera
• Dokumenti o integraciji softvera

Djelatnost:

• Na temelju zahtjeva visoke i niske razine kreirajte testne slučajeve i procedure
• Kombinirajte međugradnje modula niske razine koje implementiraju zajedničku funkcionalnost
• Razvijte testni pojas
• Testirajte izradu
• Nakon što je test prošao, build se kombinira s drugim buildovima i testira dok se sustav ne integrira kao cjelina.
• Ponovno izvršite sve testove na ciljnoj platformi temeljenoj na procesoru i dobijte rezultate

Kriteriji za izlaz:

• Uspješan završetak integracije softverskog modula na ciljni hardver
• Ispravna izvedba softvera prema navedenim zahtjevima

Izlazi

• Izvješća o testu integracije
• Slučajevi i postupci testiranja softvera [SVCP].

Uobičajeni izazovi u testiranju integracije sustava

Čak i uz dobar pristup i jasne kriterije za izlaz, integrirana okruženja stvaraju probleme koji se nikada ne pojavljuju tijekom testiranja jedinica. Njihovo rano prepoznavanje održava raspored realističnim.

• Neusklađenost okruženja: integrirani okruženje ispitivanja rijetko odražava proizvodnju, pa se vremenski i konfiguracijski nedostaci pojavljuju sve do vrlo kasno.
• Spremnost na ovisnost: Sučelja trećih strana i naslijeđena sučelja često su nedovršena, što prisiljava testere da se oslanjaju na stubove i simulatore puno dulje nego što je planirano.
• Nedosljednost podataka: Dva modula mogu različito predstavljati isti zapis, što uzrokuje tihe neusklađenosti umjesto vidljivih grešaka.
• Vlasništvo nad nedostatkom: kada neuspjeh obuhvaća dva tima, analiza uzroka i upravljanje nedostacima primjetno usporiti.
• Trošak regresije: svako novo sučelje proširuje regresijsko testiranje paket, pa ručno ponovno izvršavanje brzo postaje neodrživo.

Većina njih su rizici rasporeda, a ne tehničke slijepe ulice. Dogovaranje datuma spremnosti sučelja, opsega simulatora i vlasništva nad trijažom nedostataka prije integracije prve izgradnje uklanja većinu njih. Za sučelja u vlasništvu dobavljača, također zabilježite dogovoreni format poruke i kontakt za eskalaciju, jer nedostatak vlasnika odgađa popravak dulje nego što to zahtijeva nedostatak.

Najbolje prakse za testiranje integracije sustava

Ponovljivi SIT ciklus manje ovisi o alatima, a više o disciplini oko sučelja, podataka i dokaza. Pet dolje navedenih praksi podjednako odgovara i malim ugrađenim sustavima i velikom okruženju s više dobavljača, a svaka smanjuje potrebu za ponovnim radom koji doseže kasnije razine testiranja.

1. Prvo mapirajte svako sučelje. Navedite svaku razmjenu podataka, njezin smjer, protokol i vlasnika prije pisanja pojedinačnog testnog slučaja.
2. Prioritizirajte prema riziku. Provjerite sučelja koja nose novac, identitet ili regulirane podatke prije kozmetičkih.
3. Dizajnirajte realistične testne podatke. Pokrijte normalne, granične i abnormalne raspone kako bi se pogreške skaliranja i zaokruživanja rano pojavile.
4. Automatizirajte stabilne putanje. Žičano sučelje se provjerava u kontinuirana integracija cjevovod tako da ih svaka izgradnja ponovno provjerava.
5. Sačuvajte dokaze tracmoguće. Povežite svaki rezultat sa zahtjevom putem tracmatrica učinkovitosti tako da se kriteriji izlaska mogu dokazati, a ne tvrditi.

⚠ Savjet: Zamrznite specifikacije sučelja prije početka integracije. Kasna promjena formata poruke poništava testne slučajeve na obje strane sučelja i najčešći je uzrok prerade SIT-a.

Pitanja i odgovori