Menu

Výukový program pro strukturální testování - Co je to strukturální testování

  • Hlavní
  • Jiný
  • Výukový program pro strukturální testování - Co je to strukturální testování

structural testing tutorial what is structural testing

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

Tento komplexní výukový program Strukturální testování vysvětluje, co je Strukturální testování, jeho typy, co je Testování toku toku a Graf toku toku, Úrovně pokrytí atd .:

Rychlé vyhledání některých z nejdražších softwarových chyb na Googlu mě nechalo navíjet - 500 miliard dolarů. Ano, takto se může chyba stát nákladnou. Čtení všeho, co souvisí se ztracenými životy v dopravě a zdravotnictví kvůli softwarové chybě, může být také děsivé.

Zatímco chyby v kódu nejsou vždy tak extrémní, pokud zahrnují ztrátu velkého množství peněz a životů, jediným klíčovým krokem, který se zde snažíme sdělit, je, že nelze přehlédnout testování.

Strukturální testování

Když se testování v celém SDLC provádí často, umožňuje nám to chytit chyby, které by po odeslání produktu potřebovaly mnohem více času na opravu.

Důležité jsou typy testování softwaru, které si vybereme. Existuje několik z nich, včetně funkčních, strukturálních a změnových testů.

Tento výukový program také vysvětluje typy strukturálního testování. Naučte se podrobně provádět testy mutací, testování podle řezů, testování toku dat s příklady a vysvětlením.

Co se naučíte:

Proč je testování softwaru důležité

Kromě úspory peněz a předcházení katastrofám, jako jsou případy uvedené výše, existuje několik dalších důvodů, které ospravedlňují důležitost testování.

Níže jsou uvedeny některé důvody:

# 1) Zajistit splnění stanovených požadavků před zahájením výstavby projektu. Zainteresované strany (například vývojáři a klienti) se musí dohodnout na všech aspektech řešení / produktu / softwaru, které jsou nutné k vytvoření projektu.

Testování zahrnuje ověření, zda jsou splněny softwarové požadavky. Vývojář nebo společnost podílející se na vytváření řešení také získávají dobrou pověst při navrhování tak vysoce kvalitního řešení, které je provozováno kódem eclat.

# 2) Ověří, že funkce kódu funguje podle očekávání. Testování zahrnuje také ověření funkčnosti softwaru a v případě jakékoli poruchy by měl být opraven během raných fází SDLC (Software Development Life Cycle).

# 3) Kontroluje výkon: Například k identifikaci celkového času, který uplynul při spuštění kódu. Použijeme-li několik Pro smyčky v našem kódu bude trvat dlouho, než se získá zamýšlený výstup, a někdy dokonce vyprší časový limit.

# 4) Pomáhá dosáhnout lepší uživatelské zkušenosti. Uživatelé nebudou rádi používat software, který je nefunkční, chybný nebo „příliš pomalý“. Uživatelé budou pravděpodobně netrpěliví a přestanou používat software. Testování nám dává lepší šanci zajistit, aby uživatelé mohli snadno používat naše produkty.

# 5) Kontroluje škálovatelnost. Vývojář by se měl zaměřit na vytváření softwaru, který lze škálovat.

# 6) Kontroluje chyby zabezpečení v kódu. Testování nám umožňuje sledovat chyby zabezpečení, Například, kód, který může kompromitovat PII (Osobně identifikovatelné informace), což je pro GDPR vysoká priorita.

V tomto článku se zaměříme na jeden typ testování, tj. Strukturální testování . Jak název napovídá, souvisí se strukturou kódu. To se liší od toho, co jsme zmínili dříve, že testování pomáhá určit aspekty, jako je výkon kódu, funkčnost a zabezpečení.

Strukturální testování vs. jiné typy testování

Existuje mnoho typů testování softwaru. Nicméně STOP (International Software Testing Qualifications Board) definuje 4 hlavní typy testování softwaru, a to

  • Funkční
  • Nefunkční
  • Strukturální
  • Na základě změn

Rozdíly lze vysvětlit níže:

