Partea 1: Web/Android
Nota: acest articol este o traducere în rusă a articolului original Cu toate acestea, toate ilustrațiile, linkurile, citatele și termenii sunt păstrate în limba originală pentru a evita denaturarea sensului atunci când sunt traduși în rusă. Îți doresc să studiezi fericit!
În prezent, specialitatea DevOps este una dintre cele mai căutate în industria IT. Dacă deschideți site-uri populare de căutare a unui loc de muncă și filtrați după salariu, veți vedea că locurile de muncă legate de DevOps sunt în fruntea listei. Cu toate acestea, este important de înțeles că aceasta se referă în principal la o poziție „Senior”, ceea ce implică faptul că candidatul are un nivel ridicat de abilități, cunoștințe de tehnologie și instrumente. Acest lucru vine și cu un grad ridicat de responsabilitate asociat cu funcționarea neîntreruptă a producției. Cu toate acestea, am început să uităm ce este DevOps. Inițial, nu a fost o persoană sau un departament anume. Dacă căutăm definiții ale acestui termen, vom găsi multe substantive frumoase și corecte, precum metodologie, practici, filozofie culturală, grup de concepte și așa mai departe.
Specializarea mea este inginer de automatizare a testelor (inginer de automatizare QA), dar cred că nu ar trebui să fie asociată doar cu scrierea autotestelor sau cu dezvoltarea arhitecturii cadru de testare. În 2020, cunoașterea infrastructurii de automatizare este, de asemenea, esențială. Acest lucru vă permite să organizați singur procesul de automatizare, de la efectuarea testelor până la furnizarea de rezultate tuturor părților interesate în conformitate cu obiectivele dumneavoastră. Drept urmare, abilitățile DevOps sunt o necesitate pentru a duce treaba la bun sfârșit. Și toate acestea sunt bune, dar, din păcate, există o problemă (spoiler: acest articol încearcă să simplifice această problemă). Ideea este că DevOps este greu. Și acest lucru este evident, deoarece companiile nu vor plăti foarte mult pentru ceva ce este ușor de făcut... În lumea DevOps, există un număr mare de instrumente, termeni și practici care trebuie stăpânite. Acest lucru este deosebit de dificil la începutul unei cariere și depinde de experiența tehnică acumulată.
Sursa:
Aici probabil vom termina cu partea introductivă și ne vom concentra pe scopul acestui articol.
Despre ce este acest articol?
În acest articol, voi împărtăși experiența mea în construirea unei infrastructuri de automatizare de testare. Există multe surse de informații pe Internet despre diverse instrumente și despre modul de utilizare a acestora, dar aș dori să le privesc doar în contextul automatizării. Cred că mulți ingineri în automatizare sunt familiarizați cu situația în care nimeni, în afară de tine, nu rulează testele dezvoltate sau îi pasă să le întrețină. Ca urmare, testele devin depășite și trebuie să petreceți timp pentru a le actualiza. Din nou, la începutul unei cariere, aceasta poate fi o sarcină destul de dificilă: să decideți cu înțelepciune ce instrumente ar trebui să ajute la eliminarea unei anumite probleme, cum să le selectați, să le configurați și să le întrețineți. Unii testeri apelează la DevOps (oameni) pentru ajutor și, să fim sinceri, această abordare funcționează. În multe cazuri, aceasta poate fi singura opțiune, deoarece nu avem vizibilitate asupra tuturor dependențelor. Dar, după cum știm, DevOps sunt băieți foarte ocupați, deoarece trebuie să se gândească la infrastructura întregii companii, implementare, monitorizare, microservicii și alte sarcini similare în funcție de organizație/echipă. După cum este de obicei cazul, automatizarea nu este o prioritate. Într-un astfel de caz, trebuie să încercăm să facem tot posibilul din partea noastră de la început până la sfârșit. Acest lucru va reduce dependențele, va accelera fluxul de lucru, ne va îmbunătăți abilitățile și ne va permite să vedem o imagine de ansamblu a ceea ce se întâmplă.
Articolul prezintă cele mai populare și populare instrumente și arată cum să le folosiți pentru a construi o infrastructură de automatizare pas cu pas. Fiecare grup este reprezentat de instrumente care au fost testate prin experiența personală. Dar asta nu înseamnă că trebuie să folosești același lucru. Instrumentele în sine nu sunt importante, apar și devin învechite. Sarcina noastră de inginerie este să înțelegem principiile de bază: de ce avem nevoie de acest grup de instrumente și ce probleme de lucru putem rezolva cu ajutorul lor. De aceea, la sfârșitul fiecărei secțiuni las link-uri către instrumente similare care pot fi folosite în organizația dumneavoastră.
Ce nu este în acest articol
Repet încă o dată că articolul nu este despre instrumente specifice, așa că nu vor exista inserții de cod din documentația și descrierile unor comenzi specifice. Dar la sfârșitul fiecărei secțiuni las link-uri pentru studiu detaliat.
Acest lucru se face deoarece:
- acest material este foarte ușor de găsit în diverse surse (documentare, cărți, cursuri video);
- dacă începem să mergem mai adânc, va trebui să scriem 10, 20, 30 de părți din acest articol (în timp ce planurile sunt 2-3);
- Pur și simplu nu vreau să-ți pierd timpul, deoarece ai putea dori să folosești alte instrumente pentru a atinge aceleași obiective.
Practică
Mi-aș dori foarte mult ca acest material să fie util fiecărui cititor, și nu doar citit și uitat. În orice studiu, practica este o componentă foarte importantă. Pentru asta m-am pregatit. De asemenea, vă așteaptă teme pentru a vă asigura că nu copiați fără minte rândurile comenzilor pe care le executați.
plan
Pas
Tehnologia
Instrumente
1
Funcționare locală (pregătiți teste demo web/android și rulați-le local)
Node.js, Selenium, Appium
2
Sisteme de control al versiunilor
merge
3
Containerizare
Docker, Selenium grid, Selenoid (Web, Android)
4
CI/CD
Gitlab CI
5
Platforme de nori
Platforma Google Cloud
6
Orchestrarea
Kubernetes
7
Infrastructura ca cod (IaC)
Terraform, Ansible
Structura fiecărei secțiuni
Pentru a menține narațiunea clară, fiecare secțiune este descrisă în conformitate cu următoarea schiță:
- Scurtă descriere a tehnologiei,
- valoare pentru infrastructura de automatizare,
- ilustrare a stării actuale a infrastructurii,
- link-uri spre studiu,
- instrumente similare.
1. Rulați teste la nivel local
Scurtă descriere a tehnologiei
Acesta este doar un pas pregătitor pentru a rula testele demo la nivel local și pentru a verifica dacă acestea trec. În partea practică, se folosește Node.js, dar nici limbajul de programare și platforma nu sunt importante și le poți folosi pe cele care sunt folosite în compania ta.
Cu toate acestea, ca instrumente de automatizare, vă recomand să utilizați Selenium WebDriver pentru platformele web și, respectiv, Appium pentru platforma Android, deoarece în următorii pași vom folosi imagini Docker care sunt adaptate pentru a funcționa special cu aceste instrumente. Mai mult, referitor la cerințele postului, aceste instrumente sunt cele mai căutate pe piață.
După cum probabil ați observat, luăm în considerare doar testele web și Android. Din păcate, iOS este o poveste complet diferită (mulțumesc Apple). Plănuiesc să prezint soluții și practici legate de IOS în părțile viitoare.
Valoare pentru infrastructura de automatizare
Din perspectiva infrastructurii, rularea locală nu oferă nicio valoare. Verificați doar dacă testele rulează pe mașina locală în browsere și simulatoare locale. Dar, în orice caz, acesta este un punct de plecare necesar.
Ilustrație a stării actuale a infrastructurii
Link-uri de explorat
Instrumente similare
- orice limbaj de programare care vă place împreună cu testele Selenium/Appium;
- orice teste;
- orice alergător de testare.
2. Sisteme de control al versiunilor (Git)
Scurtă descriere a tehnologiei
Nu va fi o mare revelație pentru nimeni dacă spun că controlul versiunilor este o parte extrem de importantă a dezvoltării, atât în echipă, cât și individual. Pe baza diferitelor surse, este sigur să spunem că Git este cel mai popular reprezentant. Un sistem de control al versiunilor oferă multe beneficii, cum ar fi partajarea codului, stocarea versiunilor, restaurarea la ramurile anterioare, monitorizarea istoricului proiectului și backup-urile. Nu vom discuta fiecare punct în detaliu, deoarece sunt sigur că sunteți foarte familiarizat cu el și îl folosiți în munca de zi cu zi. Dar dacă dintr-o dată nu, atunci recomand să întrerupeți citirea acestui articol și să umpleți acest gol cât mai curând posibil.
Valoare pentru infrastructura de automatizare
Și aici puteți pune o întrebare rezonabilă: „De ce ne vorbește despre Git? Toată lumea știe acest lucru și îl folosește atât pentru codul de dezvoltare, cât și pentru codul de auto-test.” Veți avea perfectă dreptate, dar în acest articol vorbim despre infrastructură și această secțiune acționează ca o previzualizare pentru secțiunea 7: „Infrastructura ca cod (IaC)”. Pentru noi, aceasta înseamnă că întreaga infrastructură, inclusiv testarea, este descrisă sub formă de cod, astfel încât să îi putem aplica și sisteme de versiuni și să obținem beneficii similare ca și pentru codul de dezvoltare și automatizare.
Ne vom uita la IaC mai detaliat în Pasul 7, dar chiar și acum puteți începe să utilizați Git local prin crearea unui depozit local. Imaginea de ansamblu va fi extinsă atunci când vom adăuga un depozit la distanță la infrastructură.
Ilustrație a stării actuale a infrastructurii
Link-uri de explorat
Instrumente similare
3. Containerizare (Docker)
Scurtă descriere a tehnologiei
Pentru a demonstra modul în care containerizarea a schimbat regulile jocului, să ne întoarcem în timp cu câteva decenii. Pe atunci, oamenii cumpărau și foloseau mașini server pentru a rula aplicații. Dar, în majoritatea cazurilor, resursele necesare pentru pornire nu erau cunoscute dinainte. Drept urmare, companiile au cheltuit bani pentru achiziționarea de servere scumpe și puternice, dar o parte din această capacitate nu a fost utilizată complet.
Următoarea etapă a evoluției au fost mașinile virtuale (VM), care au rezolvat problema risipei banilor pe resursele neutilizate. Această tehnologie a făcut posibilă rularea aplicațiilor independent unele de altele în cadrul aceluiași server, alocând spațiu complet izolat. Dar, din păcate, orice tehnologie are dezavantajele ei. Rularea unui VM necesită un sistem de operare complet, care consumă CPU, RAM, spațiu de stocare și, în funcție de sistemul de operare, trebuie luate în considerare costurile de licență. Acești factori afectează viteza de încărcare și fac portabilitatea dificilă.
Și acum ajungem la containerizare. Încă o dată, această tehnologie rezolvă problema anterioară, deoarece containerele nu folosesc un sistem de operare complet, ceea ce eliberează o cantitate mare de resurse și oferă o soluție rapidă și flexibilă pentru portabilitate.
Desigur, tehnologia containerizării nu este nimic nou și a fost introdusă pentru prima dată la sfârșitul anilor 70. În acele zile, au fost efectuate o mulțime de cercetări, dezvoltări și încercări. Dar Docker a fost cel care a adaptat această tehnologie și a făcut-o ușor accesibilă maselor. În zilele noastre, când vorbim de containere, în majoritatea cazurilor ne referim la Docker. Când vorbim despre containere Docker, ne referim la containere Linux. Putem folosi sisteme Windows și macOS pentru a rula containere, dar este important să înțelegem că în acest caz apare un strat suplimentar. De exemplu, Docker pe Mac rulează în tăcere containere într-o mașină virtuală Linux ușoară. Vom reveni la acest subiect când vom discuta despre rularea emulatoarelor Android în interiorul containerelor, așa că aici există o nuanță foarte importantă care trebuie discutată mai detaliat.
Valoare pentru infrastructura de automatizare
Am aflat că containerizarea și Docker sunt cool. Să ne uităm la asta în contextul automatizării, deoarece fiecare instrument sau tehnologie trebuie să rezolve o problemă. Să subliniem problemele evidente ale automatizării testelor în contextul testelor UI:
- un număr mare de dependențe la instalarea Selenium și în special Appium;
- probleme de compatibilitate între versiunile de browsere, simulatoare și drivere;
- lipsa spațiului izolat pentru browsere/simulatoare, ceea ce este deosebit de critic pentru rularea în paralel;
- dificil de gestionat și întreținut dacă trebuie să rulați 10, 50, 100 sau chiar 1000 de browsere în același timp.
Dar, deoarece Selenium este cel mai popular instrument de automatizare și Docker este cel mai popular instrument de containerizare, nu ar trebui să fie surprinzător că cineva a încercat să le combine pentru a crea un instrument puternic pentru a rezolva problemele menționate mai sus. Să luăm în considerare astfel de soluții mai detaliat.
Grilă de seleniu în docker
Acest instrument este cel mai popular din lumea Selenium pentru rularea mai multor browsere pe mai multe mașini și gestionarea acestora dintr-un hub central. Pentru a începe, trebuie să înregistrați cel puțin 2 părți: Hub și Node(e). Hub este un nod central care primește toate solicitările din teste și le distribuie nodurilor corespunzătoare. Pentru fiecare Nod putem configura o anumită configurație, de exemplu, specificând browserul dorit și versiunea acestuia. Cu toate acestea, trebuie să avem grijă de driverele de browser compatibile și să le instalăm pe nodurile dorite. Din acest motiv, grila Selenium nu este folosită în forma sa pură, cu excepția cazului în care trebuie să lucrăm cu browsere care nu pot fi instalate pe sistemul de operare Linux. Pentru toate celelalte cazuri, o soluție semnificativ flexibilă și corectă ar fi utilizarea imaginilor Docker pentru a rula Selenium grid Hub și Nodes. Această abordare simplifică foarte mult gestionarea nodurilor, deoarece putem selecta imaginea de care avem nevoie cu versiuni compatibile de browsere și drivere deja instalate.
În ciuda recenziilor negative despre stabilitate, în special atunci când rulează un număr mare de Noduri în paralel, grila Selenium este încă cel mai popular instrument pentru rularea testelor Selenium în paralel. Este important de reținut că în open-source apar în mod constant diverse îmbunătățiri și modificări ale acestui instrument, care combate diverse blocaje.
Selenoid pentru Web
Acest instrument este o descoperire în lumea seleniului, deoarece funcționează imediat din cutie și a făcut viața multor ingineri în automatizare mult mai ușoară. În primul rând, aceasta nu este o altă modificare a grilei Selenium. În schimb, dezvoltatorii au creat o versiune complet nouă a Selenium Hub în Golang, care, combinată cu imagini Docker ușoare pentru diferite browsere, a dat impuls dezvoltării automatizării testelor. Mai mult, în cazul Selenium Grid, trebuie să stabilim în prealabil toate browserele necesare și versiunile acestora, ceea ce nu este o problemă atunci când lucrăm cu un singur browser. Dar când vine vorba de mai multe browsere acceptate, Selenoid este soluția numărul unu datorită funcției sale „browser la cerere”. Tot ceea ce ni se cere este să descarcăm în avans imaginile necesare cu browsere și să actualizăm fișierul de configurare cu care interacționează Selenoid. După ce Selenoid primește o solicitare de la teste, va lansa automat containerul dorit cu browserul dorit. Când testul se finalizează, Selenoid va retrage containerul, eliberând astfel resurse pentru cererile viitoare. Această abordare elimină complet problema binecunoscută a „degradării nodurilor” pe care o întâlnim adesea în grila Selenium.
Dar, din păcate, Selenoid încă nu este un glonț de argint. Avem funcția „browser la cerere”, dar funcția „resurse la cerere” încă nu este disponibilă. Pentru a folosi Selenoid, trebuie să-l implementăm pe hardware fizic sau pe o VM, ceea ce înseamnă că trebuie să știm dinainte câte resurse trebuie alocate. Bănuiesc că aceasta nu este o problemă pentru proiectele mici care rulează 10, 20 sau chiar 30 de browsere în paralel. Dar dacă avem nevoie de 100, 500, 1000 și mai mult? Nu are sens să menții și să plătești pentru atâtea resurse tot timpul. În secțiunile 5 și 6 din acest articol, vom discuta despre soluții care vă permit să extindeți, reducând astfel semnificativ costurile companiei.
Selenoid pentru Android
După succesul Selenoid ca instrument de automatizare web, oamenii și-au dorit ceva similar pentru Android. Și s-a întâmplat - Selenoid a fost lansat cu suport Android. Din punct de vedere al utilizatorului la nivel înalt, principiul de funcționare este similar cu automatizarea web. Singura diferență este că, în loc de containere de browser, Selenoid rulează containere de emulator Android. În opinia mea, acesta este în prezent cel mai puternic instrument gratuit pentru a rula teste Android în paralel.
Chiar nu mi-ar plăcea să vorbesc despre aspectele negative ale acestui instrument, deoarece îmi place foarte mult. Dar totuși, există aceleași dezavantaje care se aplică automatizării web și sunt asociate cu scalarea. Pe lângă aceasta, trebuie să vorbim despre încă o limitare care poate fi o surpriză dacă instalăm instrumentul pentru prima dată. Pentru a rula imagini Android, avem nevoie de o mașină fizică sau VM cu suport de virtualizare imbricată. În ghidul de utilizare, vă demonstrez cum să activați acest lucru pe o mașină virtuală Linux. Cu toate acestea, dacă sunteți utilizator macOS și doriți să implementați Selenoid la nivel local, atunci nu va fi posibil să rulați teste Android. Dar puteți rula oricând o mașină virtuală Linux la nivel local cu „virtualizarea imbricată” configurată și să implementați Selenoid în interior.
Ilustrație a stării actuale a infrastructurii
În contextul acestui articol, vom adăuga 2 instrumente pentru a ilustra infrastructura. Acestea sunt grila Selenium pentru testele web și Selenoid pentru testele Android. În tutorialul GitHub, vă voi arăta și cum să utilizați Selenoid pentru a rula teste web.
Link-uri de explorat
Instrumente similare
- Există și alte instrumente de containerizare, dar Docker este cel mai popular. Dacă doriți să încercați altceva, rețineți că instrumentele pe care le-am acoperit pentru rularea în paralel a testelor cu seleniu nu vor funcționa imediat.
- După cum sa spus deja, există multe modificări ale rețelei de seleniu, de exemplu,.
4.CI/CD
Scurtă descriere a tehnologiei
Practica integrării continue este destul de populară în dezvoltare și este la egalitate cu sistemele de control al versiunilor. În ciuda acestui fapt, simt că există confuzie în terminologie. În acest paragraf aș dori să descriu 3 modificări ale acestei tehnologii din punctul meu de vedere. Pe internet vei gasi multe articole cu interpretari diferite, si este absolut normal daca parerea ta difera. Cel mai important lucru este că ești pe aceeași pagină cu colegii tăi.
Deci, există 3 termeni: CI - Integrare continuă, CD - Livrare continuă și din nou CD - Implementare continuă. (Mai jos voi folosi acești termeni în engleză). Fiecare modificare adaugă câțiva pași suplimentari conductei de dezvoltare. Dar cuvântul continuu (continuu) este cel mai important lucru. În acest context, ne referim la ceva care se întâmplă de la început până la sfârșit, fără întrerupere sau intervenție manuală. Să ne uităm la CI & CD și CD în acest context.
- Integrare continuă acesta este pasul inițial al evoluției. După trimiterea unui cod nou pe server, ne așteptăm să primim feedback rapid că modificările noastre sunt ok. În mod obișnuit, CI include rularea instrumentelor de analiză statică a codului și teste API unitare/interne. Acest lucru ne permite să obținem informații despre codul nostru în câteva secunde/minute.
- Livrarea continuă este un pas mai avansat în care rulăm teste de integrare/UI. Cu toate acestea, în această etapă nu obținem rezultate la fel de repede ca în cazul CI. În primul rând, aceste tipuri de teste durează mai mult. În al doilea rând, înainte de lansare, trebuie să implementăm modificările noastre în mediul de testare/staging. Mai mult, dacă vorbim despre dezvoltarea mobilă, atunci apare un pas suplimentar pentru a crea o versiune a aplicației noastre.
- Implementare continuă presupune că eliberăm automat modificările noastre în producție dacă toate testele de acceptare au fost trecute în etapele anterioare. În plus, după etapa de lansare, puteți configura diverse etape, cum ar fi efectuarea de teste de fum pe producție și colectarea de valori de interes. Implementarea continuă este posibilă numai cu o bună acoperire prin teste automate. Dacă sunt necesare intervenții manuale, inclusiv testare, atunci aceasta nu mai este Continuu (continuu). Apoi putem spune că conducta noastră respectă doar practica livrării continue.
Valoare pentru infrastructura de automatizare
În această secțiune, ar trebui să clarific că atunci când vorbim despre testele UI end-to-end, înseamnă că ar trebui să implementăm modificările noastre și serviciile asociate pentru medii de testare. Integrare continuă - procesul nu este aplicabil pentru această sarcină și trebuie să avem grijă să implementăm cel puțin practicile de livrare continuă. Implementarea continuă are sens, de asemenea, în contextul testelor UI, dacă le vom rula în producție.
Și înainte de a ne uita la ilustrarea schimbării arhitecturii, vreau să spun câteva cuvinte despre GitLab CI. Spre deosebire de alte instrumente CI/CD, GitLab oferă un depozit de la distanță și multe alte funcții suplimentare. Astfel, GitLab este mai mult decât CI. Acesta include managementul codului sursă, managementul Agile, conductele CI/CD, instrumente de logare și colectarea de valori imediate. Arhitectura GitLab este formată din Gitlab CI/CD și GitLab Runner. Iată o scurtă descriere de pe site-ul oficial:
Gitlab CI/CD este o aplicație web cu un API care își stochează starea într-o bază de date, gestionează proiecte/build-uri și oferă o interfață cu utilizatorul. GitLab Runner este o aplicație care procesează build-uri. Poate fi implementat separat și funcționează cu GitLab CI/CD printr-un API. Pentru testele care rulează, aveți nevoie atât de instanță Gitlab, cât și de Runner.
Ilustrație a stării actuale a infrastructurii
Link-uri de explorat
Instrumente similare
- Și multe altele
5. Platforme cloud
Scurtă descriere a tehnologiei
În această secțiune vom vorbi despre o tendință populară numită „nori publici”. În ciuda beneficiilor enorme pe care le oferă tehnologiile de virtualizare și containerizare descrise mai sus, avem încă nevoie de resurse de calcul. Companiile achiziționează servere scumpe sau închiriază centre de date, dar în acest caz este necesar să facem calcule (uneori nerealiste) de câte resurse vom avea nevoie, dacă le vom folosi 24/7 și în ce scopuri. De exemplu, producția necesită un server care rulează XNUMX/XNUMX, dar avem nevoie de resurse similare pentru testare în afara orelor de lucru? Depinde și de tipul de testare efectuată. Un exemplu ar fi testele de sarcină/stres pe care intenționăm să le rulăm în timpul orelor de lucru pentru a obține rezultate a doua zi. Dar cu siguranță disponibilitatea serverului XNUMX/XNUMX nu este necesară pentru testele automate end-to-end și mai ales pentru mediile de testare manuală. Pentru astfel de situații, ar fi bine să obțineți câte resurse este nevoie la cerere, să le folosiți și să nu mai plătiți atunci când nu mai sunt necesare. Mai mult, ar fi grozav să le primiți instantaneu făcând câteva clicuri de mouse sau rulând câteva scripturi. Pentru asta sunt folosite norii publici. Să ne uităm la definiție:
„Clodul public este definit ca servicii de calcul oferite de furnizori terți prin internetul public, făcându-le disponibile oricui dorește să le folosească sau să le cumpere. Acestea pot fi gratuite sau vândute la cerere, permițând clienților să plătească numai pentru fiecare utilizare pentru ciclurile CPU, stocarea sau lățimea de bandă pe care o consumă.”
Există o părere că norii publici sunt scumpi. Dar ideea lor cheie este reducerea costurilor companiei. După cum am menționat mai devreme, cloud-urile publice vă permit să obțineți resurse la cerere și să plătiți numai pentru timpul în care le utilizați. De asemenea, uneori uităm că angajații primesc salarii, iar specialiștii sunt și ei o resursă costisitoare. Trebuie luat în considerare faptul că cloud-urile publice facilitează mult suportul infrastructurii, ceea ce le permite inginerilor să se concentreze pe sarcini mai importante.
Valoare pentru infrastructura de automatizare
De ce resurse specifice avem nevoie pentru testele UI de la capăt la capăt? Practic, acestea sunt mașini virtuale sau clustere (vom vorbi despre Kubernetes în secțiunea următoare) pentru rularea browserelor și emulatoarelor. Cu cât dorim să rulăm simultan mai multe browsere și emulatori, cu atât este nevoie de mai mult CPU și memorie și cu atât mai mulți bani trebuie să plătim pentru el. Astfel, norii publici în contextul automatizării testelor ne permit să rulăm un număr mare (100, 200, 1000...) de browsere/emulatori la cerere, să obținem rezultate ale testelor cât mai repede posibil și să nu mai plătim pentru atât de consumatoare de resurse. putere.
Cei mai populari furnizori de cloud sunt Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). Ghidul de utilizare oferă exemple despre cum să utilizați GCP, dar, în general, nu contează ce folosiți pentru sarcinile de automatizare. Toate oferă aproximativ aceeași funcționalitate. De obicei, pentru a selecta un furnizor, managementul se concentrează pe întreaga infrastructură și pe cerințele de afaceri ale companiei, ceea ce depășește domeniul de aplicare al acestui articol. Pentru inginerii de automatizare, va fi mai interesant să compare utilizarea furnizorilor de cloud cu utilizarea platformelor cloud special în scopuri de testare, cum ar fi Sauce Labs, BrowserStack, BitBar și așa mai departe. Deci hai sa o facem si noi! În opinia mea, Sauce Labs este cea mai cunoscută fermă de testare în cloud, motiv pentru care am folosit-o pentru comparație.
GCP vs Sauce Labs în scopuri de automatizare:
Să ne imaginăm că trebuie să rulăm simultan 8 teste web și 8 teste Android. Pentru aceasta vom folosi GCP și vom rula 2 mașini virtuale cu Selenoid. Pe primul vom ridica 8 containere cu browsere. Pe al doilea sunt 8 containere cu emulatori. Să ne uităm la prețuri:
Pentru a rula un container cu Chrome, avem nevoie n1-standard-1 mașină. În cazul Android va fi n1-standard-4 pentru un emulator. De fapt, o modalitate mai flexibilă și mai ieftină este de a seta anumite valori de utilizator pentru CPU/Memorie, dar în acest moment acest lucru nu este important pentru comparație cu Sauce Labs.
Și iată tarifele pentru utilizarea Sauce Labs:
Cred că ați observat deja diferența, dar voi oferi în continuare un tabel cu calcule pentru sarcina noastră:
Resurse necesare
Lunar
Ore de lucru(8:8 - XNUMX:XNUMX)
Ore de lucru+ Preemptibil
GCP pentru web
n1-standard-1 x 8 = n1-standard-8
$194.18
23 de zile * 12 ore * 0.38 = 104.88 USD
23 de zile * 12 ore * 0.08 = 22.08 USD
Laboratoarele de sos pentru web
Virtual Cloud8 teste paralele
$1.559
-
-
GCP pentru Android
n1-standard-4 x 8: n1-standard-16
$776.72
23 de zile * 12 ore * 1.52 = 419.52 USD
23 de zile * 12 ore * 0.32 = 88.32 USD
Sauce Labs pentru Android
Real Device Cloud 8 teste paralele
$1.999
-
-
După cum puteți vedea, diferența de cost este uriașă, mai ales dacă efectuați teste doar pe o perioadă de douăsprezece ore de lucru. Dar puteți reduce costurile și mai mult dacă utilizați mașini preemptibile. Ce este?
O VM preemptibilă este o instanță pe care o puteți crea și rula la un preț mult mai mic decât instanțe normale. Cu toate acestea, Compute Engine poate opri (preemptează) aceste instanțe dacă necesită acces la acele resurse pentru alte sarcini. Instanțele preemptibile reprezintă capacitatea excesivă a Compute Engine, astfel încât disponibilitatea lor variază în funcție de utilizare.
Dacă aplicațiile dvs. sunt tolerante la erori și pot rezista posibilelor preempționări ale instanțelor, atunci instanțele preempțibile vă pot reduce costurile Compute Engine în mod semnificativ. De exemplu, joburile de procesare în lot pot rula pe instanțe preemptibile. Dacă unele dintre aceste instanțe se încheie în timpul procesării, lucrarea încetinește, dar nu se oprește complet. Instanțele preemptibile completează sarcinile de procesare în lot fără a pune încărcătură suplimentară de lucru asupra instanțelor existente și fără a fi necesar să plătiți prețul întreg pentru instanțe normale suplimentare.
Și încă nu s-a terminat! În realitate, sunt sigur că nimeni nu face teste timp de 12 ore fără pauză. Și dacă da, atunci puteți porni și opri automat mașinile virtuale atunci când nu sunt necesare. Timpul efectiv de utilizare poate fi redus la 6 ore pe zi. Apoi, plata în contextul sarcinii noastre va scădea la 11 USD pe lună pentru 8 browsere. Nu este minunat? Dar cu mașinile preemptibile trebuie să fim atenți și pregătiți pentru întreruperi și instabilitate, deși aceste situații pot fi prevăzute și gestionate în software. Se merită!
Dar în niciun caz nu spun „nu folosiți niciodată fermele de testare în cloud”. Au o serie de avantaje. În primul rând, aceasta nu este doar o mașină virtuală, ci o soluție completă de automatizare a testelor, cu un set de funcționalități ieșite din cutie: acces la distanță, jurnale, capturi de ecran, înregistrare video, diverse browsere și dispozitive mobile fizice. În multe situații, aceasta poate fi o alternativă șic esențială. Platformele de testare sunt utile în special pentru automatizarea IOS, când cloud-urile publice pot oferi doar sisteme Linux/Windows. Dar despre iOS vom vorbi în articolele următoare. Recomand să te uiți mereu la situație și să pleci de la sarcini: în unele cazuri este mai ieftin și mai eficient să folosești cloud-urile publice, iar în altele platformele de testare merită cu siguranță banii cheltuiți.
Ilustrație a stării actuale a infrastructurii
Link-uri de explorat
Instrumente similare:
6. Orchestrare
Scurtă descriere a tehnologiei
Am o veste bună – suntem aproape la sfârșitul articolului! În acest moment, infrastructura noastră de automatizare constă în teste web și Android, pe care le rulăm prin GitLab CI în paralel, folosind instrumente activate pentru Docker: grila Selenium și Selenoid. Mai mult, folosim mașini virtuale create prin GCP pentru a găzdui containere cu browsere și emulatori. Pentru a reduce costurile, pornim aceste mașini virtuale doar la cerere și le oprim atunci când testarea nu este efectuată. Mai există ceva care ne poate îmbunătăți infrastructura? Raspunsul este da! Faceți cunoștință cu Kubernetes (K8s)!
Mai întâi, să ne uităm la modul în care cuvintele orchestrare, cluster și Kubernetes sunt legate între ele. La un nivel înalt, orchestrarea este sistemul care implementează și gestionează aplicațiile. Pentru automatizarea testelor, astfel de aplicații containerizate sunt Selenium grid și Selenoid. Docker și K8-urile se completează reciproc. Primul este folosit pentru implementarea aplicației, al doilea pentru orchestrare. La rândul său, K8s este un cluster. Sarcina clusterului este să folosească VM-uri ca noduri, ceea ce vă permite să instalați diverse funcționalități, programe și servicii într-un singur server (cluster). Dacă vreunul dintre noduri eșuează, alte noduri vor relua, ceea ce asigură funcționarea neîntreruptă a aplicației noastre. Pe lângă aceasta, K8s are o funcționalitate importantă legată de scalare, datorită căreia obținem automat cantitatea optimă de resurse în funcție de încărcare și limitele stabilite.
De fapt, implementarea manuală a Kubernetes de la zero nu este deloc o sarcină banală. Îți voi lăsa un link către celebrul ghid „Kubernetes The Hard Way” și dacă ești interesat, îl poți exersa. Dar, din fericire, există metode și instrumente alternative. Cel mai simplu mod este să utilizați Google Kubernetes Engine (GKE) în GCP, ceea ce vă va permite să obțineți un cluster gata făcut în câteva clicuri. Vă recomand să utilizați această abordare pentru a începe să învățați, deoarece vă va permite să vă concentrați pe învățarea cum să utilizați K8-urile pentru sarcinile dvs., în loc să învățați cum ar trebui să fie integrate componentele interne unele cu altele.
Valoare pentru infrastructura de automatizare
Să aruncăm o privire la câteva caracteristici semnificative pe care le oferă K8s:
- implementarea aplicației: utilizarea unui cluster cu mai multe noduri în loc de VM;
- scalare dinamică: reduce costul resurselor care sunt utilizate doar la cerere;
- autovindecare: recuperarea automată a păstăilor (ca urmare a căreia containerele sunt și restaurate);
- lansarea actualizărilor și derularea modificărilor fără timp de nefuncționare: actualizarea instrumentelor, browserelor și emulatorilor nu întrerupe activitatea utilizatorilor actuali
Dar K8s încă nu este un glonț de argint. Pentru a înțelege toate avantajele și limitările în contextul instrumentelor pe care le avem în vedere (grilă seleniu, selenoid), vom discuta pe scurt structura K8-urilor. Clusterul conține două tipuri de Noduri: Noduri Master și Noduri de lucru. Nodurile principale sunt responsabile pentru deciziile de gestionare, implementare și programare. Nodurile de lucru sunt locul unde sunt rulate aplicațiile. Nodurile conțin și un mediu de rulare a containerului. În cazul nostru, acesta este Docker, care este responsabil pentru operațiunile legate de containere. Dar există și soluții alternative, de exemplu. Este important să înțelegeți că detartrarea sau auto-vindecarea nu se aplică direct recipientelor. Acest lucru este implementat prin adăugarea/scăderea numărului de păstăi, care la rândul lor conțin containere (de obicei un container per pod, dar în funcție de sarcină pot fi mai multe). Ierarhia de nivel înalt constă din noduri de lucru, în interiorul cărora există poduri, în interiorul cărora sunt ridicate containerele.
Caracteristica de scalare este esențială și poate fi aplicată atât nodurilor dintr-un grup de noduri de cluster, cât și podurilor dintr-un nod. Există 2 tipuri de scalare care se aplică atât nodurilor, cât și podurilor. Primul tip este orizontal - scalarea are loc prin creșterea numărului de noduri/pod-uri. Acest tip este mai de preferat. Al doilea tip este, în consecință, vertical. Scalare se realizează prin creșterea dimensiunii nodurilor/pod-urilor, și nu a numărului acestora.
Acum să ne uităm la instrumentele noastre în contextul termenilor de mai sus.
Grila cu seleniu
După cum am menționat mai devreme, grila cu seleniu este un instrument foarte popular și nu este surprinzător faptul că a fost containerizat. Prin urmare, nu este o surpriză faptul că grila Selenium poate fi implementată în K8-uri. Un exemplu despre cum să faceți acest lucru poate fi găsit în depozitul oficial K8s. Ca de obicei, atașez link-uri la sfârșitul secțiunii. În plus, ghidul de instrucțiuni arată cum să faceți acest lucru în Terraform. Există, de asemenea, instrucțiuni despre cum să scalați numărul de pod-uri care conțin containere de browser. Dar funcția de scalare automată în contextul K8-urilor nu este încă o sarcină complet evidentă. Când am început să studiez, nu am găsit nicio îndrumare practică sau recomandări. După mai multe studii și experimente cu sprijinul echipei DevOps, am ales abordarea ridicării containerelor cu browserele necesare în interiorul unui pod, care se află în interiorul unui nod de lucru. Această metodă ne permite să aplicăm strategia de scalare orizontală a nodurilor prin creșterea numărului acestora. Sper că acest lucru se va schimba în viitor și vom vedea din ce în ce mai multe descrieri ale abordărilor mai bune și soluțiilor gata făcute, mai ales după lansarea Selenium grid 4 cu o arhitectură internă schimbată.
Selenoid:
Implementarea selenoidului în K8 este în prezent cea mai mare dezamăgire. Nu sunt compatibili. În teorie, putem ridica un container Selenoid în interiorul unui pod, dar când Selenoid începe să lanseze containere cu browsere, acestea vor fi în continuare în interiorul aceluiași pod. Acest lucru face ca scalarea să fie imposibilă și, în consecință, activitatea Selenoidului în interiorul unui cluster nu va diferi de munca în interiorul unei mașini virtuale. Sfarsitul povestii.
Lună:
Cunoscând acest blocaj atunci când lucrează cu Selenoid, dezvoltatorii au lansat un instrument mai puternic numit Moon. Acest instrument a fost conceput inițial pentru a funcționa cu Kubernetes și, în consecință, funcția de autoscaling poate și ar trebui utilizată. Mai mult, aș spune că în momentul de față este singurul un instrument din lumea Selenium, care are suport nativ pentru cluster K8s din cutie (nu mai este disponibil, vezi instrumentul următor ). Caracteristicile cheie ale Lunii care oferă acest suport sunt:
Complet apatrid. Selenoid stochează în memorie informații despre sesiunile de browser care rulează în prezent. Dacă, dintr-un motiv oarecare, procesul său se blochează, atunci toate sesiunile care rulează sunt pierdute. Dimpotrivă, Moon nu are o stare internă și poate fi replicată în centrele de date. Sesiunile de browser rămân în viață chiar dacă una sau mai multe replici se defectează.
Deci, Moon este o soluție grozavă, dar există o problemă: nu este gratuită. Pretul depinde de numarul de sedinte. Puteți rula doar 0-4 sesiuni gratuit, ceea ce nu este deosebit de util. Dar, începând cu a cincea sesiune, va trebui să plătiți 5 dolari pentru fiecare. Situația poate diferi de la companie la companie, dar în cazul nostru, folosirea Lunii este inutilă. După cum am descris mai sus, putem rula VM-uri cu Selenium Grid la cerere sau putem crește numărul de noduri din cluster. Pentru aproximativ o conductă, lansăm 500 de browsere și oprim toate resursele după finalizarea testelor. Dacă am folosi Moon, ar trebui să plătim suplimentar 500 x 5 = 2500 USD pe lună, indiferent cât de des facem teste. Din nou, nu spun că nu folosiți Moon. Pentru sarcinile dvs., aceasta poate fi o soluție indispensabilă, de exemplu, dacă aveți multe proiecte/echipe în organizația dvs. și aveți nevoie de un cluster comun imens pentru toată lumea. Ca întotdeauna, vă las un link la sfârșit și vă recomand să faceți toate calculele necesare în contextul sarcinii dvs.
Callisto: (Atenţie! Acesta nu este în articolul original și este conținut doar în traducerea rusă)
După cum am spus, Selenium este un instrument foarte popular, iar domeniul IT se dezvoltă foarte repede. În timp ce lucram la traducere, pe web a apărut un nou instrument promițător numit Callisto (bună ziua Cypress și alți ucigași de seleniu). Funcționează nativ cu K8 și vă permite să rulați containere Selenoid în pod-uri, distribuite pe noduri. Totul funcționează imediat, inclusiv autoscaling. Fantastic, dar trebuie testat. Am reușit deja să implementez acest instrument și să execut mai multe experimente. Dar este prea devreme să trag concluzii, după ce am primit rezultate la distanță lungă, poate voi face o recenzie în articolele viitoare. Deocamdată las doar linkuri pentru cercetări independente.
Ilustrație a stării actuale a infrastructurii
Link-uri de explorat
Instrumente similare
7. Infrastructura ca cod (IaC)
Scurtă descriere a tehnologiei
Și acum ajungem la ultima secțiune. De obicei, această tehnologie și sarcinile conexe nu sunt responsabilitatea inginerilor de automatizare. Și există motive pentru asta. În primul rând, în multe organizații, problemele de infrastructură sunt sub controlul departamentului DevOps, iar echipelor de dezvoltare nu le pasă cu adevărat de ceea ce face ca pipeline-ul să funcționeze și de cum trebuie susținut tot ceea ce este legat de acesta. În al doilea rând, să fim sinceri, practica Infrastructure as Code (IaC) încă nu este adoptată în multe companii. Dar cu siguranță a devenit o tendință populară și este important să încerci să te implici în procesele, abordările și instrumentele asociate cu acesta. Sau măcar să fii la curent.
Să începem cu motivația pentru utilizarea acestei abordări. Am discutat deja că pentru a rula teste în GitlabCI, vom avea nevoie cel puțin de resurse pentru a rula Gitlab Runner. Și pentru a rula containere cu browsere/emulatoare, trebuie să rezervăm o VM sau un cluster. Pe lângă resursele de testare, avem nevoie de o cantitate semnificativă de capacitate pentru a susține medii de dezvoltare, punere în scenă, producție, care include și baze de date, programări automate, configurații de rețea, echilibrare de încărcare, drepturi de utilizator și așa mai departe. Problema cheie este efortul necesar pentru a susține totul. Există mai multe moduri prin care putem face modificări și lansăm actualizări. De exemplu, în contextul GCP, putem folosi consola UI în browser și putem efectua toate acțiunile făcând clic pe butoane. O alternativă ar fi folosirea apelurilor API pentru a interacționa cu entitățile cloud sau folosirea utilitarului de linie de comandă gcloud pentru a efectua manipulările dorite. Dar cu un număr foarte mare de entități și elemente de infrastructură diferite, devine dificil sau chiar imposibil să efectuați manual toate operațiunile. Mai mult, toate aceste acțiuni manuale sunt incontrolabile. Nu le putem trimite spre examinare înainte de execuție, nu putem folosi un sistem de control al versiunilor și nu putem anula rapid modificările care au dus la incident. Pentru a rezolva astfel de probleme, inginerii au creat și creează scripturi automate bash/shell, care nu sunt cu mult mai bune decât metodele anterioare, deoarece nu sunt atât de ușor de citit, înțeles, întreținut și modificat într-un stil procedural.
În acest articol și ghidul de utilizare, folosesc 2 instrumente legate de practica IaC. Acestea sunt Terraform și Ansible. Unii oameni cred că nu are sens să le folosești în același timp, deoarece funcționalitatea lor este similară și sunt interschimbabile. Dar adevărul este că inițial li se dau sarcini complet diferite. Iar faptul că aceste instrumente ar trebui să se completeze reciproc a fost confirmat într-o prezentare comună a dezvoltatorilor care reprezintă HashiCorp și RedHat. Diferența conceptuală este că Terraform este un instrument de furnizare pentru gestionarea serverelor în sine. În timp ce Ansible este un instrument de management al configurației a cărui sarcină este să instaleze, să configureze și să gestioneze software-ul pe aceste servere.
O altă caracteristică cheie distinctivă a acestor instrumente este stilul de codare. Spre deosebire de bash și Ansible, Terraform folosește un stil declarativ bazat pe o descriere a stării finale dorite care trebuie atinsă ca rezultat al execuției. De exemplu, dacă vom crea 10 VM și vom aplica modificările prin Terraform, atunci vom obține 10 VM. Dacă rulăm din nou scriptul, nu se va întâmpla nimic, deoarece avem deja 10 VM-uri, iar Terraform știe despre acest lucru deoarece stochează starea curentă a infrastructurii într-un fișier de stare. Dar Ansible folosește o abordare procedurală și, dacă îi ceri să creeze 10 VM-uri, atunci la prima lansare vom obține 10 VM-uri, similare cu Terraform. Dar după repornire vom avea deja 20 de VM-uri. Aceasta este diferența importantă. În stil procedural, nu stocăm starea curentă și pur și simplu descriem o secvență de pași care trebuie efectuate. Desigur, putem face față diverselor situații, adăugăm mai multe verificări pentru existența resurselor și starea actuală, dar nu are rost să ne pierdem timpul și să depunem efort în controlul acestei logici. În plus, acest lucru crește riscul de a face greșeli.
Rezumând toate cele de mai sus, putem concluziona că Terraform și notația declarativă sunt un instrument mai potrivit pentru furnizarea de servere. Dar este mai bine să delegați munca de gestionare a configurației către Ansible. Cu asta în afara drumului, să ne uităm la cazurile de utilizare în contextul automatizării.
Valoare pentru infrastructura de automatizare
Singurul lucru important de înțeles aici este că infrastructura de automatizare a testelor ar trebui considerată ca parte a întregii infrastructuri a companiei. Aceasta înseamnă că toate practicile IaC trebuie aplicate la nivel global resurselor întregii organizații. Cine este responsabil pentru acest lucru depinde de procesele dvs. Echipa DevOps are mai multă experiență în aceste probleme, ei văd întreaga imagine a ceea ce se întâmplă. Cu toate acestea, inginerii QA sunt mai implicați în procesul de automatizare a clădirilor și în structura conductei, ceea ce le permite să vadă mai bine toate schimbările necesare și oportunitățile de îmbunătățire. Cea mai bună opțiune este de a lucra împreună, de a face schimb de cunoștințe și idei pentru a obține rezultatul așteptat.
Iată câteva exemple de utilizare a Terraform și Ansible în contextul automatizării testelor și al instrumentelor pe care le-am discutat anterior:
1. Descrieți caracteristicile și parametrii necesari ai VM-urilor și clusterelor folosind Terraform.
2. Folosind Ansible, instalați instrumentele necesare pentru testare: docker, Selenoid, Selenium Grid și descărcați versiunile necesare de browsere/emulatoare.
3. Folosind Terraform, descrieți caracteristicile mașinii virtuale în care va fi lansat GitLab Runner.
4. Instalați GitLab Runner și instrumentele însoțitoare necesare folosind Ansible, setați setările și configurațiile.
Ilustrație a stării actuale a infrastructurii
Link-uri de explorat:
Instrumente similare
Să rezumam!
Pas
Tehnologia
Instrumente
Valoare pentru infrastructura de automatizare
1
Funcționare locală
Node.js, Selenium, Appium
- Cele mai populare instrumente pentru web și mobil
- Suportă multe limbi și platforme (inclusiv Node.js)
2
Sisteme de control al versiunilor
merge
- Beneficii similare cu codul de dezvoltare
3
Containerizare
Docker, Selenium grid, Selenoid (Web, Android)
- Executare teste în paralel
- Medii izolate
- Actualizări de versiuni simple și flexibile
- Oprirea dinamică a resurselor neutilizate
- Ușor de configurat
4
CI/CD
Gitlab CI
- Testează o parte a conductei
- Feedback rapid
- Vizibilitate pentru întreaga companie/echipă
5
Platforme de nori
Platforma Google Cloud
- Resurse la cerere (platim doar la nevoie)
- Ușor de gestionat și actualizat
- Vizibilitatea și controlul tuturor resurselor
6
Orchestrarea
Kubernetes
În contextul containerelor cu browsere/emulatori în interiorul podurilor:
- Scalare/scalare automată
- Auto vindecare
- Actualizări și derulări fără întrerupere
7
Infrastructura ca cod (IaC)
Terraform, Ansible
- Beneficii similare cu infrastructura de dezvoltare
- Toate beneficiile versiunii de cod
- Ușor de făcut modificări și de întreținut
- Complet automatizat
Diagrame hărți mentale: evoluția infrastructurii
Pasul 1: Local
pasul 2: VCS
Pasul 3: Containerizarea
pasul 4: CI/CD
pasul 5: Platforme cloud
pasul 6: Orchestrare
pasul 7: IaC
Ce urmeaza?
Deci, acesta este sfârșitul articolului. Dar, în concluzie, aș dori să stabilesc niște acorduri cu dumneavoastră.
Din partea ta
După cum am spus la început, aș dori ca articolul să fie de folos practic și să vă ajute să aplicați cunoștințele acumulate în munca reală. adaug din nou.
Dar chiar și după aceea, nu te opri, exersează, studiază link-uri și cărți relevante, află cum funcționează în compania ta, găsește locuri care pot fi îmbunătățite și participă la ele. Noroc!
Din partea mea
Din titlu se poate observa că aceasta a fost doar prima parte. În ciuda faptului că s-a dovedit a fi destul de mare, subiectele importante nu sunt încă acoperite aici. În a doua parte, intenționez să mă uit la infrastructura de automatizare în contextul IOS. Din cauza restricțiilor Apple privind rularea simulatoarelor iOS numai pe sisteme macOS, gama noastră de soluții este restrânsă. De exemplu, nu putem folosi Docker pentru a rula simulatorul sau norii publici pentru a rula mașini virtuale. Dar asta nu înseamnă că nu există alte alternative. Voi încerca să vă țin la curent cu soluții avansate și instrumente moderne!
De asemenea, nu am menționat subiecte destul de mari legate de monitorizare. În partea 3, voi analiza cele mai populare instrumente de monitorizare a infrastructurii și ce date și valori trebuie luate în considerare.
Și, în sfârșit. În viitor, intenționez să lansez un curs video despre construirea infrastructurii de testare și a instrumentelor populare. În prezent, există destul de multe cursuri și prelegeri despre DevOps pe Internet, dar toate materialele sunt prezentate în contextul dezvoltării, nu al automatizării testelor. Cu privire la această problemă, am foarte nevoie de feedback despre dacă un astfel de curs va fi interesant și valoros pentru comunitatea de testeri și ingineri de automatizare. Vă mulțumesc anticipat!
Sursa: www.habr.com