ផ្ទុកការធ្វើតេស្តជាសេវាកម្ម CI សម្រាប់អ្នកអភិវឌ្ឍន៍

បញ្ហាមួយក្នុងចំណោមបញ្ហាដែលអ្នកលក់កម្មវិធីពហុផលិតផលតែងតែជួបប្រទះគឺការចម្លងពីសមត្ថភាពរបស់វិស្វករ - អ្នកអភិវឌ្ឍន៍ អ្នកសាកល្បង និងអ្នកគ្រប់គ្រងហេដ្ឋារចនាសម្ព័ន្ធ - ស្ទើរតែគ្រប់ក្រុម។ នេះក៏អនុវត្តចំពោះវិស្វករដែលមានតំលៃថ្លៃផងដែរ - អ្នកឯកទេសក្នុងវិស័យធ្វើតេស្តបន្ទុក។

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

អ្នកអាចស្វែងរកដំណោះស្រាយចំពោះបញ្ហាស្ថាប័នមួយចំនួនក្នុងការធ្វើតេស្តដែលយើងប្រើនៅបច្ចេកវិទ្យាវិជ្ជមាននៅក្នុង អត្ថបទមួយទៀត. ហើយនៅក្នុងមួយនេះ ខ្ញុំនឹងនិយាយអំពីលទ្ធភាពនៃការរួមបញ្ចូលការធ្វើតេស្តផ្ទុកទៅក្នុងបំពង់ CI ទូទៅ ដោយប្រើគំនិតនៃ "ការធ្វើតេស្តផ្ទុកជាសេវាកម្ម" (ការធ្វើតេស្តផ្ទុកជាសេវាកម្ម) ។ អ្នកនឹងរៀនពីរបៀប និងរូបភាព docker នៃប្រភពផ្ទុកអាចត្រូវបានប្រើនៅក្នុង CI pipeline; របៀបភ្ជាប់ប្រភពផ្ទុកទៅគម្រោង CI របស់អ្នកដោយប្រើគំរូសាងសង់។ អ្វី​ដែល​បំពង់​សាកល្បង​មើល​ទៅ​ដូច​ជា​សម្រាប់​ការ​រត់​ការ​សាកល្បង​ផ្ទុក​និង​ការ​បោះពុម្ព​ផ្សាយ​លទ្ធផល​។ អត្ថបទអាចមានប្រយោជន៍សម្រាប់វិស្វករសាកល្បងកម្មវិធី និងវិស្វករស្វ័យប្រវត្តិកម្មនៅក្នុង CI ដែលកំពុងគិតអំពីស្ថាបត្យកម្មនៃប្រព័ន្ធផ្ទុករបស់ពួកគេ។

ខ្លឹមសារនៃគំនិត

គំនិតនៃការធ្វើតេស្តផ្ទុកជាសេវាកម្មបង្កប់ន័យសមត្ថភាពក្នុងការរួមបញ្ចូលឧបករណ៍ផ្ទុក Apache JMeter, Yandex.Tank និងក្របខ័ណ្ឌផ្ទាល់ខ្លួនរបស់អ្នកទៅក្នុងប្រព័ន្ធរួមបញ្ចូលជាបន្តបន្ទាប់តាមអំពើចិត្ត។ ការបង្ហាញនឹងមានសម្រាប់ GitLab CI ប៉ុន្តែគោលការណ៍គឺជារឿងធម្មតាសម្រាប់ប្រព័ន្ធ CI ទាំងអស់។

ការធ្វើតេស្តផ្ទុកជាសេវាគឺជាសេវាកណ្តាលសម្រាប់ការធ្វើតេស្តផ្ទុក។ ការធ្វើតេស្តផ្ទុកត្រូវបានដំណើរការនៅក្នុងក្រុមភ្នាក់ងារជាក់លាក់ លទ្ធផលត្រូវបានបោះពុម្ពដោយស្វ័យប្រវត្តិនៅក្នុង GitLab Pages, Influx DB និង Grafana ឬនៅក្នុងប្រព័ន្ធរាយការណ៍សាកល្បង (TestRail, ReportPortal ។ល។)។ ស្វ័យប្រវត្តិកម្ម និងការធ្វើមាត្រដ្ឋានត្រូវបានអនុវត្តតាមតែអាចធ្វើទៅបាន ដោយបន្ថែម និងកំណត់គំរូ gitlab-ci.yml ធម្មតានៅក្នុងគម្រោង GitLab CI ។

អត្ថប្រយោជន៍នៃវិធីសាស្រ្តនេះគឺថាហេដ្ឋារចនាសម្ព័ន្ធ CI ទាំងមូល ភ្នាក់ងារផ្ទុក រូបភាព docker នៃប្រភពផ្ទុក បំពង់បង្ហូរសាកល្បង និងការបោះពុម្ពរបាយការណ៍ត្រូវបានរក្សាទុកដោយនាយកដ្ឋានស្វ័យប្រវត្តិកម្មកណ្តាល (វិស្វករ DevOps) ខណៈពេលដែលវិស្វករធ្វើតេស្តផ្ទុកអាចផ្តោតលើការខិតខំប្រឹងប្រែងរបស់ពួកគេលើការអភិវឌ្ឍន៍ការធ្វើតេស្ត។ និងការវិភាគលើលទ្ធផលរបស់ពួកគេ ដោយមិនដោះស្រាយបញ្ហាហេដ្ឋារចនាសម្ព័ន្ធ។

