Menu

Co je testování integrace (kurz s příkladem testování integrace)

what is integration testing

Vyzkoušejte Náš Nástroj Pro Odstranění Problémů

Co je testování integrace: Učte se s příklady testování integrace

Testování integrace se provádí za účelem otestování modulů / komponent, když jsou integrovány, aby se ověřilo, že fungují podle očekávání, tj. K testování modulů, které fungují samostatně, nemá problémy, pokud jsou integrovány.

Když mluvíme o testování velké aplikace pomocí techniky testování černé skříňky, zahrnuje to kombinaci mnoha modulů, které jsou navzájem pevně spojeny. Pro testování těchto typů scénářů můžeme použít koncepty techniky testování integrace.

Seznam tutoriálů zahrnutých v této sérii:

Výukový program č. 1: Co je testování integrace? (Tento návod)
Výukový program č. 2: Co je to přírůstkové testování
Výukový program č. 3: Co je Testování komponent
Výukový program č. 4: Kontinuální integrace
Výukový program č. 5 Rozdíl mezi testováním jednotek a integrací
Výukový program č. 6: Top 10 nástrojů pro testování integrace

co je testování integrace

Co se naučíte:

Co je testování integrace?

Význam testování integrace je zcela přímočarý - Integrujte / kombinujte modul testovaný na jednotce jeden po druhém a otestujte chování jako kombinovaná jednotka.

Hlavní funkcí nebo cílem tohoto testování je otestovat rozhraní mezi jednotkami / moduly.

Normálně provádíme testování integrace po „testování jednotky“. Jakmile jsou všechny jednotlivé jednotky vytvořeny a otestovány, začneme tyto moduly „Unit Tested“ kombinovat a začneme provádět integrované testování.

Hlavní funkcí nebo cílem tohoto testování je otestovat rozhraní mezi jednotkami / moduly.

Jednotlivé moduly jsou nejprve testovány izolovaně. Jakmile jsou moduly testovány na jednotku, jsou integrovány jeden po druhém, dokud nejsou integrovány všechny moduly, aby bylo možné zkontrolovat kombinační chování a ověřit, zda jsou požadavky implementovány správně nebo ne.

Zde bychom měli pochopit, že testování integrace se neděje na konci cyklu, spíše se provádí současně s vývojem. Takže ve většině případů nejsou všechny moduly skutečně k dispozici k testování a tady je výzva otestovat něco, co neexistuje!

Proč Integration Test?

Cítíme, že testování integrace je složité a vyžaduje určitý vývoj a logické dovednosti. To je pravda! Jaký je účel integrace tohoto testování do naší testovací strategie?

Zde je několik důvodů:

  1. V reálném světě se při vývoji aplikací člení na menší moduly a jednotlivým vývojářům je přiřazen 1 modul. Logika implementovaná jedním vývojářem se zcela liší od jiného vývojáře, takže je důležité zkontrolovat, zda logika implementovaná vývojářem odpovídá očekáváním a vykresluje správnou hodnotu v souladu s předepsanými standardy.
  2. Při přechodu z jednoho modulu do druhého se často mění tvář nebo struktura dat. Některé hodnoty jsou připojeny nebo odebrány, což způsobuje problémy v pozdějších modulech.
  3. Moduly také interagují s některými nástroji nebo API třetích stran, které je také třeba otestovat, zda jsou data přijatá tímto API / nástrojem správná a že generovaná odpověď je také podle očekávání.
  4. Velmi častý problém v testování - časté změny požadavků! :) Mnohokrát vývojář nasadí změny, aniž by je otestoval. V té době se stává důležitým testování integrace.

Výhody

Existuje několik výhod tohoto testování a několik z nich je uvedeno níže.

  • Toto testování zajišťuje správnou funkci integrovaných modulů / komponent.
  • Jakmile budou k dispozici testované moduly, lze zahájit testování integrace. To nevyžaduje, aby byl dokončen další modul, aby bylo možné provést testování, protože Stubs a Drivers lze použít pro stejné.
  • Detekuje chyby související s rozhraním.

Výzvy

Níže je uvedeno několik výzev, které jsou součástí testu integrace.

# 1) Testování integrace znamená testování dvou nebo více integrovaných systémů, aby se zajistilo správné fungování systému. Měly by být testovány nejen integrační odkazy, ale mělo by být provedeno důkladné testování s ohledem na prostředí, aby se zajistilo správné fungování integrovaného systému.