Funkční testování: To zahrnuje ověření funkčnosti softwaru podle stanovených požadavků. Jako vstup se použijí testovací data. Také zkontrolujeme, zda je daný výstup podle očekávání.

Nefunkční testování : Jedná se o testovací proces, který analyzuje, jak dobře software funguje, například, počet uživatelů, které dokáže zpracovat současně.

Strukturální testování: Tento typ testování je založen na struktuře kódu. Například, pokud je kód určen k výpočtu průměru sudých čísel v poli, pak by se testování založené na struktuře zajímalo spíše o „kroky, které vedou k výpočtu průměru“, než o to, zda je konečným výstupem správná číselná hodnota.

Předpokládejme, že musíme zkontrolovat, zda jsme definovali kód, který odlišuje sudá čísla od lichých čísel. Můžeme zde mít podmíněné prohlášení, například pokud je prvek pole dělitelný dvěma bez zbytku, if (arr (i)% 2 === 0) pak číslo lze říci jako sudé číslo.

Strukturální testování provádějí stejní lidé, kteří kód píší tak, jak mu nejlépe rozumí.

Testování na základě změn : To zahrnuje testování účinků provádění změn v kódu a následné zajištění toho, že provedené změny byly implementovány. Zajišťuje také, že změny kódu jej nezlomí.

Co strukturální testování není

Již jsme zmínili, že testování založené na struktuře odkazuje na strukturu kódu. Upozorňujeme, že zde se zabýváme skutečným kódem. Nekontrolujeme proti požadavkům nebo dokonce testujeme vstupy proti očekávaným výstupům. V tomto okamžiku se nezabýváme funkčností, uživatelským zážitkem nebo dokonce výkonem.

Co je strukturální testování

Testování na základě struktury lze proto definovat jako typ testování softwaru, který testuje strukturu kódu a zamýšlené toky. Například, ověření skutečného kódu pro aspekty, jako je správná implementace podmíněných příkazů, a zda je každý příkaz v kódu správně proveden. To je také známé jako testování na základě struktury.

Abychom mohli provést tento typ testování, musíme důkladně porozumět kódu. Proto toto testování obvykle provádějí vývojáři, kteří kód napsali, protože mu nejlépe rozumí.

Jak provádět strukturální zkoušky

Abychom mohli otestovat různé aspekty kódu, musíme nejprve porozumět tokům řízení.

Kontrola testování toku

Toto je odvození testů z řídicích toků kódu (pořadí, ve kterém jsou implementovány příkazy, funkce a různé aspekty kódu).

Proces testování toku řízení:

Kontrolní vývojový graf

Proces toku řízení začíná vytvořením vizuální reprezentace různých částí kódu, který nám pomáhá definovat cesty, které lze sledovat během provádění.

Tyto vizuální reprezentace jsou známé jako Control Flow Graphs (CFG) a mají několik komponent, jako jsou uzly, hrany, cesty, křižovatky a rozhodovací body. Graf lze vytvořit ručně nebo automaticky, kde se software používá k extrakci grafu ze zdrojového kódu.

Podívejme se na tyto komponenty níže:

Uzly a hrany

# 1) Procesní blok

Tato část se používá k reprezentaci části kódu, která se spouští postupně. To znamená, že se provádí pokaždé stejným způsobem a není třeba činit žádná rozhodnutí nebo „větvení“. Skládá se z uzlů s jednou vstupní a výstupní cestou.

Příklad procesního bloku:

Zpracovat blok

(obraz zdroj )

Procesní blok není podstatnou součástí regulačního toku a ve výsledku je třeba jej otestovat pouze jednou.

# 2) Rozhodovací body

Toto jsou některé klíčové komponenty v toku řízení kódu. V těchto uzlech se rozhoduje. To se obvykle provádí porovnáním a regulační tok se mění v závislosti na rozhodnutí. Tato část CFG je tvořena jedním uzlem s alespoň 2 výstupy.

