Vier uit vyf QA-aansoekers wil leer hoe om met outomatiese toetse te werk. Nie alle maatskappye kan gedurende werksure aan sulke begeertes van handtoetsers voldoen nie. Wrike het 'n outomatiseringskool vir werknemers gehou en het hierdie begeerte vir baie besef. Ek het juis as 'n QA-student aan hierdie skool deelgeneem.
Ek het geleer hoe om met Selenium te werk en ondersteun nou onafhanklik 'n sekere aantal outotoetse met feitlik geen hulp van buite nie. En, gebaseer op die resultate van ons gesamentlike ervaring en my persoonlike gevolgtrekkings, sal ek probeer om die einste formule af te lei vir die mees ideale skool van outomatisering.
Wrike se ervaring met die organisasie van 'n skool
Toe die behoefte aan 'n outomatiseringskool duidelik geword het, het die organisasie daarvan geval by Stas Davydov, die tegniese leier van outomatisering. Wie anders behalwe hy kan verduidelik hoekom hulle met hierdie inisiatief vorendag gekom het, of hulle resultate behaal het en of hulle spyt is oor die tyd wat hulle spandeer het? Kom ons gee hom die woord:
— In 2016 het ons 'n nuwe raamwerk vir outotoetse geskryf en dit so gemaak dat dit maklik geword het om toetse te skryf: normale stappe het verskyn, die struktuur het baie meer verstaanbaar geword. Ons het met 'n idee vorendag gekom: ons moet almal betrek wat nuwe toetse wil skryf, en om dit makliker te maak om te verstaan, het ons 'n reeks lesings geskep. Ons het gesamentlik met 'n plan van onderwerpe vorendag gekom, elkeen van die toekomstige dosente het een vir hulself geneem en 'n verslag daaroor voorberei.
— Watter probleme het die studente gehad?
— Hoofsaaklik natuurlik argitektuur. Daar was baie vrae oor die struktuur van ons toetse. In terugvoer is baie oor hierdie onderwerp geskryf en ons moes addisionele lesings hou om in meer besonderhede te verduidelik.
— Het die skool vrugte afgewerp?
- Ja beslis. Danksy haar was baie mense betrokke by die skryf van toetse, en gemiddeld in die hospitaal het almal beter begin verstaan wat outotoetse is, hoe dit geskryf word en hoe dit van stapel gestuur word. Die las op outomatiseringsingenieurs het ook afgeneem: ons ontvang nou baie keer minder versoeke om hulp met die ontleding van toetse, aangesien toetsers en ontwikkelaars dit self in feitlik alle situasies begin hanteer het. Wel, daar is verskeie interne voordele vir die departement: ons het ondervinding in aanbiedings en lesings opgedoen, waardeur sommige outomatiseringsingenieurs reeds daarin geslaag het om aanbiedings by konferensies te maak, en het ook 'n kragtige stel video's en aanbiedings ontvang om nuwelinge aan boord te kry.
Namens my sal ek byvoeg dat kommunikasie tussen ons departemente vereenvoudig is tot 'n ronduit belaglike maklike vlak. Byvoorbeeld, nou hoef ek feitlik nie te dink oor watter gevalle en op watter vlak van atomiteit om te outomatiseer nie. Gevolglik sorg alle belangstellendes ten volle vir die toetsdekking, wat voortdurend groei. Niemand eis die onmoontlike van ander nie.
Oor die algemeen is die impak op die werk van spanne beslis positief. Miskien dink kollegas wat hierdie artikel lees ook daaraan om iets soortgelyks te doen? Dan sal die raad eenvoudig wees: dit is die moeite werd as outomatiese toetse 'n prioriteit vir jou is. Vervolgens sal ons praat oor 'n meer komplekse vraag: hoe om dit alles so korrek as moontlik te organiseer, sodat die koste van alle partye minimaal is en die uitset maksimum is.
Organisering Wenke
Die skool was nuttig, maar, soos Stas erken het, was daar 'n paar probleme, as gevolg waarvan dit nodig was om bykomende lesings te reël. En dit was as 'n onlangse student wat myself-in-onkunde en myself vergelyk-nou dat ek die volgende stappe geformuleer het om, na my mening, die ideale manier te skep om toetsers te leer om outomatiese toetse te verstaan.
Stap 0. Skep 'n woordeboek
Natuurlik is hierdie stap nie net nodig vir QA nie. Ek wil dit egter eksplisiet maak: die outomatiseringskodebasis moet in 'n leesbare vorm gehou word. Programmeringstale - nie die minste nie tale, en hiervandaan kan jy jou duik begin.
Hier is 'n skermskoot van 'n taakaansig met die name van die elemente. Kom ons stel ons voor dat jy taakaansig as 'n swart boks toets en nog nooit Selenium in jou lewe gesien het nie. Wat doen hierdie kode?
(Spoiler - die taak word uitgevee via rus namens die admin, en dan sien ons dat daar 'n rekord hiervan in die stroom is.)
Hierdie stap alleen bring die QAA- en QA-tale nader aan mekaar. Dit is makliker vir outomatiseringspanne om die resultate van 'n lopie te verduidelik; handtoetsers hoef minder moeite te spandeer om gevalle te skep: hulle kan minder gedetailleerd gemaak word. Tog verstaan almal mekaar. Ons het die wengeld ontvang nog voordat die werklike opleiding begin het.
Stap 1. Herhaal frases
Kom ons gaan voort met die parallel met taal. Wanneer ons as kinders leer praat, begin ons nie van etimologie en semantiek nie. Ons herhaal "ma", "koop 'n speelding", maar gaan nie dadelik in op die Proto-Indo-Europese wortels van hierdie woorde nie. So dit is hier: dit is geen sin om in die dieptes van die tegniese kenmerke van outotoetse te duik sonder om iets te probeer skryf wat werk nie.
Dit klink 'n bietjie teen-intuïtief, maar dit werk.
In die eerste les is dit die moeite werd om 'n basis te gee oor hoe om outotoetse direk te skryf. Ons help met die opstel van die ontwikkelingsomgewing (in my geval, Intellij IDEA), verduidelik die minimum taalreëls wat nodig is om 'n ander metode in 'n bestaande klas te skryf deur die bestaande stappe te gebruik. Ons skryf een of twee toetse saam met hulle en gee vir hulle huiswerk, wat ek so sal formateer: 'n tak het van die meester afgetak, maar verskeie toetse is daarvan verwyder. Net hul beskrywings bly oor. Ons vra toetsers om hierdie toetse te herstel (natuurlik nie deur vertoonverskil nie).
As gevolg hiervan sal die een wat geluister en alles gedoen het in staat wees om:
- leer om met die ontwikkelingsomgewingskoppelvlak te werk: die skep van takke, sneltoetse, commits en pushes;
- bemeester die basiese beginsels van die struktuur van die taal en klasse: waar om inspuitings in te voeg en waar om in te voer, waarom aantekeninge nodig is en watter soort simbole daar gevind word, behalwe stappe;
- verstaan die verskil tussen aksie, wag en kyk, waar om wat te gebruik;
- let op die verskil tussen outotoetse en handkontroles: in outotoetse kan jy een of ander hanteerder trek in plaas daarvan om aksies deur die koppelvlak uit te voer. Stuur byvoorbeeld 'n opmerking direk na die agterkant in plaas daarvan om 'n taakaansig oop te maak, die invoer te kies, teks te tik en die Stuur-knoppie te klik;
- formuleer vrae wat in die volgende stap beantwoord sal word.
Die laaste punt is baie belangrik. Hierdie antwoorde kan maklik voor die tyd gegee word, maar dit is 'n belangrike onderrigbeginsel dat antwoorde sonder geformuleerde vrae nie onthou word nie en nie gebruik word wanneer dit uiteindelik nodig is nie.
Dit sal ideaal wees as 'n outomatiseringsingenieur van die QA-span hom 'n taak opgedra het om 'n paar toetse in 'n geveg te skryf en hom toelaat om hom tot sy tak te verbind.
Wat om nie te gee nie:
- meer diepgaande kennis van die funksionaliteit van die ontwikkelingsomgewing en die programmeertaal self, wat slegs nodig sal wees wanneer onafhanklik met takke gewerk word. Dit sal nie onthou word nie, jy sal dit twee of drie keer moet verduidelik, maar ons waardeer die tyd van outomatiseringsingenieurs, reg? Voorbeelde: die oplossing van konflikte, die byvoeging van lêers by git, die skep van klasse van nuuts af, werk met afhanklikhede;
- alles wat met xpath verband hou. Ernstig. Jy moet apart daaroor praat, een keer en baie gekonsentreerd.
Stap 2. Kyk na die grammatika van nader
Kom ons onthou die taakaansig-skermkiekie vanaf stap #0. Ons het 'n stap genaamd checkCommentWithTextExists. Ons toetser verstaan reeds wat hierdie stap doen en ons kan binne die stap kyk en dit 'n bietjie ontbind.
En binne het ons die volgende:
onCommentBlock(userName).comment(expectedText).should(displayed());Waar opCommentBlock is
onCommonStreamPanel().commentBlock(userName);Nou leer ons om nie "koop 'n speelding" te sê nie, maar "koop 'n speelding by die Detsky Mir-winkel, geleë in die blou kas op die derde rak van bo." Dit is nodig om te verduidelik dat ons opeenvolgend na 'n element wys, vanaf groter elemente (stroom -> blok met kommentaar van 'n sekere persoon -> daardie deel van hierdie blok waar die gespesifiseerde teks sit).
Nee, dit is nog nie tyd om oor xpath te praat nie. Noem net kortliks dat al hierdie instruksies deur hulle beskryf word en erfenis gaan daardeur. Maar ons moet oor al hierdie pasmaats en kelners praat; hulle hou spesifiek verband met hierdie stap en is nodig om te verstaan wat aan die gebeur is. Maar moenie oorlaai nie: jou student kan later meer komplekse bewerings op sy eie bestudeer. Heel waarskynlik, moet, wagTot, vertoon();, bestaan();, nie(); behoort voldoende te wees.
Die huiswerk is voor die hand liggend: 'n tak waarin die inhoud van verskeie stappe wat vir 'n sekere aantal toetse nodig is, verwyder is. Laat die toetsers hulle herstel en maak die lopie weer groen.
Verder, as die toetsspan nie net nuwe kenmerke in sy werk het nie, maar ook 'n paar foutoplossings, kan jy hom vra om dadelik toetse vir hierdie foute te skryf en dit vry te stel. Heel waarskynlik is al die elemente reeds beskryf; slegs 'n paar stappe kan ontbreek. Dit sal die perfekte oefensessie wees.
Stap 3. Volle onderdompeling
So volledig as moontlik vir 'n toetser wat gaan voortgaan om sy direkte pligte uit te voer. Ten slotte moet ons oor xpath praat.
Eerstens, laat ons dit duidelik maak dat al hierdie opCommentBlock en kommentaar deur hulle beskryf word.
Totaal:
"//div[contains(@class, ‘stream-panel’)]//a[contains(@class,'author') and text()='{{ userName }}’]//div[contains(@class,'change-wrapper') and contains(.,'{{ text }}’)]"Die volgorde van die storie is baie belangrik. Eerstens neem ons enige bestaande xpath en wys hoe die elemente-oortjie een en slegs een element bevat. Vervolgens praat ons oor die struktuur: wanneer jy WebElement moet gebruik, en wanneer jy 'n aparte lêer vir 'n nuwe element moet skep. Dit sal jou in staat stel om erfenis beter te verstaan.
Dit moet uitdruklik gestel word dat 'n enkele element die hele taakaansig is, dit bevat 'n kinderelement - die hele stroom, wat 'n kinderelement bevat - 'n aparte opmerking, ens. Kinderelemente is binne ouerelemente sowel op die bladsy as in die struktuur van die outotoetsraamwerk.
Op hierdie stadium moes die gehoor deeglik verstaan het hoe hulle geërf word en wat na die kolletjie by onCommentBlock ingevoer kan word. Op hierdie punt verduidelik ons al die operateurs: /, //, ., [] ensovoorts. Ons voeg kennis oor gebruik by die vrag @class en ander nodige dinge.
Studente moet verstaan hoe om xpath op hierdie manier te vertaal. Om te konsolideer - dit is reg, huiswerk. Ons verwyder die beskrywings van die elemente, laat hulle die werk van die toetse herstel.
Hoekom hierdie spesifieke pad?
Ons moet nie 'n persoon met komplekse kennis oorlaai nie, maar ons moet alles op een slag verduidelik, en dit is 'n moeilike dilemma. Hierdie pad sal ons toelaat om luisteraars eers vrae te laat vra en iets nie te verstaan nie en dit die volgende oomblik te beantwoord. As jy oor die hele argitektuur praat, sal die belangrikste dele daarvan reeds vergeet word as gevolg van hul onverstaanbaarheid teen die tyd dat die onderwerp van stappe of xpath ontleed word.
Sommige van u sal egter waarskynlik u ervaring kan deel oor hoe die proses nog meer geoptimaliseer kan word. Ek sal graag soortgelyke voorstelle in die kommentaar lees!
Bron: will.com