Eskolara itzuli: nola trebatu eskuzko probatzaileak proba automatikoei aurre egiteko

Bost QA eskatzailetik lauk proba automatizatuekin lan egiten ikasi nahi dute. Enpresa guztiek ezin dituzte eskuzko probatzaileen halako nahiak bete lan orduetan. Wrikek langileentzako automatizazio eskola bat egin zuen eta askoren gogo hori gauzatu zuen. Ikastetxe honetan parte hartu nuen, hain zuzen ere, QA ikasle gisa.

Selenium-ekin lan egiten ikasi nuen eta orain modu independentean autotest kopuru jakin bat onartzen dut ia kanpoko laguntzarik gabe. Eta, gure esperientzia bateratuaren emaitzetatik eta nire ondorio pertsonaletatik abiatuta, automatizazio eskolarik egokienaren formula bera ateratzen saiatuko naiz.

Wrike-ren esperientzia eskola bat antolatzeko

Automatizazio-eskola baten beharra argi geratu zenean, bere antolakuntza Stas Davydov-en esku geratu zen, automatizazioaren arduradun teknikoa. Nork baino berak azaldu dezake zergatik sortu duten ekimen hau, emaitzak lortu dituzten eta emandako denboraz damutzen diren? Eman diezaiogun hitza:

β€” 2016an, autotestetarako marko berri bat idatzi genuen eta probak idazteko erraza izan zedin egin genuen: urrats normalak agertu ziren, egitura askoz ulergarriagoa zen. Ideia bat bururatu zitzaigun: proba berriak idatzi nahi dituen guztiak inplikatu behar ditugu, eta ulermena errazteko, hitzaldi sorta bat sortu genuen. Kolektiboki gaien plan bat egin genuen, etorkizuneko irakasle bakoitzak beretzat hartu zuen bat eta horri buruzko txosten bat prestatu zuen.

β€” Zein zailtasun izan zituzten ikasleek?

β€” Nagusiki, noski, arkitektura. Galdera asko zeuden gure proben egiturari buruz. Iritzietan, gai honi buruz asko idatzi zen eta xehetasun gehiago azaltzeko hitzaldi osagarriak egin behar izan genituen.

β€” Eskolak irabazi al zuen?

- Bai, zalantzarik gabe. Berari esker, jende asko aritu zen idazketa probetan, eta, batez beste, ospitalean, denak hobeto ulertzen hasi ziren autotestak zer diren, nola idazten diren eta nola abian jartzen diren. Automatizazio-ingeniarien karga ere gutxitu egin da: gaur egun, probak aztertzeko laguntza eskaera askoz ere gutxiago jasotzen dugu, probatzaileak eta garatzaileak beraiek ia egoera guztietan horri aurre egiten hasi baitira. Bada, barruko hainbat abantaila ditu sailarentzat: aurkezpenetan eta hitzaldietan esperientzia lortu genuen, eta horri esker, automatizazio-ingeniari batzuek dagoeneko lortu dute hitzaldietan aurkezpenak egitea, eta bideo eta aurkezpen sorta indartsua ere jaso dute etorri berriak sartzeko.

Nire izenean, gehituko dut gure sailen arteko komunikazioa erraztu egin dela maila barregarri bezain erraz batera. Esate baterako, orain ia ez dut pentsatu behar zein kasu eta zein atomizazio mailatan automatizatu. Ondorioz, interesdun guztiak oso-osorik zaintzen ari dira probaren estaldura, etengabe hazten ari dena. Inork ez die ezinezkoa besteei eskatzen.

Oro har, taldeen lanean eragina positiboa da zalantzarik gabe. Agian artikulu hau irakurtzen duten lankideek ere antzeko zerbait egitea pentsatzen ari al dira? Orduan aholkua sinplea izango da: merezi du proba automatikoak zuretzako lehentasunak badira. Jarraian, galdera konplexuago bati buruz hitz egingo dugu: nola antolatu hau guztia ahalik eta ondoen, alderdi guztien kostuak minimoak izan daitezen eta irteera maximoa izan dadin.

Antolatzeko aholkuak

Eskola baliagarria zen, baina, Stasek aitortu zuenez, zailtasun batzuk zeuden, eta horregatik hitzaldi osagarriak antolatu behar ziren. Eta neure burua-ezjakintasunean eta neure burua-orain alderatzen berri nuen ikasle gisa, hurrengo urratsak formulatu nituen, nire ustez, probatzaileei proba automatizatuak ulertzen irakasteko modu aproposa sortzeko.

0. urratsa. Sortu hiztegi bat

Jakina, urrats hau ez da beharrezkoa QA bakarrik. Hala ere, esplizitu egin nahi dut: automatizazioaren kode-oinarria irakurtzeko moduan mantendu behar da. Programazio lengoaiak - ez behintzat hizkuntza, eta honetatik hasi dezakezu murgiltzea.

