Fjouwer fan de fiif QA-oanfregers wolle leare hoe te wurkjen mei automatisearre tests. Net alle bedriuwen kinne sokke winsken fan hânmjittige testers yn 'e wurktiden ferfolje. Wrike hold in automatisearringskoalle foar meiwurkers en realisearre dizze winsk foar in protte. Ik die mei oan dizze skoalle krekt as QA-studint.
Ik learde hoe te wurkjen mei Selenium en stypje no selsstannich in bepaald oantal autotests mei praktysk gjin help fan bûten. En, basearre op de resultaten fan ús mienskiplike ûnderfining en myn persoanlike konklúzjes, sil ik besykje de formule foar de meast ideale skoalle fan automatisearring ôf te lieden.
Wrike's ûnderfining by it organisearjen fan in skoalle
Doe't de needsaak foar in automatisearringsskoalle dúdlik waard, foel har organisaasje oan Stas Davydov, de technyske lieding fan automatisearring. Wa oars as hy kin ferklearje wêrom't se mei dit inisjatyf kamen, oft se resultaten hawwe helle en oft se spyt hawwe fan de bestege tiid? Litte wy him it wurd jaan:
- Yn 2016 hawwe wy in nij ramt foar autotests skreaun en makke dat it maklik waard om tests te skriuwen: normale stappen ferskynden, de struktuer waard folle begrypliker. Wy kamen op in idee: wy moatte elkenien belûke dy't nije toetsen skriuwe wol en om it makliker te begripen hawwe wy in searje lêzingen makke. Wy kamen mei-elkoar mei in plan fan ûnderwerpen, elk fan de takomstige dosinten naam ien foar harsels en makke dêr in ferslach oer.
- Hokker swierrichheden hiene de learlingen?
- Benammen, fansels, arsjitektuer. D'r wiene in protte fragen oer de struktuer fan ús tests. Yn feedback waard in protte oer dit ûnderwerp skreaun en moasten wy ekstra lêzingen hâlde om mear detail út te lizzen.
- Hat de skoalle lean?
- Ja, seker. Mei tank oan har wiene in protte minsken belutsen by it skriuwen fan tests, en yn 't gemiddelde yn it sikehûs begon elkenien better te begripen wat autotests binne, hoe't se skreaun binne en hoe't se wurde lansearre. De lêst op automatisearrings-yngenieurs is ek ôfnommen: wy krije no in protte kearen minder oanfragen foar help by it analysearjen fan tests, om't testers en ûntwikkelders dit sels yn hast alle situaasjes begûnen om te gean. No, d'r binne ferskate ynterne foardielen foar de ôfdieling: wy hawwe ûnderfining opdien yn presintaasjes en lêzingen, wêrtroch't guon automatisearrings-yngenieurs it al slagge hawwe om presintaasjes op konferinsjes te meitsjen, en ek in krêftige set fideo's en presintaasjes krigen foar it oan board fan nijkommers.
Ut eigen namme sil ik der oan taheakje dat de kommunikaasje tusken ús ôfdielings ferienfâldige is nei in suver ridlik maklik nivo. Bygelyks, no hoech ik praktysk net te tinken oer hokker gefallen en op hokker nivo fan atomiteit te automatisearjen. Dêrtroch soargje alle belangstellenden folslein foar de testdekking, dy't hieltyd groeit. Nimmen freget it ûnmooglike fan oaren.
Yn 't algemien is de ynfloed op it wurk fan teams perfoarst posityf. Miskien tinke kollega's dy't dit artikel lêze ek oer it dwaan fan wat ferlykber? Dan sil it advys ienfâldich wêze: it is it wurdich as automatyske testen in prioriteit foar jo binne. Folgjende sille wy prate oer in mear komplekse fraach: hoe te organisearjen dit alles sa goed mooglik, sadat de kosten fan alle partijen binne minimaal en de útfier is maksimaal.
Organizing Tips
De skoalle wie nuttich, mar, lykas Stas joech ta, wiene d'r wat swierrichheden, wêrtroch't it nedich wie om ekstra lêzingen te regeljen. En it wie as resinte studint mysels-yn-ûnwittendheid en mysels te fergelykjen-no't ik de folgjende stappen formulearre om, nei myn miening, de ideale manier te meitsjen om testers te learen om automatisearre tests te begripen.
Stap 0. Meitsje in wurdboek
Fansels is dizze stap net allinich nedich foar QA. Ik wol it lykwols eksplisyt meitsje: de automatisearringskoadebase moat yn in lêsbere foarm hâlden wurde. Programmatalen - net it minste talen, en fan dit kinne jo begjinne jo dûk.
Hjir is in skermôfbylding fan in taakwerjefte mei de nammen fan 'e eleminten. Litte wy ús foarstelle dat jo taskview as in swarte doaze testen en Selenium noait yn jo libben hawwe sjoen. Wat docht dizze koade?
(Spoiler - de taak wurdt wiske fia rest út namme fan de admin, en dan sjogge wy dat d'r in rekord is fan dit yn 'e stream.)
Dizze stap allinich bringt de QAA- en QA-talen tichter byinoar. It is makliker foar automatisearringsteams om de resultaten fan in run út te lizzen; hânmjittige testers moatte minder muoite besteegje oan it meitsjen fan gefallen: se kinne minder detaillearre wurde. Dochs begrypt elkenien inoar. Wy krigen de winst noch foardat de eigentlike training begon.
Stap 1. Werhelje phrases
Litte wy de parallel mei taal trochgean. As wy as bern prate leare, begjinne wy net fan etymology en semantyk. Wy werhelje "mem", "keapje in boartersguod", mar gean net fuortendaliks yn 'e Proto-Yndo-Jeropeeske woartels fan dizze wurden. Sa is it hjir: it hat gjin punt om yn 'e djipten fan' e technyske eigenskippen fan autotests te dûken sûnder te besykjen wat te skriuwen dat wurket.
It klinkt in bytsje tsjinoerstelde, mar it wurket.
Yn 'e earste les is it wurdich in basis te jaan oer hoe't jo autotests direkt skriuwe. Wy helpe it opsetten fan de ûntwikkeling omjouwing (yn myn gefal, Intellij IDEA), ferklearje de minimale taal regels dy't nedich binne om te skriuwen in oare metoade yn in besteande klasse mei help fan de besteande stappen. Wy skriuwe ien of twa toetsen mei har en jouwe se húswurk, dat soe ik sa opmeitsje: in tûke tûke fan 'e master ôf, mar der binne ferskate toetsen fan fuorthelle. Allinnich har beskriuwingen bliuwe oer. Wy freegje testers om dizze tests te herstellen (net fia show diff, fansels).
As gefolch sil dejinge dy't harke en alles dien hat:
- learje te wurkjen mei de ynterface foar ûntwikkelingsomjouwing: tûken meitsje, fluchtoetsen, commits en pushes;
- behearskje de basis fan 'e struktuer fan' e taal en klassen: wêr te ynfoegje ynjeksjes en wêr te ymportearjen, wêrom annotaasjes binne nedich, en hokker soarte fan symboalen wurde fûn dêr, neist stappen;
- begripe it ferskil tusken aksje, wachtsje en kontrolearje, wêr te brûken wat;
- fernimme it ferskil tusken autotests en hânmjittich kontrôles: yn autotests kinne jo lûke ien of oare handler ynstee fan in útfiere aksjes fia de ynterface. Stjoer bygelyks in opmerking direkt nei de efterkant ynstee fan in taakwerjefte te iepenjen, de ynfier te selektearjen, tekst te typen en op de knop Ferstjoere te klikken;
- formulearje fragen dy't yn 'e folgjende stap beäntwurde wurde.
It lêste punt is tige wichtich. Dizze antwurden kinne maklik fan tefoaren wurde jûn, mar it is in wichtich learprinsipe dat antwurden sûnder formulearre fragen net ûnthâlden wurde en net brûkt wurde as it úteinlik nedich is.
It soe ideaal wêze as op dit stuit in automatisearrings-yngenieur fan it QA-team him in taak tawize mei it skriuwen fan in pear tests yn 'e striid en him talitte om te subcommit nei syn branch.
Wat net te jaan:
- mear yngeande kennis fan de funksjonaliteit fan de ûntwikkelomjouwing en de programmeartaal sels, dy't allinnich nedich wêze sil by it wurkjen mei tûken selsstannich. It sil net ûnthâlden wurde, jo moatte it twa of trije kear útlizze, mar wy wurdearje de tiid fan automatisearringsingenieurs, krekt? Foarbylden: konflikten oplosse, triemmen tafoegje oan git, klassen meitsje fanôf it begjin, wurkje mei ôfhinklikens;
- alles relatearre oan xpath. Serieus. Jo moatte der apart oer prate, ien kear en tige konsintrearre.
Stap 2. In tichterby besjen op de grammatika
Litte wy it skermôfbylding fan taakwerjefte ûnthâlde fan stap #0. Wy hawwe in stap neamd checkCommentWithTextExists. Us tester begrypt al wat dizze stap docht en wy kinne yn 'e stap sjen en it in bytsje ûntbrekke.
En binnen hawwe wy it folgjende:
onCommentBlock(userName).comment(expectedText).should(displayed());Wêr opCommentBlock is
onCommonStreamPanel().commentBlock(userName);No learje wy net te sizzen "keapje in boartersguod", mar "keapje in boartersguod fan 'e Detsky Mir-winkel, leit yn' e blauwe kast op 'e tredde planke fan boppen." It is nedich om út te lizzen dat wy op in elemint sequentieel wize, fan gruttere eleminten (stream -> blok mei opmerkings fan in bepaalde persoan -> dat diel fan dit blok dêr't de oantsjutte tekst sit).
Nee, it is noch gjin tiid om oer xpath te praten. Neam mar koart dat al dizze ynstruksjes wurde beskreaun troch harren en erfenis giet troch harren. Mar wy moatte prate oer al dizze matchers en obers; se relatearje spesifyk oan dizze stap en binne nedich om te begripen wat der bart. Mar net oerladen: jo studint kin letter mear komplekse bewearingen sels bestudearje. Meast wierskynlik, should, waitUntil, displayed();, exist();, not(); soe genôch wêze moatte.
It húswurk leit foar de hân: in tak wêryn't de ynhâld fan ferskate stappen dy't nedich binne foar in bepaald oantal toetsen fuorthelle is. Lit de testers har weromsette en meitsje de rin wer grien.
Derneist, as it testteam net allinich nije funksjes yn har wurk hat, mar ek wat bugfixes, kinne jo him freegje om fuortendaliks tests foar dizze bugs te skriuwen en se frij te litten. Meast wierskynlik binne alle eleminten al beskreaun; mar in pear stappen kinne ûntbrekke. Dit sil de perfekte workout wêze.
Stap 3. Folsleine immersion
Sa folslein mooglik foar in tester dy't trochgiet mei it útfieren fan syn direkte taken. Uteinlik moatte wy prate oer xpath.
Lit ús earst dúdlik meitsje dat al dizze opCommentBlock en opmerking wurde beskreaun troch har.
Totaal:
"//div[contains(@class, ‘stream-panel’)]//a[contains(@class,'author') and text()='{{ userName }}’]//div[contains(@class,'change-wrapper') and contains(.,'{{ text }}’)]"De folchoarder fan it ferhaal is tige wichtich. Earst nimme wy alle besteande xpath en litte sjen hoe't it ljepblêd eleminten ien en mar ien elemint befettet. Folgjende, wy sille prate oer de struktuer: as jo moatte brûke WebElement, en as jo moatte meitsje in aparte triem foar in nij elemint. Dit sil tastean jo om better begripe erfenis.
It moat eksplisyt sein wurde dat ien elemint de folsleine taakwerjefte is, it befettet in bernelemint - de heule stream, dy't in bernelemint befettet - in aparte opmerking, ensfh. Berneleminten binne binnen âldereleminten sawol op 'e side as yn' e struktuer fan it autotest-ramt.
Op dit punt soe it publyk stevich moatte begrepen hawwe hoe't se erfd binne en wat kin wurde ynfierd nei de stip by onCommentBlock. Op dit punt ferklearje wy alle operators: /, //, ., [] ensafuorthinne. Wy foegje kennis oer gebrûk yn 'e lading @class en oare needsaaklike dingen.
Studinten moatte begripe hoe't jo xpath op dizze manier kinne oersette. Om te konsolidearjen - dat is krekt, húswurk. Wy wiskje de beskriuwingen fan 'e eleminten, lit se it wurk fan' e tests weromsette.
Wêrom dit bysûndere paad?
Wy moatte net overload in persoan mei komplekse kennis, mar wy moatte útlizze alles yn ien kear, en dit is in dreech dilemma. Dit paad sil ús tastean om harkers earst fragen te stellen en wat net te begripen en se it folgjende momint te beantwurdzjen. As jo prate oer de hiele arsjitektuer, dan troch de tiid dat it ûnderwerp fan stappen of xpath wurdt analysearre, de wichtichste dielen dêrfan sille al fergetten wurde fanwegen harren ûnbegryplikens.
Guon fan jo sille lykwols wierskynlik jo ûnderfining kinne diele oer hoe't it proses noch mear kin wurde optimalisearre. Ik sil bliid wêze om ferlykbere suggestjes te lêzen yn 'e kommentaren!
Boarne: www.habr.com