Rozhodnutím zde mohou být podmíněné příkazy, jako jsou příkazy if-else (které mají dva možné výstupy) a případové příkazy (které mohou mít více než dva výstupy).

CFG

(obraz zdroj )

Ve výše uvedeném diagramu je rozhodovací bod (z podmíněného „věku = 18“), za nímž následují možnosti „ano“ nebo „ne“.

# 3) Spojovací body

Z výše uvedeného diagramu můžeme snadno identifikovat spojovací body, kde se spojují rozhodovací body. Spojovací body mohou mít mnoho vstupních cest, ale mohou mít pouze jednu výstupní cestu.

Osvědčené postupy pro řízení grafů toku:

Při konstrukci grafů toku řízení je třeba si uvědomit několik věcí:

  • Snažte se co nejvíce, aby byl CFG jednoduchý. Toho můžeme dosáhnout kombinací částí, které lze považovat za „méně významné“, například, procesní bloky.
  • Zajistěte, aby v rozhodovacích bodech bylo učiněno pouze jedno rozhodnutí. Ve složitějších CFG existují „důsledky“, které nastanou po přijetí rozhodnutí. V našem výše uvedeném příkladu bychom také mohli dodat, že pokud má jednotlivec 18 let nebo více, je způsobilý a musí za lístek zaplatit. Pokud nejsou, pak je vstup zdarma. Rozhodnutí „else“ musí „přeskočit“ několik uzlů a všechny tyto kroky je třeba ukázat v našem CFG.

Jakmile jsme definovali náš CFG, je nyní čas přejít k dalšímu kroku v procesu testování kontrolního toku, tj. Definovat, do jaké míry kód otestujeme.

nejlepší bezplatný video převodník pro Windows 7

Definování toho, kolik testovat:

Kolik ze zdrojového kódu by mělo být testováno? Měli bychom otestovat každou možnou cestu? Pokus o pokrytí všech cest v našich testech je prakticky nemožný. Musíme najít střední cestu, abychom určili, kolik testování můžeme udělat.

Pokud řekneme, že se zaměřujeme na testování 50% našeho kódu, mohlo by to znamenat, že definujeme všechny příkazy spustitelného kódu a zaměříme se na testování alespoň poloviny z nich. Zde však vyvstává otázka, ‚musíme tedy definovat všechny možné spustitelné cesty? '

To může být opět prakticky nemožné. Lepší přístup by mohl být zaměřený na testování 50% cest, které můžeme identifikovat v každé části kódu.

Existují různé úrovně pokrytí, jmenovitě prohlášení, větev a pokrytí cesty. Krátce se na ně podíváme později.

Vytváření testovacích případů:

Dalším krokem je vytvoření testovacích případů, které použijeme. Testovací případy při testování na základě struktury jsou založeny na následujících faktorech:

  • Spustitelné příkazy.
  • „Rozhodnutí“, která je třeba učinit.
  • Možné cesty, které lze sledovat.
  • Podmínky, které je třeba splnit (mohou být vícenásobné nebo booleovské).

Výše uvedené faktory nám dávají představu o typech testovacích případů, které musíme vytvořit. Můžeme také použít nástroj pro generování strukturálních testů. Pokud je náš kód v programovacím jazyce C, můžeme použít PathCrawler ke generování testovacího kódu. Dalším nástrojem, který můžeme použít, je fMBT.

Provádění testovacích případů:

Zde můžeme spustit testy. Můžeme zadat vstup nebo data, abychom zkontrolovali, jak jej kód provádí, a poté ověřit, zda získáme očekávané výsledky. Například, zadejte pole do volání funkce, abyste zjistili, že výsledky, které získáme po smyčce, nebo zkontrolujte, zda rozhodovací body dělají správná rozhodnutí.

Analýza výsledků:

V této části vše, co děláme, je zkontrolovat, zda po provedení získáme správné výsledky. Například, pokud zadáme pole, kde jsou všechny hodnoty vyšší než 18, pak bychom měli mít všechny rozhodovací body vedoucí k „vhodnému“.

Předpoklady řízení toku

