មូលដ្ឋានគ្រឹះនៃ Web Automation៖ លំហូរសកម្មភាព ៤ ជំហាន និងបញ្ហាដែលជួបញឹកញាប់ ៣ ប្រភេទ

Web automation តែងតែត្រូវបានយល់ថាជាការឱ្យកម្មវិធីចុចប៊ូតុងជំនួសអ្នក។ ប៉ុន្តែពេលសរសេរវាពិតប្រាកដ អ្នកនឹងឃើញថាសកម្មភាពមួយមាន ៤ ជំហាន ហើយបើជំហានណាមួយខុស លទ្ធផលអាចមើលទៅដូចជាគ្មានអ្វីកើតឡើង។

ដំបូង ត្រូវបែងចែកគំនិតពីរដែលងាយច្រឡំ។ Web automation មានវិសាលភាពទូលំទូលាយជាង គឺការប្រើកម្មវិធីធ្វើអ្វីដែលមនុស្សត្រូវធ្វើលើ web page ជាធម្មតា រួមទាំងការទាញយក data ដោយផ្ទាល់តាម request។ Browser automation គឺជាផ្នែកជាក់លាក់ជាងនេះ៖ កម្មវិធីគ្រប់គ្រង browser ពិត ដើម្បីបើក page ដំណើរការ JavaScript និងត្រាប់តាមការចុចនិងការវាយបញ្ចូល។ សម្រាប់ករណីដែលមាន dynamic content ច្រើន ឬអន្តរកម្មស្មុគស្មាញ ជាទូទៅត្រូវប្រើវិធីទីពីរ។

សកម្មភាពមួយមាន ៤ ជំហាន

• ស្វែងរក element៖ កំណត់ target ដោយប្រើ id, name, class, CSS selector ឬ XPath។ គួរផ្តល់អាទិភាពដល់ semantic attributes ហើយប្រើ structure ឬ index តែពេលគ្មានជម្រើសល្អជាង។
• រង់ចាំឱ្យអាចអន្តរកម្មបាន៖ Element មាននៅក្នុង DOM មិនមានន័យថាអាចចុចបានភ្លាមៗទេ។ ត្រូវរង់ចាំឱ្យវា visible, clickable ឬរង់ចាំ response ពី request ជាក់លាក់មួយ។ អ្វីដែលត្រូវរង់ចាំគឺ condition មិនមែនចំនួនវិនាទីទេ។
• បើកសកម្មភាព៖ ចុច វាយបញ្ចូល ឬ scroll។ Custom component ជាច្រើនត្រូវការត្រាប់តាមលំដាប់របស់មនុស្ស៖ បើកវាមុន រង់ចាំ list render រួចហើយជ្រើសតាម text។
• ផ្ទៀងផ្ទាត់លទ្ធផល៖ បន្ទាប់ពីសកម្មភាព ត្រូវពិនិត្យថាលទ្ធផលត្រឹមត្រូវឬអត់។ មើលថា link បានផ្លាស់ប្តូរឬទេ អត្ថបទលើ page បានផ្លាស់ប្តូរឬទេ ឬ API បានត្រឡប់អ្វីមក។ បើគ្មានជំហាននេះ failure អាចត្រូវបានចាត់ទុកជា success ហើយ retry និង alert ក៏គ្មានមូលដ្ឋានដែលអាចទុកចិត្តបាន។

ក្នុង ៤ ជំហាននេះ ជំហានទី ២ និងទី ៤ ជាធម្មតាចំណាយពេល debugging ច្រើនជាងគេ។ មិនមែនព្រោះវាពិបាកទេ ប៉ុន្តែព្រោះវាអាចមិនបង្ហាញ error ហើយបង្កើតលទ្ធផលខុសដោយស្ងៀមស្ងាត់។

ស្ថិរភាពរបស់ selector កំណត់ថា script អាចដំណើរការបានយូរប៉ុនណា

ពេល page ផ្លាស់ប្តូរ locator ដែល hard-code អាចខូចភ្លាម។ ការស្វែងរកតាមអត្ថបទ ទីតាំង ឬ index មានភាពធន់ទាបបំផុតចំពោះការផ្លាស់ប្តូរ៖ បន្ថែមប៊ូតុងមួយ ឬប្តូរសារ prompt មួយ ក៏អាចធ្វើឱ្យអ្វីៗខុសបាន។

បើអាច គួរប្រើ id, name ឬ data attributes ជាមុន។ បើត្រូវប្រើ structural locator សូមដាក់វារួមគ្នានៅកន្លែងតែមួយ ដើម្បីពេលកែប្រែ កែតែម្ដងជំនួសឱ្យកែជាច្រើនបន្ទាត់។ ក៏កុំរំពឹងថាសរសេររួចហើយមិនចាំបាច់ថែទាំទៀតដែរ ព្រោះ website update ជារឿងធម្មតា ហើយ maintenance cost មួយផ្នែកធំស្ថិតនៅត្រង់នេះ។

