Del 1: Web / Android
Napomena: denna artikel är en översättning till ryska av den ursprungliga artikeln Men alla illustrationer, länkar, citat och termer har bevarats på originalspråket för att undvika förvrängning av betydelsen vid översättningen till ryska. Jag önskar dig trevlig läsning!
För närvarande är yrket DevOps ett av de mest efterfrågade inom IT-branschen. Om du öppnar populära jobbsajter och sätter filter för löner så kommer du se att jobbannonser relaterade till DevOps ligger i början av listan. Men det är viktigt att förstå att detta främst gäller positionen 'Senior', vilket innebär att kandidaten har en hög kompetensnivå och kunskap om teknologier och verktyg. Därtill följer en hög grad av ansvar kopplad till den oavbrutna drift som finns i produktionen. Men vi har kommit ihåg vad DevOps verkligen är. Ursprungligen var det inte en specifik person eller avdelning. Om vi söker efter definitioner av denna term kommer vi att hitta många vackra och korrekta substantiv, som metodologi, praxis, kulturell filosofi, konceptgrupp och så vidare.
Min specialitet är testautomationsingenjör (QA automation engineer), men jag anser att den inte bara bör kopplas till att skriva automatiska tester eller utveckla arkitekturen för testframework. År 2020 är kunskap om automatiseringsinfrastruktur också nödvändig. Det gör att man kan organisera automatiseringsprocessen självständigt, från att köra tester till att presentera resultaten för alla intressenter i enlighet med de uppställda målen. Därmed är DevOps-färdigheter en obligatorisk faktor för att utföra detta arbete. Och allt detta är bra, men tyvärr finns det ett problem (spoiler: denna artikel försöker förenkla detta problem). Det handlar om att DevOps är svårt. Och det ä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 praxis att bemästra. Särskilt är det svårt i början av karriären och beror på den tekniska erfarenhet man har samlat.
Izvor:
Här ska vi nog avsluta den inledande delen och fokusera på syftet med denna artikel.
Vad handlar denna artikel om
V tem članku želim deliti svoje izkušnje pri gradnji infrastrukture za avtomatizacijo testiranja. Na spletu lahko najdete številne vire informacij o različnih orodjih in njihovi uporabi, a rad bi jih razpravljal izključno v kontekstu avtomatizacije. Verjamem, da so številnim inženirjem za avtomatizacijo znane situacije, ko testov, ki ste jih razvili, nihče razen vas ne izvaja in ne skrbi za njihovo vzdrževanje. Posledično testi postanejo zastareli, kar zahteva porabo časa za njihovo posodabljanje. Spet, na začetku kariere je to lahko precej zahtevna naloga: pravilno določiti, katera orodja bi morala pomoč pri reševanju tega problema, kako jih izbrati, nastaviti in vzdrževati. Nekateri testerji se obračajo na DevOps in, bodimo iskreni, ta pristop deluje. V mnogih primerih je to lahko edina možnost, saj nimamo vpogleda v vse odvisnosti. A, kot vemo, so DevOps zelo zaposleni ljudje, saj morajo razmišljati o infrastrukturi cele podjetja, uvajanju, spremljanju, mikrostoritvah in drugih podobnih nalogah, odvisno od organizacije/tima. Kot običajno, avtomatizacija ni prioriteta. V tem primeru moramo poskusiti narediti vse, kar je v naši moči od začetka do konca. To bo zmanjšalo odvisnosti, pospešilo delovni proces, izboljšalo naše sposobnosti in omogočilo širši vpogled v dogajanje.
V članku so predstavljena najbolj iskana in priljubljena orodja ter prikazano, kako jih uporabiti za postopno gradnjo infrastrukture za avtomatizacijo. Vsaka skupina je predstavljena z orodji, ki so bila preizkušena na osebni izkušnji. A to ne pomeni, da morate uporabiti enaka. Sama orodja niso pomembna, pojavijo se in zastarijo. Naša inženirska naloga je razumevanje osnovnih načel: zakaj potrebujemo to skupino orodij in katere delovne naloge lahko z njihovo pomočjo rešimo. Zato na koncu vsake sekcije pustim povezave do podobnih orodij, ki se morda uporabljajo v vaši organizaciji.
Česar v tem članku ni
Ponovno naglašavam da članak nije o konkretnim alatima, stoga ovde neće biti isječaka koda iz dokumentacije niti opisivanja konkretnih komandi. Na kraju svake sekcije ostavljam linkove za detaljnije proučavanje.
To je učinjeno iz razloga što:
- ovaj materijal je vrlo lako pronaći u različitim izvorima (dokumentacija, knjige, video kursevi);
- ako se počnemo produbljivati, moraćemo napisati 10, 20 ili 30 delova ovog članka (dok su u planu 2-3);
- jednostavno ne želim trošiti vaše vreme, jer možda želite koristiti druge alate za postizanje istih ciljeva.
Praktika
Vrlo bih želeo da ovaj materijal bude koristan za svakog čitatelja, a ne samo da bude pročitano i zaboravljeno. U svakom učenju praksa je veoma važan sastojak. Zbog toga sam pripremio. Takođe vas očekuje domaći zadatak, kako biste bili sigurni da niste bezmisleno kopirali linije izvršavanih komandi
Načrt
Korak
Tehnologija
Instrumenti
1
Lokalan rad (priprema web / android demo testova i pokretanje lokalno)
Node.js, Selenium, Appium
2
Sistemi za kontrolu verzija
Git
3
Kontejnerizacija
Docker, Selenium grid, Selenoid (Web, Android)
4
CI / CD
Gitlab CI
5
Cloud platforme
Google Cloud Platform
6
Orkestracija
Kubernetes
7
Infrastruktura kao kod (IaC)
Terraform, Ansible
Struktura svake sekcije
Radi održavanja narativa na jasan način, svaka sekcija je opisana po sledećem planu:
- kratak opis tehnologije,
- vrednost za infrastrukturnu automatizaciju,
- ilustracija trenutnog stanja infrastrukture,
- linkovi za proučavanje,
- slični alati.
1. Lokalan rad testova
Kratak opis tehnologije
To je samo pripremni korak za pokretanje demo testova lokalno i provere da li oni uspešno prolaze. U praktičnom delu koristi se Node.js, ali programski jezik i platforma takođe nisu važni, i mogu se koristiti oni što se koriste u vašoj kompaniji.
Ipak, kao alate za automatizaciju preporučujem korišćenje Selenium WebDriver-a za web platforme i Appium-a za Android platformu, jer ćemo u sledećim koracima koristiti Docker slike koje su specijalizovane za rad tačno s ovim alatima. Štaviše, oslanjajući se na zahteve u oglasima za posao, ovi alati su najtraženiji na tržištu.
Kot ste lahko opazili, se osredotočamo le na spletne in Android teste. Na žalost je IOS povsem druga zgodba (hvala Apple). Načrtujem, da bom predstavil rešitve in prakse, povezane z IOS, v naslednjih delih.
Vrednost za infrastrukturo avtomatizacije
Z vidika infrastrukture lokalno izvajanje ne prinaša nobene vrednosti. Preverjate le, ali testi delujejo na lokalnem računalniku v lokalnih brskalnikih in simulatorjih. V katerem koli primeru pa je to nujna izhodiščna točka.
Ilustracija trenutnega stanja infrastrukture
Povezave za nadaljnje raziskovanje
Podobna orodja
- katerikoli programski jezik, ki vam je všeč, v povezavi s Selenium/Appium testi;
- katerikoli testi;
- katerikoli testni zagon.
2. Sistemi za nadzor različic (Git)
Kratak opis tehnologije
Za nikogar ne bo veliko odkritje, če rečem, da je sistem za nadzor različic izjemno pomemben del tako timskega kot individualnega razvoja. Na podlagi različnih virov lahko samozavestno trdim, da je Git najbolj priljubljen predstavnik. Sistem nadzora različic prinaša številne prednosti, kot so deljenje kode, shranjevanje različic, obnavljanje prejšnjih veji, sledenje zgodovini projekta in varnostne kopije. Ne bomo razpravljali o vsakem od teh točk podrobno, saj sem prepričan, da ste z njimi dobro seznanjeni in jih uporabljate v svojem vsakodnevnem delu. Ampak če slučajno niste, priporočam, da takoj prekinete z branjem tega članka in to vrzel čim prej zapolnite.
Vrednost za infrastrukturo avtomatizacije
In tukaj se lahko zastavi smiselno vprašanje: "Zakaj nam govori o Gitu? Vsi to poznajo in uporabljajo tako za razvoj kode kot za kode avto-testov." Imate prav, toda v tem članku govorimo o infrastrukturi, ta odsek pa igra vlogo uvoda za odsek 7: "Infrastruktura kot koda (IaC)". To za nas pomeni, da je vsa infrastruktura, vključno z testno, opisna v obliki kode, zato lahko nanjo apliciramo sisteme za nadzor različic in pridobimo podobne prednosti kot za razvoj in avtomatizacijo kod.
Podrobneje se bomo posvetili IaC v koraku 7, vendar lahko že sedaj začnete uporabljati Git lokalno, tako da ustvarite lokalno repozitorij. Splošna slika se bo razširila, ko bomo infrastrukturnemu delu dodali oddaljeni repozitorij.
Ilustracija trenutnega stanja infrastrukture
Povezave za nadaljnje raziskovanje
Podobna orodja
3. Kontejnorizacija (Docker)
Kratak opis tehnologije
Za prikaz, kako je kontejnorizacija spremenila pravila igre, se vrnimo nekaj desetletij v preteklost. Takrat so ljudje kupovali in uporabljali strežniške naprave za zagon aplikacij. Vendar pa so bili v večini primerov potrebni viri za zagon neznani vnaprej. Posledično so podjetja zapravljala denar za nakup dragih zmogljivih strežnikov, vendar del te moči ni bila popolnoma izkoriščena.
Naslednji korak v evoluciji so postale virtualne naprave (VM), ki so rešile problem stroškov neizkoriščenih virov. Ta tehnologija je omogočila zagon aplikacij neodvisno ena od druge znotraj enega strežnika, pri čemer se je ustvarilo popolnoma izolirano okolje. Vendar pa, žal, nobena tehnologija ni brez pomanjkljivosti. Zagon VM zahteva celotno operacijsko sistem, ki porabi CPU, RAM, shranjevanje in, odvisno od OS, je potrebno upoštevati stroške licenciranja. Ti dejavniki vplivajo na hitrost nalaganja in otežujejo prenosljivost.
In tukaj smo pri kontejnerizaciji. In spet je ta tehnologija rešila prejšnji problem, saj kontejnerji ne uporabljajo celotnega operacijskega sistema, kar omogoča sprostitev velike količine virov ter ponuja hitro in prilagodljivo rešitev za prenosljivost.
Seveda, tehnologija kontejnerizacije ni nova in je bila prvič predstavljena konec 70. let. Tedaj je bilo narejenih veliko raziskav, zasnov in poskusov. Vendar je prav Docker prilagodil to tehnologijo in jo naredil dostopno množicam. Danes, ko govorimo o kontejnerjih, v večini primerov mislimo na Docker. Ko govorimo o Docker kontejnerjih, imamo v mislih Linux kontejnerje. Uporabimo lahko sisteme Windows in macOS za zagon kontejnerjev, vendar je pomembno razumeti, da v tem primeru pride do dodatne plasti. Na primer, Docker na Macu neopazno zažene kontejnerje znotraj lahkega Linux VM. Še vrnemo se k tej temi, ko bomo razpravljali o zagonu Android emulatorjev znotraj kontejnerjev, kjer se pojavi zelo pomembna podrobnost, ki jo je treba podrobneje obdelati.
Vrednost za infrastrukturo avtomatizacije
Ugotovili smo, da sta kontejnerizacija in Docker super. Poglejmo to v kontekstu avtomatizacije, saj mora vsak instrument ali tehnologija rešiti kakšno težavo. Oznanimo očitne težave avtomatizacije testiranja v kontekstu UI testov:
- ogromno število odvisnosti pri namestitvi Selenium in zlasti Appium;
- težave s združljivostjo med različicami brskalnikov, simulatorjev in gonilnikov;
- pomanjkanje izoliranega prostora za brskalnike/simulatorje, kar je še posebej kritično za paralelni zagon;
- težko je upravljati in vzdrževati, če je treba hkrati zagnati 10, 50, 100 ali celo 1000 brskalnikov.
Toda ker je Selenium najbolj priljubljeno orodje za avtomatizacijo, Docker pa je najbolj priljubljeno orodje za kontejnerizacijo, ne bi smelo biti presenečenje, da je nekdo poskušal združiti oboje in tako dobiti močno orodje za reševanje zgoraj omenjenih težav. Poglejmo ta rešitev podrobneje.
Selenium grid v dockerju
To orodje je najbolj priljubljeno na svetu za zagon več brskalnikov na več napravah in njihovo upravljanje iz središča. Za zagon je potrebno registrirati vsaj 2 dela: Hub in Node(e). Hub je osrednje vozlišče, ki prejema vse zahteve testov in jih porazdeli med ustrezne Nodes. Za vsak Node lahko nastavite posebno konfiguracijo, na primer, določite želeni brskalnik in njegovo različico. Vendar pa moramo še vedno sami poskrbeti za združljive gonilnike za brskalnike in jih namestiti na ustrezne Nodes. Iz tega razloga se Selenium grid ne uporablja v čisti obliki, razen v primerih, ko moramo delati z brskalniki, ki jih ni mogoče namestiti na sistem Linux. V vseh drugih primerih je znatno fleksibilnejša in pravilnejša rešitev uporaba Docker slik za zagon Selenium grid Hub in Nodes. Takšen pristop močno poenostavi upravljanje vozlišč, saj lahko izberemo želeno sliko z že nameščenimi združljivimi različicami brskalnikov in gonilnikov.
Kljub negativnim mnenjem o stabilnosti delovanja, zlasti pri sočasnem zagonu velikega števila Nodes, Selenium grid še vedno ostaja najbolj priljubljeno orodje za sočasno izvajanje Selenium testov. Pomembno je poudariti, da se v open-source vedno pojavljajo različne nadgradnje in modifikacije tega orodja, ki se borijo proti različnim točkam zastoja.
Selenoid za splet
To orodje je preobrat v svetu Selenium, saj deluje takoj iz škatle in je veliko olajšalo življenje mnogim inženirjem avtomatizacije. Predvsem to ni le še ena modifikacija Selenium grid. Namesto tega so razvijalci ustvarili povsem novo različico Selenium Hub v jeziku Golang, kar v kombinaciji z lahkimi Docker slikami za različne brskalnike pomeni velik korak naprej v avtomatizaciji testiranja. Poleg tega moramo pri Selenium Gridu vnaprej določiti vse potrebne brskalnike in njihove različice, kar ni težava, ko delamo samo z enim brskalnikom. Ampak ko govorimo o več podprtih brskalnikih, je Selenoid rešitev številka ena, zahvaljujoč funkciji 'brskalnik na zahtevo'. Vse, kar potrebujemo, je, da vnaprej naložimo potrebne slike brskalnikov in posodobimo konfiguracijsko datoteko, s katero Selenoid sodeluje. Ko Selenoid prejme zahtevo iz testov, samodejno zažene potreben kontejner s pravim brskalnikom. Ko se test konča, Selenoid ustavi kontejner in s tem sprosti vire za naslednje zahteve. Takšen pristop popolnoma odpravi znan problem 'degradacije vozlišč', s katerim se pogosto srečujemo v Selenium grid.
A vendar, Selenoid še vedno ni čarobna puška. Dobili smo funkcijo 'brskalnik na zahtevo', vendar funkcija 'viri na zahtevo' še vedno ni na voljo. Za uporabo Selenoid ga moramo postaviti na fizično strojno opremo ali na VM, kar pomeni, da moramo vnaprej vedeti, koliko virov je potrebno dodeliti. Menim, da to ni težava za majhne projekte, ki hkrati izvajajo 10, 20 ali celo 30 brskalnikov. Kaj pa, če potrebujemo 100, 500, 1000 in več? Ni smisla vzdrževati in plačevati za tako veliko število virov nenehno. V razdelku 5 in 6 tega članka bomo razpravljali o rešitvah, ki omogočajo skaliranje, s čimer znatno zmanjšujejo stroške podjetja.
Selenoid za Android
Po uspehu Selenoid kot orodja za spletno avtomatizacijo so ljudje želeli nekaj podobnega za Android. In to se je uresničilo – Selenoid je bil izdan s podporo za Android. Z vidika uporabnika je načelo delovanja podobno spletnemu avtomatiziranju. Edina razlika je v tem, da Selenoid namesto vsebniki z brskalniki zažene vsebnike z Android emulatorji. Po mojem mnenju je to trenutno najmočnejše brezplačno orodje za izvajanje Android testov hkrati.
Zelo nebi želel govoriti o negativnih straneh tega orodja, ker mi je res zelo všeč. Kljub temu pa obstajajo isti slabosti, ki se nanašajo na spletno avtomatizacijo, povezane z razširljivostjo. Poleg tega moram omeniti še eno omejitev, ki lahko postane presenečenje, če orodje nastavljamo prvič. Za zagon Android slik potrebujemo fizično napravo ali VM s podporo za gnezditveno virtualizacijo. V praktičnem vodiču bom pokazal, kako to aktivirati na Linux VM. Vendar, če ste uporabnik macOS in želite lokalno namestiti Selenoid, to ne bo mogoče za zagon Android testov. Vendar lahko vedno zagnate Linux VM lokalno s konfigurirano 'gnezditveno virtualizacijo' in znotraj namestite Selenoid.
Ilustracija trenutnega stanja infrastrukture
V kontekstu tega članka bova dodala 2 orodja za ilustracijo infrastrukture. To sta Selenium grid za spletne teste in Selenoid za Android teste. V vodiču na GitHubu bom tudi pokazal, kako uporabiti Selenoid za zagon spletnih testov.
Povezave za nadaljnje raziskovanje
Podobna orodja
- Obstajajo tudi druga orodja za kontejnerizacijo, a Docker je najbolj priljubljen. Če želite poskusiti nekaj drugega, upoštevajte, da orodja, ki smo jih preučili za paralelno izvajanje Selenium testov, ne bodo delovala takoj.
- Kot je bilo že omenjeno, obstaja veliko različic Selenium grid, na primer,.
4. CI / CD
Kratak opis tehnologije
Praksa neprekinjene integracije je precej priljubljena v razvoju in je na enem nivoju s sistemi za nadzor različic. Kljub temu imam občutek, da obstaja zmeda glede terminologije. V tem odstavku bi rad opisal tri modifikacije te tehnologije z mojega vidika. Na internetu boste našli veliko člankov z različnimi interpretacijami, in to je povsem v redu, če se vaše mnenje razlikuje. Najpomembneje je, da ste na isti valovni dolžini kot vaši kolegi.
Torej obstajajo trije izrazi: CI — Continuous Integration (neprekinjena integracija), CD — Continuous Delivery (neprekinjena dobava) in ponovno CD — Continuous Deployment (neprekinjeno izvajanje). (Nato bom te izraze uporabljal v angleščini). Vsaka modifikacija doda nekaj dodatnih korakov vašemu razvojnemu cevovodu. A beseda continuous (neprekinjeno) je najpomembnejša. V tem kontekstu mislimo na nekaj, kar poteka od začetka do konca, brez prekinitev ali ročnega posredovanja. Poglejmo CI & CD in CD v tem kontekstu.
- Continuous Integration – je začetni korak evolucije. Po pošiljanju nove kode na strežnik pričakujemo hitro povratno informacijo, da so z našimi spremembami vse v redu. Običajno CI vključuje zagon orodij za statično analizo kode in enotni/testi notranjega API-ja. To nam omogoča, da informacije o naši kodi dobimo že čez nekaj sekund/minut.
- Kontinuirana isporuka je bolj napreden korak, kjer zagnamo integracijske/UI-teste. Vendar v tej fazi rezultatov ne dobimo tako hitro kot pri CI. Prvič, ti tipi testov potrebujejo več časa za izvedbo. Drugič, pred izvajanjem moramo razporediti naše spremembe v testno/odrsko okolje. Poleg tega, če govorimo o mobilnem razvoju, pride do dodatne faze za izdelavo gradnje naše aplikacije.
- Continuous Deployment predpostavlja, da avtomatsko izda (release) naša spremembe na produkciji, če so vsi sprejemni testi bili uspešno opravljeni v prejšnjih fazah. Poleg tega, po fazi izdaje lahko nastavite različne faze, kot je zagon smoke testov na produkciji in zbiranje zanimivih metrik. Continuous Deployment je mogoč le pri dobrem pokritju z avtomatiziranimi testi. Če so potrebne ročne intervencije, vključno s testiranjem, to ne pomeni več. Neprekinjeno (neprekinjeno). Takrat lahko govorimo o tem, da je naš proces ustrezen le praksi Continuous Delivery.
Vrednost za infrastrukturo avtomatizacije
V tem razdelku moram pojasniti, da, ko govorimo o end-to-end UI testih, to pomeni, da moramo implementirati naše spremembe in povezane storitve na testnih okoljih. Continuous Integration — ta proces ni uporaben za to nalogo in moramo poskrbeti za uvedbo vsaj praks Continuous Delivery. Continuous Deployment ima prav tako smislu v kontekstu UI testov, če jih nameravamo zagnati na produkciji.
In preden pogledamo ilustracijo sprememb arhitekture, želim reči nekaj besed o GitLab CI. Za razliko od drugih CI/CD orodij, GitLab ponuja oddaljeni repozitorij in številne druge dodatne funkcije. Tako je GitLab več kot CI. Vključuje upravljanje izvorne kode, Agile upravljanje, CI/CD cevi, orodja za beleženje in zbiranje metrik. Arhitektura GitLab obsega GitLab CI/CD in GitLab Runner. Navajam kratek opis iz uradne strani:
GitLab CI/CD je spletna aplikacija z API-jem, ki shranjuje svoje stanje v bazi podatkov, upravlja projekte/gradnje in nudi uporabniški vmesnik. GitLab Runner je aplikacija, ki obdeluje gradnje. Lahko se namesti ločeno in deluje z GitLab CI/CD preko API-ja. Za izvajanje testov potrebujete tako GitLab instanco kot Runner.
Ilustracija trenutnega stanja infrastrukture
Povezave za nadaljnje raziskovanje
Podobna orodja
- In mnogi drugi
5. Oblak platforme
Kratak opis tehnologije
V tem razdelu se bomo pogovarjali o priljubljenem trendu, imenovanem 'javna oblaka'. Kljub ogromnim prednostim, ki jih prinašajo zgoraj opisane tehnologije virtualizacije in kontejnerizacije, še vedno potrebujemo računalniške vire. Podjetja kupujejo drage strežnike ali najemajo podatkovne centre, vendar je v tem primeru potrebno izvesti izračune (včasih nerealne) koliko virov bomo potrebovali, ali jih bomo uporabljali 24/7 in za kakšne namene. Na primer, za produkcijo potrebujemo strežnik, ki deluje neprekinjeno, vendar potrebujemo podobne vire za testiranje v neproduktivnem času? To je odvisno tudi od vrste testiranja, ki ga izvajamo. Primer so obremenitveni/stresni testi, ki jih načrtujemo izvajati v neproduktivnem času, da bi dobili rezultate naslednji dan. Vsekakor pa ne potrebujemo 24-urne dostopnosti strežnikov za avtomatizirane teste od konca do konca, še posebej ne za ročna testiranja. Za takšne situacije bi bilo dobro prejemati toliko virov, kolikor jih potrebujemo na zahtevo, jih uporabiti in prenehati plačevati, ko jih ne rabimo več. Še bolje bi bilo, če bi jih lahko pridobili takoj, s samo nekaj kliki miške ali z zagonom nekaj skript. Za to se uporabljajo javna oblaka. Poglejmo definicijo:
"Javna oblaka so definirana kot računalniške storitve, ki jih ponujajo tretji ponudniki prek javnega interneta, kar jih naredi dostopne vsakomur, ki jih želi uporabljati ali kupiti. Lahko so brezplačne ali prodane po povpraševanju, kar omogoča strankam, da plačajo le za uporabo, glede na procesorska cikla, shranjevanje ali pasovno širino, ki jo porabijo."
Obstaja prepričanje, da so javna oblaka draga. Vendar pa je njihova ključna ideja zmanjšanje stroškov podjetja. Kot smo že omenili, javna oblaka omogočajo pridobitev virov po povpraševanju in plačilo le za čas njihove uporabe. Prav tako včasih pozabimo, da zaposleni prejemajo plače, številni strokovnjaki pa so prav tako dragoceni viri. Treba je upoštevati, da javna oblaka znatno olajšajo podporo infrastrukturi, kar inženirjem omogoča, da se osredotočijo na pomembnejše naloge.
Vrednost za infrastrukturo avtomatizacije
Katere natančne vire potrebujemo za end-to-end UI teste? V glavnem so to virtualni stroji ali grozdi (o Kubernetesu bomo govorili v naslednjem razdelku), ki se uporabljajo za zagon brskalnikov in emulatorjev. Več brskalnikov in emulatorjev želimo zagnati hkrati, več CPU in pomnilnika potrebujemo in toliko več denarja bomo morali za to plačati. Javno oblačilo v kontekstu avtomatizacije testiranja nam tako omogoča zagon velikega števila (100, 200, 1000 ...) brskalnikov/emulatorjev na zahtevo, pridobitev rezultatov testiranja čim hitreje in prenehanje plačevanja za takšne obupne vire.
Najbolj priljubljeni oblačni ponudniki so Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). V praktičnem priročniku so predstavljeni primeri uporabe GCP, vendar na splošno ni pomembno, kaj natančno boste uporabili za avtomatizacijske naloge. Vsi ponujajo približno enake funkcionalnosti. Običajno priročnik za izbiro ponudnika osredotoča na celotno infrastrukturo podjetja in poslovne zahteve, kar je zunaj okvira tega članka. Inženirje avtomatizacije bo bolj zanimalo primerjati uporabo oblačnih ponudnikov s platformami v oblaku, specifičnimi za testiranje, kot so Sauce Labs, BrowserStack, BitBar in tako naprej. Torej, poglejmo to! Po mojem mnenju je Sauce Labs najbolj znana platforma za oblačno testiranje, zato sem jo izbral za primerjavo.
GCP proti Sauce Labs za avtomatizacijske namene:
Predstavljajmo si, da moramo hkrati izvesti 8 spletnih testov in 8 Android testov. V ta namen bomo uporabili GCP in zagnali 2 virtualni napravi s Selenoid. Na prvi bomo zagnali 8 kontejnerjev z brskalniki. Na drugi – 8 kontejnerjev z emulatorji. Poglejmo si cene:
Za zagon enega kontejnerja s Chromeom potrebujemo n1-standard-1 napravo. V primeru Androida pa bo to n1-standard-4 za enega emulatorja. V resnici je bolj fleksibilen in cenejši način, da določite specifične uporabniške vrednosti za CPU/pomnilnik, vendar trenutno to ni bistveno za primerjavo s Sauce Labs.
Tukaj so tarife za uporabo Sauce Labs:
Domnevam, da ste že opazili razliko, vendar vseeno prinašam tabelo z izračuni za naše naloge:
Zahtevani viri
Mesečno
Delovne ure(8.00 - 20.00)
Delovne ure+ Preemptible
GCP za splet
n1-standard-1 x 8 = n1-standard-8
$194.18
23 дни * 12ч * 0.38 = 104.88$
23 дни * 12ч * 0.08 = 22.08$
Sauce Labs за веб
Виртуальные Cloud8 параллельные тесты
$1.559
—
—
GCP за Android
n1-standard-4 x 8: n1-standard-16
$776.72
23 дни * 12ч * 1.52 = 419.52$
23 дни * 12ч * 0.32 = 88.32$
Sauce Labs за Android
Облачные реальные устройства 8 параллельных тестов
$1.999
—
—
Как видно, разница в стоимости огромна, особенно если запускать тесты только в рабочий двенадцатичасовой промежуток. Но можно еще сильнее сократить расходы, если использовать preemptible машины. Что же это такое?
Preemptible VM – это экземпляр, который вы можете создать и запустить по гораздо более низкой цене, чем обычные экземпляры. Однако Compute Engine может прекратить (preempt) эти экземпляры, если ему потребуется доступ к этим ресурсам для других задач. Preemptible экземпляры – это избыток возможностей Compute Engine, поэтому их доступность варьируется в зависимости от нагрузки.
Если ваши приложения обладают стойкостью к сбоям и могут выдержать возможные прерывания экземпляров, то preemptible экземпляры могут значительно снизить ваши затраты на Compute Engine. Например, задачи пакетной обработки могут выполняться на preemptible экземплярах. Если некоторые из этих экземпляров прекращаются во время обработки, работа замедляется, но не останавливается полностью. Preemptible экземпляры завершают ваши задачи пакетной обработки, не создавая дополнительную нагрузку на уже существующие экземпляры и не требуя от вас платить полную цену за дополнительные обычные экземпляры.
И это все еще не конец! На самом деле, я уверен, что никто не запускает тесты по 12 часов без перерыва. И если это так, то вы можете автоматически запускать и останавливать виртуальные машины, когда они не нужны. Реальное время использования может снизиться до 6 часов в день. Тогда оплата в контексте нашей задачи уменьшится до 11$ в месяц за 8 браузеров. Разве это не замечательно? Но с preemptible машинами мы должны быть осторожны и готовы к прерываниям и нестабильной работе, хотя эти ситуации могут быть предусмотрены и обработаны программно. Оно того стоит!
Но ни в коем случае я не говорю ‘никогда не используйте облачные тестовые фермы’. Они имеют ряд преимуществ. Прежде всего это не просто виртуальная машина, а полноценное решение для автоматизации тестирования с набором функционала из коробки: удаленный доступ, логи, скриншоты, видеозапись, различные браузеры и физические мобильные устройства. Во многих ситуациях это может быть незаменимой шикарной альтернативой. Особенно тестовые платформы полезны для IOS-автоматизации, когда публичные облака могут предложить только Linux/Windows-системы. Но разговор про IOS будет в следующих статьях. Я рекомендую всегда смотреть по ситуации и отталкиваться от задач: в каких-то дешевле и эффективнее использовать публичные облака, а в каких-то тестовые платформы определенно стоят потраченных денег.
Ilustracija trenutnega stanja infrastrukture
Povezave za nadaljnje raziskovanje
Podobna orodja:
6. Orkestracija
Kratak opis tehnologije
Imam dobre novice - skoraj smo na koncu članka! Naša infrastruktura avtomatizacije trenutno vključuje spletne in Android teste, ki jih izvajamo prek GitLab CI sočasno, z uporabo orodij, ki podpirajo Docker: Selenium grid in Selenoid. Poleg tega uporabljamo virtualne stroje, ustvarjene preko GCP, za zagon kontejnerjev z brskalniki in emulatorji. Da bi zmanjšali stroške, zagnamo te virtualne stroje samo na zahtevo in jih ustavimo, ko testiranje ni v teku. Ali obstaja še kaj, kar bi lahko izboljšalo našo infrastrukturo? Odgovor je - da! Srečamo Kubernetes (K8s)!
Najprej poglejmo, kako so besede orkestracija, klaster in Kubernetes povezane. Na višji ravni je orkestracija sistem, ki uvaja in upravlja aplikacije. Za avtomatizacijo testiranja so takšne kontejnerizirane aplikacije Selenium grid in Selenoid. Docker in K8s se dopolnjujeta. Prvi se uporablja za uvajanje aplikacij, drugi pa za orkestracijo. K8s je klaster. Naloga klustra je, da uporablja virtualne stroje kot vozlišča, kar omogoča namestitev različnih funkcionalnosti, programov in storitev v okviru enega strežnika (klustra). Če katero koli od vozlišč odpove, prevzamejo druga vozlišča, kar zagotavlja neprekinjeno delovanje naše aplikacije. Poleg tega ima K8s pomembno funkcionalnost, povezano s skaliranjem, ki nam omogoča, da samodejno pridobimo optimalno število virov, na podlagi obremenitve in nastavljenih omejitev.
Resnično, ročno uvajanje Kubernetes-a od nič ni povsem trivialna naloga. Pustil bom povezavo do znanega praktičnega priročnika »Kubernetes The Hard Way«. Če vas zanima, lahko preizkusite. Na srečo pa obstajajo alternativne metode in orodja. Najlažje je uporabiti Google Kubernetes Engine (GKE) v GCP, kar bo omogočilo, da dobite pripravljen klaster po nekaj klikih. Za začetek učenja priporočam, da uporabite prav ta pristop, saj vam bo omogočil, da se osredotočite na učenje, kako uporabiti K8s za svoje naloge, namesto da raziskujete, kako morajo biti notranje komponente med seboj integrirane.
Vrednost za infrastrukturo avtomatizacije
Oglejmo si nekaj pomembnih funkcij, ki jih nudi K8s:
- uvajanje aplikacije: uporaba multi-nodnega klasterja namesto VM-ov;
- dinamično skaliranje: zmanjšuje stroške virov, ki se uporabljajo le po potrebi;
- samopopravljanje (Self-healing): samodejno obnavljanje pods (kar obnavlja tudi kontejnere);
- izvajanje posodobitev in povratnih sprememb brez ustavljanja: posodabljanje orodij, brskalnikov in emulatorjev ne prekine dela trenutnih uporabnikov.
Ampak K8s še vedno ni čarobna palica. Da bi razumeli vse prednosti in omejitve v kontekstu obravnavanih orodij (Selenium grid, Selenoid), bomo na kratko obravnavali zgradbo K8s. Klaster vsebuje dva tipa nodov: Master Nodes in Workers Nodes. Master Nodes so odgovorni za upravljanje, uvajanje in odločitve o razporejanju. Workers nodes so tisti, kjer so aplikacije zagnane. Nodes vsebujejo tudi okolje za zagon kontejnerjev. V našem primeru je to Docker, ki je odgovoren za operacije, povezane s kontejnerji. Obstajajo pa tudi alternativne rešitve, na primer. Pomembno je razumeti, da skaliranje ali samopopravljanje ni neposredno povezano s kontejnerji. To se izvaja z dodajanjem/odvzemom števila pods, ki po drugi strani vsebujejo kontejnerje (običajno en kontejner na pod, vendar je odvisno od naloge lahko tudi več). Visokonavridna hierarhija predstavlja delovno vozlišče, znotraj katerega se nahajajo pods, znotraj katerih so zagnani kontejnerji.
Funkcija skaliranja je ključna i može se primeniti i na čvorove unutar klastera node-pool, kao i na pods unutar čvora. Postoje 2 tipa skaliranja koja se odnose i na čvorove i na pods. Prvi tip – horizontalno – skaliranje se vrši povećanjem broja čvorova/podova. Ovaj tip je više preferiran. Drugi tip, prema tome, je vertikalno. Skaliranje se vrši povećanjem veličina čvorova/podova, a ne njihovog broja.
Sada ćemo pogledati naše alate u kontekstu gore pomenutih termina.
Selenium grid
Kao što je ranije pomenuto, Selenium grid je veoma popularan alat, i nije iznenađujuće što je containerizovan. Stoga, nije iznenađenje što se Selenium grid može rasporediti u K8s. Primer kako to uraditi može se pronaći u zvaničnom K8s repozitorijumu. Kao obično, prilažem linkove na kraju sekcije. Pored toga, u praktičnom vodiču je prikazano kako to uraditi putem Terraform-a. Takođe postoji uputstvo o tome kako skalirati broj podova koji sadrže kontejnere sa pretraživačima. Međutim, opcija automatskog skaliranja u kontekstu K8s ostaje još uvek nejasan zadatak. Kada sam započeo učenje, nisam našao nikakav praktični vodič ili preporuke. Nakon nekoliko istraživanja i eksperimenata uz podršku DevOps tima, odabrali smo pristup podizanja kontejnera sa potrebnim pretraživačima unutar jednog poda, koji se nalazi unutar jednog radnog čvora. Ovaj način nam omogućava da primenimo strategiju horizontalnog skaliranja čvorova povećanjem njihovog broja. Nadam se da će se situacija u budućnosti promeniti i da ćemo videti sve više i više opisa najboljih pristupa i gotovih rešenja, posebno nakon izlaska Selenium grid 4 sa izmenjenom unutrašnjom arhitekturom.
Selenoid:
Trenutno je raspoređivanje Selenoid-a u K8s najveće razočaranje. Oni nisu kompatibilni. Teoretski možemo podići Slenoid kontejner unutar poda, ali kada Selenoid počne da pokreće kontejnere sa pretraživačima, oni će i dalje biti unutar istog poda. To čini skaliranje nemogućim i, kao rezultat, rad Selenoid-a unutar klastera neće se razlikovati od rada unutar virtuelne mašine. Kraj priče.
Moon:
Zavedajoč temu ozkemu grlu pri delu s Selenoidom so razvijalci izdali močnejše orodje, ki so ga poimenovali Moon. To orodje je bilo prvotno zasnovano za delo s Kubernetesom in kot rezultat je mogoče in potrebno uporabiti funkcijo avtoširjenja. Poleg tega bi rekel, da je to trenutno jedina najboljše orodje v svetu Selenium, ki iz škatle ima podporo za native K8s cluster (niti ne, glej naslednje orodje ). Ključna značilnost Moona, ki omogoča to podporo, je:
Popolnoma brezstavno. Selenoid shranjuje v pomnilniku informacije o trenutno aktivnih sejah brskalnika. Če iz kakšnega razloga proces propade, se vse aktivne seje izgubijo. Moon pa nima notranjega stanja in ga lahko repliciramo čez podatkovne centre. Seje brskalnika ostanejo aktivne, tudi če ena ali več replik preneha delovati.
Tako je Moon odlična rešitev, vendar ima en problem, ni brezplačen. Cena je odvisna od števila sej. Brezplačno lahko zaženete samo 0-4 seje, kar ni ravno koristno. Ampak od pete seje naprej je treba plačati 5 $ za vsako. Situacija se lahko razlikuje od podjetja do podjetja, vendar v našem primeru uporaba Moona ni smiselna. Kot sem opisal zgoraj, lahko po potrebi zaženemo VM-e s Selenium Grid ali povečamo število nod v klastru. Na en pipeline običajno zaženemo 500 brskalnikov in vse vire ustavimo po končanih testih. Če bi uporabljali Moon, bi morali plačati dodatnih 500 x 5 = 2500 $ na mesec, ne glede na to, kako pogosto izvajamo teste. In ponovno, ne govorim 'ne uporabljajte Moona'. Za vaše naloge je to lahko nepogrešljiva rešitev, na primer, če imate veliko projektov/timov v organizaciji in potrebujete velik skupen klaster za vse. Kot vedno, na koncu pustim povezavo in priporočam, da izvedete vse potrebne izračune v kontekstu vaše naloge.
Callisto: (Opozorilo! To ni v prvotni članku in je vsebovano samo v ruskem prevodu)
Kot sem že povedal, je Selenium zelo priljubljeno orodje, IT sektor pa se hitro razvija. Medtem ko sem delal na prevodu, se je na spletu pojavil nov obetaven instrument Callisto (pozdrav Cypress in drugim ubijalcem Seleniuma). Deluje nativno s K8s in omogoča zagon Selenoid kontejnerjev v pods, razdeljeno po Nodes. Vse deluje takoj iz škatle, vključno z avtomatskim skaliranjem. Fantastično, a treba ga je testirati. Že uspelo mi je naložiti to orodje in izvesti nekaj poskusov. Vendar je še prezgodaj za dokončne zaključke, po prejemu rezultatov na dolgi rok bom morda napisal pregled v naslednjih člankih. Zaenkrat puščam samo povezave za samostojne raziskave.
Ilustracija trenutnega stanja infrastrukture
Povezave za nadaljnje raziskovanje
Povezave za nadaljnje raziskovanje
Podobna orodja
7. Infrastruktura kot koda (IaC)
Kratak opis tehnologije
In tu smo prišli do zadnjega poglavja. Običajno ta tehnologija in z njo povezane naloge niso v odgovornosti inženirjev za avtomatizacijo. In za to so razlogi. Prvič, v mnogih organizacijah so infrastrukturne zadeve pod nadzorom devops oddelka in ekipa razvojniški ne skrbi preveč o tem, kako pipeline deluje in kakšne podpore je potrebna za vse, kar je s tem povezano. Drugič, bodimo iskreni, praksa 'Infrastruktura kot koda (IaC)' se še vedno ne uporablja v mnogih podjetjih. Toda zagotovo je to postalo priljubljen trend in pomembno je truditi se biti vključen v povezane procese, pristope in orodja. Ali pa vsaj biti na tekočem s dogodki.
Začnimo z motivacijo za uporabo tega pristopa. Že smo razpravljali, da za zagon testov v GitlabCI potrebujemo vsaj vire za zagon Gitlab Runnerja. Za zagon kontejnerjev z brskalniki/emulatorji pa moramo rezervirati VM ali grozd. Poleg virov za testiranje potrebujemo tudi znatno število zmogljivosti za vzdrževanje razvojnih, staging in produkcijskih okolij, kar vključuje tudi baze podatkov, avtomatizirane urnike, mrežne konfiguracije, uravnoteževalnik obremenitve, uporabniška dovoljenja in še več. Ključni problem so potrebni napori za vzdrževanje vsega tega. Obstaja več načinov, kako lahko vnašamo spremembe in uvajamo posodobitve. Na primer, v kontekstu GCP lahko uporabimo UI konzolo v brskalniku in izvajamo vse akcije s klikom na gumbe. Alternativna možnost je uporaba API klicev za interakcijo s strežniškimi entitetami ali uporaba ukazne vrstice orodja gcloud za izvajanje potrebnih operacij. Vendar pa pri resnično velikem številu različnih entitet in infrastrukturnih elementov postane težko ali celo nemogoče izvesti vse operacije ročno. Kar je še huje, vse te ročne akcije so neobvladljive. Ne moremo jih poslati na pregled pred izvedbo, uporabiti sistema za nadzor različic in hitro razveljaviti spremembe, ki so pripeljale do incidenta. Za reševanje tovrstnih težav so inženirji razvili in še razvijajo avtomatizirane bash/shell skripte, kar ni veliko boljše od prejšnjih metod, saj jih ni tako enostavno hitro prebrati, razumeti, vzdrževati in modificirati v proceduralnem slogu.
V tem članku in praktičnem vodiču uporabljam 2 orodji, povezana s prakso IaC. To sta Terraform in Ansible. Nekateri menijo, da nima smisla uporabljati ju hkrati, saj imata podobne funkcionalnosti in sta medsebojno zamenljiva. Vendar pa je dejstvo, da sta ta orodja prvotno zasnovana za zelo različne naloge. Potrdili so, da bi se ta orodja morala dopolnjevati, na skupni predstavitvi razvijalcev podjetij HashiCorp in RedHat. Konceptualna razlika je v tem, da je Terraform orodje za provisioning za upravljanje samih strežnikov. Medtem ko je Ansible orodje za upravljanje s konfiguracijami, katerega naloga je namestitev, nastavitev in upravljanje programske opreme na teh strežnikih.
Še ena ključna značilnost teh orodij je slog pisanja kode. Za razliko od bash in Ansible, Terraform uporablja deklarativni slog, ki temelji na opisu želenega končnega stanja, ki ga je treba doseči. Na primer, če nameravamo ustvariti 10 VM-ov in uveljaviti spremembe preko Terraform, bomo dobili 10 VM-ov. Če skripto ponovno zaženemo, se ne bo zgodilo nič, saj že imamo 10 VM-ov, in Terraform to ve, saj shranjuje trenutno stanje infrastrukture v state-datoteko. Ansible pa uporablja proceduralni pristop in, če ga prosimo, da ustvari 10 VM-ov, bomo ob prvem zagonu dobili 10 VM-ov, podobno kot pri Terraform. A po ponovnem zagonu jih bomo imeli že 20. To je bistvena razlika. V proceduralnem slogu ne shranjujemo trenutnega stanja in preprosto opisujemo zaporedje korakov, ki jih je treba izvesti. Seveda lahko obdelamo različne situacije, dodamo nekaj preverjanj glede obstoja virov in trenutnega stanja, vendar ni smiselno izgubljati časa in naprezati se nad nadzorom te logike. Poleg tega povečuje tveganje za napake.
Skozi vse zgoraj navedeno lahko sklenemo, da je za provisioning strežnikov bolj primerno orodje Terraform in deklarativna notacija. Upravljanje s konfiguracijami pa je bolje delegirati na Ansible. Ko to razjasnimo, si poglejmo primere uporabe v kontekstu avtomatizacije.
Vrednost za infrastrukturo avtomatizacije
Pomembno je razumeti, da mora biti infrastruktura za avtomatizacijo testiranja obravnavana kot del celotne infrastrukture podjetja. To pomeni, da morajo biti vse prakse IaC globalno uporabljene za vire celotne organizacije. Kdo je za to odgovoren, je odvisno od vaših procesov. DevOps ekipa ima več izkušenj na tem področju, saj vidijo celotno sliko. Vendar so QA inženirji bolj vključeni v proces konstrukcije avtomatizacije in strukturo pipeline-a, kar jim omogoča boljši vpogled v vse zahtevane spremembe in možnosti za izboljšave. Najboljša možnost je sodelovati, izmenjavati znanje in ideje za dosego pričakovanega rezultata.
Prikazal bom nekaj primerov uporabe Terraform-a in Ansible-a v kontekstu avtomatizacije testiranja ter orodij, o katerih smo se prej pogovarjali:
1. Opisati preko Terraform-a potrebne značilnosti in parametre VMs in clustrov.
2. Namestiti s pomočjo Ansible-a potrebna orodja za testiranje: docker, Selenoid, Selenium Grid ter naložiti potrebne različice brskalnikov/emulatorjev.
3. Opisati preko Terraform-a značilnosti VM, v kateri bo zagnan GitLab Runner.
4. Namestiti s pomočjo Ansible-a GitLab Runner in potrebna spremljevalna orodja, določiti nastavitve in konfiguracije.
Ilustracija trenutnega stanja infrastrukture
Viri za študij:
Podobna orodja
Povzemimo!
Korak
Tehnologija
Instrumenti
Vrednost za infrastrukturo avtomatizacije
1
Lokalno delovanje
Node.js, Selenium, Appium
- Najbolj priljubljena orodja za splet in mobilne naprave
- Podpora mnogim jezikom in platformam (vključno z Node.js)
2
Sistemi za kontrolu verzija
Git
- Podobne prednosti s kodom razvoja
3
Kontejnerizacija
Docker, Selenium grid, Selenoid (Web, Android)
- Vzporedno izvajanje testov
- Izolirana okolja
- Enostavno, fleksibilno posodabljanje različic
- Dinamično ustavljanje neuporabljenih virov
- Enostavno nastaviti
4
CI / CD
Gitlab CI
- Testi so del konvejerja
- Hitro povratno obveščanje
- Vidnost za celotno podjetje / ekipo
5
Cloud platforme
Google Cloud Platform
- Viri po potrebi (plačamo le, ko so potrebni)
- Enostavno upravljanje in posodabljanje
- Vidnost in nadzor vseh virov
6
Orkestracija
Kubernetes
V kontekstu kontejnerjev z brskalniki/emulatorji znotraj pods:
- Širjenje / avtomatsko širjenje
- Samovzpostavitev
- Posodobitve in povratki brez prekinitev
7
Infrastruktura kao kod (IaC)
Terraform, Ansible
- Podobne prednosti z infrastrukturo razvoja
- Vse prednosti verzioniranja kode
- Enostavne spremembe in vzdrževanje
- Popolnoma avtomatizirano
Mind map diagrami: evolucija infrastrukture
korak1: Lokalan
korak2: VCS
korak3: Kontejnerizacija
korak4: CI/CD
korak5: Cloud platforme
korak6: Orkestracija
korak7: IaC
Kaj zdaj?
Dakle, ovo je kraj članka. Ali na kraju bih želeo da postavim neke dogovore s vama.
Sa vaše strane
Kao što je rečeno na početku, želeo bih da članak bude od praktične koristi i da vam pomogne da primenite stečeno znanje u stvarnom radu. Ponovo dodajem.
Ali čak i nakon toga ne stajte, vežbajte, istražujte relevantne linkove i knjige, saznajte kako to funkcioniše u vašoj kompaniji, pronađite mesta koja se mogu poboljšati i učestvujte u tome. Srećno!
S moje strane
Iz naslova je jasno da je ovo bila samo prva deo. Iako je ispao prilično obiman, ovde još uvek nisu obrađene važne teme. U drugom delu planiram da razmotrim infrastrukturu automatizacije u kontekstu IOS-a. Zbog ograničenja Appla, povezanih sa pokretanjem IOS simulacija samo na macOS sistemima, naš skup rešenja je ograničen. Na primer, lišeni smo mogućnosti da koristimo Docker za pokretanje simulacije ili javnih oblaka za pokretanje virtuelnih mašina. Ali to ne znači da ne postoje druge alternative. Pokušaću da vas obavestim o najnaprednijim rešenjima i modernim alatima!
Takođe nisam spomenuo prilično obimne teme vezane za nadzor. U delu 3 planiram da razmotrim najpopularnije alate za nadgledanje infrastrukture, kao i koje podatke i metrike treba uzeti u obzir.
I na kraju. U budućnosti planiram da objavim video kurs o izgradnji testne infrastrukture i popularnim alatima. Trenutno na internetu ima mnogo kurseva i predavanja o DevOps-u, ali svi materijali su predstavljeni u kontekstu razvoja, a ne automatizacije testiranja. U ovom pitanju mi je zaista potrebna povratna informacija, da li bi takav kurs bio zanimljiv i vredan za zajednicu testera i automatizatora. Unapred hvala!
Izvor: habr.com
