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'.

Proč provádět integrační testování?

Přestože je každý softwarový modul testován na jednotku, stále existují chyby z různých důvodů, jako je např

• Modul je obecně navržen individuálním vývojářem softwaru, jehož chápání a programovací logika se mohou lišit od jiných programátorů. Integrační testování se stává nezbytným pro ověření, že softwarové moduly fungují v jednotě
• V době vývoje modulu existuje velká šance na změnu požadavků ze strany klientů. Tyto nové požadavky nemusí být testovány na jednotku, a proto je nutné 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 se liší od ostatních testovacích případů v tom smyslu se zaměřuje především na rozhraní a tok dat/informací mezi moduly. Zde je třeba dát přednost integrující odkazy spíše než funkce jednotky, které jsou již testovány.

Ukázkové integrační testovací případy pro následující scénář: Aplikace má 3 moduly s názvem 'Přihlašovací stránka', 'Mailbox“ a „Smazat e-maily“ a každý z nich je logicky integrován.

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

Podobně Mail Box: Zkontrolujte jeho integraci do Delete 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 Mailbox a Smazat Mails Modul	od Mailvyberte e-mail a klikněte na tlačítko Odstranit	Vybraný e-mail by se měl objevit ve složce Deleted/Trash

Typy integračního testování

Softwarové inženýrství definuje různé strategie 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 shora dolů
  • Přístup zdola nahoru
  • 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:

• Pohodlné pro malé systémy.

Nevýhody:

• Lokalizace závad je obtížná.
• Vzhledem k obrovskému počtu rozhraní, která je třeba v tomto přístupu otestovat, může snadno uniknout některá testovaná propojení rozhraní.
• Vzhledem k tomu, že integrační testování může začít až poté, co jsou navrženy „všechny“ moduly, bude mít testovací tým méně času na provedení ve fázi testování.
• Protože jsou všechny moduly testovány najednou, vysoce rizikové kritické moduly nejsou izolovány a testovány prioritně. Periferní moduly, které se zabývají uživatelskými rozhraními, také nejsou izolované a prioritně testovány.

Přírůstkové testování

v Přírůstkové testování Testování se provádí integrací dvou nebo více modulů, které spolu logicky souvisejí a následně testovány na správné fungování aplikace. Poté jsou postupně integrovány 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

Stubs a Drivers

Stubs a Drivers jsou fiktivní programy v integračním testování používané k usnadnění testování softwaru aktivita. Tyto programy slouží jako náhrada za chybějící modely v testování. Neimplementují celou programovací logiku softwarového modulu, ale simulují datovou komunikaci s volajícím modulem při testování.

Pahýl: Je voláno testovaným modulem.

Řidič: Volá modul, který má být testován.

Testování integrace zdola nahoru

Testování integrace zdola nahoru je strategie, ve které jsou nejprve testovány moduly nižší úrovně. Tyto testované moduly se pak 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 moduly další úrovně.

Schématické znázornění:

Výhody:

• Lokalizace závad je jednodušší.
• Na rozdíl od přístupu velkého třesku neztrácíte čas čekáním na vývoj všech modulů

Nevýhody:

• Kritické moduly (na nejvyšší úrovni softwarové architektury), které řídí tok aplikací, jsou testovány jako poslední a mohou být náchylné k defektům.
• Raný prototyp není možný

Testování integrace shora dolů

Integrační testování shora dolů je metoda, při které probíhá integrační testování shora dolů podle řídicího toku softwarového systému. Nejprve se otestují moduly vyšší úrovně a poté se otestují a integrují moduly nižší úrovně, aby se ověřila funkčnost softwaru. Stub se používají pro testování, pokud některé moduly nejsou připraveny.

Schématické znázornění:

Výhody:

• Lokalizace závad je jednodušší.
• Možnost získat raný prototyp.
• Kritické moduly jsou testovány přednostně; hlavní konstrukční chyby mohly být nalezeny a opraveny jako první.

Nevýhody:

• Potřebuje mnoho pahýlů.
• Moduly na nižší úrovni jsou testovány nedostatečně.

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

Postup testu integrace bez ohledu na strategie testování softwaru (probráno 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).
• Rozsahy a mimo rozsah Položky testování integrace.
• Role a odpovědnosti.
• Předpoklady pro integrační testování.
• Testovací prostředí.
• Plány rizik a zmírňování.

Vstupní a výstupní kritéria integračního testování

Vstupní a výstupní kritéria do fáze testování integrace v jakémkoli modelu vývoje softwaru

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
• Technické dokumenty, které mají být předloženy, následované poznámkami k verzi.

Best Practices/ Guidelines for Integration Testing

• Nejprve určete integraci Testovací strategie které by mohly být přijaty a později podle toho 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í rozhodující roli testovací data.
• Před spuštěním mějte vždy připravená falešná data. Nevybírejte testovací data při provádění testovacích případů.