Provoz, údržba a testy IS Vývoj informačních systémů

Cíl testování Cílem testování je objevit chyby v softwaru a ne ukázat, že v něm chyby nejsou! Testování softwaru v žádném případě nemůže dokázat, že software je správný, že splňuje zadání. Důvodem je složitost programu, velké množství různých průchodů programem a velké množství argumentů funkcí. Jediné, co můžeme od testování očekávat, je nalezení exitujících chyb.

Zkušenost Jestliže test najde jen velmi málo chyb, neznamená to, že software je správný. Pravděpodobně je chybné testování. Na rozdíl od programování, testování je veřejností chápáno jako destruktivní činnost, „má zničit software, objevit jeho chyby“.

Testování Testování je jedna z důležitých technik zabezpečení kvality výsledného produktu. Provádí se v různých etapách životního cyklu systému a v několika úrovních. V závislosti na velikosti části, která je testována, se etapy označují jako úroveň modulu, úroveň jednotky nebo úroveň systému.

Metodika testování… …je úplně odlišná pro procedurální jazyky (C, C++, Pascal, apod), testuje se v pořadí modul  jednotka  podsystém  systém …a jiná pro objektově orientované jazyky (C++, Java, NET apod.), testuje se v pořadí třída  interakce mezi třídami  subsystém  systém

Charakteristika testování Testování je proces spouštění programu za účelem nalezení chyb. Dobrá testovací data jsou taková, která s velkou pravděpodobností objeví dosud neobjevené chyby. Úspěšný test je takový, který objevil dosud neobjevené chyby.

Cíl testování navrhnout test, který systematicky odkryje různé třídy chyb s minimálním úsilím a časem může ukázat, že pro určitá data program vyhovuje požadovaným specifikacím Test je indikací spolehlivosti a kvality softwaru Testování ale nemůže dokázat absenci chyb, může jen dokázat jejich přítomnost.

Principy testování Testy by se měly vztahovat k požadavkům zákazníka (většina defektů z pohledu zákazníka se projeví neshodou s požadavky). Testy by měly být plánovány v předstihu (plánovat je jakmile jsou specifikovány požadavky, navrhnout data, jakmile je proveden návrh programu.) Princip Pareto (pravidlo 80:20): většina všech neobjevených chyb má původ v několika málo modulech. Problémem je ty moduly nalézt.

(pokrač.) Testování by mělo začít testováním "v malém" a pokračovat testování "ve velkém". (Začít testováním modulů, pak integrovaných skupin (clusterů) modulů a nakonec celého systému) Úplné otestování není možné (nelze otestovat počet všech kombinací cest programem) Testování by mělo být vedeno nezávislou třetí stranou (jiný úhel pohledu, snaha nalézt chybu, ne dokázat, že tam není)

Je IS testovatelný? Vlastnosti vedoucí k dobré testovatelnosti: Spustitelnost (operability) - čím lépe modul pracuje, tím účinněji může být otestován - chyby nebrání běhu programu, může být testován a vyvíjen současně. Přehlednost (observability) - testuješ, co vidíš - různé výstupy pro různé vstupy, stavy systému a proměnné jsou viditelné během chodu, faktory ovlivňující výstup jsou viditelné, nesprávné výstupy jsou lehce identifikovatelné, vnitřní chyby jsou automaticky detekovány a zaznamenávány, je dostupný zdrojový kód

(pokrač.) Kontrolovatelnost (controllability) - čím lépe lze software kontrolovat/řídit, tím spíše lze testování automatizovat a optimalizovat - všechny možné výstupy jsou generovány nějakou kombinací vstupů, veškerý kód je spustitelný nějakou kombinací vstupů, vstupní a výstupní formát je konsistentní a Dekomponovatelnost - kontrolováním rozsahu testování můžeme rychleji oddělit problémy a provést následné testy.

(pokrač. 2) Jednoduchost - čím méně máme testovat, tím rychleji to můžeme provést - jednoduchost funkce, struktury, kódu Stabilita - čím měně změn softwaru, tím lépe - nejsou časté, jsou řízené, neovlivní provedené testy. Srozumitelnost - čím víc máme informací, tím budou testy chytřejší - srozumitelný návrh, srozumitelné závislosti mezi vnitřními, vnějšími a sdílenými komponentami, dostupnost a srozumitelnost technické dokumentace

Vlastnosti dobrého testu s velkou pravděpodobností objeví chybu. Měl by hledat chybu tam, kde může být, není redundantní Na testování je málo času, proto má mít každý test mít jiný účel, měl by objevit celou třídu chyb, neměl by být ani moc jednoduchý ani moc složitý.

