Průběžné testování - Continuous testing - Wikipedia

Průběžné testování je proces provádění automatizované testy jako součást dodávky softwaru k získání okamžité zpětné vazby na obchodní rizika spojená s kandidátem na vydání softwaru.^[1][2] Kontinuální testování bylo původně navrženo jako způsob zkrácení doby čekání na zpětnou vazbu vývojářům zavedením testů spouštěných vývojovým prostředím a tradičnějších testů spouštěných vývojářem / testerem.^[3]

U průběžného testování se rozsah testování rozšiřuje o ověření zdola nahoru požadavky nebo uživatelské příběhy k posouzení Požadavky na systém spojené s zastřešujícími obchodními cíli.^[4]

Přijímače

V roce 2010 se software stal klíčovým rozlišovacím faktorem podnikání.^[5] Výsledkem je, že organizace nyní očekávají, že vývojové týmy softwaru dodají více a inovativnější software v kratších dodacích cyklech.^[6][7] Pro splnění těchto požadavků se týmy obrátily opírat se přístupy, jako např Agilní, DevOps, a Kontinuální dodávka, pokusit se zrychlit životní cyklus vývoje systémů (SDLC).^[8] Po zrychlení dalších aspektů doručovacího kanálu týmy obvykle zjistí, že jejich testovací proces jim brání v dosažení očekávaných výhod jejich akcelerace SDLC.^[9] Testování a celkový proces kvality zůstávají problematické z několika klíčových důvodů.^[10]

• Tradiční procesy testování jsou příliš pomalé. Délka iterace se změnila z měsíců na týdny nebo dny s rostoucí popularitou Agile, DevOps a Continuous Delivery. Tradiční metody testování, které se silně spoléhají na manuální testování a automatické testy GUI, které vyžadují časté aktualizace, nemohou držet krok.^[9][11] V tomto okamžiku mají organizace tendenci uznávat potřebu rozšířit své úsilí v oblasti automatizace testů.^[1][12]
• I poté, co je do stávajícího testovacího procesu přidána další automatizace, manažerům stále chybí adekvátní přehled o úrovni rizika spojeného s aplikací v daném okamžiku.^[2] Porozumění těmto rizikům je zásadní pro rychlé rozhodování o tom, zda se jedná o proces nepřetržitého doručování.^[13] Pokud jsou testy vyvíjeny bez pochopení toho, co podnik považuje za přijatelnou úroveň rizika, je možné mít kandidáta na vydání, který projde všemi dostupnými testy, ale které by vedoucí firmy nepovažovali za připravené na vydání.^[14] Aby výsledky testu přesně naznačovaly, zda každý kandidát na vydání splňuje obchodní očekávání, musí být přístup k navrhování testů založen na toleranci podniku vůči rizikům souvisejícím se zabezpečením, výkonem, spolehlivostí a dodržováním předpisů.^[5] Kromě testů jednotek, které kontrolují kód na velmi podrobné úrovni zdola nahoru, je potřeba širší sady testů, které by poskytly hodnocení obchodního rizika kandidáta na vydání shora dolů.^[4]
• I když je testování automatizované a testy účinně měří úroveň obchodního rizika, týmy bez koordinovaného procesu end-to-end kvality mají tendenci mít potíže s uspokojením obchodních očekávání v rámci dnešních komprimovaných doručovacích cyklů.^[4] Ukázalo se, že pokus o odstranění rizik na konci každé iterace je podstatně pomalejší a náročnější na zdroje než zabudování kvality do produktu prostřednictvím strategií prevence defektů, jako je vývojové testování.^[15][16]

Organizace přijímají průběžné testování, protože si uvědomují, že tyto problémy jim brání v poskytování kvalitního softwaru požadovanou rychlostí. Uznávají rostoucí význam softwaru i rostoucí náklady na selhání softwaru a již nejsou ochotni učinit kompromis mezi časem, rozsahem a kvalitou.^[2][17][18]

Cíle a výhody

Cílem nepřetržitého testování je poskytovat rychlou a nepřetržitou zpětnou vazbu týkající se úrovně obchodního rizika v nejnovějším kandidátovi na sestavení nebo vydání.^[2] Tyto informace lze poté použít k určení, zda je software připraven kdykoli postupovat prostřednictvím doručovacího kanálu.^{[1][5][13][19]}

Vzhledem k tomu, že testování začíná brzy a je prováděno nepřetržitě, rizika aplikace se odhalí brzy po jejich zavedení.^[6] Vývojové týmy pak mohou zabránit postupu těchto problémů do další fáze SDLC. To snižuje čas a úsilí, které je třeba věnovat hledání a opravě defektů. Ve výsledku je možné zvýšit rychlost a frekvenci dodávaného kvalitního softwaru (software, který splňuje očekávání přijatelné úrovně rizika), stejně jako snížit technický dluh.^[4][10][20]

