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



Podobné dokumenty
E. Niklíková, J.Tille, P. Stránský Státní ústav pro kontrolu léiv Seminá SLP

Návrh. Kroky návrhun. Základní technologická. Vstupy pro návrhn. návrhu architektury. Píklad

ORACLE MANUFACTURING SCHEDULING ORACLE HLAVNÍ PLÁNOVÁNÍ VÝROBY

Efektivní uení. Žádná zpráva dobrá zpráva. (Structured training) Schopnost pracovat nezávisí od IQ. Marc Gold

ORACLE ÍZENÍ VÝROBY ORACLE WORK IN PROCESS KLÍOVÉ FUNKCE ORACLE WORK IN PROCESS

PÍRUKA A NÁVODY PRO ÚELY: - RUTINNÍ PRÁCE S DATY

Internetový mapový server Karlovarského kraje

E. Niklíková, J.Tille, P. Stránský Státní ústav pro kontrolu léiv Seminá SLP

POPIS TESTOVACÍHO PROSTEDÍ 1 ZÁLOŽKA PARSER

ORACLE DISCRETE MANUFACTURING ORACLE DISKRÉTNÍ VÝROBA

Úvodní studie (pokraov

O em bude prezentace. Co to je SMJ, prvky SMJ Zásady (principy) SMJ Postup pi zavádní SMJ Možnosti zavádní SMJ Pínos SMJ.

Prbžná zpráva o realizaci projektu za rok 2004

Zbytky zákaznického materiálu

Role a integrace HR systém

Ro!ní záv"rka KALKUL1

WWW poštovní klient s úložištm v MySQL databázi

WWW poštovní klient s úložištm v MySQL databázi

PRVODNÍ A SOUHRNNÁ ZPRÁVA

Pedání smny. Popis systémového protokolování. Autor: Ing. Jaroslav Halva V Plzni Strana 1/6

Základní škola Šenov, Radniní námstí 1040,

8.2 Používání a tvorba databází

PRVODNÍ A SOUHRNNÁ ZPRÁVA

délky (mm): 200, 240, 250, 266, 300, 333, 400, 500, 600, 800, 1 000, 1 200, 1 400, 1 600, 1 800, 2 000, a

Informace pro autory píspvk na konferenci ICTM 2007

Finální verze žádosti (LZZ-GP)

Ing. Jaroslav Halva. UDS Fakturace

Správa obsahu ízené dokumentace v aplikaci SPM Vema

Dodatek dokumentace KEO-Moderní kancelá verze 7.40

"DLK 642-Lite Konfigurator" Programové vybavení pro ídicí jednotku DLK642-Lite Instalaní a programovací návod verze Aktualizace 3.11.

DPS E-PROJEKT ORGANIZACE VÝSTAVBY ZPRÁVA O EŠENÍ BEZPENOST I PRÁCE A T ECHNICKÝCH ZAÍZENÍ,

VYHLÁŠKA. 111/1981 Sb. o ištní komín

Identifikaní údaje územního samosprávného celku. mstys Nehvizdy. zastupitelstvo mstysu Nehvizdy, zastoupené starostou, panem Vladimírem Nekolným

Informaní systém katastru nemovitostí eské republiky

X36SIN: Softwarové inženýrstv. enýrství í? Co to je. Píklad definice SI (SEI, CMU) Historie SI. Pro se SI na FEL uí? u.

DUM. Databáze - úvod

(uvedenou dokumentaci pikládá píjemce pomoci k žádosti o proplacení)

DOUOVÁNÍ DTÍ Z DTSKÉHO DOMOVA ŽÍCHOVEC Projekt podpory vzdlávání

Proces "Investice - výstavba nového objektu"

METODY OCEOVÁNÍ PODNIKU DEFINICE PODNIKU. Obchodní zákoník 5:

Replikace. Pro a proti replikaci. Vztah ke škálovatelnosti (1)

EVROPSKÁ ÚMLUVA O DOBROVOLNÉM KODEXU O POSKYTOVÁNÍ PEDSMLUVNÍCH INFORMACÍCH SOUVISEJÍCÍCH S ÚVRY NA BYDLENÍ (dále jen ÚMLUVA )

IMPORT DAT Z TABULEK MICROSOFT EXCEL

Zákon o zdravotních službách a podmínkách jejich poskytování. MUDr. Helena Sajdlová Odbor zdravotních služeb MZ

Projektovéízení a strategický management - východiska programového financování - IPVZ, 2008

Redakní systém (CMS) OlomouckéWeby.cz

Konzistentnost. Pro a proti replikaci. Vztah ke škálovatelnosti (1)

E. Niklíková, J.Tille, P. Stránský Státní ústav pro kontrolu léiv Seminá SLP

Využití internetového mapového serveru v informaním systému Karlovarského kraje

Prezentaní program PowerPoint

VYTVÁENÍ VÝBROVÝCH DOTAZ

Obsah. Centrum laboratorní medicíny BioLab spol. s r.o. Klatovy. Kapitola Název kapitoly

Zajišujeme: Gajdošova 61/3154, Ostrava

Zápis z prbžného oponentního ízení

MATEMATIKA MATEMATIKA

Základní parametry zadávacích podmínek ve ejné zakázky Po ízení aplikace MS2014+ a zajišt ní jejího provozu a rozvoje

Smrnice rektora. 36R/2007 POŽÁRNÍ OCHRANA

Žákovský (roníkový projekt)

E. ZÁSADY ORGANIZACE VÝSTAVBY

Databázové systémy, MS Access. Autor: Ing. Jan Nožička SOŠ a SOU Česká Lípa VY_32_INOVACE_1130_Databázové systémy, MS Access_PWP

STEDNÍ ŠKOLA EKONOMICKO-PODNIKATELSKÁ STUDÉNKA, o. p. s. A. G. L. Svobody 760, Studénka I C T P L Á N Š K O L Y

ZAJIŠTNÍ SLUŽBY CARRIER IP STREAM

Služba Zvýšená servisní podpora

FIRMA, NÁZEV I JINÉ OZNAENÍ. Msto,ulice,íslo popisné,ps:.. Zapsaná v obchodním rejstíku vedeném, oddíl., Bankovní spojení:.. . útu:..

ESKÝ JAZYK ESKÝ JAZYK

krajské školící stedisko projektu

SQL - trigger, Databázové modelování

RIGORÓZNÍ ÁD UNIVERZITY JANA EVANGELISTY PURKYN V ÚSTÍ NAD LABEM ZE DNE 20. LISTOPADU 2006

Tematická sí pro Aplikované Pohybové Aktivity Vzd lávací a sociální integrace osob s postižením prost ednictvím pohybových aktivit Cíle

lánek 1. Cíle a psobnost standardu VKIS 1) Cílem standardu VKIS je zlepšení dostupnosti a kvality VKIS jejich uživatelm.

