Hanapin ang element, hintaying maging interactive, isagawa ang action, at i-verify ang resulta: ito ang apat na hakbang ng bawat automation action. Kapag malinaw ang selectors, dynamic loading, iframe, at shadow DOM, mas tatagal at magiging mas maaasahan ang script.
Madalas isipin na ang web automation ay simpleng pagpapapindot ng button sa isang program para sa iyo. Pero kapag aktuwal mo na itong binuo, makikita mong may apat na hakbang ang bawat action, at kapag may mali sa kahit isa, puwedeng magmukhang walang nangyari.
Linawin muna ang dalawang konseptong madaling mapagkamalan. Mas malawak ang web automation: kabilang dito ang paggamit ng program para gawin ang mga gawain na karaniwang ginagawa ng tao sa web page, pati ang direktang pagkuha ng data sa pamamagitan ng requests. Mas tiyak na bahagi nito ang browser automation: kinokontrol ng program ang totoong browser para magbukas ng page, magpatakbo ng JavaScript, at gayahin ang pag-click at pag-type. Kapag maraming dynamic content o masalimuot ang interaction, karaniwang kailangan ang ikalawang paraan.
Ang apat na hakbang ng isang action
- Hanapin ang element: Tukuyin ang target gamit ang id, name, class, CSS selector, o XPath. Unahin ang semantic attributes at saka lang gumamit ng structure o index kung wala nang mas maayos na opsyon.
- Hintaying maging interactive: Hindi ibig sabihin na nasa DOM na ang element ay puwede na itong i-click. Hintaying maging visible o clickable, o hintayin ang tugon ng isang partikular na request. Kundisyon ang hinihintay, hindi bilang ng segundo.
- Isagawa ang action: Mag-click, mag-type, o mag-scroll. Madalas kailangang gayahin ng custom components ang pagkakasunod-sunod na ginagawa ng tao: buksan muna, hintaying ma-render ang listahan, saka pumili ayon sa text.
- I-verify ang resulta: Pagkatapos ng action, tiyaking tama ang kinalabasan. Tingnan kung nagbago ang link, text ng page, o response ng API. Kapag wala ang hakbang na ito, maaaring ituring na tagumpay ang pagkabigo at mawawalan ng maaasahang basehan ang retries at alerts.
Sa apat na hakbang, kadalasang ang ikalawa at ikaapat ang kumakain ng pinakamaraming oras sa debugging. Hindi dahil pinakamahirap ang mga ito, kundi dahil madalas walang error na lumalabas at tahimik lang na maling resulta ang nabubuo.
Ang tibay ng selector ang nagtatakda kung gaano katagal tatagal ang script
Kapag nagbago ang page, madaling masira ang hard-coded na locator. Pinakamahina sa pagbabago ang paghanap gamit ang text, posisyon, o index: isang dagdag na button o binagong prompt lang ay maaaring makagulo sa lahat.
Kung maaari, unahin ang id, name, o data attributes. Kung kailangang gumamit ng structural locators, ilagay ang mga ito sa iisang lugar para isang bahagi lang ang babaguhin sa halip na dose-dosenang linya. Huwag ding asahang wala nang maintenance pagkatapos maisulat ang script; normal ang pag-update ng mga website, at malaking bahagi ng maintenance cost ay nasa puntong ito.
Dynamic loading: mas mahalaga kung ano ang hinihintay kaysa kung gaano katagal
Bihira na ngayon ang page na kumpleto na agad pagkatapos ng initial load. Nire-render ang data sa pamamagitan ng asynchronous requests, kaya mas huling lumalabas ang mga element kaysa sa inaasahan.
Karaniwan ang fixed waits, pero ito rin ang madaling pumalya: ang paghihintay ng 3 segundo ay maaaring kulang sa mabagal na machine at sayang lang sa mabilis na machine. Ang tamang paraan ay hintayin ang isang kundisyon at kumilos lang kapag talagang clickable na ang element.
Kapag hindi mahanap ang element, suriin muna ang iframe at shadow DOM
Kapag malinaw namang nasa page ang element pero hindi ito makita ng script, kadalasan ay hindi selector ang problema kundi ang scope.
Hiwalay na document ang iframe. Kailangang lumipat muna sa tamang frame bago maghanap ng element at bumalik sa labas pagkatapos, kung hindi ay nasa maling context ang mga susunod na lookup. Ang nodes sa loob ng shadow DOM ay hindi direktang natatamaan ng CSS selectors mula sa labas; kunin muna ang shadow root at saka maghanap sa loob nito. Madalas mapagkamalan ang dalawang sitwasyong ito bilang pagbabago ng page at nauuwi sa sayang na oras ng debugging.
Dalawa pang bagay na madaling makaligtaan
Una ang session. Para sa tasks na nangangailangan ng login, pag-isipan kung paano ise-save at muling gagamitin ang authenticated state. Kung hindi, kailangang mag-login sa bawat run at puwede pang maipit sa verification.
Ikalawa ang environment. Kapag iisang browser environment ang gamit ng lahat ng tasks, puwedeng magkahaluan ang sessions at caches. Ang mga task na maayos kapag magkahiwalay ay maaaring mag-interfere kapag pinagsama. Kapag mula sa isang task ay naging marami, malaking tulong ang hiwalay na layer para sa environment isolation. Ang mga tool gaya ng PurpleMark ay nagbibigay ng independent fingerprint at independent proxy para sa bawat environment, habang ang automation framework ay nakatuon sa pagsasagawa ng actions.
May isang hangganang dapat kumpirmahin bago magsimula
Kayang palitan ng automation ang paulit-ulit na operasyon, pero hindi ang mga hakbang na nangangailangan ng totoong tao. Kapag may real-time facial verification o manual review sa target workflow, hindi ito magiging 100% automated.
Kaya magsimula sa pinakasimpleng pag-verify: gawin nang mano-mano ang buong workflow, itala ang bawat hakbang, at kumpirmahin kung may bahaging hindi malalampasan. Pagkatapos lamang magpasya kung gaano karaming development effort ang ilalaan. Magkaiba rin ang teknikal na posibilidad at kung ano ang pinapayagan ng mga patakaran, kaya basahin nang maaga ang terms of service ng target platform.