Eskolara itzuli: nola trebatu eskuzko probatzaileak proba automatikoei aurre egiteko

Hona hemen ataza-ikuspegi baten pantaila-argazkia, elementuen izenekin. Imajina dezagun taskview kutxa beltz gisa probatzen ari zarela eta ez duzula inoiz Selenium zure bizitzan ikusi. Zer egiten du kode honek?

Eskolara itzuli: nola trebatu eskuzko probatzaileak proba automatikoei aurre egiteko

(Spoiler - zeregina atseden bidez ezabatzen da administratzailearen izenean, eta orduan ikusten dugu korrontean horren erregistroa dagoela.)

Urrats honek bakarrik QAA eta QA hizkuntzak hurbiltzen ditu. Errazagoa da automatizazio-taldeentzat exekuzio baten emaitzak azaltzea; eskuzko probatzaileek esfortzu gutxiago egin behar dute kasuak sortzen: xehetasun gutxiago egin daitezke. Hala ere, denek elkar ulertzen dute. Benetako entrenamenduak hasi baino lehen ere jaso genituen irabaziak.

1. urratsa. Errepikatu esaldiak

Jarrai dezagun hizkuntzarekin paralelismoa. Txikitan hitz egiten ikasten dugunean, ez gara etimologiatik eta semantikatik abiatzen. "Ama", "jostailu bat erosi" errepikatzen dugu, baina ez berehala hitz hauen sustrai protoindoeuroparetara sartu. Beraz, hemen dago: ez du balio autotesten ezaugarri teknikoen sakontasunean murgiltzeak funtzionatzen duen zerbait idazten saiatu gabe.
Intuitibo samarra dirudi, baina funtzionatzen du.

Lehenengo ikasgaian, autotestak zuzenean idazteko oinarriak ematea merezi du. Garapen-ingurunea ezartzen laguntzen dugu (nire kasuan, Intellij IDEA), lehendik dagoen klase batean beste metodo bat idazteko beharrezkoak diren gutxieneko hizkuntza-arauak azaltzen ditugun urratsak erabiliz. Beraiekin proba bat edo bi idazten ditugu eta etxerako lanak ematen dizkiegu, nik honela formatuko nuke: maisutik adar bat adarkatu, baina hainbat proba kendu dizkiote. Haien deskribapenak baino ez dira geratzen. Proba hauek leheneratzeko eskatzen diegu probatzaileei (ez show diff bidez, noski).

Ondorioz, dena entzun eta egin zuenak gai izango da:

  1. garapen-ingurunearen interfazearekin lan egiten ikasi: adarrak, laster-teklak, konpromezuak eta bultzadak sortzen;
  2. hizkuntzaren eta klaseen egituraren oinarriak menderatzea: injekzioak non txertatu eta non inportatu, zergatik behar diren oharpenak eta zer-nolako sinboloak aurkitzen diren bertan, urratsez gain;
  3. ekintzaren arteko aldea ulertu, itxaron eta egiaztatu, non zer erabili;
  4. nabaritu autotesten eta eskuzko egiaztapenen arteko ezberdintasuna: autotestetan kudeatzaile bat edo beste tira dezakezu interfazearen bidez ekintzak egin beharrean. Adibidez, bidali iruzkin bat zuzenean backend-era ataza-ikuspegia ireki beharrean, sarrera hautatu, testua idatzi eta Bidali botoia sakatu;
  5. hurrengo urratsean erantzungo diren galderak formulatu.

Azken puntua oso garrantzitsua da. Erantzun hauek erraz eman daitezke aldez aurretik, baina irakaskuntza-printzipio garrantzitsua da formulatutako galderarik gabeko erantzunak ez direla gogoratzen eta ez direla erabiltzen azkenean behar denean.

Ideala litzateke une honetan QA taldeko automatizazio ingeniari batek borrokan proba pare bat idazteko zeregina esleitzea eta bere adarrarekiko konpromisoa uztea.

Zer ez eman:

  1. garapen-ingurunearen eta programazio-lengoaiaren beraren funtzionalitatearen ezagutza sakonagoa, adarrekin modu independentean lan egitean soilik beharko dena. Ez da gogoratuko, bi edo hirutan azaldu beharko duzu, baina automatizazio ingeniarien denbora baloratzen dugu, ezta? Adibideak: gatazkak konpontzea, git-era fitxategiak gehitzea, klaseak hutsetik sortzea, mendekotasunekin lan egitea;
  2. xpath-ekin zerikusia duen guztia. Serio. Bereiz hitz egin behar duzu, behin eta oso kontzentratu.

2. urratsa. Gramatika hurbilagotik begiratuz

Gogora dezagun #0 urratseko ataza-ikuspegiaren pantaila-argazkia. CheckCommentWithTextExists izeneko urratsa dugu. Gure probatzaileak urrats honek zer egiten duen ulertzen du eta urratsaren barrura begiratu eta pixka bat deskonposatu dezakegu.

