Introduktion
Du har helt sikkert hørt om regressions- og accepttest. Men ved du, hvor meget der egentlig bruges på accepttest i et projekt?
Det kan vi hurtigt få svar på ved hjælp af et tidsregistreringssystem som TMetric.
På vores projekt, accept-test en desktop-applikation på omkring 100 samlinger tog mere end 2 person-uger. Nye QA-specialister, der ikke kendte applikationen godt, havde de største vanskeligheder. Sammenlignet med mere erfarne QA-specialister brugte de meget mere tid på hver testcase.
Men efter min mening var den mest ubehagelige del dette – hvis der findes kritiske fejl inden udgivelsen, skal accepttest udføres igen efter at disse fejl er rettet.
Skriftlige enhedstests hjalp en lille smule, men de reducerede stadig for det meste tiden brugt på regressionstest. Med dette, da mængden af manuelle test nåede et kritisk niveau, begyndte vi at bevæge os mod automatisering.
ROI
Før vi skrev automatiserede UI-tests, var vi nødt til at vurdere, hvor rentable vores investeringer er. Vi gjorde dette ved hjælp af ROI (Return On Investment https://en.wikipedia.org/wiki/Return_on_investment)
Beregning af ROI af UI-test blev også en interessant opgave med flere ukendte variable:
ROI =Profit / Expenses
eller
ROI =(Profit – Expenses) / Expenses
På dette tidspunkt havde vi brug for en lille prototype, der kunne hjælpe os med at estimere alle nødvendige udgifter. Det viste meget ejendommelige resultater:at udføre accepttest tager omtrent samme tid som at automatisere denne proces. Til at begynde med så disse oplysninger tvivlsomme ud, men da vi undersøgte nærmere, blev årsagerne tydelige:
- Nye QA-specialister kan have begrænset forståelse for trin beskrevet i testcases. Når dette sker, vil nogle få personer være involveret i accepttest for at hjælpe med at forstå situationen bedre. Her bør vi også huske på spørgsmålet om, hvor relevant informationen er, som vi har om miljøindstillinger og krav.
- Nogle gange bruger folk involveret i accepttest tid på at lære teknisk dokumentation.
- Appen selv interagerer med et bestemt sæt tjenester. Hvis en af dem ikke er tilgængelig, vil de mindre erfarne QA-specialister bruge tid på at beskrive fejl, som udviklere til gengæld vil undersøge. Som et resultat er tid spildt, fordi den nødvendige service bare ikke kørte korrekt efter en blackout/hardwareopdatering/computergenstart.
- QA-testernes computere er ikke særlig kraftfulde. Hvis der ikke er nogen SSD, vil du allerede bemærke det under installationen. Hvis appen arbejder under hård belastning, er det også muligt, at en langsom personsøgningsfil vil blive brugt.
- For at være ærlig blev vi revet med og glemte, at vi arbejder med automatisering. Har du i øvrigt lukket Youtube-fanen i din browser?
Lad os nu vende tilbage til ROI. For at gøre tingene simple blev beregningerne udført efter tid. Lad os beregne fortjeneste som besparelser på manuelle test, og den tidsperiode, vi vil se på, er et år:
Fortjeneste =(X – Y) * N =(60 – 1) * 8 =472 dage
X – tid brugt på manuel test (60 dage)
Y – tid brugt på udførelse af automatiserede test (1 dag)
N – mængden af tid, der blev udført accept
Dernæst vil vi se på udgifterne:
Udgifter =A + B + C + D + E + F =0 + 10 + 5 + 50 + 7 + 8 =80
A – Omkostningerne ved automatiseringsværktøjslicensen. I vores tilfælde blev der brugt et gratis værktøj.
B – Uddannelse af en QA-specialist (10 dage)
C – Forberedelse af infrastrukturen (5 dage)
D – Udvikling af tests (50 dage)
E – Kørsel af test og beskrivelse af fejl opdaget i processen (7 dage)
F – Testvedligeholdelse (8 dage)
I alt:
ROI =Fortjeneste / Udgifter =472 / 80 =5,9
Selvfølgelig er nogle af aspekterne her estimeret. For at vurdere vores egne beregninger brugte vi noget tid på at undersøge de muligheder, som betalte løsninger og forskellige ROI-beregnere tilbyder. Med dette har vi beregnet den gennemsnitlige ROI-værdi på 2 eller 3, hvilket er et fantastisk resultat.
Eksisterende rammer
Efter at have set på organisatoriske spørgsmål, lad os fokusere på spørgsmål af den tekniske art. Den vigtigste af dem var at vælge en ramme til automatisering af test af vores desktop-applikation. Vi havde følgende krav baseret på vores projekts funktioner:
- Tests vil blive udviklet og kørt på Windows-maskiner
- Rammen bør tilpasses til test af desktop-applikationer
- UI-testning kan integreres i CI-processen. Vi brugte allerede Jenkins, så det var at foretrække her
- Evnen til at skrive test i en brugervenlig IDE – den skal have syntaksfremhævning, testscriptnavigation og IntelliSense-lignende kodefuldførelse
- Minimale udgifter til QA-træning. Af visse grunde ønskede vores QA-specialister ikke at skrive tests i Brainfuck
- Et fællesskab på Stack Overflow, MSDN osv. er at foretrække
TestComplete
Denne platform appellerede oprindeligt til os på grund af dens modenhed, hvilket gav forhåbninger vedrørende de tekniske aspekter.
Det første vi stødte på var en ustabil og ret forældet IDE. Miljøet håndterede syntaksfremhævning mere eller mindre anstændigt, men der var betydelige problemer med navigation (Gå til definition), søgning og kodeautofuldførelse:denne funktionalitet virkede slet ikke cirka 60 % af tiden. Den indbyggede optager og en Inspect-analog fungerede fint. Til sidst gav IDE os en ubehagelig overraskelse, da den begyndte at sende argumenter til applikationen. Dette forårsagede sandsynligvis fejl i applikationens ydeevne:
--no-sandbox program files (x86)\smartbear\testcomplete12\x64\bin\Extensions\tcCrExtension\tcCEFHost.dll;application/x-testcomplete12-0-chrome-browser-agent
På dette stadium involverede vi TestCompletes support i situationen for at prøve at spare tid og evaluere kvaliteten af teknisk support, før vi potentielt køber en licens. Efter et par breve blev sendt til den tekniske support, fik vi et svar - vi bør ignorere de argumenter, der blev sendt til ansøgningen. Underligt, ikke? Ved at undersøge yderligere fandt vi ud af, at disse argumenter er nødvendige for at teste applikationer, der bruger CEF. I vores næste brev erklærede vi, at vi bruger CEF, og vi fik besked på af supportspecialisterne om ikke at ignorere argumenterne. Da vi spurgte, hvordan man præcist skulle bruge dem, ændrede svaret sig tilbage til "Ignorer argumenterne".
Vi efterlod vores samtale med teknisk support, og vi henvendte os til IDE's dokumentation (uden meget håb). Den havde flere oplysninger, men vi fandt intet vedrørende den pågældende sag. Ifølge den samme dokumentation skulle IDE også have opført sig anderledes fra begyndelsen.
Det antages, at test i TestComplete vil blive skrevet ved hjælp af VBScript.
Hvis du ser længe nok på det, kan du høre det. Microsoft foreslår at konvertere dette "vidunder" til PowerShell-scripts. Som et alternativ kan JavaScript og Python bruges, hvilket hjælper på situationen.
Som et gratis værktøj ville TestComplete være tåleligt, men deres side har en prisside, og priserne er pr. bruger. Som et resultat er dette, hvad vi får efter køb af værktøjet:
- IDE, du vil lukke
- Kompatibilitet med scripts fra 1996
- En optager, så vi ikke skriver alt manuelt
- En anden inspektion, men med klokker og fløjter
- 2 typer svar på teknisk support
- Dokumentation, der ikke repræsenterer virkeligheden
Værste handelsaftale nogensinde, lad os komme videre.
Kodet brugergrænseflade
Taktisk tilbagetog, omgruppering, og vi flankerer problemet. På den ene side lærte vi at bruge Visual Studio som en IDE. På den anden side var vores tilgang baseret på DevExpress UI-komponenterne, vi bruger. Som et resultat fandt vi nogle interessante oplysninger om Coded UI-rammeværket, som officielt bruges i DevExpress til at automatisere UI-test. Denne ramme er integreret i den interne testproces så meget, at der endda er en Visual Studio-udvidelse til den.
Der var et omfattende fællesskab, Microsoft promoverede værktøjet på deres hjemmeside, og dette produkt er også blevet nævnt på "Microsoft Visual Studio” kanal. Lang historie kort, alt så lovende ud, og vi begyndte at forberede rammerne.
Det første krav, vi stødte på, var Visual Studio Enterprise. Desuden var denne version af Visual Studio ikke kun nødvendig for at skrive test, men også til at køre dem. Dette betyder, at mstest, hvorigennem lanceringen vil blive udført i tilfælde af CI, også bør være en del af Enterprise-udgaven.
Alle nødvendige kodede UI-værktøjer kan installeres ved at aktivere tilsvarende afkrydsningsfelter, når VS er installeret eller ændret.
Tilgangen til at skrive test var ret behagelig:kommandoer integreret i skallen gjorde det muligt hurtigt at starte en optager, der genererer en enhedstest og en "kort"-klasse, der beskriver brugergrænsefladen. Yderligere værktøjer integreret i VS gav mulighed for at oprette separate testklasser uden at kalde koden.
Den eneste ejendommelighed, vi bemærkede, var en delvis klasse, der havde beskrivelsen af kontrollen og var opdelt i to dele. Sammen med mange andre ting er det beskrevet i dokumentationen. Denne dokumentation er tilstrækkelig til en behagelig arbejdsproces:Kodeeksempler og skærmbilleder gør al teknisk information let tilgængelig og let at forstå. For at sige det enkelt, når optageren beskriver brugergrænsefladen, genereres en "Designer.cs" fil. Denne fil er ansvarlig for at genbruge den kode, der beskriver brugergrænsefladen. Alt, hvad optageren ikke kunne håndtere, skulle skrives manuelt og gemmes et sted uden for klassens autogenererede del. Dette ligner meget de partielle klasser skrevet af VS deigners, når de opretter kontroller. Prioriteten af operationer udført på kontroller og deres tilstandstjek er beskrevet i en metode, hvortil optageren tilføjer en standard TestMethod-attribut.
Skyerne begyndte at samle sig over rammen, da vi begyndte at undersøge de ting, som optageren genererede . Først og fremmest slørede det nogle af applikationens problemer:nogle kontrolelementers Navneegenskab blev ikke specificeret, og optageren anså for at kalde denne latterlige forekomst af regelovertrædelse acceptabel og søgte kontroller gennem teksten. Den håndterede også komplekse kontroller meget ineffektivt. For eksempel blev TreeView-noder søgt efter nodeindeks, hvilket gjorde den oprettede "kort"-klasse ubrugelig i tilfælde af grænsefladeudvidelse. Og optagerens værdi faldt markant i vores øjne – hvad er meningen med at autogenerere koden, hvis du skal tjekke den efterfølgende?
Vi kunne slutte fred med alle disse ting og finde en prisværdig løsning, men pludselig slog tordenen ned:Microsoft udtalte, at denne teknologi nu er forældet. Med dette blev VS 2019 den sidste version af Visual Studio, der understøtter Coded UI. Muligheden for at være afhængig af VS 2019 nu og et par år i forvejen virkede egentlig ikke så skræmmende, men vores projekt er ret stort, så vanskelighederne kunne starte et sted hen ad linjen (f.eks. 2025).
Lad os opsummere. Med Coded UI har vi:
- En kraftfuld betalt IDE
- Al infrastruktur, der allerede er oprettet til test:både på siden af IDE og vores CI
- Evnen til at bede enhver udvikler fra vores projekt om hjælp, fordi vi skriver test i C# i samme IDE
- En omfattende mængde dokumentation af god kvalitet
- Et par triste QA-specialister, der placerede deres kode i den autogenererede del af klassen og derefter mistede den under autogenereringsprocessen
- En masse genereret kode, der fungerer, og som du skal underkastes streng gennemgang
- En uhyrligt gennemsigtig tilgang til CI:Du kan skrive kode til at starte test gennem mstest med lukkede øjne
- En langsomt døende rød automatiseringsgigant, som konstant vokser fra nye test og er faretruende tæt på at blive enten til en falmende hvid dværg repræsenteret af en absolut isoleret maskine med irreversibelt forældet software eller til en supernova-eksplosion, når projektet imploderer under pres fra nye opdateringer.
Alt lød godt bortset fra det sidste punkt. Det er derfor, vi var nødt til at fortsætte vores søgning.
TestStack.White
Vi arbejdede på prototypetests ved hjælp af White sideløbende med at undersøge funktionaliteten af Coded UI.
White i sig selv er en indpakning omkring 'Microsoft.Automation'-bibliotekerne, som så meget lovende ud, og White ligner også Coded UI. Men ved nærmere undersøgelse fandt vi, at det var meget mere stramt, og man kunne mærke det overalt – lige fra at der ikke var nogen optager til selve teststrukturen. For eksempel ser det sådan ud at køre appen, søge efter et vindue og trykke på knappen "Udfør":
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(); Selvom der ikke er nogen klager, når det kommer til at køre applikationen, er nødvendigheden af at arbejde med InvokePattern-klassen meget tvivlsom. InitializeOption-klassen ser også mærkelig ud, fordi den har adgang til det statiske WithCache-medlem, men det er meningen, at den skal bruges strengt internt:
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();
}
Mærkelige beslutninger som denne er overalt, og rammerne viser sig at være for abstrakte til QA.
Dokumentationen er af anstændig kvalitet og har efterladt et godt generelt indtryk. Projektets kildekode blev hostet hos github, men den seneste commit blev dateret tilbage til den 8. januar 2016.
Opsummering af oplysningerne om White ville vi have:
- Anstændig dokumentation
- Adgang til kildekoden
- Et lille samfund
- Nødvendigheden af at forklare alle QA-specialister, at kontrollens adfærd er implementeret gennem mønsterklassen
- Et gammelt depot, som vi helt sikkert ville være nødt til at dele ud fra
Det mest ubehagelige var behovet for at udvikle vores egne rammer, som vi gerne vil undgå. Så vi måtte videre.
Appium
Vi er stødt på Appium i vores søgning før, men begyndte først at overveje det seriøst, efter at Microsoft stoppede med at bruge Coded UI.
Ved første øjekast ligner test ved hjælp af Appium en spillemaskine med tre hjul. Den første viser det sprog, som der er en API til, der tillader interaktion med driveren. Dette giver mulighed for at skrive test på ethvert velkendt sprog:Python, C#, Java osv. Den anden rulle viser driver-appen, der fungerer som et mellemlag mellem test og det produkt, vi tester. Som det er beskrevet i dokumentationen, udføres interaktion med tests ved hjælp af JSON Wire Protocol - det er det, der faktisk giver os mulighed for at skrive test på ethvert sprog. Og det tredje hjul viser det objekt, vi tester. Det er lige meget, om det er et websted, en mobilapp eller en desktop-app, så længe den tilsvarende driver kører. Som du kan se, er komponenterne elegant udskiftelige.
Estimeringen af pakkens relevans var tilfredsstillende – på Github-siden kunne vi se, at lageret havde nye commits. Mens vi undersøgte WinAppDriver-lageret, fandt vi ud af, at der endda var en optager i det.
Vi begyndte at bemærke nogle problemer, mens vi skrev en prototype. For eksempel, fordi rammen er for multifunktionel, har WindowsElementet, der er ansvarlig for skrivebordskontrollen, en FindElementByCssSelector-metode, der kaster følgende undtagelse ved udførelse:"Uventet fejl. Uimplementeret kommando:css-vælger-lokaliseringsstrategi er ikke understøttet”. I den næste artikel vil vi tale mere detaljeret om de problemer, vi stødte på, mens vi arbejdede med denne ramme, men indtil videre vil jeg gerne sige, at det lykkedes os at håndtere dem alle.
Som en oversigt, her er, hvad vi har, mens vi bruger Appium:
- Evnen til at teste applikationsfunktionalitet, der kræver interaktion med en browser (åbning af feedbacksiden, onlineaktivering, kontrol af levering af e-mail) inden for rammerne af én infrastruktur og én test
- Evnen til at arbejde med enhver udgave af Visual Studio
- Evnen til at teste en desktopapplikation, der bruger en browser til at gengive brugergrænsefladen. Et godt eksempel på dette ville være Azure Data Studio
- Alle fordele får vi med Coded UI
- En gratis ramme, som Microsoft anbefaler at bruge
- Infrastruktur, der er kendt for QA-specialister, der arbejdede med Selen
- Et lager opdateret med nye commits
- Et anstændigt stort fællesskab, der dog ikke er så stort som Coded UI's fællesskab
- En optager med begrænset funktionalitet
- Nødvendigheden af at køre et driverprogram til test. Ikke særlig praktisk, men det har sin egen logfunktionalitet
- Mange muligheder for at skyde sig selv i foden på grund af WindowsElements uheldige arv fra AppiumWebElement
Ved at gennemgå alle punkter med krav til rammer og sammenligne alle problemer, der findes i hver af disse rammer, valgte vi endelig Appium.
Konklusion
Det var interessant at arbejde med alle disse rammer, fordi hver enkelt af dem var baseret på en unik filosofi om at nærme sig automatiseret test. En del af dem begyndte kun deres vej, mens andre var ved at nå deres formørkelse eller allerede er forsvundet. Du kan undgå at gå tabt i de mange tilgængelige løsninger ved at oprette en liste over specifikke krav til værktøjet og have et ansvarligt team med veletableret interaktion mellem dets medlemmer. Og glem ikke, at fremtidige tests er lige så meget af et projekt, som den sædvanlige kode er, med et efterslæb, boards, CI, refactoring og alt muligt andet.