Kromě toho, když jsou snahy o kvalitu softwaru a testování v souladu s obchodními očekáváními, provedení testu vytvoří prioritní seznam proveditelných úkolů (spíše než potenciálně ohromný počet nálezů, které vyžadují ruční kontrolu). To pomáhá týmům zaměřit své úsilí na úkoly v oblasti kvality, které budou mít největší dopad na základě cílů a priorit jejich organizace.^[2]

Navíc, když týmy průběžně provádějí širokou sadu průběžných testů v celém SDLC, shromažďují metriky týkající se kvality procesu i stavu softwaru. Výsledné metriky lze použít k opětovnému prozkoumání a optimalizaci samotného procesu, včetně účinnosti těchto testů. Tyto informace lze použít k vytvoření zpětnovazební smyčky, která pomáhá týmům postupně vylepšovat proces.^[4][10] Klíčovým principem je časté měření, těsné zpětnovazební smyčky a neustálé zlepšování DevOps.^[21]

Rozsah testování

Kontinuální testování zahrnuje ověření obou funkční požadavky a nefunkční požadavky.

Pro testování funkčních požadavků (funkční testování ), Průběžné testování často zahrnuje jednotkové testy, Testování API, integrační testování, a testování systému. Pro testování nefunkčních požadavků (nefunkční testování - zjistit, zda aplikace splňuje očekávání týkající se výkonu, zabezpečení, dodržování předpisů atd.), zahrnuje postupy jako např statická analýza kódu, testování bezpečnosti, testování výkonu, atd.^[9][20] Testy by měly být navrženy tak, aby poskytovaly co nejrychlejší detekci (nebo prevenci) rizik, která jsou pro podnik nebo organizaci vydávající software nejkritičtější.^[6]

Týmy často zjistí, že aby bylo zajištěno, že testovací sada může běžet nepřetržitě a efektivně hodnotit úroveň rizika, je nutné přesunout zaměření z testování GUI na testování API, protože 1) API („transakční vrstva“) jsou považována za nejstabilnější rozhraní do testovaného systému a 2) testy GUI vyžadují značné přepracování, aby udržely krok s častými změnami typickými pro procesy zrychleného vydání; testy na vrstvě API jsou méně křehké a snáze se udržují.^[11][22][23]

Testy se provádějí během nebo po boku kontinuální integrace - alespoň denně.^[24] Pro trénující týmy průběžné dodávky, testy se běžně provádějí mnohokrát denně, pokaždé, když je aplikace aktualizována na ovládání verze Systém.^[9]

V ideálním případě se všechny testy provádějí napříč všemi neprodukčními prostředky testovací prostředí. Aby byla zajištěna přesnost a konzistence, testování by mělo být prováděno v nejkompletnějším produkčním prostředí, jaké je možné. Strategie pro zvýšení stability testovacího prostředí zahrnují virtualizační software (pro závislosti, které může vaše organizace ovládat a zobrazovat), virtualizace služeb (pro závislosti nad rámec vaší kontroly nebo nevhodné pro zobrazování) a správa testovacích dat.^{[1][4][10][25]}

Běžné postupy

• Testování by mělo být ve spolupráci společností Development, QA a Operace —V souladu s prioritami EU předmět podnikání —V rámci koordinovaného procesu end-to-end kvality.^{[1][4][10][17][26]}
• Testy by měly být logicky složené, přírůstkové a opakovatelné; výsledky musí být deterministické a smysluplné.^[1][4]
• Všechny testy je třeba spustit v určitém okamžiku v kanálu sestavení, ale ne všechny testy je nutné spouštět pořád.^[1][9]
• Eliminujte testovací data a omezení prostředí, aby testy mohly běžet neustále a konzistentně v produkčních prostředích.^[1][4][9]
• Aby se minimalizovaly falešné poplachy, minimalizovala údržba testů a efektivněji ověřovaly případy použití napříč moderními systémy s vícevrstvými architekturami, týmy by měly zdůraznit Testování API přes Testování GUI.^[4][11][12]

Výzvy / překážky

Vzhledem k tomu, že moderní aplikace jsou vysoce distribuovány, testovací sady, které je používají, obvykle vyžadují přístup k závislostem, které nejsou snadno dostupné pro testování (např. Služby třetích stran, sálové počítače, které jsou k dispozici pro testování pouze v omezené kapacitě nebo v nevhodných dobách atd.) ) Navíc s rostoucím přijetím agilních a paralelních vývojových procesů je běžné, že end-to-end funkční testy vyžadují přístup k závislostem, které se stále vyvíjejí nebo ještě nejsou implementovány. Tento problém lze vyřešit pomocí virtualizace služeb simulovat interakce testované aplikace (AUT) s chybějícími nebo nedostupnými závislostmi. Lze jej také použít k zajištění konzistence dat, výkonu a chování napříč různými testovacími běhy.^[1][7][10]

Jedním z důvodů, proč se týmy vyhýbají průběžnému testování, je to, že jejich infrastruktura není dostatečně škálovatelná k nepřetržitému provádění testovací sady. Tento problém lze vyřešit zaměřením testů na obchodní priority, rozdělením testovací základny a paralelizací testování s automatizace vydání aplikace nástroje.^[24]

Kontinuální testování vs automatizované testování

