Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

Informační systémy a technologie - přijímací zkoušky VŠE - zpracování 2022 > X. Vývoj a testování softwaru. Vzory při vývoji softwaru. Testování softwaru... > Flashcards

X. Vývoj a testování softwaru. Vzory při vývoji softwaru. Testování softwaru... Flashcards

1
Q

Vzory při vývoji softwaru

A

Softwarové vzory

Každý vzor vyjadřuje vztah mezi problémem a řešením. Jako součást světa má každý vzor vazbu na určitý kontext, určitý systém sil, který se opakovaně objevuje v daném kontextu a na určité prostorové uspořádání, jež umožňuje těmto sílám rozhodovat se.

Typy SW vzorů:

  • architektonické – rozložení složitější aplikace do logických celků, které spolu komunikuji. ;
  • analytické – týká se samotné fáze analytického modelování, tedy návrhu logické vrstvy aplikace; všechna nabízená řešení se týkají podstaty logiky aplikace;
  • návrhové – pojmenované a popsané řešení typického problému;
  • vzory kódu
  • vzory pro UI
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Návrhové vzory

A

Návrhové vzory

Návrhové vzory jsou doporučené postupy řešení často vyskytujících se úloh.

Lze je přirovnat k matematickým vzorečkům, nedosazujeme však čísla, ale třídy, rozhrání a objekty.

Snižují pravděpodobnost chyb.

Vštěpují zásady správného programování

Zestručňují komunikaci.

Velké SW firmy jejich znalost vyžadují.

Existují katalogy návrhových vzorů – nejznámější je GoF (Gang of Five – skupina 5 významných programátorů, popisuje 23 základních, obecně použitelných návrhových vzorů).

V zápisu návrhových vzorů se používá zakreslení vztahů a postupů pomocí UML diagramů a současně také slovní popis, který dané diagramy doprovází.

Definují ověřená řešení určitých problémů návrhu.

Důvod vzniku – potřeba elegantního, jednoduchého a znovupoužitelného řešení.

Je třeba najít vhodné objekty, definovat rozhraní tříd, definovat hierarchii dědičnosti, definovat vztahy mezi třídami.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Cíl návrhových vzorů:

A

Cíl:

  • sepsat katalog obecných interakcí, které byly vícekrát použity;
  • chceme získat nezávislost tříd – volné vazby;
  • u dědičnosti má potomek přístup k metodám a nesoukromým proměnným předka, když je na vrcholu hierarchie třída s definovanou implementací, tak potomci jí mají také.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Formát vzoru (jednoduchý)

A

Formát vzoru (jednoduchý):

  • název problému;
  • problém (kdy se má vzor používat);
  • řešení (prvky řešení);
  • důsledky (důsledky použití vzoru);
  • související vzory.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Návrhové vzory podle Pecinovského (které nejsou součástí GoF):

A

Návrhové vzory podle Pecinovského (které nejsou součástí GoF):

  • Jednoduchá tovární metoda – metoda, která umí vracet instanci deklarovaného typu (buď jí vytvoří, nebo najde nějakou již existující). Normální konstruktor umí instanci jen vytvořit, a navíc umí vytvářet jen instance své třídy + má další omezení.
  • Přepravka (messenger) – pokud potřebuji, aby metoda vracela více hodnot najednou, tak je můžu dát do přepravky – to je třída, jejíž instance přenáší požadované hodnoty ve svých atributech. Tyto atributy bývají veřejné, aby bylo možné přistupovat k hodnotám přímo. Samozřejmě ale mohou být privátní, a tedy přístupné jen přes příslušné metody. Přepravka tedy může mít i metody. Každá přepravka má předem připravené atributy, které se jen naplňují – pro každý typ přenášených hodnot tedy musí existovat zvláštní přepravka (např. přepravka na rozměry má atributy x a y).
  • Knihovní třída (utility) – třída, která slouží jako úložiště (knihovna) často používaných metod – je to lepší než mít v každé třídě tu samou implementaci těchto metod. Metody v této třídě bývají statické. Obvykle nemá smysl vytvářet instanci této třídy, proto její konstruktor bývá privátní, bezparametrický a s prázdným tělem.
  • A další – kontejner, výčtový typ, neměnné objekty, služebník, prázdný objekt…
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Členění podle GoF:

A

