Strategie architektury pro testování

Platí pro toto doporučení kontrolního seznamu provozní efektivity architektury Azure Well-Architected Framework:

OE:09	Vylepšete kvalitu úloh přijetím testovacích postupů, které jsou v souladu s obchodními cíli a dodržují standardy kvality.

Při zavádění změny úloh musíte zajistit, aby fungovala podle očekávání a nezavedá nové problémy. Testování je způsob vyhodnocení těchto změn. Je to základní postup pro zachování kvality a budování důvěry v vaše úlohy.

Efektivní testování poskytuje spolehlivou a vysoce kvalitní úlohu. Zabraňuje vadám, aby se dostaly do výroby, snižuje nákladné opravy a zpoždění a zajišťuje, že vaše práce je v souladu s obchodními cíli po celou dobu životního cyklu vývoje.

Tento článek obsahuje strategie, které vám pomůžou poskytovat vysoce kvalitní úlohy prostřednictvím efektivních testovacích postupů. Slouží jako základní pokyny pro specializované testovací pokyny v jiných pilířích, jako je výkon, spolehlivost a zabezpečení.

Formalizace testovací strategie a plánu

Základní artefakty jsou vaše testovací strategie a testovací plány. Poskytují jasný plán pro vaše úsilí o testování a zajistí, aby všichni pracovali na stejných cílech kvality.

Definování testovací strategie

Vaše testovací strategie je podrobný plán vysoké úrovně, který vás provede celkovým přístupem k testování. Definuje vaše testovací cíle, rozsah, metodologie, nástroje, role a zodpovědnosti. Pomáhá provádět informovaná rozhodnutí o prioritách testování, přidělování prostředků a správě rizik. Zachytí také způsob komunikace se zúčastněnými stranami a vykazování výsledků.

Dobře definovaná testovací strategie získá podporu od zainteresovaných stran a zajistí, že všichni členové týmu budou dodržovat konzistentní standardy kvality. Poskytuje směr a strukturu, zarovná testování s obchodními cíli a chrání dlouhodobou kvalitu.

Vaše testovací strategie obecně zůstává konzistentní napříč verzemi pro danou úlohu. Vždy ho ale přizpůsobte tak, aby odrážel konkrétní potřeby a obchodní cíle dané úlohy.

Poznámka:

Nepoužívejte stejnou standardizovanou strategii pro různé úlohy. Mají jedinečné aspekty, které vyžadují jedinečné přístupy.

Vytvoření plánu

Jakmile s týmem souhlasíte s testovací strategií, formalizujte ji v testovacím plánu s případy použití v souladu s obchodními cíli.

Testovací plán je podrobný dokument, který vás provede testováním provádění pro konkrétní verzi. Popisuje rozsah testování, konkrétní testovací případy, hlášení chyb, harmonogramy, přiřazení zdrojů a kritéria vstupu a ukončení pro testovací aktivity.

Dobře strukturovaný testovací plán umožňuje efektivní testování a sladění s cíli a časovými osami vydané verze. Je to váš referenční bod pro sledování průběhu a provádění informovaných rozhodnutí během testování.

Příklad: Pro systém pokladny elektronického obchodování vytváří testovací strategie konzistentní přístup napříč všemi verzemi. Definuje, že platební toky jsou vždy upřednostňovány, určuje testovací nástroje pro systém, jako je Selenium pro testování uživatelského rozhraní, JMeter pro zátěžové testování a OWASP ZAP pro testování zabezpečení, a objasňuje týmové odpovědnosti za různé typy testů. Testovací plán verze v2.5 se zaměřuje na přidání podpory Apple Pay. Definuje přesně, co se má v této verzi testovat pro Apple Pay, přiděluje prostředky (dva technici a tři zařízení s iOSem), nastaví čtyřtýdenní plán a vytvoří jasná vstupní kritéria (nakonfigurovaná kódem a prostředím) a kritéria ukončení (všechny testy projdou, nula kritických chyb a dvousekundová smlouva SLA).

