Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
Testování pomáhá zajistit, aby kód fungoval podle očekávání, ale čas a úsilí při vytváření testů odčerpává čas od jiných úloh, jako je například vývoj funkcí. S touto cenou je důležité extrahovat maximální hodnotu z testování. Tento článek popisuje principy testování DevOps, které se zaměřují na hodnotu testování jednotek a strategii testování posunu doleva.
Dedikovaní testeři psali většinu testů a mnoho vývojářů produktů se nenaučilo psát jednotkové testy. Psaní testů se může zdát příliš obtížné nebo příliš mnoho práce. Může existovat pochybnosti o tom, jestli strategie testování jednotek funguje, špatné zkušenosti s špatně napsanými testy jednotek, nebo se obáváte, že testy jednotek nahradí funkční testy.
Pokud chcete implementovat testovací strategii DevOps, buďte praktická a zaměřte se na budování dynamiky. I když můžete trvat na testech jednotek pro nový kód nebo existující kód, který lze čistě refaktorovat, může být vhodné, aby starší verze základu kódu umožňovala nějakou závislost. Pokud velké části kódu produktu používají SQL, což umožňuje testům jednotek využívat závislost na poskytovateli prostředků SQL místo napodobování této vrstvy, může být krátkodobý přístup k pokroku.
S tím, jak organizace DevOps zraly, je pro vedení snazší zlepšit procesy. I když může existovat určitý odpor ke změnám, agilní organizace hodnotí změny, které přinášejí jasné výnosy. Měli byste snadno prodat vizi rychlejších testovacích běhů s menším počtem selhání, protože znamená více času investovat do generování nové hodnoty prostřednictvím vývoje funkcí.
Taxonomie testů DevOps
Definování taxonomie testů je důležitým aspektem procesu testování DevOps. Taxonomie testů DevOps klasifikuje jednotlivé testy podle jejich závislostí a doby jejich spuštění. Vývojáři by měli rozumět správným typům testů, které se mají použít v různých scénářích a které testy vyžadují různé části procesu. Většina organizací kategorizuje testy napříč čtyřmi úrovněmi:
- Testy L0 a L1 jsou testy jednotek nebo testy, které závisí na kódu v sestavení v rámci testu a nic jiného. L0 je široká třída rychlých testů jednotek v paměti.
- L2 jsou funkční testy , které mohou vyžadovat sestavení a další závislosti, jako je SQL nebo systém souborů.
- Funkční testy L3 běží na testovatelných nasazeních služeb. Tato testovací kategorie vyžaduje nasazení služby, ale může použít stubs pro klíčové závislosti služby.
- Testy L4 jsou omezenou třídou integračních testů , které běží v produkčním prostředí. Testy L4 vyžadují úplné nasazení produktu.
I když by to bylo ideální pro všechny testy, aby běžely vždy, není to možné. Týmy můžou vybrat, kde se v procesu DevOps spustí každý test, a pomocí strategií posunu doleva nebo doprava posunete různé typy testů dříve nebo později v procesu.
Očekává se například, že vývojáři před potvrzením změn vždy provedou testy úrovně L2, pull request se automaticky nezdaří, pokud selže běh testů úrovně L3, a nasazení může být zablokováno, pokud selžou testy úrovně L4. Konkrétní pravidla se můžou lišit od organizace po organizaci, ale vynucování očekávání pro všechny týmy v organizaci přesune všechny směrem ke stejným cílům vize kvality.
Pokyny pro testování jednotek
Nastavte přísné pokyny pro testy jednotek L0 a L1. Tyto testy musí být velmi rychlé a spolehlivé. Například průměrný čas provedení pro test L0 v sestavení by měl být menší než 60 milisekund. Průměrná doba provádění pro jeden L1 test v systému by měla být kratší než 400 milisekund. Žádný test na této úrovni by neměl překročit 2 sekundy.
Jeden tým Microsoftu spouští paralelně 60 000 testů jednotek za méně než šest minut. Jejich cílem je zkrátit tuto dobu na méně než minutu. Tým sleduje dobu provádění testů jednotek pomocí nástrojů, jako je následující graf, a zaznamenává chyby proti testům, které překračují povolený čas.
Pokyny pro funkční testy
Funkční testy musí být nezávislé. Klíčovým konceptem testů L2 je izolace. Správně izolované testy se můžou spolehlivě spouštět v libovolné sekvenci, protože mají úplnou kontrolu nad prostředím, ve kterých běží. Stav musí být znám na začátku testu. Pokud jeden test vytvořil data a nechal je v databázi, mohl by poškodit spuštění jiného testu, který závisí na jiném stavu databáze.
Starší testy, které potřebují identitu uživatele, mohou volat externí poskytovatele ověřování pro získání identity. Tento postup představuje několik výzev. Externí závislost může být momentálně nespolehlivá nebo nedostupná, což způsobí přerušení testu. Tento postup také porušuje princip izolace testu, protože test může změnit stav identity, například oprávnění, což vede k neočekávanému výchozímu stavu pro jiné testy. Zvažte zabránění těmto problémům tím, že v rámci testovací architektury investujte do podpory identit.
Principy testování DevOps
Pokud chcete pomoct s přechodem testovacího portfolia na moderní procesy DevOps, představte si kvalitní vizi. Týmy by při definování a implementaci strategie testování DevOps měly dodržovat následující zásady testování.
Posunutí testování na začátek procesu
Testy mohou trvat dlouho. S tím, jak se projekty škálují, se čísla a typy testů výrazně zvětšují. Když testovací sady rostou tak, že trvají hodiny nebo dny, mohou se posunout až na poslední chvíli. Výhody testování na kvalitu kódu se projeví až dlouho poté, co byl kód potvrzen.
Dlouhotrvající testy můžou také způsobit selhání, která jsou časově náročná k prozkoumání. Týmy můžou vytvářet odolnost proti chybám, zejména v raných sprintech. Tato tolerance podkopává hodnotu testování jako přehled o kvalitě základu kódu. Dlouhotrvající testy na poslední chvíli také přinášejí nepředvídatelnost do očekávání na konci sprintu, protože kvůli odeslání kódu se musí vyrovnat neznámé množství technického dluhu.
Cílem posunu testování doleva je přesunout kvalitu směrem nahoru, a to provedením testovacích úloh dříve v kanálu. Kombinace vylepšení testů a procesů zkracuje posun doleva jak čas potřebný ke spuštění testů, tak dopad selhání později v cyklu. Posun doleva zajišťuje, že se většina testování dokončí před sloučením změn do hlavní větve.
Kromě posunu některých zodpovědností za testování doleva ke zlepšení kvality kódu můžou týmy posunout další testovací aspekty doprava nebo později v cyklu DevOps, aby zlepšily konečný produkt. Další informace najdete v tématu Shift-right testing v produkčním prostředí.
Psaní testů na nejnižší možné úrovni
Napište více jednotkových testů. Upřednostňování testů s nejmenšími externími závislostmi a zaměřte se na spouštění většiny testů v rámci sestavení. Zvažte paralelní systém sestavení, který může spouštět jednotkové testy pro sestavení ihned poté, co jsou sestavení a související testy k dispozici. Není možné testovat všechny aspekty služby na této úrovni, ale principem je použití lehčích testů jednotek, pokud mohou produkovat stejné výsledky jako těžší funkční testy.
Cílem je spolehlivost testů
Nespolehlivý test je organizačně nákladný na údržbu. Takový test funguje přímo proti cíli technické efektivity tím, že ztěžuje provádění změn s jistotou. Vývojáři by měli být schopni provádět změny kdekoli a rychle získat jistotu, že nic nebylo přerušeno. Udržujte vysokou laťku pro spolehlivost. Nedoporučujeme používat testy uživatelského rozhraní, protože jsou obvykle nespolehlivé.
Psaní funkčních testů, které se dají spustit kdekoli
Testy můžou používat specializované integrační body navržené speciálně k povolení testování. Jedním z důvodů této praxe je nedostatek testovatelnosti samotného produktu. Podobné testy bohužel často závisejí na interních znalostech a používají podrobnosti implementace, které z hlediska funkčního testu nezáleží. Tyto testy jsou omezené na prostředí, která mají tajné kódy a konfiguraci potřebné ke spuštění testů, což obecně vylučuje produkční nasazení. Funkční testy by měly používat pouze veřejné rozhraní API produktu.
Navrhování produktů pro testovatelnost
Organizace v procesu vyzrávání DevOps mají úplný přehled o tom, co znamená dodávat kvalitní produkt v rytmu cloudu. Posun rovnováhy silně ve prospěch testování jednotek oproti funkčnímu testování vyžaduje, aby týmy udělaly volby návrhu a implementace, které podporují testovatelnost. Existují různé myšlenky na to, co představuje dobře navržený a dobře implementovaný kód pro testovatelnost, stejně jako existují různé styly kódování. Principem je, že návrh pro testovatelnost musí být primární součástí diskuze o kvalitě návrhu a kódu.
Zacházení s testovacím kódem jako kódem produktu
Explicitně hlásí, že testovací kód je kód produktu, aby bylo jasné, že kvalita testovacího kódu je stejně důležitá pro expedici jako kód produktu. Týmy by měly zacházet s testovacím kódem stejným způsobem jako s kódem produktu a používat stejnou úroveň péče na návrh a implementaci testů a testovacích architektur. Toto úsilí se podobá správě konfigurace a infrastruktury jako kódu. Aby byla kontrola kódu kompletní, měla by zahrnovat testovací kód a držet ho na stejném standardu kvality jako kód produktu.
Použití sdílené testovací infrastruktury
Snižte laťku pro použití testovací infrastruktury k generování spolehlivých signálů kvality. Zobrazení testování jako sdílené služby pro celý tým Uložte kód jednotkových testů společně s kódem produktu a sestavte jej společně s produktem. Testy, které se spouští jako součást procesu sestavení, musí běžet také v rámci vývojových nástrojů, jako je Azure DevOps. Pokud se testy můžou spouštět v každém prostředí z místního vývoje prostřednictvím produkčního prostředí, mají stejnou spolehlivost jako kód produktu.
Nastavení vlastníků kódu zodpovědných za testování
Testovací kód by se měl nacházet vedle kódu produktu v úložišti. Aby byl kód testován na hranici komponenty, přenáší odpovědnost týkající se testování na osobu, která kód komponenty píše. Nespoléhejte na ostatní, kteří komponentu testují.
Případová studie: Posun doleva s testy jednotek
Tým Microsoftu se rozhodl nahradit starší testovací sady moderními testy jednotek DevOps a procesem posunu doleva. Tým sledoval průběh napříč týdenními sprinty, jak je znázorněno v následujícím grafu. Graf popisuje sprinty 78–120, které představují 42 sprintů za 126 týdnů nebo přibližně dva a půl roku úsilí.
Tým začal v 27K starších testech ve sprintu 78 a dosáhl nulového počtu starších testů na S120. Sada testů jednotek L0 a L1 nahradila většinu starých funkčních testů. Nové testy L2 nahradily některé testy a mnoho starých testů bylo odstraněno.
Na cestě k softwaru, která trvá více než dva roky, se od samotného procesu hodně naučíte. Celkově bylo úsilí o kompletní přepracování testovacího systému během dvou let masivní investicí. Ne všechny týmy funkcí pracovaly současně. Mnoho týmů v celé organizaci investovalo čas do každého sprintu a v některých sprintech to byla většina toho, co tým udělal. I když je obtížné měřit náklady na směnu, jednalo se o neopomenutelný požadavek na kvalitu a výkonnostní cíle týmu.
Začínáme
Na začátku tým nechal staré funkční testy, označované jako testy TRA, bez zásahu. Tým chtěl, aby vývojáři přijali myšlenku psaní jednotkových testů, zejména pro nové funkce. Zaměření bylo na to, aby bylo co nejjednodušší vytvářet testy L0 a L1. Tým nejdříve musel vyvinout tuto schopnost a získat dynamiku.
Předchozí graf zobrazuje počet jednotkových testů, který se začíná brzy zvyšovat, protože tým si uvědomil výhody psaní jednotkových testů. Jednotkové testy byly snazší udržovat, spouštěly se rychleji a měly méně selhání. Bylo snadné získat podporu pro spuštění všech jednotkových testů v rámci pull requestu.
Tým se nezaměřil na psaní nových testů L2 až do sprintu 101. Mezitím se počet testů TRA zpomalil z 27 000 na 14 000 z Sprintu 78 na Sprint 101. Nové testy jednotek nahradily některé testy TRA, ale mnohé byly jednoduše odstraněny na základě týmové analýzy jejich užitečnosti.
Testy TRA se v sprintu 110 zvýšily z 2100 na 3800, protože ve zdrojovém stromu byly objeveny další testy a následně přidány do grafu. Ukázalo se, že testy byly vždy spuštěné, ale nebyly sledovány správně. To nebyla krize, ale bylo důležité být upřímní a podle potřeby znovu posoudit.
Rychlejší
Jakmile měl tým signál kontinuální integrace (CI), který byl extrémně rychlý a spolehlivý, stal se důvěryhodným indikátorem pro kvalitu produktu. Následující snímek obrazovky ukazuje žádost o přijetí změn a kanál CI v akci a čas potřebný k procházení různých fází.
Sloučení pull requestu trvá přibližně 30 minut, což zahrnuje spuštění 60 000 jednotkových testů. Od sloučení kódu do sestavení CI je přibližně 22 minut. První signál kvality z CI, SelfTest, přichází asi po hodině. Pak se většina produktu testuje s navrženou změnou. Během dvou hodin od „Merge to SelfHost“ se testuje celý produkt a změna je připravená k nasazení do produkčního prostředí.
Použití metrik
Tým sleduje přehled výkonnostních metrik jako v následujícím příkladu. Na vysoké úrovni výkonnostní tabulka sleduje dva typy metrik: zdraví a dluh a tempo.
V případě metrik zdraví živého webu tým sleduje čas na zjištění, čas na zmírnění a kolik položek k opravě tým nese. Položka opravy je práce, kterou tým identifikuje během retrospektivy živého prostředí, aby se zabránilo opakování podobných událostí. Přehled výkonnostních metrik také sleduje, jestli týmy zavírají položky oprav v přiměřeném časovém rámci.
Pro metriky zdraví inženýrství tým sleduje aktivní bugy na vývojáře. Pokud má tým více než pět chyb na vývojáře, musí tým určit prioritu opravy těchto chyb před vývojem nových funkcí. Tým také sleduje staré chyby ve speciálních kategoriích, jako je bezpečnost.
Metriky rychlosti přípravy měří rychlost v různých částech kanálu kontinuální integrace a průběžného doručování (CI/CD). Celkovým cílem je zvýšit rychlost kanálu DevOps: Od nápadu, získání kódu do produkčního prostředí a příjem dat od zákazníků.