Členění podle GoF:

  • Structural Patterns (strukturální vzory)– zaměřující se na možnosti uspořádání jednotlivých tříd nebo komponent v systému.
  • Creational patterns (vzory pro vytváření objektů) – řeší problémy související s vytvářením objektů v systému.
  • Behavioral patterns (vzory chování) – zajímají se o chování systému.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Strukturální vzory

A

Strukturální vzory:

  • Adapter
  • Bridge
  • Composite
  • Decorator
  • Fascade
  • Flyweight
  • Proxy
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Adapter

A
  • Adapter
    • potřebujeme existující rozhraní objektu přetransformovat na rozhraní, které v danou chvíli potřebujeme;
    • může se implementovat třemi různými způsoby. Vždy ale jde o to, že adaptér tvoří prostředníka mezi klientem volajícím určitou metodu a třídami, které tuto metodu implementují, a přesměrovává volání od klienta na některou z těchto tříd.;
    • příklady
      • obalové třídy primitivních datových typů v Javě – abychom mohli používat metody, které se dotazují na jejich hodnoty, musí být primitivní datové typy obalené adaptérem;
      • zajištění zpětné kompatibility systému – požadavky se musí zpracovávat podle toho, jaké rozhraní klient očekává.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Bridge

A
  • Bridge
    • zavádí rozhraní, které odděluje abstrakcí zprostředkovávající nějakou službu od její implementace, takže lze obojí měnit nezávisle na sobě;
    • příklad
      • okno v GUI – abstrakce okna a její funkcionalita x specifická implementace na konkrétním OS.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Composite

A
  • Composite
    • slouží pro jednotné vyjádření hierarchií typu celek-část;
    • příklad – stromová struktura.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Decorator

A

Decorator

  • dynamicky připojuje další funkcionalitu k objektu – pokud chci, aby více objektů získalo určitou funkcionalitu, a nechci jí v každém implementovat zvlášť, tak je zabalím do určité třídy. Obalující třída má na starosti jen požadovanou funkcionalitu a zbytek deleguje na obalený objekt;
  • flexibilní alternativa dědění;
  • někdy potřebujeme přidat odpovědnosti jen jednotlivým objektům, nikoli celé třídě;
  • často se používá v Jave v GUI – např. při návrhu GUI potřebujete přidat ohraničení nebo rolování k určité komponentě. Řešení je, že vložíte komponentu do dekorátoru;
  • implementace – mám několik tříd, kterým potřebuju dodat určitou funkcionalitu. Tak jim vytvořím společné rozhraní, které implementují nejen tyto třídy, ale i dekorátory. Stejně tak můžu udělat s pomocí abstraktní třídy, která bude předkem těchto tříd a tak může implementovat nějakou funkcionalitu, která je pro všechny dceřiné třídy společná.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Decorator

A
  • Decorator
    • dynamicky připojuje další funkcionalitu k objektu – pokud chci, aby více objektů získalo určitou funkcionalitu, a nechci jí v každém implementovat zvlášť, tak je zabalím do určité třídy. Obalující třída má na starosti jen požadovanou funkcionalitu a zbytek deleguje na obalený objekt;
    • flexibilní alternativa dědění;
    • někdy potřebujeme přidat odpovědnosti jen jednotlivým objektům, nikoli celé třídě;
    • často se používá v Jave v GUI – např. při návrhu GUI potřebujete přidat ohraničení nebo rolování k určité komponentě. Řešení je, že vložíte komponentu do dekorátoru;
    • implementace – mám několik tříd, kterým potřebuju dodat určitou funkcionalitu. Tak jim vytvořím společné rozhraní, které implementují nejen tyto třídy, ale i dekorátory. Stejně tak můžu udělat s pomocí abstraktní třídy, která bude předkem těchto tříd a tak může implementovat nějakou funkcionalitu, která je pro všechny dceřiné třídy společná.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Fascade

A

Fascade

  • cílem je zjednodušit (sjednotit) rozhraní;
  • snižuje počet tříd, se kterými musí uživatel komunikovat.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Flyweight

A

Flyweight

  • vzor vhodný pro situace, kdy vzniká mnoho malých objektů, u kterých je možné podstatnou část jejich stavu sdílet nebo ho nahradit výpočtem;
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Proxy

A
  • Proxy
    • zavádí zástupce, který odstiňuje objekt od jeho uživatelů a sám řídí přístup uživatelů k danému objektu
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Vzory pro vytváření objektů (Creational patterns)

A

Vzory pro vytváření objektů