សម្រាប់ភាពសាមញ្ញនៃការពិពណ៌នា យើងនឹងសន្មត់ថាកម្មវិធីគោលដៅ ឬម៉ាស៊ីនមេដែលកំពុងធ្វើតេស្តត្រូវបានដាក់ពង្រាយ និងកំណត់រចនាសម្ព័ន្ធជាមុនរួចហើយ (ស្គ្រីបស្វ័យប្រវត្តិនៅក្នុង Python, SaltStack, Ansible ។ល។ អាចត្រូវបានប្រើសម្រាប់ការនេះ)។ បន្ទាប់មក គោលគំនិតទាំងមូលនៃការធ្វើតេស្តផ្ទុកជាសេវាមួយ សមនឹងបីដំណាក់កាល៖ ការរៀបចំ ការធ្វើតេស្ត ការបោះពុម្ពរបាយការណ៍. ព័ត៌មានលម្អិតបន្ថែមលើដ្យាក្រាម (រូបភាពទាំងអស់អាចចុចបាន)៖

គោលគំនិត និងនិយមន័យជាមូលដ្ឋានក្នុងការធ្វើតេស្តផ្ទុក

នៅពេលអនុវត្តការធ្វើតេស្តបន្ទុកយើងព្យាយាមប្រកាន់ខ្ជាប់ ស្តង់ដារ ISTQB និងវិធីសាស្រ្តប្រើវាក្យស័ព្ទសមស្រប និងរង្វាស់ដែលបានណែនាំ។ ខ្ញុំនឹងផ្តល់បញ្ជីខ្លីនៃគោលគំនិត និងនិយមន័យសំខាន់ៗក្នុងការធ្វើតេស្តផ្ទុក។

ផ្ទុកភ្នាក់ងារ - ម៉ាស៊ីននិម្មិតដែលកម្មវិធីនឹងត្រូវបានដាក់ឱ្យដំណើរការ - ប្រភពផ្ទុក (Apache JMeter, Yandex.Tank ឬម៉ូឌុលផ្ទុកដែលសរសេរដោយខ្លួនឯង) ។

គោលដៅសាកល្បង (គោលដៅ) - ម៉ាស៊ីនមេឬកម្មវិធីដែលបានដំឡើងនៅលើម៉ាស៊ីនមេដែលនឹងត្រូវផ្ទុក។

សេណារីយ៉ូសាកល្បង (ករណីសាកល្បង) - សំណុំនៃជំហានប៉ារ៉ាម៉ែត្រ៖ សកម្មភាពរបស់អ្នកប្រើ និងប្រតិកម្មដែលរំពឹងទុកចំពោះសកម្មភាពទាំងនេះ ជាមួយនឹងសំណើបណ្តាញថេរ និងការឆ្លើយតប អាស្រ័យលើប៉ារ៉ាម៉ែត្រដែលបានបញ្ជាក់។

កម្រងព័ត៌មាន ឬផែនការផ្ទុក (ទម្រង់) - ក្នុង វិធីសាស្រ្ត ISTQB (ផ្នែកទី 4.2.4 ទំព័រ 43) ទម្រង់ផ្ទុកកំណត់ម៉ែត្រដែលមានសារៈសំខាន់សម្រាប់ការធ្វើតេស្តជាក់លាក់មួយ និងជម្រើសសម្រាប់ការផ្លាស់ប្តូរប៉ារ៉ាម៉ែត្រផ្ទុកអំឡុងពេលធ្វើតេស្ត។ អ្នកអាចឃើញឧទាហរណ៍នៃទម្រង់នៅក្នុងរូប។

សាកល្បង - ស្គ្រីបដែលមានសំណុំប៉ារ៉ាម៉ែត្រដែលបានកំណត់ទុកជាមុន។

ផែនការសាកល្បង (ផែនការសាកល្បង) - សំណុំនៃការធ្វើតេស្តនិងទម្រង់ផ្ទុក។

តេសរ៉ាន់ (testrun) - ការធ្វើម្តងទៀតនៃការដំណើរការការធ្វើតេស្តមួយជាមួយនឹងសេណារីយ៉ូការផ្ទុកដែលបានប្រតិបត្តិពេញលេញ និងរបាយការណ៍ដែលទទួលបាន។

សំណើបណ្តាញ (សំណើ) - សំណើ HTTP ផ្ញើពីភ្នាក់ងារទៅគោលដៅ។

ការឆ្លើយតបបណ្តាញ (ការឆ្លើយតប) - ការឆ្លើយតប HTTP ផ្ញើពីគោលដៅទៅភ្នាក់ងារ។
កូដឆ្លើយតប HTTP (ស្ថានភាពការឆ្លើយតប HTTP) - កូដឆ្លើយតបស្តង់ដារពីម៉ាស៊ីនមេកម្មវិធី។
ប្រតិបត្តិការគឺជាវដ្តនៃការឆ្លើយតបសំណើពេញលេញ។ ប្រតិបត្តិការត្រូវបានរាប់ចាប់ពីការចាប់ផ្តើមនៃការផ្ញើសំណើ (សំណើ) រហូតដល់ការបញ្ចប់នៃការទទួលការឆ្លើយតប (ការឆ្លើយតប)។

ស្ថានភាពប្រតិបត្តិការ - ថាតើវាអាចទៅរួចក្នុងការបញ្ចប់វដ្តនៃការឆ្លើយតបសំណើដោយជោគជ័យដែរឬទេ។ ប្រសិនបើមានកំហុសណាមួយនៅក្នុងវដ្តនេះ នោះប្រតិបត្តិការទាំងមូលត្រូវបានចាត់ទុកថាមិនជោគជ័យ។

ពេលវេលាឆ្លើយតប (ភាពយឺតយ៉ាវ) - ពេលវេលាចាប់ពីចុងបញ្ចប់នៃការផ្ញើសំណើ (សំណើ) ដល់ការចាប់ផ្តើមនៃការទទួលការឆ្លើយតប (ការឆ្លើយតប) ។

