Integration testing: Intengračné testy a 10 najbežnejších chýb, ktorých sa pri nich dopúšťame

Integračné testovanie – definícia (integration testing – definition)

Integračné testovanie je definované ako typ testovania, pri ktorom sú najmenšie časti aplikácie, moduly a komponenty softvéru integrované a testované ako skupina. Typický softvérový projekt pozostáva z viacerých softvérových modulov, ktoré sú programované rôznymi developermi. Cieľom tejto úrovne testovania je odhaliť chyby v interakcii medzi týmito modulmi.

Integračné testovanie prebieha po unit testovaní a pred testovaním systému. Moduly, ktoré prešli unit testovaním, sa zoskupia do agregátov.

Zmysel integračného testovania (integration testing purpose)

Okrem faktu, že IT testeri musia otestovať všetky softvérové aplikácie pred ich releasnutím do produkcie, existuje niekoľko špecifických dôvodov, prečo by mali testeri vykonávať integračné testovanie:

Nekonzistentná logika kódu: Moduly sú programované rôznymi programátormi, ktorých logika a prístup k vývoju sa navzájom líšia, takže pri integrácii spôsobujú problémy s funkčnosťou alebo použiteľnosťou. Integračné testovanie zabezpečuje, že kód týchto komponentov je zosúladený, čo vedie k funkčnej aplikácii.

Meniace sa požiadavky: Zákazníci často menia svoje požiadavky. Úprava kódu 1 modulu s cieľom prispôsobiť sa novým požiadavkám niekedy znamená zmenu jeho logiky, čo ovplyvňuje celú aplikáciu. V prípade, že z časových dôvodov nie je možné vykonať unit testovanie, na odhalenie chýbajúcich chýb sa použije integračné testovanie.

Chybné údaje: Údaje sa môžu pri prenose medzi vyvíjanými modulmi zmeniť. Ak nie sú pri prenose správne formátované, údaje nie je možné prečítať a spracovať, čo vedie k chybám. Integračné testovanie je potrebné na určenie miesta, kde sa nachádza problém a na jeho odstránenie.

Služby tretích strán a integrácie API: Keďže sa údaje môžu pri prenose meniť, služby API a služby tretích strán môžu prijímať nesprávne vstupy a generovať nesprávne odpovede. Testovanie integrácie zabezpečuje, aby tieto integrácie mohli navzájom dobre komunikovať.

Nedostatočné spracovanie výnimiek: Vývojári zvyčajne vo svojom kóde počítajú s výnimkami, ale niekedy nemôžu úplne vidieť všetky scenáre výnimiek, kým nie sú moduly poskladané dohromady. Integračné testovanie im umožňuje rozpoznať tieto chýbajúce scenáre výnimiek a vykonať opravu.

Externé hardvérové rozhrania: Chyby môžu vzniknúť pri nekompatibilite softvéru a hardvéru, ktorú možno ľahko zistiť pomocou správneho integračného testovania.

Výhody integračného testovania (integration testing benefits)

  • Zabezpečuje, že každý integrovaný modul funguje správne.
  • Odhalí chyby rozhrania.
  • Testeri môžu začať integračné testovanie po dokončení modulu a nemusia čakať, kým bude iný modul hotový a pripravený na testovanie.
  • Testeri môžu odhaliť chyby a bezpečnostné problémy už na začiatku vývojového cyklu.
  • Poskytuje testerom komplexnú analýzu celého systému, čím sa výrazne znižuje pravdepodobnosť závažných problémov s konektivitou.
  • Zabezpečuje to, aby softvérové moduly a komponenty spolupracovali v harmónii.
  • Zvýšenie dôvery vo vývojový cyklus vďaka vyššej spoľahlivosti testov..
  • Vyššie pokrytie kódu a jednoduchšie sledovanie

Príklad integračného testu (integration test example)

Test Case ID

Cieľ testovacieho prípadu

Popis testovacieho prípadu

Očakávaný výsledok