Je důležité si uvědomit, že k provedení kontroly toku toku existuje několik předpokladů. Tyto zahrnují:

  • Jediné přítomné chyby jsou ty, které mohou ovlivnit tok řízení.
  • Všechny proměnné, funkce a prvky jsou přesně definovány.

Úrovně pokrytí v kontrolních tocích

Jak jsme již zmínili dříve, při testování toku řízení existují různé úrovně pokrytí.

Podívejme se na ně krátce.

# 1) Pokrytí prohlášení

Při strukturálním testování hrají příkazy spustitelného kódu zásadní roli při rozhodování o metodách navrhování testů.

Naším cílem je dosáhnout 100% pokrytí, což znamená, že každý spustitelný příkaz byl testován alespoň jednou. Čím vyšší je pokrytí, tím menší je pravděpodobnost chyb a chyb.

Zde je nutné použít testovací případy. Data, která potřebujeme, je zajistit, aby byl každý spustitelný příkaz v bloku kódu proveden alespoň jednou.

# 2) Pokrytí pobočky

Tato úroveň pokrytí zahrnuje testování bodů ve větvích CFG (kde se rozhoduje). Výsledky jsou logické. I když je použit příkaz switch a existuje více výsledků, v podstatě je každý případový blok porovnáním dvojice hodnot.

Stejně jako u pokrytí výpisů bychom se měli zaměřit na 100% pokrytí poboček. Abychom toho dosáhli, musíme alespoň jednou otestovat každý výsledek na každé úrovni rozhodování. Jelikož máme co do činění s booleovskými výsledky, měli bychom se zaměřit na spuštění alespoň 2 testů na sekci kódu.

# 3) Pokrytí cesty

Tato úroveň pokrytí je důkladnější ve srovnání s pokrytím rozhodnutí a prohlášení. Cílem je „objevit“ všechny možné cesty a alespoň jednou je otestovat. To může být velmi časově náročné. Může však pomoci objevit chyby nebo chyby v našem kódu nebo dokonce aspekty, které musíme definovat, například, vstup uživatele.

Typy strukturálních zkoušek

Typy strukturálních zkoušek
(obraz zdroj )

Testování mutací

Testování mutací je testovací technika založená na chybách, při které se testují různé varianty softwarové aplikace proti testovací datové sadě.

>> V tomto výukovém programu najdete podrobnější pohled Testování mutací.

Testování na základě řezů

Slice Based Testing (SBT) lze definovat jako techniku ​​testování softwaru, která je založena na plátky - spustitelné části programu nebo skupiny příkazů, které ovlivňují některé hodnoty v konkrétních bodech zájmu v programu, například, části, kde jsou definovány proměnné, nebo výstup skupiny příkazů.

Jak udělat krájení

Příklad krájení v SBT: Kód pro tisk sudých a lichých čísel (Python)

num_list = range(1,12) even_nums = () odd_nums = () for var in num_list: if var%2==0: even_nums.append(var) print(f'Even numbers: {even_nums}') elif var%3==0: odd_nums.append(var) print(f'Odd numbers: {odd_nums}')

Slice-based testování

Existují dva způsoby, jak se na řez podívat: Sledováním cesty sledované proměnné nebo části kódu, která ovlivňuje výstup.

V našem příkladu, pokud se podíváme na výstup lichých čísel, můžeme vystopovat část kódu, která nás vede k tomuto výstupu.

V kritériích pro krájení daných Markem Weiserem (který představil SBT) je řez definován pomocí tohoto vzorce: S (v, n) kde proti odkazuje na danou proměnnou ( například, kde je definována proměnná) a n je prohlášení o zájmu ( například, kde je uveden výstup) a S znamená plátek.

Ve výše uvedeném příkladu, abychom získali řez, začneme od našeho výstupu na řádku 10, který se stane naším n . Naše proměnná je kde .

Naše kritéria pro krájení jsou tedy:

S(v,n) = S(var,10)

Naším zájmem jsou prohlášení, která nás vedou k výstupu.

Tyto jsou:
10,9,8,4,3,1

