TS Flashcards

Question

Exploratory testing

Answer 1

Navrh testu a pruchodi aplikaci bez patricnych scenaru enbo nedostatecne dokumentaci a basi: "Zaznamenavam co jsem testoval" - Paralelní učení, návrh testů a jejich provádění. Tester navrhuje testy v průběhu jejich provádění a získané informace jsou využity pro návrh nových a vylepšených testovacích případů. - * Řešení situace, kdy není k dispozici test basis nebo nejsou připravené testovací scénáře a není čas je vytvořit * Závislé na zkušeném týmu testerů * Není doložené pokrytí aplikace testy * Při vhodném nastavení zvýší pokrytí zajištěné formálními technikami pro návrh testů

Answer 2

V systemu obecne bjekty/entity maji svuj zivotni cyklus, ktery upravujeme zakladnimi CRUD operacemi. Muze se vsak stat, ze proces A pracuje s entitou E a zavede do ni chybu - necha v nekonzistenntnim stavu - treba misto jmena ulozi adresu Pote proces B bude pracovat s touto Entitou a mela by se najit chyba v tento moment, aby program fungoval spravne Obycejny pruchod procesnim testem nam takovou chybu nemusi odhalit, protoze zavedeni chyby a jeji najiti nemusi lezet ve stejnem testovaci scenari nebo ve stejnem hranovem pruchodu systemu - tedy je nutne manualne osetrit pripady, kdy jeden proces chybu zavede a druhy ji odhali - nepomuze ani kompletni hranove pokryti, protoze se treba nemusi navzajem procesy vubec znat a komunikujou pouze pres databazi V realu nejde odhalit 100% CRUD chyb, ale minimalizujeme jejich vyskyst CRUD matice - matice prav na modifikaci, ukazuje, jake funkce/akce/procesy jakym zpusobem moditifikuji entity systemu. Sanity check - kazda entita musi mit definovany vsechny 4 CRUD operace napric funcemi, pokud ne -> nejspis chyba (treba nema CREATE) - kontrola logiky prav, zda to dava smysl TEST KOMPLETNOSTI TEST DATOVE KONZISTENCE - minimalizuje riziko zavlecnei chyby a prace s nekonzisentnim objektem - vytvorim testovaci scenar (procesni) ktery simuluje vsehcny CRUD operace - po kazde CRU operaci zavolam i R (idealne pokazde, protoze kompletni pokryti odhali vic chyb nez jen jedno volani R) - tedy po kazde uprave entity ji nactu a zkontorluju, zda predchozi operace ji zanechala v konzistenim stavu

Answer 3

Modifikace entity je povolena, pouze za splnenych business podminek: treba "uzivatele jde smazat, pouze pokud nema dluh" Musi se otestovat jak validni modifiakce podle podminek, tak i negativni prubeh

Answer 4

Entity v systemu mohou mit stavy a ridit se prechody (funkce/udalost/akce) do jinych stavu. Mohu reprezentovat stavovym automatem pomoci matice prechodu - - ze stavu A se dotanu do stavu B pomoci funkce F... Minimální kontrola konzistence, pokud stav. automat vytváříme ze specifikace: * Všechny akce pokryté * Všechny stavy pokryté * Definovaný počáteční a koncový stav * Do stavu se lze dostat * Kromě koncového stavu musí ze všech jít přechod ven

Answer 5

Testuje spravnost stavovych prechodu bud po jednom, nebo sekvence prechodu: Čím vyšší N, tím více kombinací přechodů musí být testováno – zvyšuje se pokrytí, ale i náročnost. V praxi se volí podle kritičnosti systému a požadavků na kvalitu. Představme si automat: Stav A → (akce x) → Stav B Stav B → (akce y) → Stav C Stav C → (akce z) → Stav A Tedy přechody: A → B B → C C → A 0-switch coverage Test obsahuje každý přechod zvlášť: A → B B → C C → A Je to základní test – pokrývá každý jednotlivý přechod. Odpovídá tzv. smoke testu. 1-switch coverage Pokrýváme všechny sekvence dvou přechodů (tzn. 3 stavy): A → B → C B → C → A C → A → B Každá dvojice navazujících přechodů je pokryta. 2-switch coverage Pokrýváme sekvence tří přechodů (tzn. 4 stavy): A → B → C → A B → C → A → B C → A → B → C A tak dále az N -coverage

