Menu

Čo je testovanie integrácie (návod s príkladom testovania integrácie)

what is integration testing

Vyskúšajte Náš Nástroj Na Odstránenie Problémov

Čo je Testovanie integrácie: Učte sa s príkladmi Testovania integrácie

Testovanie integrácie sa vykonáva na otestovanie modulov / komponentov, keď sú integrované, aby sa overilo, či fungujú podľa očakávania, t. J. Na testovanie jednotlivých modulov, ktoré fungujú dobre, nemá problémy pri integrácii.

Keď hovoríme o testovaní veľkých aplikácií pomocou testovacej techniky čiernej skrinky, ide o kombináciu mnohých modulov, ktoré sú navzájom úzko spojené. Na testovanie týchto typov scenárov môžeme použiť koncepty testovacej techniky integrácie.

Zoznam tutoriálov zahrnutých v tejto sérii:

Výukový program č. 1: Čo je testovanie integrácie? (Tento návod)
Výukový program č. 2: Čo je to prírastkové testovanie
Výukový program č. 3: Čo je to testovanie komponentov
Výukový program č. 4: Nepretržitá integrácia
Výukový program č. 5 Rozdiel medzi testovaním jednotiek a integráciou
Výukový program č. 6: Najlepšie 10 nástrojov na testovanie integrácie

čo je testovanie integrácie

Čo sa dozviete:

Čo je testovanie integrácie?

Význam integračného testovania je celkom priamy - Integrujte / kombinujte modul testovaný na jednotku jeden po druhom a testujte správanie ako kombinovaná jednotka.

Hlavnou funkciou alebo cieľom tohto testovania je testovanie rozhraní medzi jednotkami / modulmi.

Testovanie integrácie normálne robíme po „Testovaní jednotky“. Po vytvorení a otestovaní všetkých jednotlivých jednotiek začneme kombinovať tieto moduly „Unit Tested“ a začneme robiť integrované testovanie.

Hlavnou funkciou alebo cieľom tohto testovania je testovanie rozhraní medzi jednotkami / modulmi.

Jednotlivé moduly sú najskôr testované izolovane. Akonáhle sú moduly testované na jednotku, sú integrované jeden po druhom, až kým nie sú integrované všetky moduly, aby sa skontrolovalo kombinačné správanie a overilo sa, či sú požiadavky implementované správne alebo nie.

Tu by sme mali pochopiť, že integračné testovanie sa neuskutoční na konci cyklu, ale sa uskutoční súčasne s vývojom. Takže vo väčšine prípadov nie sú všetky moduly skutočne k dispozícii na testovanie, a preto je výzvou otestovať niečo, čo neexistuje!

Prečo integračný test?

Cítime, že testovanie integrácie je zložité a vyžaduje určitý vývoj a logické schopnosti. To je pravda! Aký je potom účel integrácie tohto testovania do našej testovacej stratégie?

Tu je niekoľko dôvodov:

  1. V skutočnom svete sa vývoj aplikácií rozdeľuje na menšie moduly a jednotlivým vývojárom sa priradí 1 modul. Logika implementovaná jedným vývojárom sa úplne líši od iného vývojára, takže je dôležité skontrolovať, či logika implementovaná vývojárom zodpovedá očakávaniam a poskytuje správnu hodnotu v súlade s predpísanými normami.
  2. Pri prechode z jedného modulu do druhého sa mnohokrát zmení tvár alebo štruktúra údajov. Niektoré hodnoty sú pripojené alebo odstránené, čo spôsobuje problémy v neskorších moduloch.
  3. Moduly tiež interagujú s niektorými nástrojmi alebo API tretích strán, ktoré tiež musia byť otestované, či sú údaje akceptované týmto API / nástrojom správne a či je generovaná odpoveď tiež podľa očakávaní.
  4. Veľmi častý problém pri testovaní - častá zmena požiadaviek! :) Mnohokrát vývojár zavádza zmeny bez toho, aby ich jednotka otestovala. V tom čase sa stáva dôležitým testovanie integrácie.