Poznámka:

Než jasně definujete celkovou testovací strategii a plán, nezahajte testování. Pevný testovací plán udržuje vaše úsilí zaměřené a sladěné s cíli úloh.

Testování v rané fázi, testování často, testování toho, co je důležité

Začněte testovat v nejstarších fázích životního cyklu vývoje softwaru. Když narazíte na kritické problémy pozdě, čelíte zvýšenému přepracování a pomalejším verzím. Architekti příliš často přehlédnou požadavky na testování ve fázi návrhu, což negativně ovlivňuje celkovou kvalitu.

Vývojáři by si měli osvojit přístup k zajištění kvality. Zamyslete se nad testováním i během návrhu. Použijte ho k objasnění požadavků a k odhalení potenciálních omezení. Testování je nedílnou součástí procesu vývoje. Přejměte odpovědnost za psaní a údržbu testů spolu se svým kódem.

Když včas zjistíte problémy, můžete rychle reagovat. Můžete například určit prioritu zásadních změn návrhu, které mají vliv na uživatelské prostředí, než běžné opravy chyb. Jednání včas snižuje překvapení a zpoždění na poslední chvíli.

Testování není jednorázová událost. Pokračujte v testování po spuštění jako součást nepřetržitého testovacího přístupu. Pravidelně kontrolujte, aktualizujte a rozšiřte testovací sadu, abyste se mohli zabývat novými funkcemi a řešit chyby zjištěné v produkčním prostředí, aby se zachovala dlouhodobá kvalita.

Poznámka:

Neodkládejte testování ve velkých dávkách až na pozdní fáze doručovacího cyklu. Zpoždění testů vede ke zmeškaným problémům, zvýšenému přepracování a pomalejším verzím.

Kompromis. Včasné a průběžné testování může zvýšit provozní náklady a může zpočátku zpomalit vývoj nebo vytvořit týmové tření. Vytvořte rovnováhu, určete, které testy a změny jsou nezbytné v rané fázi a které můžete odložit na pozdější fáze. To zajišťuje efektivitu bez ohrožení kvality.

Testování v produkčním prostředí pomocí ochranných opatření

I v případě silného testování a ověřovacích postupů se některé problémy zobrazují pouze v reálném provozním provozu. Pokud chcete najít problémy, které nemůžete simulovat, proveďte řízené testování v produkčním prostředí s bezpečnostními prvky, které omezují vystavení uživatelům a snižují riziko.

Plánování, izolace a monitorování produkčního testování Díky tomu můžete shromáždit skutečnou zpětnou vazbu uživatelů a data o výkonu a zároveň minimalizovat přerušení širší uživatelské základny.

Zvažte progresivní strategie nasazení, jako jsou kanárková nasazení, až když vaše úloha splňuje kritéria výjezdu a vykazuje silnou kvalitu. Tento přístup vydává aktualizace malé cílové skupiny uživatelů jako první, což vám pomůže rychle odhalit problémy, které se nemusí objevit v předprodejních prostředích. Díky tomuto přístupu urychlíte proces testování a potenciálně snížíte související náklady.

Riziko: Při testování v produkčním prostředí buďte opatrní, protože přímo ovlivňuje skutečné zákazníky. Vždy implementujte ochranu a omezte vystavení, abyste minimalizovali potenciální negativní dopady na vaši firmu.

Použití vícevrstvého přístupu v pokrytí testů

Strategie vrstveného pokrytí testů vám poskytne rychlou zpětnou vazbu, dřívější detekci vad a rychlejší vydání. Při strukturování testů ve vrstvách můžete rychle izolovat a ladit vady, což usnadňuje určení a řešení problémů.

Použití testovací pyramidy jako vodítka

