Menu

Co je přírůstkové testování: podrobné vysvětlení s příklady

what is incremental testing

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

S pomocí tohoto článku se budu věnovat jednomu z důležitých integračních přístupů - přírůstkovému testování.

Na konci této části budou mít posluchači spravedlivé znalosti o:

  • Co je přírůstkové testování?
  • Jeho cíl
  • Metodiky
  • Výhody
  • Nevýhody

Co se naučíte:

Co je to přírůstkové testování

Inkrementální testování, známé také jako Inkrementální testování integrace, je jedním z přístupů testování integrace a zahrnuje jeho základní koncepty.

Je to jako test, který kombinuje modul a integraci strategie testování .

Přírůstkové testování

V tomto testování testujeme každý modul samostatně ve fázi testování jednotky a poté jsou moduly postupně integrovány a testovány, aby bylo zajištěno plynulé rozhraní a interakce mezi moduly.

V tomto přístupu je každý modul kombinován inkrementálně, tj. Jeden po druhém, dokud nejsou logicky přidány všechny moduly nebo komponenty k vytvoření požadované aplikace, namísto integrace celého systému najednou a následného testování konečného produktu. Integrované moduly jsou testovány jako skupina, aby byla zajištěna úspěšná integrace a tok dat mezi moduly.

Stejně jako v testování integrace je hlavním cílem tohoto testování kontrola rozhraní, integrovaných odkazů a toku informací mezi moduly. Tento proces se opakuje, dokud nejsou moduly úspěšně kombinovány a testovány.

Příklad

Pojďme pochopit tento koncept na příkladu:

Systémová nebo softwarová aplikace se skládá z následujících modulů:

Softwarová aplikace

Přístup k testování přírůstkové integrace

  • Každý modul, tj. M1, M2, M3 atd., Se testuje jednotlivě jako součást testování jednotky
  • Moduly jsou postupně kombinovány, tj. Jeden po druhém a testovány na úspěšnou interakci
  • Na obr. 2 jsou moduly M1 a modul M2 kombinovány a testovány
  • Na obr3 je přidán a testován modul M3
  • Na obr. 4 je přidán modul M4 a provádí se testování, aby bylo zajištěno, že vše úspěšně funguje
  • Zbytek modulů se také postupně přidává v každém kroku a testuje se na úspěšnou integraci

Obr

Kombinované dva moduly

Obr

Kombinované 3 moduly

manuální testování pokračuje po dobu 3 let zkušeností

Obr

Kombinované čtyři moduly

Cíl přírůstkového testu

  • Zajistit, aby různé moduly po integraci úspěšně spolupracovaly
  • Zjistěte vady dříve a v každé fázi. To dává vývojářům výhodu, aby zjistili, kde je problém. Stejně jako v případě, že je testování po integraci M1 a M2 úspěšné, ale po přidání M3 se test nezdaří; pomůže to vývojáři oddělit problém
  • Problémy lze opravit v rané fázi bez většího přepracování a za nižší cenu

Metodiky testování postupné integrace

Než začneme s tímto tématem, rád bych se krátce seznámil s tématem Pahýly a řidiči protože tyto termíny budeme často používat.

Pahýly a ovladače jsou pseudokód nebo fiktivní kód používaný v integraci nebo testování komponent když jeden nebo více modulů nejsou vyvíjeny, ale jsou vyžadovány k testování jiného modulu.

Pahýly se používají v přístupu shora dolů a jsou známé jako „nazývané programy“. Pahýly pomáhají simulovat rozhraní mezi spodními pákovými moduly, které nejsou k dispozici nebo jsou vyvíjeny.

Řidiči se používají při testování zdola nahoru a jsou známé jako „volací programy“. Ovladače pomáhají simulovat rozhraní mezi moduly nejvyšší úrovně, které nejsou vyvíjeny ani dostupné.

Některým z nás by mohla nastat otázka, proč před zahájením testování nečekat, až budou vyvinuty všechny aplikační moduly, namísto použití pahýl / ovladače?