Výhody

Existuje niekoľko výhod tohto testovania a niekoľko z nich je uvedených nižšie.

  • Toto testovanie zaisťuje správne fungovanie integrovaných modulov / komponentov.
  • Testovanie integrácie je možné začať, keď budú k dispozícii moduly, ktoré sa majú testovať. Na vykonanie testovania sa nevyžaduje dokončenie druhého modulu, pretože stuby a ovládače sa môžu používať rovnako.
  • Zisťuje chyby súvisiace s rozhraním.

Výzvy

Nižšie je uvedených niekoľko výziev, ktoré sú súčasťou testu integrácie.

# 1) Testovanie integrácie znamená testovanie dvoch alebo viacerých integrovaných systémov, aby sa zabezpečilo správne fungovanie systému. Mali by sa testovať nielen integračné odkazy, ale je potrebné vykonať dôkladné testovanie s ohľadom na prostredie, aby sa zabezpečilo správne fungovanie integrovaného systému.

Na testovanie integrovaného systému môžu byť rôzne cesty a permutácie.

#dva) Správa testovania integrácie sa stáva zložitou z dôvodu niekoľkých faktorov, ako sú databáza, platforma, prostredie atď.

# 3) Integrácia každého nového systému so starým systémom si vyžaduje veľa zmien a testovacieho úsilia. To isté platí pri integrácii akýchkoľvek dvoch starších systémov.

# 4) Integrácia dvoch rôznych systémov vyvinutých dvoma rôznymi spoločnosťami je veľkou výzvou, pretože nie je isté, aký vplyv bude mať jeden zo systémov na druhý systém, ak dôjde k zmenám v ktoromkoľvek zo systémov.

Aby sa minimalizoval dopad pri vývoji systému, malo by sa vziať do úvahy niekoľko vecí, ako je možná integrácia s inými systémami atď.

Typy testovania integrácie

Ďalej je uvedený typ integrácie testu spolu s jeho výhodami a nevýhodami.

Prístup veľkého tresku:

Prístup veľkého tresku integruje všetky moduly naraz, to znamená, že nejde o integráciu modulov jeden po druhom. Overuje, či systém funguje podľa očakávania alebo či nie je integrovaný. Ak sa v úplne integrovanom module zistí akýkoľvek problém, je ťažké zistiť, ktorý modul spôsobil problém.

Prístup veľkého tresku je časovo náročný proces hľadania modulu, ktorý má samotnú chybu, pretože to bude trvať dlho a akonáhle je chyba zistená, jeho oprava by stála vysokú cenu, pretože chyba sa zistí v neskoršej fáze.

Prístup veľkého tresku

Výhody prístupu veľkého tresku:

  • Je to dobrý prístup pre malé systémy.

Nevýhody prístupu veľkého tresku:

  • Je ťažké zistiť modul, ktorý spôsobuje problém.
  • Prístup veľkého tresku vyžaduje na testovanie všetky moduly dohromady, čo zase vedie k kratšiemu času na testovanie, pretože návrh, vývoj a integrácia by zabrali väčšinu času.
  • Testovanie sa uskutočňuje naraz, čím sa nezostane čas na samostatné testovanie kritických modulov.

Kroky testovania integrácie:

  1. Pripravte integráciu Plán skúšok.
  2. Pripravte scenáre a testovacie prípady integrácie.
  3. Pripravte si skripty na automatizáciu testov.
  4. Vykonajte testovacie prípady.
  5. Poruchy nahláste.
  6. Sledujte a znova otestujte chyby.
  7. Opakované testovanie a testovanie pokračuje, kým nie je testovanie integrácie dokončené.

Prístupy integrácie testov

Existujú zásadne 2 prístupy k integrácii testov:

  1. Prístup zdola nahor
  2. Prístup zhora nadol.

Pozrime sa na nasledujúci obrázok, ktorý otestuje prístupy:

Integrácia 1

Prístup zdola nahor:

