Inleiding
Je hebt vast wel eens gehoord van regressie- en acceptatietesten. Maar weet u hoeveel er daadwerkelijk wordt uitgegeven aan acceptatietesten in een project?
Hier kunnen we snel antwoord op krijgen met behulp van een tijdregistratiesysteem als TMetric.
Op ons project, acceptatietesten een desktoptoepassing van ongeveer 100 assemblages vergde meer dan 2 persoonsweken. Nieuwe QA-specialisten die de applicatie niet goed kenden, hadden de grootste problemen. Vergeleken met meer ervaren QA-specialisten, besteedden ze veel meer tijd aan elke testcase.
Naar mijn mening was dit echter het meest onaangename deel:als er kritieke fouten worden gevonden vóór de release, moeten de acceptatietests opnieuw worden uitgevoerd nadat deze fouten zijn verholpen.
Geschreven unit-tests hielpen een beetje, maar ze verminderden toch grotendeels de tijd die aan regressietests werd besteed. Hiermee, toen de hoeveelheid handmatig testen een kritiek niveau bereikte, begonnen we richting automatisering te gaan.
ROI
Voordat we geautomatiseerde UI-tests gingen schrijven, moesten we beoordelen hoe winstgevend onze investeringen zijn. We deden dit met behulp van ROI (Return On Investment https://en.wikipedia.org/wiki/Return_on_investment)
Het berekenen van de ROI van UI-testen werd ook een interessante taak met meerdere onbekende variabelen:
ROI =Winst / Uitgaven
of
ROI =(Winst – Uitgaven) / Uitgaven
In dit stadium hadden we een klein prototype nodig waarmee we alle noodzakelijke uitgaven konden inschatten. Het leverde zeer merkwaardige resultaten op:het uitvoeren van acceptatietesten kost ongeveer evenveel tijd als het automatiseren van dit proces. In eerste instantie leek deze informatie twijfelachtig, maar toen we verder onderzoek deden, werden de redenen duidelijk:
- Nieuwe QA-specialisten hebben mogelijk een beperkt begrip van de stappen die in testcases worden beschreven. Wanneer dit gebeurt, zullen een paar mensen worden betrokken bij acceptatietesten om de situatie beter te begrijpen. Hierbij moeten we ook rekening houden met de vraag hoe relevant de informatie is die we hebben over omgevingsinstellingen en -vereisten.
- Soms besteden mensen die betrokken zijn bij acceptatietesten tijd aan het leren van technische documentatie.
- De app zelf werkt samen met een specifieke set services. Als een van hen niet beschikbaar is, zullen de minder ervaren QA-specialisten tijd besteden aan het beschrijven van bugs die ontwikkelaars op hun beurt zullen onderzoeken. Als gevolg hiervan gaat er tijd verloren omdat de benodigde service gewoon niet goed werkte na een black-out/hardware-update/computer opnieuw opstarten.
- De computers van QA-testers zijn niet erg krachtig. Als er geen SSD is, merk je dat al tijdens de installatie. Als de app zwaar wordt belast, is het ook mogelijk dat er een langzaam wisselbestand wordt gebruikt.
- Om eerlijk te zijn, werden we meegesleept en vergaten we dat we met automatisering werken. Trouwens, heb je het YouTube-tabblad in je browser gesloten?
Laten we nu terugkeren naar ROI. Om het eenvoudig te maken, werden de berekeningen uitgevoerd op tijd. Laten we de winst berekenen als een besparing op handmatige tests, en de periode waar we naar kijken is een jaar:
Winst =(X – Y) * N =(60 – 1) * 8 =472 dagen
X – tijd besteed aan handmatig testen (60 dagen)
Y – tijd besteed aan het uitvoeren van geautomatiseerde tests (1 dag)
N – de hoeveelheid tijd die acceptatie is uitgevoerd
Vervolgens kijken we naar de uitgaven:
Uitgaven =A + B + C + D + E + F =0 + 10 + 5 + 50 + 7 + 8 =80
A – De kosten van de licentie voor de automatiseringstool. In ons geval werd een gratis tool gebruikt.
B – Opleiden van een QA-specialist (10 dagen)
C – Voorbereiden van de infrastructuur (5 dagen)
D – Ontwikkelen van tests (50 dagen)
E – Testen uitvoeren en fouten beschrijven die tijdens het proces zijn ontdekt (7 dagen)
F – Onderhoud testen (8 dagen)
Totaal:
ROI =Winst / Uitgaven =472 / 80 =5,9
Natuurlijk zijn sommige aspecten hier geschat. Om onze eigen berekeningen te beoordelen, hebben we enige tijd besteed aan het onderzoeken van de mogelijkheden van betaalde oplossingen en verschillende ROI-calculators. Hiermee hebben we de gemiddelde ROI-waarde van 2 of 3 berekend, wat een geweldig resultaat is.
Bestaande kaders
Laten we ons, na de organisatorische vragen te hebben bekeken, concentreren op vragen van technische aard. De belangrijkste daarvan was het kiezen van een raamwerk om het testen van onze desktopapplicatie te automatiseren. We hadden de volgende vereisten op basis van de kenmerken van ons project:
- Tests worden ontwikkeld en uitgevoerd op Windows-machines
- Het raamwerk moet worden aangepast voor het testen van desktop-applicaties
- UI-testen kunnen worden geïntegreerd in het CI-proces. We gebruikten Jenkins al, dus het had hier de voorkeur
- De mogelijkheid om tests te schrijven in een gebruiksvriendelijke IDE - het moet syntaxisaccentuering, testscriptnavigatie en IntelliSense-achtige code-aanvulling hebben
- Minimale kosten voor QA-training. Om bepaalde redenen wilden onze QA-specialisten geen tests schrijven in Brainfuck
- Een community op Stack Overflow, MSDN, etc. heeft de voorkeur
TestVoltooid
Dit platform sprak ons in eerste instantie aan vanwege zijn volwassenheid, wat hoop gaf met betrekking tot de technische aspecten.
Het eerste wat we tegenkwamen was een onstabiele en nogal verouderde IDE. De omgeving ging min of meer fatsoenlijk om met syntaxisaccentuering, maar er waren aanzienlijke problemen met navigatie (Ga naar definitie), zoeken en automatisch aanvullen van code:deze functionaliteit werkte ongeveer 60% van de tijd helemaal niet. De ingebouwde recorder en een Inspect analoog werkten prima. Uiteindelijk gaf de IDE ons een onaangename verrassing toen het begon met het doorgeven van argumenten aan de applicatie. Dit veroorzaakte naar verwachting fouten in de prestaties van de applicatie:
--no-sandbox program files (x86)\smartbear\testcomplete12\x64\bin\Extensions\tcCrExtension\tcCEFHost.dll;application/x-testcomplete12-0-chrome-browser-agent
In dit stadium hebben we de ondersteuning van TestComplete bij de situatie betrokken om tijd te besparen en de kwaliteit van de technische ondersteuning te evalueren voordat we mogelijk een licentie kopen. Nadat er een paar brieven naar de technische ondersteuning waren gestuurd, kregen we een antwoord - we moeten de argumenten negeren die aan de toepassing zijn doorgegeven. Vreemd, niet? Na verder onderzoek kwamen we erachter dat deze argumenten nodig zijn om applicaties te testen die CEF gebruiken. In onze volgende brief zeiden we dat we CEF gebruiken en kregen we van de ondersteuningsspecialisten te horen dat we de argumenten niet moesten negeren. Toen we vroegen hoe we ze precies moesten gebruiken, veranderde het antwoord weer in "Negeer de argumenten".
We verlieten ons gesprek met technische ondersteuning en wendden ons tot de documentatie van de IDE (zonder veel hoop). Het had meer informatie, maar we vonden niets met betrekking tot de zaak in kwestie. Volgens dezelfde documentatie had de IDE zich vanaf het begin ook anders moeten gedragen.
Er wordt aangenomen dat tests in TestComplete worden geschreven met VBScript.
Als je er lang genoeg naar kijkt, kun je dit horen. Microsoft stelt voor om dit "wonder" om te zetten in PowerShell-scripts. Als alternatief kunnen JavaScript en Python worden gebruikt, wat de situatie helpt.
Als gratis tool zou TestComplete draaglijk zijn, maar hun site heeft een prijspagina en de prijzen zijn per gebruiker. Als resultaat krijgen we dit na aankoop van de tool:
- IDE die je wilt sluiten
- Compatibiliteit met scripts uit 1996
- Een recorder zodat we niet alles handmatig opschrijven
- Nog een inspectie, maar met toeters en bellen
- 2 soorten technische ondersteuningsantwoorden
- Documentatie die de werkelijkheid niet vertegenwoordigt
Slechtste handelsdeal ooit, laten we verder gaan.
Gecodeerde gebruikersinterface
Tactische terugtrekking, hergroepering, en wij flankeren de kwestie. Aan de ene kant hebben we geleerd hoe we Visual Studio als IDE kunnen gebruiken. Aan de andere kant was onze aanpak gebaseerd op de DevExpress UI-componenten die we gebruiken. Als gevolg hiervan hebben we interessante informatie gevonden over het Coded UI-framework dat officieel in DevExpress wordt gebruikt om UI-tests te automatiseren. Dit framework is zo geïntegreerd in het interne testproces dat er zelfs een Visual Studio-extensie voor is.
Er was een uitgebreide community, Microsoft promootte de tool op hun website en dit product is ook genoemd op de "Microsoft Visual Studio”-kanaal. Om een lang verhaal kort te maken, alles zag er veelbelovend uit en we begonnen met het voorbereiden van het framework.
De eerste vereiste die we tegenkwamen was Visual Studio Enterprise. Bovendien was deze versie van Visual Studio niet alleen nodig voor het schrijven van tests, maar ook om ze uit te voeren. Dit betekent dat mstest waarmee de lancering zal worden uitgevoerd in het geval met CI ook een onderdeel moet zijn van de Enterprise-editie.
Alle benodigde gecodeerde UI-tools kunnen worden geïnstalleerd door overeenkomstige selectievakjes in te schakelen wanneer VS wordt geïnstalleerd of gewijzigd.
De benadering van het schrijven van tests was vrij aangenaam:opdrachten die in de shell waren geïntegreerd, lieten toe om snel een recorder te starten die een eenheidstest en een "kaart" -klasse genereert die de gebruikersinterface beschrijft. Extra tools die in VS waren geïntegreerd, boden de mogelijkheid om afzonderlijke testklassen te maken zonder de code aan te roepen.
De enige bijzonderheid die we opmerkten, was een gedeeltelijke klasse die de beschrijving van het besturingselement bevatte en in twee delen was verdeeld. Samen met vele andere dingen wordt het beschreven in de documentatie. Deze documentatie is voldoende voor een comfortabel werkproces:codevoorbeelden en screenshots maken alle technische informatie gemakkelijk toegankelijk en begrijpelijk. Simpel gezegd, wanneer de recorder de gebruikersinterface beschrijft, wordt een "Designer.cs" -bestand gegenereerd. Dit bestand is verantwoordelijk voor het hergebruik van de code die de gebruikersinterface beschrijft. Alles wat de recorder niet aankan, moet handmatig worden geschreven en ergens buiten het automatisch gegenereerde deel van de klas worden opgeslagen. Dit lijkt erg op de gedeeltelijke klassen die zijn geschreven door VS-deigners bij het maken van besturingselementen. De prioriteit van bewerkingen die worden uitgevoerd op controles en van hun statuscontroles wordt beschreven in een methode waaraan de recorder handig een standaard TestMethod-attribuut toevoegt.
De wolken begonnen zich boven het raamwerk te verzamelen toen we begonnen te kijken naar de dingen die de recorder genereerde . Allereerst verdoezelde het enkele van de problemen van de toepassing:de eigenschap Name van sommige besturingselementen was niet gespecificeerd en de recorder vond dit belachelijke geval van regelovertreding acceptabel en zocht besturingselementen door de tekst. Ook behandelde het complexe controles zeer inefficiënt. TreeView-knooppunten werden bijvoorbeeld doorzocht op knooppuntindex, waardoor de gemaakte "map" -klasse onbruikbaar werd in het geval van interface-uitbreiding. En de waarde van de recorder daalde in onze ogen aanzienlijk - wat heeft het voor zin om de code automatisch te genereren als je het achteraf moet controleren?
We zouden vrede kunnen sluiten met al deze dingen en een prijzenswaardige oplossing vinden, maar plotseling sloeg de donder toe:Microsoft verklaarde dat deze technologie nu achterhaald is. Hiermee werd VS 2019 de laatste versie van Visual Studio die Coded UI ondersteunt. De mogelijkheid om nu en een paar jaar van tevoren afhankelijk te zijn van VS 2019 leek niet zo eng, maar ons project is vrij groot, dus de moeilijkheden kunnen ergens in de loop van de tijd beginnen (bijvoorbeeld (2025).
Laten we samenvatten. Met gecodeerde gebruikersinterface hebben we:
- Een krachtige betaalde IDE
- Alle infrastructuur die al is gemaakt voor tests:zowel aan de kant van de IDE als van onze CI
- De mogelijkheid om elke ontwikkelaar van ons project om hulp te vragen omdat we tests schrijven in C# in dezelfde IDE
- Een uitgebreide hoeveelheid documentatie van goede kwaliteit
- Een paar trieste QA-specialisten die hun code in het automatisch gegenereerde deel van de klas plaatsten en deze vervolgens verloren tijdens het autogeneratieproces
- Veel gegenereerde code die werkt en die je strikt moet controleren
- Een waanzinnig transparante benadering van CI:je kunt code schrijven voor het starten van tests via mstest met je ogen dicht
- Een langzaam stervende rode reus van automatisering die voortdurend groeit uit nieuwe tests en gevaarlijk dicht bij het veranderen is in een vervagende witte dwerg, vertegenwoordigd door een absoluut geïsoleerde machine met onomkeerbaar verouderde software, of in een supernova-explosie wanneer het project implodeert onder de druk van nieuwe updates.
Alles klonk goed, behalve het laatste punt. Daarom moesten we onze zoektocht voortzetten.
TestStack.Wit
We werkten aan prototyping-tests met de hulp van White, parallel aan het onderzoeken van de functionaliteit van Coded UI.
White zelf is een wrap rond de 'Microsoft.Automation'-bibliotheken die er veelbelovend uitzagen, en White lijkt ook op Coded gebruikersinterface. Bij nader onderzoek vonden we het echter veel soberder en je kon het overal merken - van het feit dat er geen recorder was tot de daadwerkelijke teststructuur. Als u bijvoorbeeld de app uitvoert, naar een venster zoekt en op de knop 'Uitvoeren' drukt, ziet het er als volgt uit:
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(); Zelfs als er geen klachten zijn als het gaat om het uitvoeren van de applicatie, is de noodzaak om met de InvokePattern-klasse te werken zeer twijfelachtig. De klasse InitializeOption ziet er ook vreemd uit omdat deze toegang heeft tot het statische lid WithCache, maar wordt verondersteld strikt intern te worden gebruikt:
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();
}
Vreemde beslissingen zoals deze zijn overal, en het raamwerk blijkt te abstract voor QA.
De documentatie is van behoorlijke kwaliteit en heeft een goede algemene indruk achtergelaten. De broncode van het project werd gehost op github, maar de laatste commit dateert van 8 januari 2016.
Als we de informatie over White samenvatten, zouden we het volgende hebben:
- Degelijke documentatie
- Toegang tot de broncode
- Een kleine gemeenschap
- De noodzaak om aan alle QA-specialisten uit te leggen dat het gedrag van de besturing wordt geïmplementeerd via de Pattern-klasse
- Een oude repository waarvan we zeker zouden moeten foren
Het meest onaangename deel was de noodzaak om ons eigen raamwerk te ontwikkelen, wat we graag willen vermijden. Dus moesten we verder.
Appium
We zijn Appium eerder tegengekomen in onze zoektocht, maar begonnen het pas serieus te overwegen nadat Microsoft stopte met het gebruik van Coded UI.
Op het eerste gezicht lijkt het testen met behulp van Appium op een gokautomaat met drie rollen. De eerste toont de taal waarvoor er een API is die interactie met de bestuurder mogelijk maakt. Dit biedt de mogelijkheid om tests te schrijven in elke bekende taal:Python, C#, Java, enz. De tweede rol toont de driver-app die dient als een tussenlaag tussen tests en het product dat we testen. Zoals beschreven in de documentatie, wordt interactie met tests uitgevoerd met behulp van JSON Wire Protocol - dit is wat ons in feite de mogelijkheid geeft om tests in elke taal te schrijven. En de derde rol toont het object dat we testen. Het maakt niet echt uit of het een website, een mobiele app of een desktop-app is, zolang het bijbehorende stuurprogramma maar actief is. Zoals je kunt zien, zijn de componenten elegant uitwisselbaar.
De schatting van de relevantie van het pakket was bevredigend - op de Github-pagina konden we zien dat de repository nieuwe commits had. Tijdens het onderzoeken van de WinAppDriver-repository kwamen we erachter dat er zelfs een recorder in zat.
We begonnen enkele problemen op te merken tijdens het schrijven van een prototype. Omdat het framework bijvoorbeeld te multifunctioneel is, heeft het WindowsElement dat verantwoordelijk is voor het bureaubladbesturingselement een FindElementByCssSelector-methode die de volgende uitzondering veroorzaakt bij de uitvoering:"Onverwachte fout. Niet-geïmplementeerde opdracht:css selector locator-strategie wordt niet ondersteund”. In het volgende artikel zullen we dieper ingaan op de problemen die we tegenkwamen tijdens het werken met dit framework, maar voor nu wil ik zeggen dat we erin geslaagd zijn om ze allemaal op te lossen.
Samenvattend, hier is wat we zullen hebben tijdens het gebruik van Appium:
- De mogelijkheid om applicatiefunctionaliteit te testen die interactie met een browser vereist (openen van de feedbackpagina, online activering, controleren van e-mailbezorging) in het kader van één infrastructuur en één test
- De mogelijkheid om met elke editie van Visual Studio te werken
- De mogelijkheid om een desktoptoepassing te testen die een browser gebruikt om de gebruikersinterface weer te geven. Een goed voorbeeld hiervan is Azure Data Studio
- Alle voordelen die we krijgen met gecodeerde gebruikersinterface
- Een gratis framework dat Microsoft aanbeveelt te gebruiken
- Infrastructuur die bekend is bij QA-specialisten die met Selenium hebben gewerkt
- Een repository bijgewerkt met nieuwe commits
- Een behoorlijk grote community die echter niet zo groot is als de community van Coded UI
- Een recorder met beperkte functionaliteit
- De noodzaak om een stuurprogrammatoepassing uit te voeren om te testen. Niet erg handig, maar het heeft zijn eigen logfunctie
- Veel mogelijkheden om jezelf in de voet te schieten vanwege de ongelukkige erfenis van het WindowsElement van AppiumWebElement
Door alle punten met vereisten voor frameworks door te nemen en alle problemen in elk van die frameworks te vergelijken, hebben we uiteindelijk voor Appium gekozen.
Conclusie
Het was interessant om met al deze frameworks te werken, omdat ze allemaal gebaseerd waren op een unieke filosofie om geautomatiseerd testen te benaderen. Een deel van hen begon pas aan hun pad terwijl anderen hun eclips bereikten of al vervaagd zijn. U kunt voorkomen dat u verdwaalt in de vele beschikbare oplossingen door een lijst met specifieke vereisten voor de tool op te stellen en een verantwoordelijk team te hebben met een gevestigde interactie tussen de leden. En vergeet niet dat toekomstige tests net zo'n project zijn als de gebruikelijke code, met een achterstand, boards, CI, refactoring en al het andere.