Minimální znalosti Flashcards
(20 cards)
Rozdíl mezi laděním softwaru, testováním softwaru a formální verifikací
Ladění softwaru (debugging) - proces hledání defektu (lokace v kódu) při znalosti selhání
Testování (testing) - je vyhodnocování SUT (Subject Under Test) sledováním jeho běhu. Zkoumá SW jeho spuštěním za účelem zlepšení jeho kvality.
Formální Verifikace - s pomocí formálních metod ověřuje, zda systém odpovída specifikaci. Dokazuje, nebo vyvrací správnost systému vzhledem k dané formální specifikaci nebo vlastnosti, použítiím matematických formálních metod
Definice testovacího případu (Test casu) a z čeho se skládá
Soubor podmínek, které určují zda aplikace, sw systém nebo jedna z jeho funkcí funguje tak, jak bylo původně zamýšleno.
Skládá se ze vstupních hodnot, očekávaných výsledků, ale také z prefixových a postfixových hodnot (pro přípravu programu před test a jeho vyčištění po testu)
Slouží k získání odpovědi ano/ne (passed/failed)
V-model (Nakresli obrázek, fáze, co uzavírá smyčku)
Smyčku uzavírá regresní testování (na různých úrovních) pro ověření, že nová verze SW nezavádí novou chybu
V-model - Akceptační testování
Účel: Zjišťujeme zda SW splňuje požadavky zákazníka
Typy chyb, které zjišťuje: SW neplní svůj primární účel
Testěři: Lidé, kteří jsou oddáleni od samotného vývoje.
Předpoklad: Případy užití domluvené se zákazníkem
V-model - Systémové testování
Účel: Splňuje SW jako celek specifikaci požadavků?
Typy chyb, které odhaluje: Chyby v návrhu a specifikaci
Testeři: Skupina lidí oddělená od vývojářu daného systému
Předpoklad: Jednotlivé části systému pracují samostatně
V-model - Integrační testování
Účel: Ověření rozhraní modulů v podsystému, jejich předpokladů a vzájemné komunikace
Typy chyb: Chyby v rozhraní a předpokládaných stavech systému
Testěři: Jsou součástí vývojové týmu
Předpoklad: Jednotlivé moduly pracují správně
V-model - Testování modulů
Modul je kolekce souvisejících jednotek (units), které jsou seskupeny v jednom souboru (C), tříde (C++/Java), baličku/modulu (Ada/Python/Perl), rozšíření (PHP)
Účel: Ověření zda jednotlivé moduly v izolaci pracují správně
Typy chyb, které zjišťuje: Chyby v komunikaci jednotek v modulu, chyby v použití/předání datových struktur v rámci modulu
Testeři: Většinou samotní programátoři modulu
Předpoklad: Jednotky splňují základní chování
V-model - Jednotkové Testování (Unit testing)
Účel: Zmenšit rozsah testování na vyšších úrovních. Poskytnout uživateli základní metriku o spolehlivosti jednotek
Typy chyb, které zjišťuje: Chyby na nejnižší úrovni (funkcionalita, návratové hodnoty, krajní hodnoty parametrů, vedlejší účinky)
Testeři: Samotní programátoři jednotek
Předpoklad: Modul (tj. funkce a datové struktury) je navržen pro unit testing
Co je to jednotka? (Unit)
Jednotka je fragment kódu popisující chování systému (např. posloupnost příkazu v imperativních jazycích) a související datové struktury, zaobalený v dále nedělitelném logickém celku
Např. procedury nebo funkce (C)
Jednoduché třídy nebo složitější metody v OOP jazycích (Java, C++)
Triggery v SQL
Klauzule v Prologu
Fáze jednotkového testování
Setup - Nastavení stavu/kontextu/prostředí pro SUT
Exercise - přenechání řízení SUT
Verify - kontrola dosažených výsledků a změněného stavu SUT
Teardown - vyčištění vedlejších účinků z testu
Vztah kritéria pokrytí (coverage criterion), požadavků na test (test requirements), testovacího případu (test case) a testovací sady (test suite)
Kritérium pokrytí (coverage criterion) - Pravidlo/předpis pro systematické generování požadavků na test (test requirement - specifický element SW, který musí daný test pokrýt/splnit)
Testovací sada (test set/suite) Množina testovacích případů (test case). Měla by se tvořit na základě předem zvoleného kritéria pokrytí s cílem dosáhnout 100% pokrytí (Míry udávající, jak moc daná testovací sada zkoumá SUT)
Definice zahrnutí kritéria pokrytí (coverage criterion subsumption)
Kritérium C1 zahrnuje kritérium C2 (C1 > C2), právě když kazdá testovací sada splňující (Sada s ohledem na kritérium pokrývá 100% testovacích artefaktů) kritérium C1 také splňuje kritérium C2.
Pomůcka: Když vytvočřím 100% testovací sadu silnějšího kritéria pokrytí, nemusím se zabývat slabšími kritérii
Tvorba CFG podle zdrojového kódu
CFG - Control flow graph (Graf toku řízení) je abstraktní model SUT (tzn. reprezentuje pouze vybrané informace daného systému/pohledu na něj). Slouží jako grafová reprezentace řízení běhu SUT.
Základní blok je posloupnost maximálního počtu příkazů pro které platí, že:
- Vstupní bod je na prvním příkazu
- Výstupní bod je na posledním příkazu
- Příkazy se provádí vždy sekvenčně v pořadí daném posloupností
- Základní blok může obsahovat příkaz pro větvení (skok) pouze na konci
Princip TDD (Test-Driven development)
Testování přenést co nejvíce na začátek projektu (na testování se nezapomene)
Těžit z automatizace spuštění testů (typicky unit-testy použitelné nejen pro ověření nové funkcionality, ale také jako regresní testy)
Princip:
- Napsat sadu testů
- Spustit testy a ověřit, že žádný neprošel
- Napsat kus kódu
- Spustit testy
- V případě zvýšení počtu passed refaktorovat kód a akci opakovat
Definice rozdílu mezi mock a stub
Stub - Objekt, kterého když se na něco zeptá SUT, odpoví vždy stejně (např. při zavolání open ho nezajímají parametry a vrátí pevně daný file descriptor)
Mock - Navíc od stubu kontroluje vstupní parametry a dokáže celý test selhat (tj. dokáže selhat i ve fázi exercise)
Definice kritéria pokrytí Modified Condition Decision Coverage
Vyžaduje, aby pro každý predikát p ∈ P a každou majoritní klauzuli ci ∈ Cp TR (test requirements) obsahovaly dva požadavky: ci se vyhodnutí na true a ci se vyhodnotí na false.
Majoritní klauzule ci určuje hodnotu predikátu p, pokud všechny minoritní klauzule
cj ∈ p, j != i mají hodnoty takové, že změna pravdivostní hodnoty majoritní klauzule ci změní pravdivostní hodnotu p.
Příklad požadavku:
abc = TFT
abc = FTF
TR = {abc = XTF, abc = TXF, abc = TFX}
Po expanzi TR = {abc = FTF, abc = TFF, abc = TFT, abc = TTF}
Definice kritéria pokrytí Pair-Wise Coverage (PWC)
Kritérium pokrytí všech páru bloků (PWC) vyžaduje, aby TR (Test requirements) obsahovaly každý blok každé charakteristiky a každý pár bloků každý z jiné charakteristiky.
Charakteristika - Typický znak, rys, profil (př. seřazení souboru - seřazeň vzestupně, seřazen sestupně)
Model vstupní domény - Abstrakce vstupů testovaného systému.
- Tester popisuje strukturu modelu vstupní domény pomocí charakteristik - Pro každou charakteristiku provádí rozklad vstupní domény na jednotlivé bloky - Každý blok představuje množinu hodnot vstupu SUT
Definice data-race(Časově závislá chyba nad daty) + příklad
Běh programu obsahuje data race, jestliže obsahuje 2 nesynchronizované přístupy ke sdílené proměnné a alespoň jeden z nich je zápis.
Definice load testing, stress testing, capacity testing
Performance testing patří do testování nefunkcionálních vlastností systému
Load testing - Zátěžové testování. Simuluje přístup několika uživatelů současně (například 50) a sleduje chování systému.
Průběh:
1. Tvorba virtuálního uživatele
2. Simulace zátěže
3. Monitoring AUT + logování
-malá sonda sledující pouze vybrané vlastnosti (kvůli režii)
- logování mimo testovaný stroj
Stress testing - Podobný princip jako load testing. Postupné zvyšování zátěže. Sledování požadovaných parametrů ( Např. kolik požadavků od uživatelů zvládne systém obsloužit s průměrnou dobou reakce max 5 sekund)
Capacity testing - Při určité hranici se z stress testing stává capacity testing. Zjišťování hranice, kdy systém přestává být spolehlivý
QA vs QC
Quality Control - Zajišťuje kvalitu produktu. Najde chybu a opraví ji (testování). Provádí validaci (Zjišťuje zda systém provádí to, co se očekává tedy to, co chce zákazník). Zodpovídá za testovací cyklus.
Quality Assurance - Zajišťuje kvalitu procesu tvorby produktu. Snaží se o to, zabránit vzniku chyby (např při návrhu). Provádí verifikaci (Zjišťuje zda systém odpovídá specifikacím). Zodpovídá za celý vývojový cyklus
