Testujeme software Testujeme software
  • Úvod
  • Blog
  • Nástroje
  • Slovníček
Testujeme software Testujeme software
Testujeme software Testujeme software
  • Úvod
  • Blog
  • Nástroje
  • Slovníček
  • Blog

Automatické testy z pohledu vývojáře

  • 3. 10. 2022
  • Jan Zatloukal
Total
0
Shares
0
0
0

Výhody automatického testování zřejmě není potřeba vysvětlovat. Pro testery znamenají zrychlení a usnadnění práce a díky nim se můžeme více soustředit na manuální testy. Jak se ale na automatické testování dívají vývojáři?

Výhody automatického testování

Sebevědomí

Vývoj software není jen o přidávání nových funkcí nebo opravě chyb. Pokud chceme, aby byl projekt stále životaschopný, musíme občas provést “úklid”, refaktorovat nebo aktualizovat používané knihovny. To s sebou ale nese také potřebu celý produkt kompletně přetestovat. To může znamenat přípravu nových test casů, určení rozsahu testování. Musíme přemýšlet o tom, co všechno bylo změněno a co mohlo být změnou ovlivněno. Potřebujeme si na testování vyhradit čas. Tím se ale zvyšuje riziko, že něco přehlédneme nebo vynecháme – prostě proto, že nám to nepřijde důležité, nebo že na testování máme jen omezenou dobu. Při častějších změnách se také může snížit pravděpodobnost, že se testování někdo vůbec bude věnovat.

Automatické testování nám dává sebevědomí dělat jakékoli změny. Díky automatizaci se nemusíme bát změn, protože je můžeme v podstatě okamžitě otestovat. Můžeme projekt zlepšovat, na více úrovních a vždy máme přehled o tom, jaké měly změny vliv. Bez vylepšování by projekt brzy začal “hnít”.

Náklady

Manuální i automatické testování samozřejmě stojí peníze. I když se může investice do automatizace zdát vysoká, její návratnost je v podstatě okamžitá. S minimálními náklady pak můžeme přidávat další testy, nebo upravovat stávající. Automatizace pomáhá snižovat náklady a drahocenný čas potom můžeme věnovat podrobnějšímu manuálnímu testování.

Škálovatelnost

Nespornou výhodou je i škálovatelnost. Pokud produkt testujeme na více podporovaných systémech a chceme přidat podporu pro další, víme okamžitě, jak na tom jsme. Při ručním testování by to znamenalo spousty repetitivní práce. Automatické testy můžeme spustit na (v podstatě) neomezeném množství konfigurací.

Spolehlivost automatických testů

U automatických testů musíme počítat s tím, že jsou spolehlivé tak, jako je nejméně spolehlivá komponenta v testovacím řetězci. Testy musí být deterministické a náhoda zde nemůže hrát roli. Pokud je nějaký test náhodně vyhodnocován jako chybný, roste pravděpodobnost, že se tak stane s počtem spouštěných testů.

Při vytváření automatických testů je tedy potřeba mít dobré znalosti testovacího systému, vstupních parametrů a konfigurací. Testy by na sobě neměly být závislé a nemělo by záležet na jejich pořadí. Testy by také neměly mít vedlejší efekty, na začátku by mělo být test definovat všechny potřebné prerekvizity a na konci systém vrátit do původního stavu. Větší množství malých a nezávislých testů nám dává větší variabilitu.

Kdy začít s automatizací

Nejlepší je začít ihned. “Jakmile to něco dělá, mělo by to být otestované.” Když chceme začít s automatickými testy, je potřeba navrhnout infrastrukturu, strategii a to se nejlépe dělá na začátku projektu společně s plánováním ostatních věci. Pokud už projekt běží, přidává se automatizace hůře.

Kdy psát testy

Připravit nejdříve logiku a potom až testy? To záleží na preferencích vývojáře, nastavení projektu nebo použité technologii. Pořadí je méně důležité, vždy je potřeba myslet na oboje. Někdy je dobré iterovat – při přidávání logiky přemýšlet o tom, jak se bude daná věc testovat. Následně napsat testy a opět se vrátit k logice. A toto opakovat, než jsme s výsledkem spokojení.

Jak často testy spouštět

Ideálně (automaticky) po každém sestavení projektu (buildu). Vývojář si také testy může spustit ručně po každé změně, které by mohla něco ovlivnit. Důležité je tedy, aby testy byly snadno spustitelné a trvaly přiměřeně dlouhou dobu. Vhodné je mít testy rozdělené do více vrstev tak, aby bylo možné si spustit například jen část z nich.

Pokrytí a prioritizace

Honba za 100% pokrytí kódu testy může přinést potíže při refaktoringu – testy mohouzhoršovat možnost  systém refaktorovat zevnitř. Velké množství testů může být problém sám o sobě i z toho důvodu, že testy prostě trvají dlouhou dobu. Také to zvyšuje nároky na potřebnou údržbu. Při návrhu testů tedy musíme počítat s prioritizací pokrytí: veřejná rozhraní aplikace, funkcionalita důležití pro business, to jsou místa, které by případné bugy měly velký dopad.

Vyhodnocování automatických testů