Testovanie zdola nahor, ako to naznačuje názov, začína od najnižšej alebo najvnútornejšej jednotky aplikácie a postupne sa posúva nahor. Testovanie integrácie sa začína od najnižšieho modulu a postupne postupuje k horným modulom aplikácie. Táto integrácia pokračuje, kým nie sú integrované všetky moduly a celá aplikácia je testovaná ako jedna jednotka.

V tomto prípade sú moduly B1C1, B1C2 a B2C1, B2C2 najnižším modulom, ktorý je testovaný na jednotku. Modul B1 a B2 ešte nie sú vyvinuté. Funkcionalita modulov B1 a B2 spočíva v tom, že volá moduly B1C1, B1C2 a B2C1, B2C2. Pretože B1 a B2 ešte nie sú vyvinuté, potrebovali by sme nejaký program alebo „stimulátor“, ktorý bude volať moduly B1C1, B1C2 a B2C1, B2C2. Tieto stimulačné programy sa nazývajú VODIČI .

Jednoduchými slovami VODIČI sú fiktívne programy, ktoré sa používajú na vyvolanie funkcií najnižšieho modulu v prípade, že volacia funkcia neexistuje. Technika zdola nahor vyžaduje, aby ovládač modulu napájal vstup testovacieho prípadu do rozhrania testovaného modulu.

Výhodou tohto prístupu je, že ak dôjde k závažnej poruche na najnižšej jednotke programu, je ľahšie ju zistiť a je možné prijať nápravné opatrenia.

Nevýhodou je, že hlavný program v skutočnosti neexistuje, kým nie je integrovaný a otestovaný posledný modul. Vo výsledku budú chyby konštrukcie na vyššej úrovni zistené až na konci.

Prístup zhora nadol

Táto technika začína od najvyššieho modulu a postupne postupuje k dolným modulom. Izoluje sa iba horný modul. Potom sú dolné moduly integrované jeden po druhom. Proces sa opakuje, kým nie sú integrované a otestované všetky moduly.

ako tlačiť jeden prvok poľa v jave -

V kontexte nášho obrázku testovanie začína od modulu A a nižšie moduly B1 a B2 sú integrované jeden po druhom. Teraz tu spodné moduly B1 a B2 nie sú v skutočnosti k dispozícii na integráciu. Aby sme teda otestovali najvyššie moduly A, vyvíjame „ STUBS “.

„Pahýly“ možno označiť ako útržok kódu, ktorý prijíma vstupy / požiadavky z horného modulu a vracia výsledky / odpoveď. Takto napriek spodným modulom neexistujú, sme schopní otestovať vrchný modul.

V praktických scenároch nie je správanie pahýľov také jednoduché, ako sa zdá. V tejto ére zložitých modulov a architektúry, tzv. Modulu, väčšinou ide o zložitú obchodnú logiku, ako je pripojenie k databáze. Výsledkom je, že vytváranie pahýlov sa stáva rovnako zložitým a časovo náročným ako skutočný modul. V niektorých prípadoch sa modul pahýľa môže ukázať ako väčší ako stimulovaný modul.

Stubs aj ovládače sú atrapy kódu, ktorý sa používa na testovanie „neexistujúcich“ modulov. Spustia funkcie / metódu a vrátia odpoveď, ktorá sa porovná s očakávaným správaním

Poďme na záver nejaký rozdiel medzi Pahýly a vodič :

PahýlyVodič
Používa sa v prístupe zhora nadolPoužíva sa pri prístupe zdola nahor
Najdôležitejší modul je testovaný ako prvýNajskôr sa testujú najnižšie moduly.
Stimuluje nižšiu úroveň komponentovStimuluje vyššiu úroveň komponentov
Fiktívny program komponentov nižšej úrovneFiktívny program pre komponent vyššej úrovne

Jedinou zmenou je na tomto svete stála zmena, takže máme ďalší prístup s názvom „ Testovanie sendvičov ”, Ktorý kombinuje vlastnosti prístupu zhora nadol aj zdola nahor. Keď testujeme obrovské programy, ako sú operačné systémy, musíme mať k dispozícii nejaké ďalšie techniky, ktoré sú účinné a zvyšujú väčšiu dôveru. Sandwichové testovanie tu hrá veľmi dôležitú úlohu, kde sa testovanie zhora nadol a zdola nahor začína súčasne.

