Zajištění kvality programového vybavení - testování

Podobné dokumenty
Vývoj řízený testy Test Driven Development

Testování software. Jaroslav Žáček

Obsah. Úvod 9 Poděkování 10 Co je obsahem této knihy 10 Pro koho je tato kniha určena 11 Zpětná vazba od čtenářů 11 Errata 11

Testování softwaru. 10. dubna Bořek Zelinka

Testování Java EE aplikací Petr Adámek

Analýza a Návrh. Analýza

Ročníkový projekt. Jaroslav Žáček

TECHNICKÉ POŽADAVKY NA NÁVRH, IMPLEMENTACI, PROVOZ, ÚDRŽBU A ROZVOJ INFORMAČNÍHO SYSTÉMU

12 Zajištění kvality programového vybavení

12 Zajištění kvality programového vybavení

Zátěžové testy aplikací

Nebojte se přiznat, že potřebujete SQA

A7B36SI2 Tematický okruh SI08 Revidoval: Martin Kvetko

PŘÍLOHA C Požadavky na Dokumentaci

Náklady na odstranění chyby stoupají, v čím pozdější fázi životního cyklu aplikace je chyba nalezena.

Proces vývoje HRIS Vema (Human Resources Information System) Jaroslav Šmarda

WINCOR NIXDORF. Certifikovaný PCI DSS auditor - QSA

Kvalita SW produktů. Jiří Sochor, Jaroslav Ráček 1

Informační systémy 2008/2009. Radim Farana. Obsah. Nástroje business modelování. Business modelling, základní nástroje a metody business modelování.

Aplikační Dokumentace Standardy ICT MPSV

X36SIN: Softwarové inženýrství. Životní cyklus a plánování

Obsah. Zpracoval:

Analytická specifikace a její zpracování

Informace pro žadatele o certifikáty testerů softwaru ISTQB (Certifikační předpis)

End-to-end testování. 26. dubna Bořek Zelinka

2013 IBM Corporation

Odbor informatiky a provozu informačních technologií

Ročníkový projekt. Jaroslav Žáček

Michal Kolařík ISZR - Brána k základním registrům

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

RDF DSPS ROZVOJ PORTÁLU

Metodiky pro automatické testování webové aplikace. Ondřej Melkes, Martin Komenda

Mib:S4Road přechod k SAP S/4HANA. Jiří Palát

Vývoj informačních systémů. Obecně o IS

TÉMATICKÝ OKRUH Softwarové inženýrství

Specifikace předmětu plnění Datová tržiště

MST - sběr dat pomocí mobilních terminálů on-line/off-line

1 Úvod 1.1 Vlastnosti programového vybavení (SW)

Design systému. Komponentová versus procesní architektura

ové kampaně Byznys CRM s.r.o.

GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER. váš partner na cestě od dat k informacím

Architektury Informačních systémů. Jaroslav Žáček

Aktuální otázky provozu datových skladů PAVEL HNÍK

Jak efektivně ochránit Informix?

Specifikace požadavků. POHODA Web Interface. Verze 1.0. Datum: Autor: Ondřej Šrámek

1. Webové služby. K čemu slouží? 2. RPC Web Service. 3. SOA Web Service. 4. RESTful Web services

TREND POPIS ODPOVĚDNOSTI PRACOVNÍKA MANAŽER VÝVOJE

Zhodnocení architektury podniku. Jiří Mach

PRODEJ Prodej je pochopitelně základní funkcí pokladního systému. Systému MERCATOR umožňuje prodej realizovat ve 3 režimech:

Project management. Příprava projektu Zahájení High level plánování. Vykonávání Detailní plánování Vykonávání Řízení a monitorování

Monitorování a audit databází v reálném čase. Ing. Jan Musil IBM Česká republika

Kapitola 1: Úvod. Systém pro správu databáze (Database Management Systém DBMS) Účel databázových systémů

Jak testovat software v praxi. aneb šetříme svůj vlastní čas

METODIKA PROVÁDĚNÍ AUDITU COBIT

Metodika analýzy. Příloha č. 1

10 Metody a metodologie strukturované analýzy

Architektury Informačních systémů. Jaroslav Žáček

Konvence testování navazujících evidencí Metodický popis testování a evidence testů navazující evidence Verze: 2.0 Datum:

Manažerská informatika - projektové řízení

IS pro podporu BOZP na FIT ČVUT