Pozor Každý test se musí spouštět nezávisle, aby jejich případné vedlejší efekty nepřekryly chyby! Pozor, dále popsané testovací metody se hodí na programy. Na celý IS je lze použít jen omezeně.

Black-box testování Testování, které označujeme jako testování černé skříňky, je testování správného provádění funkcí systému Tento typ testování nepotřebuje znát vnitřní strukturu IS. Potřebuje jen znát hodně vstupních kombinací a k nim odpovídající výsledky Nevýhoda: nemusí postihnout všechny podrobnosti implementace

White-box testování White-box testing (strukturální testování) - testuje, zda všechny vnitřní komponenty správně fungují. White-box testování se liší od black-box tím, že používá informace o vnitřní struktuře testovaného modulu a znalosti zdrojového kódu. Tento typ testování nemusí postihnout chybějící alternativy.

Testování podle základních cest Ve skriptu je příklad na white-box testing, ve kterém je ukázán redukovaný graf programu:

(pokrač.) Testování lze provést projitím všech nezávislých cest. Nezávislá cesta je taková, která prochází od začátku do konce programem a prochází alespoň jedním příkazem nebo podmínkou, kterým neprochází jiná taková cesta. Cyklomatická složitost je metrika složitosti programu, která udává počet nezávislých cest v programu.

Testování podle řídicí struktury Testování podmínek - testování všech větví (branch testing) Testování domén (domain testing) - otestování všech kombinací vztahů proměnných testu (např. pro A relace B, budou tři testy, kdy A>B, A B, A<B, A=B)

Testování cyklů Jednoduchý cyklus: přeskoč cyklus, pak ho projdi 1x, 2x, …, N-krát Vložené cykly: začni nejvnitřnějším cyklem, ostatní cykly nastav na minimum průchodů. Postupuj směrem k vnějšímu cyklu, vnější cykly nastav na minimum průchodů, vnitřní na "typickou hodnotu"

Metody založené na grafu Ověřit, že všechny objekty jsou v požadovaných vzájemných vztazích. Znázornit graficky a navrhnout test, který pokrývá graf. Znázornit graficky a navrhnout test, který pokrývá graf. Objekty grafu mohou být jak datové objekty tak i programové objekty (moduly, nebo množina programových příkazů).

Rozdělení do tříd ekvivalencí Rozdělení vstupní domény programu do tříd a odvození testovacích dat. Pokud vstupní podmínka specifikuje rozsah, jedna třída bude pro platná data a dvě pro neplatná. Pokud vstupní podmínka požaduje specifickou hodnotu, bude jedna platná a jedna neplatná. Pokud vstupní podmínka specifikuje množinu dat, bude jedna platná a jedna neplatná. Pokud vstupní podmínka je booleovská, bude jedna platná a jedna neplatná

Analýza okrajových hodnot Z málo známých důvodů se velký počet chyb vyskytuje kolem okrajových podmínek vstupních dat spíše než uprostřed. Doplňuje předešlou metodu. Vybírají se data blízká hranicím tříd ekvivalence. Uvažují se jak vstupní podmínky tak i výstupní podmínky. Příklad: pokud vstupní podmínka specifikuje rozsah od A do B, testovací data mají být A, B, bezprostředně nad a pod A i B.

Srovnávací testování Pro požadavky zvýšené spolehlivosti (navigace letadel, řízení nukleární elektrárny a pod.) mohou být některé časti (HW i SW) redundantní, zpracovávané nezávislými týmy ze stejných specifikací. Každá aplikace je testována se stejnými daty a výsledky by měly být stejné. Pak jsou všechny verze prováděny paralelně s porovnáním reálného času výsledků a zajištění konsistence. Někdy se pouze kritické části programují paralelně, ale předává se jen jedna verze. Testy se provádějí podle některé z výše uvedených metod.

Změny Změny při vývoji IS jsou přirozené a je nutné s nimi počítat. Změny za provozu jsou přirozeným důsledkem vývoje ve společnosti. Změny je potřeba analyzovat dříve, než nastanou a evidovat je před tím, než se implementují. Je nutné uvědomit o chybách ty, kterých se týkají.

SCM Řízení konfigurací označujeme SCM (Software Configuration management) a má za cíl: –identifikovat změny –řídit změny –zajistit, aby změny byly řádně implementovány –informovat o změnách ty, kterých se to týká SCM je aktivita, která začíná na začátku softwarového projektu a končí až, když je software vyřazený z provozu

