Automatizace funkčních testů - VI.

V posledním díle uvedu jen několik tipů, které se při automatizaci mohou hodit a tím seriál článků o základech automatizace končí.

1. Důkladně logujte průběh testu


Klasický scénář pro automatizované testování (obzvlášť u regresních testů) je ten, že před odchodem z práce testy spustíte a ráno po příchodu do práce analyzujete výsledek testů - přesněji testovací log.


Většina nástrojů pro automatizaci nějakým způsobem loguje, úroveň logování se ale liší.
Tyto záznamy vám ale nemusí vždy pomoct při diagnostice chyby, proto je nejvhodnější zapisovat do logu i "vlastní záznamy" - a to jak v případe úspěšného testu, tak i chyby.

Počítejte s tím, že budete ráno sedět nad testovacím logem a v tom horším případě (pokud neloguje něco i samotná testovaná aplikace) budete mít pouze tento test log na to, abyste zjistili, co se přesně stalo. (Chyba v aplikaci? Chyba testovacího scénáře? Spustil se v průběhu testu Windows Update a restartoval se testovací počítač? Vyskočilo nějaké neočekávané modální okno?)

Použijte tedy veškeré dostupné prostředky k tomu, abyste zalogovali všechno, co budete potřebovat pro analýzu výsledků a případné zareportování chyby. Například pokud v testu dojde k neočekávanému chování v aplikaci, típněte si rovnou screenshot testované aplikace.



2. Oddělte programovou vrstvu detekce ovládacích prvků od výkonného kódu


Táto "good practice" vyplývá z toho, že testovaná aplikace se mění a vy následně budete muset měnit automatizované testy. Pokud máte na X místech v kódu něco jako

MyButton = Process("IExplore").Page("http:/www.mynet.com/myloginpage").Frame("frmLogin").Button("btnLogin");
MyButton.Click();


a vývojáři vám upraví URL stránky nebo název framu, automat se "nechytí".
Velmi výhodné je proto oddělit "získání" ovládacích prvků do separátních modulů a ten samý kód volat takhle:

MyButton = MyLoginPageControls.LoginButton();
MyButton.Click();

Změny pak budete provádět jenom na jednom místě a udržíte tím i přehlednější logiku kódu.

Některé nástroje toto "mapování" ukládají do speciálních struktur, aby ulehčily uživatelům toto "oddělení vrstvy detekce" - například v TestComplete je to NameMapping a Aliasing.
V některých případech se sice přesto "vlastnímu detekčnímu kódu" nevyhnete (já byl k tomu donucen při psaní automatu na test webového klienta Siebelu), ale je dobré v maximální míře použít mapovací features nástroje.



3. Low-level procedury využívejte jen v případě nouze 


Low level procedury jsou charakteristické tím, že "nevnímají" objekt (například tlačítko), ale jen souřadnice uvnitř okna nebo obrazovky.

Nebezpečí je zřejmé - stačí když se vám změní rozlišení obrazovky, nebo se okno přesune do jiné časti desktopu a skript nebude fungovat.
Jsou ale situace, kdy sa nedá low-level procedurám vyhnout (test tool "nedetekuje" ovládací prvek, testuje se například kreslení čáry v Malování atd.).

Doporučení, když už musíte low-level použít:

• Test pište pro konkrétní rozlišení obrazovky - například na všech počítačích simulujících "testovací zátěž" musí být také nastavené toto rozlišení .
• Okno testované aplikace mějte maximalizované na celou obrazovku, případně ho na začátku testu programově přesuňte na pevně stanovené souřadnice (například 0,0). 
• Low-level procedury vždy ukládejte do samostatného modulu - odděleně od kódu používajícího "klasickou detekci ovládacích prvků".

4. Při přehrávaní testů mějte spuštěné jen nevyhnutelné aplikace

Tato best practice patří k těm, které vám mohou ušetřit spoustu zklamání.

Představte si, že před odchodem z práce spustíte automatizovaný test a ráno zistíte, že test neproběhl - nechali jste totiž zapnutý Windows Update, systém Windows se v noci updatoval a rozhodl o automatickém restartu počítače. Z test logu se dočtete jen to, že "všechny testy probíhaly v pořádku a pak náhle v test logu již nic dalšího není".

Proto doporučuji před spuštěním testů povypínat veškeré aplikace i služby, které by mohly tyto "nepříjemnosti" způsobit.

5. Nepoužívejte "pevné delays" na čekání na objekt

V kódu automatizovaných testů často narazím na něco jako

MyButton1.Click();

Delay(5000); //čekám na zobrazení druhého tlačítka

MyButton2.Click();

Tato praxe je nesprávná. Pokud čekáte na "objevení" daného objektu, má se použít nějaká forma "čekání na objekt", například Wait, WaitChild, WaitAlias - případně cyklus, který čeká na existenci objektu.

Pokud budete používat pevné delays, vystavujete sa riziku, že:

• Až se změní implementace, daná "magická konstanta" čekání nebude vyhovující - buď bude příliš malá (a skript následně selže), nebo příliš velká (a testovací skript bude zbytečně pomalý). 
• Nemůžete tyto skripty použít na performance testy, protože tam vkládáte umělou pauzu, která není závislá na výkonu aplikace. 

Pevné delays se nicméně mohou hodit v těchto případech:

• Simulujete "chování uživatele"- snažíte se vytvořit scénář podle šablony "jakoby to uživatel naklikal ručně v reálném čase". Je to vhodná technika na simulaci provozní zátěže. 
• Nemáte jinou možnost - například čekáte na ovládací prvek, který se obtížně detekuje (přeškrtnutí panáčka v obrázku...) 

Upozornění: Pokud budete využívat "čekání na prvek" v programové smyčce, nezapomeňte na timeout - teda jestli se komponenta do nějaké doby neobjeví, failujte test. Jinak by se mohlo stát, že přijdete ráno do práce a zjistíte, že nástroj od večera čeká na zobrazení nějakého prvku a test proto "zastal na mrtvém bodě".

6. Určete si "výchozí stav" aplikace 

Když začínáte designovat testy, určete si "výchozí stav", ve kterém budou začínat všechny testovací případy. Je to výhodné, pokud plánujete jednotlivé testy "spojovat" do větších business scénářů.

Pokud třeba testy

• změna adresy zákazníka
• změna příjmení zákazníka 
• vymazání zákazníka 

začnete na obrazovce "hlavní zobrazení zákazníka", bude se vám pohodlně tvořit jakákoliv kombinace těchto případů v "business scénářích".

Když to nejde jinak, jako výchozí stav vezměte "čistý start aplikace".

Jaké "best practices" při automatizovaných testech se osvědčily vám? Vyjádřete se v diskuzi :-)