Mohou existovat různé cesty a obměny, které lze použít k testování integrovaného systému.

#dva) Správa testování integrace se stává složitou kvůli několika faktorům, jako je databáze, platforma, prostředí atd.

# 3) Při integraci jakéhokoli nového systému se starým systémem to vyžaduje spoustu změn a úsilí o testování. Totéž platí při integraci jakýchkoli dvou starších systémů.

# 4) Integrace dvou různých systémů vyvinutých dvěma různými společnostmi je velkou výzvou, protože není jisté, jak jeden ze systémů ovlivní druhý systém, pokud dojde k jakýmkoli změnám v kterémkoli ze systémů.

Aby se minimalizoval dopad při vývoji systému, mělo by se brát v úvahu několik věcí, jako je možná integrace s jinými systémy atd.

Druhy testování integrace

Níže je uveden typ integrace testu spolu s jeho výhodami a nevýhodami.

Přístup velkého třesku:

Přístup velkého třesku integruje všechny moduly najednou, tj. Nejde o integraci modulů jeden po druhém. Ověří, zda systém funguje podle očekávání nebo není integrován. Pokud je v plně integrovaném modulu zjištěn jakýkoli problém, je obtížné zjistit, který modul způsobil problém.

Přístup velkého třesku je časově náročný proces hledání modulu, který má samotnou vadu, protože by to vyžadovalo čas a jakmile je vada detekována, její oprava by stála vysokou částku, protože vada je detekována v pozdější fázi.

Přístup velkého třesku

Výhody přístupu velkého třesku:

  • Pro malé systémy je to dobrý přístup.

Nevýhody přístupu velkého třesku:

  • Je obtížné detekovat modul, který způsobuje problém.
  • Přístup velkého třesku vyžaduje pro testování všechny moduly dohromady, což zase vede ke zkrácení času na testování, protože návrh, vývoj a integrace by trvaly většinu času.
  • Testování probíhá pouze najednou, čímž nezůstává čas na testování kritických modulů v izolaci.

Kroky testování integrace:

  1. Připravte integraci Testovací plán.
  2. Připravte scénáře a testovací případy integrace.
  3. Připravte si automatizační skripty testu.
  4. Provádějte testovací případy.
  5. Nahlaste závady.
  6. Sledujte a znovu otestujte vady.
  7. Opakované testování a testování pokračuje, dokud není dokončeno testování integrace.

Testujte integrační přístupy

Existují zásadně 2 přístupy k provádění testovací integrace:

  1. Přístup zdola nahoru
  2. Přístup shora dolů.

Podívejme se na níže uvedený obrázek, abychom otestovali přístupy:

Integrace 1

Přístup zdola nahoru:

Testování zdola nahoru, jak název napovídá, začíná od nejnižší nebo nejvnitřnější jednotky aplikace a postupně se pohybuje nahoru. Testování integrace začíná od nejnižšího modulu a postupně postupuje směrem k horním modulům aplikace. Tato integrace pokračuje, dokud nejsou integrovány všechny moduly a celá aplikace je testována jako jedna jednotka.

V tomto případě jsou moduly B1C1, B1C2 a B2C1, B2C2 nejnižší modul, který je testován na jednotku. Modul B1 a B2 ještě není vyvinut. Funkčnost modulů B1 a B2 spočívá v tom, že volá moduly B1C1, B1C2 a B2C1, B2C2. Protože B1 a B2 ještě nejsou vyvinuté, potřebovali bychom nějaký program nebo „stimulátor“, který bude volat moduly B1C1, B1C2 a B2C1, B2C2. Tyto stimulační programy se nazývají ŘIDIČI .

Jednoduše řečeno, ŘIDIČI jsou fiktivní programy, které se používají k volání funkcí nejnižšího modulu v případě, že volací funkce neexistuje. Technika zdola nahoru vyžaduje, aby ovladač modulu napájel vstup testovacího případu do rozhraní testovaného modulu.

Výhodou tohoto přístupu je, že pokud existuje závažná chyba na nejnižší jednotce programu, je snazší ji detekovat a lze přijmout nápravná opatření.

Nevýhodou je, že hlavní program ve skutečnosti neexistuje, dokud není integrován a otestován poslední modul. Ve výsledku budou chyby návrhu na vyšší úrovni detekovány až na konci.