1 Overenie prihlásenia a rozhrania modulu poštovej schránky Zadaj požadované prihlasovacie údaje a klikni na tlačidlo prihlásenia Kontrola sa prenesie do poštovej schránky
2 Overenie poštovej schránky a prepojenia rozhrania modulu Odstrániť poštu Vyber e-mail zo schránky a potom klikni na „odstrániť“. Vybraný e-mail sa odošle do priečinka Odstránené/Trash.

Typy integračného testovania (integration testing types)

integration testing
integration testing diagram

Poznáme 5 foriem integračného testovania:

  • Metóda veľkého tresku (integration testing – big-bang approach)

Táto metóda zahŕňa integráciu všetkých modulov a komponentov a ich testovanie naraz ako jedného celku. Táto metóda je známa aj ako neinkrementálne integračné testovanie.

  • Metóda zdola nahor (integration testing bottom up approach)

Táto metóda vyžaduje najprv testovanie modulov nižšej úrovne, ktoré sa potom použijú na uľahčenie testovania vyšších modulov. Tento proces pokračuje, až kým nie je otestovaný každý modul najvyššej úrovne. Keď sú všetky moduly nižšej úrovne úspešne otestované a integrované, vytvorí sa ďalšia úroveň modulov.

integration testing
integration testing – Bottom Up
  • Hybridná metóda testovania (Hybrid Testing Method)

Táto metóda sa nazýva aj „sendvičové testovanie“. Zahŕňa súčasné testovanie modulov najvyššej úrovne s modulmi nižšej úrovne a integráciu modulov nižšej úrovne s modulmi najvyššej úrovne a ich testovanie ako systému. Tento postup je teda v podstate spojením typov testovania zdola nahor a zhora nadol.

Integration testing Top down, Buttom up - Hybrid
Integration testing Top down, Buttom up – Hybrid
  • Inkrementálny prístup (Incremental Approach)

Tento prístup integruje dva alebo viac logicky súvisiacich modulov a potom ich testuje. Potom sa postupne zavádzajú a integrujú ďalšie súvisiace moduly, až kým sa úspešne neotestujú všetky logicky súvisiace moduly. Tester môže použiť buď metódu zhora nadol, alebo zdola nahor.

  • Prístup zhora nadol (Top-down integration testing)

Na rozdiel od metódy zdola nahor sa pri prístupe zhora nadol najprv testujú moduly vyššej úrovne a postupuje sa až k modulom nižšej úrovne. Ak niektoré moduly nižšej úrovne nie sú pripravené, testeri môžu použiť stubs (útržok kódu, ktorý sa používa na zastupovanie niektorých ďalších funkcií programovania pri vývoji softvéru – môže simulovať správanie existujúceho kódu alebo zastupovať kód, ktorý ešte nebol vyvinutý).

integration testing top down
Integration testing – Top down

Najbežnejšie chyby, ktorých sa pri integračnom testovaní dopúšťame

  1. Výber nesprávneho nástroja

Pri plánovaní integračného testovania je jedným z najdôležitejších rozhodnutí výber správneho nástroja alebo frameworku. Aby si sa uistil, že si si vybral správne, zváž faktory, ako sú typ a zložitosť testovaného systému, použitý programovací jazyk a prostredie, požadovaná úroveň integrácie a pokrytia, rozpočet a dostupné zdroje, kompatibilita a interoperabilita s inými nástrojmi a systémami, ako aj jednoduchosť používania a údržby nástroja. Na vhodný výber nástroja sa odporúča preskúmať rôzne alternatívy a otestovať ich, aby si zistil, ako zodpovedajú tvojim potrebám a očakávaniam.

Viac o výbere vhodného nástroja si prečítaš tu – top integration testing automation tools for 2024.

  1. Zanedbanie návrhu testu