Náš řez v tomto kódu je tedy:

num_list = range(1,12) odd_nums = () for var in num_list: elif var%3==0: odd_nums.append(var) print(f'Odd numbers: {odd_nums}')

SBTSlice

Typy testování podle řezů

Existují dva typy SBT: statické a dynamické

# 1) Dynamické testování založené na řezech

Příklad SBT vysvětlený výše, kde jsme se podívali na příkazy, které ovlivňují tisk lichých čísel, je dynamický SBT. Náš zájem je velmi konkrétní. Zaměříme se pouze na to, co přímo ovlivňuje konkrétní výstup.

Spustíme kód a pomocí testovacích dat zajistíme, aby fungoval tak, jak má. Mohli bychom zvýšit rozsah na rozsah (1,50), například, zjistit, zda stále generuje pouze lichá čísla. Dynamické SBT je také známé jako ověřovací testování.

# 2) StatickéTestování na základě řezů

Na rozdíl od Dynamic SBT se statické testování zaměřuje na konkrétní proměnnou. Pokud uvažujeme o našem výstupu ve výše uvedeném příkladu jako kde , můžeme vystopovat řez, který jej ovlivňuje jako 10,9,8,7,6,5,4,3,2,1

Je to v podstatě celý blok kódu! Zde ověřujeme správnost kódu z hlediska syntaxe a požadavků a neprovádíme jej. Statický SBT je také známý jako ověřovací testování.

Je důležité si uvědomit, že dynamický SBT je „menší“ ve srovnání s jeho statickým protějškem. Je to také konkrétnější.

Osvědčené postupy / pokyny pro testování na základě řezů

Kritéria pro krájení by měla být určena:

  • Příkazy, kde jsou hodnoty definovány nebo přiřazena hodnota, stejně jako znovu přiřazená hodnota.
  • Výpisy, kde jsou hodnoty přijímány mimo program, například, prostřednictvím vstupu uživatele.
  • Příkazy, které tisknou výstup / vracejí výstup.
  • Poslední prohlášení programu, například, volání funkce, které může definovat hodnoty nebo poskytovat hodnoty argumentům

Mezi výhody testování založeného na řezech patří:

  • Protože v SBT pracujeme pouze se specifickými oblastmi zájmu, usnadňuje to efektivní generování testovacích sad.
  • Cesta je definována závislostmi v rámci kódu, což je lepší než použití pokrytí cesty.
  • S SBT je snazší najít chyby ve zdrojovém kódu.

Nevýhody testování založeného na řezech zahrnují:

  • Pokud při testování velké databáze kódů použijeme dynamické testování, budeme potřebovat spoustu výpočetních prostředků.
  • Pokud použijeme statické testování, mohou nám chybět chyby.

Testování toku dat

Testování toku dat lze definovat jako techniku ​​testování softwaru, která je založena na hodnotách dat a jejich použití v programu. Ověřuje, že hodnoty dat byly správně použity a že generují správné výsledky. Testování toku dat pomáhá vysledovat závislosti mezi hodnotami dat na konkrétní cestě provedení.

Anomálie toku dat

Anomálie toku dat jsou jednoduše chyby v softwarovém programu. Jsou rozděleny do typů 1, 2 a 3.

Pojďme se jimi zabývat níže:

Typ 1: Proměnná je definována a je jí přiřazena hodnota dvakrát.

Příklad kódu: Python

jak přehrávat soubory .swf
lst_1 = (1,2,3,4) lst_1 = (5,6,7,8) for var in lst_1: print(var)

Typ1

Lst_1 je definována a jsou jí přiřazeny dvě různé hodnoty. První hodnota je jednoduše ignorována. Anomálie typu 1 nezpůsobí selhání programu.

Typ 2: Hodnota proměnné se použije nebo na kterou se odkazuje před jejím definováním.

Příklad kódu: Python

for var in lst_1: print(var)

Typ 2

Smyčka výše nemá žádné hodnoty k iteraci. Anomálie typu 2 způsobují selhání programu.