Integrácia sa začína strednou vrstvou a pohybuje sa súčasne smerom hore a dole. V prípade našej postavy začne naše testovanie od B1 a B2, kde jedno rameno bude testovať horný modul A a druhé rameno bude testovať spodné moduly B1C1, B1C2 a B2C1, B2C2.

Pretože obidva prístupy začínajú súčasne, je táto technika trochu zložitá a vyžaduje viac ľudí spolu s konkrétnymi súbormi zručností, a zvyšuje tak náklady.

Test integrácie aplikácií GUI

Teraz si povieme, ako môžeme naznačiť testovanie integrácie v technike Black box.

Všetci chápeme, že webová aplikácia je viacvrstvová aplikácia. Máme klientske rozhranie, ktoré je viditeľné pre používateľa, máme strednú vrstvu, ktorá má obchodnú logiku, máme ďalšiu strednú vrstvu, ktorá vykonáva určité overenia, integruje niektoré API tretích strán atď., Potom máme zadnú vrstvu, ktorá je databázy.

Príklad testovania integrácie:

Pozrime sa na nasledujúci príklad:

Som majiteľom reklamnej spoločnosti a zverejňujem reklamy na rôznych webových stránkach. Na konci mesiaca chcem zistiť, koľko ľudí videlo moje reklamy a koľko ľudí kliklo na moje reklamy. Potrebujem prehľad o svojich zobrazených reklamách a podľa toho účtujem poplatky svojim klientom.

Softvér GenNext vyvinul tento produkt pre mňa a nižšie bola uvedená architektúra:

Integrácia 2

CIBUĽA - Modul užívateľského rozhrania, ktorý je viditeľný pre koncového používateľa a obsahuje všetky vstupy.
BL - Je modul obchodnej logiky, ktorý obsahuje všetky výpočty a obchodné metódy.
VAL - Je modul Validation, ktorý má všetky validácie správnosti vstupu.
CNT - Je modul obsahu, ktorý má všetok statický obsah, špecifický pre vstupy zadané používateľom. Tento obsah sa zobrazuje v prehľadoch.
IN - Je modul Engine, tento modul načítava všetky údaje pochádzajúce z modulov BL, VAL a CNT, extrahuje dopyt SQL a spúšťa ho do databázy.
Plánovač - Je modul, ktorý naplánuje všetky prehľady na základe výberu používateľa (mesačne, štvrťročne, polročne a ročne)
DB - Je to databáza.

Teraz, keď sme videli architektúru celej webovej aplikácie ako jednu jednotku, sa testovanie integrácie v tomto prípade zameria na tok údajov medzi modulmi.

Tu sú otázky:

  1. Ako budú moduly BL, VAL a CNT čítať a interpretovať údaje zadané v module UI?
  2. Prijímajú moduly BL, VAL a CNT správne údaje z používateľského rozhrania?
  3. V akom formáte sa údaje z BL, VAL a CNT prenášajú do modulu EQ?
  4. Ako bude EQ načítať údaje a extrahovať dopyt?
  5. Je dopyt extrahovaný správne?
  6. Získava plánovač správne údaje pre prehľady?
  7. Je výsledný súbor prijatý EN z databázy správny a podľa očakávania?
  8. Je EN schopná odoslať odpoveď späť do modulu BL, VAL a CNT?
  9. Je modul UI schopný načítať údaje a vhodne ich zobraziť na rozhraní?

V skutočnom svete sa komunikácia údajov uskutočňuje vo formáte XML. Takže akékoľvek údaje, ktoré používateľ zadá do používateľského rozhrania, sa prevedú do formátu XML.