Model testovací pyramidy znázorňuje tento vícevrstvý přístup pro automatizaci testů. Distribuuje testy mezi různé vrstvy, aby se maximalizovalo pokrytí a minimalizovaly náklady na dobu provádění a údržbu.

• Základní vrstva: Testy jednotek ověřují jednotlivé komponenty izolovaně. Běží rychle a poskytují okamžitou zpětnou vazbu.
• Střední vrstva: Integrační testy ověřují interakce mezi komponentami a službami. Běží pomaleji než testy jednotek, ale poskytují širší pokrytí chování systému.
• Horní vrstva: Kompletní testy ověřují cesty uživatelů po celém systému a simulují skutečné scénáře. Tyto testy běží nejpomalejší, ale poskytují nejvyšší důvěru v celkovou kvalitu.

Do vašich potrubí můžete základní a střední testy vrstev snadněji integrovat, protože mají minimální závislosti. Tato integrace umožňuje rychlou zpětnou vazbu v případě selhání testů a umožňuje okamžité zastavení procesu sestavení, což brání chybnému kódu v dalším pokroku.

S rostoucím pokrytím testů se doba provádění pipeliny může výrazně zvýšit. Udržujte rychlou smyčku zpětné vazby pomocí paralelních a distribuovaných strategií provádění testů a udržujte kanály efektivní i při nárůstu pokrytí.

Poznámka:

Do počátečního kanálu buildu, který zkompiluje a ověřuje váš kód, nezahrnujte všechny možné testy. Tato volba zpomaluje cykly vydávání verzí a riskuje vynechání důležitých testů. Zaměřte se na testy, které přímo chrání kritické pracovní postupy a poskytují smysluplnou důvěru v kvalitu systému.

Kompromis. Existuje kompromis mezi pokrytím testů a efektivitou kanálu. I když větší sady testů zvyšují pokrytí, zvyšují také dobu provádění a náklady. Ne vždy poskytují smysluplnou návratnost investic.

Samostatné testování aplikací a infrastruktury

Vytvořte jasné segmentace mezi testováním kódu aplikace a kódu infrastruktury. Ověřte infrastrukturu tím, že sledujete chování aplikace prostřednictvím nasazení softwaru a spuštění testů.

Spuštění kouřových testů aplikací může odhalit problémy s infrastrukturou, jako jsou chyby sítě, chybné konfigurace DNS nebo omezení prostředků, než ovlivní produkci. Orientační test, který ověřuje koncové body stavu rozhraní API, může například rychle zjišťovat problémy se zřizováním infrastruktury nebo problémy se zásadami sítě.

Díky tomuto přístupu aplikace proaktivně identifikují a řeší problémy s infrastrukturou a snižují potřebu samostatného ověřování infrastruktury. Dává vám jistotu, že váš kód i základní infrastruktura spolupracují správně.

Začlenění různých typů testování

V celé úloze používejte různé testovací metody. Dokončení jednotkových testů neznamená, že jste s testováním hotovi. Každý aspekt vaší úlohy potřebuje odlišný přístup. Více typů testů zvyšuje celkovou kvalitu a vytváří jistotu, že systém funguje podle očekávání.

Na základě vyspělosti úloh a rizikového profilu zvolte správný typ testu. Začněte funkčním ověřováním prostřednictvím vrstev testovací pyramidy a pak přidejte nefunkční testování, jako je výkon, zabezpečení a odolnost. Srovnejte výběr testovacího typu se kritickými scénáři a riziky vaší úlohy.

Následující tabulka ukazuje, kdy použít různé typy testů v průběhu testovacího cyklu. Každá z nich řeší konkrétní rizika. I když tato tabulka není vyčerpávajícím seznamem všech možných typů testů, slouží jako ilustrativní příklad.