Typ 3: A generuje se datová hodnota, ale nikdy se nepoužívá.

Příklad kódu: Python

lst_1 = (1,2,3,4) lst_2 = (5,6,7,8) for var in lst_1: print(var)

Typ 3

Proměnná lst_2 nebyl odkazován. Anomálie typu 3 nemusí způsobit selhání programu.

Proces testování toku dat

Chcete-li definovat závislosti mezi datovými hodnotami, musíme definovat různé cesty, které lze v programu sledovat. Abychom to mohli efektivně provést, musíme si půjčit od jiného typu strukturálního testování známého jako testování kontrolního toku .

Krok 1) Nakreslete kontrolní tokový graf

Musíme nakreslit kontrolní tokový graf, což je grafické znázornění cest, kterými bychom mohli v našem programu postupovat.

Příklad kódu: Python

cost = 20 y = int(input('How many visitor seats did you reserve? ')) x = int(input('How many member seats did you reserve? ')) if y>x: bill = cost -1 else: bill = cost print(bill)

Testování toku dat

Ve výše uvedeném příkladu kódu by měl člen získat slevu, pokud pozve návštěvníka.

Kontrolní vývojový graf (CFG):

Kontrolní vývojový graf

Krok 2) Prozkoumejte definici a použití proměnných a datových hodnot.

Proměnná v programu je definována nebo použita. V CFG máme proměnné v každém uzlu. Každý uzel je pojmenován podle typu proměnné, ve které je umístěn. Pokud je proměnná definována v určitém uzlu, vytvoří definující uzel. Pokud se proměnná použije v uzlu, vytvoří uzel využití.

Pokud vezmeme v úvahu variabilní náklady v CFG, jedná se o uzly definování a použití:

UzelTypKód
jeden Definování uzlucena = 20
5 Uzel použitíúčet = náklady -1
7 Uzel použitíúčet = náklady

Krok č. 3) Definujte cesty definice - použití.

Existují dva typy cest definice-použití: cesty du a dc cesty. cesty du jsou definiční cesty, které začínají definičním uzlem a končí uzlem použití. To je případ cesty s odkazem na výše uvedené variabilní náklady.

Příkladem cesty dc, cesty rozhodování, je cesta s ohledem na proměnnou bill, jak je uvedeno níže:

UzelTypKód
5 Definování uzluúčet = náklady -1
7 Definování uzluúčet = náklady
8 Uzel použitítisk (účet)

stejnosměrná cesta má více než jeden definiční uzel, přestože stále končí v uzlu použití.

Krok č. 4) Vytvořte testovací sadu.

To je přidání vstupu. Všimněte si, že pro každou proměnnou musíme mít jinou testovací sadu. Sada testů nám pomůže identifikovat anomálie toku dat.

Typy testování toku dat

Existují dva typy - Statické a dynamické .

Statické znamená, že procházíme kódem a CFG, abychom identifikovali anomálie dat, aniž bychom je provedli. Dynamický znamená, že ve skutečnosti identifikujeme konkrétní cesty a poté vytvoříme testovací sady, abychom je otestovali v nabídce, abychom „zachytili“ anomálie, které nám během statického testování mohly uniknout.

Výhody a nevýhody testování toku dat:

  • Testování toku dat je ideální pro identifikaci anomálií toku dat, což z něj činí velmi efektivní metodu strukturálního testování.
  • Jeho nevýhodou je, že je potřeba se dobře orientovat v jazyce použitém k napsání kódu, aby bylo možné používat testování toku dat. Je to také časově náročné.

Výhody a nevýhody strukturálních zkoušek

Pojďme nyní najít důvody, proč je strukturální testování skvělým přístupem, a prozkoumejte také některé jeho nevýhody.

