Jak testovat instalaci, aktualizaci a migraci dat
Uživatel se k funkcím desktopové aplikace nedostane, pokud selže už instalace nebo aktualizace. Ruční ověřování těchto scénářů je přitom zdlouhavé, proto se často zkoušejí pouze na jednom počítači a s jednou verzí. V článku si ukážeme, jak je rozdělit na opakovatelné kontroly a kde automatizace přináší největší hodnotu.
Kde vznikají nejčastější problémy
Čistá instalace na počítači vývojáře nestačí. Zákazníci mohou aktualizovat z různých podporovaných verzí, používat odlišná nastavení a pracovat s databází, která se vyvíjela několik let. Problém se proto může projevit pouze při konkrétní kombinaci původní verze, dat a prostředí.
Mezi běžná rizika patří:
- chybějící závislost, služba nebo oprávnění na čistém počítači;
- soubor uzamčený běžícím procesem během aktualizace;
- ztráta uživatelských nastavení nebo nesprávný převod databáze;
- nefunkční přechod ze starší, ale stále podporované verze;
- neúplná odinstalace, po které další instalace selže.
Největší chybou bývá kontrola pouze výsledku „aplikace se otevřela“. Poškozené záznamy, změněná nastavení nebo nefunkční služba se mohou projevit až později.
Jak vytvořit spolehlivé pokrytí
Nejprve připravíme matici podporovaných cest. Určíme, které verze lze aktualizovat přímo, které vyžadují mezikrok a které typy uživatelských dat musí po migraci zůstat zachované. Netestujeme každou historickou kombinaci, ale ty, které výrobce podporuje a zákazníci skutečně používají.
Každý test začíná ve známém stavu. Virtuální stroj nebo vyhrazené testovací prostředí obnovíme ze snímku, nainstalujeme určenou starší verzi a připravíme kontrolní data. Po aktualizaci ověříme nejen spuštění aplikace, ale také:
- verzi programu a nainstalovaných komponent;
- stav služeb, souborů a konfigurace;
- počty a vybrané hodnoty v databázi;
- zachování uživatelských nastavení;
- klíčový pracovní scénář po migraci.
Příkazové nebo tiché rozhraní instalátoru používáme tam, kde je dostupné. Grafického průvodce automatizujeme pouze v části, kterou musí projít také uživatel. Při ovládání oken dáváme přednost Windows UI Automation před klikáním na pevné souřadnice; rozdíl vysvětlujeme v článku Proč netestovat desktop pomocí souřadnic a obrázků.
Testy lze spouštět na vyhrazeném Windows runneru podle rizika: při změně instalátoru, pravidelně v noci nebo před releasem. Ne každá aktualizační cesta musí běžet při každém buildu.
Na co si dát pozor
Migrační testy musí používat připravená testovací data, nikoli jedinou kopii produkční databáze. Také je třeba předem vyřešit licence, aktivaci, administrátorská oprávnění a chování antivirové ochrany. Pokud má instalátor podporovat návrat ke starší verzi, rollback je samostatný scénář a je nutné ho ověřit stejně důkladně.
Co tím získáte
Tým dostane opakovatelnou informaci o tom, zda lze aplikaci nainstalovat a zda podporované aktualizační cesty zachovají data. Ruční testování se soustředí na nové nebo nestandardní situace namísto opakování stejných kroků na čistých strojích.
Zároveň se chyba projeví v konkrétní kombinaci verze a dat. Vývojář proto nemusí hledat příčinu až podle hlášení zákazníka a release nemusí stát na jediném narychlo provedeném testu.
Další krok
Sepište podporované zdrojové verze, cílový release a dva až tři reprezentativní datové soubory. Na jedné aktualizační cestě potom ověřte celý postup od přípravy prostředí až po kontrolu dat. Výsledek ukáže, co lze bezpečně zařadit do pravidelného automatizovaného běhu.