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 23:17]
roozi
+++ mgr-szz:in-gra:21-gra [2018/01/29 23:46]
roozi
@@ Řádek 91: / Řádek 91: @@
 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í.
@@ Řádek 173: / Řádek 190: @@
   * 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.
+**„Bad 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**\\
+====== 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