Zanedbanie fázy návrhu testov je častým úskalím, ktoré môže viesť k neadekvátnym alebo nadbytočným testovacím prípadom, chýbajúcim alebo nesprávnym testovacím údajom, nereálnym alebo irelevantným testovacím scenárom, nekonzistentným alebo nejednoznačným výsledkom testov a nespoľahlivým alebo nepresným testovacím správam. Aby sa predišlo týmto problémom, je nevyhnutné dodržiavať systematický a štruktúrovaný prístup k návrhu testov. To zahŕňa identifikáciu integračných bodov a rozhraní medzi komponentmi, definovanie úrovní a typov testov (napr. zdola nahor, zhora nadol, big-bang atď.), špecifikáciu cieľov a požiadaviek na testovanie (napr. funkčné, nefunkčné atď.), návrh testovacích prípadov a údajov na základe cieľov a požiadaviek a preskúmanie a overenie návrhu so zainteresovanými stranami a odborníkmi.

  1. Zneužívanie funkcií nástroja

Pri používaní nástrojov na integračné testovanie je dôležité vyhnúť sa nesprávnemu alebo nadmernému využívaniu ich funkcií. Nástroje na integračné testovanie môžu ponúkať mnoho výhod a možností, ako je automatizácia vykonávania a overovania testov, generovanie a manipulácia s testovacími údajmi, simulácia, meranie a vykazovanie pokrytia a kvality testov a integrácia s inými nástrojmi. Môžu však prinášať aj niektoré nevýhody a riziká, ako napríklad zavádzanie chýb do testovacích skriptov alebo kódu, vytváranie závislostí alebo konfliktov s nástrojom alebo jeho komponentmi, zníženie prehľadu alebo kontroly nad procesom testovania alebo výsledkami, zvýšenie zložitosti testovacieho prostredia alebo infraštruktúry alebo obmedzenie flexibility testovacieho prístupu alebo rozsahu.

Ignorovanie spätnej väzby

Pri používaní nástrojov na integračné testovanie je nevyhnutné vyhnúť sa ignorovaniu spätnej väzby. Ide o mechanizmus, ktorý umožňuje zhromažďovať, analyzovať a konať na základe informácií a poznatkov získaných z integračných testov. Bez správnej spätnej väzby môžeš prísť o odhalenie a vyriešenie chýb alebo problémov v testovanom systéme alebo testovacom prostredí, optimalizáciu výkonu, funkčnosti alebo spoľahlivosti systému, zlepšenie návrhu testov, ich vykonania alebo reportovania, získanie osvedčených postupov z testovania a komunikáciu a spoluprácu s ostatnými zainteresovanými stranami v životnom cykle vývoja softvéru.

Nedostatok testov

Testovanie je „súčasťou definície DONE“ – nemôžeš dokončiť úlohu, ak si ju neotestoval. V skutočnosti sú však vývojári hodnotení podľa počtu story pointov storiek, ktoré dokončia a nie podľa hĺbky alebo kvality testovacieho kódu, ktorý vytvoria.

To môže viesť k situácii, keď sa časti aplikácie netestujú alebo sa testujú veľmi povrchne, čo vedie k chybám, ktoré sa odhalia až v produkcii.

Príliš veľa testov

V organizáciách, v ktorých je kvalita silnou hnacou silou a to z dôvodu kultúry, požiadaviek manažmentu alebo veľmi náročných zákazníkov, môže byť tendencia k nadmernému testovaniu. Do budovania agilných infraštruktúr na testovanie kontinuálnej integrácie sa môžu investovať obrovské zdroje, čo vedie k obrovským testovacím súborom, ktorých spustenie trvá dlho a ktorých údržba je nerealizovateľná. Potom má armáda teserov za úlohu „optimalizovať testy“ – dosiahnuť, aby táto testovacia sada bežala len 20 minút namiesto 15 hodín.

Každý test, ktorý sa nedá udržiavať v priebehu času s existujúcimi zdrojmi, je pre systém záťažou. Vyhni sa vytváraniu automatizovaných testov, ktoré nemôžeš udržiavať alebo ktoré nemôžeš rozumne spustiť v rámci cyklu CI.

  1. Spoliehanie sa na zbytočné testovacie metriky

