Co je integrační testování? (Příklad)

Co je integrační testování?

Testování integrace je definován jako typ testování, kde jsou softwarové moduly integrovány logicky a testovány jako skupina. Typický softwarový projekt se skládá z několika softwarových modulů, kódovaných různými programátory. Účelem této úrovně testování je odhalit defekty v interakci mezi těmito softwarovými moduly, když jsou integrovány

Integrační testování se zaměřuje na kontrolu datové komunikace mezi těmito moduly. Proto se také nazývá jako 'TO' (Integrace a testování), 'Testování řetězců' a někdy 'Testování vláken'.

Kdy a proč provádět integrační testování?

Integrační testování se používá po jednotkových testech a před úplným testováním systému. Je nejužitečnější při ověřování toku dat, sdílených API a vzájemně závislých modulů v různých prostředích. Včasným spuštěním integračních testů mohou týmy odhalit neshody rozhraní, chybějící datové kontrakty a selhání závislostí, které jednotkové testy často přehlížejí.

Integrační testování byste měli používat, když si musí data vyměňovat více modulů nebo služeb, když se jedná o integrace třetích stran a kdykoli by změny v jednom modulu mohly ovlivnit ostatní. Snižuje únik vad, zlepšuje celkovou kvalitu a poskytuje jistotu, že systém může spolehlivě fungovat, než se přistoupí k testování nebo vydání ve větším měřítku.

Přestože je každý softwarový modul jednotkově testován, stále existují vady z různých důvodů, jako například

• Modul je obecně navržen jednotlivým vývojářem softwaru, jehož chápání a programovací logika se mohou lišit od chápání a programovací logiky ostatních programátorů. Integrační testování je nezbytné k ověření, zda softwarové moduly fungují v souladu.
• V době vývoje modulů existuje vysoká pravděpodobnost změn požadavků ze strany klientů. Tyto nové požadavky nemusí být jednotkově testovány, a proto je nezbytné testování systémové integrace.
• Rozhraní softwarových modulů s databází může být chybné
• Externí hardwarová rozhraní, pokud existují, mohou být chybná
• Nedostatečné zpracování výjimek může způsobit problémy.

klikněte zde pokud video není přístupné

Příklad integračního testovacího případu

Integrace Testovací případ liší se od ostatních testovacích případů v tom smyslu, že se zaměřuje především na rozhraní a tok dat/informací mezi modulyZde je třeba dát přednost integrující odkazy spíše než funkce jednotky, které jsou již otestovány.

Ukázkové testovací případy integrace pro následující scénář: Aplikace má 3 moduly, například „Přihlašovací stránka“, „Mail„box“ a „Smazat e-maily“, přičemž každá z nich je logicky integrována.

Zde se příliš nezaměřujte na testování přihlašovací stránky, protože to již bylo provedeno v Testování jednotek. Ale zkontrolujte, jak je to spojeno s Mail Box Page.

Podobně, Mail BoxZkontrolujte jeho integraci s funkcí Smazat Mails Modul.

ID testovacího případu	Cíl testovacího případu	Testovací případ Description	Očekávaný výsledek
1	Zkontrolujte propojení rozhraní mezi přihlášením a Mailkrabicový modul	Zadejte přihlašovací údaje a klikněte na tlačítko Přihlásit	Chcete-li být nasměrováni na Mail Box
2	Zkontrolujte propojení rozhraní mezi Mailpole a tlačítko Odstranit Mails Modul	od Mailpole, vyberte e-mail a klikněte na tlačítko Smazat	Vybraný e-mail by se měl objevit ve složce Deleted/Trash

Typy integračního testování

Softwarové inženýrství definuje řadu strategií pro provádění integračního testování, viz.

• Přístup velkého třesku:
• Incremental Approach: který se dále dělí na následující
  • Přístup zdola nahoru
  • Přístup shora dolů
  • Sendvičový přístup – kombinace shora dolů a zdola nahoru

Níže jsou uvedeny různé strategie, způsob jejich provádění a jejich omezení a také výhody.

Testování velkého třesku

Testování velkého třesku je přístup k testování integrace, ve kterém jsou všechny komponenty nebo moduly integrovány dohromady a poté testovány jako celek. Tato kombinovaná sada komponent je při testování považována za entitu. Pokud nejsou dokončeny všechny součásti v jednotce, proces integrace se neprovede.

