Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
090416_STATNICE_Zaklady_softwaroveho_inzenyrstv...doc
Скачиваний:
0
Добавлен:
01.03.2025
Размер:
1.51 Mб
Скачать
  1. Jaké metody testování softwarových produktů znáte?

Testování:

  • proces spouštění programu (IS?) za účelem nalezení chyby

  • úspěšný test je takový, který objevil dosud neobjevené chyby

  • může ukázat, že pro určitá data program vyhovuje požadovaným specifikacím. Je to indikací spolehlivosti a kvality softwaru.

  • testování má zvýšit pravděpodobnost, že v programu nejsou chyby

  • měly by vztahovat k požadavkům zákazníka

  • měly být plánovány v předstihu (plánovat je jakmile jsou specifikovány požadavky, navrhnout data, jakmile je proveden návrh programu.)

  • úplné otestování není možné (nelze otestovat počet všech kombinací cest programem)

Principy testování:

Testy by se měly vztahovat k požadavkům zákazníka (většina defektů z pohledu zákazníka se projeví neshodou s požadavky). Testy by měly být plánovány v předstihu (plánovat je jakmile jsou specifikovány požadavky, navrhnout data, jakmile je proveden návrh programu.) Princi Pareto: většina všech neobjevených chyb má původ v několika málo modulech. Problémem je ty moduly nalézt.

Testování by mělo začít testováním “v malém” a pokračovat testování “ve velkém”. (Začít testováním modulů, pak integrovaných skupin (clusterů) modulů a nakonec celého systému). Úplné otestování není možné (nelze otestovat počet všech kombinací cest programem). Testování by mělo být vedeno nezávislou třetí stranou (jiný úhel pohledu, snaha nalézt chybu, ne dokázat, že tam není)

Testovatelnost:

Výčet vlastností vedoucích k dobré testovatelnosti:

operability - spustitelnost (čím lépe pracuje, tím účinněji může být otestován), chyby nebrání běhu programu, může být testován a vyvíjen současně

observability - přehlednost (testuješ, co vidíš) - různé výstupy pro různé vstupy, stavy systému a proměnné jsou viditelné během chodu, faktory ovlivňující výstup jsou viditelné, nesprávné výstupy jsou lehce identifikovatelné, vnitřní chyby jsou automaticky detekovány a zaznamenávány, je dostupný zdrojový kód

controllability - (čím lépe lze software kontrolovat/řídit, tím spíše lze testování automatizovat a optimalizovat) - všechny možné výstupy jsou generovány nějakou kombinací vstupů, veškerý kód je spustitelný nějakou kombinací vstupů, vstupní a výstupní formát je konsistentní a strukturovaný, testy mohou být specifikovány, automatizovány a reprodukovány

dekomponovatelnost - (kontrolováním rozsahu testování můžeme rychleji oddělit problémy a provést následné testy)

jednoduchost - (čím méně máme testovat, tím rychleji to můžeme provést) - jednoduchost funkce, struktury, kódu

stabilita - (čím méně změn softwaru, tím lépe) - nejsou časté, jsou řízené, neovlivní provedené testy

srozumitelnost - (čím víc máme informací, tím budou testy chytřejší) - srozumitelný návrh, srozumitelné závislosti mezi vnitřními, vnějšími a sdílenými komponentami, dostupnost a srozumitelnost technické dokumentace

White-box testing (strukturální testování)

  • vychází ze znalosti programové řídicí struktury. Testy by měly vyzkoušet alespoň jeden průchod všemi příkazy a vyzkoušet všechny logické podmínky.

  • je to testování v malém, pro malé programy a moduly

  • testování toho, zda všechny vnitřní komponenty správně fungují (ale nemusí postihnout chybějící alternativy)

  • všechny samostatné cesty uvnitř modulu budou provedeny alespoň jednou

  • všechny podmínky se projdou podél větve s hodnotou ANO (true) i podél větve s hodnotou NE (false)

  • projde všechny cykly

  • prověří vnitřní datové struktury

Black-box testing (funkcionální testování)

  • hledá chyby ve funkčním chování, bez ohledu na jejich implementaci. Je zaměřeno na informační doménu, odvozuje testovací data ze vstupních a výstupních podmínek.

  • testování správného provádění všech navržených funkcí produktu (ale nemusí postihnout všechny podrobnosti implementace)

  • je založeno na funkčních požadavcích.

  • vzhledem k white-box testing jde o doplňkovou nikoli alternativní metodu

  • aplikuje se až po white-box testing.

Hledá:

  • nesprávné nebo chybějící funkce

  • chyby rozhraní

  • chyby datových struktur nebo přístupu k externím databázím

  • chybné chování (performance)

  • chyby

  • inicializace nebo skončení

Speciální metody testování jsou pro různé typy programů a aplikačních oblastí - GUI, klient/server, real time, dokumentace a help.

Ruční testování

  • tester testuje aplikaci a její funkce - většinou se to týká uživatelského rozhraní na klientské vrstvě (př. přihlášení do aplikace, proklikání menu aplikace, vyplnění formuláře a uloženi apod.) nebo něčeho co nelze dobře otestovat automatizovaně

Automatizované testování

  • používá se k tomu nějakého nástroje pro ten účel

  • nejprve se napíše scénář pro testování (může to byt i rozsáhlý program v nějakém programovacím jazyce nebo jen vstupní data)

  • scénář může pokrývat opakovaně testovaní určité funkce nebo části aplikace nebo informačního systému, může se jednat o simulace i několika tisíc uživatelů paralelně tedy ve stejný okamžik pro stejnou funkčnost ale rozdílná data

  • součástí bývá přehled statistik a reportu pro porovnávání výsledků apod.

Unit testy (testování jednotek)

  • to řeší především programátor

  • jedna se o testování části kódu či metod tříd nebo programovacích standardů jestli vrací správné výsledky

Některé metodiky doporučují dokonce začínat právě testováním a dále průběžně testovat.

Test bezespornosti

  • řešíme konzistenci modulů, dělá se průběžně, na každé úrovni se používají různé moduly

Test úplnosti

  • zda je vše popsáno tak aby tomu programátor rozuměl, jestli je to podle BA, požadavků, návrhz implementace