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

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

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

A7B36SI2 Tematický okruh SI08 Revidoval: Martin Kvetko

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

Vývoj řízený testy Test Driven Development

3 Inženýrství systémů založených na počítačích (Computer-based System Engineering)

5 Požadavky a jejich specifikace

A7B36SI2 Tematický okruh SI11 Revidoval: Martin Kvetko

5 Požadavky a jejich specifikace

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

MATURITNÍ OTÁZKY ELEKTROTECHNIKA - POČÍTAČOVÉ SYSTÉMY 2003/2004 PROGRAMOVÉ VYBAVENÍ POČÍTAČŮ

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

3 Inženýrství systémů založených na počítačích (Computer-based System Engineering)

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

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

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

2 Životní cyklus programového díla

Řízení kvality SW produktů Jiří Sochor, Jaroslav Ráček 1

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

6 Objektově-orientovaný vývoj programového vybavení

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

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

Analytická specifikace a její zpracování

NPRG030 Programování I, 2015/16 1 / :25:32

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

ČÁST 1. Základy 32bitového programování ve Windows

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

Vstupní požadavky, doporučení a metodické pokyny

Obsah. Předmluva 13 Zpětná vazba od čtenářů 14 Zdrojové kódy ke knize 15 Errata 15

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

Zátěžové testy aplikací

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

Maturitní otázky z předmětu PROGRAMOVÁNÍ

Software generické produkty - smluvní, zakázkové produkty - - udržovatelnost spolehlivost efektivita použitelnost specifikace

Architektura softwarových systémů

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

7 Jazyk UML (Unified Modeling Language)

- 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á

Evropský sociální fond Praha & EU: Investujeme do vaší budoucnosti

7. Pracovní postupy. Fakulta informačních technologií MI-NFA, zimní semestr 2011/2012 Jan Schmidt

Testování software. Jaroslav Žáček

KIV/ASWI 2007/2008 Techniky zajištění kvality software. Kvalita software Techniky včasné detekce

Sdílení dat mezi podprogramy

8 Přehled OO metodik (metod, metodologií)

8 Přehled OO metodik (metod, metodologií)

Projekt Velryba Ozdravné pobyty pro děti. Semestrální projekt

CASE. Jaroslav Žáček

Evropský sociální fond Praha & EU: Investujeme do vaší budoucnosti

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

Programovací jazyk Pascal

Platforma.NET 11.NET Framework 11 Visual Basic.NET Základní principy a syntaxe 13

Hodnoticí standard. Programátor (kód: M) Odborná způsobilost. Platnost standardu. Skupina oborů: Informatické obory (kód: 18)

Obsah. Zpracoval:

Testování, ladění a dokumentace programů

11 Návrh programového vybavení

Primární klíč (Primary Key - PK) Je právě jedna množina atributů patřící jednomu z kandidátů primárního klíče.

1 Webový server, instalace PHP a MySQL 13

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

7 Jazyk UML (Unified Modeling Language)

CASE nástroje. Jaroslav Žáček

10 Metody a metodologie strukturované analýzy

ZEMĚMĚŘICKÝ ÚŘAD. Výzkum a vývoj programového aparátu pro generalizaci státního mapového díla. Ing. Přemysl JINDRÁK

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

Název předmětu: Školní rok: Forma studia: Studijní obory: Ročník: Semestr: Typ předmětu: Rozsah a zakončení předmětu:

VÝUKOVÝ MATERIÁL. Bratislavská 2166, Varnsdorf, IČO: tel Číslo projektu

Protokol o atestačním řízení

Vyučovací hodina. 1vyučovací hodina: 2vyučovací hodiny: Opakování z minulé hodiny. Procvičení nové látky

Programování II. Modularita 2017/18

Design systému. Komponentová versus procesní architektura

01 Teoretické disciplíny systémové vědy

Joelův test. 12 kroků k lepšímu programování. Jaroslav Šnajdr

Analýza a Návrh. Analýza

Obsah. Začínáme programovat v Ruby on Rails 9. Úvod Vítejte v Ruby 15. O autorovi 9 Poděkování 9

10. Techniky formální verifikace a validace

POČÍTAČE A PROGRAMOVÁNÍ

Kam směřuje akreditace v příštích letech

Základy programovaní 3 - Java. Unit testy. Petr Krajča. Katedra informatiky Univerzita Palackého v Olomouci. 26.,27.

Uživatelské hodnocení kvality a dostupnosti ICT služeb. Zbyšek Chvojka, Mylène Veillet

Systém managementu jakosti ISO 9001

SPECIFIKA CERTIFIKACE PODLE ČSN EN ISO 9001:2001 V ORGANIZACÍCH, KTERÉ SE ZABÝVAJÍ VÝVOJEM SOFTWARE

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

Programovací techniky

VISUAL BASIC. Přehled témat

1.1 Zátěžové testování

Certifikační laboratoř OIS

Specializace Návrhář software na základě analýzy vytváří návrh softwarových aplikací ve formě schémat a diagramů.

Microsoft Word základní

Inovace bakalářského studijního oboru Aplikovaná chemie

Smysl metodiky IS/IT. Koncentrovaná zkušenost Checklist na nic nezapomeneme

Návrh softwarových systémů - úvod, motivace

Semestrální projekt. Informační systém ozdravných pobytů

Protokol o atestačním řízení

Ukazka knihy z internetoveho knihkupectvi

Čtvrtek 8. prosince. Pascal - opakování základů. Struktura programu:

Vlastnosti algoritmu. elementárnost. determinovanost. rezultativnost. konečnost. hromadnost. efektivnost

Principy počítačů I Netradiční stroje

KATALOG SLUŽEB NÁSLEDNÉ PODPORY

ISO 9001 : Certifikační praxe po velké revizi

Management rizik v životním cyklu produktu

PROMĚNNÉ, KONSTANTY A DATOVÉ TYPY TEORIE DATUM VYTVOŘENÍ: KLÍČOVÁ AKTIVITA: 02 PROGRAMOVÁNÍ 2. ROČNÍK (PRG2) HODINOVÁ DOTACE: 1

Transkript:

12 Zajištění kvality programového vybavení Obecně dva druhy kvality u technických produktů: a) Kvalita návrhu - vlastnosti komponent, specifikované návrháři. U SW se týká analýzy a specifikace požadavků a návrhu. b) Kvalita shody - stupeň souladu výroby se specifikací návrhu. U SW se týká implementace. Řízení kvality - série inspekcí, posuzování a testů prováděných během vývoje s cílem zajistit, že každý výsledek splňuje požadavky na něj kladené. Zajištění kvality - funkce spojené s kontrolami a zprávami pro management. Náklady kvality: a) prevence - plán kvality, posuzování, testovací podpora, školení, b) odstranění chyb - vnitřní (před odevzdáním) - ladění, odstranění, - vnější (po předání) - řešení reklamace, záruční práce, zaslání opravené verze, hot line, - náklady na odstranění rostou v závislosti na fázi vývoje. Jaroslav Zendulka: Projektování programových systémů - 12 Zajištění kvality programového vybavení 1 12.1 Kvalita programového vybavení Kvalita programového vybavení je soulad s explicitně stanovenými funkčními a výkonnostními požadavky, explicitně dokumentovanými vývojovými standardy a implicitními vlastnostmi, které jsou očekávány od každého profesionálně vyvíjeného programového vybavení. Faktory ovlivňující kvalitu (Mc Call): a) Operace produktu (správnost, spolehlivost, efektivita, integrita, použitelnost) b) Revize produktu (udržovatelnost, flexibilita, testovatelnost) c) Přechod produktu (přenositelnost, opakované použití, interoperabilita) Zajištění kvality SW - plánovaný systematický sled akcí, vyžadovaný k zajištění kvality. Jaroslav Zendulka: Projektování programových systémů - 12 Zajištění kvality programového vybavení 2

Analýza a návrh Kódování Údržba Softwaroví inženýři Skupina zajištění (řízení) kvality (SQA group) Aktivity skupiny zajištění kvality: - příprava plánu kvality projektu (prováděná hodnocení, audity a oponování, standardy použité v projektu, dokumentace, plán testů, postupy při zjištění chyb) - účast na tvorbě popisu procesu projektu (inženýři vyberou, skupina posuzuje) - oponování vývojových aktivit a výsledků aktivit - dokumentování odchylek od stanoveného procesu a tvorba zpráv pro management - řízení a správa změn, sběr a analýza softwarových metrik, Jaroslav Zendulka: Projektování programových systémů - 12 Zajištění kvality programového vybavení 3 Mezinárodní standardy (ISO 9001) Systém řízení kvality Příručka kvality Standardy Procedury Kontroly Projekt 1 Plán kvality Projekt 2 Plán kvality Projekt n Plán kvality Jaroslav Zendulka: Projektování programových systémů - 12 Zajištění kvality programového vybavení 4

Př) Doporučení pro zápis programů v C++ Převzato z knihy Maths Henricson, Erik Nyquist: Industrial Strength C++. Prentice Hall, 1997, ISBN 0-13-120965-5 Pojmenování Smysluplná jména Používejte smysluplná jména. Pro identifikátory používejte anglická jména Buďte konzistentní při pojmenovávání funkcí, typů, proměnných a konstant. Kolidující jména Globální by měla být pouze jména pro namespace. Nepoužívejte globální deklarace using a direktivy using uvnitř vkládaných souborů. Nevhodná jména Nepoužívejte identifikátory obsahující dvě nebo více podtržení za sebou. Nepoužívejte identifikátory začínající podtržením. Organizace zdrojového kódu Každý vkládaný soubor by měl být soběstačný. Vyhýbejte se vkládání nepotřebných souborů. Zabraňte vícenásobnému vkládání uzavřením veškerého kódu ve vkládaných souborech do podmíněného překladu. Definice inline metod by měly být umístěny v samostatném souboru. Jaroslav Zendulka: Projektování programových systémů - 12 Zajištění kvality programového vybavení 5 12.2 Formální oponentury (posuzování) - filtr procesu vývoje, vyčištění produktů vývoje Důvody: 1. Mýlit se je lidské. 2. Autor přehlédne řadu chyb. Cíl: odhalení chyb, upozornění na potřebná vylepšení, sjednocení způsobu vývoje Př.) Walkthrough - schůzky: 3 až 5 lidí, příprava účastníků (max. 2 hod.), trvání max. 2 hod. - účastníci: vedoucí oponent, oponenti, autor - procházení závěr (přijetí/nutnost menších modifikací/odmítnutí) Jaroslav Zendulka: Projektování programových systémů - 12 Zajištění kvality programového vybavení 6

12.3 Verifikace a validace Validace: Vytváříme správný produkt? Verifikace: Vytváříme produkt správně? Techniky: a) statické b) dynamické () Statické techniky Specifikace požadavků Návrh architektury Detailní návrh Program Prototyp Dynamické techniky : a) chyb (defect testing) b) statistické - výkonnostní a spolehlivostní Jaroslav Zendulka: Projektování programových systémů - 12 Zajištění kvality programového vybavení 7 chyb Dobrý test - test s vysokou pravděpodobností odhalení dosud neodhalených chyb. Úspěšný test - objeví dosud neodhalenou chybu. nemůže prokázat nepřítomnost chyb, může pouze ukázat, že v programu chyby jsou. Ladění Lokalizuj chybu Navrhni opravu Oprav chybu Znovu testuj Testovací případy Výsledky testů Provedení testů Regresní testy Opravy Další testy Předpokládané příčiny Identifikované příčiny Ladění Jaroslav Zendulka: Projektování programových systémů - 12 Zajištění kvality programového vybavení 8

12.4 Strategie jednotek modulů podsystémů Systémové Přejímací komponent Integrační uživatelem Specifikace požadavků Specifikace systému Systémový návrh Detailní návrh Plán přejímacích testů Plán integračních testů systému Plán integračních testů podsystémů jednotek a modulů Provoz Přejímací Integrační systému Integrační podsystémů Jaroslav Zendulka: Projektování programových systémů - 12 Zajištění kvality programového vybavení 9 jednotek Testovací případy Rozhraní Lokální datové struktury Hraniční podmínky Nezávislé cesty Zpracování chyb Jednotka Driver Testovací případy Testovaná jednotka Stub Stub Výsledky Jaroslav Zendulka: Projektování programových systémů - 12 Zajištění kvality programového vybavení 10

Integrační a) neinkrementální b) inkrementální shora - dolů M 1 M 1 M 1 M 1 M 2 S 3 S 4 M 2 M 3 S 4 M 2 M 3 M 4 M 2 M 3 M 4 S 5 - měl by být použit při vývoji programu shora dolů, evolučním prototypování apod. - příklad náhražek : zobrazení zprávy, zobrazení předaného parametru, vrácení hodnoty z tabulky, souboru nebo zadané + možnost odhalení chyb (strukturních) v ranném stádiu programování, brzy je k dispozici systém s omezenou funkčností (psychologický efekt, možnost validace) - nutnost implementace náhražek zdola - nahoru S 5 M 5 Jaroslav Zendulka: Projektování programových systémů - 12 Zajištění kvality programového vybavení 11 D 1 D 2 M 1 M 3 M 2 M 3 M 4 M 2 M 3 M 4 M 5 M 5 M 5 - příklad driveru : spuštění podřízeného, zobrazení vráceného parametru, předání hodnoty z tabulky, souboru nebo zadané - použití zpravidla pro kritické komponenty, jinak shora dolů Regresní - po přidání modulu, resp. provedené změně (údržba). Cíl: Ověření, že to, co fungovalo před přidáním modulu (změnou), funguje i po něm porovnáním výsledků testů. Zahrnuje: - reprezentativní vzorek testů ověřujících všechny funkce, - nové testy, zaměřující se na funkce, které pravděpodobně byly ovlivněny, - testy zaměřující se na nové funkce, resp. změny. - problém regresního interakčních programů s GUI. Jaroslav Zendulka: Projektování programových systémů - 12 Zajištění kvality programového vybavení 12

Validační Validace je úspěšná, funguje-li programové vybavení tak, jak to zřejmě očekává zákazník. Dva případy: a) programové vybavení vytvářeno pro jednoho zákazníka přejímací testy (alfa ) b) programové vybavení vytvořeno jako produkt na trh beta Systémové (kompletní systém s počítači) - zaměření se na vlastnosti, které nelze ověřit samostatně (výkonnost, bezpečnost, zotavení, ) Jaroslav Zendulka: Projektování programových systémů - 12 Zajištění kvality programového vybavení 13 Některé speciální typy testů Výkonnostní, kapacitní vliv zátěže. Operační delší dobu v provozních podmínkách V plném provozu (full scale) pokračování operačních, přiblížení se limitu Přetížení (stress) chyby při přetížení, chování Negativní chybné používání. Ergonomické uživatelské rozhraní (konzistence, čitelnost, barvy, nápověda, ) Dokumentace instalace, použití (srozumitelnost, aktuálnost, vyváženost kapitol, Regresní viz integrační. Jaroslav Zendulka: Projektování programových systémů - 12 Zajištění kvality programového vybavení 14

12.5 Techniky chyb Testovací případy Testovací data Výsledky testů Zprávy o testech Návrh testovacích případů Příprava testovacích dat Běh programu s testovacími daty Porovnání výsledků s testovacími případy - úplné prakticky nemožné podmnožina případů, např.: - každý příkaz programu proveden alespoň jednou nebo - schopností systému důležitější než komponent, starých schopností (u nového systému) důležitější než nových, typických situací mnohem důležitější než okrajových Tři přístupy k : a) Funkční (black-box), b) Strukturní (white-box), c) rozhraní Jaroslav Zendulka: Projektování programových systémů - 12 Zajištění kvality programového vybavení 15 Tým testerů Tým vývojářů Funkční rozhraní Strukturní Systém Podsystém Jednotka a modul Funkční Vstupní testovací data Testovaný systém Výsledky testů I e O e Problém: nalezení co nejvíce dat z I e Jaroslav Zendulka: Projektování programových systémů - 12 Zajištění kvality programového vybavení 16

Metoda rozčlenění podle ekvivalence (equivalence partitioning) - rozčlenění dat do tříd ekvivalence a výběr kandidátů Př) Test podprogramu pro vyhledání prvku v poli procedure Search (Key: ELEM; T: ELEM_ARRAY; Found: out BOOLEAN; L: out ELEM_INDEX); Pre-condition TFIRST <= TLAST -- the array has at least one element Post-condition -- the element is found and is referenced by L (Found and T(L) = Key) or -- the element is not in the array (not Found and not (exists i, TFIRST>= i <= TLAST, T(i) = Key)) Třídy ekvivalence: a) prvek je-není v poli b) pole má jeden-více prvků c) hledaný prvek je první-poslední-uprostřed - hraničních podmínek a výjimečných situací Jaroslav Zendulka: Projektování programových systémů - 12 Zajištění kvality programového vybavení 17 Strukturní - tester zná kód a může využít znalosti struktury testované části cest - prověření všech nezávislých cest komponenty ( každý příkaz proveden nejméně jednou, každé větvení testováno pro obě podmínky) - počet nezávislých cest lze zjistit analýzou grafu toku řízení podmínek - všech logických podmínek (chyby operátorů, precedence, výrazů v podmínkách, ) cyklů - konstrukcí cyklů rozhraní - odhalení chyb v důsledku chyb rozhraní nebo chybných předpokladů - důležité u OO vývoje (opakované použití, interakce) Typy rozhraní: a) parametry b) sdílená paměť Jaroslav Zendulka: Projektování programových systémů - 12 Zajištění kvality programového vybavení 18

c) procedurální (objekty, ADT) d) předávání zpráv Typy chyb: a) chybné použití rozhraní (typ, počet, pořadí parametrů) b) chybné pochopení specifikace a rozhraní c) chyby v časování (hlavně RT systémy) - význam typových kontrol a inspekcí programu. Jaroslav Zendulka: Projektování programových systémů - 12 Zajištění kvality programového vybavení 19