TS Flashcards
7 zakladnich principu testovani
- Testovani pouze najde chyby, ale nedokaze, ze chyby nejsou
- Nelze otestovat vsechno
- Testovani by mel byt nazaseno v kazde fazi vyvoje systemuu
- Defekty se shlukuji, chyby nejsou rozprostreny rovnomerne
- Stale ty same testy casem nebudou moct nalezt chyby - update
- Dukladnost testovani se odviji od zopdovednosti systemu
- Nalezeni a oprava chyb nezachrani nefunkcni pozadavky
Zakladni deleni testu podle typu
- Podle test levels:
- vyvojarske
- integracni
- systemove
- uzivatelske akcepcni - Podle znalosti vnitrni struktury:
- black-box
- white-box
- grey-box - Podle toho, kdo a kde testuje:
- alfa testy
- beta tesy - Podle technickeho postupu nebo charakteristiky systemu
- unit testy
- funkcni testy
- E2E testy
- zatezove testy
- penetracni testy
- crash testy…
Black box, white box, grey box
- Black box - nevime nic o systemu, tedy zname jenom co prijde a co ma vyjit
- testovani scenare pisu jen podle analyzy, specifikace nebo dokumentace, aniz bych znal struktury systemu
- treba testovani podle use-case - White box
- testovaci scnerae vytvarim se znalosti vnitrni struktury a funkcionality
- treba staticka analyza kodu, treba podle radek - Grey box - kombinace obou
Verifikace vs validace
Verifikace - zda system vyvijime spravne podle predpisu a dokumentace
Validace - zda vyvijime to, co klient pozadoval
Tedy je to bud technicka kontrola pozadavku, nebo business kontrola pozadavku na system
V-model
Zakladni model vyvoje a testovani softwaru:
Z pohledu vyvoje:
1. Business model
2. Pozadavky
3. Funkcni navrh
4. Technicky navrh
5. Implementace
Pod kazdou fazi mame odpovidajici tetovani:
1. Business model - produkcni provoz, prod
2. Pozadavky - uzivatelske akcepcni testy, QA
3. Funkcni navrh - systemove testy
4. Technicky navrh - integracni testy
5. Implementace - vyvojarske testy
Nevyhodou ale je, ze zavlecene chyby uz na zacatku pozadavku se muzou najednou objevit az v QA na samem konci, treba pri spatnem pochopeni pozadavku klienta, a oprava chyby je extremne draha
Test Basis a Test Level
Test Basis - leva strana V-modelu, tedy mnozina dat, nad kterou budeme vytvaret testy
- vsechny informace pro testovaci scenare
Test Level - prava strana V-modelu, tedy uz samostatne testovani, ktere ma za ukol otestovat odpovidajici hladinu V-modelu, zda patricny basis je naimplemetovan podle pozadavku
Boehmuv prvni zakon
Chyby se vyskytuji nejcasteji ve fazich pozadavku a navrhu aplikace. Cim pozdeji se odhali, tim exponencialne drazsi je jejich oprava
W-model
Realnejsi a pouzivanejsi pristup vyvoje systemu, ktery pridava kontroly k V-modelu aby v kazdem korku byla jistota, ze se vykonava jen to co ma
- Business model - revize- produkcni provoz - testy po nasazeni
- Pozadavky - revize - instalace systemu - UAT
- Funkcni navrh - revize - sestaveni systemu - systemove testy
- Technicky navrh - revize - sestaveni komponent - integracni testy
- Implementace - vyvojarske testy
UAT - uzivatelske akcepcni testy
Testovaci scenar
Jednoynacnz predpis, jakou akci v testovane aplikaci vzvolat a jakz je ocekavanz vzsledek
Je to predpis pro test, nez se zance psat
- evidujeme scenare v nastroji nejakem
- musi se udrzovat updatovana vuci aplikaci
- anglicky test case
Bud high nebo low level podle konkretnosti dat, low level scenar pracuje primo s dosazovanymi hodnotami konkretne.
High level pracuje abstaktne bez konkretnich hodnot ale pouze logicky prubeh aplikace:
treba “zmenim cenu produktu za urcitych podminek -> cena se zmenila” VS
“nastavim cenu na 10kc -> nova cena 10kc”
Struktura testovaciho scenare
ID
Nazev testu
Popis testu
Vstupni podminky
Testovaci data
Ocekavany vysledek
Stav pripravy
Nepovinne polozky:
shnuti testu
autor
priorita
testovaci prostredi
pokryte pozadavky
pokryte casi apliakce
Po spusteni se uvede:
ID
Souhrnny vysledek
Tester
Cas prvniho kroku
Cas posledniho krokku
Nalezene chyby
Regrese a test coverage
Regrese - zanaseni novych chyb vlivem oprav nebo zmen systemu
- casovy stres
- vyvojari neznaji celou strukturu systemu
Testovaci pokrytit
- jaka cast software a jeho funkci je pokryta tetovacimi scenari
- klidne na radky nebo procenta
SLA (Service Level Agreement
Dohoda mezi klientem a dodavatelem ohledne sluzeb
- treba Praci na odstraneni zavazne chyby musi dodavatel zacit do 4 hodin a opravit do 12 hodin…
Nebo “system musi byt dostupny neustale…”
Zavazky obou stran
Workaround - docasne, jednoduche, upravujici reseni
Typy chyb bugu podle priority
A - critical
Chyba blokuje podstatné procesy v aplikaci, významným
způsobem poškozuje data. Neexistuje workaround.
B - medium
Chyba výrazně znepříjemňuje práci s aplikací, je možné
aplikaci dočasně provozovat s touto chybou, ale
workaround je obtížný a znamená velké úsilí.
C - low
Chyba se kterou je možné aplikaci provozovat, znamená
akceptovatelný nekomfort, týká se nedůležitých částí
nebo dat. Existuje jednoduchý workaround.
Report o chybe
Na jeho základě vývojář znovu nasimuluje chybu, aby ji mohl lokalizovat a
opravit
Tester se nemusí pouštět do analýzy příčiny, podstatné je chybu dobře popsat
Typický report o chybě obsahuje:
* ID
* Název (shrnutí chyby)
* Odkaz na testovací scénář, který chybu odhalil
* Popis chyby
* Kde se chyba nalezla (modul aplikace, proces, funkcionalita, interface, …)
* Jaké kroky vykonat, aby se chyba vyvolala
* Nad jakými testovacími daty
* Testovací prostředí, build, release na kterém byla chyba nalezena
* Tester, který chybu nalezl
* Čas nálezu chyby
* Stav ve workflow opravy chyb (viz další slide)
Smoke test a test condition
Smoke test - sada zakaldnich testu proverujicich nejdulezitejsi funkcionalitu systemu
Test Condition - element nebo udalost v systemu, kterou je mozne proverit testovacim pripadem - treba funkce, transakce, strulktuaralni element
Klasifikační strom
- Můžeme vytvořit pro každý rozhodovací bod v aplikaci
- Dá se aplikovat na různých úrovních: vstup dat přes webový formulář, interní
výpočet a rozhodování v aplikaci, test integračního rozhraní, … - Uzly = classification ~ jednotlivé vstupy pro rozhodovací bod (příklad:
políčka z webového formuláře, část podmínky v procesu rozhodování, …) - Listy = třídy ekvivalence pro danou classification (viz dále)
Trida ekvivalence
mnozina vstupnich dat, pro kterou se program chova stejne
EC
Tedy vstupni data muzeme rozdelit na tridy ekvivalence
Muze byt bud Interval nebo diskrerni
Interval - rozmezi hodnot od az po
- tedy ma mezni podminky
Diskretni hodnoty - vycet
- vyber z predem dane mnoziny hodnot
- treba menu
- nejsou mezni podminky
- Validní třídy ekvivalence – nastavují situace, které systém zpracuje
standardním způsobem. „Správná data“. - Nevalidní třídy ekvivalence – nastavují situace, na které by měl systém
zareagovat korektním ošetřením chyby. „Naschvál zadaná neplatná data“