Řeší problémy související s vytvářením objektů v systému:

  • snaží se oddělit vytváření objektů do samostatné třídy/tříd
  • konkrétní třída, od níž se vytváří instance, se určuje až za běhu programu
  • třeba zajistit správný počet objektů
  1. tovární metoda (factory method)
  2. abstraktní továrna (abstract factory)
  3. stavitel (builder)
  4. prototype
  5. jedináček
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Tovární metoda (factory method)

A
  • tovární metoda (factory method)
    • několik tříd, které mají obvykle společného předka a poskytují různé služby
    • dovoluje za běhu programu vytvořit instanci některé z těchto tříd
    • definuje rozhraní pro vytváření objektu; přenechává rozhodnutí, od které třídy vytvořit objekt, na své podtřídy
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Abstraktní továrna

A
  • abstraktní továrna (abstract factory)
    • při vytváření více objektů, které spolu souvisí
    • poskytuje rozhraní pro vytváření rodiny příbuzných objektů bez nutnosti specifikovat konkrétní třídy
    • složená třída obsahující stejné složky vytvářené různě v závislosti na aplikaci
    • abstraktní továrna je založena na myšlence, že se jako parametr do konstruktoru předá třída (továrna) se standardním rozhraním – to je pak použito konstruktorem, ale jeho metody jsou implementovány odlišně pro každý typ továrny
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Stavitel (builder)

A
  • stavitel (builder)
    • podobný abstract factory
    • máme různé objekty s podobným procesem konstrukce
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Prototype

A
  • prototype
    • vytvoření kopie existujícího objektu namísto vytváření nové třídy (v Javě rozhraní Cloneable)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Jedináček (singleton)

A

jedináček (singleton)

  • cílem je zabránit vícenásobnému spouštění konstruktoru – chceme, aby třída měla pouze jedinou instanci
  • řešení
    • použít statickou proměnnou třídy, která bude obsahovat informaci o tom, zda již byla vytvořena instance třídy
    • definovat privátní konstruktor třídy
    • definovat statickou metodu getInstance(), která bude vracet instanci třídy
  • příklady
    • jediné připojení k databázi
    • správce tiskových úloh
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Vzory chování

A

Vzory chování

  • mediator (prostředník)
  • observer (pozorovatel)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

Mediator (prostředník)

A

mediator (prostředník)

  • definujeme objekt prostředníka, který zprostředkovává veškerou komunikaci objektů
  • vzájemně závislosti objektů se tak omezí na závislost na prostředníku
  • u telefonů – obdobné řešení – telefony také nejsou spojeny každý s každým, ale spojují se prostřednictvím ústředny
  • většinou implementován pomocí vzoru Observer
24
Q

Observer (pozorovatel)

A
  • observer (pozorovatel)
    • problém
      • na stavu jednoho objektu závisí jiné objekty
      • při změně stavu jednoho objektu je třeba informovat objekty na něm závislé
      • tyto objekty jsou volně vázané – objekt měnící svůj stav informuje ostatní, ale je nezávislý na jejich vnitřním uspořádání
    • řešení
      • objekt měnící stav – subjekt – informuje objekty u něj zaregistrované jako pozorovatele/posluchače – observer
        • pozorovaný objekt (subjekt) udělám potomkem třídy Observable a zařídím, aby ve správnou chvíli informoval pozorovatele
        • pozorovatele nechám implementovat rozhraní Observer a definuji v nich metodu update, kterou subjekt při dané změně stavu zavolá
    • příklad
      • změní se zaškrtnutý RadioButton
      • v adventuře byly na změně místnosti závislé věci v dané místnosti
25
Q

Přínos návrhových vzorů

A

Přínos návrhových vzorů

  • popisují opakující se problém spojený s návrhem SW a poskytují jeho řešení,
  • zachycují a dokumentují již existující a praxí ověřený návrh,
  • umožňují pracovat na vyšší úrovni abstrakce,
  • definují jazyk pro popis návrhu,
  • dokumentují architekturu,
  • stavební prvky, z nichž se dávají stavět komplexní návrhy
  • zajišťují vyšší kvalitu SW.
26
Q

Výhody používání vzorů

A

Výhody používaní vzorů

  • zvýšení znovupoužitelnosti a produktivity
  • řízení znalostí
  • rychlejší a efektivnější vývoj – vývojáři se zaměřují na to, co vytvářet a ne, jak to vytvářet
  • automatizované generování kódu pro vzory
  • zvýšení kvality kódy
27
Q

Architektonické vzory

A

Architektonické vzory

SW vzory, které představují řešení architektonických problémů v SW inženýrství.