Typ testování	Primární účel	Vhodné použití služby	Náklady a důležité informace
Ruční testování	Ověřte scénáře vyžadující lidský úsudek, průzkumné učení, použitelnost a nuance uživatelského prostředí.	Raný vývoj, změny uživatelského rozhraní, nejednoznačné toky nebo v případě, že automatizace není možná.	Vysoká cena, nízká škálovatelnost. Používejte střídmě a zaměřte se na oblasti, kde lidský přehled přidává nenahraditelnou hodnotu.
Jednotkové testování	Ověřte izolovanou jednotlivou komponentu nebo logiku funkce.	Nepřetržitě během vývoje.	Nejnižší náklady a nejvyšší hodnota. Rychlá, spolehlivá a kritická pro prevenci regresí. Zaměřte se na široké pokrytí.
Integrační testování	Ověřte interakce mezi komponentami, rozhraními API, kontrakty a sdílenými službami.	Když jsou komponenty a služby připravené k interakci nebo při integraci nových závislostí.	Střední náklady. Důležité pro včasné zachytávání chybných konfigurací a vad interakce.
Kompletní testování (E2E)	Ověřte správnost celého pracovního postupu v celém systému od akce uživatele až po back-endové služby.	Když se základní cesty uživatelů stabilizují a dají se automatizovat.	Vysoké náklady a křehké. Používejte selektivně pro nejdůležitější obchodní toky.
Testování uživatelského rozhraní	Rozpoznává regrese vizuálu, rozložení a interakce.	Po stabilizaci návrhu uživatelského rozhraní nebo v případech, kdy je vizuální věrnost požadavkem na vydání.	Vysoké náklady na údržbu. Omezte kritické cesty uživatelského rozhraní a kritické scénáře přístupnosti.
Zátěž a testování výkonu	Ověřte výkon, latenci, propustnost a škálovatelnost v rámci očekávané úlohy.	Začněte co nejdříve a opakujte, jak se architektura vyvíjí.	Vysoké náklady, ale nezbytné pro provozní připravenost, zejména pro úlohy orientované na zákazníky.
zátěžové testování	Určení systémových limitů, mezních bodů a způsobů obnovy.	Před provozní připraveností nebo významnými změnami architektury.	Vysoké náklady poskytují přehledy o odolnosti. Provozujte selektivně kvůli dopadu na životní prostředí.
Testování zabezpečení	Identifikujte ohrožení zabezpečení, chybné konfigurace a vektory útoku.	Použijte v průběhu životního cyklu vývoje.	Střední–vysoké náklady, ale extrémně vysoká hodnota. Důležité pro ochranu dat, dodržování předpisů a snížení obchodních rizik.

Vyhodnoťte jednotlivé funkce nebo změny na základě obchodního dopadu a rizika. Určete prioritu typů testů na základě tohoto posouzení. U úloh určených pro zákazníky zvýrazněte kompletní testování a testování uživatelského rozhraní. V případě úloh řízených rozhraním API se zaměřte na integraci a testování kontraktů. V případě systémů s vysokou dostupností investujte do testování odolnosti a chaosu.

Kompromis. Určete prioritu testů zabezpečení na začátku procesu vydání. Tento přístup pomáhá zabránit ohrožením zabezpečení a zajistit bezpečnější nasazení. Tato priorita ale může zpomalit tempo, kterým do produkčního prostředí dodáváte nové funkce.

Považovat testovací prostředky za důležité jako prostředky kódu

Testovací prostředky zachycují základní obchodní pravidla, hraniční případy, historické vzory vad a cenné organizační znalosti. Když se kvalita testu sníží, týmy ztrácejí čas laděním nespolehlivých testů místo toho, aby hledaly skutečné chyby. Tato situace vytváří frustraci a vývojáři ztratí důvěru v testovací architekturu.

Zacházejte s testovacími prostředky se stejnou přísností jako s prostředky kódu. Převzetí plné odpovědnosti za testovací prostředky zvyšuje spolehlivost i celkovou kvalitu testovací architektury.

Strukturování a zabezpečení testů

