Testvání Tmáš Krátký, Bhumír Zubek
Schematický phled C je Sftware testing? Zkušení / simulace prvzu SW Ustanvení důvěry v t, že SW dělá c má, a nedělá, c nemá Analýza SW s cílem nalézt chyby a prblémy Měření funkcinality a kvality SW Zhdncení atributů a schpnstí SW, zda dsahují pžadvaných či akceptvatelných výsledků Inspekce, stejně jak prvádění testů kódu Executin Testing Evaluatin
Sftwarvý prces
Sftwarvý prces Převzat z http://csse.usc.edu/csse/research/coradmo/
Načasvání testů aneb V mdel
Trcha histrie Testing bjectives Pmci jasně ppsat chvání systému Nalézt defekty v pžadavcích, designu, dkumentaci a kódu jak nejdříve je t mžné DEMONSTRACE Ukázat fungvání DETEKCE Hledat defekty PREVENCE Řízení kvality 1960s 1970s 1990s
Základní pjmy Test plan (plán testů) Definuje strategii testů, vždy bsahuje Test cverage (c testvat, c netestvat), Test methds & tls (jak testvat a pmcí jakých nástrjů), Test respnsibilities (dpvědnsti) Test case (testvací případ) Mnžina pdmínek, za kterých tester určí, zda aplikace či systém funguje krektně či nikliv Test script Mnžina instrukcí (krků), které budu prvedeny na testvaném systému s cílem zjistit, zda systém funguje, jak je čekáván Test data (testvací data) Data speciálně identifikvaná pr využití v rámci testvacíh případu Test reprt (výsledky testu) Výsledek jednh či více testů bsahující minimálně identifikaci testu a jednznačný výsledek splečně s kmentářem, je-li třeba
Základní principy Kmpletní testvání není mžné Práce testerů je kreativní a nárčná Testvání je řízen riziky Analýza, plánvání a návrh jsu důležité Mtivace je důležitá Čas a zdrje jsu důležité Časvání přípravy testů hraje velku rli Měření a sledvání pkrytí je důležité
Typlgie testů Tři různé dimenze c testujeme za knfigurační jedntku jaký aspekt knfigurační jedntky testujeme s jakým cílem testujeme Funkční testy Výknvé testy Bezpečnstní testy Unit testy Integrační testy Systémvé testy Regresní testy Testy dstupnsti Testy splehlivsti Akceptační testy Kvalifikační testy Uživatelské Operační?
Začínáme testvat
Základy základů Pzitivní vs. Negativní testy vždy zkušet, jak se SW chvá v případě nepřípustných hdnt, perací, Black bx White bx Testujeme prti rzhraní Strukturální testy Nezajímá nás implementace VS. Přihlížíme k implementaci Bundary and Equivalence Analysis funguje, c fungvat má nefunguje c fungvat nemá nemezvat se na přípustné hdnty, perace, Rbustnější není nutné čast upravvat Testů je příliš mnh Partitining (rzdělení testů d tříd ekvivalence) Prvádění více testů ze stejné skupiny je redundantní Křehčí změna implementace je rzbije Vlba nejvhdnějšíh reprezentanta skupiny - ten s max. pravděpdbnstí dhalení chyby Hraniční testvací případy jsu bvykle velmi mcné a identifikují čast chyby path testing
Testvací techniky Testvací techniky / paradigmata Definuje typy testů, které jsu relevantní a zajímavé Vytváří určitý způsb myšlení a přístup k testváni Implicitně určuje limity c je relevantní, zajímavé neb mžné Existuje velké mnžství technik, cca 150 Překrývají se Jak je využíváme ke tvrbě testů? Analýza situace Mdelvání testvacíh prstru Vlba pkrytí Knfigurace testvacíh systému Prvz testvacíh systému Pzrvání testvacíh systému Zhdncení výsledků testu Testvací technika je recept pr prvádění těcht činnstí s cílem bjevit něc, c stjí za reprting.
Výběr vhdné techniky Záleží na něklika aspektech Pžadavky na testy Atributy testů Kntext vývje Elementy prduktu Kritéria kvality Rizika Omezení prjektu Příklad Funkce stejně důležité Chyby stejně závažné Která varianta je lepší?
Výběr vhdné techniky Varianta I Nalezen před releasem Nalezen pzději Celkem Funkce A 100 0 100 Funkce B 0 16 16 Funkce C 0 16 16 Funkce D 0 16 16 Celkem 100 48 148 Varianta II Funkce A 50 50 100 Funkce B 8 8 16 Funkce C 8 8 16 Funkce D 8 8 16 Celkem 74 74 148
Výběr vhdné techniky Pžadavky na testy Najít důležité bugy, aby byly dstraněny Pmci udělat ship / n-ship rzhdnutí Ověřit interperabilitu s jiným prduktem Minimalizvat náklady na technicku pdpru Ověřit shdu se specifikací Změřit kvalitu
Jak vybrat vhdnu techniku Atributy testů Pwer vyská pravděpdbnst nalezení prblému, pkud existuje Valid dhalí skutečné chyby Value dhalí chyby důležité pr uživatele Credible dpvídá čekávanému chvání uživatele Representative dpvídá tmu, čeh si uživatel nejpravděpdbněji všimne Nn-redundant reprezentuje skupinu testů, které se zaměřují na stejné rizik Mtivating klient bude chtít chyby nalezené testem pravit Perfrmable prveditelný v suladu s návrhem Maintainable udržvatelný při změnách systému Repeatable snadn a levně znvupužitelný Pp (Karl Ppper) dhalí věci týkající se základních či kritických předpkladů Cverage vyzkuší systém způsbem, kterým t nečiní jiné testy Easy t evaluate snadné a jasné vyhdncení Apprpriately cmplex dstatečná kmplexnst Accuntable bhajitelnst, prkazatelnst testu Supprts trubleshting pskytuje užitečné infrmace k ladění nalezených prblémů Cst přímé náklady, čas a pracnst Opprtunity cst náklady, které se ušetří prvedením testu
Dminantní techniky Functin Specificatin-based Dmain Risk-based Scenari Stress User High vlume autmated Explratry Regressin Regresní testvání není technika sama sbě, jde využití testů vytvřených dle jiných technik, zde explicitně vytažen pr svu důležitst
Plánvání testů
Plánvání testů Jak neuspět Zapmenut, že testují lidé Předstírat, že testeři jsu dpvědní za kvalitu, nikli management Diktvat datum spuštění bez hledu na reálná mezení prjektu Hdntit testerů pdle pčtu nalezených chyb Nedstatek vzdělávání pr testery Oddělit vývj a testvání Plán testů Klik času vyhradit na testvání? C všechn má být v plánu testů? Test cverage (c testvat) Test methds and tls (jak testvat) Test respnsibilities (dpvědnsti)
Návrh testvacích případů
Návrh testvacích případů Jak neuspět Malá diverzita pužitých technik Puze specificatin based testing Puze functin testing Příliš detailní testvací skripty Malá vlnst pr kreativitu testera Malý prstr pr náhdu Obtížná udržvatelnst Explratry testing bez patřičnéh vzdělávání Oddělení návrhu a prvádění testů Ignrvání existujících rizik Jak má vypadat testvací případ? Viz techniky testvání Viz atributy testu Míra detailu Testvací data Standardní struktura
Prvádění a vyhdncení testů
Prvádění testů Kdy začít testvat? Plánvaný harmngram vs. realita zpždění ddavatele čekat neb začít dříve? Dbré časvání je zásadní příliš pzdě prblém se splněním termínů, mál času na testvání příliš brz nestabilní SW, zbytečně vynalžený čas a práce testerů
Truble ticketing, bug reprting Základní pravidla Evidence všech nalezených issues Jediné míst pravdy Nejde jen t nahlásit issue, důležité je udělat t tak, aby byl mžné jej nasimulvat a pravit Schpnst dlišit chyby, které prkluznu Truble ticketing Bug tracking?
Reprtvání výsledků testů Standardizvaný test reprt Celkvé zhdncení testvanéh SW Dpad nedstatků na prjekt, systém, Detailní výsledky Nalezené prblémy Odchylky d testvacích případů Lg testů (prvedené testy, průběh testů, )
Řízení průběhu testů
Řízení průběhu testů Klasické aktivity jak v případě Prject managementu Alkace zdrjů Dynamické přidělvání a plánvání práce Reakce na prblémy Zlepšvání prcesu testvání Snaha ptimalizvat Musíme vědět jak na tm jsme! Klik testvání jste na prjektu už udělali? Jak a pdle čeh měřit rzsah testvání? C je t rzsah testvání?
Řízení průběhu testů C je t rzsah testvání? Typicky dpvědi zalžené na Prdukt: Otestvali jsme 70% řádek kódu Plán: Prvedli jsme 65% testvacích případů Výsledky: Našli jsme 753 chyb Pracnst: Pracvali jsme 3 měsíce 60 hdin týdně, prvedli jsme 8956 testů Kvalita testvání: Beta testeři našli 28 chyb, které nám unikly, naše regresní testy se zdají neefektivní Rizika: Dstáváme spustu stížnstí d Beta testerů, stále máme tevřených přes 500 prblémů, prdukt nebude d 3 dnů připraven ke spuštění Prjektvá histrie: V tent mment jsme na předchzích prjektech měli 12% nalezených prblémů stále tevřených, stejné by t měl být i teď Měření rzsahu testvání Žádná metrika není dknalá Řešením z praxe je? kmbinace více různých metrik pkrytí, pracnst, výsledky, rizika, ptíže,
Autmatizace v kntextu testvání
Autmatizace exekuce testů Snaha autmatizvat testy již mnh desítek let Prč? Opakvatelnst a knzistence testů stejné vstupy a pdmínky nezávisle na pčtu pakvání, dpadá prblém s mtivací lidí k pakvání stejných testů Praktická znvupužitelnst testů lze pakvat stejný test v různých prstředích, v různých knfiguracích, s mírně mdifikvanými vstupními daty, a znvuspuštění testu je levné Praktické baseline testy autmatizace umžňuje spustit velmi hutnu sadu testů, umžňují efektivně prvádět regresní testvání
Autmatizace regresních testů Velice častý scénář Typický průběh autmatizace Vytvřit testvací případ Manuálně jej spustit a věřit výstup V případě selhání nahlásit chybu V případě úspěchu ulžit výsledek Opakvaně spuštět test a výsledky prvnávat s ulženými, hlásit chybvé situace Udržvat autmatický test Je t skutečně autmatizace? Analýza prgramu Design testu První spuštění testu Ulžení výsledků Dkumentace testu Znvuspuštění testu Vyhdncení výsledků Údržba testu C z th vlastně dělá strj?
Autmatizace regresních testů Ne pr autmatizaci Tvrba testvacích případů je drahá Vyžaduje velmi technicky zkušené členy týmu Vyžaduje dbře definvané a stabilní rzhraní Vyplácí se pzdě (výhdy autmatizace v release N se vrací až v release N+1) Regresní testy mají čast menší Pwer než nvé testy Kdy může mít smysl? Vždy tázka ROI! Smke testing (Cntinuus Integratin) Cnfiguratin testing (HW SW cmpatibility) Variace (viz. debata Stchastic testing) Stress testing Lad testing Příprava testvacíh prstředí (data, )
Nástrje pr autmatizaci testů Unit a integrační testy junit, TestNG, jmck, EasyMck, DbUnit, Statická analýza kódu Findbugs, PMD, JDepend, FxCp, Funkční testy tlustý klient Selenium, HP QuickTest, IBM Functinal Tester, Funkční testy tenký klient HP QuickTest, IBM Functinal Tester, White, AutIt, Výknvé testy JMeter, Dieseltest, QALad, Kmplexní řešení HP Test Suite, IBM/Ratinal Test Suite, Příprava testvacíh prstředí IBM Optim, Grid-Tls DataMaker, Oracle Datamasking,
Gdies
Diskuze 39
Děkujeme za pzrnst Prfinit, s.r.. Tychnva 2, 160 00 Praha 6 Telefn + 420 224 316 016 Web www.prfinit.eu LinkedIn linkedin.cm/cmpany/prfinit Twitter twitter.cm/prfinit_eu
Backup slides dminantní techniky
Dminantní techniky Functin testing Test každé funkce / feature v izlaci Pužití patrných (middle-f-the-rad) hdnt Nečekáváme selhání Pzději přitvrdíme Highly credible a Easy t evaluate testy Opmíjí interakce a průzkum přínsů prgramu Specificatin-based testing Test SW prti každému tvrzení v referenční dkumentaci (specifikace, uživatelský manuál, ) Závisí na kvalitě referenční dkumentace Nutná revize Neúplnst, nejednznačnst, netestvatelnst Traceability matrix (pkrytí tvrzení testy) Highly significant (mtivating) testy Hledá špatně specifikvané blasti
Dminantní techniky Risk-based testing Představit si mžné způsby, jak může prgram selhat, a navrhnut jeden či více testů, které věří, zda skutečně daným způsbem selže. Snaha najít velké prblémy c nejdřív Optimalizace pririt dle míry rizika Kmpletní mnžina risk-based testů zalžena na úplném seznamu rizik (věcí, které mhu jít špatně) Nebezpečí špatné identifikace rizik Highly credible, highly mtivating testy Ptenciál mít high infrmatin value
Dminantní techniky Risk-based testing kde hledat prblémy Nesplnění některých atributů kvality Nvé funkce, technlgie Věci dělané na pslední chvíli Unavení, prblémví prgramátři Nejasnsti (ve specifikaci, ) Kmplexní funkce Histricky chybvé funkce Hlášené prblémy statních http://www.bugnet.cm http://www.cnet.cm dkazy na http://www.winfiles.cm některé mailing listy a další zdrje
Dminantní techniky Scenari testing Testy jak kmplexní příběhy, které dpvídají způsbu pužití prgramu v reálných situacích Nutn ddržet následující atributy Cmplex (mnh funkcí) Credible, Mtivating (dpvídá reálnému pužití) Easy t evaluate (žádná nejasnst, zda test prběhl či selhal) High pwer testy Jedná chybná funkce zhatí vše Nebezpečí nedstatečnéh pkrytí Inspirace Dle prduktů knkurence Způsby chvání zákazníka Varianta harsher testy (killer sap pera ) Běžný scenari test, puze jiná sekvence či ne tak běžná data Netypické chvání uživatele
Dminantní techniky Dmain testing Testy prměnných (vstupy, knfig. hdnty, ) Prměnné v izlaci i ve skupinách Všechny přípustné i nepřípustné hdnty Partitining, třídy ekvivalence, nejlepší zástupce Pzr na chyby mim hraniční případy High pwer, Lt f Infrmatin value testy Nižší Credible a Mtivating (crner cases) Regressin testing Vytváření testů s důrazem na jejich pravidelné pakvání p prvedení změn v prgramu Libvlný test lze pužít jak regresní Zpčátku Pwer a Credible testy, jejich síla klesá s časem a pčtem jejich pakvání (pkud se nedějí v systému velké změny) Je nutné se naučit navrhvat testvací případy s důrazem na znvupužitelnst
Dminantní techniky Stress testing Něklik definic Zatížit prgram extrémní aktivitu a sledvat, zda selže Testvání za hranicemi specifikvaných pžadavků na kmpnentu či prgram s cílem způsbit selhání systému Zahnání aplikace nestandardními pdmínkami d stavu selhání s cílem sledvat JAK prgram selže a jaká slabst se tímt dhalí High pwer testy Někdy ne tlik Credible a Mtivating testy (netypické pr uživatele) Prblémy s diagnstiku v případě selhání High vlume autmated testing Randm / Stchastic testing Strukturu testu navrhuje člvěk, jedntlivé testvací případy vyvíjí, spuští a interpretuje strj, který následně upzrňuje na selhání Nutná maximální (kmpletní) míra autmatizace Testy někdy slabé, mál Credible a Mtivating, není t řemeslná práce Nutn zabudvat trubleshting
Dminantní techniky User testing Testvání, které dělají skuteční uživatelé, ne testeři předstírající uživatele Navrhvat testy mhu testeři Libvlný test lze pužít jak User test Důležité je nechat uživateli dstatek prstru Credible a Mtivating testy Explratry testing Libvlné testvání takvé, že tester aktivně kntrluje návrh testu během jejich prvádění a využívá infrmace nabyté během testvání k návrhu nvých a lepších testů Očekávané výsledky ani knkrétní pdba testů není definvaná, záleží na uvážení testera Pužívání mnha stylů, pdle th, který je zrvna nejvhdnější pr splnění cíle Nutný velmi zkušený tester se znalstí prduktu, dmény, test. technik, Vhdné pr párvé testvání