បីជំនាន់នៃស្វ័យប្រវត្តិកម្មកម្មវិធីរុករក៖ ការធ្វើត្រាប់តាមការបញ្ចូល ការគ្រប់គ្រងតាមពិធីការ និងការសម្រេចចិត្តរបស់ម៉ូដែល

ស្វ័យប្រវត្តិកម្មកម្មវិធីរុករកមានអាយុកាលជាងម្ភៃឆ្នាំហើយ ហើយក្នុងរយៈពេលនេះ វាបានផ្លាស់ប្តូរទិសដៅសំខាន់ៗចំនួនបីជំនាន់។ ចំណុចគួរឱ្យចាប់អារម្មណ៍គឺ ជំនាន់នីមួយៗដោះស្រាយបញ្ហាប្រភេទផ្សេងគ្នា ហើយពេលបញ្ហាមួយត្រូវបានដោះស្រាយ ចំណុចស្ទះក៏ផ្លាស់ទីទៅកន្លែងថ្មី។

ជំនាន់ទីមួយ៖ ធ្វើត្រាប់តាមថាមានមនុស្សកំពុងផ្លាស់ទី mouse នៅកម្រិតប្រព័ន្ធប្រតិបត្តិការ

ស្វ័យប្រវត្តិកម្មដំបូងបំផុតមិនបានធ្វើការនៅក្នុង browser ទេ ប៉ុន្តែធ្វើការនៅកម្រិតប្រព័ន្ធប្រតិបត្តិការ។ Script ផ្លាស់ទី mouse និងចុច key ខណៈ browser គ្រាន់តែទទួល input ទាំងនោះដោយអកម្ម។

អត្ថប្រយោជន៍គឺភាពទូលំទូលាយ៖ អ្វីក៏ដោយដែលបង្ហាញលើអេក្រង់អាចធ្វើអន្តរកម្មបាន មិនថាជា web page, client application ឬ desktop software ចាស់ ហើយ browser ក៏មិនចាំបាច់បើក interface ពិសេសណាមួយ។ តម្លៃដែលត្រូវបង់ក៏ច្បាស់ដែរ។ Script ពឹងផ្អែកលើ screen coordinates ដូច្នេះគ្រាន់តែប្តូរ resolution, system scaling ឬទីតាំង window សកម្មភាពដដែលអាចចុចខុសកន្លែង។ វាក៏មិនដឹងថា page បាន load រួចពេញលេញឬអត់ ហើយត្រូវពឹងផ្អែកលើការរង់ចាំថេរ។ ការដំណើរការស្របគ្នាកាន់តែពិបាក៖ machine មួយមាន mouse និង keyboard តែមួយឈុត ដូច្នេះ environment ដប់ត្រូវការ machine ដប់។

បញ្ហាដែលជំនាន់នេះទុកចោលគឺសាមញ្ញ៖ វាមើលមិនឃើញ page។

ជំនាន់ទីពីរ៖ រំលងអេក្រង់ ហើយទាក់ទងដោយផ្ទាល់ជាមួយ browser

ការមកដល់របស់ WebDriver បានលើកស្វ័យប្រវត្តិកម្មពីកម្រិត pixel ទៅកម្រិត element៖ វាស្វែងរក element ជាក់លាក់នៅក្នុង page ជំនួសឱ្យទីតាំង pixel ទី 800 លើអេក្រង់។ Code ដូចគ្នាអាចបញ្ជា browser ផ្សេងៗ និងសរសេរជាភាសាកម្មវិធីផ្សេងៗបាន ហើយនេះក៏ជាមូលហេតុមួយដែលវាក្លាយជាស្តង់ដារនៅក្នុងការធ្វើតេស្ត។