ផ្ទុកម៉ែត្រ - លក្ខណៈនៃសេវាកម្មដែលបានផ្ទុក និងភ្នាក់ងារផ្ទុកដែលបានកំណត់នៅក្នុងដំណើរការនៃការធ្វើតេស្តផ្ទុក។

ម៉ែត្រជាមូលដ្ឋានសម្រាប់វាស់ប៉ារ៉ាម៉ែត្រផ្ទុក

មួយចំនួនដែលត្រូវបានប្រើប្រាស់ និងណែនាំជាទូទៅបំផុតនៅក្នុងវិធីសាស្រ្ត ISTQB (ទំ. ៣៦, ៥២) រង្វាស់ត្រូវបានបង្ហាញក្នុងតារាងខាងក្រោម។ រង្វាស់ស្រដៀងគ្នាសម្រាប់ភ្នាក់ងារ និងគោលដៅត្រូវបានរាយបញ្ជីនៅលើបន្ទាត់ដូចគ្នា។

ម៉ែត្រសម្រាប់ភ្នាក់ងារផ្ទុក
ម៉ែត្រនៃប្រព័ន្ធគោលដៅ ឬកម្មវិធីដែលកំពុងត្រូវបានសាកល្បងនៅក្រោមការផ្ទុក

ចំនួន  vCPU និងការចងចាំ អង្គ​ចងចាំ,
ថាស - លក្ខណៈ "ជាតិដែក" នៃភ្នាក់ងារផ្ទុក
ស៊ីភីយូ, អង្គចងចាំ ការប្រើប្រាស់ថាស - ថាមវន្តនៃស៊ីភីយូ អង្គចងចាំ និងការផ្ទុកថាស
នៅក្នុងដំណើរការនៃការធ្វើតេស្ត។ ជាធម្មតាវាស់វែងជាភាគរយ
តម្លៃអតិបរមាដែលមាន

បណ្តាញឆ្លងកាត់ (នៅលើភ្នាក់ងារផ្ទុក) - ឆ្លងកាត់
ចំណុចប្រទាក់បណ្តាញនៅលើម៉ាស៊ីនមេ,
កន្លែងដែលភ្នាក់ងារផ្ទុកត្រូវបានតំឡើង។
ជាធម្មតាវាស់ជាបៃក្នុងមួយវិនាទី (bps)
បណ្តាញឆ្លងកាត់(នៅលើគោលដៅ) - កម្រិតបញ្ជូនចំណុចប្រទាក់បណ្តាញ
នៅលើម៉ាស៊ីនមេគោលដៅ។ ជាធម្មតាវាស់ជាបៃក្នុងមួយវិនាទី (bps)

អ្នកប្រើប្រាស់និម្មិត- ចំនួនអ្នកប្រើប្រាស់និម្មិត,
ការអនុវត្តសេណារីយ៉ូការផ្ទុកនិង
ធ្វើត្រាប់តាមសកម្មភាពអ្នកប្រើប្រាស់ពិតប្រាកដ
ស្ថានភាពអ្នកប្រើប្រាស់និម្មិតឆ្លងកាត់/បរាជ័យ/សរុប — ចំនួនជោគជ័យ និង
ស្ថានភាពមិនជោគជ័យរបស់អ្នកប្រើនិម្មិត
សម្រាប់សេណារីយ៉ូនៃការផ្ទុក ក៏ដូចជាចំនួនសរុបរបស់វា។

ជាទូទៅគេរំពឹងថាអ្នកប្រើប្រាស់ទាំងអស់អាចបំពេញបាន។
រាល់កិច្ចការរបស់អ្នកដែលបានបញ្ជាក់នៅក្នុងទម្រង់ផ្ទុក។
កំហុសណាមួយនឹងមានន័យថាអ្នកប្រើប្រាស់ពិតប្រាកដនឹងមិនអាច
ដោះស្រាយបញ្ហារបស់អ្នកនៅពេលធ្វើការជាមួយប្រព័ន្ធ

សំណើក្នុងមួយវិនាទី (នាទី)- ចំនួនសំណើបណ្តាញក្នុងមួយវិនាទី (ឬនាទី) ។

លក្ខណៈសំខាន់នៃភ្នាក់ងារផ្ទុកគឺចំនួនសំណើដែលវាអាចបង្កើតបាន។
តាមពិតនេះគឺជាការក្លែងបន្លំនៃការចូលប្រើកម្មវិធីដោយអ្នកប្រើប្រាស់និម្មិត
ការឆ្លើយតបក្នុងមួយវិនាទី (នាទី)
- ចំនួននៃការឆ្លើយតបបណ្តាញក្នុងមួយវិនាទី (ឬនាទី) ។

លក្ខណៈសំខាន់នៃសេវាកម្មគោលដៅ៖ ប៉ុន្មាន
បង្កើត និងផ្ញើការឆ្លើយតបទៅនឹងសំណួរជាមួយ
ភ្នាក់ងារផ្ទុក

ស្ថានភាពឆ្លើយតប HTTP- ចំនួន​នៃ​កូដ​ឆ្លើយ​តប​ផ្សេង​គ្នា​
ពីម៉ាស៊ីនមេកម្មវិធីដែលបានទទួលដោយភ្នាក់ងារផ្ទុក។
ឧទាហរណ៍ 200 OK មានន័យថាការហៅជោគជ័យ។
និង 404 - ថាធនធានមិនត្រូវបានរកឃើញ

ភាពយឺតយ៉ាវ (ពេលវេលាឆ្លើយតប) - ពេលវេលាពីទីបញ្ចប់
ផ្ញើសំណើ (សំណើ) មុនពេលចាប់ផ្តើមទទួលការឆ្លើយតប (ការឆ្លើយតប) ។
ជាធម្មតាវាស់ជាមីលីវិនាទី (ms)