DODATEK Č. 3 KE SMLOUVĚ O DÍLO. mezi. 1. CENIA, česká informační agentura životního prostředí. INISOFT, s.r.o.

Chyby software. J. Sochor, J. Ráček 1

Real Time programování v LabView. Ing. Martin Bušek, Ph.D.

Obsah. Kapitola 1. Kapitola 2. Kapitola 3. Úvod 9

Aplikační standard - Dokumentace ICT Standardy MPSV MPSV

Příloha 1 Specifikace předmětu plnění

Nasazení bezpečnostního monitoringu v praxi. Jan Svoboda AEC

14 Úvod do plánování projektu Řízení projektu

CMMI-DEV v.1.3 PA Configuration management

Rozdíly mezi normou ISO 9001:2008 a ISO 9001:2015.

Zkouška ITIL Foundation

Bezpečnostní politika společnosti synlab czech s.r.o.

1/1 ČESKÁ ZEMĚDĚLSKÁ UNIVERZITA V PRAZE PROVOZNĚ EKONOMICKÁ FAKULTA PŘIJÍMACÍ ŘÍZENÍ 2017/2018

Úvodem 9. Zpětná vazba od čtenářů 10 Zdrojové kódy ke knize 10 Errata 10. Než začneme 11

Návrh softwarových systémů - architektura softwarových systémů

Procesní řízení operačních sálů Mgr. Martin Gažar

Globální strategie, IT strategie, podnikové procesy. Jaroslav Žáček

eidas electronic IDENTITY PORTAL SOLUTION DEFINICE PRODUKTU TS-MyeID PORTAL

Požadavky Modelování případů užití

Testování SW produktů. Jiří Sochor, Jaroslav Ráček 1

Softwarové komponenty a Internet

Dominik Vymětal. Informační technologie pro praxi 2009, Ostrava

Implementace systému ISMS

14 Úvod do plánování projektu Řízení projektu

Personální evidence zaměstnanců

Data Protection Delivery Center, s. r. o. IDENTITY MANAGEMENT, SPRÁVA OPRÁVNĚNÍ. a SINGLE SIGN-ON. DPDC Identity. pro Vaši bezpečnost

FAKULTA INFORMAČNÍCH TECHNOLOGIÍ SPOLEČNOST DECADIC PROJEKT FRAMETRIX

Příloha: Dodatečné informace, včetně přesného znění žádosti dodavatele o dodatečné informace

Návrh vyhlášky k zákonu o kybernetické bezpečnosti. Přemysl Pazderka NCKB

Procesní přístup k projektům informačních systémů. RNDr. Vladimír Krajčík, Ph.D.

SIEM Mozek pro identifikaci kybernetických útoků. Jan Kolář , Praha, Cyber Security konference 2014

Testování SOA systémů v Oracle SOA Suite

ehealth Day 2016 Jak zavést účinná organizační a technická opatření pro řízení bezpečnosti

Konvence testování navazujících evidencí

financnasprava.sk Portál Technologie Microsoft zjednodušují komunikaci občanů s Finanční správou SR a činí výběr daní transparentnějším.

1. Integrační koncept

Objektově orientované technologie Business proces Diagram aktivit. Daniela Szturcová

- kvalitní dokumentace k SW je vyžadovaným STANDARDEM. vzájemná provázanost SW (IS) ve velkých společnostech. aktuální přehledná srozumitelná

5 Požadavky a jejich specifikace

Význam měřm. Mgr. Anna Borovcová doc. Ing. Alena Buchalcevová, Ph.D. VŠE Praha

Transkript:

Zajištění kvality programového vybavení - testování

Základy testování Proč se to dělá? Kvalita software 100% testování není možné Různé pohledy: Vývojářské testování (testy komponent, integrační, systémové ) Akceptační ověření funkce dle očekávání Ohodnocení kvality Provozní testování Psychologie testování: Záleží na stupni nezávislosti

7 principů testování 1. Ukazuje přítomnost chyb Může ukázat na přítomnost chyb, neukazuje ale že žádné nejsou 2. Vyčerpávající testování je nemožné Testování všech kombinací je nemožné (až na triviální případy) 3. Včasné testování test.aktivity musejí v rámci živ.cyklu SW začít co nejdříve 4. Shlukování chyb Jedna chyba na sebe nabaluje další 5. Pesticidní paradox Opakované testy nenaleznou nic opakovat, revidovat 6. Testování je závislé na kontextu Test. je vykonáváno odlišně v různých kontextech (banka X e-shop) 7. Falešná představa o neexistenci omylů Nalezení a opravení chyb nepomůže, když je systém nepoužitelný

