Rozdíly

Zde můžete vidět rozdíly mezi vybranou verzí a aktuální verzí dané stránky.

--- mgr-szz:in-gra:21-gra [2018/01/29 22:21]
roozi
+++ mgr-szz:in-gra:21-gra [2018/01/29 23:51]
roozi
@@ Řádek 85: / Řádek 85: @@
-====== Softwarové metriky, refaktoring kódu ======
+====== Fáze testování a typy testů ======
-Softwarová metrika je nějaký údaj (měření, atribut softwaru), který lze nakonec převést na číselné hodnocení.
+Proces spuštění (části) programu s cílem nalézt chyby. Nemůže ukázat nepřítomnost defektů, může pouze ukázat, že v softwaru jsou chyby. Testování také ukazuje funkce a výkon. A je také ukazatelem kvality software.Testování je destruktivní činnost, není vhodné, aby vývojář a tester byla ta samá osoba.
+  * Verifikace - test proti vnitřní činnosti (unit testy)
+  * Validace - test proti specifikaci
+BlackBox vs. WhiteBox (vidím/nevidím do struktury programu)
+**Typy testů**
+  * **Unit testy** - hledají defekty uvnitř softwarových komponent a verifikují fungování softwarových komponent (např. modulů, programů, objektů, tříd, atd.), které jsou testovatelné samostatně.
+  * **Assembly testy** - mají za úkol ověřit, že jednotlivé části kódu, testované v rámci unit testů, spolu fungují.
+  * **Integrační testy** - Integrační testování testuje rozhraní mezi komponentami, interakce s různými částmi systému jako jsou operační systém, souborový systém, hardware anebo rozhraní mezi systémy.
+  * **Systémové testy** - Systémové testování se zabývá chováním celého systému/produktu, jak byl definován rozsahem vyvíjeného projektu nebo programu. Měly by pokrýt jak funkční tak nefunkční požadavky.
+  * **Akceptační testy** - jsou hlavní částí testování z pohledu dodávky aplikace zákazníkovi.
+**Další testy**
+  * **Funkční testy** – slouží k nalezení rozdílů mezi aktuální aplikací proti funkční specifikaci (funkční požadavky)
+  * **Nefunkční testy** - zahrnují testování výkonu, zátěžové testování, stres testování, testování použitelnosti, testování udržovatelnosti, testování spolehlivosti a testování přenositelnosti. Je testováním toho, “jak“ systém pracuje (jako celek).
+  * **Statické testy** – provádí manuální prozkoumání (revidování) a automatizovanou analýzu (statickou analýzu) kódu nebo jiné projektové dokumentace (uživ.příručky, apod.)
+  * **Dynamické testy** - znamenají provádění testování na již běžící systému, aplikaci
+  * **Regresní testy** - testy na ověření stávající funkcionality (provádí se po opravení chyb či novem release)
+  * **Progresní testy** - testy na ověření nové funkcionality
+  * **Smoke test** - je krátký test, který slouží jako ověření, že vyvíjená aplikace je "způsobilá" pro další fázi testování.
+====== Softwarové metriky, refaktoring kódu ======
+Softwarová metrika je nějaký údaj (měření, atribut softwaru), který lze nakonec převést na číselné hodnocení.
 **Metrika**\\
 **Kvantitativní** (číselně vyjádřená) míra, tj. ukazatel do jaké míry se nějaký atribut vyskytuje v systému, komponentě nebo procesu nebo **kvalitativní** charakter, tj. nečíselné vyjádření.\\
@@ Řádek 159: / Řádek 183: @@
 Stupeň, do jaké míry systém, komponenta nebo proces splňuje zákazníkovy nebo uživatelovy potřeby nebo jeho očekávání. (spíše u krabicového SW)
+**Techniky zajištění kvality software**\\
+Obecně lze mluvit o testování, validaci a verifikaci produktu. Validací se rozumí otázka, zda jsme vytvořili správný produkt tj. jestli produkt odpovídá potřebám uživatele. Verifikací se rozumí, zda jsme produkt vytvořili správně tj. zda produkt odpovídá specifikaci. Testováním se pak pokoušíme zmíněné předchozí dokázat pro omezenou sadu příkladů.\\
+  * Inspekce, recenze
+  * Testování
+  * Měření
+  * Standardy a procedury
+====== Údržba a znovupoužitelnost (+refaktoring) ======
+Velmi nákladná v čase, finance odpovídají tomu jak dlouho ho chceme udržet. Náklady jsou 2x -100x větší než na vývoj. Na údržbu se mělo myslet již při vývoji.
+  * Oprava softwarových chyb
+  * Adaptace softwaru na jiné operační prostředí
+  * Přidat nebo měnit systémovou funkcionalitu -> každá implementace degraduje kvalitu systému
+**Systémový re-engineering**\\
+Znovu napsání celé části systému bez účelu změnit její funkcionalitu, když subsystémy vyššího systému vyžadují častou údržbu. Cílem je vytvoření nového systému, který by se lépe udržoval (i snížení ceny za údržbu).
+**Refactoring**\\
+Refactoring je kontinuální proces vylepšení skrze vývojový a evoluční proces. Jeho záměrem je vyhnout se degradaci struktury a kódu, která zvyšuje cenu za údržbu.
+**„Code smells“**\\
+  * Duplikovaný kód - kód se opakuje na různých místech programu
+  * Dlouhé metody
+  * Long Parameter List - dlouhý seznam parametrů
+  * Shotgun Surgery - abychom udělali jednoduchou změnu v kódu, je nutné sahat na mnoho míst, indikátor toho, že máme špatný model, že třídy mají špatnou zodpovědnost
+  * Middle Man - zprostředkované volání objektu zbytečně přes prostředníka
+  * Lazy Class - prázdná skořápka, třída, která nic nedělá
+  * Spekulativní obecnost - kód, který je v programu obsažen, aby sloužil někdy do budoucna
+**Znovupoužitelnost**\\
+Hlavní výhodou je několikanásobné finanční ohodnocení jednou vyvinuté komponenty.
+**Úrovně znovupoužitelnosti (reuse levels)**\\
+  * Abstrakce (The abstraction level): analytické prvky
+  * Objekty (The object level): třídy
+  * Komponenty (The component level): kolekce tříd
+  * Systém (The system level): celý systém a různé platformy
+**Reuse-Oriented software engineering**\\
+Model vývoje SW, založen na systematickém znovuužití, kde jsou systémy integrovány z existujících komponent (commercial-off-the-shelf = COTS). Zbylou funkcionalitu (kterou ještě nemáme) doprogramujme, především proxy, adaptéry a GUI. Jedná se o standardní budování business systémů.
+====== Zdroje ======
+Velká většina z https://docs.google.com/document/d/1JVC34-jBqK-hnyxty9YNelID_LChUsvREdgS9NaEjvI

mgr-szz/in-gra/21-gra.txt · Poslední úprava: 2020/04/12 16:56 (upraveno mimo DokuWiki)

Nahoru