ពេលវេលាឆ្លើយតបប្រតិបត្តិការ- ពេលវេលានៃប្រតិបត្តិការពេញលេញមួយ
ការបញ្ចប់វដ្តនៃការឆ្លើយតបសំណើ។
នេះគឺជាពេលវេលាចាប់តាំងពីការចាប់ផ្តើមនៃការផ្ញើសំណើ (សំណើ)
រហូតដល់ការបញ្ចប់នៃការទទួលបានការឆ្លើយតប (ការឆ្លើយតប) ។

ពេលវេលាប្រតិបត្តិការអាចត្រូវបានវាស់ជាវិនាទី (ឬនាទី)
នៅក្នុងវិធីជាច្រើន: ពិចារណាអប្បបរមា,
អតិបរមា មធ្យម និងឧទាហរណ៍ 90 ភាគរយ។
ការអានអប្បបរមា និងអតិបរមាគឺខ្លាំងបំផុត។
ស្ថានភាពដំណើរការប្រព័ន្ធ។
ភាគរយទីកៅសិបគឺត្រូវបានគេប្រើញឹកញាប់បំផុត,
ដូចដែលវាបង្ហាញអ្នកប្រើប្រាស់ភាគច្រើន
ដំណើរការប្រកបដោយផាសុកភាពនៅកម្រិតនៃដំណើរការប្រព័ន្ធ

ប្រតិបត្តិការក្នុងមួយវិនាទី (នាទី) - ចំនួនពេញលេញ
ប្រតិបត្តិការក្នុងមួយវិនាទី (នាទី),
នោះគឺថាតើពាក្យសុំអាចទទួលយកបានប៉ុន្មាន និង
ដំណើរការសំណើ និងចេញការឆ្លើយតប។
តាមពិតនេះគឺជាដំណើរការនៃប្រព័ន្ធ

ស្ថានភាពប្រតិបត្តិការ , ឆ្លងកាត់ / បរាជ័យ / សរុប - លេខ
ជោគជ័យ មិនជោគជ័យ និងចំនួនប្រតិបត្តិការសរុប។

សម្រាប់អ្នកប្រើប្រាស់ពិតមិនជោគជ័យ
ប្រតិបត្តិការពិតជាមានន័យ
អសមត្ថភាពក្នុងការធ្វើការជាមួយប្រព័ន្ធដែលកំពុងផ្ទុក

ផ្ទុកដ្យាក្រាមគ្រោងការណ៍នៃការធ្វើតេស្ត

គោលគំនិតនៃការធ្វើតេស្តផ្ទុកគឺសាមញ្ញណាស់ ហើយមានបីដំណាក់កាលសំខាន់ៗ ដែលខ្ញុំបានលើកឡើងរួចហើយ៖ រៀបចំ-សាកល្បង-របាយការណ៍នោះគឺការរៀបចំគោលដៅសាកល្បង និងកំណត់ប៉ារ៉ាម៉ែត្រសម្រាប់ប្រភពផ្ទុក បន្ទាប់មកអនុវត្តការធ្វើតេស្តផ្ទុក ហើយនៅចុងបញ្ចប់ បង្កើត និងបោះពុម្ពរបាយការណ៍សាកល្បង។

កំណត់ចំណាំតាមគ្រោងការណ៍៖

• QA.Tester គឺជាអ្នកជំនាញក្នុងការធ្វើតេស្តបន្ទុក
• គោលដៅគឺជាកម្មវិធីគោលដៅដែលអ្នកចង់ដឹងពីអាកប្បកិរិយារបស់វានៅក្រោមការផ្ទុក។

ការចាត់ថ្នាក់នៃអង្គភាព ដំណាក់កាល និងជំហានក្នុងដ្យាក្រាម

ដំណាក់កាលនិងជំហាន
តើ​មាន​រឿង​អ្វី​កើតឡើង
អ្វីដែលនៅច្រកចូល
តើអ្វីជាទិន្នផល

ការរៀបចំ៖ ដំណាក់កាលត្រៀមសម្រាប់ការធ្វើតេស្ត

ប៉ារ៉ាម៉ែត្រផ្ទុក
ការកំណត់និងការចាប់ផ្តើម
អ្នក​ប្រើ
ប៉ារ៉ាម៉ែត្រផ្ទុក,
ជម្រើសនៃម៉ែត្រនិង
ការរៀបចំផែនការសាកល្បង
(ផ្ទុកទម្រង់)
ជម្រើសផ្ទាល់ខ្លួនសម្រាប់
ការចាប់ផ្តើមផ្ទុកភ្នាក់ងារ
ផែនការសាកល្បង
គោលបំណងនៃការធ្វើតេស្ត

VM
ការដាក់ពង្រាយលើពពក
ម៉ាស៊ីននិម្មិតជាមួយ
លក្ខណៈដែលត្រូវការ
ការកំណត់ VM សម្រាប់ភ្នាក់ងារផ្ទុក
ស្គ្រីបស្វ័យប្រវត្តិកម្មសម្រាប់
ការបង្កើត VM
VM បានកំណត់រចនាសម្ព័ន្ធនៅក្នុង
ពពក

អេន
ការរៀបចំ និងរៀបចំប្រព័ន្ធប្រតិបត្តិការ
បរិស្ថានសម្រាប់
ផ្ទុកការងារភ្នាក់ងារ
ការកំណត់បរិស្ថានសម្រាប់
ភ្នាក់ងារផ្ទុក
ស្គ្រីបស្វ័យប្រវត្តិកម្មសម្រាប់
ការកំណត់បរិស្ថាន
បរិស្ថានបានរៀបចំ៖
ប្រព័ន្ធប្រតិបត្តិការ សេវាកម្ម និងកម្មវិធី
ចាំបាច់សម្រាប់ការងារ
ភ្នាក់ងារផ្ទុក

