Kas ir sistēmas integrācijas testēšana?
Sistēmas integrācijas testēšana ir definēta kā programmatūras testēšanas veids, kas tiek veikts integrētā aparatūras un programmatūras vidē, lai pārbaudītu visas sistēmas darbību. Tas tiek testēts uz pilnīgu, integrētu sistēmu, lai novērtētu sistēmas atbilstību tās noteiktajām prasībām.
Sistēmas integrācijas pārbaude (SIT) tiek veikta, lai pārbaudītu mijiedarbību starp programmatūras sistēmas moduļiem. Tas nodarbojas ar programmatūras prasību specifikācijā / datos un programmatūras noformēšanas dokumentā norādīto augsta un zema līmeņa programmatūras prasību pārbaudi.
Tas arī pārbauda programmatūras sistēmas līdzāspastāvēšanu ar citiem un pārbauda saskarni starp lietojumprogrammas moduļiem. Šāda veida testēšanā moduļi vispirms tiek pārbaudīti atsevišķi un pēc tam apvienoti, lai izveidotu sistēmu.
Piemēram, programmatūras un / vai aparatūras komponenti tiek pakāpeniski apvienoti un testēti, līdz visa sistēma ir integrēta.
Šajā apmācībā jūs uzzināsiet
- Kas ir sistēmas integrācijas testēšana?
- Kāpēc jāveic sistēmas integrācijas testēšana
- Kā veikt sistēmas integrācijas testēšanu
- Integrācijas testēšanas ieejas un izejas kritēriji
- Aparatūras programmatūras integrācijas testēšanai
- Programmatūras programmatūras integrācijas testēšanai
- Pieeja no augšas uz leju
- Pieeja no apakšas uz augšu
- Lielā sprādziena pieeja
Kāpēc jāveic sistēmas integrācijas testēšana
Programmatūras inženierijā sistēmu integrācijas testēšana tiek veikta, jo
- Tas palīdz savlaicīgi atklāt defektu
- Būs pieejamas agrākas atsauksmes par individuālā moduļa pieņemamību
- Defektu labojumu plānošana ir elastīga, un to var pārklāties ar attīstību
- Pareiza datu plūsma
- Pareiza vadības plūsma
- Pareizs laiks
- Pareiza atmiņas izmantošana
- Pareizi ar programmatūras prasībām
Kā veikt sistēmas integrācijas testēšanu
Tas ir sistemātisks paņēmiens programmas struktūras izveidošanai, vienlaikus veicot testus, lai atklātu kļūdas, kas saistītas ar saskarni.
Visi moduļi ir iepriekš integrēti, un visa programma tiek pārbaudīta kopumā. Bet šī procesa laikā, visticamāk, radīsies kļūdu kopums.
Šādu kļūdu labošana ir sarežģīta, jo izolācijas cēloņus sarežģī plašā visas programmas paplašināšanās. Kad šīs kļūdas ir novērstas un izlabotas, parādīsies jauna, un process bez traucējumiem turpinās bezgalīgi . Lai izvairītos no šīs situācijas, tiek izmantota cita pieeja - Inkrementālā integrācija. Sīkāku informāciju par pakāpenisku pieeju redzēsim vēlāk apmācībā.
Ir dažas papildu metodes, piemēram, integrācijas testi tiek veikti sistēmā, kuras pamatā ir mērķa procesors. Izmantotā metodika ir melnās kastes testēšana. Var izmantot integrāciju no apakšas uz augšu vai no augšas uz leju.
Testa gadījumi tiek definēti, izmantojot tikai augsta līmeņa programmatūras prasības.
Programmatūras integrāciju lielā mērā var panākt arī resursdatora vidē, resursdatorā turpinot simulēt mērķa videi raksturīgas vienības. Atkārtoti būs nepieciešami atkārtoti testi mērķa vidē, lai saņemtu apstiprinājumu.
Apstiprināšanas testi šajā līmenī identificēs ar vidi saistītas problēmas, piemēram, kļūdas atmiņas piešķiršanā un atdalīšanā. Programmatūras integrācijas praktiskums resursdatora vidē būs atkarīgs no tā, cik daudz ir mērķa specifiskās funkcionalitātes. Dažām iegultām sistēmām savienojums ar mērķa vidi būs ļoti spēcīgs, padarot programmatūras integrāciju resursdatora vidē praktisku.
Liela programmatūras izstrāde sadalīs programmatūras integrāciju vairākos līmeņos. Zemākos programmatūras integrācijas līmeņus galvenokārt var pamatot resursdatora vidē, vēlāk programmatūras integrācijas līmeņi kļūst arvien atkarīgāki no mērķa vides.
Piezīme. Ja tiek pārbaudīta tikai programmatūra, to sauc par programmatūras programmatūras integrācijas testēšanu [SSIT] un, ja tiek pārbaudīta gan aparatūra, gan programmatūra, to sauc par aparatūras programmatūras integrācijas testēšanu [HSIT].
Integrācijas testēšanas ieejas un izejas kritēriji
Parasti, veicot integrācijas testēšanu, tiek izmantota stratēģija ETVX (Entry Criteria, Task, Validation and Exit Criteria).
Ieejas kritēriji:
- Vienības testēšanas pabeigšana
Ieejas:
- Programmatūras prasību dati
- Programmatūras projektēšanas dokuments
- Programmatūras verifikācijas plāns
- Programmatūras integrācijas dokumenti
Aktivitātes:
- Pamatojoties uz Augsta un Zema līmeņa prasībām, izveidojiet pārbaudes gadījumus un procedūras
- Apvienojiet zema līmeņa moduļu būvējumus, kas ievieš kopēju funkcionalitāti
- Izstrādājiet testa vadu
- Pārbaudiet uzbūvi
- Kad tests ir nokārtots, būvējums tiek apvienots ar citiem būvējumiem un tiek pārbaudīts, līdz sistēma tiek integrēta kopumā.
- Atkārtoti veiciet visus testus uz mērķa procesora bāzes platformas un iegūstiet rezultātus
Izejas kritēriji:
- Veiksmīgi pabeigta programmatūras moduļa integrācija mērķa aparatūrā
- Pareiza programmatūras darbība atbilstoši norādītajām prasībām
Rezultāti
- Integrācijas testa ziņojumi
- Programmatūras testēšanas gadījumi un procedūras [SVCP].
Aparatūras programmatūras integrācijas pārbaude
Aparatūras programmatūras integrācijas pārbaude ir datoru programmatūras komponentu (CSC) testēšanas process augsta līmeņa funkcijām mērķa aparatūras vidē. Aparatūras / programmatūras integrācijas testēšanas mērķis ir pārbaudīt izstrādātās programmatūras darbību, kas integrēta aparatūras komponentā.
Uz prasībām balstīta aparatūras un programmatūras integrācijas testēšana
Uz prasībām balstītas aparatūras / programmatūras integrācijas testēšanas mērķis ir pārliecināties, ka mērķa datorā esošā programmatūra atbildīs augsta līmeņa prasībām. Šīs testēšanas metodes atklātās tipiskās kļūdas ietver:
- Aparatūras / programmatūras saskarnes kļūdas
- Programmatūras sadalīšanas pārkāpumi.
- Nespēja atklāt kļūmes ar iebūvētu testu
- Nepareiza reakcija uz aparatūras kļūmēm
- Kļūda secības, īslaicīgu ieejas slodžu un ieejas jaudas pārejas dēļ
- Atsauksmes rada nepareizu rīcību
- Nepareiza vai nepareiza atmiņas pārvaldības aparatūras kontrole
- Datu kopnes strīda problēma
- Nepareiza mehānisma darbība, lai pārbaudītu laukā ielādējamas programmatūras savietojamību un pareizību
Aparatūras programmatūras integrācija nodarbojas ar augsta līmeņa prasību pārbaudi. Visi šī līmeņa testi tiek veikti ar mērķa aparatūru.
- Melnās kastes testēšana ir galvenā testēšanas metodika, ko izmanto šajā testēšanas līmenī.
- Definējiet testa gadījumus tikai pēc augsta līmeņa prasībām
- Pārbaude jāveic ar ražošanas standarta aparatūru (mērķī)
Kas jāņem vērā, izstrādājot testēšanas gadījumus HW / SW integrācijai
- Pareiza programmatūras visu datu iegūšana
- Datu mērogošana un diapazons, kā paredzēts, no aparatūras līdz programmatūrai
- Pareiza datu izvade no programmatūras uz aparatūru
- Dati atbilstoši specifikācijām (normālā diapazonā)
- Dati ārpus specifikācijām (nenormāls diapazons)
- Robežu dati
- Pārtrauc apstrādi
- Laiks
- Pareiza atmiņas izmantošana (adresēšana, pārklāšanās utt.)
- Stāvokļa pārejas
Piezīme. Pārtraukumu testēšanai visi pārtraukumi tiks pārbaudīti neatkarīgi no sākotnējā pieprasījuma, veicot pilnīgu apkalpošanu, un pēc pabeigšanas. Testa gadījumi tiks īpaši izstrādāti, lai pienācīgi pārbaudītu pārtraukumus.
Programmatūras programmatūras integrācijas testēšanai
Tā ir datora programmatūras komponenta pārbaude, kas darbojas resursdatorā / mērķa datorā
Vide, vienlaikus simulējot visu sistēmu [citas CSC], un augsta līmeņa funkcionalitāte.
Tas koncentrējas uz CSC uzvedību imitētā resursdatora / mērķa vidē. Programmatūras integrācijai izmantotā pieeja var būt inkrementāla pieeja (pieeja no augšas uz leju, no apakšas uz augšu vai abu kombinācija).
Inkrementālā pieeja
Elementārā pārbaude ir integrācijas testēšanas veids. Šāda veida testēšanas metodē vispirms pārbaudiet katru programmatūras moduli atsevišķi un pēc tam turpiniet testēšanu, pievienojot tam citus moduļus, pēc tam vēl vienu un tā tālāk.
Papildu integrācija ir kontrasts ar lielā sprādziena pieeju. Programma ir veidota un testēta mazos segmentos, kur kļūdas ir vieglāk izolēt un labot. Saskarnes, visticamāk, tiks pilnībā pārbaudītas, un var izmantot sistemātisku testa pieeju.
Ir divi papildu testēšanas veidi
- No augšas uz leju pieeja
- No apakšas uz augšu pieeja
Pieeja no augšas uz leju
Šāda veida pieejā individuāli jāsāk, pārbaudot tikai lietotāja saskarni, pamatfunkcionalitāti simulējot ar celmiem, pēc tam jūs pārvietojaties uz leju, integrējot zemākos un apakšējos slāņus, kā parādīts zemāk esošajā attēlā.
- Sākot ar galveno vadības moduli, moduļi tiek integrēti, virzoties lejup pa vadības hierarhiju
- Galvenā vadības moduļa apakšmoduļi tiek iekļauti struktūrā vai nu vispirms ar dziļumu, vai vispirms.
- Pirmajā dziļuma integrācijā visi moduļi tiek integrēti galvenajā struktūras vadības ceļā, kā parādīts šajā diagrammā:
Moduļu integrācijas process tiek veikts šādā veidā:
- Galvenais vadības modulis tiek izmantots kā testa draiveris, un celmus aizstāj visi moduļi, kas tieši pakļauti galvenajam vadības modulim.
- Pakārtotie stublāji tiek aizstāti pa vienam ar faktiskajiem moduļiem atkarībā no izvēlētās pieejas (platums vispirms vai dziļums vispirms).
- Testi tiek veikti, kad katrs modulis ir integrēts.
- Pabeidzot katru testu kopu, pēc katra testa komplekta pabeigšanas cits spraudnis tiek aizstāts ar reālu moduli
- Lai pārliecinātos, ka nav ieviestas jaunas kļūdas, var tikt veikta regresijas pārbaude.
Process turpinās no 2. posma, līdz tiek izveidota visa programmas struktūra. No augšas uz leju stratēģija izklausās samērā nesarežģīta, taču praksē rodas loģistikas problēmas.
Visizplatītākās no šīm problēmām rodas, ja, lai adekvāti pārbaudītu augšējos līmeņus, nepieciešama apstrāde zemos hierarhijas līmeņos.
Stumbri aizstāj zema līmeņa moduļus testēšanas sākumā no augšas uz leju, un tāpēc programmas struktūrā nav nozīmīgu datu.
Problēmas, ar kurām testētājs var saskarties:
- Atlikt daudzus testus, līdz stublāji tiek aizstāti ar faktiskajiem moduļiem.
- Izstrādājiet celmus, kas veic ierobežotas funkcijas, kas simulē faktisko moduli.
- Integrējiet programmatūru no hierarhijas apakšas uz augšu.
Piezīme: Pirmās pieejas dēļ mēs zaudējam zināmu kontroli pār atbilstību starp īpašiem testiem un īpašu moduļu iekļaušanu. Tā rezultātā var rasties grūtības noteikt kļūdu cēloni, kas mēdz pārkāpt ļoti ierobežoto pieeju “no augšas uz leju”.
Otrā pieeja ir efektīva, taču tā var radīt ievērojamas papildu izmaksas, jo celmi kļūst arvien sarežģītāki.
Pieeja no apakšas uz augšu
Integrācija no apakšas uz augšu sāk būvniecību un testēšanu ar moduļiem programmas struktūras zemākajā līmenī. Šajā procesā moduļi tiek integrēti no apakšas uz augšu.
Šajā pieejā vienmēr ir pieejama apstrāde, kas nepieciešama noteiktam līmenim pakārtotajiem moduļiem, un nepieciešamība pēc stublājiem tiek novērsta.
Šis integrācijas testa process tiek veikts četru darbību sērijā
- Zema līmeņa moduļi tiek apvienoti kopās, kas veic noteiktu programmatūras apakšfunkciju.
- Vadītājs tiek rakstīts, lai koordinētu testa gadījuma ievadi un izvadi.
- Klasteris vai būvējums tiek pārbaudīts.
- Draiveri tiek noņemti un kopas tiek apvienotas, virzoties uz augšu programmas struktūrā.
Kad integrācija virzās uz augšu, nepieciešamība pēc atsevišķām testa braucēju nodarbībām. Patiesībā, ja divi augšējie programmas struktūras līmeņi ir integrēti no augšas uz leju, draiveru skaitu var ievērojami samazināt un kopu integrācija ir ievērojami vienkāršota. Integrācija notiek pēc zemāk ilustrētās shēmas. Kad integrācija virzās uz augšu, nepieciešamība pēc atsevišķām testa vadītāju nodarbībām.
Piezīme: Ja ir integrēti divi augšējie programmas struktūras līmeņi no augšas uz leju, draiveru skaitu var ievērojami samazināt, un būvju integrācija ir ievērojami vienkāršota.
Lielā sprādziena pieeja
Šajā pieejā visi moduļi nav integrēti, kamēr visi moduļi nav gatavi. Kad tie ir gatavi, visi moduļi tiek integrēti un pēc tam tiek izpildīti, lai uzzinātu, vai visi integrētie moduļi darbojas vai nē.
Šajā pieejā ir grūti uzzināt neveiksmes galveno cēloni, jo viss tiek integrēts vienlaikus.
Turklāt ražošanas vidē būs liela kritisko kļūdu iespējamība.
Šī pieeja tiek izmantota tikai tad, kad integrācijas pārbaude jāveic uzreiz.
Kopsavilkums:
- Integrācija tiek veikta, lai pārbaudītu mijiedarbību starp programmatūras sistēmas moduļiem. Tas palīdz savlaicīgi atklāt defektu
- Integrācijas testēšanu var veikt aparatūras-programmatūras vai aparatūras-aparatūras integrācijai
- Integrācijas testēšana tiek veikta ar divām metodēm
- Papildu pieeja
- Lielā sprādziena pieeja
- Veicot integrācijas testēšanu, parasti tiek izmantota stratēģija ETVX (Entry Criteria, Task, Validation and Exit Criteria).