Kas ir integrācijas testēšana?
INTEGRĀCIJAS PĀRBAUDE ir definēta kā testēšanas veids, kur programmatūras moduļi tiek loģiski integrēti un pārbaudīti kā grupa. Tipisks programmatūras projekts sastāv no vairākiem programmatūras moduļiem, kurus kodē dažādi programmētāji. Šāda līmeņa testēšanas mērķis ir atklāt defektus mijiedarbībā starp šiem programmatūras moduļiem, kad tie ir integrēti
Integrācijas testēšana koncentrējas uz datu komunikācijas pārbaudi starp šiem moduļiem. Tāpēc to sauc arī par “I & T” (integrācija un testēšana), “virkņu testēšana” un dažreiz “pavedienu pārbaude” .
- Kas ir integrācijas testēšana?
- Kāpēc veikt integrācijas testēšanu?
- Integrācijas testa gadījuma piemērs
- Integrācijas testēšanas pieejas, stratēģijas, metodikas
- Lielā sprādziena pieeja:
- Inkrementālā pieeja
- Kas ir Stub un Driver?
- Integrācija no apakšas uz augšu
- No augšas uz leju integrācija:
- Hibrīda / sviestmaižu integrācija
- Kā veikt integrācijas testēšanu?
- Īss integrācijas testēšanas plānu apraksts:
- Integrācijas testēšanas ieejas un izejas kritēriji
- Labākā prakse / vadlīnijas integrācijas testēšanai
Kāpēc veikt integrācijas testēšanu?
Lai gan katrs programmatūras modulis ir pārbaudīts ar vienību, defekti joprojām pastāv dažādu iemeslu dēļ, piemēram,
- Moduli parasti izstrādā individuāls programmatūras izstrādātājs, kura izpratne un programmēšanas loģika var atšķirties no citiem programmētājiem. Integrācijas testēšana ir nepieciešama, lai pārliecinātos, ka programmatūras moduļi darbojas vienoti
- Moduļu izstrādes laikā pastāv lielas iespējas mainīt klienta prasības. Šīs jaunās prasības, iespējams, netiks pārbaudītas vienībā, un tāpēc ir nepieciešama sistēmas integrācijas testēšana.
- Programmatūras moduļu saskarnes ar datu bāzi varētu būt kļūdainas
- Ārējās aparatūras saskarnes, ja tādas ir, varētu būt kļūdainas
- Nepietiekama izņēmumu apstrāde var radīt problēmas.
Noklikšķiniet šeit, ja videoklips nav pieejams
Integrācijas testa gadījuma piemērs
Integrācijas testa gadījums atšķiras no citiem testa gadījumiem ar to, ka tas galvenokārt koncentrējas uz saskarnēm un datu / informācijas plūsmu starp moduļiem . Šeit prioritāte jāpiešķir integrējošajām saitēm, nevis vienības funkcijām, kuras jau ir pārbaudītas.
Integrācijas testa gadījumu paraugi šādam scenārijam: Lietojumprogrammai ir 3 moduļi: “Pieteikšanās lapa”, “Pastkaste” un “Dzēst e-pastus”, un katrs no tiem ir loģiski integrēts.
Šeit nav īpaši jākoncentrējas uz pieteikšanās lapas testēšanu, jo tas jau ir izdarīts vienības testēšanā. Bet pārbaudiet, kā tas ir saistīts ar pastkastes lapu.
Līdzīgi arī pastkaste: pārbaudiet tās integrāciju modulī Dzēst vēstules.
| Testa lietas ID | Pārbaudes gadījuma mērķis | Testa gadījuma apraksts | Gaidāmais Rezultāts |
|---|---|---|---|
| 1 | Pārbaudiet saskarnes saiti starp moduli Pieteikšanās un Pastkaste | Ievadiet pieteikšanās akreditācijas datus un noklikšķiniet uz pogas Pieteikties | Tiek novirzīts uz pastkasti |
| 2 | Pārbaudiet saskarnes saiti starp pastkasti un ziņojumu dzēšanu | Sadaļā Pastkaste atlasiet e-pastu un noklikšķiniet uz pogas Dzēst | Atlasītajam e-pastam vajadzētu parādīties mapē Dzēst / Miskaste |
Integrācijas testēšanas pieejas, stratēģijas, metodikas
Programmatūras inženierija nosaka dažādas stratēģijas integrācijas testēšanas veikšanai, ti.
- Lielā sprādziena pieeja:
- Inkrementālā pieeja: ko sīkāk iedala šādi
- Pieeja no augšas uz leju
- Pieeja no apakšas uz augšu
- Sandwich pieeja - kombinācija no augšas uz leju un no apakšas uz augšu
Zemāk ir norādītas dažādas stratēģijas, to izpildes veids un ierobežojumi, kā arī priekšrocības.
Lielā sprādziena pārbaude
Lielā sprādziena pārbaude ir integrācijas testēšanas pieeja, kurā visas sastāvdaļas vai moduļi tiek integrēti kopā un pēc tam pārbaudīti kā vienība. Šis kombinētais komponentu kopums testēšanas laikā tiek uzskatīts par vienību. Ja visi vienības komponenti nav pabeigti, integrācijas process netiks izpildīts.
Priekšrocības:
- Ērti mazām sistēmām.
Trūkumi:
- Kļūdu lokalizācija ir sarežģīta.
- Ņemot vērā milzīgo saskarņu skaitu, kas jāpārbauda šajā pieejā, dažas pārbaudāmās saskarnes saites varētu viegli palaist garām.
- Tā kā integrācijas testēšana var sākties tikai pēc visu moduļu izstrādes, testēšanas komandai testēšanas posmā būs mazāk laika izpildei.
- Tā kā visi moduļi tiek pārbaudīti vienlaikus, augsta riska kritiskie moduļi netiek izolēti un pārbaudīti prioritāri. Arī perifērijas moduļi, kas nodarbojas ar lietotāja saskarnēm, netiek izolēti un pārbaudīti prioritāri.
Papildu pārbaude
Jo Pakāpeniska testēšanas pieeju, pārbaude tiek veikta, integrējot divus vai vairākus moduļus, kas ir loģiski saistīti viens ar otru, un tad testēti pareizai darbībai pieteikumu. Tad pārējie saistītie moduļi tiek pakāpeniski integrēti un process turpinās, līdz visi loģiski saistītie moduļi tiek veiksmīgi integrēti un pārbaudīti.
Savukārt pieaugošo pieeju veic ar divām dažādām metodēm:
- Apakšā uz augšu
- No augšas uz leju
Stublāji un vadītāji
Stubs and Drivers ir integrācijas testēšanas fiktīvās programmas, ko izmanto, lai atvieglotu programmatūras testēšanas darbību. Šīs programmas darbojas kā trūkstošo modeļu aizstājēji testēšanā. Viņi neīsteno visu programmatūras moduļa programmēšanas loģiku, bet testēšanas laikā simulē datu saziņu ar izsaukšanas moduli.
Stub : To izsauc testējamais modulis.
Vadītājs : aicina moduli pārbaudīt.
No apakšas uz augšu integrācijas testēšana
No apakšas uz augšu integrācijas testēšana ir stratēģija, kurā vispirms tiek pārbaudīti zemākā līmeņa moduļi. Šie pārbaudītie moduļi tiek tālāk izmantoti, lai atvieglotu augstāka līmeņa moduļu testēšanu. Process turpinās, līdz tiek pārbaudīti visi moduļi augstākajā līmenī. Kad zemākā līmeņa moduļi ir pārbaudīti un integrēti, tad tiek veidots nākamais moduļu līmenis.
Diagrammas attēlojums :
Priekšrocības:
- Kļūdu lokalizācija ir vienkāršāka.
- Nav laika velti gaidot visu moduļu izstrādi atšķirībā no Big-bang pieejas
Trūkumi:
- Kritiskie moduļi (programmatūras arhitektūras augšējā līmenī), kas kontrolē lietojumprogrammu plūsmu, tiek pārbaudīti pēdējie un var būt pakļauti defektiem.
- Agrīns prototips nav iespējams
No augšas uz leju integrācijas testēšana
Integrācija no augšas uz leju ir metode, kurā integrācijas testēšana notiek no augšas uz leju, sekojot programmatūras sistēmas vadības plūsmai. Vispirms tiek pārbaudīti augstākā līmeņa moduļi, pēc tam tiek pārbaudīti un integrēti zemākā līmeņa moduļi, lai pārbaudītu programmatūras funkcionalitāti. Stumbri tiek izmantoti testēšanai, ja daži moduļi nav gatavi.
Diagrammas attēlojums:
Priekšrocības:
- Kļūdu lokalizācija ir vienkāršāka.
- Iespēja iegūt agrīnu prototipu.
- Kritiskos moduļus pārbauda prioritāri; Vispirms varēja atrast un novērst galvenos dizaina trūkumus.
Trūkumi:
- Nepieciešami daudzi Stubs.
- Moduļi zemākā līmenī tiek pārbaudīti nepietiekami.
Sviestmaižu pārbaude
Sandwich Testing ir stratēģija, kurā augstākā līmeņa moduļi tiek pārbaudīti ar zemāka līmeņa moduļiem, tajā pašā laikā zemākie moduļi tiek integrēti augšējos moduļos un tiek pārbaudīti kā sistēma. Tā ir kombinācija no augšas uz leju un no apakšas uz augšu, tāpēc to sauc par hibrīda integrācijas testēšanu . Tas izmanto gan balstus, gan vadītājus.
Kā veikt integrācijas testēšanu?
Integrācijas testa procedūra neatkarīgi no programmatūras testēšanas stratēģijām (apspriesta iepriekš):
- Sagatavojiet integrācijas testu plānu
- Izstrādājiet testa scenārijus, gadījumus un skriptus.
- Testa gadījumu veikšana, kam seko ziņošana par defektiem.
- Defektu izsekošana un atkārtota pārbaude.
- 3. un 4. darbību atkārto, līdz integrācijas pabeigšana ir veiksmīga.
Īss integrācijas testēšanas plānu apraksts:
Tas ietver šādus atribūtus:
- Testēšanas metodes / pieejas (kā apspriests iepriekš).
- Darbības jomas un ārpus darbības jomas integrācijas testēšana.
- Lomas un pienākumi.
- Priekšnoteikumi integrācijas testēšanai.
- Pārbaudes vide.
- Riska un mazināšanas plāni.
Integrācijas testēšanas ieejas un izejas kritēriji
Ieejas un izejas kritēriji integrācijas testēšanas fāzē jebkurā programmatūras izstrādes modelī
Ieejas kritēriji:
- Vienības pārbaudītie komponenti / moduļi
- Visas augstas prioritātes kļūdas ir novērstas un aizvērtas
- Visi kodi ir jāaizpilda un veiksmīgi jāintegrē.
- Integrācijas testi Plāns, testa gadījums, scenāriji, kas jāparaksta un jādokumentē.
- Nepieciešama testa vide, kas jāizveido integrācijas testēšanai
Izejas kritēriji:
- Veiksmīga integrētās lietojumprogrammas pārbaude.
- Izpildītās pārbaudes lietas ir dokumentētas
- Visas augstas prioritātes kļūdas ir novērstas un aizvērtas
- Iesniedzamie tehniskie dokumenti, kam seko piezīmes par izlaidumu.
Labākā prakse / vadlīnijas integrācijas testēšanai
- Vispirms nosakiet integrācijas testēšanas stratēģiju, ko varētu pieņemt, un vēlāk attiecīgi sagatavojiet testa gadījumus un testa datus.
- Izpētiet lietojumprogrammas arhitektūras dizainu un identificējiet kritiskos moduļus. Tie jāpārbauda prioritāri.
- Iegūstiet saskarnes dizainu no Architectural komandas un izveidojiet testa gadījumus, lai detalizēti pārbaudītu visas saskarnes. Saskarne ar datu bāzi / ārēju aparatūru / programmatūru ir jāpārbauda detalizēti.
- Pēc testa gadījumiem kritisko lomu spēlē testa dati.
- Pirms izpildes vienmēr sagatavojiet izspēles datus. Izpildot pārbaudes gadījumus, neatlasiet testa datus.