„Playwright“ ar „Selenium“: daugiau darbuotojų testus gali net sulėtinti

Naujam naršyklės testų rinkiniui „Playwright“ dažnai patogesnis dėl automatinio laukimo ir integruoto lygiagretaus vykdymo. Jei jau turite stabilų „Selenium“ rinkinį, perkėlimą verta rinktis tik tada, kai jūsų pačių bandymas parodo naudą, kuri atsveria perrašymo darbą ir išsaugo reikiamų naršyklių aprėptį.

„Darbuotojai“ šiame palyginime yra testus vykdantys procesai, o ne komandos žmonės. Jų pagausinimas gali trumpinti bendrą laiką, kol naršyklėms ir bandomajai programai pakanka išteklių; peržengus šią ribą, tie patys testai gali užtrukti ilgiau. Todėl sistemos pasirinkimo ir lygiagretumo nustatymo negalima grįsti vienu svetimu greičio skaičiumi.

Automatinis laukimas keičia kodą, bet negarantuoja greičio

Prieš paspaudimą „Playwright“ tikrina, ar elementas matomas, stabilus, gali priimti paspaudimą ir yra aktyvus; oficialios veiksmų tinkamumo taisyklės taip pat numato klaidą, jei sąlygos neįvykdomos per nustatytą laiką. Automatiškai kartojami teiginiai leidžia laukti ir rezultato, pavyzdžiui, kol po veiksmo pasirodys atnaujinta puslapio būsena. Tai mažina poreikį kiekvienam sąsajos pokyčiui rašyti atskirą laukimo ciklą.

„Selenium“ turi savus sinchronizavimo būdus: jos laukimo dokumentacija aprašo bendrą numanomą laukimą ieškant elemento ir aiškų laukimą konkrečiai sąlygai. Numanomas laukimas baigiasi elementą radus, todėl didesnė jo riba savaime neprideda tiek laiko prie kiekvienos paieškos. Dokumentacija įspėja, kad numanomo ir aiškaus laukimo maišymas gali duoti sunkiai prognozuojamą laukimo trukmę.

Skirtumą verta vertinti pagal scenarijaus vietą, kurioje prarandamas laikas. Jei testas laukia dinamiškai atsirandančio mygtuko ar pranešimo, sąlyga grįstas laukimas gali pakeisti per ilgą fiksuotą pauzę. Jei didžiąją trukmės dalį sudaro serverio atsakas į prisijungimą ar užsakymo pateikimą, kitos testavimo sistemos laukimo taisyklės to atsako nesutrumpins. Automatinis laukimas padeda sinchronizuoti veiksmą su sąsaja, bet nepašalina būtinybės patikrinti, ar po jo atsirado laukiama būsena.

Kodėl papildomi procesai pailgino mažąjį bandymą

Paulo Yardley „Sanzu“ Oracle APEX bandyme septynių testų rinkinys su nuosekliai vykdytu „Selenium“ truko 57,83 s, su „Playwright“ vienu darbuotoju – 49,84 s, dviem – 25,29 s, trimis – 32,84 s, o keturiais – 55,78 s. Keturių darbuotojų konfigūracija beveik panaikino dviejų darbuotojų sutaupytą laiką ir net atsiliko nuo vieno darbuotojo konfigūracijos.

Šiame palyginime „Selenium“ scenarijai buvo parašyti Ruby ir vykdyti nuosekliai, o „Playwright“ scenarijai – TypeScript; pastarųjų paleidimas turėjo atskirą prisijungimo būsenos parengimą. Dėl to nuoseklių rinkinių skirtumas nėra grynas automatizavimo įrankio efektyvumo matas. Darbuotojų skaičiaus kaita to paties „Playwright“ rinkinio viduje tiesiogiau parodo lygiagretumo poveikį, nors ir čia svarbi konkreti kompiuterio bei programos apkrova.

Padidinus lygiagretumą, kai kurie pavieniai scenarijai vykdyti ilgiau, tad bendrą laiką prailgino ne vien papildomų procesų paleidimo kaina. Tikėtina, kad vienu metu veikiančios naršyklės varžėsi dėl vietinio kompiuterio išteklių, o jų užklausos galėjo apkrauti ir APEX programą. Kiekvieno veiksnio indėlis atskirai neišmatuotas. Tokiam rinkiniui svarbu stebėti ir bendrą trukmę, ir lėčiausius scenarijus: vien didesnis procesų skaičius nėra našumo rodiklis.

Ką duoda didesnio rinkinio perkėlimas