Výhody:

  • Umožňuje důkladné testování kódu, což vede k minimálním chybám. Strukturální testování poskytuje prostor pro důkladné testování softwaru. Různé úrovně pokrytí - prohlášení po prohlášení, každý rozhodovací bod a cesta mají za cíl dosáhnout 100% pokrytí, což výrazně snižuje pravděpodobnost, že chyby zůstanou nezjištěny.
  • Schopnost automatizovat . Existuje několik nástrojů, které můžeme použít k automatizaci testování. To nám pomůže dosáhnout maximálního pokrytí kódu a za kratší dobu ve srovnání s ručním provedením testování.
  • Výsledkem je kvalitnější kód . Vývojáři mají šanci prostudovat strukturu a implementaci kódu, opravit případné chyby a vylepšit tyto aspekty. Umožňuje nám to mít na paměti velkou strukturu, když píšeme další části kódu nebo implementujeme zbývající funkce.
  • Lze to provést v každé fázi SDLC - Strukturální testování lze provádět v každé fázi SDLC bez čekání na 100% dokončení vývoje. To usnadňuje identifikaci chyb v počáteční fázi, a tím šetří mnoho času ve srovnání s testováním po dokončení vývoje.
  • Pomáhá zbavit se mrtvého kódu . To lze považovat za „extra“ nebo zbytečný kód, například, kód, který vypočítá výsledek, ale nikdy jej nepoužije v žádném z následujících výpočtů.
  • Účinnost - Jelikož vývojáři píšící kód jsou stejní, kteří jej testují, není třeba zapojovat další lidi, jako jsou QA.

Nevýhody:

  • Vývojáři, kteří provádějí testování založené na struktuře, potřebují důkladně porozumět jazyku . Ostatní vývojáři a QA, kteří nejsou dobře obeznámeni s jazykem, nemohou s testováním pomoci.
  • Může to být docela drahé z hlediska času a peněz . Efektivní testování vyžaduje spoustu času a prostředků.
  • Způsobuje zpoždění při poskytování funkcí . Důvodem je, že vývojáři jsou taženi od vytváření softwaru k testování.
  • Škálování je problém, zejména pokud se jedná o velké aplikace . Velká aplikace se rovná nadměrně vysokému počtu cest k pokrytí. Dosažení 100% pokrytí se stává nemožným.
  • Mohou chybět případy a trasy , například, v případě, že funkce nejsou plně rozvinuty nebo se teprve budou vyvíjet. To znamená, že je třeba jej kombinovat s dalšími typy testování, jako je testování požadavků (kde kontrolujeme srovnání se specifikovanými funkcemi, které je třeba sestavit).

Osvědčené postupy pro strukturální testování

Některé z faktorů, které vyžadují pozornost při provádění testování na základě struktury, jsou následující:

  • Jasně označte a pojmenujte testy . Pokud někdo potřebuje provést testy, musí být schopen je snadno najít.
  • Před vylepšením kódu, tj. Jeho refaktorováním a optimalizací pro použití v různých prostředích, zajistěte, aby jeho struktura a tok byly ideální.
  • Spusťte testy samostatně . Tímto způsobem je snadné identifikovat chyby a opravit je. Na druhou stranu je méně pravděpodobné, že nám budou chybět chyby nebo cesty v důsledku překrývání sekcí kódu, bloků nebo cest.
  • Před provedením změn generujte testy . Testy jsou vyžadovány k provedení podle očekávání. Tímto způsobem, pokud se něco zlomí, je snadné problém dohledat a opravit.
  • Udržujte testy pro každou sekci nebo blok kódu zvlášť . Tímto způsobem, pokud dojde ke změnám po řádku, nemusíme měnit mnoho testů.
  • Před pokračováním v testování opravte chyby . Pokud identifikujeme nějaké chyby, je lepší je opravit dříve, než přistoupíme k testování další části nebo bloku kódu.
  • Nikdy nevynechávejte strukturální testování s předpokladem, že QA „bude i tak provádět testování“. I když se chyby mohou na první pohled zdát kumulativní, mohou mít za následek buggy kód, který nikdy nemůže dosáhnout svého zamýšleného účelu.

Nejčastější dotazy týkající se testování na základě struktury

Zde prozkoumáme často kladené otázky, pokud jde o testování na základě struktury.

Otázka č. 1) Jaký je rozdíl mezi funkčním a strukturálním testováním?