Výhody:

• Rychlejší nastavení – Všechny moduly integrované najednou.
• Úplný pohled na systém – Okamžitě pozorujte celkové chování.
• Žádné pahýly/ovladače – Snižuje dodatečné úsilí vynaložené na vývoj.
• Dobré pro malé projekty – Jednodušší systémy se dobře hodí.
• Uživatelsky orientovaný – Velmi podobá se zkušenostem koncového uživatele.

Nevýhody:

• Těžko ladit – Selhání je hůře izolovatelné.
• Pozdní zjištění závady – Chyby nalezené až po plné integraci.
• Vysoké riziko – Závažné problémy mohou zablokovat celé testování.
• Není škálovatelné – Složité systémy se stávají nezvládnutelnými.
• Slabé pokrytí testy – Některé moduly nebyly dostatečně otestovány.

Přírůstkové testování

v Přírůstkové testování V tomto přístupu se testování provádí integrací dvou nebo více modulů, které spolu logicky souvisejí, a následným testováním správného fungování aplikace. Poté se postupně integrují další související moduly a proces pokračuje, dokud nejsou všechny logicky související moduly integrovány a úspěšně otestovány.

Inkrementální přístup se zase provádí dvěma různými metodami:

• Zdola nahoru
• Vzhůru nohama
• Sendvičový přístup

Testování integrace zdola nahoru

Testování integrace zdola nahoru je strategie, při které se nejprve testují moduly nižší úrovně. Tyto testované moduly se poté dále používají k usnadnění testování modulů vyšší úrovně. Proces pokračuje, dokud nejsou otestovány všechny moduly na nejvyšší úrovni. Jakmile jsou moduly nižší úrovně otestovány a integrovány, vytvoří se další úroveň modulů.

Schématické znázornění:

Výhody:

• Rané testování modulů – Nejprve testovány moduly nižší úrovně.
• Snadnější ladění – Vady izolované na úrovni modulů.
• Žádné pahýly nejsou potřeba – Ovladače se vytvářejí jednodušší.
• Spolehlivý základ – Základní moduly testované před vyššími úrovněmi.
• Progresivní integrace – Systém stabilně a sebejistě roste.

Nevýhody:

• Zobrazení pozdě uživatelem – Celý systém je viditelný pouze na konci.
• Potřebuje řidiče – Množství úsilí na sestavení ovladačů.
• Uživatelské rozhraní zpožděno – Rozhraní nejvyšší úrovně testována velmi pozdě.
• Časově náročné – Postupná integrace trvá déle.
• Mezery v testech – Interakce na vysoké úrovni mohou problémy přehlédnout.

Testování integrace shora dolů

Testování integrace shora dolů je metoda, při které integrační testování probíhá odshora dolů a sleduje řídicí tok softwarového systému. Nejprve se testují moduly vyšší úrovně a poté se testují a integrují moduly nižší úrovně, aby se ověřila funkčnost softwaru. Stuby se používají k testování, pokud některé moduly nejsou připraveny.

Výhody:

• Názor prvních uživatelů – Rozhraní testovaná od začátku.
• Nejprve kritické moduly – Logika na vysoké úrovni ověřena včas.
• Progresivní integrace – Problémy zachycené krok za krokem.
• Nejsou potřeba žádní řidiči – Vyžadují se pouze pahýly.
• Včasné ověření návrhu – Rychle potvrzuje architekturu systému.

Nevýhody:

• Potřebuje pahýly – Psaní mnoha pahýlů vyžaduje více úsilí.
• Spodní moduly zpožděny – Základní moduly testovány později.
• Neúplné rané testy – Chybějící detaily z neintegrovaných modulů.
• Složitější ladění – Chyby se mohou šířit ze stubů.
• Časově náročné – Vytváření stubů zpomaluje proces.

Výhody:

• Vyvážený přístup – Kombinuje silné stránky shora dolů a zdola nahoru.
• Paralelní testování – Horní a spodní moduly testovány současně.
• Rychlejší pokrytí – Více modulů testovaných dříve.
• Prioritizace kritických modulů – Ověřeny jak vysoké, tak nízké hladiny.
• Snížené riziko – Problémy zjištěny na obou stranách.