ភ្នាក់ងារផ្ទុក
ការដំឡើង ការកំណត់រចនាសម្ព័ន្ធ និងការកំណត់
ភ្នាក់ងារផ្ទុក។
ឬទាញយករូបភាព docker ពី
ប្រភពផ្ទុកដែលបានកំណត់ទុកជាមុន
ផ្ទុករូបភាព docker ប្រភព
(YAT, JM ឬក្របខណ្ឌសរសេរដោយខ្លួនឯង)
ការកំណត់
ភ្នាក់ងារផ្ទុក
រៀបចំ និងរៀបចំ
ដើម្បីធ្វើការភ្នាក់ងារផ្ទុក

តេស្តៈ ដំណាក់កាលនៃការអនុវត្តតេស្តផ្ទុក។ ប្រភពគឺជាភ្នាក់ងារផ្ទុកដែលបានដាក់ពង្រាយនៅក្នុងក្រុមភ្នាក់ងារជាក់លាក់សម្រាប់ GitLab CI

ផ្ទុក
ការចាប់ផ្តើមភ្នាក់ងារផ្ទុក
ជាមួយនឹងផែនការសាកល្បងដែលបានជ្រើសរើស
និងប៉ារ៉ាម៉ែត្រផ្ទុក
ជម្រើសអ្នកប្រើប្រាស់
សម្រាប់ការចាប់ផ្តើម
ភ្នាក់ងារផ្ទុក
ផែនការសាកល្បង
គោលបំណងនៃការធ្វើតេស្ត
កំណត់ហេតុប្រតិបត្តិ
ការធ្វើតេស្តផ្ទុក
កំណត់ហេតុប្រព័ន្ធ
ថាមវន្តនៃការផ្លាស់ប្តូរក្នុងរង្វាស់គោលដៅ និងភ្នាក់ងារផ្ទុក

ដំណើរការភ្នាក់ងារ
ការប្រតិបត្តិភ្នាក់ងារ
ផ្ទុកស្គ្រីបសាកល្បង
នៅ​ក្នុង​ការ​អនុលោម​តាម
ផ្ទុកទម្រង់
ផ្ទុកអន្តរកម្មភ្នាក់ងារ
សម្រាប់គោលបំណងសាកល្បង
ផែនការសាកល្បង
គោលបំណងនៃការធ្វើតេស្ត

កំណត់ហេតុ
ការប្រមូលកំណត់ហេតុ "ឆៅ"
កំឡុងពេលធ្វើតេស្តផ្ទុក៖
ផ្ទុកកំណត់ត្រាសកម្មភាពភ្នាក់ងារ,
ស្ថានភាពនៃគោលដៅសាកល្បង
និង VM ដែលដំណើរការភ្នាក់ងារ

កំណត់ហេតុប្រតិបត្តិ
ការធ្វើតេស្តផ្ទុក
កំណត់ហេតុប្រព័ន្ធ

ម៉ែត្រ
ការប្រមូលរង្វាស់ "ឆៅ" កំឡុងពេលធ្វើតេស្ត

ថាមវន្តនៃការផ្លាស់ប្តូរនៅក្នុងរង្វាស់គោលដៅ
និងភ្នាក់ងារផ្ទុក

របាយការណ៍៖ ដំណាក់កាលរៀបចំរបាយការណ៍សាកល្បង

ម៉ាស៊ីនភ្លើង
ដំណើរការត្រូវបានប្រមូល
ប្រព័ន្ធផ្ទុកនិង
ប្រព័ន្ធត្រួតពិនិត្យ "ឆៅ"
ម៉ែត្រនិងកំណត់ហេតុ
ការបង្កើតរបាយការណ៍នៅក្នុង
ទម្រង់ដែលអាចអានបានរបស់មនុស្ស
អាចធ្វើទៅបានជាមួយធាតុ
អ្នកវិភាគ
កំណត់ហេតុប្រតិបត្តិ
ការធ្វើតេស្តផ្ទុក
កំណត់ហេតុប្រព័ន្ធ
ថាមវន្តនៃការផ្លាស់ប្តូរនៅក្នុងម៉ែត្រ
គោលដៅនិងភ្នាក់ងារផ្ទុក
ដំណើរការកំណត់ហេតុ "ឆៅ"
ក្នុងទម្រង់សមរម្យសម្រាប់
ផ្ទុកឡើងទៅកន្លែងផ្ទុកខាងក្រៅ
របាយការណ៍ផ្ទុកឋិតិវន្ត,
មនុស្សអាចអានបាន។

បោះពុម្ពផ្សាយ
ការបោះពុម្ពរបាយការណ៍
អំពីបន្ទុក
ការធ្វើតេស្តខាងក្រៅ
សេវាកម្ម។
កែច្នៃ "ឆៅ"
កត់ត្រាក្នុងទម្រង់សមរម្យ
សម្រាប់ផ្ទុកទៅខាងក្រៅ
ឃ្លាំង
រក្សាទុកក្នុងផ្នែកខាងក្រៅ
របាយការណ៍ផ្ទុកនៅលើ
ផ្ទុក, សមរម្យ
សម្រាប់ការវិភាគរបស់មនុស្ស

ការភ្ជាប់ប្រភពផ្ទុកនៅក្នុងគំរូ CI

ចូរបន្តទៅផ្នែកជាក់ស្តែង។ ខ្ញុំចង់បង្ហាញពីរបៀបលើគម្រោងមួយចំនួននៅក្នុងក្រុមហ៊ុន បច្ចេកវិទ្យាវិជ្ជមាន យើងបានអនុវត្តគំនិតនៃការធ្វើតេស្តផ្ទុកជាសេវាកម្មមួយ។

