Co je automatizované testování?
V této lekci se dozvíte o výhodách automatizovaného testování a o typech testování, které můžete provést. Dozvíte se také, co je dobrým testem a seznámíte se s některými testovacími nástroji, které jsou pro vás k dispozici.
Co je automatizované testování?
Automatizované testování používá software ke spouštění kódu a porovnávání skutečných výsledků s očekávanými výsledky. Můžeš to porovnat s nahodilým nebo manuálním testováním, kdy nějaký člověk obvykle postupuje podle pokynů v testovacím plánu a ověřuje, že software funguje podle očekávání.
Manuální testování má svoje výhody. Jak ale roste velikost základu kódu, může se manuální testování všech funkcí stát repetitivním, zdlouhavým a náchylným k chybám. Automatizované testování může pomoct eliminovat některé z těchto zátěží a umožnit ručním testerům zaměřit se na to, co dělají nejlépe: zajistit, aby vaši uživatelé měli pozitivní zkušenosti s vaším softwarem.
Pyramida testování
Když uvažujeme o automatizovaném testování, je běžné oddělit testy do vrstev. Mike Cohn navrhuje tento koncept – označovaný jako pyramida testování – ve své knize Succeeding with Agile.
I když se jedná o zjednodušenou verzi modelu Cohn, koncept ukazuje, že se nejvíce zaměřujete na psaní testů, které ověřují základní úrovně vašeho softwaru (bublinový popisek 1 v pyramidě), jako jsou funkce, třídy a metody. Postupně se zaměřujete na menší úsilí, protože se kombinují funkce, jako je vrstva uživatelského rozhraní (UI) (bublinový popisek 2 v pyramidě). Myšlenka spočívá v tom, že pokud můžete ověřit, že každá komponenta nižší úrovně funguje podle očekávání v izolaci, testy na vyšších úrovních potřebují pouze ověřit, že několik komponent spolupracuje, aby získaly očekávaný výsledek.
Kdy bychom měli psát testy?
Odpověď závisí hlavně na vašich potřebách a na zkušenostech se psaním testů.
Nikdy není příliš pozdě na to, abyste začali přidávat testy kódu, který jste už napsali a nasadili. To platí zejména pro funkce, u kterých dochází často k chybám nebo které vyžadují většinu úsilí testovacího týmu.
Pokud souvisíte s testováním s průběžnou integrací a kanály průběžného doručování, uslyšíte dva koncepty, o které se dozvíte, že průběžné testování a přesouvání doleva.
Průběžné testování znamená, že testy se spouští v rané fázi procesu vývoje, protože každá změna prochází kanálem. Posun doleva znamená zvažování kvality softwaru a testování v dřívější fázi procesu vývoje.
Vývojáři například často při vývoji funkce přidávají testovací případy a před odesláním změny do kanálu spouštějí celou sadu testů. Tento přístup pomáhá zajistit, aby se funkce, kterou sestavují, chovala očekávaným způsobem a nenarušovala stávající funkce.
Tady je krátké video, kde Abel Wang, poradce pro cloud v Microsoftu, vysvětluje, jak zajistit zachování kvality v plánu DevOps.
Zeptejte se Abela
Posun doleva často vyžaduje, aby se testeři zapojili do procesu návrhu, a to i před napsáním jakéhokoli kódu funkce. Porovnejte ho s modelem "předání", kde se testovací tým prezentuje s novými funkcemi pro testování až po navržení a napsání softwaru. Chyba zjištěná pozdě v procesu může ovlivnit plán doručení týmu a chyby můžou být zjištěny týdny nebo dokonce měsíce poté, co vývojář původně funkci vytvořil.
Kompromis
S automatizovaným testováním existuje kompromis. I když automatizované testování umožňuje testerům zaměřit svůj čas na ověření prostředí koncového uživatele, vývojáři mohou potřebovat věnovat více času psaní a údržbě testovacího kódu.
Cílem automatizovaného testování je ale zajistit, aby testeři dostávali pouze kód nejvyšší kvality, který byl prokázáno, že funguje podle očekávání. Vývojáři proto můžou část času uvolnit tím, že musí zpracovat méně chyb nebo se vyhnout přepsání kódu kvůli hraničnímu případu, který původně nepovažovali.
Další přidané výhody
Dokumentace a možnost refaktorovat kód snadněji jsou dvěma přidanou výhodou automatizovaného testování.
Dokumentace
Manuální testovací plány můžou sloužit jako určitý typ dokumentace, která popisuje, jak by se měl software chovat a proč existují určité funkce.
Automatizované testy můžou sloužit ke stejnému účelu. Kód automatizovaných testů často používá formát, který můžou číst lidé. Sada zadaných vstupů představuje hodnoty, které mohou uživatelé zadat. Každý přidružený výstup určuje výsledek, který by uživatelé měli očekávat.
Ve skutečnosti mnoho vývojářů sleduje metodu TDD (testem řízený vývoj ) napsáním testovacího kódu před implementací nové funkce. Myšlenka je taková, že se napíše sada testů, často označovaných jako specifikace, které na začátku selžou. Vývojář pak postupně píše kód pro implementaci příslušné funkce, dokud nejsou všechny testy úspěšné. Nejen, že specifikace dokumentují požadavky, ale proces vývoje řízeného testy pomáhá zajistit, že pro implementaci funkce se napíše jen nezbytné množství kódu.
Refaktoring
Řekněme, že máte rozsáhlý základ kódu, který chcete refaktorovat, aby určité části běžely rychleji. Jak víte, že vaše úsilí věnované refaktoringu nezpůsobí, že u některých částí vaší aplikace bude docházet k chybám?
Automatizované testy slouží jako typ kontraktu. To znamená, že zadáte vstupy a očekávané výsledky. Když máte sadu úspěšných testů, můžete lépe experimentovat a refaktorovat svůj kód. Když provedete nějakou změnu, potřebujete pouze spustit tyto testy a ověřit, že jsou nadále úspěšné. Jakmile splníte cíle refaktoringu, můžete odeslat změnu do kanálu buildu, aby mohli všichni těžit, ale s nižším rizikem, že se něco zlomí.
Jaké typy automatizovaného testování existují?
Existuje mnoho typů automatizovaného testování. Každý test slouží k samostatnému účelu. Můžete například spouštět testy zabezpečení, které vám pomůžou ověřit, že k určitému softwaru nebo jedné z jeho funkcí mají přístup pouze autorizovaní uživatelé.
Když zmíníme kontinuální integraci a kanál buildu, obvykle odkazujeme na vývojové testování. Testování během vývoje odkazuje na testy, které můžete spouštět před nasazením aplikace do testovacího nebo produkčního prostředí.
Například lint testing, forma statické analýzy kódu, zkontroluje zdrojový kód a určí, jestli vyhovuje průvodci stylem vašeho týmu. Kód, který je formátovaný konzistentně, je pro každého jednodušší číst a udržovat.
V tomto modulu budete pracovat s testováním částí a testováním pokrytí kódu.
Testování jednotek ověřuje nejzákladnější součásti vašeho programu nebo knihovny, například jednotlivé funkce nebo metody. Určíte jeden nebo více vstupů spolu s očekávanými výsledky. Spouštěč testů provádí každý test a kontroluje, jestli se skutečné a očekávané výsledky shodují.
Řekněme například, že máte funkci, která provádí aritmetickou operaci, která zahrnuje dělení. Můžete zadat několik hodnot, které očekáváte, že uživatelé zadají spolu s hodnotami hran, jako jsou 0 a -1. Pokud určitý vstup způsobí chybu nebo výjimku, můžete ověřit, že funkce vytvoří stejnou chybu.
Testování pokrytí kódu vypočítá procento kódu kódu, na který se vztahuje testy jednotek. Testování pokrytí kódu může obsahovat podmíněné větve v kódu, aby se zajistilo, že je funkce pokryta.
Čím větší je procento pokrytí vašeho kódu, o to větší můžete mít jistotu, že později neobjevíte chybu v kódu, který nebyl plně otestován. Nemusíte dosahovat 100% pokrytí kódu. Když začnete, pravděpodobně zjistíte, že máte nízké procento, ale to vám dává výchozí bod, ze kterého můžete přidat další testy, které pokrývají problematické nebo často používané kódy.
Udržování testů jednotek izolovaně
Když se seznámíte s testováním jednotek, uslyšíte termíny, jako jsou napodobení, zástupné procedury a injektáž závislostí.
Vzpomeňte si, že test jednotek by měl ověřit jednotlivé funkce nebo metodu, a ne způsob interakce s více komponentami. Ale pokud máte funkci, která volá databázi nebo webový server, jak to zvládnete?
Nejen, že volání externí služby přeruší izolaci, ale může to zpomalit. Pokud dojde k výpadku databáze nebo webového serveru nebo je jinak nedostupný, může volání také narušit testovací běh.
Pomocí technik, jako je napodobení a injektáž závislostí, můžete vytvořit komponenty, které napodobují tuto externí funkci. Příklad získáte později v tomto modulu.
Později pak můžete spustit testy integrace a ověřit, že vaše aplikace funguje správně se skutečnou databází nebo webovým serverem.
Jak má vypadat dobrý test?
Budete lépe schopni identifikovat dobrý test, když získáte zkušenosti s psaním vlastních testů a čtením testů, které napsali jiní uživatelé. Tady je několik pokynů pro začátek:
- Neprovádějte testování kvůli testování: Testy by měly sloužit k účelu, než je položka kontrolního seznamu, která se má přeškrtnout. Napište testy, které ověřují, že váš kritický kód funguje tak, jak má, a neruší stávající funkce.
- Udržujte testy krátké: Testy by se měly dokončit co nejrychleji, zejména ty, ke kterým dochází během fází vývoje a sestavení. Když se testy spustí, když se každá změna prochází kanálem, nechcete, aby byly kritickým bodem.
- Ujistěte se, že testy jsou opakovatelné: Testovací běhy by měly pokaždé vytvářet stejné výsledky, ať už je spouštíte na počítači, v počítači spolupracovníka nebo v kanálu buildu.
- Zaměřte se na testy: Běžným omylem je, že testy jsou určené k pokrytí kódu napsaného jinými uživateli. Testy by se obvykle měly týkat jenom vašeho kódu. Pokud ve svém projektu používáte například opensourcovou grafickou knihovnu, nemusíte tuto knihovnu testovat.
- Zvolte správnou členitost: Pokud například provádíte testování jednotek, neměl by jednotlivý test kombinovat nebo testovat více funkcí nebo metod. Testujte každou funkci samostatně a později napište testy integrace, pomocí kterých ověříte, že více součástí funguje správně společně.
Jaké typy testovacích nástrojů jsou k dispozici?
Používané testovací nástroje závisí na typu aplikace, kterou vytváříte, a na typu testování, které chcete provést. Selenium můžete například použít k testování uživatelského rozhraní na mnoha typech webových prohlížečů a operačních systémů.
Bez ohledu na jazyk, ve kterém je vaše aplikace napsaná, máte k dispozici mnoho testovacích nástrojů.
Například u aplikací v jazyce Java můžete zvolit Checkstyle pro testování typu lint a JUnit pro testování jednotek.
V tomto modulu použijeme NUnit pro testování jednotek, protože je oblíbená v komunitě .NET.