Cílem průběžného testování je aplikovat „extrémní automatizaci“ na stabilní produkční testovací prostředí. Automatizace je nezbytná pro průběžné testování.^[27] Automatizované testování však není to samé jako kontinuální testování.^[4]

Automatizované testování zahrnuje automatické provádění jakékoli sady testů, které tým nashromáždil, na základě CI.^{[je zapotřebí objasnění ]} Přechod od automatizovaného testování k průběžnému testování zahrnuje provedení sady testů, které jsou speciálně navrženy k vyhodnocení obchodních rizik spojených s kandidátem na vydání, a k pravidelnému provádění těchto testů v kontextu stabilních testovacích prostředí podobných produkci. Některé rozdíly mezi automatizovaným a nepřetržitým testováním:

• U automatizovaného testování může selhání testu indikovat cokoli od kritického problému až po porušení triviálního standardu pojmenování. Při průběžném testování selhání testu vždy naznačuje kritické obchodní riziko.
• S průběžným testováním je selhání testu řešeno jasným pracovním postupem pro stanovení priorit vad oproti obchodním rizikům a pro řešení těch nejdůležitějších.
• S průběžným testováním, pokaždé, když je identifikováno riziko, existuje proces odhalení všech podobných vad, které již mohly být zavedeny, a také prevence opakování stejného problému v budoucnosti.^[2][5]

Předchůdci

Od 90. let Kontinuální vývoj zaměřený na testování byl použit k poskytnutí rychlé zpětné vazby programátorům o tom, zda kód, který přidali a) fungoval správně ab) neúmyslně změnil nebo porušil stávající funkčnost. Toto testování, které bylo klíčovou součástí Extrémní programování, zahrnuje automatické provádění testů jednotek (a někdy i akceptačních testů nebo kouřových testů) jako součást automatizovaného sestavení, často mnohokrát denně. Tyto testy jsou psány před implementací; absolvování testů naznačuje, že implementace je úspěšná.^[13][28]

Nástroje pro průběžné testování

Výzkumné firmy Forrester Research a Gartner učinili z průběžného testování primární hledisko ve svých každoročních hodnoceních nástrojů automatizace testů. Gartner zveřejnil aktualizovanou verzi výzkumu v roce 2019.

Gartner vyhodnotil 10 nástrojů, které splnily jejich kritéria pro nástroje automatizace testů na podnikové úrovni. Hodnocení zahrnovalo dotazy s klienty společnosti Gartner, průzkumy uživatelů nástrojů, odpovědi prodejců na otázky společnosti Gartner, ukázky produktů prodejců. Gartner požadoval nástroje pro podporu testování nativních desktopových aplikací pro Windows a Android nebo iOS, stejně jako podporu 3 z následujících: responzivní webové aplikace, mobilní aplikace, balíkové aplikace, API / webové služby. Výsledky výzkumu Magic Quadrant 2019 jsou:^[29]

• Vedoucí: Lilek, Software SmartBear, Tricentis
• Vyzyvatelé: IBM, Micro Focus
• Vizionáři: Broadcom, Parasoft
• Niche hráči: froglogic, Ranorex, Worksoft

V roce 2020 společnost Forrester Research vyhodnotila 15 nástrojů, které splňovaly jejich kritéria pro nástroje automatizace funkčních testů na podnikové úrovni.^[30] Forrester stanovil 26 kritérií na základě minulých výzkumů, potřeb uživatelů a rozhovorů s odborníky, poté vyhodnotil produkty versus tato kritéria na základě odpovědí prodejců na otázky Forresteru, předvádění produktů prodejců a rozhovorů se zákazníky. Forrester požadoval nástroje, aby měl možnosti testování mezi prohlížeči, mobilními zařízeními, uživatelským rozhraním a API. Výsledky vlny Forrester 2020 jsou:^[30]

• Vedoucí: ACCELQ, lilek, Parasoft, Tricentis
• Silní umělci: Broadcom, IBM, Mabl, Micro Focus, Nezbytně, Omáčkové laboratoře Software SmartBear
• Uchazeči: Cyara, Expiretest, Worksoft
• Vyzyvatelé: Ranorex

Viz také

• Kontinuální dodávka
• Kontinuální integrace
• DevOps
• Správa vydání
• Virtualizace služeb
• Testování softwaru
• Automatizace testů

Další čtení

• Ariola, Wayne; Dunlop, Cynthia (2014). Průběžné testování. CreateSpace. ISBN  978-1494859756.
• Gruver, Gary; Mouser, Tommy (2015). Vedení transformace: Uplatnění agilních principů a principů DevOps v měřítku. IT revoluční tisk. ISBN  978-1942788010.
• Whittaker, James; Arbon, Jason; Carollo, Jeff (2012). Jak Google testuje software. Addison-Wesley Professional. ISBN  978-0321803023.
• Pokorný, Jez; Farley, David (2010). Kontinuální dodávka: Spolehlivé softwarové verze prostřednictvím automatizace sestavování, testování a nasazení. Addison-Wesley Professional. ISBN  978-0-321-60191-9.

Reference