Představují základní strukturu SW systému, která se skládá ze subsystémů, jejich odpovědností a vzájemných vztahů.

Představují koncept, který obsahuje podstatné prvky SW architektury.

Důležitou vlastností je, že obsahují různé atributy kvality.

Některé vzory představují řešení problémů výkonu, jiné řeší problém vysoké dostupnosti.

28
Q

Kategorizace architektonických vzorů

A

Kategorizace architektonických vzorů

  • vrstvy – dekompozice systému na části; agregátová vrstva, filtrující vrstva, indirection layer;
  • tok dat – pipes and filters;
  • centralizace dat – přístup k datům – shared repository;
  • adaptace;
  • rozšíření jazyka;
  • interakce s uživatelem – model-view-controller;
  • interakce komponent – client-server, peer to peer;
  • distribuce.
29
Q

Vrstvy

A

Vrstvy

Systém má několik úrovní komponent, kde komponenty vyšší úrovně závisí na komponentách nižší úrovně. Cílem oddělení komponent do vrstev je modifikovatelnost, přenositelnost a znovupoužitelnost.

  • Agregátová vrstva
    • technologická vrstva vytvářející mocnější agregované funkce z funkcí elementárnějších
    • vytvoření množiny funkcí, s jejichž pomocí je možné daný problém vyřešit nejrychleji a nejefektivněji
    • z agregace nižších funkcí do funkcí vyššího řádu:
      • na vyšší vrstvě se redukuje množina úloh, které lze pomocí funkcí vyšší vrstvy řešit,
      • na vyšší vrstvě se redukuje počet možných cest řešení úloh realizovatelných jak funkcemi vyšší vrstvy, tak funkcemi nižší vrstvy,
      • ty úlohy, na jejichž řešení je vyšší vrstva orientovaná se na této vrstvě řeší rychleji a efektivněji.
    • příklad:
      • tabulkový procesor; integrace dílčích služeb do komplexní služby při prodeji aut přes Internet
    • na vyšší vrstvě nelze realizovat ty úlohy, které jsou z hlediska cíle vrstvy irelevantní = redukce
  • Filtrující vrstva
    • technologická vrstva odstíněná od nepodstatných nebo nežádoucích specifik vrstev na nižší úrovni hierarchie
    • Použití
      • odstínění rozdílů v uživatelském rozhraní několika HW nebo SW komponent stejného typu – zajištění portability,
      • odstínění změn rozhraní v čase,
      • vytváření virtuálních zařízení, která odstiňují navazujícím vrstvám pro ně nepodstatné charakteristiky těchto zařízení (př. virtuální paměť, virtuální terminál).
  • Indirection layer
    • subsystém má být přístupný z jedné nebo více komponent, ale přímý přístup je problematický
    • k přístupu se používají speciální komponenty – wrappery
    • nepřímá vrstva zapouzdřuje všechny wrappery
30
Q

Tok dat

A

Tok dat

Pipes and Filters

  • filter – komplexní úloha je rozdělena na řadu menších úloh, které jsou navzájem nezávislé
  • proudy dat se transformují ze vstupních na výstupní
  • filter může mít více vstupů a více výstupů
  • filtry jsou propojeny pomocí pipes
  • filter se nestará o to, kdo je následujícím
  • pipes fungují jako datové buffery mezi filtry
  • variantou je pipelaine – nelze rozdvojení ani smyčky
31
Q

Centralizace dat

A

Centralizace dat – přístup k datům

Shared repository

  • data musí být sdílena mezi komponentami
  • jedna komponenta slouží jako centrální datové úložiště, ke kterému přistupují ostatní komponenty
32
Q

Interakce s uživatelem

A

Interakce s uživatelem

Model-view-controller – MVC

  • původně v jazyce SmallTalk
  • UI se mění častěji než business logika, v UI se zobrazují stejná data různými způsoby (tabulka, graf), je třeba měnit zobrazení za chodu. Změna rozhraní se však nesmí dotknout zdrojového kódu. UI kód je závislý na zařízeních
  • odděluje modelování problémové oblasti, prezentace a akcí uživatelského vstupu do tříd
  • příklad
    • spinner skládající se z textového pole a dvou tlačítek. Každé tlačítko má přiřazen ActionListener(controller), po stisknutí tlačítka se změní model a podle modelu (protože je sdílený) se změní zobrazení na textovém poli
  • princip
    • model zapouzdřuje data a logiku
    • jeden nebo několik views zobrazuje data uživateli
    • controller je spojen s každým view zpracovává vstupy a překládá je do požadavků na model