Strukturujte testovací kód se stejnými principy architektury jako kód vaší aplikace. Pokud je to možné, udržujte testy společně s kódem ve stejném úložišti, aby se zjednodušila údržba a zvýšení konzistence.

Pokud se vaše automatizační sada nachází v samostatném úložišti, implementujte ekvivalentní řízení zásad, jako jsou povinné kontroly kódu, zásady pro žádosti o přijetí změn a pipeliny pro ověřování sestavení, pro udržení standardů kvality.

Testy často pracují s produkčními daty a systémy, což může představovat rizika z importovaných knihoven nebo zranitelného testovacího kódu. Implementujte v testovacím kódu zabezpečené postupy kódování, abyste zabránili ohrožením zabezpečení. Zacházejte s testy podle stejných standardů zabezpečení jako s produkčním kódem.

Spravujte verze testovacích dat spolu s kódem. Když změníte schémata dat nebo obchodní pravidla, aktualizujte testovací data tak, aby odpovídala aktuálnímu stavu úlohy.

Proveďte základní ověření vlastních testů, abyste měli jistotu, že fungují podle očekávání. Jakákoli selhání by měla odkazovat na skutečné problémy s aplikací, nikoli na testovací vady. Ověřte, že testy správně selhávají a konzistentně procházejí, když je vaše pracovní zátěž v pořádku. Okamžitě vyřešte nespolehlivé testy a zajistěte, aby aserce testů posílily záměr každého testu.

Nastavte postupy, které zajišťují nezávislost a spolehlivost testů, jako je izolace testovacích dat, zabránění sdílenému stavu a implementace správných procesů nastavení a odstranění. Implementujte automatizované vyčištění testovacích dat. Pokud chcete využít paralelního provádění testů, navrhněte testy tak, aby byly nezávislé, aby mohly běžet v libovolném pořadí, aniž by to mělo vliv na výsledky. Nezávislé testy by měly vždy nastavovat a rušit svá vlastní data a závislosti, aby se stavy nepřenesly do dalšího testovacího běhu.

Pokud vaše aplikace vyžaduje sekvencování v testech, použijte testovací architektury, které podporují seřazené provádění testů.

Údržba a vývoj testů

Zachování testovacích prostředků je zásadní pro zachování kvality úloh. Tyto prostředky často obsahují cenné organizační znalosti. Pokud je pravidelně neudržujete, rychle se stanou zastaralými, což podkopává jejich efektivitu a vaši schopnost dodávat vysoce kvalitní releasy.

S vývojem úloh se testovací prostředky musí vyvíjet paralelně, aby zůstaly v souladu s obchodními cíli. Pro návrh testu použijte stejné principy architektury jako v produkčním kódu.

Sada regresních testů by měla obsahovat ty nejhodnotnější a stabilní testy. Začněte malou a rozšiřte regresní sadu záměrně. Přidejte testy, když dojde k produkčním incidentům, při opravě kritických chyb a při zavedení vysoce rizikových změn. Automatizujte regresní sadu tak, aby běžela konzistentně bez zásahu člověka. Vytvářejte rychlé orientační testy, které běží při každém commitu, a širší regresní testy, které běží přes noc nebo před vydáním.

Testovací případy zachycují záměr, rozsah a očekávané výsledky. Udržování skriptů automatizace testů i testovacích případů v synchronizaci je nezbytné. Pokud se automatizační skripty liší od odpovídajících testovacích případů, je obtížné sledovat, co se ověřuje, což vede k mezerám v pokrytí a odpovědnosti.

Proaktivně naplánujte pravidelné aktualizace testovacích případů při zavádění nových funkcí a vylepšení úloh. Při automatizaci testovacího případu propojte automatizaci s původním testovacím případem, abyste mohli sledovat pokrytí.

Správa zkušebního technického dluhu

Naplánujte pravidelné sprinty údržby testů, aby se řešily hromadící se dluhy dříve, než se stanou nezvladatelnými.

