Softwarové inženýrství II

Editovat
Note

Testování, verifikace a validace. Provoz, údržba a další vývoj systému. Role jazyka UML v podpoře analýzy a návrhu SW.

PB007
Warning
 Obrázky v této otázce kreslené rukou byly sprostě ukradeny Dominice Krejčí z https://github.com/Krejdom/school_notes. Snad jen dočasně.

Testování

Snaha o automatizovanou kontrolu přítomnosti chyb v kódu. Umí potvrdit přítomnost chyb, nikoli dokázat jejich absenci.

Funkční požadavky

Unit testy

Testují jednu ,,jednotku'' (většinou funkci) v dané situaci.

Integrační testy

Používají více ,,jednotek'' dohromady.

UI testy

Otevřou (většinou) browser a interagují se stránkou tak, jak by se (snad) choval uživatel.

Nefunkční požadavky

Benchmarky

Testy výkonu.

Stress testy

Odpovídají na otázku ,,Jak vysokou zátež to asi snese?''

Testování bezpečnosti

Známé útoky, password checkery, formální verifikace.

Test-driven development (TTD)

Metodika, jenž klade důraz na 100% pokrytí testy a psaní testů před psaním vlastního kódu.

Note
 Test-driven development stejně jako každý seznam pouček v softwarovém inženýrství jsou spíše doporučení než-li opravdová pravidla.
Poučky

  • Nejprve napíšeš testy, pak teprve implementaci.

  • Každý řádek kódu testy pokryješ.

  • Regrese (opětovné zavedení chyby) odhalíš.

Fáze testování

  • Development — v průběhu vývoje (unit testy, integrační testy, systémové testy)

  • Release — těsně před zveřejněním

  • User — za pomoci potenciálních uživatelů

    • Alfa testování — uživatelé spolupracují s vývojáři při vývoji

    • Beta testování — SW je napůl venku, uživatelé hlásí chyby

    • A/B testování — sběr názorů na variantu A a variantu B

    • Acceptance testování — zákazníkovo požehnání při převzetí

Verifikace

Funguje ta věc správně?

Statická

Hledáme chyby, aniž bychom spustili kód. Využívá statické analýzy programovacího jazyka.

Dynamická

Kontrolujeme, jestli systém dělá, co má, za běhu.

Formální

Využívá formalismů — např. automatů.

Validace

Je ta věc fakt to, co chci?

Týká se abstraktnějších a hůře testovatelných konceptů jako: moralita, bezpečnost, spolehlivost, …​

Údržba

Jakmile je systém ,,hotov'' a je nasazen v produkčním prostředí, začíná fáze údržby. Je i nadále třeba opravovat chyby, aktualizovat závislosti třetích stran, spravovat HW, a přidávat nové fíčury.

Refactoring

Zlepšení struktury, časové/prostorové složitosti, čitelnosti kódu.

Unified Modeling Language (UML)

Specifikace diagramů určených pro modelování systému. Využivá grafickou notaci pro vyjádření různých pohledů na systém a dá se zákazníkům ukázat spíš než kód.

Diagram případů užití (use case diagram)

Znázornění požadavků na systém a interakce s uživateli. Pohled na systém zvenku, bez implementačních detailů.

p18 use case
Diagram tříd (class diagram)

Zobrazuje OOP třídy a vztahy mezi nimi (zejména dedičnost, kompozici a referenci). Pokud toho obsahuje málo, označuje se za analytický. Pokud reflektuje ty typy do detailu, je návrhový.

p18 class
Sekvenční diagram (sequence diagram)

Interakce mezi aktéry (uživateli a externími entitami), systémem a vnitřními komponentami systému.

p18 sequence
Diagram aktivit (activity diagram)

Zachycuje procesy jako posloupnost událostí včetně možných rozvětvení.

p18 activity

Perpektivy UML

Perspektiva Diagramy

Vnější

Use case

Strukturální

Class, Package, Object, Component, …​

Interakční

Sequence, Communication, Timing, …​

Chování

Activity, State