Niektoré testovacie metriky sú jednoducho zbytočné –

  • Počet vykonaných testovacích prípadov – nedokáže ti povedať, aké testovacie prípady sa testujú a či sú vôbec účinné
  • Počet chýb na jedného testera – podporuje neefektívnosť, napríklad objavovanie nezmyselných chýb a podporuje mentalitu „každý za seba“.
  • Percentuálna úspešnosť – ľahko manipulovateľná, napríklad jeden dlhý test sa môže rozdeliť na mnoho malých, čím sa umelo zvýši úspešnosť.
  • Pokrytie kódu unit testami – nezohľadňuje kvalitu unit testov a tiež iné typy testovania, ako napríklad integračné a systémové testovanie, ktoré sú kľúčové.
  • Percento automatizácie – znie to výborne, ale neodhaľuje to kvalitu automatizácie. Ak sú automatizované testy zle navrhnuté, budeš na tom v tíme horšie ako v časoch manuálneho testovania.
  1. Ilúzia pokrytia testov

Súvisí s predchádzajúcim bodom – mnohé agilné tímy merajú pokrytie kódu alebo množstvo unit testov a považujú to za mieru svojho „test coverage“. Niektoré sa dokonca usilujú o 100 % pokrytie kódu a veria, že sa to aspoň do určitej miery rovná úplnému pokrytiu testami.

  1. Testovanie negatívnych scenárov

Negatívne scenáre sú dôležitou súčasťou hodnotenia každého softvérového produktu, pretože overujú, ako sa systém správa, keď používateľ zadá neplatný, neočakávaný vstup. Takýto neočakávaný vstup sa nevyskytuje často, preto ho testeri zvyčajne úplne ignorujú a zameriavajú sa na „happy path“.

Testovaním negatívnych scenárov môžu testeri určiť podmienky, za ktorých môžu aplikácie spadnúť, zvýšiť pokrytie testov a zabezpečiť, aby bola v softvéri prítomná dostatočná validácia chýb.

Je však veľkou chybou zahrnúť negatívne scenáre do integračného testovania. Negatívne testovacie prípady si vyžadujú veľa nastavení, to výrazne predlžuje čas tvorby testov.

ruky pracujú na laptope

Najlepšie postupy integračných testov (integration testing – best practices)

1.     Navrhni nezávislé testy

Výsledok 1 testu by nemal ovplyvniť výsledok iného testu a všetky potrebné údaje a zdroje potrebné na spustenie testu vrátane konfiguračných súborov, databáz, premenných prostredia by mali byť vždy zahrnuté v samotnom teste. Prijatím tohto postupu budú testy spoľahlivejšie, pretože závislosť od externých zdrojov môže v prípade akýchkoľvek zmien spôsobiť neočakávané správanie.

2.     Pred vykonaním integračného testu starostlivo urč stratégiu integračného testu

Ak sa rozhodneš použiť na integračné testovanie prístup inkrementálnej integrácie, je nevyhnutné dôkladne preštudovať systém a navrhnúť integračnú stratégiu:

  • Pochop návrh architektúry aplikácie a identifikuj kritické moduly
  • V závislosti od toho, či použiješ prístup zhora nadol alebo zdola nahor, môžeš segmentovať moduly s vysokou prioritou
  • Spolupracuj s vývojármi a príslušnými zainteresovanými stranami na identifikácii požiadaviek (aké funkcie sa majú testovať, aké moduly sú zapojené do testov, aké systémové požiadavky a testovacie údaje sú potrebné na spustenie testu atď.)
  • Identifikuj „stubs“ a „ovládače“, ktoré treba pripraviť a udržiavať

Kontinuálne integračné testovanie vyžaduje, aby tímy QA testovali funkcie okamžite v produkcii na získanie rýchlej spätnej väzby, ale niekedy nemusia byť vždy k dispozícii určité moduly potrebné na testovanie. V takýchto prípadoch musia tímy QA vytvoriť „stubs“ a „drivers (ovládače)“, ktoré v podstate nahrádzajú nedostupné moduly.

3.     Over integritu údajov medzi systémami

