Úvod
Určitě jste slyšeli o regresi a akceptačním testování. Ale víte, kolik se ve skutečnosti utratí za akceptační testování v projektu?
Na to můžeme rychle získat odpověď pomocí systému sledování času, jako je TMetric.
Na našem projektu akceptační testování desktopová aplikace s přibližně 100 sestaveními zabrala více než 2 osobo-týdny. Největší potíže měli noví specialisté na kontrolu kvality, kteří aplikaci dobře neznali. Ve srovnání se zkušenějšími QA specialisty strávili nad každým testovacím případem mnohem více času.
Nicméně to bylo podle mého názoru nejnepříjemnější – pokud se před vydáním najdou nějaké kritické chyby, musí se znovu provést akceptační testování poté, co jsou tyto chyby opraveny.
Psané jednotkové testy trochu pomohly, ale stále většinou zkrátily čas strávený regresním testováním. Když množství ručního testování dosáhlo kritické úrovně, začali jsme směřovat k automatizaci.
ROI
Před psaním automatických testů uživatelského rozhraní jsme potřebovali posoudit, jak ziskové jsou naše investice. Udělali jsme to s pomocí ROI (Return On Investment https://en.wikipedia.org/wiki/Return_on_investment)
Výpočet ROI testování uživatelského rozhraní se také stal zajímavým úkolem s mnoha neznámými proměnnými:
ROI =zisk / náklady
nebo
ROI =(zisk – náklady) / náklady
V této fázi jsme potřebovali malý prototyp, který by nám pomohl odhadnout všechny nutné výdaje. Vykázalo to velmi zvláštní výsledky:provedení akceptačního testování trvá přibližně stejně dlouho jako automatizace tohoto procesu. Zpočátku tato informace vypadala pochybně, ale když jsme ji dále zkoumali, důvody byly jasné:
- Noví specialisté na kontrolu kvality mohou mít omezené znalosti kroků popsaných v testovacích případech. Když k tomu dojde, do akceptačního testování se zapojí několik lidí, kteří pomohou situaci lépe porozumět. Zde bychom také měli mít na paměti otázku, jak relevantní jsou informace, které máme o nastavení prostředí a požadavcích.
- Někdy lidé zapojení do akceptačního testování tráví čas učením se technické dokumentace.
- Aplikace samotná spolupracuje s konkrétní sadou služeb. Pokud je jeden z nich nedostupný, méně zkušení QA specialisté stráví čas popisováním chyb, které budou vývojáři zase zkoumat. Výsledkem je ztráta času, protože potřebná služba po výpadku napájení/aktualizaci hardwaru/restartování počítače neběží správně.
- Počítače testerů kvality nejsou příliš výkonné. Pokud není SSD, všimnete si toho již při instalaci. Pokud aplikace pracuje pod velkým zatížením, je také možné, že bude použit pomalý stránkovací soubor.
- Abych byl upřímný, nechali jsme se unést a zapomněli jsme, že pracujeme s automatizací. Mimochodem, zavřeli jste ve svém prohlížeči kartu Youtube?
Nyní se vraťme k ROI. Pro zjednodušení byly výpočty prováděny podle času. Vypočítejme zisk jako úsporu manuálních testů a časové období, na které se podíváme, je jeden rok:
Zisk =(X – Y) * N =(60 – 1) * 8 =472 dní
X – čas strávený manuálním testováním (60 dní)
Y – čas strávený prováděním automatizovaných testů (1 den)
N – množství času, kdy bylo provedeno přijetí
Dále se podíváme na výdaje:
Výdaje =A + B + C + D + E + F =0 + 10 + 5 + 50 + 7 + 8 =80
A – Cena licence na automatizační nástroj. V našem případě byl použit bezplatný nástroj.
B – Školení specialisty QA (10 dní)
C – Příprava infrastruktury (5 dní)
D – Vývoj testů (50 dní)
E – Spouštění testů a popis chyb objevených v procesu (7 dní)
F – Údržba testu (8 dní)
Celkem:
ROI =Zisk / Výdaje =472 / 80 =5,9
Některé aspekty jsou zde samozřejmě odhadovány. Abychom mohli posoudit naše vlastní výpočty, strávili jsme nějaký čas zkoumáním možností, které nabízejí placená řešení a různé kalkulačky návratnosti investic. S tím jsme vypočítali průměrnou hodnotu ROI 2 nebo 3, což je skvělý výsledek.
Stávající rámce
Když jsme se podívali na organizační otázky, zaměřme se na otázky technického druhu. Nejdůležitější z nich byl výběr frameworku pro automatizaci testování naší desktopové aplikace. Na základě funkcí našeho projektu jsme měli následující požadavky:
- Testy budou vyvinuty a spuštěny na počítačích se systémem Windows
- Rámec by měl být přizpůsoben pro testování desktopových aplikací
- Testování uživatelského rozhraní lze integrovat do procesu CI. Už jsme používali Jenkins, takže to bylo lepší zde
- Možnost psát testy v uživatelsky přívětivém IDE – musí mít zvýraznění syntaxe, navigaci testovacími skripty a dokončování kódu ve stylu IntelliSense
- Minimální náklady na školení QA. Z určitých důvodů naši specialisté na kontrolu kvality nechtěli psát testy v Brainfuck
- Vhodnější je komunita na Stack Overflow, MSDN atd.
Test dokončen
Tato platforma nás zpočátku oslovila svou vyspělostí, což dávalo naději ohledně technických aspektů.
První věc, na kterou jsme narazili, bylo nestabilní a dosti zastaralé IDE. Prostředí zvládlo zvýraznění syntaxe víceméně slušně, ale vyskytly se značné problémy s navigací (Přejít na definici), vyhledáváním a automatickým doplňováním kódu:tato funkce nefungovala vůbec přibližně 60 % času. Vestavěný rekordér a analog Inspect fungovaly dobře. Nakonec nás IDE nemile překvapilo, když aplikaci začalo předávat argumenty. To podle očekávání způsobilo chyby ve výkonu aplikace:
--no-sandbox program files (x86)\smartbear\testcomplete12\x64\bin\Extensions\tcCrExtension\tcCEFHost.dll;application/x-testcomplete12-0-chrome-browser-agent
V této fázi jsme do situace zapojili podporu TestComplete, abychom se pokusili ušetřit čas a vyhodnotili kvalitu technické podpory před případným nákupem licence. Po odeslání několika dopisů na technickou podporu jsme dostali odpověď – argumenty předané aplikaci bychom měli ignorovat. Divné, že? Při dalším zkoumání jsme zjistili, že tyto argumenty jsou nutné pro testování aplikací, které používají CEF. V našem dalším dopise jsme uvedli, že používáme CEF, a specialisté podpory nám řekli, abychom argumenty neignorovali. Když jsme se zeptali, jak přesně je používat, odpověď se změnila zpět na „Ignorujte argumenty“.
Když jsme opustili konverzaci s technickou podporou, obrátili jsme se na dokumentaci IDE (bez velké naděje). Měl více informací, ale nenašli jsme nic, co by se týkalo daného případu. Také podle stejné dokumentace se IDE mělo od začátku chovat jinak.
Předpokládá se, že testy v TestComplete budou psány pomocí VBScriptu.
Když se na to díváte dostatečně dlouho, můžete to slyšet. Microsoft navrhuje převést tento „zázrak“ na skripty PowerShellu. Jako alternativu lze použít JavaScript a Python, což situaci napomáhá.
Jako bezplatný nástroj by byl TestComplete snesitelný, ale jejich stránka má stránku s cenami a ceny jsou za uživatele. V důsledku toho po zakoupení nástroje získáme toto:
- IDE, které chcete zavřít
- Kompatibilita se skripty od roku 1996
- Rekordér, abychom vše nezapisovali ručně
- Další kontrola, ale se zvonky a píšťalkami
- 2 typy odpovědí technické podpory
- Dokumentace, která neodpovídá skutečnosti
Nejhorší obchodní dohoda všech dob, pojďme dál.
Kódované uživatelské rozhraní
Taktický ústup, přeskupení a obcházíme problém. Na jedné straně jsme se naučili používat Visual Studio jako IDE. Na druhou stranu byl náš přístup založen na komponentách uživatelského rozhraní DevExpress, které používáme. V důsledku toho jsme našli několik zajímavých informací o frameworku Coded UI, který se oficiálně používá v DevExpress k automatizaci testování uživatelského rozhraní. Tento framework je integrován do interního testovacího procesu natolik, že pro něj existuje dokonce rozšíření Visual Studio.
Existovala rozsáhlá komunita, Microsoft propagoval nástroj na svých webových stránkách a tento produkt byl také zmíněn na „Microsoft kanál Visual Studio“. Stručně řečeno, vše vypadalo slibně a začali jsme připravovat framework.
Prvním požadavkem, na který jsme narazili, bylo Visual Studio Enterprise. Navíc tato verze Visual Studia nebyla nezbytná pouze pro psaní testů, ale také pro jejich spouštění. To znamená, že součástí edice Enterprise by měl být i mstest, přes který bude spouštění prováděno v případě CI.
Všechny potřebné nástroje pro kódované uživatelské rozhraní lze nainstalovat zaškrtnutím příslušných políček při instalaci nebo úpravě VS.
Přístup k psaní testů byl docela příjemný:příkazy integrované do shellu umožňovaly rychle spustit záznamník, který generuje test jednotky a třídu „map“ popisující uživatelské rozhraní. Další nástroje integrované do VS poskytovaly možnost vytvářet samostatné testovací třídy bez volání kódu.
Jedinou zvláštností, kterou jsme zaznamenali, byla částečná třída, která měla popis ovládání a byla rozdělena na dvě části. Spolu s mnoha dalšími věcmi je to popsáno v dokumentaci. Tato dokumentace je dostatečná pro pohodlný pracovní proces:příklady kódu a snímky obrazovky umožňují snadnou dostupnost a srozumitelnost všech technických informací. Jednoduše řečeno, když zapisovač popíše uživatelské rozhraní, vygeneruje se soubor „Designer.cs“. Tento soubor je zodpovědný za opětovné použití kódu, který popisuje uživatelské rozhraní. Vše, co rekordér nezvládl, by mělo být zapsáno ručně a uloženo někde mimo automaticky generovanou část třídy. To je velmi podobné dílčím třídám, které napsali VS deigners při vytváření ovládacích prvků. Priorita operací prováděných na ovládacích prvcích a jejich stavových kontrol je popsána v metodě, ke které záznamník užitečně přidává standardní atribut TestMethod.
Mračna se nad rámcem začala shromažďovat, když jsme začali zkoumat věci, které záznamník vygeneroval. . Zaprvé to zakrylo některé problémy aplikace:vlastnost Name některých ovládacích prvků nebyla specifikována a záznamník považoval tento směšný případ porušení pravidel za přijatelný a prohledal ovládací prvky v textu. Také to zvládalo složité ovládání velmi neefektivně. Například uzly TreeView byly prohledávány podle indexu uzlu, díky čemuž byla vytvořená třída „map“ nepoužitelná v případě rozšíření rozhraní. A hodnota rekordéru v našich očích výrazně klesla – jaký má smysl automatické generování kódu, když jej potřebujete následně zkontrolovat?
Mohli bychom se se všemi těmito věcmi smířit a najít chvályhodné řešení, ale najednou udeřil hrom:Microsoft uvedl, že tato technologie je nyní zastaralá. Díky tomu se VS 2019 stala poslední verzí sady Visual Studio, která podporuje kódované uživatelské rozhraní. Možnost být závislý na VS 2019 teď a na pár let dopředu se opravdu nezdálo tak děsivé, ale náš projekt je poměrně velký, takže potíže by mohly začít někde níže (například 2025).
Pojďme si to shrnout. S kódovaným uživatelským rozhraním budeme mít:
- Výkonné placené IDE
- Veškerá infrastruktura již vytvořená pro testy:jak na straně IDE, tak na straně našeho CI
- Možnost požádat kteréhokoli vývojáře z našeho projektu o pomoc, protože píšeme testy v C# ve stejném IDE
- Rozsáhlé množství kvalitní dokumentace
- Několik smutných specialistů na kontrolu kvality, kteří umístili svůj kód do automaticky generované části třídy a poté jej během procesu automatického generování ztratili
- Mnoho vygenerovaného kódu, který tento druh funguje a který musíte podrobit přísné kontrole
- Neskutečně transparentní přístup ke CI:můžete psát kód pro spouštění testů pomocí mstest se zavřenýma očima
- Pomalu umírající rudý obr automatizace, který neustále roste z nových testů a je nebezpečně blízko k tomu, aby se proměnil buď v blednoucího bílého trpaslíka reprezentovaného absolutně izolovaným strojem s nevratně zastaralým softwarem, nebo ve výbuch supernovy, když projekt imploduje pod tlak nových aktualizací.
Všechno znělo dobře, až na poslední bod. Proto jsme museli pokračovat v hledání.
TestStack.White
Pracovali jsme na prototypových testech s pomocí Whitea souběžně se zkoumáním funkčnosti Coded UI.
White sám o sobě je obalem knihoven 'Microsoft.Automation', které vypadaly velmi slibně, a White je také podobný Coded UI. Při bližším zkoumání jsme však zjistili, že je mnohem strohější a mohli jste si toho všimnout všude – od faktu, že chyběl rekordér, až po samotnou testovací strukturu. Například spuštění aplikace, vyhledání okna a stisknutí tlačítka „Execute“ vypadá takto:
var appPath = @"C:\Program files\UiAutomatedTestApplication\TestApplication.exe";
var app = TestStack.White.Application.Launch(appPath);
var windowSearchCriteria = SearchCriteria.ByAutomationId("MainForm");
var window = app.GetWindow(windowSearchCriteria, InitializeOption.NoCache);
var execute = window.GetElement(SearchCriteria.ByText("Execute"));
var invokePattern = (InvokePattern)execute.GetCurrentPattern(InvokePattern.Pattern);
invokePattern.Invoke();
app.WaitWhileBusy(); I když na provoz aplikace nejsou žádné stížnosti, nutnost práce s třídou InvokePattern je velmi sporná. Třída InitializeOption také vypadá zvláštně, protože má přístup ke statickému členu WithCache, ale předpokládá se, že se používá výhradně interně:
public class InitializeOption {
//
// Summary:
// This option should not be used as this is only for internal white purposes
public static InitializeOption WithCache { get; }
public static InitializeOption NoCache { get; }
public virtual bool Cached { get; }
public virtual string Identifier { get; }
public virtual bool NoIdentification { get; }
//
// Summary:
// Specify the unique identification for your window. White remembers the location
// of UIItems inside a window as you find them. Next time when items inside the
// same window is found they are located first based on position which is faster.
//
// Parameters:
// identifier:
public virtual InitializeOption AndIdentifiedBy(string identifier);
public virtual void NonCached();
public override string ToString();
}
Podivná rozhodnutí, jako je toto, jsou všude a rámec se zdá být pro QA příliš abstraktní.
Dokumentace je slušné kvality a zanechala dobrý celkový dojem. Zdrojový kód projektu byl hostován na githubu, ale poslední potvrzení bylo datováno 8. ledna 2016.
Shrneme-li informace o Whiteovi, měli bychom:
- Slušná dokumentace
- Přístup ke zdrojovému kódu
- Malá komunita
- Potřeba vysvětlit všem specialistům na kontrolu kvality, že chování ovládacího prvku je implementováno prostřednictvím třídy Pattern
- Staré úložiště, ze kterého bychom určitě museli forkovat
Nejnepříjemnější na tom byla potřeba vyvinout vlastní framework, čemuž bychom se rádi vyhnuli. Takže jsme museli jít dál.
Appium
Na Appium jsme při hledání narazili již dříve, ale vážně o něm začali uvažovat až poté, co Microsoft přestal používat Coded UI.
Na první pohled vypadá testování s pomocí Appium jako automat se třemi kotouči. První ukazuje jazyk, pro který existuje API, které umožňuje interakci s ovladačem. To poskytuje možnost psát testy v jakémkoli známém jazyce:Python, C#, Java atd. Druhý válec ukazuje aplikaci ovladače, která slouží jako mezivrstva mezi testy a produktem, který testujeme. Jak je popsáno v dokumentaci, interakce s testy se provádí pomocí protokolu JSON Wire Protocol – to nám ve skutečnosti dává možnost psát testy v jakémkoli jazyce. A třetí válec ukazuje objekt, který testujeme. Nezáleží na tom, zda se jedná o webovou stránku, mobilní aplikaci nebo desktopovou aplikaci, pokud je spuštěn odpovídající ovladač. Jak můžete vidět, komponenty jsou elegantně zaměnitelné.
Odhad relevance balíčku byl uspokojivý – na stránce Github jsme viděli, že úložiště má nové commity. Při zkoumání úložiště WinAppDriver jsme zjistili, že v něm byl dokonce i záznamník.
Při psaní prototypu jsme si začali všímat některých problémů. Protože je například framework příliš víceúčelový, má prvek WindowsElement zodpovědný za ovládání plochy metodu FindElementByCssSelector, která při spuštění vyvolá následující výjimku:„Neočekávaná chyba. Neimplementovaný příkaz:Strategie lokátoru css selector není podporována“. V příštím článku si povíme o problémech, na které jsme narazili při práci s tímto frameworkem, podrobněji, ale prozatím bych rád řekl, že jsme je zvládli všechny.
Pro shrnutí, zde je to, co budeme mít při používání Appium:
- Možnost testovat funkčnost aplikace, která vyžaduje interakci s prohlížečem (otevření stránky zpětné vazby, online aktivace, kontrola doručování e-mailů) v rámci jedné infrastruktury a jednoho testu
- Možnost pracovat s jakoukoli edicí sady Visual Studio
- Možnost otestovat počítačovou aplikaci, která k vykreslení uživatelského rozhraní používá prohlížeč. Dobrým příkladem toho může být Azure Data Studio
- Všechny výhody kódovaného uživatelského rozhraní
- Bezplatný rámec, který společnost Microsoft doporučuje používat
- Infrastruktura, kterou znají specialisté na kontrolu kvality, kteří pracovali se Selenium
- Repozitář aktualizovaný o nové commity
- Slušně velká komunita, která však není tak velká jako komunita Coded UI
- Záznamník s omezenou funkčností
- Nutnost spustit aplikaci ovladače pro testování. Není to příliš pohodlné, ale má vlastní funkci protokolování
- Spousta příležitostí ke střelbě do vlastní nohy kvůli nešťastnému dědictví WindowsElement od AppiumWebElement
Když jsme prošli všechny body s požadavky na rámce a porovnali všechny problémy nalezené v každém z těchto rámců, nakonec jsme vybrali Appium.
Závěr
Bylo zajímavé pracovat se všemi těmito frameworky, protože každý z nich byl založen na jedinečné filozofii přístupu k automatizovanému testování. Část z nich teprve začala svou cestu, zatímco jiní dosahovali svého zatmění nebo již zmizeli. Můžete se vyhnout ztrátě v mnoha dostupných řešeních vytvořením seznamu specifických požadavků na nástroj a vytvořením odpovědného týmu s dobře zavedenou interakcí mezi jeho členy. A nezapomeňte, že budoucí testy jsou stejným projektem jako běžný kód, s nevyřízenými záležitostmi, deskami, CI, refaktoringem a vším ostatním.