Testy s nestabilními výsledky, duplicitní pokrytí, zastaralé testy a špatný návrh testu všechny přispívají k dluhu způsobenému testováním. Když identifikujete nespolehlivé testy, upřednostněte jejich opravu nebo odebrání, abyste zachovali integritu sady testů. Menší sada spolehlivých testů je hodnotnější než velká sada nestabilních testů.

Strategická rozhodnutí o přeskočení nebo odložení testů jsou stejně důležitá jako to, co testujete. Zvažte vynechání testů pro triviální nebo málo rizikový kód, jako jsou jednoduché gettery a settery bez obchodní logiky, extrémně vzácné hraniční případy, knihovny třetích stran a starší kód naplánované k odebrání. Zdokumentujte tato rozhodnutí, aby se k nim váš tým mohl vrátit jako ke změnám kontextu.

Vyhodnoťte sadu testů a oddělte spolehlivé konzistentní testy od těch, které jsou náchylné k externím změnám. Testy, které se často přerušují kvůli faktorům mimo vaši kontrolu, jako jsou testy uživatelského rozhraní ovlivněné častými aktualizacemi uživatelského rozhraní, nemusí být vhodnými kandidáty pro automatizaci. Toto oddělení vám pomůže určit, které testy se mají automatizovat a které se mají uchovávat ručně.

Kompromis. Když odeberete křehké testy, snížíte pokrytí automatizace. Vyvažte toto snížení tím, že se zaměříte na automatizaci na stabilní rozhraní a kritické pracovní postupy a současně přijmete ruční testování pro často se měnící prvky uživatelského rozhraní.

Ne všechny testy si zaslouží průběžnou údržbu. Vyřazení testů pro funkce, které jste odebrali, testy, které duplikují pokrytí, a testy, které již neposkytují hodnotu. Zdokumentujte, proč odebíráte testy, aby rozhodnutí bylo jasné vašemu týmu.

Rozšíření pozorovatelnosti do testovací architektury

Pozorovatelnost při testování dosahuje dvou klíčových cílů: zajištění spolehlivého fungování testovací architektury a zajištění průběžného přehledu o kvalitě a stavu vaší úlohy. Když integrujete postupy pozorovatelnosti do testovací architektury, posilujete diagnostické funkce, usnadňujete monitorování stability v reálném čase a řídíte průběžné vylepšování procesů testování.

Bez této viditelnosti čelíte značným potížím s diagnostikou problémů, omezenou schopností monitorovat systémy v reálném čase a nezískáte jasné přehledy o efektivitě pokrytí automatizace.

Sady testů se v průběhu času zhoršily, testy se stanou nespolehlivými, ztratí relevanci nebo se nepodaří udržet krok se změnami úloh. Začleněním pozorovatelnosti můžete efektivně monitorovat stav testovací sady, rychle určit a řešit selhání a činit informovaná rozhodnutí o prioritách a vylepšeních údržby. Generování sestav pokrytí usnadňuje identifikaci mezer v automatizaci. Když pokrytí testů odpovídá datům pozorovatelnosti z produkčních incidentů, týmy získají přehled o tom, které scénáře nemají odpovídající ověření.

Použijte standardní testovací nástroje a nástroje pro vytváření sestav v rámci vašeho frameworku k:

• Zajištění jasného přehledu o testovaných cestách kódu
• Identifikace konzistentně neúspěšných testů
• Analýza dlouhodobých trendů ve spolehlivosti testů
• Trasování původu selhání pro cílená vylepšení

Riziko: Pokud jsou protokoly nekonzistentní a příliš podrobné, můžou způsobit větší šum než hodnotu, což znesnadňuje ladění. Implementujte strukturované protokolování s jasnými zprávami a různými úrovněmi podrobností, abyste zajistili smysluplné přehledy bez zahlcení vašeho týmu.

Simulace realistických podmínek