Úrovně testování Testování komponent Základ testování: Požadavky na komponenty, detailní návrh, kód Objekty testování: Komponenty, programy, konverze dat, DB moduly Typicky se realizuje přístupem k testovanému kódu s pomocí unit test frameworku Chyby opravovány hned bez formálního řízení Test driven development vývoj v malých cyklech test první Integrační testování Základ testování: Návrh SW, Achitektura, Workflow, příklady použití Objekty testování:podsystémy,impl.databází, infrastruktura, ozhranní Ověřuje rozhranní mezi komponentami, interakce různých částí

Úrovně testování Systémové testování Základ testování: Specifikace požadavků systému a SW, případy užití, funkcionální specifikace, reporty a analýzy rizik Objekty testování: Systémové, uživ. a operační manuály, konfig. systému a konfig. Data Chování celého systému / produktu Testovací prostředí by mělo korespondovat s finálním produkčním Funkcionální i nefunkcionální požadavky Akceptační testování Základ testování: Uživatelské a systémové požadavky, případy použití, byznys procesy, reporty analýzy rizik Objekty testování: Byznys procesy, provozní a údržbové procesy uživ.postupy, formuláře, reporty, konfig. Data Často realizované zákazníkem Vyhodnocení připravenosti systému pro nasazení a používání

Typy testů různé účely Funkcionální testování ( co systém dělá) Zkoumání externího chování SW (black box testing) Založeny na funkcích a vlastnostech Na všech úrovních testování Nefunkcionální testování ( jak systém pracuje) výkon, zátěžové testování, stres test., použitelnost, spolehlivost, udržovatelnost, přenositelnost Strukturální testování Zkoumání interní struktury systému (white box testing) Měření pokrytí kódu, příkazů nebo rozhodování (stat.analýza) Na všech úrovních ( architektura, byznys modely..) Regresní testování Opakované testování po modifikaci -> cíl je najít defekty zanesené změnou

Proces vývoje testů Návrh testů na základě identifikace test.podmínek Specifikace testovacích případů Specifikace testovacích procedur (pořadí činností pro vykonání testu) Snaha identifikovat test.podmínky (položka nebo událost, která může být verifikována) Sledovatelnost směrem od test.podmínek zpět ke specifikacím a požadavkům -> účinná dopadová analýza a pokrytí

Specifikace test případu ID: identifikátor Položky testu: stručný popis položek a vlastností, které budou testovány Specifikace vstupů: všechny vstupy (databáze. Soubory, hodnoty z OS, atd.), specifikace vztahů mezi vstupy Specifikace výstupů: všechny výstupy a vlastnosti (např odezvy), definice přesných hodnot jednotlivých výstupů Požadavky na prostředí: HW, SW, Ostatní (např. zaškolený personál) Speciální procedurální požadavky: omezení na test.procedury (specifické nastavení atd.) Mezipřípadové závislosti: seznam identifikátorů test. Případů, které musí být vykonány před tímto případem

Kategorie technik návrhu testů Cílem je identifikace test.podmínek, test. případů a test. dat Black-box testing Založené na specifikaci nic nevíme o vnitřní struktuře vycházíme z analýzy dokumentace testování Funkcionální i nefunkcionální testování White-box testing Založené na analýze struktury komponenty nebo systému Používá se informace o tom, jak je SW vytvořen a z toho se odvozují test. Případy Rozsah pokrytí může být měřen pro existující test. Případy a další test.případy se vytvoří pro zvýšení pokrytí

Techniky black-box testing Rozdělení ekvivalencí Vstupy rozděleny do skupin s očekávaným stejným chováním Sekce ekvivalencí pro platná i neplatná data (mohou být nalezeny i pro výstupy, vnitřní hodnoty, časově související hodnoty, parametry rozhraní) Př.: Systém sledující délku hesla uživatele povoluje heslo min. 8 znaků a max 64 znaků 1. Identifikujeme hraniční hodnoty 2. Určení sekcí platných i neplatných hodnot a očekávané výsledky testu 3. Vytvoření test. případu pro každou sekci