Dynamic loading៖ អ្វីដែលរង់ចាំសំខាន់ជាងរង់ចាំប៉ុន្មានវិនាទី

សព្វថ្ងៃមាន page តិចណាស់ដែលអ្វីៗរួចរាល់ភ្លាមៗបន្ទាប់ពី initial load។ Data ត្រូវបាន render តាម asynchronous request ដូច្នេះ element តែងតែលេចឡើងយឺតជាងការរំពឹង។

Fixed wait គឺជាវិធីដែលប្រើញឹកញាប់ ហើយក៏ងាយបរាជ័យ។ ការគេងរង់ចាំ ៣ វិនាទីអាចមិនគ្រប់គ្រាន់លើ machine យឺត ហើយគ្រាន់តែខ្ជះខ្ជាយពេលលើ machine លឿន។ វិធីត្រឹមត្រូវគឺរង់ចាំឱ្យ condition មួយក្លាយជាពិត ហើយធ្វើសកម្មភាពពេល element អាចចុចបានពិតប្រាកដ។

បើរក element មិនឃើញ សូមពិនិត្យ iframe និង shadow DOM ជាមុន

បើ element មើលឃើញច្បាស់នៅលើ page តែ script រកមិនឃើញ បញ្ហាជាញឹកញាប់មិនមែន selector ទេ ប៉ុន្តែជា scope។

iframe គឺជា document ដាច់ដោយឡែក។ ត្រូវ switch ចូល frame ត្រឹមត្រូវសិនមុនរក element ហើយ switch ចេញវិញបន្ទាប់ពីធ្វើការរួច បើមិនដូច្នោះទេ lookup បន្ទាប់នឹងធ្វើនៅ context ខុស។ Node នៅក្នុង shadow DOM មិនអាចត្រូវបាន CSS selector ពីខាងក្រៅ match ដោយផ្ទាល់ទេ ត្រូវយក shadow root ជាមុន ហើយស្វែងរកនៅខាងក្នុងវា។ ករណីទាំងពីរនេះតែងតែត្រូវយល់ច្រឡំថា page ត្រូវបាន redesign ហើយធ្វើឱ្យខ្ជះខ្ជាយពេល debugging។

មានពីររឿងទៀតដែលងាយភ្លេច

ទីមួយគឺ session។ សម្រាប់ task ដែលត្រូវ login ត្រូវគិតថាតើរក្សាទុក និង reuse authenticated state ដូចម្តេច។ បើមិនដូច្នោះទេ រាល់ run ត្រូវ login ម្តងទៀត ហើយអាចជាប់នៅជំហាន verification។

ទីពីរគឺ environment។ បើ task ទាំងអស់ប្រើ browser environment តែមួយ session និង cache អាចរំខានគ្នា។ Task ដែលដំណើរការល្អពេលបំបែកគ្នា អាចចាប់ផ្តើមរំខានគ្នាពេលរត់រួម។ ពេល task កើនពីមួយទៅច្រើន ការបំបែក environment isolation ជា layer ផ្ទាល់ខ្លួនអាចសន្សំបញ្ហាបានច្រើន។ Tool ដូចជា PurpleMark ផ្តល់ fingerprint និង proxy ដាច់ដោយឡែកសម្រាប់ environment នីមួយៗ ខណៈ automation framework ផ្តោតតែលើការអនុវត្តសកម្មភាព។

មានព្រំដែនមួយដែលគួរបញ្ជាក់មុនចាប់ផ្តើម

Automation អាចជំនួសការងារដដែលៗ ប៉ុន្តែមិនអាចជំនួសជំហានដែលត្រូវការមនុស្សពិតបានទេ។ បើ target workflow មាន real-time facial verification ឬ manual review វាមិនអាច automated ១០០% បានឡើយ។

ដូច្នេះ សូមសាកល្បងតាមវិធីសាមញ្ញបំផុតជាមុន៖ ដំណើរការ workflow ទាំងមូលដោយដៃ កត់ត្រារាល់ជំហាន និងពិនិត្យថាមានជំហានណាដែលមិនអាចឆ្លងកាត់បានឬអត់។ បន្ទាប់មកទើបសម្រេចថាគួរវិនិយោគ development effort ប៉ុន្មាន។ ភាពអាចធ្វើបានផ្នែកបច្ចេកទេស និងអ្វីដែលច្បាប់អនុញ្ញាត គឺជារឿងពីរផ្សេងគ្នា ដូច្នេះគួរអាន terms of service របស់ target platform ជាមុន។