33
Q

Interakce komponent

A

Interakce komponent

Client-server

  • dvě komponenty potřebují komunikovat a jsou navzájem nezávislé (běží v různých procesech nebo na různých strojích)
  • nemají stejnou roli – ale jedna iniciuje komunikaci tím, že požaduje službu, kterou druhá poskytuje
  • komponenta musí umět poskytovat službu více klientům současně

Peer to peer

  • každá komponenta má stejné odpovědnosti, tj. může fungovat jako klient i jako server

peer-to-peer síť se skládá z dynamických komponent

34
Q

Testování SW

A

Žádný SW není bezchybný:

  • Čím později je chyba objevena, tím dražší je její odstranění
  • Náklady na odstranění chyb v průběhu cyklu projektu stoupají 100x až 1000x
35
Q

Testování SW

A

Je provádění funkcí programu v definovaném okolí a porovnání dosažených výsledků s těmi očekávanými, aby bylo zjištěno, jak dalece se program chová, tak, jak vyžaduje jeho specifikace.

Cílem testování SW je nalézt chyby ve zkoumaném SW, a tak vytvořit předpoklady pro jejich odstranění, což vede ke zvýšení kvality SW. Dalším cílem je dosažení spolehlivosti.

Testy, i rozsáhlé, nemohou zpravidla zaručit bezchybnost SW.

Oblast použití: SW, jehož kvalita má být dokázána.

Jen výjimečně postačují samotné testy k důkazu bezpečnosti.

Soudobý trend – vývoj řízený testy (TDD – Test Driven Development)

Definice:

  • Proces získání důvěry v to, že program nebo systém dělá, co se od něj očekává (Hetzel 1973)
  • Provozování programu nebo systému za účelem hledání chyb (Myers 1979)
  • Jakákoliv aktivita zaměřená na vyhodnocení vlastností a schopností programu nebo systému a určení, zda odpovídají očekávaným výsledkům (Hetzel 1983)
36
Q

Testování-fakta

A

Testování – fakta

  • testování pokrývá 50 % času projektu;
  • v tomto je zahrnuto i ladění a všechny typy testování,
  • vývojářské testování – 10 – 25 % času projektu,
  • 80 % chyb je ve 20 % kódu,
  • většinu (> 95 %) chyb vytvoří programátoři aplikace, tj. nejsou v OS, db, knihovnách…
  • třetina chyb jsou obyčejné překlepy a pravopisné chyby.
37
Q

Testování jako projekt

A

Testování jako projekt

K testování SW je vhodné přistoupit jako k jakémukoliv jinému projektu. Celý projekt lze rozdělit do 4 hlavních částí:

  • příprava na testování – v této fázi vznikají obvykle tyto dokumenty: testovací plán, testovací scénáře a testovací případy;
  • provedení testů – v souladu s testovacím plánem pak probíhají vlastní testy podle testovacích scénářů;
  • vyhodnocení testů – pokud by se vyhodnocování neprovádělo, tak by testování ani nemělo smysl;
  • rozhodnutí o dalším postupu – zopakování některých testů apod.
38
Q

Axiomy testování

A

Axiomy testování

  • žádný program nelze otestovat komplexně (množství různých vstupů do aplikace);
  • testování je postaveno na riziku (co když bude chyba zrovna v tom, co neotestujeme);
  • testování nikdy neprokáže, že chyby neexistují;
  • čím víc chyb najdete, tím víc jich tam je;
  • ne všechny chyby se odstraní;
  • cíl testování je v rozporu s cíli ostatních aktivit – zde je cílem nalézt chybu.
39
Q

Místo testování při řízení projektu

A

Místo testování při řízení projektu

Pokud testujeme v počátečních fázích vývoje, snižuje testování náklady na pozdější odstraňování chyb. Důležitým faktorem ovlivňujícím cenu je část životního cyklu, v jaké se SW při objevení problému nachází. Čím později je chyba odhalena, tím větší množství peněz stojí její odstranění.

40
Q

Kategorizace testů

A

Z hlediska předmětu rozlišujeme úrovně testů a z hlediska cíle rozlišujeme typy testů.

  • Z hlediska předmětu – úrovně testů
  • Z hlediska cíle – typy testů
41
Q

Z hlediska předmětu – úrovně testů

A