Přístup shora dolů

Tato technika začíná od nejvyššího modulu a postupně postupuje směrem k nižším modulům. Pouze horní modul je testován samostatně. Poté jsou spodní moduly integrovány jeden po druhém. Proces se opakuje, dokud nejsou všechny moduly integrovány a testovány.

jak zpřístupnit výchozí bránu

V kontextu našeho obrázku začíná testování od modulu A a nižší moduly B1 a B2 jsou integrovány jeden po druhém. Nyní zde nejsou pro integraci k dispozici spodní moduly B1 a B2. Abychom mohli otestovat nejvyšší moduly A, vyvíjíme „ STUBS “.

„Stubs“ lze označovat jako fragment kódu, který přijímá vstupy / požadavky z horního modulu a vrací výsledky / odpověď. Tímto způsobem, navzdory spodním modulům, neexistují, jsme schopni otestovat horní modul.

V praktických scénářích není chování pahýlů tak jednoduché, jak se zdá. V této éře komplexních modulů a architektury, tzv. Modulu, většinou jde o komplexní obchodní logiku, jako je připojení k databázi. Výsledkem je, že vytváření Stubů se stává stejně složitým a časově náročným jako skutečný modul. V některých případech se modul Stub může ukázat být větší než stimulovaný modul.

Jak Stubs, tak ovladače jsou fiktivní částí kódu, která se používá k testování „neexistujících“ modulů. Spustí funkce / metodu a vrátí odpověď, která se porovná s očekávaným chováním

Pojďme uzavřít nějaký rozdíl mezi Pahýly a řidič :

PahýlyŘidič
Používá se v přístupu shora dolůPoužívá se v přístupu zdola nahoru
Nejdůležitější modul je testován jako prvníNejprve se testují nejnižší moduly.
Stimuluje nižší úroveň komponentStimuluje vyšší úroveň komponent
Fiktivní program komponent nižší úrovněFiktivní program pro součást vyšší úrovně

Jedinou změnou je na tomto světě Constant, takže máme další přístup zvaný „ Testování sendvičů “, Který kombinuje funkce přístupu shora dolů i zdola nahoru. Když testujeme obrovské programy, jako jsou operační systémy, musíme mít několik dalších technik, které jsou účinné a zvyšují větší jistotu. Zde hraje velmi důležitou roli sendvičové testování, kde se současně spouští testování shora dolů i zdola nahoru.

Integrace začíná střední vrstvou a pohybuje se současně směrem nahoru a dolů. V případě našeho obrázku bude naše testování zahájeno od B1 a B2, kde jedno rameno bude testovat horní modul A a druhé rameno bude testovat spodní moduly B1C1, B1C2 a B2C1, B2C2.

Jelikož oba přístupy začínají současně, je tato technika trochu složitá a vyžaduje více lidí spolu se specifickými sadami dovedností, což zvyšuje náklady.

Test integrace aplikací GUI

Nyní si promluvme o tom, jak můžeme naznačit integrační testování v technice Black Box.

Všichni chápeme, že webová aplikace je vícevrstvá aplikace. Máme přední část, která je viditelná pro uživatele, máme střední vrstvu, která má obchodní logiku, máme nějakou další střední vrstvu, která provádí nějaké ověření, integruje některé API třetích stran atd., Pak máme zadní vrstvu, která je databáze.

Příklad testování integrace:

Podívejme se na níže uvedený příklad:

Jsem vlastníkem reklamní společnosti a zveřejňuji reklamy na různých webových stránkách. Na konci měsíce chci zjistit, kolik lidí vidělo moje reklamy a kolik lidí kliklo na mé reklamy. Potřebuji přehled zobrazených reklam a podle toho účtuji svým klientům.

Software GenNext vyvinul tento produkt pro mě a níže byla architektura:

Integrace 2

CIBULE - Modul uživatelského rozhraní, který je viditelný pro koncového uživatele, kde jsou uvedeny všechny vstupy.
BL - Je modul Business Logic, který obsahuje všechny výpočty a metody specifické pro podnikání.
VAL - Je modul Ověření, který má všechna ověření správnosti vstupu.
CNT - Je modul obsahu, který má veškerý statický obsah, specifický pro vstupy zadané uživatelem. Tento obsah se zobrazí v přehledech.
V - Je modul Engine, tento modul čte všechna data pocházející z modulu BL, VAL a CNT, extrahuje dotaz SQL a spouští jej do databáze.
Plánovač - Je modul, který naplánuje všechny zprávy na základě výběru uživatele (měsíčně, čtvrtletně, pololetně a ročně)
DB - Je databáze.