Některé testy můžou ve výsledcích “svítit červeně”, to ale nemusí nutně znamenat chybu nebo nemožnost vydání produktu. Některé můžou být známe bugy, někde můžeme například čekat na opravu třetí strany. Je důležité ale vědět, proč tyto testy neprochází. U každého takového testu bychom měli mít možnost přidat poznámku s odůvodněním. Před vydáním verze by samozřejmě takové testy neměly být nebo by jejich množství mělo být minimální. Interpretace výsledků by tak měla být jasná a měli bychom si vystačit s klasickým passed/failed.

Total
0
Shares
Sdílet 0
Tweetnout 0
Sdílet 0
Související témata
  • Automatizace
Jan Zatloukal

Tester a vývojář se zálibou v automatizaci a zlepšování procesu vývoje. Aktuálně pracuji na projektu automatizace elektronových mikroskopů v Pythonu.

Předchozí článek
  • Blog

Na dvou židlích aneb (ne)výhody testování na dvou projektech

  • 1. 10. 2022
  • Jan Zatloukal
Zobrazit článek
Další článek
  • Blog

Prezentace výsledků testování v Streamlit – 1. díl – tabulky

  • 3. 10. 2022
  • Jan Zatloukal
Zobrazit článek
Mohlo by se vám také líbit
Zobrazit článek
  • Blog

Automatické spouštění testů během buildu v GitLabu

  • Aleš Tichý
  • 1. 6. 2023
Zobrazit článek
  • Blog

Automatizované testování Windows aplikací s Robot Frameworkem a RPA.Windows 

  • Jan Zatloukal
  • 18. 5. 2023
Zobrazit článek
  • Blog

Perfomance monitoring pomocí Telegrafu a Grafany (1. díl)

  • Radek Vavřín
  • 4. 5. 2023
Zobrazit článek
  • Blog

Jak nastartovat projekt v Pythonu

  • Jan Zatloukal
  • 6. 4. 2023
Zobrazit článek
  • Blog

Přes noc testerkou – Lucka Korená

  • Lucie Korená
  • 23. 3. 2023
Zobrazit článek
  • Blog

Jak jsem automatizoval testy, až mě to přestalo bavit – cesta k TestComplete

  • Štěpán Černoch
  • 9. 3. 2023
Zobrazit článek
  • Blog

Software testing očima nováčka, díl I.

  • Vojtěch Camfrla
  • 24. 2. 2023
Zobrazit článek
  • Blog

Git pro testery – nastavení a první krůčky

  • Jan Zatloukal
  • 9. 2. 2023

Napsat komentář Zrušit odpověď na komentář

Vaše e-mailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *

Doporučené příspěvky
  • 1
    Automatické spouštění testů během buildu v GitLabu
    • 1. 6. 2023
  • 2
    Automatizované testování Windows aplikací s Robot Frameworkem a RPA.Windows 
    • 18. 5. 2023
  • 3
    Perfomance monitoring pomocí Telegrafu a Grafany (1. díl)
    • 4. 5. 2023
  • 4
    Jak nastartovat projekt v Pythonu
    • 6. 4. 2023
  • 5
    Přes noc testerkou – Lucka Korená
    • 23. 3. 2023
Poslední příspěvky
  • Jak jsem automatizoval testy, až mě to přestalo bavit – cesta k TestComplete
    • 9. 3. 2023
  • Software testing očima nováčka, díl I.
    • 24. 2. 2023
  • Git pro testery – nastavení a první krůčky
    • 9. 2. 2023
Rubriky
  • Blog (20)
Testujeme software Testujeme software
  • Edhouse.cz
  • Vyšíváme software
  • Zásady cookies (EU)
Testujeme software – vše o testování software | Všechna práva vyhrazena © 2022

Zadejte klíčové slovo a stiskněte Enter.

Spravovat Souhlas s cookies
Abychom poskytli co nejlepší služby, používáme k ukládání a/nebo přístupu k informacím o zařízení, technologie jako jsou soubory cookies. Souhlas s těmito technologiemi nám umožní zpracovávat údaje, jako je chování při procházení nebo jedinečná ID na tomto webu. Nesouhlas nebo odvolání souhlasu může nepříznivě ovlivnit určité vlastnosti a funkce.
Funkční Vždy aktivní
Technické uložení nebo přístup je nezbytně nutný pro legitimní účel umožnění použití konkrétní služby, kterou si odběratel nebo uživatel výslovně vyžádal, nebo pouze za účelem provedení přenosu sdělení prostřednictvím sítě elektronických komunikací.
Předvolby
Technické uložení nebo přístup je nezbytný pro legitimní účel ukládání preferencí, které nejsou požadovány odběratelem nebo uživatelem.
Statistické
Technické uložení nebo přístup, který se používá výhradně pro statistické účely. Technické uložení nebo přístup, který se používá výhradně pro anonymní statistické účely. Bez předvolání, dobrovolného plnění ze strany vašeho Poskytovatele internetových služeb nebo dalších záznamů od třetí strany nelze informace, uložené nebo získané pouze pro tento účel, obvykle použít k vaší identifikaci.
Marketingové
Technické uložení nebo přístup je nutný k vytvoření uživatelských profilů za účelem zasílání reklamy nebo sledování uživatele na webových stránkách nebo několika webových stránkách pro podobné marketingové účely.
Spravovat možnosti Spravovat služby Spravovat dodavatele Přečtěte si více o těchto účelech
Zobrazit předvolby
{title} {title} {title}