Z hlediska předmětu – úrovně testů

  • jednotkové testování – testování nejmenších vymezených částí systému (jednotek), provádějí vývojáři;
  • integrační testování – testování zaměřené na vzájemné vazby a propojení částí systému, ověřuje, že jednotky dodané vývojovým týmem lze integrovat, tj. vytvořit funkční build;
  • smoke test – ověřuje stabilitu buildu, provádí se před systémovým testem – eliminuje situaci, kdy po zapojení většího počtu testerů systém selže a není možné v testech pokračovat;
  • systémové testování – testování systému jako celku, od vstupu po výstup. Systémový test představuje hloubkový test systému, při kterém se zpravidla provádějí téměř všechny typy testů;
  • akceptační testování – testování za účelem prokázání splnění definovaných akceptačních kritérií, testy provádí koncový uživatel na vlastním testovacím prostředí, tím, je zaručena reálnost testovaných situací.
42
Q

Z hlediska cíle – typy testů

A

Z hlediska cíle – typy testů

Podle základních atributů kvality FURPS(FURPS+)

  • functionality – testy funkčnosti – testování funkčních požadavků;
  • usability – testy použitelnosti – test uživatelského rozhraní, nápovědy, školících materiálů, dokumentace;
  • reliability – testy spolehlivosti – frekvence selhání, možnosti obnovitelnosti, nestandartní podmínky;
  • performance – testy výkonu – časová odezva, propustnost, přesnost, dostupnost;
  • supportability – testy podpory – adaptabilita, udržovatelnost, internacionalizace, konfigurovatelnost.
43
Q

Dělení testů

A

Dělení testů

  • podle způsobu provedení
  • podle potřeby spouštět program
  • funkční/nefunkční/testy spojené se změnami
  • podle znalosti kódu
  • regresní testování
  • závislé x nezávislé testování
44
Q

Podle způsobu provedení

A

Podle způsobu provedení

  • manuální – testy provádí člověk (obvykle tester) podle předem stanovených testovacích směrnic, vlastních zkušeností atd.
  • automatické – spouštění předem naprogramovaných testů ve speciálním programu
45
Q

Podle potřeby spouštět program

A

Podle potřeby spouštět program

  • statické – provádí se bez nutnosti spuštění programového kódu. Testování probíhá analýzou kódu (code view). Analýza může být provedena buď ručně, nebo pomocí speciálních nástrojů;
  • dynamické – provádí se spouštěním programu a kontrolou jeho funkčnosti. Testování probíhá prováděním ručních testů, nebo spouštěním předem připravených automatických testů.
46
Q

Funkční/nefunkční/testy spojené se změnami

A

Funkční/nefunkční/testy spojené se změnami

  • funkční testy – založené na funcích, vlastnostech a možnostech interakce programu s jinými systémy, např. testy funkcionality, bezpečnostní testy…
  • nefunkční testy – komplexní testování toho, jak systém funguje, např. zátěžové, stresové, testy stability…
  • testy spojené se změnami – po provádění nezbytných změn, například oprav chyb nebo defektů, musí být SW znovu otestován, aby se zjistilo, zda došlo k odstranění problému, např. regresní testování.
47
Q

Podle znalosti kódu

A

Podle znalosti kódu

  • testování „černé skříňky“ (black box testing) – tester má přístup k programu pouze přes stejné rozhraní jako zákazník nebo uživatel. Zadává vstupy, postupuje podle připravených scénářů a na konci porovnává výsledek, zda se shoduje s očekáváním;
  • testování „bílé skříňky“ (white box testing) – tester má přístup ke zdrojovému kódu programu a zná vnitřní datové a programové struktury. Při testování tuto znalost využívá;
  • testování „šedé skříňky“ (grey box testing) – tester má přístup ke zdrojovému kódu, ale obvykle při spouštění testu nepotřebuje ke kódu přistupovat.
48
Q

Regresní testování

A

Regresní testování

  • takový test systému, při kterém jsou kromě nově přidaných funkčnsotí testovány i všechny funkčnosti z dřívějších buildů;
  • cíl – zabránit regresním chybám (rozbije se to, co dříve fungovalo; případně navrácení již odstraněných chyb).
49
Q

Závislé x nezávislé testování

A

Závislé x nezávislé testování

  • závislé testování – provádějí role, které mají jinou specializaci než testování (testují produkty vlastní práce), příklad vývojářské testování;
  • nezávislé testování – provádějí role, které testují výsledek práce jiných rolí, například testeři, zástupci zákazníka podílející se například na akceptačním testování nebo beta testování.
