Testy běží příliš dlouho: jak zrychlit regresní sadu
Regresní sada opakovaně ověřuje, zda změna nepoškodila funkce, které dříve fungovaly. Pokud její výsledek přichází příliš pozdě, vývojář na něj nemusí čekat a tým přesune testy pouze do nočního běhu. Cílem zrychlení není působivé číslo, ale výsledek doručený v době, kdy ještě ovlivní rozhodnutí o změně nebo releasu.
Kde se čas nejčastěji ztrácí
Příliš mnoho kontrol běží přes uživatelské rozhraní. Každý test otevírá prohlížeč, přihlašuje se a prochází obrazovkami, přestože ověřuje pouze jednu kombinaci pravidel.
Testy běží pouze postupně. Nezávislé scénáře čekají jeden na druhý, protože sdílejí účet, data nebo prostředí.
Sada obsahuje pevné pauzy a opakování. Krátká čekání se ve stovkách kroků sčítají. Nestabilní test navíc spotřebuje čas druhým či třetím pokusem.
Příprava prostředí se opakuje. Instalace závislostí, sestavení aplikace nebo vytváření stejných dat může trvat déle než samotné ověření.
Všechno běží při každé změně. Rychlá kontrola kritické funkce čeká na scénáře, které jsou relevantní pouze pro jinou část produktu.
Nejprve oddělte jednotlivé části času
Změřte nejen celkovou délku pipeline, ale také čekání ve frontě, přípravu prostředí, jednotlivé testy a opakované pokusy. Sledujte medián i pomalejší běhy, protože průměr může skrýt občasný velký výkyv.
Výsledkem má být seznam největších položek. Pokud většinu času spotřebuje sestavení prostředí, paralelizace testů příliš nepomůže. Pokud několik testů čeká na externí službu, výkonnější počítač jejich příčinu nevyřeší.
Jak sadu zrychlit
Přesuňte kontrolu na vhodnou úroveň
Kombinace výpočtů, oprávnění a chybových stavů často patří do jednotkových nebo API testů. V prohlížeči ponechte reprezentativní uživatelské cesty. Tento poměr vysvětluje testovací pyramida a praktické porovnání API a UI testů.
Připravte testy na souběžný běh
Každý test potřebuje vlastní data a nezávislý stav. Když si testy nepřepisují stejného uživatele nebo objednávku, lze je rozdělit mezi více workerů. Počet workerů přizpůsobte kapacitě aplikace a infrastruktury; příliš velký souběh může prostředí přetížit a výsledek zhoršit.
Nahraďte čekání na čas čekáním na stav
Test má pokračovat hned, jakmile se očekávaná operace dokončí, ne po pevném počtu sekund. Zároveň sledujte testy, které projdou až na opakovaný pokus. Jejich stabilizace často zkrátí sadu bez změny pokrytí.
Rozdělte zpětnou vazbu podle účelu
Malá sada kritických kontrol může běžet při každé relevantní změně. Širší sada může následovat před releasem nebo podle plánu. Rozdělení nesmí znamenat, že se důležité testy odsunou na noc bez vlastníka; každá vrstva potřebuje jasnou reakci na selhání.
Odstraňte duplicity a neplatné scénáře
Test, který ověřuje zrušenou funkci nebo přesně duplikuje jinou kontrolu, prodlužuje běh i údržbu. Před vyřazením potvrďte jeho účel s vlastníkem produktu a důvod zdokumentujte.
Na co si dát pozor
Samotné přidání výkonnějšího počítače nebo dalších workerů může zakrýt neefektivní architekturu. Stejně nebezpečné je zrychlovat vypnutím kontrol bez posouzení rizika. Po každé změně porovnejte nejen čas, ale také stabilitu a zachované pokrytí kritických cest.
Co tím získáte
- Kratší běh může snížit čekání týmu a přinést výsledek v době, kdy na něj vývojář a release proces ještě dokážou reagovat.
- Dopad na náklady na infrastrukturu závisí na způsobu zrychlení; větší souběh může její spotřebu také zvýšit.
- Souběžné a izolované testy poskytují předvídatelnější zpětnou vazbu.
- Měření ukáže, které další zlepšení má největší přínos.
Další krok
Rozdělte poslední běh na čekání, přípravu, samotné testy a opakování a označte tři největší položky. Pokud chcete připravit plán zrychlení bez ztráty důležitého pokrytí, ozvěte se nám. Navrhneme pořadí úprav a metriku, kterou se výsledek ověří.