V našom scenári sa údaje zadané do modulu používateľského rozhrania prevedú do súboru XML, ktorý je interpretovaný 3 modulmi BL, VAL a CNT. Modul EN načíta výsledný súbor XML vygenerovaný 3 modulmi, extrahuje z neho SQL a zadá dotazy do databázy. Modul EN tiež prijme výsledkovú sadu a prevedie ju do súboru XML a vráti ju späť do modulu používateľského rozhrania, ktorý prevedie výsledky do užívateľsky čitateľnej formy a zobrazí ich.

V strede máme modul plánovača, ktorý prijíma výsledkovú sadu z modulu EN, vytvára a plánuje reporty.

Kam teda príde testovanie integrácie?

Testovanie toho, či informácie / dáta prúdia správne alebo nie, bude vaším integračným testovaním, ktoré by v tomto prípade overovalo súbory XML. Sú súbory XML generované správne? Majú správne údaje? Prenášajú sa údaje správne z jedného modulu do druhého? Všetky tieto veci budú testované v rámci integračného testovania.

Pokúste sa vygenerovať alebo získať súbory XML, aktualizovať značky a skontrolovať správanie. Je to niečo veľmi odlišné od obvyklého testovania, ktoré testeri bežne robia, ale to zvýši hodnotu znalostí a porozumenia aplikácie testermi.

Niekoľko ďalších podmienok testu vzorky môže byť nasledovné:

  • Generujú možnosti ponuky správne okno?
  • Sú okná schopné vyvolať testované okno?
  • Pre každé okno identifikujte volania funkcií pre okno, ktoré by mala aplikácia povoliť.
  • Identifikujte všetky hovory z okna do ďalších funkcií, ktoré by mala aplikácia umožňovať
  • Identifikujte reverzibilné hovory: zatvorenie volaného okna by sa malo vrátiť do volajúceho okna.
  • Identifikujte nezvratné hovory: volanie systému Windows sa zavrie skôr, ako sa zobrazí okno volaného.
  • Vyskúšajte rôzne spôsoby vykonávania hovorov do iného okna, napr. - ponuky, tlačidlá, kľúčové slová.

Kroky na začatie integračných testov

  1. Pochopte architektúru svojej aplikácie.
  2. Identifikujte moduly
  3. Pochopte, čo jednotlivé moduly robia
  4. Pochopte, ako sa údaje prenášajú z jedného modulu do druhého.
  5. Pochopte, ako sa údaje zadávajú a prijímajú do systému (vstupný a výstupný bod aplikácie)
  6. Aplikáciu oddeľte tak, aby vyhovovala vašim testovacím potrebám.
  7. Identifikujte a vytvorte testovacie podmienky
  8. Berte jednu podmienku po druhej a zapisujte si testovacie prípady.

Kritériá vstupu / výstupu pre testovanie integrácie

Kritériá vstupu:

  • Dokument plánu integračného testu je podpísaný a schválený.
  • Boli pripravené integračné testovacie prípady.
  • Testovacie údaje boli vytvorené.
  • Testovanie jednotky vyvinutých modulov / komponentov je hotový.
  • Všetky kritické chyby a chyby vysokej priority sú uzavreté.
  • Testovacie prostredie je nastavené na integráciu.

Kritériá výstupu:

  • Boli vykonané všetky testovacie prípady integrácie.
  • Nie sú otvorené žiadne kritické chyby a chyby priority P1 a P2.
  • Správa o teste bola pripravená.

Testovacie prípady integrácie

Integračné testovacie prípady sa zameriavajú hlavne na rozhranie medzi modulmi, integrované odkazy, prenos dát medzi modulmi ako modulmi / komponentmi, ktoré sú už testované na jednotku, t. j. funkčnosť a ďalšie aspekty testovania už boli pokryté.

Hlavnou myšlienkou je teda otestovať, či integrácia dvoch pracovných modulov funguje podľa očakávania pri integrácii.