Vyhodnoťte pracovní postupy z pohledu koncového uživatele, abyste měli jistotu, že skutečně řeší potřeby a očekávání zákazníků. Definujte jasná kritéria přijetí pro vaše úlohy a testy návrhu, které přesně odrážejí skutečné toky a prostředí uživatelů, nejen izolované chování systému.

Strategické škálování pokrytí

Škálujte pokrytí testu na základě rizika a hodnoty. Upřednostněte pokrytí cest uživatelů s vysokou hodnotou a kritických cest, které přímo ovlivňují uživatelské prostředí. S rostoucí složitostí úloh rozšiřte pokrytí testů vyhodnocením scénářů, které poskytují nejvyšší důvěru v kvalitu a spolehlivost úloh.

Riziko: Nepřeinvestujte do jednoho uživatelského toku za bodem klesající návratnosti. Jakmile dosáhnete dostatečného pokrytí kritických cest, přesuňte fokus na další důležité oblasti. Snažte se dosáhnout vyváženého pokrytí, nikoli dokonalosti v jednom toku.

Zajistit sladění s obchodními cíli a cíli úrovně služeb (SLOs)

Sladění testů s obchodními cíli i cíli úrovně služeb (SLO) Nastavte měřitelné prahové hodnoty kvality, které odrážejí obchodní závazky a očekávání uživatelů. Odsouhlaste tyto prahové hodnoty, protože poskytují referenční bod pro detekci odchylek a odstraňování chyb. Tento přístup chrání uživatelské prostředí tím, že zajišťuje, aby se neohrožovaly klíčové prahové hodnoty kvality služeb. Pravidelně kontrolujte a aktualizujte základní metriky, abyste měli jistotu, že budou i nadále vyhovovat aktuálním potřebám a očekáváním zákazníků.

Použití reprezentativních testovacích dat

Testovací data by měla co nejblíže reprezentovat scénáře z reálného světa. Syntetická data můžou simulovat autentické uživatelské scénáře a zároveň se vyhnout složitosti zpracování produkčních dat. Syntetické testování může například replikovat scénáře z reálného světa generováním reprezentativních datových sad a vyhodnotit výkon úloh za plánovaných podmínek škálování.

Pokud potřebujete k testování použít produkční data, ujistěte se, že správně anonymizujete všechny informace, abyste ochránili citlivé informace.

Jako výchozí volbu použijte syntetická data. Zarezervujte produkční data pro konkrétní scénáře, kdy syntetická data nemůžou replikovat potřebnou složitost, například testovací skripty migrace dat.

Simulace produkčního prostředí

Produkční prostředí je vaším zdrojem pravdy, abyste pochopili, jak se vaše úlohy chovají v reálných podmínkách. Vytvořte prostředí, které úzce zrcadlí reálné podmínky, abyste mohli důvěřovat tomu, že systém funguje podle očekávání v produkčním prostředí.

Přizpůsobte si přístup ke zrcadlení produkčních prostředí konkrétním potřebám vaší úlohy. Pro klíčové úlohy, které vyžadují vysokou dostupnost, otestujte ve vyhrazeném prostředí, které se úzce podobá produkčnímu prostředí. U těchto úloh pečlivě vyvažte optimalizaci nákladů s potřebou robustního ověření. K zajištění přesného hodnocení chování služeb za realistických podmínek použijte vyhrazené produkční prostředí pro testování výkonu a zátěžového testování.

U jiných úloh zajistěte, aby vaše prostředí úzce odráželo produkční infrastrukturu, aby se snížil počet falešně pozitivních případů, kdy testy uspět v nižších prostředích, ale v produkčním prostředí selžou. Snažte se zajistit konzistenci napříč všemi prostředími, jak váš kód postupuje potrubím. Simulace produkčních podmínek v různých aspektech vaší úlohy, včetně infrastruktury, dat a zabezpečení, za účelem zajištění spolehlivých výsledků testů