Techniky black-box testing 2. Analýza hraničních hodnot Chování na okraji rozdělení ekviv. může být nesprávné s větší pravděpodobností, než chování uvnitř dané sekce Rozšíření předchozího příkladu o testování na hranicích rozdělení

Techniky black-box testing 3. Testování rozhodovacích tabulek Pro zachycení požadavků s logickými podmínkami Identifikování podmínky a činnosti systému Rozhodovací tab. obsahuje spouštěcí podmínky (často bool) pro všechny vstup. podmínky a výsledné činnosti pro každou kombinaci podmínek Každý sloupec odpovídá byznys pravidlu Standardem pokrytí je mít alespoň jeden test na každý sloupec v tabulce

Techniky black-box testing- příklad Systém musí rozhodnout, zda firma finančně přispěje svému zaměstnanci na důchodové spoření.aby tak učinila, musí mít zaměstnanec založeno důchodové spoření a musí být ve firmě alespoň 3 měsíce.

Techniky black-box testing- příklad Transformace na testovací případy

Transformace na testovací případy 4. Testování přechodových stavů Systém může dávat různou odpověď v závislosti na aktuálních podmínkách nebo předcházející historii Stavy musejí být samostatelné, identifikovatelné a musí jich být konečně množství Stavová tabulka Testy se navrhují pro pokrytí typických nebo všech stavů, s cílem vykonat každý přechod, testovat neplatné přechody stavů Hlavně pro embedded SW a technickou automatizaci

Techniky black-box testing 5. Testování případů užití Odvozeny z use cases Mohou být na abstraktní úrovni (úroveň obch.procesu nebo systému) Obvykle základní a alternativní scénáře Užitečné pro akceptační testování Pomůžou odhalit integrační defekty způsobené interakcí komponent Definovány z pohledu uživatele ne systému popisují co uživatel vidí a co dělá

Techniky white-box testing Založené na idetifikované struktuře SW nebo systému Příklady: Úroveň komponenty: struktura SW komponenty, tj. příkazy, rozhodnutí nebo větve Integrační úroveň: strom volání (moduly volají další moduly) Systémová úroveň: struktura menu, web.stránky, byznys procesu

Výběr testovacích technik Typ systému Regulační standardy Zákaznické / smluvní požadavky Úroveň rizika Typ rizika Cíl testování Dostupná dokumentace Znalosti testerů Čas a rozpočet Životní cyklus vývoje Modely případu užití Předcházející zkušenosti

Nástroje 1. Management testování Rozhraní pro vykonáváníí testů, sledování defektů,řízení požadavků, reportování 2. Management požadavků Popisy požadavků, trasování požadavků 3. Management incidentů Uchovávají a řídí záznamy o incidentech a požadavcích na změnu 4. Navržení testů Z návrhových modelů, kódu, GUI nebo z požadavků 5. Příprava testovacích dat Manipulace s DB, soubory nebo přenosy dat

Nástroje Statické testování 1. Nástroje pro statickou analýzu Nalezení chyb před dynamickým testováním, analýza struktur a závislostí 2. Modelovací nástroje Validace modelů SW (např. fyzický dat.model pro rel.db) Vykonávání a zaznamenávání testů 1. Nástroje pro vykonávání testů Automatické vykonávání testů, reporting, konfigurace 2. FW pro Unit test Usnadňuje testování komponent simulováním prostředí, ve kterém bude běžet 3. Komparátory testů Rozdíly mezi soubory, databázemi nebo výsledky testování 4. Měření pokrytí

Nástroje Výkon a monitorování 1. Nástroje pro dynamickou analýzu Testování komponent, integrační testování 2. Testování výkonu / stres testování Simulace zátěže Vykonávání a zaznamenávání testů 1. Nástroje pro vykonávání testů Automatické vykonávání testů, reporting, konfigurace 2. FW pro Unit test Usnadňuje testování komponent simulováním prostředí, ve kterém bude běžet 3. Komparátory testů Rozdíly mezi soubory, databázemi nebo výsledky testování 4. Měření pokrytí

Unit testy 1. Izolované Není potřeba stavět celý dům, když je potřeba testovat zvonek 2. Opakovatelné Test musí být spustitelný pro každého, nezávisle na tom jaké má nastavení prostředí 3. Rychlé Čas jsou peníze 4. Self documenting Není potřeba popisovat jak komponenta pracuje, stačí se podívat na test Nástroje: JUnit (http://www.junit.org) NUnit (http://www.nunit.org) Test NG (http://testng.org)