„ScrollTest“ autoriaus elektroninės prekybos rinkinio perkėlime 200 testų trukmė sumažėjo nuo 47 iki 19 minučių; abi sistemos buvo vykdomos lygiagrečiai prieš tą pačią bandomąją aplinką. Tai įdomus viso perkėlimo rezultatas, tačiau aprašytas vienas rinkinys, o ne standartizuotas skirtingų programų tyrimas.

Perkeliant rinkinį buvo pakeistas ne vien įrankis: naudota pakartotinai pritaikoma prisijungimo būsena, atsisakyta dalies fiksuotų pauzių ir kitaip suorganizuotas lygiagretus vykdymas. Todėl sutrumpėjusio laiko negalima priskirti vien automatiniam laukimui. Komandai, kurios scenarijuose daug pasikartojančių prisijungimų, ši migracijos dalis gali būti reikšminga; kitokioje programoje didžiausią trukmės dalį gali sudaryti pats serveris.

Mažojo bandymo darbuotojų kaitaliojimas ir didesnio rinkinio perkėlimas matuoja skirtingus dalykus. Pirmasis parodo, kad ta pati testų sistema toje pačioje aplinkoje gali sulėtėti didinant vienalaikių procesų skaičių. Antrasis apima ir testų kodo, ir vykdymo organizavimo pakeitimus. Jų rezultatai naudingi kaip klausimai savo rinkiniui, bet nėra patikimas išankstinis jo trukmės skaičiuotuvas.

Naršyklių aprėptis gali nulemti pasirinkimą

„Playwright“ naršyklių dokumentacija nurodo „Chromium“, „Firefox“ ir „WebKit“, taip pat galimybę naudoti įdiegtus „Google Chrome“ bei „Microsoft Edge“ kanalus; jos „Firefox“ remiasi pritaikyta versija, o „WebKit“ nėra pati „Safari“ naršyklė. Todėl reikalavimas testuoti konkrečią oficialią naršyklės laidą skiriasi nuo reikalavimo padengti jos variklio elgseną.

Ypač svarbu tai atskirti, jei testų rezultatai naudojami sutartiniam suderinamumui patvirtinti arba programai reikalingi tam tikri medijos kodekai. Bandymas su „Chromium“ ne visada pakeičia bandymą su „Chrome“, kaip ir bandymas su „WebKit“ savaime nepakeičia bandymo su „Safari“. Esamą „Selenium“ rinkinį verta išlaikyti ten, kur jis patikimai vykdomas būtinoje naršyklėje, kol alternatyva praktiškai padengia tą patį reikalavimą.

Migracijos kainą parodo lygiavertis bandomasis rinkinys

Prieš perrašant visą rinkinį, prasminga pasirinkti reprezentatyvius scenarijus: prisijungimą, dinamiškai atsinaujinantį turinį, kelių puslapių navigaciją ir veiksmus, po kurių dažniausiai tenka kartoti nepavykusį testą. Perkeltame variante turi likti tos pačios tikrinamos sąlygos. Jei viename variante išmetama dalis teiginių ar sutrumpinamas kelias per programą, greitesnis rezultatas nebebus lygiavertis palyginimas.

• Užfiksuokite dabartinio rinkinio bendrą trukmę, pavienių scenarijų laiką ir pakartotinių paleidimų dažnį.
• Įvertinkite, kiek darbo pareikalauja lokatorių, laukimo sąlygų, prisijungimo ir testų duomenų perkėlimas.
• Toje pačioje CI aplinkoje keiskite lygiagretumą ir stebėkite, kada bendras laikas nustoja trumpėti arba ima ilgėti pavieniai scenarijai.
• Patikrinkite privalomas naršykles ir palyginkite sutaupytą vykdymo bei priežiūros laiką su perrašymo kaina.

Lygiagretūs naršyklės kontekstai savaime neišskiria bendrų programos duomenų. Jei scenarijai tuo pačiu metu keičia tą pačią paskyrą ar užsakymą, klaidos gali kilti dėl duomenų konflikto, o ne dėl paties įrankio laukimo mechanizmo. Tik atskyrus tokius konfliktus galima spręsti, ar reikia keisti testų duomenis, CI pajėgumą, darbuotojų skaičių ar pačią testavimo sistemą.

Taip pat skaitykite:

• DI raštingumas pagal ES aktą: vien skaidrių darbuotojams gali nepakakti
• „Upwork“ ar „Fiverr“: 20 % mokestis gali panaikinti greito užsakymo naudą
• DI keičia Lietuvos IT rinką: per 8 mėnesius darbuotojų sumažėjo 681