Jednoduchá odpověď je, že zvyšuje dobu realizace projektu, protože testeři budou nečinní, dokud nebudou vyvinuty všechny moduly. To také ztěžuje kořenovou analýzu defektu. Tento typ testovacího přístupu je znám jako Big-Bang Integration testing.

Nyní, když jsme pokryli Stubs a řidiče, pojďme k tomu různé metodiky přírůstkového testování:

# 1) Shora dolů

Jak název napovídá, testování probíhá shora dolů, tj. Od centrálního modulu k dílčímu modulu. Nejprve jsou testovány moduly rámující horní vrstvu aplikace.

Tento přístup sleduje strukturální tok testované aplikace. Nedostupné nebo nevyvinuté moduly nebo komponenty jsou nahrazeny pahýly.

Pochopme to na příkladu:

  • Modul : Přihlášení na web aka L
  • Modul : Objednávka aka O
    • Shrnutí objednávky modulu aka OS (dosud nevyvinuto)
  • Modul : Platba aka P
    • Modul Platba v hotovosti aka CP
    • Platební debetní / kreditní modul aka DP (dosud nevyvinuto)
    • Platba v peněžence modulu aka WP (dosud nevyvinuto)
  • Modul: Hlášení aka R (dosud nevyvinuto)

Přístup shora dolů

Přístup k testování přírůstkové integrace shora dolů

Budou odvozeny následující testovací případy:

Testovací případ 1: Moduly L a O budou integrovány a otestovány
Testovací případ 2: Modul L, O a P bude integrován a otestován
Testovací případ 3: Modul L, O, P a R bude integrován a otestován.

A tak jsou odvozeny další testovací případy.

Tento typ testování, kde jsou nejprve integrovány a testovány všechny moduly ve vrstvě, je znám jako „nejdříve“. Další kategorií je „nejdříve hloubka“.

kde najít klíč zabezpečení sítě na routeru

Pro „hloubku nejdříve“ budou odvozeny následující testovací případy:

Testovací případ 1: Moduly L a O budou integrovány a otestovány
Testovací případ 2: Modul L, O a OS budou integrovány a otestovány
Testovací případ 3: Modul L, O, OS, P bude integrován a otestován
Testovací případ4: Modul L, O, OS, P, CP bude integrován a otestován

A tak jsou odvozeny další testovací případy.

Podstata metodiky shora dolů

  • Včasné odhalení vad architektury
  • Popisuje fungování aplikace jako celku v raných fázích a pomáhá při včasném odhalení vad designu
  • Hlavní kontrolní body jsou testovány brzy

Odplata metodiky shora dolů

  • Významné moduly jsou testovány pozdě v cyklu
  • Je velmi náročné napsat podmínky testu
  • Pahýl není dokonalá implementace souvisejícího modulu. Prostě simuluje tok dat mezi dvěma moduly

# 2) zdola nahoru

V tomto přístupu probíhá testování zdola nahoru, tzn. Nejdříve jsou integrovány a testovány moduly ve spodní vrstvě a poté jsou postupně posouvány další moduly. Nedostupné nebo nevyvinuté moduly jsou nahrazeny ovladači.

Pro lepší pochopení se podívejme na níže uvedený příklad:

Moduly Rank, Marks, Percentage a Sports Grade ještě nejsou vyvinuty, takže budou nahrazeny souvisejícím Driverem:

Přístup zdola nahoru

Přístup zdola nahoru, postupné testování integrace

Budou odvozeny následující testovací případy:

Testovací případ 1: Jednotkové testování modulu Praktická a teorie
Testovací případ 2: Integrace a testování modulů Marks-Practical-theory
Testovací případ3 : Integrace a testování modulů Percentage-Marks-Practical-Theory
Testovací případ4: Jednotkové testování modulu Sports Grade
Testovací případ5: Integrace a testování modulů Rank-Sports Grade-Percentage-Marks-Practical-Theory

Podstata metodiky zdola nahoru

  • Tato metodika je velmi užitečná pro aplikace, kde se používá konstrukční model zdola nahoru
  • Je snazší vytvořit testovací podmínky v přístupu zdola nahoru
  • Zahájit testování na spodní úrovni hierarchie znamená testování kritických modulů nebo funkcí v rané fázi. To pomáhá při včasném odhalení chyb
  • Vady rozhraní jsou detekovány v rané fázi