Všeobecné obchodní podmínky spolenosti SV metal spol. s r.o.

Vaše uživatelský manuál ESET MOBILE ANTIVIRUS

Podílový fond PLUS. komplexní zabezpeení na penzi

Obsah Úvod...2 Slovníek pojm Popis instalace...3 Nároky na hardware a software...3 Instalace a spouštní...3 Vstupní soubory

ŠANCE PRO SPOLENOST, obanské sdružení

2. Posouzení efektivnosti investice do malé vtrné elektrárny

PEDPISY PRO PRAVIDELNÉ PERIODICKÉ KONTROLY (REVIZE) BLOKANT A LANOVÝCH SVR

Bezpenost dtí v okolí škol z pohledu bezpenostního auditora

Bezpenost a hygiena práce

Sítání dopravy na silnici II/432 ul. Hulínská Osvoboditel v Kromíži

Návod k obsluze. Samostatné ovládací za ízení UC 42. Samostatné ovládací za ízení pro montážní lištu UC 45. D ležité informace pro elektrické zapojení

Základní informace: vysoce komfortnímu prostředí je možné se systémem CP Recorder efektivně pracovat prakticky okamžitě po krátké zaškolení.

DOKUMENTACE ISM. P íru ka ISM ISM 01. Geodetická kancelá, která m í cokoliv...

Zpráva o plnní cíl projektu VISK 8/B

Instalace multiimportu

Nabídka systému rozpoznávání SPZ pro parkovací a vjezdové systémy

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

Další vzdlávání pracovník škol a školských zaízení

asté otázky a odpov di k zákonu. 406/2000 Sb.

Ošetovatelský proces. Ošetovatelský proces pispívá u sestry:

SIX SIGMA IN LOGISTICS

RADA EVROPY VÝBOR MINISTR VÝBORU MINITR LENSKÝM STÁTM OHLEDN ZÁSAD PRÁVNÍ OCHRANY NEZPSOBILÝCH DOSPLÝCH OSOB

Zajištní vybraných služeb mobilních komunikací pro DPMO, a.s.

POPIS A NÁVOD K OBSLUZE

HYDROIZOLACE SPODNÍ STAVBY

REDAS. Vývoj informaních systém Tvrci: Petr Kalíš Judita Hlinková,, Richard Vavrda

INVESTINÍ DOTAZNÍK. 1. Identifikace zákazníka. 2. Investiní cíle zákazníka. Investiní dotazník

Snížení nezamstnanosti Podpora rozvoje živností zamené na obanské služby

Á D TAJEMNÍKA MSTSKÉHO ÚADU . R 03/2007 PODPISOVÝ ÁD

Transkript:

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

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) 1. + 2. (totální) korektnost SWI041 - Testování 4

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

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

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

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

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 Neznáme vnitek, známe požadovanou funkci white box Známe strukturu, známe požadovanou funkci SWI041 - Testování 10

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

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

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

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

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

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

Specifikace prosted edí: benchmarkové testy TPC: Nkteré kategorie test TPC: http://www.tpc.org/ 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

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

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*10 10 10 Customer Customer W*30K W*30K 3K 3K History History W*30K+ W*30K+ 1+ 1+ Item Item 100K ( 100K (fixed fixed) Stock Stock W*100K W*100K 100K 100K W Order Order W*30K+ W*30K+ 1+ 1+ Order Order-Line Line W*300K+ W*300K+ 10 10-15 15 New New-Order Order W*5K W*5K 0-1

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 = 9.6 3 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

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

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

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

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

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

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

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

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

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

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

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

Inspekce Pohled na dílo oima inspektora Audit

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

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

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

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

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

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

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

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

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

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

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

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

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

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/2000 - 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

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

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

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

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

Ž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

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

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

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

Ž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

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

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

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 ECOuser/heslo@instance 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

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

The End