SWI041: Testování programových systém Jak se to ov í
Nejprve trochu kontroly Stav projekt
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)) “Vytvo ili jsme správný produkt? (vzhledem k požadavk m daným akcepta ním testem)” verifikace ∀ t∈ ∈Seq. sorted(sort(t)) ∧ is-Permutation(t,sort(t)) “Vytvo ili jsme produkt správn ? (vzhledem ke specifikaci)” SWI041 - Testování
3
Matematická verifikace 1. proces pro libovolná vstupní data vždy skon í (konvergence) 2. za p edpokladu, že proces pro daná vstupní data skon í, vrací pro tato vstupní data správné výsledky (parciální korektnost) 1. + 2. (totální) korektnost SWI041 - Testování
4
Pro má testování takový význam? 40% asu vývoje rozsáhlých aplikací p edstavuje jejich ov ování až 50% náklad na vývoj p ipadá na testování 75% všech aplikací má problémy s kvalitou pouze 1% aplikací je dokon eno v as, v rámci stanoveného rozpo tu a v požadované kvalit velmi zna né riziko, že m j programový systém „spadne do uvedených kategorií“ nutnost riziko ídit a snížit SWI041 - Testování
5
Co by m lo být cílem testování ov ení 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í ov ení p enositelnosti instalace ov ení chování p i havárii a následném zotavení zákaznické
zajišt ní kvality programového systému zajišt ní d v ry v kvalitu SWI041 - Testování
6
Primární testovací hlediska Funkcionalita: D lá aplikace vše, co je požadováno? Spolehlivost: "Padá" aplikace periodicky? (nedostatek pam ti, netestovaný kód, hrani ní podmínky) Test aplikace: Reaguje aplikace p ijateln ? (výkonnostní problémy na stran klienta, výkon serveru) Test systému: Je systém výkonný i p i plném zatížení? (výkonnostní a zát žové testování simulující reálné použití systému)
SWI041 - Testování
7
Jaké typy test p ipadají v úvahu? testy základních modul testy uživatelského rozhraní integra ní testy finální testy (funk nost, zát ž, dokumentace) akcepta ní testy profylaxe = pravidelná ov ování ve fázi údržby ov ení zm n (p vodní kvalita + nové vlastnosti) ov ení rozši itelnosti SWI041 - Testování
8
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
Techniky testování “black box”
“white box”
SWI041 - Testování
Neznáme vnit ek, známe požadovanou funkci
Známe strukturu, známe požadovanou funkci
10
Testování Testování podle struktury dat rozklad domény hodnot na oblasti analýza hrani ních hodnot (a okolí) analýza p í in a d sledk srovnávací testy (více r zných implementací)
Testování podle struktury programu Testování asových závislostí (zejména u systém ur ených pro ízení a u paralelních systém ) SWI041 - Testování
11
Testování podle struktury dat Vstup EOF p íliš-dlouhé-slovo ...
SWI041 - Testování
Výstup EOF hlášení chyby
12
P íklad: sou et 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
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
Testovací data podle struktury programu pro funkci „sumpls“ cyklomatické íslo µ(sumpls) = 3 1. soubor s jednou v tou s jiným klí em (≠ k) 2. soubor s jednou v tou se stejným klí em a zápornou ástkou 3. soubor s jednou v tou se stejným klí em a kladnou ástkou
SWI041 - Testování
15
Testovací plán testy uživatelského rozhranní (menu, formulá , sestav) testy ru n ešených postup a jejich návaznosti na systém testy jednotlivých modul a zp sob jejich akceptace integra ní testy a zp sob jejich akceptace testy výkonnosti systému a zp sob jejich akceptace testy bezpe nosti systému a zp sob jejich akceptace testy obnovení innosti systému po výpadku a zp sob jejich akceptace SWI041 - Testování
16
Požadavky na proces testování testy jsou založeny na specifikaci a uživatelské dokumentaci musí být ov eny minimáln všechny požadavky dané specifikací, pop . závaznými standardy pro v cnou oblast testy musí být opakovatelné, p esn definované a dokumentované musí být stanoveno a dodrženo testovací prost edí a testovací podmínky, které musí spl ovat podmínku neovlivn nosti pr b hu testu inností jiného programového systému, nebo speciálním hardware SWI041 - Testování
17
Specifikace prost edí: benchmarkové testy TPC: N které kategorie test TPC: http://www.tpc.org/ TPC-A m í výkonnost v aktualiza n náro ném DB prost edí typicky OLTP aplikací
TPC-B hodnocení výkonnosti jádra DB systému s opera ním systémem, na kterém DB server b ží
TPC-C modelování komplexn jšího systému
TPC-D výkonnost DB systém p i dotazech pro podporu rozhodování SWI041 - Testování
18
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
P .: TPC-C (pokra .) transakce pracují proti databázi obsahující dev t tabulek transakce provád jí 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
Warehouse W
Stock
100K
W*100K
W*10
one-to-many relationship
secondary index
3K
Customer
Order
1+
W*30K+
1+
10-15
History
Order-Line
SWI041 - Testování
100K (fixed)
Table Name
District
W*30K+
W Legend
10
W*30K
Item
New-Order 0-1
W*5K
W*300K+
21
1 Select txn from menu: 1. New-Order 2. Payment 3. Order-Status 4. Delivery 5. Stock-Level
45% 43% 4% 4% 4%
2
Cycle Time Decomposition (typical values, in seconds, for weighted average txn)
Measure menu Response Time Input screen
3
Output screen
Keying time
Keying = 9.6
Measure txn Response Time Think time
Menu = 0.3
Txn RT = 2.1 Think = 11.4
Average cycle time = 23.4 Go back to 1 SWI041 - Testování
22
Typická konfigurace pro TPC-C Emulovaná innost uživatele
Prezenta ní služby
klient/ aplika ní server
Hardware
Term. LAN
Software
zde se m í doba odezvy
Nap .: Empower preVue LoadRunner
SWI041 - Testování
TPC-C aplikace + transak ní monitor event. knihovny pro RPC na DB nap ., Tuxedo, ODBC
Databázová funkcionalita C/S LAN
DB server ... TPC-C aplikace (uložené procedury) + databázový server + transak ní monitor nap ., SQL Server, Tuxedo
23
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ád ní a vyhodnocování test zm ny SWI041 - Testování
24
1. fáze: 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 ov ení systému v každé fázi životního cyklu ur ení shody finálního produktu s p ihlédnutím k pot ebám a požadavk m uživatele ov ení chování systému pomocí jeho testovacího provozu p i využití testovacích dat SWI041 - Testování
25
1.fáze: Strategie testování II m la by být p ipravena verze pro každý projekt specifikuje systém testování (metody - typy test a postupy jejich použití) zp sob vyhodnocování standardy testovací týmy - role, mapování na organiza ní strukturu, pravomoci, odpov dnosti
SWI041 - Testování
26
2.fáze: Plá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ýb r a zp sob použití metod testování práce se zjišt ný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
3.fáze: Návrh test definování ástí aplikace, které budou samostatn testovány ur ení testu a definování jeho cíle cílem testování je zejména odhalení chyb -> 70% negativních test testy s komplexn jším záb rem mají v tší šanci na odhalení chyb testy by m ly být efektivní (ú inné, ne redundantní)
ur ení postupu testu jednotlivé kroky s ur ením o ekávaných výsledk vstupní data (v etn hrani ních a nekorektních)
vychází se z dokumentace programového systému znalostí tv rc systému
SWI041 - Testování
28
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 (prost edí, konfigurace) a zp sobu jejich ustavení opakovatelnost vylou ení vlivu jiného systému dokumentovatelnost
SWI041 - Testování
29
5.fáze: Návrh testovacích cykl testovací cyklus = skupina test provád ná za ur itým ú elem cyklus se ur uje dle specifických cíl a ú elu testování v dané fázi vývoje systému (testy modul , integra ní testy, …) v závislosti na procesu ov ování kvality (základní úrove , b žná úrove , nadstavbové testy, speciální testy) v závislosti na p edm tu testování (testy modul , funkcí, subsystém ) SWI041 - Testování
30
6.fáze: Provád ní a vyhodnocování provedení jednotlivých krok test a dokumentování jejich výsledk dokumentace eventuáln zjišt ných nesoulad chyby programového systému chyby testu kategorizace chyby (dle škály) návrh ešení
SWI041 - Testování
31
7.fáze: Zm ny cíl: odstran ní zjišt ných neshod postup zjišt ní p í iny neshody ur ení zp sobu odstran ní ur ení zodpov dného pracovníka dokumentace provád ných zm n ohlášení odstran ní neshody opakované testování SWI041 - Testování
32
Jak celý proces zvládnout? nutnost profesionálního p ístupu (plánování, p i azení asových, lidských i materiálních zdroj ) d sledná realizace popsaného procesu využití technologických nástroj
SWI041 - Testování
33
Inspekce Pohled na dílo o ima inspektora Audit
Aktivity p i inspekci
SWI041 - Testování
35
Inspek ní tým - 3 až 7 lidí Role: autor - osoba, která je autorem produktu a je zodpov dná za zm ny ešící nalezené problémy moderátor - osoba, která zajištuje pr b h inspekce podle p ipraveného plánu tená - osoba, která p eklá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 p edkládaném produktu snaží nalézt chyby SWI041 - Testování
36
Poznámky k inspekci: Minimální inspek ní tým má t i osoby - autor, tená a moderátor/zapisovatel (všichni jsou sou asn inspektory). Autor musí být vždy p ítomen a nesmí zastávat žádnou jinou roli (s výjimkou inspektora). Inspek ní tým by m l být p im ený - nejvíce asi 7 osob, pokud je to vhodné. Inspekce není ur ena pro manažery. SWI041 - Testování
37
Metody pro výb r moderátora Moderátor je p id len autor m již p i vytvá ení plánu projektu. Moderátor je vybrán koordinátorem inspekcí. Autor si vybírá moderátora ze seznamu pov ených moderátor . Autor si vybírá moderátora sám.
SWI041 - Testování
38
Plánování inspekce Ú el: organizace inspek ního procesu Úlohy: Vymezení nebo potvrzení vstupních kritérií (pro p ijetí produktu k inspekci) Ustavení plánu (inspekce by rozhodn nem la trvat déle než 2-3 hodiny) Výb r participant Rozhodnutí o p ehledech (p ehledy slouží pro seznámení s produktem) P íprava podklad pro inspek ní setkání (typ inspekce, p edm t inspekce, doba a místo konání p ehled , doba a místo konání inspekce, odhad asu, požadovaná p íprava) Distribuce materiál participant m
Role: moderátor, autor SWI041 - Testování
39
P ehledy a p íprava na inspekci P ehledy (overview) Ú el: seznámení s produktem nebo p edm tem (volitelné) Úlohy: Prezentace Role: moderátor, autor, inspekto i, ostatní
P íprava Ú el: porozum ní materiál m, potenciální identifikace chyb Úlohy: Studium matriál Role: všichni inspekto i SWI041 - Testování
40
Inspek ní setkání Ú el: ov ení produktu Úlohy: Otev ení inspek ního setkání (seznámení s obsahem, postupem a kritérii) Ov ení p ipravenosti 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áv ry 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, inspekto i SWI041 - Testování
41
Uzáv rka inspekce P epracování Ú el: spln ní výstupních kritérií Úlohy: vy ešení všech chyb Role: autor
Uzáv rka Úcel: Potvrzení inspekce Úlohy: Ov ení úprav produktu Zpráva o výsledku inspekce Role: moderátor, autor, (inspekto i)
SWI041 - Testování
42
Akcepta ní test Co to je akcepta ní test Jak se definuje Jak se provede
Akcepta ní test: Pro definici akcepta ního testu je nutno: Sestavit podmínky, dokumentaci a akce definující akcepta ní test (na za átku projektu) Dohodnout se s investorem, že definice akcepta ního testu je akceptována
Pro absolvování akcepta ního testu je nutno: Provést všechny akce stanovené v akcepta ní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
P íklad umíst ní akcepta ního testu do projektu
SWI041 - Testování
45
Co to je akcepta ní test? Akcepta ní test p edstavuje podklad pro ov ení funk nosti ešení. Definice akcepta ního testu musí proto obsahovat následující náležitosti: podmínky pro akcepta ní test dokumentaci pro akcepta ní test definici akcí pro akcepta ní test
SWI041 - Testování
46
Podmínky pro akcepta ní test Popis prost edí, ve kterém bude akcepta ní test probíhat. Není-li v akcepta ním testu prost edí explicitn stanoveno, musí být možno akcepta ní test vykonat v rámci standardního prost edí. Popis všech vstupních dat, která budou v akcepta ním testu využívána. Pat í sem popis všech databází, konfigura ních soubor a jiných testovacích dat, která budou v akcepta ním testu využívána. SWI041 - Testování
47
P .: Podmínky akcepta ního testu ECO Definice akcepta ní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 vytvo en pomocí nástroj Designer/2000 a Developer/2000 - Forms. Akcepta ní test produktu ECO m že proto probíhat kdekoli, kde je p ístup z MS-Windows k serveru Oracle. Pro provedení akcepta ního testu je nutno mít právo p ihlásit se jako uživatel do MS-Windows. Dále je nutné mít p ístup k n jaké vhodné databázi Oracle jako uživatel, který m že instalovat data produktu. SWI041 - Testování
48
Podmínky akcepta ního testu (pokra .) Definice akcepta ního testu pro ECO P ed spušt ním produktu ECO je nutno vytvo it v databázi objekty aplikace a uložit do nich testovací data. Doporu ený postup je vytvo ení uživatele ECOuser, p id lit mu právo na vytvá ení objekt a pod tímto uživatelem spustit skript (crECO.sql), který vytvo í pot ebné objekty pro ECO a naplní je po áte ními testovacími daty. Po absolvování akcepta ního testu lze data z databáze odstranit zrušením uživatele ECOuser (s kaskádním odstran ním jeho objekt ).
SWI041 - Testování
49
Dokumentace akcepta ního testu Dokumentace pot ebná pro vytvo ení a instalaci produktu Uživatelská p íru ka Definice akcepta ního testu Protokol o provedení akcepta ního testu
SWI041 - Testování
50
Dokumentace akcepta ního testu ECO
Definice akcepta ního testu pro ECO
Návod pro instalaci aplikace ECO (zahrnuje popis instalace datové základny a formulá aplikace) Uživatelská p íru ka produktu ECO Definice akcepta ního testu ECO Protokol o provedení akcepta ního testu
SWI041 - Testování
51
Akce akcepta ního testu Popis všech scéná , které budou tvo it akcepta ní test. Sada scéná musí zaru it dostate né ov ení funk nosti ešení. Pro scéná e, pro které je možno stanovit požadovanou reakci systému, je sou ástí akcepta ního testu i popis odpovídajících reakcí. Scéná e akcepta ního testu musí zahrnovat i základní chybové situace a jejich ešení. SWI041 - Testování
52
Životní cyklus “ECO-skladu” Definice akcepta ního testu pro ECO Lifecycle ECO-sklad: (dodávka | p ejímka)* || (dotaz na stav | je bezpe ný?)* Služby pro role OPERÁTOR a MANAŽER - pro akceptaci ECO je t eba stanovit: Jak se vyzkouší za azení 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
Scéná e pro ECO (viz model jednání) Definice akcepta ního testu pro ECO Operátor provádí p ejímku Operátor vybavuje dodávku Manažer se dotazuje na stav skladu Manažer zjiš uje, zda je sklad v bezpe ném stavu
SWI041 - Testování
54
Pro akceptaci ECO je t eba stanovit: Definice akcepta ního testu pro ECO Jak se vyzkouší chování p i akci p ejímka Jak se vyzkouší chování p i akci dodávka Jak se vyzkouší chování p i akci dotaz na stav skladu Jak se vyzkouší chování p i zjiš ování, zda je sklad bezpe ný Jak se ov í, že aplikace umí navázat akce
SWI041 - Testování
55
Scéná pro “dodávku” Definice akcepta ního testu pro ECO operátor
system
skladník
prázdná plošina požadovaná dodávka
p íkaz pro skladníka
skute ná dodávka
SWI041 - Testování
56
Životní cyklus “dodávky” Definice akcepta ního testu pro ECO dodávka = prázdná plošina.požadovaná dodávka. #skute ná dodávka. #p íkaz pro skladníka Musí se vyzkoušet: zda produkt nepovolí nesprávné po adí 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
Definice akcí pro akcepta ní test ECO:
Definice akcepta ního testu pro ECO
Akce 1: Instalace aplikace ECO možné reakce: OK, nepovedlo se
Akce 2: Spušt ní aplikace ECO, za azení do rolí možné reakce: OK, nepovedlo se
Akce 3: Dotaz na stav skladu možné reakce: OK, povedlo se - ale chybný výsledek, nepovedlo se
Akce 4: P ejímka pro správnou dodávku Akce 5: P ejímka pro chybnou dodávku ... SWI041 - Testování
58
Popis pro “Akci 4” Definice akcepta ního testu pro ECO Akce: 4 Popis: : P ejímka pro správnou dodávku P edpokládá ECO-sklad v korektním stavu Postup: spušt ní funkce p ejí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 ukon ení musí být ECO-sklad ve správném stavu (ov í se funkcí “dotaz na stav”) a bezpe ný (ov í se funkcí “je bezpe ný?”) SWI041 - Testování
59
Vstupní data pro akci 4: Definice akcepta ního testu pro ECO ECO sklad musí být ve stavu S4 získaném importem souboru ECOS4.dmp p íkazem imp ECOuser/heslo@instance file=ECOS4.dmp Dodací list: 5 barel typu A 4 barely typu B 2 barely typu C Postup vykládky: A, A, B, C, B, C, A, A, A, B, B
SWI041 - Testování
60
Výstupní reakce na akci 4: Definice akcepta ního testu pro ECO Pokud je sklad ve stavu S4 m la by akce 4 vyvolat následující: Nebyly detekovány žádné rozdíly mezi dodacím listem a skute nou 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 neumis uje barely typu B a C do stejné budovy, celkový po et barel v budov nep esáhne kapacitu budovy. SWI041 - Testování
61
The End