ជាដំបូង ដោយមានជំនួយពីវិស្វករ DevOps របស់យើង យើងបានបង្កើតក្រុមភ្នាក់ងារពិសេសមួយនៅក្នុង GitLab CI ដើម្បីដំណើរការការធ្វើតេស្តផ្ទុក។ ដើម្បីកុំឱ្យច្រឡំពួកវានៅក្នុងគំរូជាមួយអ្នកដទៃ ដូចជាអាងប្រមូលផ្តុំ យើងបានបន្ថែមស្លាកទៅភ្នាក់ងារទាំងនេះ។ ស្លាក: ផ្ទុក។ អ្នកអាចប្រើស្លាកដែលអាចយល់បានផ្សេងទៀត។ ពួកគេសួរ ក្នុងអំឡុងពេលចុះឈ្មោះ អ្នករត់ GitLab CI ។

តើធ្វើដូចម្តេចដើម្បីស្វែងរកថាមពលដែលត្រូវការដោយផ្នែករឹង? លក្ខណៈនៃភ្នាក់ងារផ្ទុក - ចំនួនគ្រប់គ្រាន់នៃ vCPU, RAM និង Disk - អាចត្រូវបានគណនាដោយផ្អែកលើការពិតដែលថា Docker, Python (សម្រាប់ Yandex.Tank), ភ្នាក់ងារ GitLab CI, Java (សម្រាប់ Apache JMeter) គួរតែដំណើរការលើភ្នាក់ងារ . សម្រាប់ Java ក្រោម JMeter វាត្រូវបានណែនាំផងដែរឱ្យប្រើ RAM អប្បបរមា 512 MB ហើយជាដែនកំណត់ខាងលើ។ 80% អង្គចងចាំដែលអាចប្រើបាន.

ដូច្នេះ ដោយផ្អែកលើបទពិសោធន៍របស់យើង យើងសូមណែនាំឱ្យប្រើ vCPU យ៉ាងហោចណាស់ 4, RAM 4 GB, 60 GB SSD សម្រាប់ភ្នាក់ងារផ្ទុក។ លំហូរនៃកាតបណ្តាញត្រូវបានកំណត់ដោយផ្អែកលើតម្រូវការនៃទម្រង់ផ្ទុក។

យើងប្រើប្រភពផ្ទុកពីរជាចម្បង - Apache JMeter និង Yandex.Tank docker រូបភាព។

ធុង Yandex គឺជាឧបករណ៍ប្រភពបើកចំហពី Yandex សម្រាប់ការធ្វើតេស្តផ្ទុក។ ស្ថាបត្យកម្ម​ម៉ូឌុល​របស់​វា​គឺ​ផ្អែក​លើ​ម៉ាស៊ីន​បង្កើត​សំណើ HTTP ដែល​ដំណើរការ​ដោយ​អសមកាល​ដែល​មាន​ប្រសិទ្ធភាព​ខ្ពស់​របស់ Phantom។ ធុងមានការត្រួតពិនិត្យធនធានរបស់ម៉ាស៊ីនមេដែលកំពុងធ្វើតេស្តតាមរយៈពិធីការ SSH អាចបញ្ឈប់ការធ្វើតេស្តដោយស្វ័យប្រវត្តិក្រោមលក្ខខណ្ឌដែលបានបញ្ជាក់ អាចបង្ហាញលទ្ធផលទាំងនៅក្នុងកុងសូល និងក្នុងទម្រង់ក្រាហ្វ អ្នកអាចភ្ជាប់ម៉ូឌុលរបស់អ្នក ទៅវាដើម្បីពង្រីកមុខងារ។ ដោយវិធីនេះ យើងបានប្រើធុង នៅពេលដែលវាមិនទាន់ជាចរន្ត។ នៅក្នុងអត្ថបទ "ស្វ័យប្រវត្តិកម្មសាកល្បង Yandex.Tank និងផ្ទុក» អ្នក​អាច​អាន​រឿង​នៃ​របៀប​ដែល​យើង​បាន​ធ្វើ​តេស្ត​ផ្ទុក​ជាមួយ​វា​ក្នុង​ឆ្នាំ 2013 ជញ្ជាំងភ្លើងកម្មវិធី PT គឺជាផលិតផលមួយរបស់ក្រុមហ៊ុនយើងខ្ញុំ។

កម្មវិធី Apache JMeter គឺជាឧបករណ៍សាកល្បងផ្ទុកប្រភពបើកចំហពី Apache ។ វា​អាច​ត្រូវ​បាន​ប្រើ​ស្មើ​គ្នា​ល្អ​សម្រាប់​ការ​សាកល្បង​ទាំង​កម្មវិធី​បណ្ដាញ​ឋិតិវន្ត​និង​ថាមវន្ត។ JMeter គាំទ្រពិធីការ និងវិធីជាច្រើនដើម្បីធ្វើអន្តរកម្មជាមួយកម្មវិធី៖ HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET ។ល។), SOAP/REST Webservices, FTP, TCP, LDAP, SMTP(S), POP3( S) ) និង IMAP(S) មូលដ្ឋានទិន្នន័យតាមរយៈ JDBC អាចប្រតិបត្តិពាក្យបញ្ជាសែល និងធ្វើការជាមួយវត្ថុ Java ។ JMeter មាន IDE សម្រាប់បង្កើត បំបាត់កំហុស និងអនុវត្តផែនការសាកល្បង។ វាក៏មាន CLI សម្រាប់ប្រតិបត្តិការបន្ទាត់ពាក្យបញ្ជានៅលើប្រព័ន្ធប្រតិបត្តិការដែលត្រូវគ្នាជាមួយ Java ណាមួយ (Linux, Windows, Mac OS X)។ ឧបករណ៍នេះអាចបង្កើតរបាយការណ៍សាកល្បង HTML យ៉ាងសកម្ម។

