© Jiří Sochor, Jaroslav Ráček 1 Testování SW produktů © Jiří Sochor, Jaroslav Ráček 2 Cena testování během vývoje 7% 16% 24% 24% 29% požadavky předběžný návrh podrobný návrh testování kódu a jednotek integrační a systémové testy © Jiří Sochor, Jaroslav Ráček 3 Zdroje defektů 7% 27% 10% 56% návrh jiné kód požadavky © Jiří Sochor, Jaroslav Ráček 4 Pokud by 99.9% funkcí bylo správně ... • 9,703 šeků by bylo každou hodinu proplaceno z jiných bankovních účtů. • 27,800 dopisů by se každou hodinu ztratilo. • 3,000,000 nesprávných předpisů na léky by se ročně vydalo. • 8,605 komerčních letů by každoročně během startu havarovalo. © Jiří Sochor, Jaroslav Ráček 5 Produkty podle etap Software Concept Requirements Analysis Design Coding and Debugging Systems Testing Deployment & Maintenance Possible Deliverables by Phase Concept Document Statement of Work (SOW) Project Charter RFP & Proposal Requirements Document (Software Requirements Specification) Work Breakdown Structure (WBS) Functional Specification ( Top Level Design Specification) Entity Relationship Diagram Data Flow Diagram Detailed Design Specification Object Diagrams Detailed Data Model Coding Standards Working Code Unit Tests Acceptance Test Procedures Tested Application Maintenance Specification Deployed Application Project Development Plan (Software Development Plan ) Baseline Project Plan Quality Assurance Plan Configuration Management Plan Risk Management Plan Integration Plan Detailed SQA Test Plan SQA Test Cases User Documentation Training Plan © Jiří Sochor, Jaroslav Ráček 6 • Testování je proces spuštění programu s cílem nalézt chyby. • Dobrý testovací případ má vysokou pravděpodobnost nalezení dosud nenalezené chyby. • Úspěšný test je takový, který odhalí dosud neodhalenou chybu. - Myers Co je testování? © Jiří Sochor, Jaroslav Ráček 7 ... takže: Def.: Test je úspěšný, pokud neodhalí žádné anomálie na výstupu programu. Def.: Test je úspěšný, pokud zjistí přítomnost jedné či více chyb v programu. - Myers, 1979 © Jiří Sochor, Jaroslav Ráček 8 V - procesní model Product Requirements and Specification Analysis Project Requirements and Planning Production, Operations, and Maintenance System Testing and Acceptance Testing Integration and Testing Unit Testing Coding Detailed Design High-Level Desig Non-functional Requirements Load & Performance Test User Interface Design Usability Test © Jiří Sochor, Jaroslav Ráček 9 • Testování nemůže ukázat nepřítomnost defektů, může pouze ukázat, že v softwaru jsou chyby. • Testování také ukazuje funkce a výkon. • A je také ukazatelem kvality software. Co testování ukazuje? © Jiří Sochor, Jaroslav Ráček 10 Každý inženýrský výrobek může být testován dvěma způsoby: • test proti specifikovaným funkcím = Validace “Dělat správné věci” • test proti vnitřní činnosti = Verifikace “Dělat věci správně” Verifikace &Validace © Jiří Sochor, Jaroslav Ráček 11 Testování v týmu Testování je destruktivní činnost! Programátor není dobrým testerem vlastního výtvoru. Detailní znalost struktury programu usnadňuje hledání a opravu chyb. Je nutná spolupráce dvou nezávislých, organizačně samostatných týmů. Tým kvality Realizační tým © Jiří Sochor, Jaroslav Ráček 12 Úplné testy • I u malých programů může být počet různých logických cest ohromný. • Program se 100 řádky, několik vnořených cyklů, každý proveden 20 krát. Existuje přibližně 1014 možných cest, které mohou být provedeny. • Při rychlosti 1 test/ms by testování trvalo 3170 roků! • Úplné testování není realizovatelné. © Jiří Sochor, Jaroslav Ráček 13 Selektivní testy • I tehdy, kdy úplné testování není reálné (prakticky vždy!), testování „bílá skříňka“ by nemělo být vynecháno. • Důležité logické cesty a cykly by měly být testovány. • Selektivní testování validuje rozhraní a vytváří důvěru ve vnitřní činnost software. © Jiří Sochor, Jaroslav Ráček 14 Dynamické testování • Provedení počítačového programu s předem určenými vstupy. • Porovnání dosažených výsledků s očekávanými výsledky. • Testování je vlastně vzorkování, nemůže absolutně prokázat absenci defektů. • Každý software má vši, testování nezaručí odvšivení. © Jiří Sochor, Jaroslav Ráček 15 Testovací případy • Klíčové položky plánu testování. • Mohou obsahovat skripty, data, kontrolní seznamy. • Mohou mít vztah k Matici pokrytí požadavků. - nástroj pro sledování © Jiří Sochor, Jaroslav Ráček 16 „Černé a bílé skříňky“ FUNKCE - test činnosti každé funkce - test ČERNÉ SKŘÍŇKY VNITŘNÍ PRÁCE - test, zda ‘všechny motory pracují’ - test BÍLÉ SKŘÍŇKY © Jiří Sochor, Jaroslav Ráček 17 Testování „černá skříňka“ • Funkční testování • Program je “černá skříňka” – Nezajímá nás, jak to pracuje, ale co to dělá. – Zaměřeno na vstupy & výstupy • Testovací případy založené na SRS (specifikacích požadavků) © Jiří Sochor, Jaroslav Ráček 18 Návrh testu „černé skříňky“ - příklad s := Hledej (NejakePole,UlozenaHodnota) 1. 1 existuje 2. 1 není 3. 0 4. sudé je první 5. sudé je poslední 6. sudé není 7. liché je první 8. liché je poslední 9. liché není 10. sudé je v obecné pozici 11. liché je v obecné pozici velikost pole hledaný prvek V tomto testu je obsažena zkušenost s mnoha verzemi vyhledávacích programů. © Jiří Sochor, Jaroslav Ráček 19 Testování „bílá skříňka“ • Zohledňuje strukturu programu • Pokrytí – provedené příkazy – cesty průchodu kódem © Jiří Sochor, Jaroslav Ráček 20 Testování „bílá skříňka“ 1. výpočet cyklomatické složitosti: počet rozhodnutí + 1 (predikátové uzly) nebo počet ploch (oblastí) nebo hrany – uzly + 2 © Jiří Sochor, Jaroslav Ráček 21 Testování „bílá skříňka“ 2. Nalezneme nezávislé cesty. Protože cyklomat. složitost = 4 existují 4 nezávislé cesty: cesta 1: 1,2,3,6,7,8 cesta 2: 1,2,3,5,7,8 cesta 3: 1,2,4,7,8 cesta 4: 1,2,4,7,1,2,4,...7,8 2 4 3 5 6 7 8 1 © Jiří Sochor, Jaroslav Ráček 22 Testování „bílá skříňka“ • Vývojový diagram není nutný, ale obrázek pomůže vysledovat příslušné cesty. • Testy základních cest by měly být provedeny u kritických modulů. © Jiří Sochor, Jaroslav Ráček 23 Testování jednotek, modulů • Typ testování „bílá skříňka“ - někdy ale jako „černá skříňka“ • Kdo testuje jednotky? - vývojáři - testy jednotek jsou programovány – stejný jazyk jako moduly – alt.název “Testovací drivery” • Individuální testy mohou být seskupeny - „Kolekce testů“ (Test suites) • Kdy se testují jednotky? - postupně během vývoje - po dokončení individuálních modulů © Jiří Sochor, Jaroslav Ráček 24 Integrace & Testování • Vývoj/integrace/testování - nejčastější místo, kde dochází k překrývání aktivit • Někdy je integrace/testování považováno za jednu etapu • Postupně propojuje funkcionalitu • QA tým pracuje souběžně s vývojovým týmem © Jiří Sochor, Jaroslav Ráček 25 Integrační postupy Shora dolů • Nejprve je implementováno jádro (kostra) systému. • Zkombinováno do minimální „skořápky“ systému. • Pro doplnění neúplných částí se použijí „protézy“ nahrazované postupně aktuálními moduly. Zdola nahoru • Začne s individuálními moduly a sestavuje zdola. • Individuální jednotky (po testování jednotek) jsou kombinovány do subsystémů. • Subsystémy jsou kombinovány do celku. © Jiří Sochor, Jaroslav Ráček 26 Testování shora-dolů, zdola-nahoru Shora-dolů (TDT): použití „stubs“ (pahýly, protézy) - jednoduché náhražkové objekty se shodným rozhraním. Zdola-nahoru(BUT): klasický testovací proces s nadřazenými testovacími objekty - „drivers“. Testování shora-dolů odhaluje chyby analýzy a návrhu, je v souladu s prototypováním. © Jiří Sochor, Jaroslav Ráček 27 Nevýhody TDT a BUT Nevýhody TDT: - Složité objekty, moduly, nelze jednoduše zaměnit za „protézu“. - Výsledky testů na vyšších úrovních nemusí bý přímo „viditelné“. Nevýhody BUT: - Čas a náklady na konstrukci „drivers“ pro testování jsou obvykle vyšší, než u „protéz“. - Až v závěru vznikne program použitelný pro předvedení, ve formě „prototypu“. Obě metody mají své nevýhody, nelze říci, že jedna je nejlepší. © Jiří Sochor, Jaroslav Ráček 28 Atributy integrace • Kdo dělá integrační testování? • vývojářský a/nebo QA tým • Počet pracovníků a rozpočet jsou na vrcholu • „Jde do tuhého“ • Problémy: • práce pod tlakem • blíží se datum odevzdání • neočekávaná selhání (vši) • motivační problémy • konflikty při přejímání zákazníkem © Jiří Sochor, Jaroslav Ráček 29 Integrační testování A B C D A B C D Testování modulů Integrační testování Kde je chyba ? Inkrementální integrace a testování © Jiří Sochor, Jaroslav Ráček 30 Úkoly • Pro svůj projekt (část projektu) vytvořte plán testování a začleňte jej do celkového plánu projektu (pokud jste tak již neučinili). • Pro projekt navrhněte příklad konkrétního testu typu „černá skříňka“.