Agenda. Smysl teoretických cvičení Klasifikace Obecná pravidla Bugzilla Klasické problémy Poznámky k jednotlivým pojmům Antipatterns Testování testů

Transkript

1 Testování a QA

2 Agenda Smysl teoretických cvičení Klasifikace Obecná pravidla Bugzilla Klasické problémy Poznámky k jednotlivým pojmům Antipatterns Testování testů

3 Klasifikace Kategorie black box grey box Typ unit integration Podtyp funkční nefunkční white box system system integration výkon (load/stress) bezpečnost usability localization Způsob manuální automatické Exekuce kódu statické dynamické Skupiny regresní akceptační kvalifikační usability smoke

4 Obecná pravidla Oddělené testovací prostředí Jinak se testy mohou chovat nedeterministicky. Vývojáři a testeři se mohou vzájemně rušit. Oddělení může být časové (od teď už se nevyvíjí, ale testuje) Testovací prostředí by mělo být co nejpodobnější reálnému (HW, SW) Drahé často se sahá ke kompromisům Žádná umělá degradace

5 Obecná pravidla Neoddělovat vývojáře a testery Vývojáři již při vývoji myslí na testovatelnost Nevzniká bariéra mezi vývojáři a testery Efektivnější alokace lidí. U velmi velkých systému toto neplatí

6 Obecná pravidla Testy psát co nejkratší testující jen jednu funkčnost. Minimálně dva testy na úspěch (různé parametry) Testovat mezní hodnoty a nepřípustné hodnoty parametrů. Hlavně pozor na null / 0

7 Bugzilla Bug tracking systém Zřejmě nejpoužívanější (v Profinitu tvoří páteř IS :-) ) Uchovává historii bugů i po letech lze zjistit, proč se udělalo to či ono. Životní cyklus chyby New (někdo nahlásí chybu) Assigned (ujme se jí vývojář) Fixed (chyba je opravena) Verified (interní přetestování) Closed (ověření zákazníkem). Umožňuje připojovat soubory logy, screenshoty...

8 Klasické problémy Odkládání tvorby testů až bude čas Vývoj testů ad-hoc bez jakéhokoliv plánu, rozmyšlení, architektury Někdy se vyplatí pojmout tvorbu testů jako samostatný projekt. Duplikace kódu, málo komentářů či absence dokumentace. Testy jsou, ale nikdo je nepouští. Testy se pouští, ale nikdo nekontroluje výsledky.

9 Klasické problémy Neznalost kontextu zákazníka. Například máte přetestovat opravu následující chyby: V pojištění STR se u Doložky 22 špatně aplikuje pro-rata. Může pomoci Bugzilla (nebo kolegové). Chyba objevená při testování (nebo hůř v produkci) se nedá v testovacím prostředí reprodukovat. Čím jsou testy podrobnější, tím nákladnější je jejich údržba. Tím větší tlak na dočasné vyřazení rozbitých testů

10 Automatické testy Automatické testy většinou zlepšují design aplikace. Vývojáři jsou nuceni programovat s ohledem na snadnou testovatelnost loose coupling. U složitějších aplikací usnadňují ladění Nemusí se debuggovat přes UI.

11 Manuální vs. automatické Vzájemně se doplňují Většinou není možné (ekonomické) plně pokrýt aplikaci automatickými nebo manuálními testy. Nám se osvědčilo: Před prvním nasazením se aplikace důkladně prokliká. Vytvoří se regresní testy (testují aplikaci z GUI) Selenium, HttpUnit, AutoIt Vytvoří se (během vývoje) unit testy pokrývající core funkcionalitu (výpočty, práce s daty )

12 Unit testy Testují jednotku (unit) nezávisle na ostatních unit většinou = třída. Mockování ostatních (asociovaných) tříd. Simulujeme jejich chování => testování třídy nezávisle na ostatních Typicky připojení k databázi Vede k výraznému zrychlení Nástroje: jmock, EasyMock

13 Unit testy (2) Specifická forma dokumentace kódu Z testu lze vyčíst, jak daný kód použít Dá se na ně dívat jako na rozšíření kompilátoru Kontrola sémantiky Frameworky JUnit, NUnit, TestNG (i integrační testy)

14 Testování testů? Jak poznat, že testy k něčemu jsou? Teoretici i testy se musí testovat. Do kódu záměrně zaneseme chyby a zkoumáme, zda je testy odhalí Používá se jen u mission-critical systémů Praxe měření pokrytí kódu Pokrytí metod Pokrytí řádků kódu Pokrytí větví.

15 Pokrytí kódu - Cobertura Poskytuje vývojáři informace o: Pokrytí balíčků Pokrytí tříd Pokrytí metod Pokrytí větví Reporty lze procházet až na úroveň zdrojových kódů Přehledně znázorněno, kolikrát byl daný řádek navštíven.

16 Cobertura - Nevýhody Svádí k uctívání pokrytí 100 % pokrytí kódu neznamená, že je program bez chyb Někteří projektoví vedoucí mají tendence stanovovat minimální procento pokrytí kódu. => Easy testy (testují se gettery, settery ) Někdy obtížně integrovatelná s projektem Například pokud testy běží v kontejneru Pouze pro automatické testy

17 Cobertura - Ukázkový report Screenshoty pochází z ukázkového reportu na adrese

18 Antipatterns

19 Jen jeden happy path test public class Factorial { public int eval(int cislo) { return (cislo!= 1)? cislo * eval(cislo - 1) : 1; } } public void testeval() { Factorial fact = new Factorial(); int vysledek = fact.eval(3); assertequals(6, vysledek); }

20 Kde je problém? Test projde i pro následující implementaci: public class Factorial { public int eval(int cislo) { return (cislo!= 1)? cislo + eval(cislo - 1) : 1; } } Ale i předchozí implementace je chybná eval(0); Nutno testovat mezní hodnoty

21 Easy tests Testují se snadno testovatelné podpůrné metody, ale ne hlavní logika. Gettery, settery, tostring Problém hlavně u nezkušených programátorů Časté rovněž při direktivním stanovení určitého pokrytí kódu testy.

22 Spoléhání na konkrétní implementaci Někdy je to vhodné, ale zpravidla je lepší se tomu vyhnout. public class Data { private Collection prvky = new ArrayList(); } public void pridej(object prvek) { prvky.add(prvek); } public Collection getprvky() { return prvky;} public void testpridej () { Data data = new Data(); data.pridej(0); // spolehame na autoboxing assertequals(0, ((ArrayList) data.getprvky()).get(0)); }

23 Diskuse Komentáře Otázky Připomínky Upřesnění Poznámky