ក្រោយមក ដំណោះស្រាយដែលផ្អែកលើ browser debugging protocol បានពង្រីកផ្លូវនេះឱ្យកាន់តែជ្រៅ។ Puppeteer និង Playwright ទាក់ទងដោយផ្ទាល់ជាមួយ browser engine និងអាចទទួលស្ថានភាពខាងក្នុងរបស់ page បាន៖ រង់ចាំ element ឱ្យរួចរាល់ដោយស្វ័យប្រវត្តិ, intercept និង rewrite request, ភ្ជាប់ទៅ browser instance ដែលបើករួច, ដំណើរការ headless និងបើក context ច្រើនស្របគ្នា។ សមត្ថភាពជាច្រើនដែលមើលទៅធម្មតាសព្វថ្ងៃត្រូវបានបំពេញនៅដំណាក់កាលនេះ។

វាដោះស្រាយការគ្រប់គ្រង និងស្ថិរភាព ប៉ុន្តែទុកបញ្ហាពីរផ្សេងទៀត។ ទីមួយ script នៅតែត្រូវបានមនុស្សសរសេរជាមុនយ៉ាងតឹងរឹង។ ពេល page structure ផ្លាស់ប្តូរ ឬ selector លែងដំណើរការ ត្រូវត្រឡប់ទៅកែ code ហើយតម្លៃថែទាំកើនតាមទំហំ project។ ទីពីរជាបញ្ហាមូលដ្ឋានជាងនេះ៖ វាគ្រប់គ្រងថាត្រូវធ្វើដូចម្តេច ប៉ុន្តែមិនគ្រប់គ្រងថាមើលទៅដូចអ្នកណាជាអ្នកធ្វើទេ។ ការភ្ជាប់តាម protocol ដោយផ្ទាល់ធ្វើឱ្យការគ្រប់គ្រងកាន់តែច្បាស់លាស់ ប៉ុន្តែការផ្លាស់ប្តូរវិធីទំនាក់ទំនងមិនធ្វើឱ្យស្នាមស្វ័យប្រវត្តិកម្មបាត់ទៅទេ។ ទោះ script ដំណើរការមានស្ថិរភាពខ្លាំងក៏ដោយ វានៅតែអាចមើលទៅជាស្គ្រីបក្នុងភ្នែកអ្នកដទៃ។

ជំនាន់ទីបី៖ មនុស្សមិនចាំបាច់សរសេររាល់ជំហានទៀត ហើយបញ្ហាក៏ផ្លាស់ទីម្តងទៀត

ការផ្លាស់ប្តូររបស់ជំនាន់ទីបីមិនស្ថិតនៅវិធីគ្រប់គ្រងទេ ប៉ុន្តែស្ថិតនៅវិធីសម្រេចចិត្ត។ ជំនាន់ពីរមុនត្រូវឱ្យមនុស្សកំណត់រាល់ជំហាន៖ ចុច button ណា បំពេញ field ណា និងធ្វើតាមលំដាប់ណា។ នៅជំនាន់ដែលដឹកនាំដោយ model អ្នកផ្តល់គោលដៅ ហើយ model រៀបផែនការផ្លូវដោយខ្លួនឯង និងអាចរក entry point ថ្មីបានពេល page ត្រូវបានរចនាឡើងវិញ។

ដូច្នេះ បញ្ហាលម្អិតពីមុន ដូចជាត្រូវសរសេរ selector យ៉ាងដូចម្តេច ឬត្រូវរង់ចាំប៉ុន្មាន ក្លាយជាមិនសូវធ្ងន់ធ្ងរបន្តិចម្តងៗ។ ប៉ុន្តែបញ្ហាថ្មីក៏លេចឡើងភ្លាមៗ។