Příčiny změn nové obchodní nebo tržní podmínky, které vyvolávají změny v požadavcích na produkt nebo v obchodních pravidlech nové potřeby zákazníka, vyžadující modifikace produkovaných dat z IS, funkčnosti produktu, nebo služeb poskytovaných počítačovým systémem. reorganizace nebo obchodní změny, které mohou způsobovat změny v prioritách projektu nebo v realizačním týmu omezení rozpočtu nebo harmonogramu, které způsobují změnu definice systému nebo produktu

Srovnávací základna Srovnávací základna (Baseline) je specifikace nebo produkt, který byl formálně revidován a odsouhlasen tak, že pak slouží jako základ pro další vývoj a může být změněn jenom formálně řízenou změnovou procedurou. Než se produkt stane srovnávací základnou, jsou změny snadné (týkají se jen jednoho nebo úzkého okruhu tvůrců).

(pokrač.) Jakmile se stane srovnávací základnou - prakticky po nějakém milníku, kdy byla provedena revize, jsou změny komplikovanější, protože se týkají více lidí, musí se provést podle určitých pravidel. Srovnávací základna je uložena do projektové databáze (softwarový repositář nebo projektová knihovna). Často jsou jako srovnávací základny uvažovány i verze kompilátoru, CASE nástroje a editory, protože jiné verze mohou způsobovat změny produktu

Proces SCM Proces řízení softwarových komunikací musí odpovědět na otázky: Jak organizace identifikuje a řídí velké množství existujících verzí programů (včetně dokumentace) tak, aby bylo možné účinně provádět změny. Jak řídí organizace změny před a po dodání softwaru zákazníkovi? Kdo zodpovídá za schvalování a určování priorit změn? Jak je zabezpečeno, aby změny proběhly správně? Jak jsou ošetřeny vedlejší změny, které mohou nastat?

(pokrač.) Aby proces SCM mohl na uvedené otázky odpovědět, musí provést některé základní úkoly, kterými jsou: Identifikace produktu řízení verzí řízení změn audit konfigurací evidence a zprávy

Identifikace Každý objekt je identifikován: jménem (jednoznačný řetězec znaků) popisem (typ: dokument, program, data; identifikace projektu, změny, verze) seznamem zdrojů (entity "poskytované, zpracovávané, odkazované nebo jinak požadované objektem" - např. datové typy, funkce, proměnné) part of (např.objekt je částí agregovaného objektu, ERD je částí datového modelu, datový model je částí analytické specifikace) interrelated (např. datový model je v relaci s DFD, s testovacími daty apod.)

Řízení verzí Forma reprezentace verzí je evoluční graf, který zobrazuje hierarchii změn. Každý jeho uzel je agregovaný objekt: kompletní verze softwaru (zdrojový kód, dokumentace a data) Každá verze může být složena z různých variant. Varianty se mohou lišit např. výběrem různých komponent (např. pro monochromní nebo barevný displej) Každá varianta je složena s odlišného souboru objektů jedné úrovně revize a tudíž koexistuje paralelně s jinými variantami.

Změnové řízení (1) zjištěná potřeba změny požadavek na změnu od uživatele vyhodnocení vývojářem generovaní změnové zprávy odpovědná osoba nebo skupina - CCA (change control authority) rozhodne o změně (v případě neakceptace je informován uživatel a proces změny končí)

Změnové řízení (2) požadavek je zařazen do pořadí k vyřízení, stanoví se kritéria pro revizi či audit - ECO (engineering change order) určí se pracovníci příslušný konfigurační objekt se vybere z databáze provedou se změny provede se revize (audit) konfigurační objekt se zařadí do databáze

Změnové řízení (3) stanoví se srovnávací základna pro testování provedou se aktivity QA a testování změny se zahrnou do dalšího vydání (release) přepracuje se příslušná verze softwaru Provede se revize (audit) změn ve všech SW zahrnout změny do nové verze distribuovat novou verzi

Audit konfigurací Formální revize. Je zaměřena na technickou správnost modifikovaného konfiguračního objektu, prověří konzistentnost k jiným SW, úplnost, případné vedlejší efekty. SC audit kontroluje, zda byly změny specifikované v ECO provedeny, zda nebyly provedeny ještě další změny, zda byly změny správně označeny v SCI, zda bylo zaznamenáno datum a autor změny. Zda byla změna evidována a oznámena. Zda byly opraveny všechny související SW.

Evidence stavu (status reporting ) co se stalo kdo to udělal kdy se to stalo co dalšího to ovlivnil

Děkuji za pozornost.