Nyní, když jsme viděli architekturu celé webové aplikace jako jednu jednotku, se testování integrace v tomto případě zaměří na tok dat mezi moduly.

Otázky zde jsou:

  1. Jak BL, VAL a modul CNT budou číst a interpretovat data zadaná v modulu uživatelského rozhraní?
  2. Přijímají moduly BL, VAL a CNT správná data z uživatelského rozhraní?
  3. V jakém formátu jsou data z BL, VAL a CNT přenášena do modulu EQ?
  4. Jak bude EQ číst data a extrahovat dotaz?
  5. Je dotaz extrahován správně?
  6. Získává plánovač správná data pro přehledy?
  7. Je výsledná sada přijatá EN z databáze správná a podle očekávání?
  8. Je EN schopen odeslat odpověď zpět do modulu BL, VAL a CNT?
  9. Je modul uživatelského rozhraní schopen číst data a odpovídajícím způsobem je zobrazit na rozhraní?

V reálném světě se komunikace dat provádí ve formátu XML. Bez ohledu na to, jaké údaje uživatel zadá do uživatelského rozhraní, budou převedeny do formátu XML.

V našem scénáři se data zadaná v modulu uživatelského rozhraní převedou do souboru XML, který je interpretován 3 moduly BL, VAL a CNT. Modul EN čte výsledný soubor XML vygenerovaný 3 moduly a extrahuje z něj SQL a dotazuje se do databáze. Modul EN také obdrží sadu výsledků a převede ji do souboru XML a vrátí ji zpět do modulu uživatelského rozhraní, který převede výsledky v uživatelsky čitelné formě a zobrazí ji.

Uprostřed máme modul plánovače, který přijímá sadu výsledků z modulu EN, vytváří a plánuje sestavy.

Kam se tedy dostane testování integrace?

Testování toho, zda informace / data plynou správně, či nikoli, bude vaším integračním testováním, které by v tomto případě ověřovalo soubory XML. Jsou soubory XML generovány správně? Mají správná data? Jsou data správně přenášena z jednoho modulu do druhého? Všechny tyto věci budou testovány v rámci testování integrace.

Pokuste se vygenerovat nebo získat soubory XML, aktualizovat značky a zkontrolovat chování. To je něco velmi odlišného od obvyklého testování, které testeři obvykle dělají, ale to přidá hodnotu znalostem testerů a porozumění aplikaci.

Několik dalších podmínek testu vzorku může být následující:

  • Generují možnosti nabídky správné okno?
  • Jsou okna schopna vyvolat testované okno?
  • U každého okna identifikujte volání funkce pro okno, které by aplikace měla povolit.
  • Identifikujte všechna volání z okna do dalších funkcí, které by aplikace měla povolit
  • Identifikujte reverzibilní hovory: zavření volaného okna by se mělo vrátit do volajícího okna.
  • Identifikujte nevratná volání: volání oken se zavře, než se objeví volané okno.
  • Vyzkoušejte různé způsoby provádění hovorů do jiného okna, např. - nabídky, tlačítka, klíčová slova.

Kroky k zahájení integračních testů

  1. Pochopte architekturu vaší aplikace.
  2. Určete moduly
  3. Pochopte, co jednotlivé moduly dělají
  4. Pochopte, jak jsou data přenášena z jednoho modulu do druhého.
  5. Pochopte, jak se data zadávají a přijímají do systému (vstupní a výstupní bod aplikace)
  6. Oddělte aplikaci tak, aby vyhovovala vašim testovacím potřebám.
  7. Určete a vytvořte podmínky testu
  8. Vezměte jednu podmínku po druhé a zapište si testovací případy.

Kritéria vstupu / výstupu pro testování integrace

Vstupní kritéria:

  • Dokument plánu integrace je podepsán a schválen.
  • Byly připraveny integrační testovací případy.
  • Testovací data byla vytvořena.
  • Testování jednotky vyvinutých modulů / komponent je kompletní.
  • Všechny kritické a vysoce prioritní vady jsou uzavřeny.
  • Testovací prostředí je nastaveno pro integraci.