Odpovědět: Funkční testování je typ testování softwaru na základě stanovených požadavků v SRS (Specifikace softwarových požadavků). Obvykle se to dělá ve snaze najít rozdíly mezi specifikacemi v SRS a tím, jak kód funguje. Strukturální testování je založeno na vnitřní struktuře kódu a jeho implementaci. Je nutné důkladné porozumění kódu.

Otázka č. 2) Jaké jsou typy strukturálních zkoušek?

Odpovědět typy zahrnují:

  • Testování toku dat
  • Testování mutací
  • Kontrola testování toku
  • Slice-based testování

Otázka č. 3) Co je to příklad testování konstrukce?

Odpověď: Zde je příklad ukazující pokrytí prohlášení:

const addNums = (num) => { let sum = num.reduce ((a,b) => a+b); if (sum > 0) { alert(sum); } else { alert(‘please enter positive numbers’); } }; addNums();

Rozsah pokrytí, který získáme, závisí na testovacích datech, která poskytneme jako vstup (zda splňuje podmínky součtu> 0).

Otázka č. 4) Jaký je rozdíl mezi testováním toku dat a testováním kontrolního toku?

Odpovědět: Testování toku dat i testování toku toku používají grafy toku toku. Jediným rozdílem je, že při testování toku řízení se zaměřujeme na cesty generované z kódu, zatímco při testování toku dat se zaměřujeme na hodnoty dat, jejich definici a použití v rámci cest identifikovaných v rámci programu.

Otázka č. 5) K čemu se používá testování toku dat?

Odpovědět: Testování toku dat je ideální pro identifikaci anomálií v používání hodnot dat v rámci cest v grafu toku řízení, například, jedna proměnná, které byla přiřazena hodnota dvakrát, proměnná, která byla definována a nebyla použita, nebo proměnná, která byla použita nebo odkazována a nebyla definována.

Otázka č. 6) Jaký je rozdíl mezi krájením a krájením při testování softwaru?

Odpovědět: Krájení znamená soustředit se na konkrétní prohlášení o zájmu o program a zbytek ignorovat. Dicing je, když identifikujeme řez, který má nesprávný vstup, a poté jej dále krájíme, abychom vystopovali správné chování.

Otázka č. 7) Jaký je rozdíl mezi testováním mutací a pokrytím kódu?

Odpovědět: Při testování mutací považujeme počet zabitých mutantů za procento z celkového počtu mutantů. Pokrytí kódu je jednoduše množství kódu, které bylo testováno v programu.

Závěr

V tomto tutoriálu jsme se podívali na strukturální testování do hloubky - co to je, co to není, jak na to, typy pokrytí, výhody a nevýhody, osvědčené postupy a dokonce i některé časté dotazy týkající se tohoto typu testování softwaru.

Stále je toho mnohem víc, co se můžeme dozvědět o testování na základě struktury. V budoucích cvičeních prozkoumáme pokrytí kódu (prohlášení, rozhodnutí, větev a cesta), typy strukturálního testování (mutace, tok dat a řezy) a dokonce i nástroje, které můžeme použít k automatizaci těchto testovacích procesů.

Je důležité si uvědomit, že neexistuje žádný typ testování softwaru nebo přístup, který by byl 100% efektivní. Vždy je vhodné kombinovat různé typy testování a přístupy.

Například, strukturální testování je značně doplněno testováním požadavků, protože mohou existovat funkce, které nemuseli být vyvinuty v době, kdy se provádělo strukturální testování.

Techniky strukturního testování jsou založeny na chybách, které lidští programátoři dělají při psaní kódu. Předpokládá se, že programátor je odborník a ví, co kóduje, ale občas se mýlí.

Různé typy strukturálního testování, na které jsme se podívali - testování mutací, testování založené na řezech a testování toku dat lze vysledovat zpět k chybám, jako je použití nesprávného operátoru (testování mutací) nebo odkazování na proměnnou před jejím použitím (testování toku dat) .

Doporučené čtení

^