
Business & Integration IT konzultant
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.
V článku sa dozvieš:
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.
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.
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. |
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.
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.
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.
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.
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ý).
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.
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.
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.
Niektoré testovacie metriky sú jednoducho zbytočné –
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.
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.
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.
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:
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.
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ť.
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.
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.
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ú.
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.
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.
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ť.
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, si IT tester alebo automatizovaný tester, pozri si naše firemné benefity a reaguj na pracovné ponuky.