Introduktion
Du har säkert hört talas om regression och acceptanstestning. Men vet du hur mycket som faktiskt går åt till acceptanstestning i ett projekt?
Vi kan snabbt få svar på detta med hjälp av ett tidsregistreringssystem som TMetric.
På vårt projekt, acceptanstestning en skrivbordsapplikation med cirka 100 sammanställningar tog mer än 2 personveckor. Nya QA-specialister som inte kände till applikationen väl hade de största svårigheterna. Jämfört med mer erfarna QA-specialister spenderade de mycket mer tid på varje testfall.
Den mest obehagliga delen enligt min mening var dock detta – om några kritiska fel upptäcks innan releasen måste acceptanstestning utföras igen efter att dessa fel har åtgärdats.
Skriftliga enhetstester hjälpte lite, men de minskade ändå mestadels tiden för regressionstestning. Med detta, när mängden manuell testning nådde en kritisk nivå, började vi gå mot automatisering.
ROI
Innan vi skrev automatiserade UI-tester behövde vi bedöma hur lönsamma våra investeringar är. Vi gjorde detta med hjälp av ROI (Return On Investment https://en.wikipedia.org/wiki/Return_on_investment)
Att beräkna ROI för UI-testning blev också en intressant uppgift med flera okända variabler:
ROI =Vinst / Kostnader
eller
ROI =(Profit – Expenses) / Expenses
I detta skede behövde vi en liten prototyp som skulle hjälpa oss att uppskatta alla nödvändiga utgifter. Det visade mycket märkliga resultat:att utföra acceptanstestning tar ungefär lika lång tid som att automatisera denna process. Till en början såg den här informationen tvivelaktig ut, men när vi undersökte vidare blev skälen tydliga:
- Nya QA-specialister kan ha begränsad förståelse för steg som beskrivs i testfall. När detta händer kommer ett fåtal personer att delta i acceptanstestning för att hjälpa till att förstå situationen bättre. Här bör vi också tänka på frågan om hur relevant informationen är om miljöinställningar och krav.
- Ibland ägnar personer som är involverade i acceptanstestning tid åt att lära sig teknisk dokumentation.
- Appen i sig interagerar med en specifik uppsättning tjänster. Om en av dem är otillgänglig kommer de mindre erfarna QA-specialisterna att lägga tid på att beskriva buggar som utvecklarna i sin tur kommer att undersöka. Som ett resultat av detta slösas tid eftersom den nödvändiga tjänsten helt enkelt inte fungerade korrekt efter en blackout/hårdvaruuppdatering/omstart av datorn.
- QA-testarnas datorer är inte särskilt kraftfulla. Om det inte finns någon SSD kommer du redan att märka det under installationen. Dessutom, om appen fungerar under en hård belastning, är det möjligt att en långsam personsökningsfil kommer att användas.
- För att vara ärlig så blev vi med och glömde att vi arbetar med automatisering. Förresten, har du stängt Youtube-fliken i din webbläsare?
Låt oss nu återgå till ROI. För att göra det enkelt utfördes beräkningarna efter tid. Låt oss beräkna vinsten som besparingar på manuella tester, och tidsperioden vi ska titta på är ett år:
Vinst =(X – Y) * N =(60 – 1) * 8 =472 dagar
X – tid som ägnas åt manuell testning (60 dagar)
Y – tid som ägnas åt att utföra automatiserade tester (1 dag)
N – hur lång tid acceptans utfördes
Därefter ska vi titta på utgifterna:
Kostnader =A + B + C + D + E + F =0 + 10 + 5 + 50 + 7 + 8 =80
A – Kostnaden för licensen för automationsverktyget. I vårt fall användes ett gratisverktyg.
B – Utbilda en kvalitetssäkringsspecialist (10 dagar)
C – Förbereda infrastrukturen (5 dagar)
D – Utveckla tester (50 dagar)
E – Köra tester och beskriva buggar som upptäckts under processen (7 dagar)
F – Testunderhåll (8 dagar)
Totalt:
ROI =Vinst / Kostnader =472 / 80 =5,9
Naturligtvis är några av aspekterna här uppskattade. För att bedöma våra egna beräkningar ägnade vi lite tid åt att undersöka de möjligheter som erbjuds av betalda lösningar och olika ROI-kalkylatorer. Med detta beräknade vi det genomsnittliga ROI-värdet på 2 eller 3, vilket är ett utmärkt resultat.
Befintliga ramar
Efter att ha tittat på organisatoriska frågor, låt oss fokusera på frågor av det tekniska slaget. Den viktigaste av dem var att välja ett ramverk för att automatisera testningen av vår skrivbordsapplikation. Vi hade följande krav baserat på vårt projekts funktioner:
- Tester kommer att utvecklas och köras på Windows-datorer
- Ramverket bör anpassas för att testa skrivbordsprogram
- UI-testning kan integreras i CI-processen. Vi använde redan Jenkins, så det var att föredra här
- Möjligheten att skriva tester i en användarvänlig IDE – den måste ha syntaxmarkering, testskriptnavigering och kodkomplettering i IntelliSense-stil
- Minsta kostnader för QA-utbildning. Av vissa skäl ville inte våra QA-specialister skriva tester i Brainfuck
- En gemenskap på Stack Overflow, MSDN, etc. är att föredra
TestComplete
Den här plattformen tilltalade oss initialt på grund av dess mognad, vilket gav förhoppningar angående de tekniska aspekterna.
Det första vi stötte på var en instabil och ganska förlegad IDE. Miljön hanterade syntaxmarkering mer eller mindre anständigt, men det fanns betydande problem med navigering (Gå till definition), sökning och autokomplettering av kod:den här funktionen fungerade inte alls ungefär 60 % av tiden. Den inbyggda inspelaren och en Inspect-analog fungerade bra. Till slut gav IDE oss en obehaglig överraskning när den började skicka argument till applikationen. Detta orsakade förmodligen fel i programmets prestanda:
--no-sandbox program files (x86)\smartbear\testcomplete12\x64\bin\Extensions\tcCrExtension\tcCEFHost.dll;application/x-testcomplete12-0-chrome-browser-agent
I detta skede involverade vi TestCompletes support i situationen för att försöka spara tid och utvärdera kvaliteten på teknisk support innan vi eventuellt köpte en licens. Efter att några brev skickats till den tekniska supporten fick vi svar – vi bör ignorera argumenten som skickats till ansökan. Konstigt, inte sant? När vi undersökte ytterligare fann vi att dessa argument krävs för att testa applikationer som använder CEF. I vårt nästa brev uppgav vi att vi använder CEF och fick höra av supportspecialisterna att inte ignorera argumenten. När vi frågade exakt hur vi skulle använda dem ändrades svaret tillbaka till "Ignorera argumenten".
Vi lämnade vårt samtal med teknisk support och vände oss till IDE:s dokumentation (utan mycket hopp). Den hade mer information, men vi hittade inget som rör det aktuella fallet. Enligt samma dokumentation borde IDE också ha betett sig annorlunda från början.
Det antas att tester i TestComplete kommer att skrivas med VBScript.
Om du tittar tillräckligt länge kan du höra det här. Microsoft föreslår att du konverterar detta "under" till PowerShell-skript. Som ett alternativ kan JavaScript och Python användas, vilket hjälper situationen.
Som ett gratis verktyg skulle TestComplete vara uthärdligt, men deras sida har en prissida och priserna är per användare. Som ett resultat är detta vad vi får efter att ha köpt verktyget:
- IDE som du vill stänga
- Kompatibilitet med skript från 1996
- En brännare så att vi inte skriver allt manuellt
- En annan inspektera, men med klockor och visselpipor
- Två typer av tekniska supportsvar
- Dokumentation som inte representerar verkligheten
Sämsta handelsuppgörelsen någonsin, låt oss gå vidare.
Kodat användargränssnitt
Taktisk reträtt, omgruppering och vi flankerar frågan. Å ena sidan lärde vi oss hur man använder Visual Studio som en IDE. Å andra sidan baserades vårt tillvägagångssätt på DevExpress UI-komponenterna vi använder. Som ett resultat hittade vi en del intressant information om det kodade UI-ramverket som officiellt används i DevExpress för att automatisera UI-testning. Detta ramverk är integrerat i den interna testprocessen så mycket att det till och med finns en Visual Studio-tillägg för det.
Det fanns en omfattande community, Microsoft marknadsförde verktyget på sin webbplats, och den här produkten har också nämnts på "Microsoft Visual Studio” kanal. Lång historia kort, allt såg lovande ut och vi började förbereda ramverket.
Det första kravet vi stötte på var Visual Studio Enterprise. Dessutom var den här versionen av Visual Studio inte bara nödvändig för att skriva tester, utan också för att köra dem. Detta innebär att mstest genom vilken start kommer att utföras i fall med CI också bör vara en del av Enterprise-utgåvan.
Alla nödvändiga kodade UI-verktyg kan installeras genom att aktivera motsvarande kryssrutor när VS installeras eller modifieras.
Tillvägagångssättet för att skriva test var ganska trevligt:kommandon integrerade i skalet gjorde det möjligt att snabbt starta en brännare som genererar ett enhetstest och en "map"-klass som beskriver användargränssnittet. Ytterligare verktyg integrerade i VS gav möjligheten att skapa separata testklasser utan att anropa koden.
Den enda egenheten vi märkte var en partiell klass som hade beskrivningen av kontrollen och var uppdelad i två delar. Tillsammans med många andra saker beskrivs det i dokumentationen. Denna dokumentation är tillräcklig för en bekväm arbetsprocess:kodexempel och skärmdumpar gör all teknisk information lättillgänglig och lätt att förstå. För att uttrycka det enkelt, när inspelaren beskriver användargränssnittet genereras en "Designer.cs"-fil. Denna fil är ansvarig för att återanvända koden som beskriver användargränssnittet. Allt som inspelaren inte kunde hantera bör skrivas manuellt och sparas någonstans utanför klassens autogenererade del. Detta är mycket likt de partiella klasserna skrivna av VS deigners när de skapar kontroller. Prioriteten för operationer som utförs på kontroller och för deras tillståndskontroller beskrivs i en metod till vilken brännaren på ett användbart sätt lägger till ett standardtestmetod-attribut.
Molnen började samlas över ramverket när vi började titta på de saker som brännaren genererade . Först och främst döljde det några av programmets problem:vissa kontrollers namnegenskap specificerades inte, och inspelaren ansåg att detta löjliga fall av regelöverträdelse var acceptabelt och sökte igenom texten. Dessutom hanterade den komplexa kontroller mycket ineffektivt. Till exempel söktes TreeView-noder efter nodindex, vilket gjorde den skapade "map"-klassen oanvändbar vid gränssnittsexpansion. Och inspelarens värde sjönk avsevärt i våra ögon – vad är poängen med att autogenerera koden om du behöver kontrollera den efteråt?
Vi kunde sluta fred med alla dessa saker och hitta en lovvärd lösning, men plötsligt slog åskan ner:Microsoft uppgav att denna teknik nu är föråldrad. Med detta blev VS 2019 den sista versionen av Visual Studio som stöder kodat UI. Möjligheten att vara beroende av VS 2019 nu och ett par år i förväg verkade egentligen inte så skrämmande, men vårt projekt är ganska stort, så svårigheter kan börja någonstans längre fram (till exempel 2025).
Låt oss sammanfatta. Med kodat användargränssnitt har vi:
- En kraftfull betald IDE
- All infrastruktur som redan har skapats för tester:både på sidan av IDE och vår CI
- Möjligheten att be alla utvecklare från vårt projekt om hjälp eftersom vi skriver tester i C# i samma IDE
- En omfattande mängd dokumentation av god kvalitet
- Några sorgliga QA-specialister som placerade sin kod i den autogenererade delen av klassen och sedan tappade den under autogenereringsprocessen
- Mycket genererad kod som fungerar och som du måste granskas noggrant
- Ett skandalöst transparent förhållningssätt till CI:du kan skriva kod för att starta tester genom mstest med slutna ögon
- En långsamt döende röd automationsjätte som ständigt växer från nya tester och är farligt nära att förvandlas till antingen en blekande vit dvärg representerad av en absolut isolerad maskin med irreversibelt föråldrad programvara eller till en supernovaexplosion när projektet imploderar under trycket på nya uppdateringar.
Allt lät bra förutom den sista punkten. Det är därför vi behövde fortsätta vår sökning.
TestStack.White
Vi arbetade med prototyptester med hjälp av White parallellt med att undersöka funktionaliteten hos Coded UI.
White i sig är en linda runt "Microsoft.Automation"-biblioteken som såg mycket lovande ut, och White liknar också Coded UI. Men vid närmare granskning fann vi att det var mycket mer stramt, och man kunde märka det överallt – från det faktum att det inte fanns någon brännare till själva teststrukturen. Till exempel, att köra appen, söka efter ett fönster och trycka på knappen "Execute" ser ut så hä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(); Även om det inte finns några klagomål när det gäller att köra applikationen, är nödvändigheten av att arbeta med klassen InvokePattern mycket tveksam. Klassen InitializeOption ser också konstig ut eftersom den har tillgång till den statiska WithCache-medlemmen, men är tänkt att användas strikt 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();
}
Konstiga beslut som detta finns överallt, och ramverket visar sig vara för abstrakt för QA.
Dokumentationen är av hyfsad kvalitet och har lämnat ett gott allmänt intryck. Projektets källkod var värd hos github, men den senaste commit daterades tillbaka till den 8 januari 2016.
Sammanfattning av informationen om White, skulle vi ha:
- Anständig dokumentation
- Åtkomst till källkoden
- Ett litet samhälle
- Nödvändigheten att förklara för alla QA-specialister att kontrollens beteende implementeras genom klassen Mönster
- Ett gammalt förråd som vi definitivt skulle behöva gå från
Det mest obehagliga var behovet av att utveckla vårt eget ramverk, vilket vi skulle vilja undvika. Så vi var tvungna att gå vidare.
Appium
Vi har stött på Appium i vår sökning tidigare, men började överväga det på allvar först efter att Microsoft slutat använda kodat UI.
Vid första anblicken ser testning med hjälp av Appium ut som en spelautomat med tre hjul. Den första visar språket för vilket det finns ett API som tillåter interaktion med drivrutinen. Detta ger möjligheten att skriva tester på vilket språk som helst:Python, C#, Java, etc. Den andra rullen visar drivrutinsappen som fungerar som ett mellanlager mellan tester och produkten vi testar. Som det beskrivs i dokumentationen utförs interaktion med tester med JSON Wire Protocol – det är detta som faktiskt ger oss möjligheten att skriva tester på vilket språk som helst. Och den tredje rullen visar objektet vi testar. Det spelar egentligen ingen roll om det är en webbplats, en mobilapp eller en stationär app så länge motsvarande drivrutin körs. Som du kan se är komponenterna elegant utbytbara.
Uppskattningen av paketets relevans var tillfredsställande – på Github-sidan kunde vi se att förvaret hade nya commits. När vi undersökte WinAppDriver-förrådet fick vi reda på att det till och med fanns en inspelare i det.
Vi började märka några problem när vi skrev en prototyp. Till exempel, eftersom ramverket är för mångsidigt, har WindowsElement som ansvarar för skrivbordskontrollen en FindElementByCssSelector-metod som kastar följande undantag vid körning:"Oväntat fel. Oimplementerat kommando:css-väljarlokaliseringsstrategi stöds inte”. I nästa artikel kommer vi att prata mer detaljerat om de problem vi stötte på när vi arbetade med detta ramverk, men för tillfället skulle jag vilja säga att vi lyckades hantera dem alla.
Som en sammanfattning, här är vad vi kommer att ha när vi använder Appium:
- Möjligheten att testa applikationsfunktioner som kräver interaktion med en webbläsare (öppna feedbacksidan, onlineaktivering, kontrollera e-postleverans) inom ramen för en infrastruktur och ett test
- Möjligheten att arbeta med alla utgåvor av Visual Studio
- Möjligheten att testa ett skrivbordsprogram som använder en webbläsare för att rendera användargränssnittet. Ett bra exempel på detta skulle vara Azure Data Studio
- Alla fördelar vi får med kodat UI
- Ett gratis ramverk som Microsoft rekommenderar att du använder
- Infrastruktur som är bekant för QA-specialister som arbetade med Selenium
- Ett arkiv uppdaterat med nya commits
- En anständigt stor community som dock inte är lika stor som Coded UI:s community
- En inspelare med begränsad funktionalitet
- Nödvändigheten att köra ett drivrutinsprogram för testning. Inte särskilt bekvämt, men det har sin egen loggningsfunktion
- Många möjligheter att skjuta sig själv i foten på grund av WindowsElements olyckliga arv från AppiumWebElement
Genom att gå igenom alla punkter med krav på ramverk och jämföra alla problem som finns i vart och ett av dessa ramverk valde vi slutligen Appium.
Slutsats
Det var intressant att arbeta med alla dessa ramverk eftersom var och en av dem baserades på en unik filosofi om att närma sig automatiserad testning. En del av dem började bara sin väg medan andra nådde sin förmörkelse eller redan har försvunnit. Du kan undvika att gå vilse i de många tillgängliga lösningarna genom att skapa en lista med specifika krav för verktyget och ha ett ansvarsfullt team med väletablerad interaktion mellan dess medlemmar. Och glöm inte att framtida tester är lika mycket av ett projekt som vanligt kod är, med en eftersläpning, kort, CI, refactoring och allt annat.