Answer 6

Dalsi pokryvaci testovaci technika zalozena na zkusenosti testera- - odhadne slaba mista, nebo podle povahy systemu historicky nejkritictejsi misto - treba platba - nebo zadavani udaju od uzivatelu... - simulace "hloupeho" uzivatele, ktery zavlece chybu - snaha poskodit system a podle toho ho testovat - rozbit system

Answer 7

Casovy zaznam pouzivani apliakce realnymi uzivateli - po nasazeni monitorovani, sledovnai, logovani - zisk konkretnich scenaru, procesu a pruchodu apliakci - vylepseni testovacch pripadu - vylespeni/robustnejsi posila nejcastesjich pruchodu pomoci dalsich testu Mohu vytvorit matici pravdepodobnosti vyvoalni nejake akce v apliakci - tedy seznam stavu aplikace a sloupce jsou pravdepodobnost zavolani akce - stochasticke amtice - soucet radku musi dat 100% - tedy z kazde akce se musim nutne umet dostat do jineho stavu podle nejvetsi bunky pravdepodobnosti vyvolani akce -> nejvic tam poslu testu

Answer 8

Testovací prostředí (IEEE 610 definice) * Prostředí obsahující hardware, simulátory, nástroje a další podpůrné elementy pro provádění testů Angl. (podle ISTQB): Test environment, Test rig, Test bed Účel testovacího prostředí: * Ideální stav: izolované prostředí pro vykonávání testů - minimalizace interferencí s vývojovým týmem: * Změny testovaného systému pod kontrolou (plán nasazování do prostředí) * Možnost připravit specifická testovací data * Stav aplikace vázaný na průběh testů zůstane zachovaný Obecne v IDE treba soubezne s vyvyjenou aplikaci ve stavu DEV. Napisu zakladni strukturu (unit, procesni...), pripravim testovaci data (bud si vytvorim sam, nebo vygeneruju nova, nebo pouziju realne PROD data), bud mohu pustit primo nebo pres virtualizaci nejakych komponent (mockito)

Answer 9

trivialne...

Answer 10

Obence: coverage = (testovane_prvky / celkem_prvku) * 100 1. Line coverage - kazdy prikaz je otestovan 2. Branch coverage - kazda mozna vetev je otestovana ve stromu pruchodu 3. Function coverage - kazda procedura otestovana 4. State coverage - otestovani vsech stavu

Answer 11

Vylepseni JUnit, knihovna ktera se prida do pom.xml jako dependency Poskytuje treba individualni @Before a @After pro jednotlivy assert test a ne pro celou skupinu - lidstejsi zapis assertu

Answer 12

Pomocna metoda, kterou zadefinuju jako @DataProvider, potom JUnit metody ji mohoou pouzivat jako factory na data -@Test(DataProveder = 'name') void foo(...) {pozuiva data generovana z Data provider metody)

Answer 13

Z vice unit testu v sobe - tedy je to sekvence vice akci/metod, po kazdem vykonani provedu assert a pokracuju v dalsih funkcich a zas assert atd... Tedy zretezim nekolik unit testu do jednoho logickeho pruchodu E2E apliakci

Answer 14

Klasické jednotkové testy, Integrační a FE testy * Arrange-act-assert sktruktua * Čitelný kód * Srozumitelné jmenné konvence * Konkrétní assert zprávy → snadnější reportování * Konfigurace mimo sadu testů Klasické jednotkové testy navíc: * Nezávislost jednotkových testů * Granularita Vyhněte se následujícím negativním vzorům (antipatterns): * Weak tests (not likely to fail) * Wrong try-catch inside * Overprotective tests (failing also for irrelevant causes) * Readability * Unclear assertions * Hyperassertions * Too much code extra to the test making it unclear, long code * Using magic numbers instead of self-explanatory constants * Too extensive set-up code * Granularity * @Test checking multiple things

Answer 15