Pri prenose údajov medzi modulmi a systémami môže dôjsť k ich strate, zmene formátu alebo ohrozeniu a integrita údajov je zárukou, že sa tak nestalo spôsobom, ktorý môže ovplyvniť výsledky testov. Na dosiahnutie tohto cieľa by testeri mali pre každý systém vytvoriť základnú úroveň údajov, ktorá zahŕňa pôvodné hodnoty údajov. Po ukončení integračných testov môžeme porovnať nové hodnoty s východiskovými, aby sme identifikovali nezrovnalosti. Tento proces sa dá úplne automatizovať.

4.     Nepoužívaj pevne zakódované hodnoty

Pri výbere vstupných údajov sa môže zdať, že použitie pevne kódovaných hodnôt je najjednoduchším riešením. Môže to dobre fungovať pri jednotlivých testoch, ktoré sa vykonávajú izolovane, ale môže to spôsobiť problémy pri opakovaní testov. Napríklad pri prvom spustení testu môže aplikácia na základe vstupov z testu uložiť položky databázy. Keď sa test spustí druhýkrát s použitím rovnakých vstupných údajov, záznamy v databáze už budú existovať. Najbezpečnejším prístupom je často použitie náhodných vstupných údajov.

5.     Nespúšťaj testy na staging prostredí

Spúšťanie integračných testov v prostredí staging alebo predprodukčnom prostredí sa môže zdať ako samozrejmosť. Zo skúseností však vyplýva, že spúšťanie integračných testov v plne integrovaných prostrediach môže spôsobiť viac škody ako úžitku. Keďže integračné testy často používajú falošné alebo nezmyselné údaje, testy v jednej aplikácii môžu často viesť k nepredvídaným chybám v nadväzujúcich aplikáciách. Tieto chyby môžu byť problematické pri diagnostike a môžu odvádzať pozornosť od skutočných chýb na iných miestach.

6.     Testuj jednu vec

Tak ako pri všetkých automatizovaných testoch, aj tu platí, že pri každom teste je vhodné testovať jednu operáciu. Testy s malým rozsahom sa rýchlo debuggujú a zlyhania sa ľahšie reprodukujú a opravujú.

7.     Používaj obchodné názvy

Integračné testy by sa mali písať s ohľadom na koncového používateľa. Snaž sa používať doménový jazyk a opisovať správanie, nie implementáciu.

8.     Navrhuj testy tak, aby sa dali spustiť súbežne

Integračné testy sa zo svojej podstaty vykonávajú pomalšie ako unit testy. Preto je ešte dôležitejšie obmedziť počet testov, ktoré píšeš a ak je to možné, spúšťať ich paralelne. Paralelné vykonávanie je súčasťou väčšiny moderných testovacích frameworkov.

9.     Začni integračné testovanie čo najskôr

Vďaka dnešnej agilnej metodike môžu vývojári vykonávať integračné testovanie už v skoršej fáze projektu. To znamená, že môžu skôr nájsť chyby a problémy s integráciou, čím sa zabezpečí rýchlejší release pre verejnosť.

Zhrnutie

Integračné testovanie má zásadný význam pri zabezpečovaní funkčnosti a interakcií medzi rôznymi softvérovými modulmi. Preto sa hojne využíva pri testovaní rôznych typov softvéru v rôznych odvetviach, od SaaS až po elektronické obchodovanie. Odporúča sa však vykonať integračné testovanie po testovaní jednotiek, aby sa otestovali funkcie jednotlivých jednotiek a funkčnosť a interakcie medzi týmito jednotkami s cieľom zabezpečiť optimálnu kvalitu softvéru.

Ak si IT tester a vieš po nemecky, pozri si naše firemné benefity a reaguj na pracovné ponuky.

O autorovi

Michaela Kojnoková

Agile Test Engineer

Po štúdiu informatiky na ŽU a TUKE som sa najviac ponorila do oblasti automatizácie testovania. Okrem toho sa venujem tvorbe webov, databázam, dátovej analytike, umelej inteligencii a strojovému učeniu. Mám rada cestovanie, šport a najviac si užívam čas strávený v prírode s mojimi blízkymi. LinkedIn

Daj nám o sebe vedieť