Nevýhody:

• Vysoká složitost – Obtížnější plánování a řízení.
• Potřebuje pahýly/ovladače – Mimořádné úsilí pro testovací lešení.
• Nákladné – Je zapotřebí více zdrojů a času.
• Prostřední moduly zpožděny – Testováno pouze po horní a spodní části.
• Není ideální pro malé systémy – Režijní náklady převažují nad benefity.

Co jsou stuby a ovladače v integračním testování?

Stuby a ovladače jsou nezbytné fiktivní programy, které umožňují integrační testování, když nejsou všechny moduly k dispozici současně. Tyto duplikáty testů simulují chybějící komponenty, což umožňuje pokračovat v testování bez čekání na kompletní vývoj systému.

Co jsou to pahýly?

Stuby jsou fiktivní moduly, které nahrazují komponenty nižší úrovně, které dosud nebyly vyvinuty nebo integrovány. Jsou volány testovaným modulem a vracejí předdefinované odpovědi. Například při testování modulu pro zpracování plateb, který vyžaduje výpočet daně, může stub vracet pevné hodnoty daně, dokud není připraven skutečný daňový modul.

Charakteristika pahýlů:

• Simulace chování modulů nižší úrovně
• Vrátit pevně zakódované nebo jednoduše vypočítané hodnoty
• Používá se v integračním testování shora dolů
• Minimální implementace funkcionality

Co jsou ovladače?

Ovladače jsou fiktivní programy, které volají testovaný modul a simulují komponenty vyšší úrovně. Předávají testovací data modulům nižší úrovně a shromažďují výsledky. Například při testování databázového modulu ovladač simuluje vrstvu obchodní logiky a odesílá dotazy.

Charakteristika řidičů:

• Vyvolání testovaných modulů s testovacími daty
• Zachycení a ověření odpovědí
• Používá se v integračním testování zdola nahoru
• Tok provádění řídicího testu

Praktický příklad implementace

Payment Module Testing:
- Stub: Simulates tax calculation service returning 10% tax
- Driver: Simulates checkout process calling payment module
- Result: Payment module tested independently of unavailable components

Kdy použít který z nich?

Složka	Použít pahýl	Použít ovladač
Testovací přístup	Testování shora dolů	Testování zdola nahoru
Nahrazuje	Moduly nižší úrovně	Moduly vyšší úrovně
funkce	Vrací fiktivní data	Odesílá testovací data
Komplexita	Jednoduché odpovědi	Orchestrace testů

Stuby a ovladače snižují závislosti na testování, umožňují paralelní vývoj a urychlují testovací cykly eliminací čekacích dob na úplnou dostupnost systému.

Jak provést integrační testování?

Postup integračního testování bez ohledu na strategie testování softwaru (popsané výše):

1. Připravte integraci Plán testů
2. Navrhněte testovací scénáře, případy a skripty.
3. Provedení testovacích případů s následným nahlášením závad.
4. Sledování a opětovné testování závad.
5. Kroky 3 a 4 se opakují, dokud není integrace úspěšná.

Stručný Descriptintegračních testovacích plánů

Zahrnuje následující atributy:

• Metody/přístupy k testování (jak bylo diskutováno výše).
• Rozsah a položky mimo rozsah integračního testování.
• Role a odpovědnosti.
• Předpoklady pro integrační testování.
• Testovací prostředí.
• Plány rizik a zmírňování.

Jaká jsou vstupní a výstupní kritéria pro integrační testování?

Vstupní a výstupní kritéria definují jasné kontrolní body pro zahájení a dokončení integračního testování, čímž je zajištěn systematický postup v celém životním cyklu testování a zároveň zachování standardů kvality.

Kritéria vstupu:

• Součásti/moduly testované na jednotku
• Všechny chyby s vysokou prioritou opraveny a uzavřeny
• Všechny moduly musí být úspěšně dokončeny a integrovány.
• Integrační testy Plán, testovací případ, scénáře, které mají být podepsány a zdokumentovány.
• Požadovaný Testovací prostředí které mají být nastaveny pro testování integrace

Kritéria výstupu:

• Úspěšné testování integrované aplikace.
• Provedené testovací případy jsou zdokumentovány
• Všechny chyby s vysokou prioritou opraveny a uzavřeny
• Je třeba předložit technické dokumenty a následně poznámky k vydání.

Jak byste navrhli integrační testovací případy?

Silný integrační test ověřuje, jak si moduly vyměňují data v reálných pracovních postupech. Níže je uveden příklad proces přihlášení uživatele který integruje vrstvy uživatelského rozhraní, API a databáze:

Krok	Vstup	Očekávaný výsledek
1	Uživatel zadá na přihlašovací obrazovce platné přihlašovací údaje	Přihlašovací údaje bezpečně odeslané do ověřovacího API
2	API ověřuje přihlašovací údaje v databázi	Databáze potvrzuje shodu uživatelského jména/hesla
3	API vrací ověřovací token	Token vygenerován a odeslán zpět do aplikace
4	Uživatelské rozhraní přesměruje uživatele na dashboard	Uživatelská relace byla úspěšně navázána

Tento jednoduchý postup potvrzuje komunikaci mezi třemi kritickými moduly: Uživatelské rozhraní → API → DatabázeNeúspěšný krok přesně ukazuje, kde integrace přerušuje, což pomáhá týmům izolovat vady rychleji než pouhé testování na úrovni systému.

Best Practices/ Guidelines for Integration Testing

• Nejprve určete integraci Testovací strategie které by mohly být přijaty, a později odpovídajícím způsobem připravit testovací případy a testovací data.
• Prostudujte si Architecture design aplikace a identifikaci kritických modulů. Ty je třeba přednostně otestovat.
• Získejte návrhy rozhraní z Architechnický tým a vytvářejte testovací případy k podrobnému ověření všech rozhraní. Rozhraní k databázi/externí hardwarové/softwarové aplikaci musí být detailně otestováno.
• Po testovacích případech hrají klíčovou roli testovací data.
• Před spuštěním mějte vždy připravená simulovaná data. Během provádění testovacích případů nevybírejte testovací data.

Společné výzvy a řešení

Integrační testování představuje jedinečné překážky, které mohou ovlivnit časové harmonogramy a kvalitu projektu. Zde jsou nejzávažnější výzvy a jejich praktická řešení.

1. Správa komplexních závislostí

Challenge: Vícenásobné závislosti modulů vytvářejí složité testovací scénáře s kaskádovitými selháními.

Řešení: Používejte vkládání závislostí, kontejnerizaci (Docker) a testujte v inkrementálních vrstvách. Zdokumentujte všechna propojení v maticích závislostí.

2. Neúplné moduly

Challenge: Testování je blokováno, pokud závislé moduly nejsou připraveny.

Řešení: Včas vyvíjejte komplexní stuby/ovladače, používejte virtualizaci služeb (WireMock) a implementovat testování smluv s dobře definovanými rozhraními.

3. Správa testovacích dat

Challenge: Udržování konzistentních a realistických testovacích dat napříč systémy.

Řešení: Implementujte automatizované generování testovacích dat, používejte snímky databáze pro rychlé resety a kontrolujte verze testovacích dat spolu s testovacími případy.

4. Konfigurace prostředí

Challenge: Nekonzistentní prostředí způsobují selhání integrace.

Řešení: Používejte infrastrukturu jako kód (IaC), kontejnerizaci pro zajištění parity prostředí a nástroje pro správu konfigurace, jako je Ansible.

5. Ladění chyb integrace

Challenge: Identifikace hlavních příčin napříč více složkami je složitá.

Řešení: Implementujte komplexní protokolování, používejte distribuované trasování (Jaeger/Zipkin) a přidávejte korelační ID pro sledování požadavků napříč službami.

6. Integrace služeb třetích stran

Challenge: Nedostupnost externích služeb nebo změny API narušují testování.

Řešení: Simulované externí služby (Postman Mock Server), implementujte mechanismy opakování a udržujte testování kompatibility verzí API.

7. Úzká místa výkonu

Challenge: Integrační body se při zatížení stávají úzkými hrdly.

Řešení: Provádějte včasné profilování výkonu, implementujte strategie ukládání do mezipaměti a v případě potřeby používejte asynchronní komunikaci.

Nejčastější dotazy

Shrnutí