Zalozen na JUnit hlavne - agilbi metodika vyvoje SW - jedna z komponent extremniho programovani Zakaldni postup: 1. Nejdriv napis test na novou funkcionalitu (ktera jeste neexistuje) 2. Proved testy - vsechny predchozi testy pass, novy test fail 3. Pridej metodu na novou funkcionalitu 4. Opakuj krok 2 dokud i novy test neda pass 5. Zacni od kroku 1 Tedy je to stale opakujici se smycka kdy napisu test -> az pak na nej napisu metodu -> dokud mi neprojde novy test -> prepisuj metodu NIKDY se nesmi stat, ze by neprosly testy, ktere pred tim davaly pass Muze vyuzivat stub (nahrazuje volanou komponentu, simuluje navrat) nebo driver nebo simulator komponent, pokud k nim nema pristup nebo jeste neexistujou

Answer 16

Na zacatku vyvoje se stanovi akcepcni testy s klientem, ktere se od zacatku vyvoje kontorluji a tomu se prizpusobuje kod. Predejde tomu, ze vyvyjime ne uplne to co klient chtel (i kdzy testy prochazeji) - tedy opakovana kontorla, ze dalsi featura nam nepokazi pozadavky klienta

Answer 17

Testovaci Strategie - High-level popis test levels a testů prováděných v rámci těchto test levels na úrovni organizace nebo programu (program se skládá z více projektů) Test Approach - Implementace testovací strategie pro specifický projekt. Typicky zahrnuje cíle testování, zhodnocení rizik, které určují organizaci testů, test design techniky, které budou použité, exit criteria a typy testů, které budou prováděny Test Plan - Dokument, který popisuje scope, přístup, zdroje, harmonogram konkrétních testovacích aktivit. Mimo jiné popisuje části systému k otestování, jejich funkce, úkoly, které plynou z přípravy a exekuce testů, přiřazení úkolů členům týmu, popis testovacího prostředí, test design techniky, které budou použity a zdůvodnění jejich výběru, entry a exit kritéria, zhodnocení rizik a popis případného záložního plánu (definice podle IEEE 829, převzatá do ISTQB Master Test Plan - Test plan, který typicky pokrývá více test levels Strategie = "co a proč testujeme obecně", Přístup = "jak to uděláme v tomto projektu", Plán = "kdo, kdy, co přesně bude testovat", Master plán = "plán, který koordinuje více testovacích částí nebo úrovní". V praxi hlavne MTP - strukturovany dokument poskytujici velmi globalni prehled o testovani daneho projektu: - musi se neustale aktualizovat

Answer 18

Vhodna na vetsi projekty Vystupem je velka tabulka obshujcii a popisujici: - test goals - evidence pozadavku, specifikaci, casti testovaneho systemu - analyzu rizik systemu - definovane test levels - druhy provadenych testu a intenzitu - zvolene test design pristpy 1. Test Goals - popisuji nezavisle cile testovani - overal test goals - od investora treba - departmetn test goals - typicky od uzivatelu koncovych - popisuje ocekavanou kvalitu systemu - muze najit rozpory mezi pozadavky - neco jako Business Cile (overal) a Business Pozadavky (department), tedy overal jsou konkretni extremne obecne kvalitni pozadavky a pak department level je urpesnuje a vztahuje na overal cil 2. Evidence pozadavku - k tomu muzu pridat QUALITY CHARACTERISTICS jako vtah na oblast systemu - "tyka se tento pozadavek GUI, nebo bezpenosti, nebo vykonnosti, nebo privetivosti atd..?" To pridam do tabulky test Goals pozadavku 3. Urceni rizik - podle pravdepodobnosti selhani nebo vyvolani ake - podle priority rizik nastavim intenzitu a hloubku testovani - vyju z monitorovani/profilovani/ zkusenosti, zpetne vazby, znalosti slabych mist/dulzezitych systemu - beru v potaz i pravni/financni nasledky nedostateceneho osetreni rizikove oblasti systemu - popisu tedy cast systmeu, jeji prioritu, riziko, dopad selhani a vysvetleni - rizika muzu podle zavaznosti a pravdepodobnosti stepit na tridy rizik 4. Pro kazdy element tabulky stanovim uroven jejiho testovani 5. Pridam intenzitu testovani kazde urovne 6. Pridam i konkretni test design k polozkam

Answer 19

Exploratory testing (průzkumné testování) je typ testování, při kterém tester současně navrhuje, provádí a vyhodnocuje testy, aniž by měl předem připravené testovací případy. Bez detailního skriptu – tester nemá přesný seznam kroků, ale spíš cíle nebo oblasti k prozkoumání. Založené na zkušenostech – tester používá svou intuici, doménové znalosti a kreativitu. Interaktivní a adaptivní – testování se přizpůsobuje výsledkům, které se právě objevily. Často se používá k objevování neočekávaných chyb, které by skriptované testy přehlédly. Máš aplikaci na rezervaci hotelů. Místo toho, abys podle skriptu zadal „datum příjezdu → datum odjezdu → počet osob“, se rozhodneš zkoumat chování: zadáním budoucího i minulého data, zadáním nulového počtu osob, rychlým klikáním zpět a vpřed, použitím speciálních znaků v poznámce pro recepci. 🛠 Kdy se používá: Když není dost času na tvorbu testovacích případů. Pro doplňkové testování k automatizovaným nebo skriptovaným testům. Při zkoumání nových funkcí nebo prototypu. V raných fázích vývoje nebo u rizikových oblastí.

Answer 20

1. Nizka intenzita - Exploratory testing - TDL1, TDL2 - State 0-switch, State 1-switch coverage - CD/C kombinace vstupnich dat, manualni kombinace 2. Stredni intenzita - Exploratory testing, Error guessing - TDL2, TDL3 - State 1-switch, State 2-switch coverage - CRUD basic pruchody - Paiwise testing, MC/DC 3. Vysoka intenzita (kriticke casti, rizika) - zadny Exploratory ani Error guessing, pouze strukturovane planovani testu - TDL3 az TDLN - State 2-switch a N coverage - CRUD extended - MC/DC, MCC (kompletni pokryti vsech vstupnich dat a vsech pruchodu)

Answer 21

E2E - princip jako integracni/procesni testy, akorat musi zacinat a koncit v logickych bodech aplikace - od zacatku do konce, a ne jen vybrana podposloupnost akci - testuje celkovy flow apliakce z pohledu uzivatele od vyhledani webov e starnky, proklikavani, potvrzovani a opusteni - testuje aplikaci jako celek - vetsi testovaci coverage - dokaze odhalit chyby vyskytujici pouze spoustenim urcitych akci - prevetns regresions - pokryva nejenom nas kod ale take i jeho spolupraci s podsystmu nebo servisami - tedy netestuje izolovany celek, ale celou architekturu systemu - testuje napric celym systemem od unit testu po UAT Dva hlavni typy: 1. Horizontalni - navigace uvnitr apliakce z pohledu uzivatele, zda se dokaze vsude proklikat - spis simulace uzivatelu - odchytavani procesnich bugu - tedy je to strukturovany, vrstveny test treba zapni apliakci, spust browser, naviguj se na policko, prihlas se, zkus zmenit ucet, zkontroluj ze ucet byt aktualizovat v databazi - zameruje se na konzistenci a bezpecnost systemu - jde spis o zatezovny a kontrolni test 2. Vertikalni - postupne testuje zvlast vsechny komponenty systemu - treba proces jako " spust unit testy, spust platici testy procesni, spust emailovaci testy integracni, spust testy site..." - tedy automatizacni testy ktere zkontrolujou napric celym systeme odshora dolu pres vsehny test level treba Selenium, Postman

Answer 22

Nastroj pro automatizovany prohlizeni webu - automaticke testovani - e2e testovani - web-crawling - data extraction Nahraje stranku rozpozna elementy najde textove hodnoty umi handlovat user input vyplnuje pole pohybuje se po strance managuje cookies Spusti lokalni server v ramci Browser WebDriver a komunikuje pomoci http requesty POM pristup - nacte stranku jako lokalni tridu, kde elementy jsou pristupne jako atributy pomoci identifikatu findby name, find by id, find by class - design pattern ktery vytvori Objektovy repozitar pro elementy UI stranky - jednotlive stranky web aplikace prevede na tridy - elementy strnaky jsou atributy trid a muzeme se k nim dotazovat podle tanovenych metod a identifikatoru Spolupracuje s Page Object Factory - design pattern, ktery zabaluje hodne Selenium nizkourovneoveho kodu a poskytuje rozhrani pro pristup k elementum strnaky (stranka je primo namapovana na classu) - poskytuje publkic metody lidstesi jako: - enterUserName, enterPassword, login, logout... - tyto metody patri jednotlivym strankam - tedy prace je pak uzivatelsky prijemnejsi - nemusime pak psat jednotlive kroky rucne v Seleniu - staci tedy: - new driver -> NewPage page = facotry.goTo(page) -> page.perfrormAction1.performAction2...performActionN.logout()... - nevyhody: dlouhy a narocny setup, nova trida pro kazdou stranku Muzeme retezit operace do sekvenci, ktere se maji provest v prohlizeci Zakladni pouziti v testu: new driver drever get (stranka) driver.findelement by id (name).click / sendkeys... wait for update click znova zkontroluj zmenu...

Answer 23

Metodika testovani SW kdy je snahou minimalizovat caste chyby testovani nebo znovuopakovani tech samych procesu z duvodu nepochipeni nebo spatne zadane specifikace - snazi se minimalizovat komunikacni mezery - pouziva priklady, jak se system ma chovat (behavior), poukazuje na business pozadavky a pravidla - cilem a myslenkou je, ze jakykoliv netechnicky clovek by mel byt schopny navrhovat testy bez znalosti zadnych technik -> jen podle popisu chovani aplikace pracuje na popisu testu z pohledu tri stavu: GIVEN, WHEN, THEN Popis jako podobne funkcni pozadavky: Scenar: provedeni nejake aktiviyty v systemu GIVEN: za techno PREDPOKLADU WHEN: provede se aktivita THEN: co se ma stat/zkontrolovat/zmenit... Jako uzivatel XY chcy mit moznost ZW

Answer 24

Navrhovy vzor pouzivanej v Serenity nastorji - nahrazuje klasicky POM tim, ze testy modeluje jako scenare slovnimi popisy podle sablony: actor - uzivatele, kteri provadi akce, klade otazky ability - schopnonosti uzivatelu, "muze prochaze web" task - ukoly vykonane actors, login interaction - konkretni akce, klidnuti, navigace, zadani textu v tasku Question - dotazy ktere akter poklada systemu Vyhody proto POM: - jeste lidstejsi, citelnejsi a jednodussi kod - testovani muzou napsat i netechnisti lidi - lepsi udrzitelnost Pise se pomoci scenaru: Scenario: Successful login GIVEN John is on the login page WHEN he logs in with valid credentials THEN he should see the welcome message Ktere se pak implmenutji pomoci nastroje Serenity, ktery definuje metody jako goals, definuje GIVEN, potom tasks (pokrocivle akce, ktere uzivatel podnikne k dosazeni goals) a action - co se ma provest Test metoda pomoci Serenity: @Test public void shouldBeAbleToLogIn() { Actor john = Actor.named("John").whoCan(BrowseTheWeb.with(hisBrowser)); givenThat(john).wasAbleTo( Open.url("http://example.com/login") ); when(john).attemptsTo( LogIn.withCredentials("user@example.com", "secret123") ); then(john).should( seeThat(TheWelcomeMessage.text(), equalTo("Welcome, John!")) ); } Pokrocilejsi techniky umi poskytovat i GUI BDD Serenity Report, ktery vykresli Story scenare, jeho popis na korky a provedni i vcetne screenshotu

Answer 25

Pomoci treba Postmana, pisu dotazy na web s query dat a porovnamvam navratove hodnoty s expected hodnotami

Answer 26

Situace, kdy testy nekdy projdou nekdy ne Signalizuje mozna velmi hlubokou chybu, kterou je slozite trasovat - jeden z nejhorsich typu chyb, protoze nevime, zda pred tim nam ji zachytavali nebo nemohlu - nelz selhani reprodukovat jednoduse - nahodne padaji testy - vysledky zavisi na dobe nebo poradi spusteni Priciny: - bud jsou zavisle na okoli - nejsou dost izolovane - nedostatenej wait na nacteni treba UI prvku (test kontroluje jeste nenactenou komponentu UI) - zavislsot na case a timeoutech site - sdileni stavu mezi testy - nestabilni michane prostredi Obence E2E testy jsou nestalejsi, pomalejsi a drazsi na vyrobu proto by mel byt zruha jeden E2E test na kazdy DULEZITY use-case, neni trba pro vsechny, procesni jsou postacujici - E2E muze pouzivat nastroje terich stran, ktere se kdykoliv mohou zmenit nebo zcela zmizet

TS Flashcards

(50 cards)