Opodstatněnost metodiky zdola nahoru

  • Ovladače jsou těžší psát než stub
  • Vady návrhu jsou zachyceny v pozdější fázi
  • V tomto přístupu nemáme funkční aplikaci, dokud nebude sestaven poslední modul
  • Ovladač není úplnou implementací souvisejícího modulu. Prostě simuluje tok dat mezi dvěma moduly.

# 3) Testování sendvičů

Tento přístup je hybridem metodiky shora dolů a zdola nahoru. Pahýl a ovladače se používají pro neúplné nebo nevyvinuté moduly.

Přístup k testování

  • Je identifikována střední vrstva, ze které se provádí testování zdola nahoru a shora dolů. Tato střední vrstva je také známá jako cílová vrstva
  • Cílová vrstva je identifikována podle heuristického přístupu, tj. Vyberte vrstvu, která umožňuje minimální použití pahýlů a ovladačů
  • Testování shora dolů začíná od střední vrstvy a pohybuje se směrem dolů k modulům nižší úrovně. Tato vrstva pod střední vrstvou je známá jako spodní vrstva
  • Testování zdola nahoru také začíná od střední vrstvy a posune se nahoru k modulům horní vrstvy. Tato vrstva nad střední vrstvou je známá jako horní vrstva
  • Pomocí stubů a ovladačů se testuje uživatelské rozhraní a funkce modulů nižší úrovně
  • Nakonec pro provedení závěrečného testu zbývá pouze střední vrstva

Příklad:

Příklad sendvičového testování

S Sandwich Testing Strategy lze odvodit následující testovací případy:

Testovací případ 1: Test A, X, Y a Z jednotlivě - kde Test A spadá pod Test vrchní vrstvy a Test X, Y a Z spadá pod Testy spodní vrstvy
Testovací případ 2: Test A, G, H a I
Testovací případ 3: Vyzkoušejte G, X a Y
Testovací případ4: Otestujte ruku Z
Testovací případ5: Test A, G, H, I, X, Y a Z.

Přednosti metodiky sendvičového testování

  • Je to velmi výhodné pro velký projekt, který má různé dílčí projekty
  • Metodika testování shora dolů a zdola nahoru může probíhat vedle sebe

Opodstatněnost metodiky sendvičového testování

  • Před sjednocením modulů nejsou subsystémy a jejich rozhraní důkladně testovány
  • Vyšší náklady díky zapojení metodiky testování shora dolů i zdola nahoru
  • Tento typ testování se nedoporučuje pro systém, kde jsou moduly vysoce závislé

Závěr

Inkrementální testování spadá do rámce testování integrace. V tomto přístupu testování se testování integrace provádí na jednotlivém modulu jako součást testování jednotky a v další fázi se moduly nebo komponenty aplikace postupně integrují a testování se provádí na kombinovaných modulech jako skupina.

Ze tří metodik přírůstkového testování integrace závisí výběr metodiky, která se má zvolit, na struktuře aplikace a také na poloze vysoce rizikových modulů.

Všechny tři metodiky přírůstkového testování spadají do horizontální kategorie kvůli následujícím aspektům chování:

  • Všechny tři metodiky se zaměřují na testování vrstev
  • Všichni zvažují strukturální nebo hierarchický design
  • Všechny integrují vrstvy postupně

Zásluhy:

S tímto přístupem k testování je snazší včas identifikovat vady a také pomáhá vývojáři určit příčinu problému. Jelikož využívá základy strukturovaného testování, je tento testovací přístup velmi efektivní a přesný.

Nevýhody:

Tento typ testovacího přístupu je časově náročný kvůli použití pahýlů a ovladačů. Je to také opakující se.

O autor: Tento užitečný tutoriál napsal Neha B. Je vedoucím analytikem kvality s certifikací ISTQB a má více než 8 let zkušeností.

Pokud máte jakékoli dotazy / návrhy, dejte nám vědět.

Doporučené čtení

^