Del 1: Webb/Android
Notera: denna artikel är en översättning till ryska av originalartikeln Alla illustrationer, länkar, citat och termer är dock bevarade på originalspråket för att undvika förvrängning av betydelsen när de översätts till ryska. Jag önskar dig lycka till med studierna!
För närvarande är DevOps-specialiteten en av de mest efterfrågade inom IT-branschen. Om du öppnar populära jobbsöksajter och filtrerar efter lön ser du att DevOps-relaterade jobb ligger högst upp på listan. Det är dock viktigt att förstå att detta främst avser en "Senior"-tjänst, vilket innebär att kandidaten har en hög nivå av kompetens, kunskap om teknik och verktyg. Detta kommer också med en hög grad av ansvar förknippad med oavbruten drift av produktionen. Vi började dock glömma vad DevOps är. Till en början var det inte någon specifik person eller avdelning. Om vi letar efter definitioner av denna term kommer vi att hitta många vackra och korrekta substantiv, som metodik, praktiker, kulturfilosofi, grupp av begrepp och så vidare.
Min specialisering är en testautomationsingenjör (QA-automationsingenjör), men jag anser att den inte bara bör förknippas med att skriva autotester eller utveckla testramverksarkitektur. År 2020 är kunskap om automationsinfrastruktur också väsentlig. Detta gör att du kan organisera automatiseringsprocessen själv, från att köra tester till att ge resultat till alla intressenter i enlighet med dina mål. Som ett resultat är DevOps-kunskaper ett måste för att få jobbet gjort. Och allt detta är bra, men tyvärr finns det ett problem (spoiler: den här artikeln försöker förenkla detta problem). Poängen är att DevOps är svårt. Och detta är uppenbart, eftersom företag inte kommer att betala mycket för något som är lätt att göra... I DevOps-världen finns det ett stort antal verktyg, termer och metoder som måste bemästras. Detta är särskilt svårt i början av en karriär och beror på den samlade tekniska erfarenheten.
Källa:
Här kommer vi förmodligen att avsluta med den inledande delen och fokusera på syftet med denna artikel.
Vad handlar den här artikeln om?
I den här artikeln kommer jag att dela med mig av min erfarenhet av att bygga en testautomationsinfrastruktur. Det finns många informationskällor på Internet om olika verktyg och hur man använder dem, men jag skulle vilja titta på dem rent i automationssammanhang. Jag tror att många automationsingenjörer känner till situationen när ingen utom du kör de utvecklade testen eller bryr sig om att underhålla dem. Som ett resultat blir tester inaktuella och du måste lägga tid på att uppdatera dem. Återigen, i början av en karriär kan detta vara en ganska svår uppgift: att klokt bestämma vilka verktyg som ska hjälpa till att eliminera ett givet problem, hur man väljer, konfigurerar och underhåller dem. Vissa testare vänder sig till DevOps (människor) för hjälp och, låt oss vara ärliga, det här tillvägagångssättet fungerar. I många fall kan detta vara det enda alternativet eftersom vi inte har insyn i alla beroenden. Men som vi vet är DevOps väldigt upptagna killar, eftersom de måste tänka på hela företagets infrastruktur, driftsättning, övervakning, mikrotjänster och andra liknande uppgifter beroende på organisation/team. Som vanligt är automatisering inte en prioritet. I ett sådant fall måste vi försöka göra allt möjligt från vår sida från början till slut. Detta kommer att minska beroenden, påskynda arbetsflödet, förbättra våra färdigheter och göra det möjligt för oss att se helheten av vad som händer.
Artikeln presenterar de mest populära och populära verktygen och visar hur man använder dem för att bygga en automationsinfrastruktur steg för steg. Varje grupp representeras av verktyg som har testats genom personlig erfarenhet. Men det betyder inte att du måste använda samma sak. Verktygen i sig är inte viktiga, de dyker upp och blir föråldrade. Vår ingenjörsuppgift är att förstå de grundläggande principerna: varför vi behöver denna grupp av verktyg och vilka arbetsproblem vi kan lösa med deras hjälp. Det är därför jag i slutet av varje avsnitt lämnar länkar till liknande verktyg som kan användas i din organisation.
Vad står inte i den här artikeln
Jag upprepar än en gång att artikeln inte handlar om specifika verktyg, så det kommer inte att finnas några insatser av kod från dokumentationen och beskrivningar av specifika kommandon. Men i slutet av varje avsnitt lämnar jag länkar för detaljerad studie.
Detta görs för att:
- detta material är mycket lätt att hitta i olika källor (dokumentation, böcker, videokurser);
- om vi börjar gå djupare måste vi skriva 10, 20, 30 delar av den här artikeln (medan planerna är 2-3);
- Jag vill bara inte slösa bort din tid eftersom du kanske vill använda andra verktyg för att uppnå samma mål.
Praxis
Jag skulle verkligen vilja att detta material var användbart för alla läsare, och inte bara läst och glömt. I alla studier är övning en mycket viktig komponent. För detta har jag förberett. Det finns också läxor som väntar på dig för att se till att du inte tanklöst kopierar raderna för de kommandon du kör.
planen
Steg
Teknologi
verktyg
1
Lokal körning (förbered webb- / android-demo-tester och kör det lokalt)
Node.js, Selen, Appium
2
Versionsstyrsystem
gå
3
container
Docker, selennät, selenoid (webb, Android)
4
CI/CD
Gitlab CI
5
Cloud plattformar
Google Cloud Platform
6
orkestrering
Kubernetes
7
Infrastruktur som en kod (IaC)
Terraform, Ansible
Struktur för varje avsnitt
För att hålla berättelsen tydlig beskrivs varje avsnitt enligt följande disposition:
- kort beskrivning av tekniken,
- värde för automationsinfrastruktur,
- illustration av infrastrukturens nuvarande tillstånd,
- länkar till studier,
- liknande verktyg.
1. Kör tester lokalt
Kort beskrivning av tekniken
Detta är bara ett förberedande steg för att köra demotesterna lokalt och verifiera att de klarar. I den praktiska delen används Node.js men programmeringsspråket och plattformen är inte heller viktiga och du kan använda de som används i ditt företag.
Som automationsverktyg rekommenderar jag dock att du använder Selenium WebDriver för webbplattformar respektive Appium för Android-plattformen, eftersom vi i nästa steg kommer att använda Docker-bilder som är skräddarsydda för att fungera specifikt med dessa verktyg. Dessutom, med hänvisning till jobbkraven, är dessa verktyg de mest efterfrågade på marknaden.
Som du kanske har märkt tar vi bara hänsyn till webb- och Android-tester. Tyvärr är iOS en helt annan historia (tack Apple). Jag planerar att visa upp IOS-relaterade lösningar och praxis i kommande delar.
Värde för automationsinfrastruktur
Ur ett infrastrukturperspektiv ger det inget värde att driva lokalt. Du kontrollerar endast att testen körs på den lokala maskinen i lokala webbläsare och simulatorer. Men det är i alla fall en nödvändig utgångspunkt.
Illustration av infrastrukturens nuvarande tillstånd
Länkar att utforska
Liknande verktyg
- alla programmeringsspråk du gillar i samband med Selenium/Appium-tester;
- eventuella tester;
- någon testlöpare.
2. Versionskontrollsystem (Git)
Kort beskrivning av tekniken
Det blir ingen stor uppenbarelse för någon om jag säger att versionskontroll är en oerhört viktig del av utvecklingen, både i team och individuellt. Baserat på olika källor är det säkert att säga att Git är den mest populära representanten. Ett versionskontrollsystem ger många fördelar, såsom koddelning, lagring av versioner, återställning till tidigare grenar, övervakning av projekthistorik och säkerhetskopior. Vi kommer inte att diskutera varje punkt i detalj, eftersom jag är säker på att du är mycket bekant med den och använder den i ditt dagliga arbete. Men om plötsligt inte, så rekommenderar jag att du pausar att läsa den här artikeln och fyller denna lucka så snart som möjligt.
Värde för automationsinfrastruktur
Och här kan du ställa en rimlig fråga: ”Varför berättar han om Git? Alla vet detta och använder det både för utvecklingskod och autotestkod.” Du kommer att ha helt rätt, men i den här artikeln pratar vi om infrastruktur och det här avsnittet fungerar som en förhandsvisning av avsnitt 7: "Infrastructure as Code (IaC)". För oss innebär det att hela infrastrukturen inklusive testning beskrivs i form av kod, så vi kan även applicera versionssystem på den och få liknande fördelar som för utvecklings- och automationskod.
Vi kommer att titta på IaC mer i detalj i steg 7, men redan nu kan du börja använda Git lokalt genom att skapa ett lokalt arkiv. Den stora bilden kommer att utökas när vi lägger till ett fjärrlager till infrastrukturen.
Illustration av infrastrukturens nuvarande tillstånd
Länkar att utforska
Liknande verktyg
3. Containerization (Docker)
Kort beskrivning av tekniken
För att visa hur containerisering har förändrat spelets regler, låt oss gå tillbaka i tiden några decennier. På den tiden köpte och använde människor servermaskiner för att köra applikationer. Men i de flesta fall var de nödvändiga startresurserna inte kända i förväg. Som ett resultat av detta spenderade företag pengar på att köpa dyra, kraftfulla servrar, men en del av denna kapacitet utnyttjades inte helt.
Nästa steg i utvecklingen var virtuella maskiner (VM), som löste problemet med att slösa pengar på oanvända resurser. Denna teknik gjorde det möjligt att köra applikationer oberoende av varandra inom samma server, vilket tilldelade helt isolerat utrymme. Men tyvärr har all teknik sina nackdelar. Att köra en virtuell dator kräver ett komplett operativsystem, som förbrukar CPU, RAM, lagring och, beroende på operativsystemet, måste licenskostnader tas med i beräkningen. Dessa faktorer påverkar lastningshastigheten och gör portabiliteten svår.
Och nu kommer vi till containerisering. Återigen löser denna teknik det tidigare problemet, eftersom containrar inte använder ett fullständigt OS, vilket frigör en stor mängd resurser och ger en snabb och flexibel lösning för portabilitet.
Naturligtvis är containeriseringsteknik inget nytt och introducerades först i slutet av 70-talet. På den tiden utfördes mycket forskning, utveckling och försök. Men det var Docker som anpassade denna teknik och gjorde den lättillgänglig för massorna. Nuförtiden, när vi talar om containrar, menar vi i de flesta fall Docker. När vi pratar om Docker-behållare menar vi Linux-behållare. Vi kan använda Windows- och macOS-system för att köra behållare, men det är viktigt att förstå att i det här fallet visas ett extra lager. Till exempel kör Docker på Mac tyst behållare inuti en lättviktig Linux-VM. Vi kommer att återkomma till detta ämne när vi diskuterar att köra Android-emulatorer inuti behållare, så här finns det en mycket viktig nyans som behöver diskuteras mer i detalj.
Värde för automationsinfrastruktur
Vi fick reda på att containerization och Docker är coola. Låt oss titta på detta i samband med automatisering, eftersom varje verktyg eller teknik behöver lösa ett problem. Låt oss beskriva de uppenbara problemen med testautomatisering i samband med UI-tester:
- ett stort antal beroenden när du installerar Selenium och speciellt Appium;
- kompatibilitetsproblem mellan versioner av webbläsare, simulatorer och drivrutiner;
- brist på isolerat utrymme för webbläsare/simulatorer, vilket är särskilt viktigt för parallellkörning;
- svårt att hantera och underhålla om du behöver köra 10, 50, 100 eller till och med 1000 webbläsare samtidigt.
Men eftersom Selenium är det mest populära automationsverktyget och Docker är det mest populära containeriseringsverktyget borde det inte komma som någon överraskning att någon har försökt kombinera dem för att skapa ett kraftfullt verktyg för att lösa ovan nämnda problem. Låt oss överväga sådana lösningar mer i detalj.
Selennät i docker
Detta verktyg är det mest populära i Selenium-världen för att köra flera webbläsare på flera maskiner och hantera dem från ett centralt nav. För att börja måste du registrera minst 2 delar: Hub och Nod(er). Hub är en central nod som tar emot alla förfrågningar från tester och distribuerar dem till lämpliga noder. För varje nod kan vi konfigurera en specifik konfiguration, till exempel genom att ange önskad webbläsare och dess version. Men vi måste fortfarande ta hand om kompatibla webbläsardrivrutiner själva och installera dem på önskade noder. Av denna anledning används inte Selenium grid i sin rena form, förutom när vi behöver arbeta med webbläsare som inte kan installeras på Linux OS. För alla andra fall skulle en mycket flexibel och korrekt lösning vara att använda Docker-bilder för att köra Selenium grid Hub och Nodes. Detta tillvägagångssätt förenklar nodhanteringen avsevärt, eftersom vi kan välja den bild vi behöver med kompatibla versioner av webbläsare och drivrutiner som redan är installerade.
Trots negativa recensioner om stabilitet, speciellt när man kör ett stort antal noder parallellt, är Selenium Grid fortfarande det mest populära verktyget för att köra Selenium-tester parallellt. Det är viktigt att notera att olika förbättringar och modifieringar av detta verktyg ständigt dyker upp i öppen källkod, som bekämpar olika flaskhalsar.
Selenoid för webben
Det här verktyget är ett genombrott i selenvärlden eftersom det fungerar direkt ur lådan och har gjort livet för många automationsingenjörer mycket enklare. Först och främst är detta inte ytterligare en modifiering av selennätet. Istället skapade utvecklarna en helt ny version av Selenium Hub i Golang, som i kombination med lätta Docker-bilder för olika webbläsare gav fart åt utvecklingen av testautomatisering. Dessutom, i fallet med Selenium Grid, måste vi bestämma alla nödvändiga webbläsare och deras versioner i förväg, vilket inte är ett problem när du arbetar med endast en webbläsare. Men när det kommer till flera webbläsare som stöds är Selenoid den främsta lösningen tack vare sin "webbläsare på begäran". Allt som krävs av oss är att ladda ner de nödvändiga bilderna med webbläsare i förväg och uppdatera konfigurationsfilen som Selenoid interagerar med. Efter att Selenoid har fått en förfrågan från testerna kommer den automatiskt att starta den önskade behållaren med den önskade webbläsaren. När testet är klart kommer Selenoid att dra tillbaka behållaren och därigenom frigöra resurser för framtida förfrågningar. Detta tillvägagångssätt eliminerar helt det välkända problemet med "nodnedbrytning" som vi ofta stöter på i selennät.
Men tyvärr är Selenoid fortfarande inte en silverkula. Vi har funktionen "webbläsare på begäran", men funktionen "resurser på begäran" är fortfarande inte tillgänglig. För att använda Selenoid måste vi distribuera den på fysisk hårdvara eller på en virtuell dator, vilket innebär att vi måste veta i förväg hur många resurser som behöver allokeras. Jag antar att detta inte är ett problem för små projekt som kör 10, 20 eller till och med 30 webbläsare parallellt. Men vad händer om vi behöver 100, 500, 1000 och mer? Det är ingen mening att underhålla och betala för så mycket resurser hela tiden. I avsnitt 5 och 6 i denna artikel kommer vi att diskutera lösningar som gör att du kan skala och därigenom minska företagets kostnader avsevärt.
Selenoid för Android
Efter framgången med Selenoid som ett webbautomatiseringsverktyg ville folk ha något liknande för Android. Och det hände - Selenoid släpptes med Android-stöd. Ur användarsynpunkt på hög nivå liknar driftprincipen webbautomatisering. Den enda skillnaden är att istället för webbläsarbehållare kör Selenoid Android-emulatorbehållare. Enligt min mening är detta för närvarande det mest kraftfulla gratisverktyget för att köra Android-tester parallellt.
Jag skulle verkligen inte vilja prata om de negativa aspekterna av detta verktyg, eftersom jag verkligen gillar det. Men ändå finns det samma nackdelar som gäller för webbautomatisering och som är förknippade med skalning. Utöver detta måste vi prata om ytterligare en begränsning som kan komma som en överraskning om vi sätter upp verktyget för första gången. För att köra Android-bilder behöver vi en fysisk maskin eller virtuell dator med kapslat virtualiseringsstöd. I instruktionsguiden visar jag hur man aktiverar detta på en Linux-VM. Men om du är en macOS-användare och vill distribuera Selenoid lokalt, kommer detta inte att vara möjligt att köra Android-tester. Men du kan alltid köra en Linux VM lokalt med "kapslad virtualisering" konfigurerad och distribuera Selenoid inuti.
Illustration av infrastrukturens nuvarande tillstånd
I samband med denna artikel kommer vi att lägga till 2 verktyg för att illustrera infrastrukturen. Dessa är Selenium grid för webbtester och Selenoid för Android-tester. I GitHub-handledningen kommer jag också att visa dig hur du använder Selenoid för att köra webbtester.
Länkar att utforska
Liknande verktyg
- Det finns andra verktyg för containerisering, men Docker är det mest populära. Om du vill prova något annat, kom ihåg att verktygen vi har täckt för att köra Selenium-tester parallellt inte fungerar direkt.
- Som redan sagt finns det många modifieringar av selennät, till exempel,.
4.CI/CD
Kort beskrivning av tekniken
Utövningen av kontinuerlig integration är ganska populär i utvecklingen och är i nivå med versionskontrollsystem. Trots detta känner jag att det råder förvirring i terminologin. I detta stycke skulle jag vilja beskriva 3 modifieringar av denna teknik från min synvinkel. På internet hittar du många artiklar med olika tolkningar, och det är helt normalt om din åsikt är olika. Det viktigaste är att du är på samma sida med dina kollegor.
Så det finns tre termer: CI - Kontinuerlig integration, CD - Kontinuerlig leverans och återigen CD - Kontinuerlig distribution. (Nedan kommer jag att använda dessa termer på engelska). Varje ändring lägger till flera ytterligare steg till din utvecklingspipeline. Men ordet kontinuerlig (kontinuerlig) är det viktigaste. I detta sammanhang menar vi något som sker från början till slut, utan avbrott eller manuella ingrepp. Låt oss titta på CI & CD och CD i detta sammanhang.
- Fortsatt integration detta är det första steget i evolutionen. Efter att ha skickat in ny kod till servern förväntar vi oss att få snabb feedback om att våra ändringar är ok. Vanligtvis inkluderar CI att köra statiska kodanalysverktyg och enhets-/interna API-tester. Detta gör att vi kan få information om vår kod inom några sekunder/minuter.
- Kontinuerlig leverans är ett mer avancerat steg där vi kör integration/UI-tester. Men i detta skede får vi inte resultat lika snabbt som med CI. För det första tar dessa typer av test längre tid att slutföra. För det andra, innan vi lanserar, måste vi implementera våra ändringar i test-/staging-miljön. Dessutom, om vi pratar om mobilutveckling, visas ytterligare ett steg för att skapa en konstruktion av vår applikation.
- Kontinuerlig distribution förutsätter att vi automatiskt släpper våra ändringar i produktionen om alla acceptanstest har godkänts i tidigare skeden. Utöver detta kan du efter releasestadiet konfigurera olika steg, som att köra röktester på produktion och samla in mätvärden av intresse. Kontinuerlig distribution är endast möjlig med god täckning genom automatiserade tester. Om några manuella ingrepp krävs, inklusive testning, är detta inte längre Kontinuerlig (kontinuerlig). Då kan vi säga att vår pipeline endast överensstämmer med praxis för kontinuerlig leverans.
Värde för automationsinfrastruktur
I det här avsnittet bör jag förtydliga att när vi talar om end-to-end UI-tester betyder det att vi bör distribuera våra ändringar och tillhörande tjänster för att testa miljöer. Kontinuerlig integration - processen är inte tillämplig för denna uppgift och vi måste se till att implementera åtminstone praxis för kontinuerlig leverans. Continuous Deployment är också vettigt i samband med UI-tester om vi ska köra dem i produktion.
Och innan vi tittar på illustrationen av arkitekturförändringen vill jag säga några ord om GitLab CI. Till skillnad från andra CI/CD-verktyg tillhandahåller GitLab ett fjärrlager och många andra ytterligare funktioner. Således är GitLab mer än CI. Det inkluderar källkodshantering, agil hantering, CI/CD-pipelines, loggningsverktyg och insamling av mätvärden direkt. GitLab-arkitekturen består av Gitlab CI/CD och GitLab Runner. Här är en kort beskrivning från den officiella hemsidan:
Gitlab CI/CD är en webbapplikation med ett API som lagrar sitt tillstånd i en databas, hanterar projekt/byggen och tillhandahåller ett användargränssnitt. GitLab Runner är en applikation som bearbetar builds. Den kan distribueras separat och fungerar med GitLab CI/CD via ett API. För tester som körs behöver du både Gitlab-instans och Runner.
Illustration av infrastrukturens nuvarande tillstånd
Länkar att utforska
Liknande verktyg
- Och många andra
5. Molnplattformar
Kort beskrivning av tekniken
I det här avsnittet kommer vi att prata om en populär trend som kallas "offentliga moln". Trots de enorma fördelar som virtualiserings- och containeriseringsteknikerna som beskrivs ovan ger, behöver vi fortfarande datorresurser. Företag köper dyra servrar eller hyr datacenter, men i det här fallet är det nödvändigt att göra beräkningar (ibland orealistiska) av hur många resurser vi kommer att behöva, om vi kommer att använda dem 24/7 och för vilka ändamål. Till exempel kräver produktionen en server som körs XNUMX/XNUMX, men behöver vi liknande resurser för att testa utanför arbetstid? Det beror också på vilken typ av testning som utförs. Ett exempel skulle vara belastnings-/stresstester som vi planerar att köra under icke-arbetstid för att få resultat nästa dag. Men definitivt XNUMX/XNUMX servertillgänglighet krävs inte för automatiserade tester från slut till ände och speciellt inte för manuella testmiljöer. För sådana situationer skulle det vara bra att skaffa så många resurser som behövs på begäran, använda dem och sluta betala när de inte längre behövs. Dessutom skulle det vara bra att ta emot dem direkt genom att göra några musklick eller köra ett par skript. Detta är vad offentliga moln används för. Låt oss titta på definitionen:
"Det offentliga molnet definieras som datortjänster som erbjuds av tredjepartsleverantörer över det offentliga Internet, vilket gör dem tillgängliga för alla som vill använda eller köpa dem. De kan vara gratis eller säljas på begäran, vilket gör att kunderna endast kan betala per användning för de CPU-cykler, lagring eller bandbredd de förbrukar."
Det finns en åsikt att offentliga moln är dyra. Men deras nyckelidé är att minska företagets kostnader. Som tidigare nämnts tillåter offentliga moln dig att få resurser på begäran och endast betala för den tid du använder dem. Ibland glömmer vi också att anställda får löner, och specialister är också en dyr resurs. Man måste ta hänsyn till att publika moln gör infrastrukturstödet mycket enklare, vilket gör att ingenjörer kan fokusera på viktigare uppgifter.
Värde för automationsinfrastruktur
Vilka specifika resurser behöver vi för end-to-end UI-tester? I grund och botten är dessa virtuella maskiner eller kluster (vi kommer att prata om Kubernetes i nästa avsnitt) för att köra webbläsare och emulatorer. Ju fler webbläsare och emulatorer vi vill köra samtidigt, desto mer CPU och minne krävs och desto mer pengar måste vi betala för det. Således tillåter publika moln i testautomatiseringssammanhang att vi kan köra ett stort antal (100, 200, 1000...) webbläsare/emulatorer på begäran, få testresultat så snabbt som möjligt och sluta betala för så vansinnigt resurskrävande kraft.
De mest populära molnleverantörerna är Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). Hur-man-guiden ger exempel på hur man använder GCP, men i allmänhet spelar det ingen roll vad du använder för automatiseringsuppgifter. De har alla ungefär samma funktionalitet. Vanligtvis, för att välja en leverantör, fokuserar ledningen på företagets övergripande infrastruktur och affärskrav, vilket ligger utanför ramen för denna artikel. För automationsingenjörer blir det mer intressant att jämföra användningen av molnleverantörer med användningen av molnplattformar specifikt för teständamål, som Sauce Labs, BrowserStack, BitBar, och så vidare. Så låt oss göra det också! Enligt min åsikt är Sauce Labs den mest kända molntestningsgården, varför jag använde den för jämförelse.
GCP vs Sauce Labs för automationsändamål:
Låt oss föreställa oss att vi behöver köra 8 webbtester och 8 Android-tester samtidigt. För detta kommer vi att använda GCP och köra 2 virtuella maskiner med Selenoid. På den första kommer vi att höja 8 behållare med webbläsare. På den andra finns 8 behållare med emulatorer. Låt oss ta en titt på priserna:
För att köra en behållare med Chrome behöver vi n1-standard-1 bil. I fallet med Android kommer det att vara det n1-standard-4 för en emulator. Faktum är att ett mer flexibelt och billigare sätt är att ställa in specifika användarvärden för CPU/minne, men för närvarande är detta inte viktigt för jämförelse med Sauce Labs.
Och här är tarifferna för att använda Sauce Labs:
Jag tror att du redan har märkt skillnaden, men jag kommer fortfarande att ge en tabell med beräkningar för vår uppgift:
Nödvändiga resurser
Månadsvis
Arbetstimmar(8–8)
Arbetstimmar+ Uttagbar
GCP för webben
n1-standard-1 x 8 = n1-standard-8
$194.18
23 dagar * 12 timmar * 0.38 = 104.88 USD
23 dagar * 12 timmar * 0.08 = 22.08 USD
Sauce Labs för webben
Virtual Cloud8 parallelltester
$1.559
-
-
GCP för Android
n1-standard-4 x 8: n1-standard-16
$776.72
23 dagar * 12 timmar * 1.52 = 419.52 USD
23 dagar * 12 timmar * 0.32 = 88.32 USD
Sauce Labs för Android
Real Device Cloud 8 parallelltester
$1.999
-
-
Som du kan se är skillnaden i kostnad enorm, speciellt om du kör tester endast under en tolvtimmars arbetsperiod. Men du kan sänka kostnaderna ännu mer om du använder undandragbara maskiner. Vad är det?
En undanträngbar virtuell dator är en instans som du kan skapa och köra till ett mycket lägre pris än vanliga instanser. Compute Engine kan dock avsluta (förebygga) dessa instanser om den kräver åtkomst till dessa resurser för andra uppgifter. Undantagbara instanser är överskott av Compute Engine-kapacitet, så deras tillgänglighet varierar med användning.
Om dina appar är feltoleranta och kan motstå möjliga instansförhandsavgöranden, kan utgångsbara instanser minska dina Compute Engine-kostnader avsevärt. Till exempel kan batchbearbetningsjobb köras på undanträngbara instanser. Om några av dessa instanser avslutas under bearbetningen saktar jobbet ner men stoppas inte helt. Undantagbara instanser slutför dina batchbearbetningsuppgifter utan att lägga ytterligare arbetsbelastning på dina befintliga instanser och utan att du behöver betala fullt pris för ytterligare normala instanser.
Och det är fortfarande inte över! I verkligheten är jag säker på att ingen kör tester i 12 timmar utan paus. Och i så fall kan du automatiskt starta och stoppa virtuella maskiner när de inte behövs. Den faktiska användningstiden kan minskas till 6 timmar per dag. Då kommer betalningen i samband med vår uppgift att minska till $11 per månad för 8 webbläsare. Är inte detta underbart? Men med öppningsbara maskiner måste vi vara försiktiga och förberedda på avbrott och instabilitet, även om dessa situationer kan tillhandahållas och hanteras i mjukvara. Det är värt det!
Men jag säger inte på något sätt "använd aldrig molntestfarmar". De har ett antal fördelar. Först och främst är detta inte bara en virtuell maskin, utan en fullfjädrad testautomatiseringslösning med en uppsättning funktioner ur lådan: fjärråtkomst, loggar, skärmdumpar, videoinspelning, olika webbläsare och fysiska mobila enheter. I många situationer kan detta vara ett viktigt chic alternativ. Testplattformar är särskilt användbara för IOS-automatisering, när offentliga moln bara kan erbjuda Linux/Windows-system. Men vi kommer att prata om iOS i följande artiklar. Jag rekommenderar att alltid titta på situationen och utgå från uppgifterna: i vissa fall är det billigare och effektivare att använda publika moln, och i andra är testplattformarna definitivt värda pengarna.
Illustration av infrastrukturens nuvarande tillstånd
Länkar att utforska
Liknande verktyg:
6. Orkestrering
Kort beskrivning av tekniken
Jag har goda nyheter – vi är nästan i slutet av artikeln! För tillfället består vår automationsinfrastruktur av webb- och Android-tester, som vi kör genom GitLab CI parallellt, med hjälp av Docker-aktiverade verktyg: Selenium grid och Selenoid. Dessutom använder vi virtuella maskiner skapade via GCP för att vara värd för behållare med webbläsare och emulatorer. För att minska kostnaderna startar vi dessa virtuella maskiner endast på begäran och stoppar dem när testning inte utförs. Finns det något annat som kan förbättra vår infrastruktur? Svaret är ja! Möt Kubernetes (K8s)!
Låt oss först titta på hur orden orkestrering, kluster och Kubernetes är relaterade till varandra. På en hög nivå är orkestrering systemet som distribuerar och hanterar applikationer. För testautomatisering är sådana containeriserade applikationer Selenium Grid och Selenoid. Docker och K8s kompletterar varandra. Den första används för applikationsdistribution, den andra för orkestrering. I sin tur är K8s ett kluster. Klustrets uppgift är att använda virtuella datorer som noder, vilket gör att du kan installera olika funktioner, program och tjänster inom en server (kluster). Om någon av noderna misslyckas, kommer andra noder att plocka upp, vilket säkerställer oavbruten drift av vår applikation. Utöver detta har K8s viktig funktionalitet relaterad till skalning, tack vare vilken vi automatiskt får den optimala mängden resurser baserat på belastningen och sätter gränser.
Faktum är att manuellt distribuera Kubernetes från början inte alls en trivial uppgift. Jag lämnar en länk till den berömda instruktionsguiden "Kubernetes The Hard Way" och om du är intresserad kan du öva på den. Men lyckligtvis finns det alternativa metoder och verktyg. Det enklaste sättet är att använda Google Kubernetes Engine (GKE) i GCP, vilket gör att du kan få ett färdigt kluster med några få klick. Jag rekommenderar att du använder detta tillvägagångssätt för att börja lära dig, eftersom det låter dig fokusera på att lära dig hur du använder K8:erna för dina uppgifter istället för att lära dig hur de interna komponenterna ska integreras med varandra.
Värde för automationsinfrastruktur
Låt oss ta en titt på några viktiga funktioner som K8s tillhandahåller:
- applikationsdistribution: använder ett kluster med flera noder istället för virtuella datorer;
- dynamisk skalning: minskar kostnaden för resurser som endast används på begäran;
- självläkning: automatisk återhämtning av baljor (som ett resultat av vilket behållare också återställs);
- utrullning av uppdateringar och återställning av ändringar utan driftstopp: uppdateringsverktyg, webbläsare och emulatorer avbryter inte arbetet för nuvarande användare
Men K8s är fortfarande ingen silverkula. För att förstå alla fördelar och begränsningar i samband med de verktyg vi överväger (Selenium grid, Selenoid), kommer vi kort att diskutera strukturen för K8:or. Klustret innehåller två typer av noder: masternoder och arbetarnoder. Master Nodes ansvarar för hantering, driftsättning och schemaläggningsbeslut. Arbetarnoder är där applikationer startas. Noder innehåller också en containerruntime-miljö. I vårt fall är detta Docker, som ansvarar för containerrelaterad verksamhet. Men det finns också alternativa lösningar till exempel. Det är viktigt att förstå att fjällning eller självläkning inte gäller direkt för behållare. Detta implementeras genom att lägga till/minska antalet pods, som i sin tur innehåller containrar (vanligtvis en container per pod, men beroende på uppgift kan det finnas fler). Högnivåhierarkin består av arbetarnoder, inuti vilka det finns pods, inuti vilka containrar är upphöjda.
Skalningsfunktionen är nyckeln och kan tillämpas på både noder inom en klusternodpool och pods inom en nod. Det finns 2 typer av skalning som gäller både noder och poddar. Den första typen är horisontell - skalning sker genom att öka antalet noder/pods. Denna typ är mer att föredra. Den andra typen är följaktligen vertikal. Skalning utförs genom att öka storleken på noder/pods, och inte deras antal.
Låt oss nu titta på våra verktyg i samband med ovanstående termer.
Selen rutnät
Som nämnts tidigare är selennät ett mycket populärt verktyg, och det är ingen överraskning att det har blivit containeriserat. Därför kommer det inte som någon överraskning att selennät kan användas i K8s. Ett exempel på hur man gör detta kan hittas i det officiella K8s-förrådet. Som vanligt bifogar jag länkar i slutet av avsnittet. Dessutom visar instruktionsguiden hur man gör detta i Terraform. Det finns också instruktioner om hur man skalar antalet poddar som innehåller webbläsarbehållare. Men den automatiska skalningsfunktionen i K8s-sammanhang är fortfarande inte en helt självklar uppgift. När jag började studera hittade jag ingen praktisk vägledning eller rekommendationer. Efter flera studier och experiment med stöd av DevOps-teamet valde vi metoden att höja behållare med nödvändiga webbläsare inuti en pod, som är placerad inuti en arbetarnod. Denna metod tillåter oss att tillämpa strategin för horisontell skalning av noder genom att öka deras antal. Jag hoppas att detta kommer att förändras i framtiden och vi kommer att få se fler och fler beskrivningar av bättre tillvägagångssätt och färdiga lösningar, speciellt efter lanseringen av Selenium grid 4 med en förändrad intern arkitektur.
Selenoid:
Selenoiddistribution i K8s är för närvarande den största besvikelsen. De är inte kompatibla. I teorin kan vi höja en Selenoid-behållare inuti en pod, men när Selenoid börjar lansera containrar med webbläsare kommer de fortfarande att finnas i samma pod. Detta gör skalning omöjlig och som ett resultat kommer Selenoids arbete i ett kluster inte att skilja sig från arbete inuti en virtuell maskin. Slutet av berättelsen.
Månen:
Genom att känna till denna flaskhals när de arbetade med Selenoid, släppte utvecklarna ett kraftfullare verktyg som heter Moon. Det här verktyget designades ursprungligen för att fungera med Kubernetes och som ett resultat kan och bör funktionen för automatisk skalning användas. Dessutom skulle jag säga att det är det just nu bara ett verktyg i Selenium-världen, som har inbyggt K8s-klusterstöd direkt (inte längre tillgänglig, se nästa verktyg ). De viktigaste funktionerna hos Moon som ger detta stöd är:
Helt statslös. Selenoid lagrar information i minnet om webbläsarsessioner som körs för närvarande. Om dess process av någon anledning kraschar — då går alla pågående sessioner förlorade. Moon har däremot inget internt tillstånd och kan replikeras över datacenter. Webbläsarsessioner förblir vid liv även om en eller flera repliker försvinner.
Så, Moon är en bra lösning, men det finns ett problem: det är inte gratis. Priset beror på antalet sessioner. Du kan bara köra 0-4 sessioner gratis, vilket inte är särskilt användbart. Men från och med den femte sessionen måste du betala $5 för varje. Situationen kan skilja sig från företag till företag, men i vårt fall är det meningslöst att använda Moon. Som jag beskrev ovan kan vi köra virtuella datorer med Selenium Grid på begäran eller öka antalet noder i klustret. För ungefär en pipeline lanserar vi 500 webbläsare och stoppar alla resurser efter att testerna är slutförda. Om vi använde Moon skulle vi behöva betala ytterligare 500 x 5 = $2500 per månad, oavsett hur ofta vi kör tester. Återigen, jag säger inte att du inte använder Moon. För dina uppgifter kan detta vara en oumbärlig lösning, till exempel om du har många projekt/team i din organisation och du behöver ett enormt gemensamt kluster för alla. Som alltid lämnar jag en länk i slutet och rekommenderar att du gör alla nödvändiga beräkningar i samband med din uppgift.
Callisto: (Uppmärksamhet! Detta finns inte i originalartikeln och finns endast i den ryska översättningen)
Selen är som sagt ett väldigt populärt verktyg och IT-området utvecklas väldigt snabbt. Medan jag arbetade med översättningen dök ett nytt lovande verktyg kallat Callisto upp på webben (hej Cypress och andra selenmördare). Det fungerar inbyggt med K8s och låter dig köra Selenoid-behållare i pods, fördelade över noder. Allt fungerar direkt ur lådan, inklusive automatisk skalning. Fantastiskt, men måste testas. Jag har redan lyckats distribuera det här verktyget och köra flera experiment. Men det är för tidigt att dra slutsatser, efter att ha fått resultat över en lång sträcka kanske jag kommer att göra en recension i framtida artiklar. För närvarande lämnar jag bara länkar för oberoende forskning.
Illustration av infrastrukturens nuvarande tillstånd
Länkar att utforska
Liknande verktyg
7. Infrastruktur som kod (IaC)
Kort beskrivning av tekniken
Och nu kommer vi till det sista avsnittet. Vanligtvis är denna teknik och relaterade uppgifter inte automationsingenjörernas ansvar. Och det finns skäl till detta. För det första, i många organisationer är infrastrukturfrågor under kontroll av DevOps-avdelningen och utvecklingsteamen bryr sig inte riktigt om vad som får pipelinen att fungera och hur allt som är kopplat till den behöver stödjas. För det andra, låt oss vara ärliga, praxisen med Infrastructure as Code (IaC) är fortfarande inte antagen i många företag. Men det har definitivt blivit en populär trend och det är viktigt att försöka vara delaktig i de processer, tillvägagångssätt och verktyg som är kopplade till det. Eller åtminstone hålla dig uppdaterad.
Låt oss börja med motivationen för att använda detta tillvägagångssätt. Vi har redan diskuterat att för att köra tester i GitlabCI kommer vi att behöva minst resurserna för att köra Gitlab Runner. Och för att köra behållare med webbläsare/emulatorer måste vi reservera en virtuell dator eller ett kluster. Förutom testresurser behöver vi en betydande mängd kapacitet för att stödja utveckling, iscensättning, produktionsmiljöer, vilket även inkluderar databaser, automatiska scheman, nätverkskonfigurationer, lastbalanserare, användarrättigheter och så vidare. Nyckelfrågan är den ansträngning som krävs för att stödja det hela. Det finns flera sätt vi kan göra ändringar och lansera uppdateringar. Till exempel, i samband med GCP, kan vi använda UI-konsolen i webbläsaren och utföra alla åtgärder genom att klicka på knappar. Ett alternativ skulle vara att använda API-anrop för att interagera med molnenheter, eller använda kommandoradsverktyget gcloud för att utföra de önskade manipulationerna. Men med ett riktigt stort antal olika enheter och infrastrukturelement blir det svårt eller till och med omöjligt att utföra alla operationer manuellt. Dessutom är alla dessa manuella åtgärder okontrollerbara. Vi kan inte skicka in dem för granskning innan de körs, använda ett versionskontrollsystem och snabbt återställa ändringarna som ledde till incidenten. För att lösa sådana problem har ingenjörer skapat och skapat automatiska bash/shell-skript, som inte är mycket bättre än tidigare metoder, eftersom de inte är så lätta att snabbt läsa, förstå, underhålla och modifiera i en procedurstil.
I den här artikeln och guiden använder jag 2 verktyg relaterade till IaC-övningar. Dessa är Terraform och Ansible. Vissa människor tror att det inte är meningsfullt att använda dem samtidigt, eftersom deras funktionalitet är liknande och de är utbytbara. Men faktum är att de till en början får helt andra uppgifter. Och det faktum att dessa verktyg borde komplettera varandra bekräftades vid en gemensam presentation av utvecklare som representerar HashiCorp och RedHat. Den konceptuella skillnaden är att Terraform är ett provisioneringsverktyg för att hantera själva servrarna. Medan Ansible är ett konfigurationshanteringsverktyg vars uppgift är att installera, konfigurera och hantera programvara på dessa servrar.
En annan viktig utmärkande egenskap hos dessa verktyg är kodningsstilen. Till skillnad från bash och Ansible använder Terraform en deklarativ stil baserad på en beskrivning av det önskade sluttillståndet som ska uppnås som ett resultat av exekvering. Om vi till exempel ska skapa 10 virtuella datorer och tillämpa ändringarna genom Terraform, kommer vi att få 10 virtuella datorer. Om vi kör skriptet igen kommer ingenting att hända eftersom vi redan har 10 virtuella datorer, och Terraform vet om detta eftersom det lagrar det aktuella tillståndet för infrastrukturen i en tillståndsfil. Men Ansible använder ett procedurmässigt tillvägagångssätt och om du ber den att skapa 10 virtuella datorer, kommer vi vid den första lanseringen att få 10 virtuella datorer, liknande Terraform. Men efter omstart har vi redan 20 virtuella datorer. Detta är den viktiga skillnaden. I procedurstil lagrar vi inte det aktuella tillståndet och beskriver helt enkelt en sekvens av steg som måste utföras. Naturligtvis kan vi hantera olika situationer, lägga till flera kontroller för att det finns resurser och det aktuella tillståndet, men det är ingen idé att slösa bort vår tid och lägga kraft på att kontrollera denna logik. Dessutom ökar detta risken att göra misstag.
Genom att sammanfatta allt ovan kan vi dra slutsatsen att Terraform och deklarativ notation är ett mer lämpligt verktyg för att tillhandahålla servrar. Men det är bättre att delegera arbetet med konfigurationshantering till Ansible. Med det ur vägen, låt oss titta på användningsfall i samband med automatisering.
Värde för automationsinfrastruktur
Det enda viktiga att förstå här är att testautomationsinfrastrukturen bör betraktas som en del av hela företagets infrastruktur. Detta innebär att all IaC-praxis måste tillämpas globalt på hela organisationens resurser. Vem som ansvarar för detta beror på dina processer. DevOps-teamet är mer erfarna i dessa frågor, de ser hela bilden av vad som händer. QA-ingenjörer är dock mer involverade i processen för byggnadsautomation och strukturen i pipelinen, vilket gör att de bättre kan se alla nödvändiga förändringar och möjligheter till förbättringar. Det bästa alternativet är att arbeta tillsammans, utbyta kunskap och idéer för att uppnå det förväntade resultatet.
Här är några exempel på användning av Terraform och Ansible i samband med testautomatisering och de verktyg vi diskuterade tidigare:
1. Beskriv nödvändiga egenskaper och parametrar för virtuella datorer och kluster med hjälp av Terraform.
2. Använd Ansible, installera de verktyg som krävs för att testa: docker, Selenoid, Selenium Grid och ladda ner de nödvändiga versionerna av webbläsare/emulatorer.
3. Använd Terraform och beskriv egenskaperna hos den virtuella datorn där GitLab Runner kommer att lanseras.
4. Installera GitLab Runner och de nödvändiga medföljande verktygen med Ansible, ställ in inställningar och konfigurationer.
Illustration av infrastrukturens nuvarande tillstånd
Länkar att utforska:
Liknande verktyg
Låt oss sammanfatta det!
Steg
Teknologi
verktyg
Värde för automationsinfrastruktur
1
Lokal löpning
Node.js, Selen, Appium
- De mest populära verktygen för webb och mobil
- Stöder många språk och plattformar (inklusive Node.js)
2
Versionsstyrsystem
gå
- Liknande fördelar med utvecklingskod
3
container
Docker, selennät, selenoid (webb, Android)
- Köra tester parallellt
- Isolerade miljöer
- Enkla, flexibla versionsuppgraderingar
- Dynamiskt stoppa oanvända resurser
- Lätt att installera
4
CI/CD
Gitlab CI
- Testar en del av pipelinen
- Snabb feedback
- Synlighet för hela företaget/teamet
5
Cloud plattformar
Google Cloud Platform
- Resurser på begäran (vi betalar endast vid behov)
- Lätt att hantera och uppdatera
- Synlighet och kontroll över alla resurser
6
orkestrering
Kubernetes
I samband med behållare med webbläsare/emulatorer inuti pods:
- Skalning/automatisk skalning
- Självläkande
- Uppdateringar och återställningar utan avbrott
7
Infrastruktur som en kod (IaC)
Terraform, Ansible
- Liknande fördelar med utvecklingsinfrastruktur
- Alla fördelar med kodversionering
- Lätt att göra ändringar och underhålla
- Helt automatiserad
Tankekartadiagram: utveckling av infrastruktur
steg 1: Lokalt
steg 2: VCS
steg 3: Containerisering
steg 4: CI/CD
steg 5: Molnplattformar
steg 6:Orkestrering
steg 7: IaC
Vad händer nu?
Så här är slutet på artikeln. Men avslutningsvis skulle jag vilja upprätta några avtal med dig.
Från din sida
Som jag sa i början skulle jag vilja att artikeln skulle vara till praktisk användning och hjälpa dig att tillämpa kunskapen som du fått i verkligt arbete. lägger jag till igen.
Men även efter det, sluta inte, öva, studera relevanta länkar och böcker, ta reda på hur det fungerar i ditt företag, hitta platser som kan förbättras och ta del av det. Lycka till!
Från min sida
Av titeln kan man se att detta bara var den första delen. Trots att det visade sig vara ganska stort, tas viktiga ämnen fortfarande inte upp här. I den andra delen planerar jag att titta på automationsinfrastruktur i IOS-sammanhang. På grund av Apples restriktioner för att köra iOS-simulatorer endast på macOS-system, är vårt utbud av lösningar begränsat. Till exempel kan vi inte använda Docker för att köra simulatorn eller offentliga moln för att köra virtuella maskiner. Men det betyder inte att det inte finns några andra alternativ. Jag ska försöka hålla dig uppdaterad med avancerade lösningar och moderna verktyg!
Dessutom har jag inte nämnt ganska stora ämnen relaterade till övervakning. I del 3 ska jag titta på de mest populära verktygen för övervakning av infrastruktur och vilka data och mätvärden som ska beaktas.
Och slutligen. I framtiden planerar jag att släppa en videokurs om att bygga testinfrastruktur och populära verktyg. För närvarande finns det en hel del kurser och föreläsningar om DevOps på Internet, men allt material presenteras i utvecklingssammanhang, inte testautomatisering. I den här frågan behöver jag verkligen feedback om huruvida en sådan kurs kommer att vara intressant och värdefull för gemenskapen av testare och automationsingenjörer. Tack på förhand!
Källa: will.com