ចំណុចសំខាន់គឺ model ខ្លួនឯងមិនចូលទៅកាន់ web page ទេ។ អ្នកដែលបើក page, load resources និងរក្សា login state នៅតែជា browser។ ដូច្នេះពេល task ចាប់ផ្តើមមិនមានស្ថិរភាព មូលហេតុជាញឹកញាប់មិនមែន model សម្រេចចិត្តខុសទេ ប៉ុន្តែជាអង្គធាតុ execution environment ខាងក្រោម៖ task ច្រើនប្រើ browser តែមួយ ហើយ cookies និង cache ប៉ះពាល់គ្នា; fingerprint characteristics ស្រដៀងគ្នាខ្លាំង ធ្វើឱ្យ platform មើលឃើញថា task ទាំងអស់មកពី machine តែមួយ; account ត្រូវបានប្រើឆ្លង task ហើយ anomaly មួយអាចប៉ះពាល់ដល់ច្រើន; environment ត្រូវបង្កើតជាបណ្តោះអាសន្ន និងយកត្រឡប់ក្រោយប្រើ ប៉ុន្តែមិនមាន scheduling រួម។ Model ដោះស្រាយសំណួរថាធ្វើដូចម្តេច ហើយធ្វើឱ្យសំណួរថាធ្វើនៅឯណាក្លាយជាចំណុចស្ទះថ្មី។

ស្រទាប់បន្ថែមនៅក្នុងស្ថាបត្យកម្ម

បើមើលជំនាន់ទាំងបីជាមួយគ្នា ភាពខុសគ្នាមិនមែនថាជំនាន់ណាទំនើបជាងទេ។ ជំនាន់នីមួយៗត្រូវទទួលយកអ្វីដែលជំនាន់មុនមិនបានដោះស្រាយ។ ក្នុងជំនាន់ពីរដំបូង environment មិនមែនជាបញ្ហាធំទេ ព្រោះ automation ដំណើរការលើ browser របស់ machine ផ្ទាល់ខ្លួន។ នៅដំណាក់កាល Agent task មានច្រើន ដំណើរការស្របគ្នា និងគ្មានមនុស្សតាមដាន ដូច្នេះ environment ត្រូវបានគ្រប់គ្រងច្បាស់លាស់៖ task នីមួយៗដំណើរការនៅ environment ដាច់ដោយឡែក; fingerprints និង sessions មិនលាយគ្នា; login state ត្រូវរក្សាទុកឆ្លង task ដើម្បីមិនចាំបាច់ login រាល់ពេល; IP, time zone និង language ត្រូវផ្គូផ្គងជាកញ្ចប់; ហើយ environment ត្រូវបង្កើត និងយកត្រឡប់តាមតម្រូវការ ដូចជា computing resources។

PurpleMark ធ្វើការនៅស្រទាប់នេះ ដោយបម្លែង browser environment ទៅជាធនធានដែលអាច scheduling បាន ដើម្បីឱ្យ Agent ផ្តោតលើ task logic។

វាក៏ធ្វើឱ្យការជ្រើសរើសងាយស្រួលដែរ។ Enterprise testing stacks និង script assets ដែលមានស្រាប់អាចបន្តតាមផ្លូវដើម; Web applications ស្មុគស្មាញដែលត្រូវការ request-level control សមស្របនឹងជំនាន់ protocol-driven; ចំពោះ task ដែល model ជាអ្នករៀបផែនការ ហើយត្រូវដំណើរការមានស្ថិរភាពរយៈពេលវែង បច្ចេកវិទ្យាពីជំនាន់ពីរដំបូងនៅតែអាចប្រើបាន ប៉ុន្តែ environment layer ត្រូវដោះស្រាយដាច់ដោយឡែក។ ប្រសិនបើសេណារីយ៉ូរបស់អ្នកត្រូវការឱ្យប្រតិបត្តិការមើលទៅដូចជាអ្នកប្រើប្រាស់ពិតកំពុងធ្វើ នោះមិនមែនជាអ្វីដែល automation framework អាចផ្តល់ដោយខ្លួនឯងបានទេ មិនថាជំនាន់ណាក៏ដោយ។

ក្រៅពីផ្លូវបច្ចេកទេស ក៏មានព្រំដែនមួយទៀត៖ ប្រតិបត្តិការស្វ័យប្រវត្តិត្រូវគោរពតាមច្បាប់របស់ platform គោលដៅ និងច្បាប់ក្នុងតំបន់។ អ្វីដែលអាចដំណើរការបានផ្នែកបច្ចេកទេស មិនមានន័យថាសមស្របសម្រាប់អាជីវកម្មជានិច្ចទេ។