ដើម្បីភាពងាយស្រួលនៃការប្រើប្រាស់នៅក្នុងក្រុមហ៊ុនរបស់យើង ដើម្បីសមត្ថភាពរបស់អ្នកសាកល្បងខ្លួនឯងក្នុងការផ្លាស់ប្តូរ និងបន្ថែមបរិយាកាស យើងបានបង្កើតរូបភាព docker នៃប្រភពផ្ទុកនៅលើ GitLab CI ជាមួយនឹងការបោះពុម្ពទៅផ្នែកខាងក្នុង។ ការចុះបញ្ជី docker នៅ Artifactory. នេះធ្វើឱ្យវាកាន់តែលឿន និងងាយស្រួលក្នុងការភ្ជាប់ពួកវានៅក្នុងបំពង់សម្រាប់ការធ្វើតេស្តផ្ទុក។ របៀបធ្វើ Docker រុញទៅបញ្ជីឈ្មោះតាមរយៈ GitLab CI - សូមមើល ការណែនាំ.

យើងបានយកឯកសារ docker មូលដ្ឋាននេះសម្រាប់ Yandex.Tank៖

Dockerfile 
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]

ហើយសម្រាប់ Apache JMeter មួយនេះ៖

Dockerfile 
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]

អ្នកអាចអានពីរបៀបដែលប្រព័ន្ធរួមបញ្ចូលជាបន្តបន្ទាប់របស់យើងដំណើរការនៅក្នុងអត្ថបទ "ស្វ័យប្រវត្តិកម្មនៃដំណើរការអភិវឌ្ឍន៍៖ របៀបដែលយើងអនុវត្តគំនិត DevOps នៅបច្ចេកវិទ្យាវិជ្ជមាន"។

គំរូនិងបំពង់

ឧទាហរណ៍នៃគំរូសម្រាប់ធ្វើតេស្តផ្ទុកមាននៅក្នុងគម្រោង បន្ទុកសាកល្បង។ នេះ ឯកសារ readme អ្នកអាចអានការណែនាំសម្រាប់ការប្រើប្រាស់គំរូ។ នៅក្នុងគំរូខ្លួនវា (ឯកសារ .gitlab-ci.yml) មានកំណត់ចំណាំអំពីអ្វីដែលជំហាននីមួយៗទទួលខុសត្រូវ។

គំរូនេះគឺសាមញ្ញណាស់ ហើយបង្ហាញពីដំណាក់កាលទាំងបីនៃការធ្វើតេស្តបន្ទុកដែលបានពិពណ៌នានៅក្នុងដ្យាក្រាមខាងលើ៖ ការរៀបចំ ការធ្វើតេស្ត និងការបោះពុម្ពរបាយការណ៍។ ទទួលខុសត្រូវចំពោះរឿងនេះ កម្មសិក្សា: រៀបចំ សាកល្បង និងរាយការណ៍.

1. ដំណាក់កាល រៀបចំ គួរតែត្រូវបានប្រើដើម្បីកំណត់គោលដៅសាកល្បងជាមុន ឬពិនិត្យមើលភាពអាចរកបានរបស់វា។ បរិស្ថានសម្រាប់ប្រភពផ្ទុកមិនចាំបាច់កំណត់រចនាសម្ព័ន្ធទេ ពួកគេត្រូវបានបង្កើតជាមុនជារូបភាព docker ហើយបង្ហោះក្នុងបញ្ជីឈ្មោះ docker៖ គ្រាន់តែបញ្ជាក់កំណែដែលចង់បាននៅដំណាក់កាលសាកល្បង។ ប៉ុន្តែ​អ្នក​អាច​បង្កើត​វា​ឡើង​វិញ និង​បង្កើត​រូបភាព​ដែល​បាន​កែប្រែ​ដោយ​ខ្លួនឯង។
2. ដំណាក់កាល ការធ្វើតេស្ត ប្រើដើម្បីបញ្ជាក់ប្រភពផ្ទុក ដំណើរការតេស្ត និងរក្សាទុកវត្ថុបុរាណសាកល្បង។ អ្នកអាចជ្រើសរើសប្រភពផ្ទុកណាមួយ៖ Yandex.Tank, Apache JMeter, ផ្ទាល់ខ្លួនរបស់អ្នក ឬទាំងអស់គ្នា។ ដើម្បីបិទប្រភពដែលមិនចាំបាច់ គ្រាន់តែបញ្ចេញមតិ ឬលុបការងារនោះ។ ចំណុចចូលសម្រាប់ប្រភពផ្ទុក៖
   • ប៉ារ៉ាម៉ែត្រចាប់ផ្តើមសម្រាប់ Yandex.Tank ត្រូវបានបញ្ជាក់នៅក្នុង ./tests/yandextank.sh,
   • ប៉ារ៉ាម៉ែត្រចាប់ផ្តើម Apache JMeter ត្រូវបានបញ្ជាក់នៅក្នុងឯកសារ ./tests/jmeter.sh.

   ចំណាំ៖ គំរូនៃការកំណត់រចនាសម្ព័ន្ធការជួបប្រជុំគ្នាត្រូវបានប្រើដើម្បីរៀបចំអន្តរកម្មជាមួយប្រព័ន្ធ CI និងមិនបញ្ជាក់ពីការដាក់តក្កវិជ្ជាសាកល្បងនៅក្នុងវាទេ។ សម្រាប់ការធ្វើតេស្ត ចំណុចចូលត្រូវបានបញ្ជាក់ ជាកន្លែងដែលស្គ្រីប bash បញ្ជាស្ថិតនៅ។ វិធីសាស្រ្តនៃការដំណើរការការធ្វើតេស្ត បង្កើតរបាយការណ៍ និងស្គ្រីបសាកល្បងខ្លួនឯងត្រូវតែអនុវត្តដោយវិស្វករ QA ។ នៅក្នុងការបង្ហាញ សម្រាប់ប្រភពផ្ទុកទាំងពីរ សំណើទំព័រមេ Yandex ត្រូវបានប្រើជាការសាកល្បងសាមញ្ញបំផុត។ ស្គ្រីប និង​ប៉ារ៉ាម៉ែត្រ​សាកល្បង​មាន​នៅ​ក្នុង​ថត ./tests.