Při replikaci vašich prostředí na produkční může odchylka konfigurace vytvořit falešný pocit důvěry v kvalitu. Zabráníte tomu implementací automatizovaných kontrol ověřování odchylek konfigurace, aby se zajistilo, že vaše prostředí zůstane v souladu s produkčním prostředím. V případě potřeby nastavte brány nasazení, abyste ověřili, že je před zahájením testování nasazena správná verze.

Riziko: Když zrcadlíte produkční prostředí, to může výrazně zvýšit provozní náklady. Vyhodnoťte, jestli dočasné prostředí nebo trvalá testovací prostředí nabízejí optimální rovnováhu mezi nákladovou efektivitou a kvalitou pro vaši úlohu.

Vytváření testovacích prostředí řízených účelem

Návrh prostředí s jasným zaměřením na zamýšlený účel Vyhodnoťte jedinečné požadavky jednotlivých fází v životním cyklu testování a ujistěte se, že prostředí úzce odpovídá cílům této fáze.

Záměrně navrhujte každé testovací prostředí tak, aby odpovídalo konkrétní fázi a cílům testování, ať už jde o funkční ověřování, testování integrace nebo jiné účely. Pokud zjednodušené prostředí efektivně obsluhuje vaše požadavky na testování, upřednostněte tento přístup, aby se maximalizovala efektivita.

Použití simulovaných služeb

Úplná replikace produkčních systémů pro každý testovací scénář je často nepraktická. Vyhodnoťte, které součásti vaší úlohy můžete bezpečně replikovat pro testování, aniž by došlo k ohrožení důležitých obchodních pracovních postupů. Pokud úplná replikace není proveditelná, použijte napodobené služby, které přesně simulují chování produkčních služeb a efektivně ověřují scénáře bez rizika živých operací.

Účelem řízená testovací prostředí poskytují ideální základ pro nasazování napodobených služeb v dočasných prostředích. Dočasné prostředí nabízejí nákladově efektivní způsob simulace produkčních podmínek pro testování. Interakce a chování můžete ověřit bez režie na údržbu celých produkčních prostředí pro každý testovací scénář. Tato prostředí na vyžádání se vytvářejí pro konkrétní testovací účely a po použití se zničí, což snižuje náklady na infrastrukturu při zachování kvality testů.

Vytváření dočasných prostředí vyžaduje, aby vaše úloha dosáhla vyšší úrovně vyspělosti, kdy je dobře zavedená automatizace pomocí infrastruktury jako kódu (IaC) a kanálů nasazení.

Usnadnění na platformě Azure

Azure Test Plans je řešení pro správu testů založené na prohlížeči, které poskytuje všechny možnosti potřebné pro plánované ruční testování, testování přijetí uživatelů, průzkumné testování a shromažďování zpětné vazby od zúčastněných stran. Zahrnuje analýzu testů ke sledování kvality testů v průběhu času a identifikaci oblastí pro zlepšení.

Azure Pipelines umožňuje integraci testování do kanálu CI/CD. Můžete také použít GitHub Actions integrované s Azure.

Azure App Testing je služba, která podporuje funkční a výkonnostní testy. Umožňuje spouštět funkční testy pomocí pracovních prostorů Playwright a výkonnostních testů pomocí služby Azure Load Testing.

Prostředí nasazení Azure můžou pomoct aktivovat infrastrukturu aplikací pomocí šablon založených na projektu, které vytvářejí konzistenci a osvědčené postupy při maximalizaci zabezpečení.

Azure také poskytuje nástroje nativní pro platformu, které podporují spolehlivost, výkon a testování zabezpečení.

Související odkazy

• Doporučení pro testování výkonu
• Doporučení pro testování spolehlivosti
• Doporučení pro testování zabezpečení

Kontrolní seznam pro efektivitu provozu

Podívejte se na úplný soubor doporučení.

Kontrolní seznam pro efektivitu provozu