50
Q

Vývoj řízený testy (TDD – Test Driven Development)

A

Vývoj řízený testy (TDD – Test Driven Development)

Myšlenka: definovat nejprve sadu testů a teprve pak psát testovaný program. Při psaní programu se pak stačí soustředit pouze na to, aby výsledný program prošel napsanými testy. Jakmile program těmito testy projde, programátor se zamyslí, jak by jej měl dále vylepšit, zase napíše testy a opět se snaží upravit program tak, aby testy prošel.

Refaktorování je nedílnou součástí vývoje řízeného testy – jedná se o proces provádění změn v softwarovém systému takovým způsobem, že nemají vliv na vnější chování kódu, ale vylepšují jeho vnitřní strukturu. Je to disciplinovaný způsob pročišťování kódu s minimálním rizikem vnášení chyb. Zlepšování návrhu kódu poté, co byl napsán.

Výhody TDD:

  • při psaní programu může programátor kdykoliv spustit předpřipravenou sadu testů a průběžně na nich kontrolovat, kolik jich už proběhlo a kolik práce mu ještě zbývá;
  • ve chvíli, kdy proběhnou všechny testy, je programátor s prací hotov a nemusí již přemýšlet nad tím, jestli v jeho programu nejsou chyby.
51
Q

JUnit testování

A

JUnit testování

Open-source nástroj (framework) pro testování tříd napsaných v Javě.

Testovací rámec pro tvorbu a spouštění automatizovaných jednotkových testů.

Pro každou třídu se vytvoří soubor testů, které kontrolují, zda jednotlivé veřejné metody vracejí k zadaným vstupům očekávané hodnoty. Použití např. v metodice TDD (Test-Driven Development) – testy píšeme před zápisem samotného kódu

TestCase – nejčastěji užívaná třída frameworku JUnit – za pomoci dědičnosti jsou z ní vytvářeny odvozené třídy, které obsahují samotný testovací kód.

Každý z testů ve třídách odvozených od TestCase má 3 části (metody):

  • setUp()

metoda, která vytváří tzv. „přípravek“ = sada objektů, které se vytvoří před spuštěním každého testu, doplněná případně o nastavení nějakých okrajových podmínek. V této metodě je realizována tvorba a uložení instancí do atributů, nastavení vstupních hodnot atd.

  • testNazevTestu()

tato metoda zkoumá a vyhodnocuje chování testovaných prvků. Jméno testovací metody musí vždy začínat prefixem test. Framework díky tomuto předpokladu automaticky pozná, že se jedná o testovací metodu.

  • tearDown()

úklid po testu – uvolnění zdrojů

Uvnitř testovací metody se nachází tzv. potvrzovací metody (nazývány také testovací konstrukce):

  • v testovacích metodách se používají pro ověřování, zda je předpokládaný výsledek rovný výsledku skutečnému
  • Základními potvrzovacími metodami jsou metody assertEquals(x1,x2), kterých je celá řada a liší se pouze tím, jakého typu jsou jejich parametry. Těmto metodám předáme v prvním parametru očekávanou hodnotu a ve druhém hodnotu, ke které dospěl program. Pokud se tyto hodnoty liší, metody vypíší v testovacím okně očekávanou a obdrženou hodnotu a daný test ukončí.
  • Dále např.: assertTrue, assertNull, fail a další.
52
Q

Správa konfigurací

Software Configuration Management

A

Software Confiuration Management

Řízení vývoje SW systémů. (SCM)

Sledování a řízení změn v SW.

Standardy v oblasti SCM: ITIL, ISO19001…

Základní aspekty SCM

  • identifikace a dokumentace funkčních a fyzických charakteristik jednotlivých prvků systému,
  • řízení změn prvků a jejich charakteristik,
  • řízení verzí,
  • zaznamenávání a zpracování požadavků na změnu systému a stavu implementace
  • ověřování kompletnosti a validity systému,
  • řízení dlouhodobé konzistentnosti systému.

Konfigurace – souhrn prvků konfigurace reprezentující určitou podobu daného SW systému.

Cíle konfiguračního řízení

  • Určení a správa konfigurací
    • určení (identifikace) prvků systému, přiřazení odpovědnosti,
    • identifikace jednotlivých verzí prvků,
    • kontrolované uvolňování (release) produktu,
    • řízení změn produktu během jeho vývoje.
  • Správa sestavení a koordinace práce
    • určování postupů a nástrojů pro tvorbu spustitelné verze,
    • ověřování úplnosti, konzistence a správnosti produktu,
    • koordinace spolupráce vývojářů.
  • Zjišťování stavu systému
    • udržení informovanosti o změnách a stavu prvků,
    • zaznamenávání stavu prvků konfigurace a požadavků na změny
    • poskytování informací o stavech
    • statistiky a analýzy

