SWI041: Testování programových. Jak se to oví

Transkript

1 SWI041: Testování programových systém Jak se to oví

2 Nejprve trochu kontroly Stav projekt

3 Testování,, validace a verifikace testování t Seq. sorted(sort(t)) is-permutation(t,sort(t)) validace (Val Seq) t Val. sorted(sort(t)) is-permutation(t,sort(t)) Vytvoili jsme správný produkt? (vzhledem k požadavkm daným akceptaním testem) verifikace t Seq. sorted(sort(t)) is-permutation(t,sort(t)) Vytvoili jsme produkt správn? (vzhledem ke specifikaci) SWI041 - Testování 3

4 Matematická verifikace 1. proces pro libovolná vstupní data vždy skoní (konvergence) 2. za pedpokladu, že proces pro daná vstupní data skoní, vrací pro tato vstupní data správné výsledky (parciální korektnost) (totální) korektnost SWI041 - Testování 4

5 Pro má testování takový význam? 40% asu vývoje rozsáhlých aplikací pedstavuje jejich ovování až 50% náklad na vývoj pipadá na testování 75% všech aplikací má problémy s kvalitou pouze 1% aplikací je dokoneno vas, v rámci stanoveného rozpotu a v požadované kvalit velmi znané riziko, že mj programový systém spadne do uvedených kategorií nutnost riziko ídit a snížit SWI041 - Testování 5

6 Co by mlo m být cílem c testování ovení nepredikovatelných následk událostí a stav (zejména u událostmi ízených programových systém) chování v reálných podmínkách nasazení ovení penositelnosti instalace ovení chování pi havárii a následném zotavení zákaznické zajištní kvality programového systému zajištní dvry v kvalitu SWI041 - Testování 6

7 Primárn rní testovací hlediska Funkcionalita: Dlá aplikace vše, co je požadováno? Spolehlivost: "Padá" aplikace periodicky? (nedostatek pamti, netestovaný kód, hraniní podmínky) Test aplikace: Reaguje aplikace pijateln? (výkonnostní problémy na stran klienta, výkon serveru) Test systému: Je systém výkonný i pi plném zatížení? (výkonnostní a zátžové testování simulující reálné použití systému) SWI041 - Testování 7

8 Jaké typy test pipadají v úvahu? testy základních modul testy uživatelského rozhraní integraní testy finální testy (funknost, zátž, dokumentace) akceptaní testy profylaxe = pravidelná ovování ve fázi údržby ovení zmn (pvodní kvalita + nové vlastnosti) ovení rozšiitelnosti SWI041 - Testování 8

9 Metody testování simulace innosti uživatele testy vstup a výstup modul (black-box) testy struktur systému (white-box) inspekce (audit) porovnání s definovaným standardem (atest) sledování a vyhodnocování praktického nasazení (monitor) SWI041 - Testování 9

10 Techniky testování black box Neznáme vnitek, známe požadovanou funkci white box Známe strukturu, známe požadovanou funkci SWI041 - Testování 10

11 Testování Testování podle struktury dat rozklad domény hodnot na oblasti analýza hraniních hodnot (a okolí) analýza píin a dsledk srovnávací testy (více rzných implementací) Testování podle struktury programu Testováníasových závislostí (zejména u systém urených pro ízení a u paralelních systém) SWI041 - Testování 11

12 Testování podle struktury dat Vstup EOF píliš-dlouhé-slovo... Výstup EOF hlášení chyby SWI041 - Testování 12

13 Píklad: souet kladných položek typedef struct { Klic Key; int Castka; } Veta; int sumpls(veta usek[], int delka, Klic k) { int S,i; Veta t; } i = 0; S = 0; while (i < delka) { t = usek[i]; if (t.key == k) { if (t.castka > 0) S += t.castka; } } return S; SWI041 - Testování 13

14 Graf struktury funkce sumpls i = 0 µ(sumpls) = H - U + p = 3 S = 0 i < delka t = usek[i] t.key == k S += t.castka SWI041 - Testování 14

15 Testovací data podle struktury programu pro funkci sumpls cyklomatickéíslo µ(sumpls) = 3 1. soubor s jednou vtou s jiným klíem ( k) 2. soubor s jednou vtou se stejným klíem a zápornou ástkou 3. soubor s jednou vtou se stejným klíem a kladnou ástkou SWI041 - Testování 15

16 Testovací plán testy uživatelského rozhranní (menu, formulá, sestav) testy runešených postup a jejich návaznosti na systém testy jednotlivých modul a zpsob jejich akceptace integraní testy a zpsob jejich akceptace testy výkonnosti systému a zpsob jejich akceptace testy bezpenosti systému a zpsob jejich akceptace testy obnoveníinnosti systému po výpadku a zpsob jejich akceptace SWI041 - Testování 16

17 Požadavky na proces testování testy jsou založeny na specifikaci a uživatelské dokumentaci musí být oveny minimáln všechny požadavky dané specifikací, pop. závaznými standardy pro vcnou oblast testy musí být opakovatelné, pesn definované a dokumentované musí být stanoveno a dodrženo testovací prostedí a testovací podmínky, které musí splovat podmínku neovlivnnosti prbhu testu inností jiného programového systému, nebo speciálním hardware SWI041 - Testování 17

18 Specifikace prosted edí: benchmarkové testy TPC: Nkteré kategorie test TPC: TPC-A mí výkonnost v aktualizan nároném DB prostedí typicky OLTP aplikací TPC-B hodnocení výkonnosti jádra DB systému s operaním systémem, na kterém DB server bží TPC-C modelování komplexnjšího systému TPC-D výkonnost DB systém pi dotazech pro podporu rozhodování SWI041 - Testování 18

19 P.: TPC-C - 5 transakcí vlož objednávku od zákazníka (New-order) aktualizuj saldo zákazníka dle provedené platby (Payment) vyízení objednávek (Delivery) zjisti stav poslední zákazníkovi objednávky (Order-status) monitorování skladu (Stock-level) SWI041 - Testování 19

20 P.: TPC-C C (pokra( pokra.) transakce pracují proti databázi obsahující devt tabulek transakce provádjí update, insert, delete a také rollback; využívají primární i sekundární klíe doba odezvy: 90% transakcí musí mít dobu odezvy 5 sekund (složité pak 20 sekund) SWI041 - Testování 20

21 SWI041 - Testování 21 Warehouse Warehouse W Legend Legend Table Table Name Name <cardinality cardinality> one one-to to-many many relationship relationship secondary secondary index index District District W*10 W* Customer Customer W*30K W*30K 3K 3K History History W*30K+ W*30K Item Item 100K ( 100K (fixed fixed) Stock Stock W*100K W*100K 100K 100K W Order Order W*30K+ W*30K Order Order-Line Line W*300K+ W*300K New New-Order Order W*5K W*5K 0-1

22 1 Select txn from menu: 1. New-Order 45% 2. Payment 43% 3. Order-Status 4% 4. Delivery 4% 5. Stock-Level 4% Cycle Time Decomposition (typical values,, in seconds, for weighted average txn) 2 Measure menu Response Time Menu = 0.3 Input screen Keying time Keying = Output screen Measure txn Response Time Think time Txn RT = 2.1 Think = 11.4 Average cycle time = 23.4 Go back to 1 SWI041 - Testování 22

23 Typická konfigurace pro TPC-C Emulovanáinnost uživatele Prezentaní služby Databázov zová funkcionalita Hardware Term. LAN zde se mm í doba odezvy klient/ aplikaní server C/S LAN DB server... Software Nap.: Empower prevue LoadRunner TPC-C C aplikace + transakní monitor event. knihovny pro RPC na DB nap., Tuxedo,, ODBC TPC-C C aplikace (uložen ené procedury) + databázový server + transakní monitor nap., SQL Server, Tuxedo SWI041 - Testování 23

24 Proces testování Fáze testování: definice strategie testování pro vývoj a údržbu programového systému tvorba plánu test návrh test tvorba test návrh testovacích cykl provádní a vyhodnocování test zmny SWI041 - Testování 24

25 1. fáze: f Strategie testování I obsahuje definici cíle, úelu a pozice testování odráží specifická rizika projektu specifické cíle projektu ekonomickou stránku testování a projektu organizaci projektu a životní cyklus projektu možné koncepty ovení systému v každé fázi životního cyklu urení shody finálního produktu s pihlédnutím k potebám a požadavkm uživatele ovení chování systému pomocí jeho testovacího provozu pi využití testovacích dat SWI041 - Testování 25

26 1.fáze: Strategie testování II mla by být pipravena verze pro každý projekt specifikuje systém testování (metody - typy test a postupy jejich použití) zpsob vyhodnocování standardy testovací týmy - role, mapování na organizaní strukturu, pravomoci, odpovdnosti SWI041 - Testování 26

27 2.fáze: Plánov nování test co testovat jaké jsou klíové oblasti testované aplikace (DB operace, výkonnost, ) jaké jsou priority testování (viz analýza rizik) jaké cíle jsou definovány z hlediska jakosti jak testovat výbr a zpsob použití metod testování práce se zjištnými neshodami (klasifikace závažnosti, vliv na životní cyklus) formalizace kdo bude testovat definice lidských zdroj a jejich organizace definice materiálních zdroj kdy se bude testovat SWI041 - Testování 27

28 3.fáze: Návrh N test definováníástí aplikace, které budou samostatn testovány urení testu a definování jeho cíle cílem testování je zejména odhalení chyb -> 70% negativních test testy s komplexnjším zábrem mají vtší šanci na odhalení chyb testy by mly být efektivní (úinné, ne redundantní) urení postupu testu jednotlivé kroky s urením oekávaných výsledk vstupní data (vetn hraniních a nekorektních) vychází se z dokumentace programového systému SWI041 - Testování 28 znalostí tvrc systému

29 4.fáze: Tvorba test vytváení test dle návrhu eventuální korekce navržených krok testu píprava testovacích dat specifikace testovacích podmínek (prostedí, konfigurace) a zpsobu jejich ustavení opakovatelnost vylouení vlivu jiného systému dokumentovatelnost SWI041 - Testování 29

30 5.fáze: Návrh N testovacích ch cykl testovací cyklus = skupina test provádná za uritým úelem cyklus se uruje dle specifických cíl a úelu testování v dané fázi vývoje systému (testy modul, integraní testy, ) v závislosti na procesu ovování kvality (základní úrove, bžná úrove, nadstavbové testy, speciální testy) v závislosti na pedmtu testování (testy modul, funkcí, subsystém) SWI041 - Testování 30

31 6.fáze: Provádní a vyhodnocování provedení jednotlivých krok test a dokumentování jejich výsledk dokumentace eventuáln zjištných nesoulad chyby programového systému chyby testu kategorizace chyby (dle škály) návrh ešení SWI041 - Testování 31

32 7.fáze: Zmny cíl: odstranní zjištných neshod postup zjištní píiny neshody urení zpsobu odstranní urení zodpovdného pracovníka dokumentace provádných zmn ohlášení odstranní neshody opakované testování SWI041 - Testování 32

33 Jak celý proces zvládnout? nutnost profesionálního pístupu (plánování, piazeníasových, lidských i materiálních zdroj) dsledná realizace popsaného procesu využití technologických nástroj SWI041 - Testování 33

34 Inspekce Pohled na dílo oima inspektora Audit

35 Aktivity pi p i inspekci SWI041 - Testování 35

36 Inspekní tým - 3 aža 7 lidí Role: autor - osoba, která je autorem produktu a je zodpovdná za zmny ešící nalezené problémy moderátor - osoba, která zajištuje prbh inspekce podle pipraveného plánu tená - osoba, která pekládá produkt k inspekci zapisovatel - osoba, která zaznamenává indikované chyby a spolupracuje s moderátorem na píprav zprávy o inspekci inspektor - osoba, která se v pedkládaném produktu snaží nalézt chyby SWI041 - Testování 36

37 Poznámky k inspekci: Minimální inspekní tým má ti osoby - autor, tená a moderátor/zapisovatel (všichni jsou souasn inspektory). Autor musí být vždy pítomen a nesmí zastávat žádnou jinou roli (s výjimkou inspektora). Inspekní tým by ml být pimený - nejvíce asi 7 osob, pokud je to vhodné. Inspekce není urena pro manažery. SWI041 - Testování 37

38 Metody pro výbr r moderátora Moderátor je pidlen autorm již pi vytváení plánu projektu. Moderátor je vybrán koordinátorem inspekcí. Autor si vybírá moderátora ze seznamu povených moderátor. Autor si vybírá moderátora sám. SWI041 - Testování 38

39 Plánov nování inspekce Úel: organizace inspekního procesu Úlohy: Vymezení nebo potvrzení vstupních kritérií (pro pijetí produktu k inspekci) Ustavení plánu (inspekce by rozhodn nemla trvat déle než 2-3 hodiny) Výbr participant Rozhodnutí o pehledech (pehledy slouží pro seznámení s produktem) Píprava podklad pro inspekní setkání (typ inspekce, pedmt inspekce, doba a místo konání pehled, doba a místo konání inspekce, odhad asu, požadovaná píprava) Distribuce materiál participantm Role: moderátor, autor SWI041 - Testování 39

40 Pehledy a pípravaprava na inspekci Pehledy (overview) Úel: seznámení s produktem nebo pedmtem (volitelné) Úlohy: Prezentace Role: moderátor, autor, inspektoi, ostatní Píprava Úel: porozumní materiálm, potenciální identifikace chyb Úlohy: Studium matriál Role: všichni inspektoi SWI041 - Testování 40

41 Inspekní setkání Úel: ovení produktu Úlohy: Otevení inspekního setkání (seznámení s obsahem, postupem a kritérii) Ovení pipravenosti participant (bez pípravy nemá inspekce cenu) tení produktu (tená prezentuje produkt), indikace a záznam chyb Zkontrolování seznamu chyb (zapisovatel prezentuje zaznamenané chyby) Vyhodnocení a závry inspekce (A - akceptovat bez další inspekce, B - další akceptace ponechána na moderátorovi, C - vyžaduje novou inspekci) Role: moderátor, autor, tená, zapisovatel, inspektoi SWI041 - Testování 41

42 Uzávrka inspekce Pepracování Úel: splnní výstupních kritérií Úlohy: vyešení všech chyb Role: autor Uzávrka Úcel: Potvrzení inspekce Úlohy: Ovení úprav produktu Zpráva o výsledku inspekce Role: moderátor, autor, (inspektoi) SWI041 - Testování 42

43 Akceptaní test Co to je akceptaní test Jak se definuje Jak se provede

44 Akceptaní test: Pro definici akceptaního testu je nutno: Sestavit podmínky, dokumentaci a akce definující akceptaní test (na zaátku projektu) Dohodnout se s investorem, že definice akceptaního testu je akceptována Pro absolvování akceptaního testu je nutno: Provést všechny akce stanovené v akceptaním testu (na konci projektu) V pípad neúspšného testu je nutno produkt opravit, absolvovat test znovu tak dlouho, až vyhovuje, nebo projekt skoní neúspšn SWI041 - Testování 44

45 Píklad umístní akceptaního testu do projektu SWI041 - Testování 45

46 Co to je akceptaní test? Akceptaní test pedstavuje podklad pro ovení funknosti ešení. Definice akceptaního testu musí proto obsahovat následující náležitosti: podmínky pro akceptaní test dokumentaci pro akceptaní test definici akcí pro akceptaní test SWI041 - Testování 46

47 Podmínky pro akceptaní test Popis prostedí, ve kterém bude akceptaní test probíhat. Není-li v akceptaním testu prostedí explicitn stanoveno, musí být možno akceptaní test vykonat v rámci standardního prostedí. Popis všech vstupních dat, která budou v akceptaním testu využívána. Patí sem popis všech databází, konfiguraních soubor a jiných testovacích dat, která budou v akceptaním testu využívána. SWI041 - Testování 47

48 P.: Podmínky akceptaního testu ECO Definice akceptaního testu pro ECO Produkt ECO bude realizován jako formuláová aplikace pro MS-Windows, pracující s daty uloženými v databázi Oracle. Produkt bude vytvoen pomocí nástroj Designer/2000 a Developer/ Forms. Akceptaní test produktu ECO mže proto probíhat kdekoli, kde je pístup z MS-Windows k serveru Oracle. Pro provedení akceptaního testu je nutno mít právo pihlásit se jako uživatel do MS-Windows. Dále je nutné mít pístup k njaké vhodné databázi Oracle jako uživatel, který mže instalovat data produktu. SWI041 - Testování 48

49 Podmínky akceptaního testu (pokra.) Definice akceptaního testu pro ECO Ped spuštním produktu ECO je nutno vytvoit v databázi objekty aplikace a uložit do nich testovací data. Doporuený postup je vytvoení uživatele ECOuser, pidlit mu právo na vytváení objekt a pod tímto uživatelem spustit skript (creco.sql), který vytvoí potebné objekty pro ECO a naplní je poáteními testovacími daty. Po absolvování akceptaního testu lze data z databáze odstranit zrušením uživatele ECOuser (s kaskádním odstranním jeho objekt). SWI041 - Testování 49

50 Dokumentace akceptaního testu Dokumentace potebná pro vytvoení a instalaci produktu Uživatelská píruka Definice akceptaního testu Protokol o provedení akceptaního testu SWI041 - Testování 50

51 Dokumentace akceptaního testu ECO Definice akceptaního testu pro ECO Návod pro instalaci aplikace ECO (zahrnuje popis instalace datové základny a formulá aplikace) Uživatelská píruka produktu ECO Definice akceptaního testu ECO Protokol o provedení akceptaního testu SWI041 - Testování 51

52 Akce akceptaního testu Popis všech scéná, které budou tvoit akceptaní test. Sada scéná musí zaruit dostatené ovení funknosti ešení. Pro scénáe, pro které je možno stanovit požadovanou reakci systému, je souástí akceptaního testu i popis odpovídajících reakcí. Scénáe akceptaního testu musí zahrnovat i základní chybové situace a jejich ešení. SWI041 - Testování 52

53 Životní cyklus ECO-skladu Lifecycle ECO-sklad: (dodávka pejímka)* (dotaz na stav je bezpený?)* Definice akceptaního testu pro ECO Služby pro role OPERÁTOR a MANAŽER - pro akceptaci ECO je teba stanovit: Jak se vyzkouší zaazení do role OPERÁTOR a MANAŽER Jak se oví, že každá role má k dispozici požadovanou sadu služeb SWI041 - Testování 53

54 Scénáe pro ECO (viz( model jednání) Definice akceptaního testu pro ECO Operátor provádí pejímku Operátor vybavuje dodávku Manažer se dotazuje na stav skladu Manažer zjišuje, zda je sklad v bezpeném stavu SWI041 - Testování 54

55 Pro akceptaci ECO je teba stanovit: Definice akceptaního testu pro ECO Jak se vyzkouší chování pi akci pejímka Jak se vyzkouší chování pi akci dodávka Jak se vyzkouší chování pi akci dotaz na stav skladu Jak se vyzkouší chování pi zjišování, zda je sklad bezpený Jak se oví, že aplikace umí navázat akce SWI041 - Testování 55

56 Scéná pro dodávku Definice akceptaního testu pro ECO operátor system skladník prázdná plošina požadovaná dodávka skutená dodávka píkaz pro skladníka SWI041 - Testování 56

57 Životní cyklus dodávky Definice akceptaního testu pro ECO dodávka = prázdná plošina.požadovaná dodávka. #skutená dodávka. #píkaz pro skladníka Musí se vyzkoušet: zda produkt nepovolí nesprávné poadí akcí pípad, kdy požadovanou dodávku lze splnit pípad, kdy požadovanou dodávku nelze splnit zda jsou reakce systému správné SWI041 - Testování 57

58 Definice akcí pro akceptaní test ECO: Akce 1: Instalace aplikace ECO možné reakce: OK, nepovedlo se Akce 2: Spuštní aplikace ECO, zaazení do rolí možné reakce: OK, nepovedlo se Akce 3: Dotaz na stav skladu Definice akceptaního testu pro ECO možné reakce: OK, povedlo se - ale chybný výsledek, nepovedlo se Akce 4: Pejímka pro správnou dodávku Akce 5: Pejímka pro chybnou dodávku... SWI041 - Testování 58

59 Popis pro Akci 4 Akce: 4 Popis: : Pejímka pro správnou dodávku Pedpokládá ECO-sklad v korektním stavu Postup: Definice akceptaního testu pro ECO spuštní funkce pejímka - musí vyvolat formulá pro zadání informací z dodacího listu zadávají se údaje o barelech - generují se ID barel (viz Vstupní data 4)... Po ukonení musí být ECO-sklad ve správném stavu (oví se funkcí dotaz na stav ) a bezpený (oví se funkcí je bezpený? ) SWI041 - Testování 59

60 Vstupní data pro akci 4: ECO sklad musí být ve stavu S4 získaném importem souboru ECOS4.dmp píkazem Dodací list: imp file=ecos4.dmp Postup vykládky: Definice akceptaního testu pro ECO 5 barel typu A 4 barely typu B 2 barely typu C A, A, B, C, B, C, A, A, A, B, B SWI041 - Testování 60

61 Výstupní reakce na akci 4: Definice akceptaního testu pro ECO Pokud je sklad ve stavu S4 mla by akce 4 vyvolat následující: Nebyly detekovány žádné rozdíly mezi dodacím listem a skutenou dodávkou Nebyly detekovány žádné barely, které nelze do skladu umístit Píkaz pro skladníka obsahuje všechny barely dodávky a nikdy neumisuje barely typu B a C do stejné budovy, celkový poet barel v budov nepesáhne kapacitu budovy. SWI041 - Testování 61

62 The End