Kritéria ukončení:

  • Byly provedeny všechny testovací případy integrace.
  • Nejsou otevřeny žádné kritické a prioritní vady P1 a P2.
  • Zpráva o zkoušce byla připravena.

Testovací případy integrace

Integrační testovací případy se zaměřují hlavně na rozhraní mezi moduly, integrované odkazy, přenos dat mezi moduly jako moduly / komponenty, které jsou již jednotkově testovány, tj. funkčnost a ostatní aspekty testování již byly pokryty.

Hlavní myšlenkou je tedy otestovat, zda integrace dvou pracovních modulů funguje podle očekávání při integraci.

Pro příklady integračních testovacích případů pro aplikaci Linkedin budou zahrnovat:

  • Ověření propojení rozhraní mezi přihlašovací stránkou a domovskou stránkou, tj. Když uživatel zadá pověření a protokoly, mělo by být přesměrováno na domovskou stránku.
  • Mělo by se otevřít propojení rozhraní mezi domovskou stránkou a profilovou stránkou, tj. Profilovou stránkou.
  • Ověřte propojení rozhraní mezi stránkou sítě a stránkami připojení, tj. Kliknutím na tlačítko Přijmout na stránce Pozvánky na stránce sítě by se po kliknutí mělo zobrazit přijaté pozvání na stránce připojení.
  • Ověřte odkaz na rozhraní mezi stránkami oznámení a řekněte tlačítko gratulujeme, tj. Kliknutím na tlačítko gratulace gratulujeme, aby směřovalo k novému oknu zprávy.

Pro tento konkrétní web lze napsat mnoho testovacích případů integrace. Výše uvedené čtyři body jsou pouze příkladem k pochopení toho, jaké integrační testovací případy jsou zahrnuty do testování.

Je integrace technikou bílé nebo černé skříňky?

Techniku ​​testování integrace lze počítat v obou černých polích stejně jako technika bílé krabice . Technika černé skříňky je místo, kde tester nemusí mít žádné vnitřní znalosti o systému, tj. znalost kódování se nevyžaduje, zatímco technika bílé skříňky vyžaduje vnitřní znalosti o aplikaci.

Nyní při provádění testování integrace by to mohlo zahrnovat testování dvou integrovaných webových služeb, které načtou data z databáze a poskytnou data podle potřeby, což znamená, že by mohly být testovány pomocí techniky testování bílé krabice, zatímco integrace nové funkce na webu může být testována pomocí techniky černé skříňky.

Není tedy konkrétní, že testování integrace je technika černé skříňky nebo bílé skříňky.

Nástroje pro testování integrace

Pro toto testování je k dispozici několik nástrojů.

Níže je uveden seznam nástrojů:

  • Produkt Rational Integration Tester
  • Úhloměr
  • Parní
  • TESSY

Další podrobnosti o výše uvedených nástrojích najdete v tomto kurzu:

Top 10 integračních testovacích nástrojů pro zápis integračních testů

Testování integrace systému

Testování integrace systému se provádí za účelem testování kompletní integrovaný systém .

Moduly nebo komponenty jsou testovány jednotlivě při testování jednotek před integrací komponent.

Jakmile jsou všechny moduly otestovány, testování integrace systému se provádí integrací všech modulů a testuje se systém jako celek.

Rozdíl mezi testováním integrace a testováním systému

Testování integrace je testování, při kterém je k testování integrován jeden nebo dva moduly, které jsou testovány na jednotce, a provádí se ověření za účelem ověření, zda integrované moduly fungují podle očekávání nebo ne.

Testování systému je testování, kde systém jako celek je testováno, tj. všechny moduly / komponenty jsou integrovány společně, aby se ověřilo, zda systém funguje podle očekávání a že kvůli integrovaným modulům nedojde k problémům.

Závěr

Jedná se o testování integrace a jeho implementaci v bílé a černé skříňce. Doufám, že jsme to jasně vysvětlili na příslušných příkladech.

Integrace testu je důležitou součástí testovacího cyklu, protože usnadňuje nalezení defektu, když jsou integrovány dva nebo více modulů, aby bylo možné integrovat všechny moduly dohromady v prvním kroku.

Pomáhá při hledání závad v rané fázi, což zase šetří úsilí a náklady. Zajišťuje správnou funkci integrovaných modulů podle očekávání.

Doufám, že tento poučný návod na Testování integrace by obohatil vaše znalosti o konceptu.

Doporučené čtení

^