3. នៅឆាក របាយការណ៍ អ្នកត្រូវពណ៌នាអំពីរបៀបបោះផ្សាយលទ្ធផលតេស្តដែលទទួលបាននៅដំណាក់កាលសាកល្បងទៅកាន់កន្លែងផ្ទុកខាងក្រៅ ឧទាហរណ៍ទៅកាន់ GitLab Pages ឬប្រព័ន្ធរាយការណ៍ពិសេស។ ទំព័រ GitLab តម្រូវឱ្យថតឯកសារ ./public មិនទទេ និងមានឯកសារ index.html យ៉ាងតិចបន្ទាប់ពីការធ្វើតេស្តបានបញ្ចប់។ អ្នកអាចអានអំពីភាពខុសគ្នានៃសេវាកម្ម GitLab Pages ។ តំណភ្ជាប់.

   ឧទាហរណ៍នៃរបៀបនាំចេញទិន្នន័យ៖

   • ពី JMeter ទៅ ទំព័រ GitLab,
   • ពី Yandex.Tank ទៅ InfluxDB និង Grafana.

   ការបង្ហោះការណែនាំអំពីការដំឡើង៖

   • HTML ឋិតិវន្តនៅក្នុង ទំព័រ GitLab,
   • ទៅ InfluxDB ហើយបន្ទាប់មកទៅ ហ្គ្រេណាណា.

នៅក្នុងឧទាហរណ៍សាកល្បង បំពង់ដែលមានការធ្វើតេស្តផ្ទុក និងប្រភពផ្ទុកពីរ (អ្នកអាចបិទដំណើរការដែលមិនចាំបាច់) មើលទៅដូចនេះ៖

Apache JMeter អាចបង្កើតរបាយការណ៍ HTML ដោយខ្លួនឯង ដូច្នេះវាកាន់តែចំណេញក្នុងការរក្សាទុកវានៅក្នុង GitLab Pages ដោយប្រើឧបករណ៍ស្តង់ដារ។ នេះជារបៀបដែលរបាយការណ៍ Apache JMeter មើលទៅដូចនេះ៖

នៅក្នុងឧទាហរណ៍សាកល្បងសម្រាប់ Yandex.Tank អ្នកនឹងឃើញតែប៉ុណ្ណោះ របាយការណ៍អត្ថបទក្លែងក្លាយ នៅក្នុងផ្នែកសម្រាប់ទំព័រ GitLab ។ កំឡុងពេលសាកល្បង ធុងអាចរក្សាទុកលទ្ធផលទៅក្នុងមូលដ្ឋានទិន្នន័យ InfluxDB ហើយពីទីនោះពួកវាអាចត្រូវបានបង្ហាញជាឧទាហរណ៍ក្នុង Grafana (ការកំណត់រចនាសម្ព័ន្ធត្រូវបានធ្វើរួចនៅក្នុងឯកសារ ./tests/example-yandextank-test.yml) នេះជារបៀបដែលរបាយការណ៍របស់ Tank មើលទៅក្នុង Grafana៖

សង្ខេប

នៅក្នុងអត្ថបទខ្ញុំបាននិយាយអំពីគំនិតនៃ "ការធ្វើតេស្តផ្ទុកជាសេវាកម្ម" (ការធ្វើតេស្តផ្ទុកជាសេវាកម្ម) ។ គំនិតសំខាន់គឺត្រូវប្រើហេដ្ឋារចនាសម្ព័ន្ធនៃក្រុមភ្នាក់ងារផ្ទុកដែលបានកំណត់ជាមុន រូបភាព docker នៃប្រភពផ្ទុក ប្រព័ន្ធរាយការណ៍ និងបំពង់ដែលរួមបញ្ចូលគ្នាពួកវានៅក្នុង GitLab CI ដោយផ្អែកលើគំរូ .gitlab-ci.yml សាមញ្ញ (ឧទាហរណ៍ តំណភ្ជាប់) ទាំងអស់នេះត្រូវបានគាំទ្រដោយក្រុមវិស្វករស្វ័យប្រវត្តិកម្មតូចមួយ ហើយចម្លងតាមសំណើរបស់ក្រុមផលិតផល។ ខ្ញុំសង្ឃឹមថាវានឹងជួយអ្នកក្នុងការរៀបចំ និងអនុវត្តគម្រោងស្រដៀងគ្នានៅក្នុងក្រុមហ៊ុនរបស់អ្នក។ សូមអរគុណចំពោះការយកចិត្តទុកដាក់!

PS ខ្ញុំចង់និយាយការថ្លែងអំណរគុណយ៉ាងជ្រាលជ្រៅចំពោះសហសេវិករបស់ខ្ញុំគឺលោក Sergey Kurbanov និង Nikolai Yusev សម្រាប់ជំនួយបច្ចេកទេសក្នុងការអនុវត្តគំនិតនៃការធ្វើតេស្តបន្ទុកជាសេវាកម្មនៅក្នុងក្រុមហ៊ុនរបស់យើង។

អ្នកនិពន្ធ: Timur Gillmullin - អនុប្រធាន ប្រធានផ្នែកបច្ចេកវិទ្យា និងដំណើរការអភិវឌ្ឍន៍ (DevOps) នៅបច្ចេកវិទ្យាវិជ្ជមាន

ប្រភព: www.habr.com