Príklady testovacích príkladov integrácie pre aplikáciu Linkedin budú zahŕňať:

  • Overenie prepojenia rozhrania medzi prihlasovacou stránkou a domovskou stránkou, t. J. Keď používateľ zadá poverenia a prihlási sa, malo by to byť nasmerované na domovskú stránku.
  • Malo by sa otvoriť overenie prepojenia rozhrania medzi domovskou stránkou a profilovou stránkou, t. J. Profilovou stránkou.
  • Overte prepojenie rozhrania medzi sieťovou stránkou a stránkami pripojenia, t. J. Kliknutím na tlačidlo Prijať na stránke Pozvánky na stránke so sieťou by sa po kliknutí malo zobraziť prijaté pozvanie na stránke pripojenia.
  • Overte prepojenie rozhrania medzi stránkami s upozorneniami a vyslovte tlačidlo gratulujeme. To znamená, že kliknutie na tlačidlo vysloviť gratulujeme, by malo smerovať do nového okna správy.

Pre tento konkrétny web je možné napísať veľa testovacích prípadov integrácie. Vyššie uvedené štyri body sú iba príkladom na pochopenie toho, aké integračné testovacie prípady sú súčasťou testovania.

Je integrácia technikou bielej alebo čiernej skrinky?

Techniku ​​integračného testovania možno počítať rovnako v oboch čiernych skrinkách technika bielej skrinky . Technika čiernej skrinky je miesto, kde tester nemusí mať interné znalosti systému, t. j. znalosti kódovania sa nevyžadujú, zatiaľ čo technika bielej skrinky vyžaduje interné znalosti aplikácie.

Teraz, keď sa vykonáva testovanie integrácie, by to mohlo zahŕňať testovanie dvoch integrovaných webových služieb, ktoré načítajú údaje z databázy a poskytnú údaje podľa potreby, čo znamená, že je možné ich otestovať pomocou testovacej techniky bielej skrinky, zatiaľ čo integráciu novej funkcie na web je možné otestovať technikou čiernej skrinky.

Nie je teda konkrétne, že testovanie integrácie predstavuje techniku ​​čiernej skrinky alebo bielej skrinky.

Nástroje na integráciu

Pre toto testovanie je k dispozícii niekoľko nástrojov.

Ďalej je uvedený zoznam nástrojov:

  • Tester racionálnej integrácie
  • Uhlomer
  • Parou
  • TESSY

Viac podrobností o vyššie uvedených nástrojoch nájdete v tomto výučbe:

Najlepšie 10 nástrojov na testovanie integrácie na zápis testov integrácie

Testovanie integrácie systému

Testovanie systémovej integrácie sa vykonáva s cieľom otestovať kompletný integrovaný systém .

Moduly alebo komponenty sa pred integráciou komponentov testujú jednotlivo pri jednotkovom testovaní.

Po otestovaní všetkých modulov sa vykoná testovanie integrácie systému integráciou všetkých modulov a otestuje sa systém ako celok.

Rozdiel medzi testovaním integrácie a testovaním systému

Integračné testovanie je testovanie, pri ktorom je na testovanie integrovaný jeden alebo dva moduly, ktoré sú testované na jednotku, a vykonáva sa overenie, aby sa overilo, či integrované moduly fungujú podľa očakávania alebo nie.

Testovanie systému je testovanie, kde systém ako celok je testovaný, to znamená, že všetky moduly / komponenty sú integrované dohromady, aby sa overilo, či systém funguje podľa očakávania a či kvôli integrovaným modulom nedochádza k problémom.

Záver

Toto je všetko o integračnom testovaní a jeho implementácii v technike White box aj Black box. Dúfam, že sme to jasne vysvetlili na relevantných príkladoch.

Integrácia testu je dôležitou súčasťou testovacieho cyklu, pretože uľahčuje hľadanie chyby, keď sú integrované dva alebo viac modulov, aby bolo možné integrovať všetky moduly dohromady v prvom kroku.

Pomáha pri hľadaní defektov v ranom štádiu, čo následne šetrí aj námahu a náklady. Zaisťuje, aby integrované moduly fungovali podľa očakávania.

Dúfam, že tento informatívny návod na Testovanie integrácie by obohatil vaše vedomosti o koncepte.

Odporúčané čítanie

^