Automatizarea browserului a trecut prin trei generații. Fiecare a rezolvat blocajul celei precedente și a mutat următorul blocaj în altă parte. Este mai util să înțelegi problemele rămase decât să memorezi nume de instrumente.
Automatizarea browserului există de peste douăzeci de ani și a trecut prin trei direcții majore. Interesant este că fiecare generație rezolvă un alt tip de problemă, iar după rezolvare blocajul se mută din nou în altă parte.
Prima generație: simularea, la nivelul sistemului de operare, a unei persoane care mișcă mouse-ul
Cele mai vechi forme de automatizare nu funcționau de fapt în browser, ci la nivelul sistemului de operare. Scriptul mișca mouse-ul și apăsa taste, iar browserul doar primea pasiv aceste intrări.
Avantajul era generalitatea: putea interacționa cu orice apărea pe ecran — pagini web, aplicații client sau software desktop vechi — fără ca browserul să ofere vreo interfață specială. Costul era la fel de direct. Scriptul lucra cu coordonate pe ecran, astfel încât o schimbare de rezoluție, o ajustare a scalării sistemului sau mutarea ferestrei putea face aceeași acțiune să dea clic în locul greșit. Nici nu știa dacă pagina se încărcase complet și trebuia să se bazeze pe timpi de așteptare fixați. Paralelizarea era și mai dificilă: o mașină are un singur mouse și o singură tastatură, deci zece medii necesitau zece mașini.
Problema lăsată de această generație era simplă: nu putea vedea pagina.
A doua generație: ocolirea ecranului și comunicarea directă cu browserul
Apariția WebDriver a mutat automatizarea de la nivelul pixelilor la nivelul elementelor: era căutat un anumit element din pagină, nu poziția pixelului 800 de pe ecran. Același cod putea controla browsere diferite și putea fi scris în limbaje diferite, motiv pentru care a devenit ulterior un standard în testare.
Mai târziu, soluțiile bazate pe protocoalele de depanare ale browserelor au dus această abordare mult mai departe. Familia Puppeteer și Playwright comunică direct cu motorul browserului și poate accesa starea internă a paginii: așteptare automată până când elementele sunt pregătite, interceptarea și rescrierea cererilor, conectarea la o instanță de browser deja deschisă, rulare fără interfață și deschiderea în paralel a mai multor contexte. Multe dintre funcțiile considerate astăzi normale s-au maturizat în această etapă.
Această generație a rezolvat controlul și stabilitatea, dar a lăsat două alte probleme. Prima este că scripturile erau în continuare fixate de oameni. Când structura paginii se schimba sau un selector nu mai funcționa, codul trebuia modificat, iar costul de întreținere creștea odată cu proiectul. A doua problemă este mai fundamentală: abordarea controlează cum se operează, nu cum pare actorul. Comunicarea directă prin protocol face controlul mai precis, dar urmele automatizării nu dispar doar pentru că se schimbă metoda de comunicare. Chiar și un script foarte stabil poate continua să pară un script.
A treia generație: pașii nu mai sunt scriși de oameni, iar problema se mută din nou
În a treia generație nu se schimbă metoda de control, ci metoda de decizie. Primele două cereau ca oamenii să descrie fiecare pas: ce buton se apasă, ce câmp se completează și în ce ordine. În generația bazată pe modele, oferi un obiectiv, modelul își planifică singur traseul și poate găsi din nou intrarea dacă pagina este reproiectată.
Astfel, problemele mărunte de altădată, precum scrierea selectorilor sau stabilirea timpilor de așteptare, devin treptat mai puțin critice. Dar apar imediat probleme noi.
Esențial este că modelul însuși nu accesează pagina web. Browserul este în continuare cel care deschide pagina, încarcă resursele și menține starea de autentificare. De aceea, când o sarcină devine instabilă, cauza nu este adesea o decizie greșită a modelului, ci mediul de execuție de sub el: mai multe sarcini folosesc același browser și își contaminează reciproc cookie-urile și cache-ul; caracteristicile de fingerprint sunt foarte asemănătoare, iar platforma vede sarcinile ca venind de pe aceeași mașină; conturile sunt reutilizate între sarcini și o anomalie afectează mai multe dintre ele; mediile trebuie create temporar și recuperate după utilizare, dar fără o planificare unificată. Modelul rezolvă cum se face lucrul și transformă unde se face în noul blocaj.
Stratul suplimentar din arhitectură
Privite împreună, cele trei generații nu diferă pur și simplu prin cât de avansate sunt. Fiecare trebuie să preia ceea ce precedenta nu a rezolvat. În primele două generații, mediul nu era o problemă majoră deoarece automatizarea folosea browserul de pe propria mașină. În etapa Agent, sarcinile sunt numeroase, concurente și nesupravegheate, așa că mediul trebuie gestionat explicit: fiecare sarcină rulează într-un mediu izolat, fără amestecarea fingerprinturilor și sesiunilor; starea de autentificare se păstrează între sarcini pentru a evita reconectarea repetată; IP-ul, fusul orar și limba sunt potrivite ca un set; mediile sunt create și recuperate la cerere, asemenea resurselor de calcul.
PurpleMark lucrează exact la acest strat, transformând mediile de browser în resurse programabile, astfel încât Agentul să se poată concentra pe logica sarcinii.
Alegerea devine astfel mai ușor de încadrat. Stivele de testare ale companiilor și scripturile existente pot rămâne pe traseul actual; aplicațiile web complexe care au nevoie de control la nivelul cererilor se potrivesc generației bazate pe protocol; iar pentru sarcini planificate de un model, care trebuie să ruleze stabil pe termen lung, tehnologiile primelor două generații rămân utilizabile, însă stratul de mediu trebuie rezolvat separat. Dacă scenariul trebuie să pară că este operat de un utilizator real, acesta nu este un lucru pe care un framework de automatizare îl poate oferi singur, indiferent de generație.
Dincolo de traseul tehnic există și o altă limită: operațiunile automatizate trebuie să respecte regulile platformei țintă și legislația locală. Faptul că ceva funcționează tehnic nu înseamnă automat că este potrivit pentru afacere.