Eta barruan honako hauek ditugu:

onCommentBlock(userName).comment(expectedText).should(displayed());

Non dagoenCommentBlock

onCommonStreamPanel().commentBlock(userName);

Orain "erosi jostailu bat" ez esaten ikasten dugu, "erosi jostailu bat Detsky Mir dendatik, goiko hirugarren apalean dagoen armairu urdinean dagoena". Elementu bat sekuentzialki seinalatzen dugula azaldu behar da, elementu handiagoetatik (korrontea -> blokea pertsona jakin baten iruzkinekin -> zehaztutako testua dagoen bloke honen zati hori).

Ez, oraindik ez da garaia xpath-i buruz hitz egiteko. Aipatu laburki argibide hauek guztiak haiek deskribatzen dituztela eta herentzia horietatik pasatzen dela. Baina parekide eta zerbitzari guzti horiei buruz hitz egin behar dugu; urrats horri bereziki lotuta daude eta beharrezkoak dira gertatzen ari dena ulertzeko. Baina ez gehiegi kargatu: zure ikasleak gero bere kabuz azter ditzake baieztapen konplexuagoak. Seguruenik, beharko luke, waitUntil, bistaratu();, existitzen();, not(); nahikoa izango litzateke.

Etxeko lanak begi bistakoak dira: proba kopuru jakin baterako beharrezkoak diren hainbat urratsen edukia kendu den adar bat. Utzi probalariek leheneratzen dituzten eta martxan jarri berriro berdea.

Gainera, proba-taldeak bere lanean funtzio berriak ez ezik, akatsen konponketa ere baditu, akats horien probak berehala idazteko eta askatzeko eska diezaiokezu. Seguruenik, elementu guztiak dagoeneko deskribatuta daude; baliteke urrats pare bat faltatzea. Hau entrenamendu ezin hobea izango da.

3. urratsa. Murgiltze osoa

Ahalik eta osatuena bere eginkizun zuzenak betetzen jarraituko duen probatzaile batentzat. Azkenik, xpath-i buruz hitz egin behar dugu.

Lehenik eta behin, argi utzi CommentBlock eta iruzkin hauek guztiak haiek deskribatzen dituztela.

Eskolara itzuli: nola trebatu eskuzko probatzaileak proba automatikoei aurre egiteko

Guztira:

"//div[contains(@class, β€˜stream-panel’)]//a[contains(@class,'author') and text()='{{ userName }}’]//div[contains(@class,'change-wrapper') and contains(.,'{{ text }}’)]"

Istorioaren ordena oso garrantzitsua da. Lehenik eta behin, dagoen edozein xpath hartzen dugu eta elementuen fitxak elementu bat eta bakarra duen erakusten dugu. Jarraian, egiturari buruz hitz egingo dugu: WebElement erabili behar duzunean eta elementu berri baterako fitxategi bereizi bat sortu behar duzunean. Honek herentzia hobeto ulertzeko aukera emango dizu.

Esplizituki adierazi behar da elementu bakar bat zereginen ikuspegi osoa dela, elementu ume bat duela - korronte osoa, haurraren elementu bat duena - iruzkin bereizia, etab. Elementu seme-alabak elementu nagusien barruan daude bai orrialdean, bai autotest esparruaren egituran.

Une honetan, ikusleek ondo ulertu beharko lukete nola heredatzen diren eta zer sar daitekeen puntuaren ondoren onCommentBlock-en. Une honetan, eragile guztiak azalduko ditugu: /, //, ., [] eta abar. Erabilerari buruzko ezagutza gehitzen dugu zamari @class eta beharrezko beste gauza batzuk.

Eskolara itzuli: nola trebatu eskuzko probatzaileak proba automatikoei aurre egiteko

Ikasleek xpath modu honetan nola itzultzen den ulertu beharko lukete. Finkatzeko - hori bai, etxeko lanak. Elementuen deskribapenak ezabatzen ditugu, proben lana berreskura dezatela.

Zergatik bide zehatz hau?

Ez dugu ezagutza konplexua duen pertsona bat gainkargatu behar, baina dena aldi berean azaldu behar dugu, eta hori dilema zaila da. Bide honek aukera emango digu lehenik eta behin entzuleei galderak egin eta zerbait ez ulertzea eta hurrengo momentuan erantzutea. Arkitektura osoari buruz hitz egiten baduzu, urratsen edo xpath gaia aztertzen den unean, haren atal garrantzitsuenak ahaztu egingo dira ulertezinaren ondorioz.

Hala ere, zuetako batzuk ziurrenik zure esperientzia partekatu ahal izango duzu prozesua nola optimizatu daitekeenari buruz. Pozik irakurriko ditut antzeko iradokizunak iruzkinetan!

Iturria: www.habr.com

Gehitu iruzkin berria