SCM komponenty

  • správa verzí (version control),
  • řízení sestavení (system building),
  • distribuce aplikace (release management),
  • správa rozhraní (interface control)
  • řízení subdodavatelů (subcontractor control)
53
Q

Integrace/sestavení

A

Integrace / sestavení

Činnosti spojené se sestavením modulu či celé aplikace. Cílem je vytvořit systematický a automatizovaný postup. Build (sestavení) – postup při vytvoření aplikace, často se používá i pro označení výsledku, jednoznačný identifikátor, opakovatelný, konzistentní, úplný.

Postupné fázové sestavení:

  • Návrh, kód, testování a ladění jednotlivých tříd – vývoj jednotek (unit development),
  • Spojování tříd do velkého systému (systémová integrace, „velký třesk“),
  • Testování a ladění celého systému (systémová dezintegrace“)

Přírůstkové sestavení:

  • Vytvořte malou funkční část systému. Tu důkladně otestujte. Vytvoříte kostru.
  • Navrhněte, naprogramujte, otestujte a odlaďte další třídu.
  • Integrujte novou třídu s již hotovou kostrou.

Výhody – rychlejší odhalení chyb, lze dodávat zákazníkovi po částech, lepší sledování postupu.

54
Q

Nástroje pro podporu sestavení

A

Nástroje pro podporu sestavení

  • Správa sestavení
    • Luntbuild, CruiseControl, AntHill, Hudson
  • Vytváření skriptů
    • Make, ant, maven
  • Testování
    • Jednotkové testování – xUnit
    • Systémové testy
    • Funkční (akceptační) testy – selenium
  • Kontrola kódu
    • Metriky – CCN
    • Detekce chybných konstrukcí – PMD, FindBugs
    • Pokrytí kódu testy – EMMA, Cobertura
  • Integrace databáze
    • Database sandbox, SQLUnit
  • Zpětná vazba
    • Správné informace, správným lidem, ve správný čas, správným způsobem – mail, SMS, zvukové, speciální aplikace na liště.
55
Q

Distribuce aplikací -SD

A

Distribuce aplikací – SD

Všechny aktivity spojené s uvedením programu (softwarového systému) do používání.

Problémy při distribuci aplikací:

  • změny nainstalovaných a běžících aplikací,
  • závislosti mezi komponentami a aplikacemi,
  • koordinace při distribuci ve velkých sítích (klient server aplikace),
  • správa heterogenních platforem,
  • bezpečnost: soukromí, autorizace, kontrola integrity.

Činnosti SD

  • uvolnění (release) – činnosti spojené se zabalením aplikace a přípravou k distribuci zákazníkům. Navazuje na vývoj aplikace. Je potřeba též shromáždit všechny informace potřebné pro navazující kroky. Má obvykle dvě části:
    • balení aplikace,
    • informování zákazníků o vlastnostech a požadavcích aplikace;
  • instalace (install) – počáteční nahrání aplikace k zákazníkovi. Obvykle je to nejnáročnější část distribuce aplikace. Má dvě části:
    • distribuce aplikace na počítač,
    • konfigurace aplikace;
  • aktivace (activate) – činnosti ke spuštění aplikace. Může to být jednoduchý příkaz či složitý proces spouštění jednotlivých procesů;
  • deaktivace (deactivate) – opak aktivace, ukončení/zastavení běžících částí aplikace. Provádí se před aktualizací, odinstalováním či částí údržby (zálohování);
  • aktualizace (update) – instalace nové verze aplikace – speciální případ instalace. Obvyklý postup: deaktivace – aktualizace – aktivace;
  • přizpůsobování (adapt) – úprava již instalované aplikace na místní podmínky či změny místních podmínek;
  • odinstalování (deinstall) – aplikace bude odinstalována z počítače. Vhodná podpora systému pro distribuci sw. Je třeba správně vyřešit závislosti (co nechat a co zrušit);
  • vyřazení (derelease, retire) – aplikace již dále nebude vyvíjena/distribuována/podporována. Je potřeba informovat zákazníky.

Informační systémy a technologie - přijímací zkoušky VŠE - zpracování 2022 (11 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions