
- •Co je předmětem fáze analýzy požadavků na informační systém? Analýza
- •Výstupem analýzy:
- •Co je smyslem modelem řízeného vývoje (mda, resp. Mdd)?
- •Co to je architektura informačního systému? Uveďte typické příklady architektury.
- •Integrace stávajících aplikací
- •Co to je bezpečnost informačních systémů, jak se zajišťuje?
- •Co to je inspekce produktu?
- •Inspekční setkání
- •Co to je programové rozhraní (api), jak se navrhuje?
- •Co to je síťový graf (pert)?
- •Co to je sloupcový diagram (Gantt Chart)?
- •Co to je softwarové inženýrství a proč vzniklo?
- •Co to je softwarový projekt a jaké jsou jeho charakteristické rysy?
- •Co to je uml, k čemu V kontextu softwarového inženýrství slouží?
- •C o to jsou funkční a nefunkční požadavky?
- •Co to jsou softwarové metriky, kdy se používají?
- •Co to jsou stupně dospělosti vývoje (cmm), jak se liší?
- •Jaké dokumenty jsou vstupem a výstupem fáze návrhu informačního systému?
- •Vstupy:
- •Výstupní dokumenty návrhu
- •Jaké metodiky řízení vývoje informačních systémů znáte?
- •Jaké metody modelování informačních systémů znáte?
- •Jaké metody se používají pro řízení kvality vývoje informačních systémů?
- •Jaké metody testování softwarových produktů znáte?
- •Jaké nástroje pro vývoj informačních systémů znáte? Ve kterých fázích se používají?
- •Implementace:
- •Výběr vhodného case nástroje
- •Jaké softwarové profese znáte a co je předmětem jejich zaměření?
- •Jaké techniky plánování znáte, jak se liší?
- •Jaké znáte metody odhadu nákladů na informační systém?
- •Jaký je rozdíl mezi strukturovanými a objektovými metodikami?
- •Vazba (link)
- •Jakými fázemi prochází životní cyklus informačního systému?
- •Na čem je založena technika odhadu dekompozicí?
- •Na čem jsou založeny statistické metody odhadu (cocomo)?
- •Vysvětlete pojem datové modelování, jaké datové modely znáte?
- •Vysvětlete pojem funkční (procesní) modelování, jaké modely znáte?
- •Vysvětlete, co to je akceptační test.
- •1. Podmínky pro akceptační test – za kterých bude splněn
- •2. Dokumentaci pro akceptační test – jak se to má dokumentovat
- •3. Definici akcí pro akceptační test – postup aby naplnil scénář
Jaké metody testování softwarových produktů znáte?
Testování:
proces spouštění programu (IS?) za účelem nalezení chyby
úspěšný test je takový, který objevil dosud neobjevené chyby
může ukázat, že pro určitá data program vyhovuje požadovaným specifikacím. Je to indikací spolehlivosti a kvality softwaru.
testování má zvýšit pravděpodobnost, že v programu nejsou chyby
měly by vztahovat k požadavkům zákazníka
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.)
úplné otestování není možné (nelze otestovat počet všech kombinací cest programem)
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.) Princi Pareto: většina všech neobjevených chyb má původ v několika málo modulech. Problémem je ty moduly nalézt.
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í)
Testovatelnost:
Výčet vlastností vedoucích k dobré testovatelnosti:
operability - spustitelnost (čím lépe 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ě
observability - přehlednost (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
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 strukturovaný, testy mohou být specifikovány, automatizovány a reprodukovány
dekomponovatelnost - (kontrolováním rozsahu testování můžeme rychleji oddělit problémy a provést následné testy)
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
White-box testing (strukturální testování)
vychází ze znalosti programové řídicí struktury. Testy by měly vyzkoušet alespoň jeden průchod všemi příkazy a vyzkoušet všechny logické podmínky.
je to testování v malém, pro malé programy a moduly
testování toho, zda všechny vnitřní komponenty správně fungují (ale nemusí postihnout chybějící alternativy)
všechny samostatné cesty uvnitř modulu budou provedeny alespoň jednou
všechny podmínky se projdou podél větve s hodnotou ANO (true) i podél větve s hodnotou NE (false)
projde všechny cykly
prověří vnitřní datové struktury
Black-box testing (funkcionální testování)
hledá chyby ve funkčním chování, bez ohledu na jejich implementaci. Je zaměřeno na informační doménu, odvozuje testovací data ze vstupních a výstupních podmínek.
testování správného provádění všech navržených funkcí produktu (ale nemusí postihnout všechny podrobnosti implementace)
je založeno na funkčních požadavcích.
vzhledem k white-box testing jde o doplňkovou nikoli alternativní metodu
aplikuje se až po white-box testing.
Hledá:
nesprávné nebo chybějící funkce
chyby rozhraní
chyby datových struktur nebo přístupu k externím databázím
chybné chování (performance)
chyby
inicializace nebo skončení
Speciální metody testování jsou pro různé typy programů a aplikačních oblastí - GUI, klient/server, real time, dokumentace a help.
Ruční testování
tester testuje aplikaci a její funkce - většinou se to týká uživatelského rozhraní na klientské vrstvě (př. přihlášení do aplikace, proklikání menu aplikace, vyplnění formuláře a uloženi apod.) nebo něčeho co nelze dobře otestovat automatizovaně
Automatizované testování
používá se k tomu nějakého nástroje pro ten účel
nejprve se napíše scénář pro testování (může to byt i rozsáhlý program v nějakém programovacím jazyce nebo jen vstupní data)
scénář může pokrývat opakovaně testovaní určité funkce nebo části aplikace nebo informačního systému, může se jednat o simulace i několika tisíc uživatelů paralelně tedy ve stejný okamžik pro stejnou funkčnost ale rozdílná data
součástí bývá přehled statistik a reportu pro porovnávání výsledků apod.
Unit testy (testování jednotek)
to řeší především programátor
jedna se o testování části kódu či metod tříd nebo programovacích standardů jestli vrací správné výsledky
Některé metodiky doporučují dokonce začínat právě testováním a dále průběžně testovat.
Test bezespornosti
řešíme konzistenci modulů, dělá se průběžně, na každé úrovni se používají různé moduly
Test úplnosti
zda je vše popsáno tak aby tomu programátor rozuměl, jestli je to podle BA, požadavků, návrhz implementace