Բեռնել փորձարկումը որպես CI ծառայություն մշակողների համար

Խնդիրներից մեկը, որին հաճախ հանդիպում են բազմաբնույթ արտադրանք ծրագրային ապահովման վաճառողները, ինժեներների՝ մշակողների, փորձարկողների և ենթակառուցվածքի ադմինիստրատորների իրավասությունների կրկնօրինակումն է գրեթե բոլոր թիմերում: Սա վերաբերում է նաև թանկարժեք ինժեներներին՝ բեռի փորձարկման ոլորտի մասնագետներին։

Իրենց անմիջական պարտականությունները կատարելու և իրենց եզակի փորձն օգտագործելու փոխարեն բեռնվածության փորձարկման գործընթաց ստեղծելու, մեթոդաբանություն, օպտիմալ չափումներ և բեռնվածության պրոֆիլներին համապատասխան ինքնաթեստեր ընտրելու համար, ինժեներները հաճախ ստիպված են լինում զրոյից տեղակայել թեստային ենթակառուցվածքը, կարգավորել բեռնման գործիքները և տեղադրել դրանք։ իրենք իրենց CI համակարգերում, ստեղծեցին մոնիտորինգ և հաշվետվությունների հրապարակում:

Դուք կարող եք լուծումներ գտնել կազմակերպչական որոշ խնդիրների թեստավորման ժամանակ, որոնք մենք օգտագործում ենք Positive Technologies-ում մեկ այլ հոդված. Եվ այս մեկում ես կխոսեմ բեռնվածության թեստերը ընդհանուր CI խողովակաշարում ինտեգրելու հնարավորության մասին՝ օգտագործելով «բեռնվածության փորձարկումը որպես ծառայություն» հայեցակարգը (բեռնվածության փորձարկումը որպես ծառայություն): Դուք կսովորեք, թե ինչպես և բեռնվածքի աղբյուրների որ դոկերի պատկերները կարող են օգտագործվել CI խողովակաշարում; ինչպես միացնել բեռնման աղբյուրները ձեր CI նախագծին՝ օգտագործելով build template-ը; ինչպիսին է ցուցադրական խողովակաշարը բեռնվածության թեստերն իրականացնելու և արդյունքները հրապարակելու համար: Հոդվածը կարող է օգտակար լինել ծրագրային ապահովման փորձարկման ինժեներների և CI-ի ավտոմատացման ինժեներների համար, ովքեր մտածում են իրենց բեռնման համակարգի ճարտարապետության մասին:

Հայեցակարգի էությունը

Բեռնվածության թեստավորման հայեցակարգը որպես ծառայություն ենթադրում է բեռնման գործիքներ Apache JMeter, Yandex.Tank և ձեր սեփական շրջանակները կամայական շարունակական ինտեգրման համակարգում ինտեգրելու հնարավորություն: Դեմո ցուցադրությունը կլինի GitLab CI-ի համար, սակայն սկզբունքները ընդհանուր են բոլոր CI համակարգերի համար:

Բեռի փորձարկումը որպես ծառայություն կենտրոնացված ծառայություն է բեռի փորձարկման համար: Բեռնման թեստերն իրականացվում են հատուկ գործակալների լողավազաններում, արդյունքները հրապարակվում են ավտոմատ կերպով GitLab Pages-ում, Influx DB-ում և Grafana-ում կամ թեստային հաշվետվությունների համակարգերում (TestRail, ReportPortal և այլն): Ավտոմատացումն ու մասշտաբավորումն իրականացվում են հնարավորինս պարզ՝ GitLab CI նախագծում սովորական gitlab-ci.yml ձևանմուշն ավելացնելով և պարամետրացնելով:

Այս մոտեցման առավելությունն այն է, որ ամբողջ CI ենթակառուցվածքը, բեռնման գործակալները, բեռնման աղբյուրների դոկերի պատկերները, փորձարկման խողովակաշարերը և հրապարակման հաշվետվությունները պահպանվում են կենտրոնացված ավտոմատացման բաժնի կողմից (DevOps ինժեներներ), մինչդեռ բեռի փորձարկման ինժեներները կարող են կենտրոնացնել իրենց ջանքերը թեստի մշակման վրա: և դրանց արդյունքների վերլուծություն՝ առանց ենթակառուցվածքի խնդիրների հետ առնչվելու։

Նկարագրության պարզության համար մենք կենթադրենք, որ թիրախային հավելվածը կամ սերվերը, որը փորձարկվում է, արդեն տեղակայվել և կարգավորվել է նախապես (դրա համար կարող են օգտագործվել Python-ի, SaltStack-ի, Ansible-ի և այլնի ավտոմատացված սկրիպտները): Այնուհետև բեռի փորձարկման ամբողջ հայեցակարգը որպես ծառայություն տեղավորվում է երեք փուլով. հաշվետվությունների պատրաստում, փորձարկում, հրապարակում. Լրացուցիչ մանրամասներ դիագրամի վերաբերյալ (բոլոր նկարները կարելի է սեղմել).

Հիմնական հասկացություններ և սահմանումներ բեռի փորձարկման մեջ

Բեռի փորձարկումներ կատարելիս մենք փորձում ենք հավատարիմ մնալ ISTQB ստանդարտներ և մեթոդաբանություն, օգտագործեք համապատասխան տերմինաբանությունը և առաջարկվող չափումները: Ես կտամ բեռի փորձարկման հիմնական հասկացությունների և սահմանումների կարճ ցուցակը:

Բեռնման գործակալ - վիրտուալ մեքենա, որի վրա կգործարկվի հավելվածը, բեռնման աղբյուրը (Apache JMeter, Yandex.Tank կամ ինքնուրույն գրված բեռնման մոդուլ):

Փորձարկման նպատակ (նպատակ) - սերվերի վրա տեղադրված սերվեր կամ հավելված, որը ենթակա է բեռնման:

Փորձարկման սցենար (փորձարկման դեպք) - պարամետրացված քայլերի մի շարք. օգտագործողի գործողություններ և ակնկալվող արձագանքներ այդ գործողություններին, ֆիքսված ցանցային հարցումներով և պատասխաններով՝ կախված նշված պարամետրերից:

Պրոֆիլ կամ բեռնման պլան (պրոֆիլ) - ին ISTQB մեթոդաբանություն (Բաժին 4.2.4, էջ 43) բեռնվածության պրոֆիլները սահմանում են չափումներ, որոնք կարևոր են որոշակի թեստի համար և փորձարկման ընթացքում բեռնվածքի պարամետրերը փոխելու տարբերակներ: Նկարում կարող եք տեսնել պրոֆիլների օրինակներ:

Փորձարկում — նախապես որոշված ​​պարամետրերով սկրիպտ:

Փորձարկման պլան (թեստ-պլան) - թեստերի մի շարք և բեռնման պրոֆիլ:

Տեստրան (թեստրան) - մեկ փորձարկում իրականացնելու մեկ կրկնություն՝ ամբողջությամբ կատարված ծանրաբեռնվածության սցենարով և ստացված զեկույցով:

Ցանցի հարցում (խնդրանք) — Գործակալից թիրախ ուղարկված HTTP հարցում:

Ցանցային արձագանք (պատասխան) — թիրախից գործակալին ուղարկված HTTP պատասխան:
HTTP պատասխանի կոդը (HTTP պատասխանների կարգավիճակ) - ստանդարտ պատասխանի կոդ հավելվածի սերվերից:
Գործարքը հարցում-պատասխանի ամբողջական ցիկլ է: Գործարքը հաշվվում է հարցում (հարցում) ուղարկելու սկզբից մինչև պատասխանի (պատասխանի) ստացման ավարտը:

Գործարքի կարգավիճակը - հնարավո՞ր էր հաջողությամբ ավարտել հարցում-պատասխան ցիկլը: Եթե ​​այս ցիկլում որևէ սխալ է եղել, ապա ամբողջ գործարքը համարվում է անհաջող:

Արձագանքման ժամանակ (ուշացում) - հարցում (հարցում) ուղարկելու ավարտից մինչև պատասխան (պատասխան) ​​ստանալու սկիզբը ընկած ժամանակահատվածը.

Բեռնման չափումներ - բեռնված ծառայության և բեռնվածքի գործոնի բնութագրերը, որոնք որոշվել են բեռի փորձարկման գործընթացում:

Բեռի պարամետրերի չափման հիմնական չափորոշիչներ

Մեթոդաբանության մեջ առավել հաճախ օգտագործվող և առաջարկվողներից մի քանիսը ISTQB (էջ 36, 52) չափիչները ներկայացված են ստորև բերված աղյուսակում: Գործակալի և թիրախի նմանատիպ ցուցանիշները նշված են նույն տողում:

Չափումներ բեռի գործակալի համար
Թիրախային համակարգի կամ հավելվածի չափումները, որոնք փորձարկվում են բեռի տակ

Թիվ  vCPU և հիշողություն RAM,
Սկավառակ - բեռի նյութի «երկաթե» բնութագրերը
CPU, Հիշողություն, սկավառակի օգտագործում - պրոցեսորի, հիշողության և սկավառակի բեռնման դինամիկան
փորձարկման գործընթացում։ Սովորաբար չափվում է որպես տոկոս
առավելագույն մատչելի արժեքներ

ցանցի թողունակությունը (բեռնվածքի գործակալի վրա) - թողունակություն
ցանցային ինտերֆեյս սերվերի վրա,
որտեղ տեղադրված է բեռի գործակալը:
Սովորաբար չափվում է բայթ/վրկ (bps)
ցանցի թողունակությունը(թիրախում) - ցանցային ինտերֆեյսի թողունակություն
թիրախային սերվերի վրա: Սովորաբար չափվում է բայթ/վրկ (bps)

Վիրտուալ օգտվողներ- վիրտուալ օգտագործողների թիվը,
բեռնվածության սցենարների իրականացում և
իրական օգտագործողի գործողությունների իմիտացիա
Վիրտուալ օգտվողների կարգավիճակը, Անցած/Չհաջողվեց/Ընդհանուր — հաջողվածների թիվը և
վիրտուալ օգտատերերի անհաջող կարգավիճակները
ծանրաբեռնվածության սցենարների համար, ինչպես նաև դրանց ընդհանուր թիվը:

Ընդհանուր առմամբ, ակնկալվում է, որ բոլոր օգտվողները կարողացան ավարտել
ձեր բոլոր առաջադրանքները, որոնք նշված են բեռնման պրոֆիլում:
Ցանկացած սխալ կնշանակի, որ իրական օգտվողը չի կարողանա
լուծել ձեր խնդիրը համակարգի հետ աշխատելիս

Հարցումներ վայրկյանում (րոպե)- ցանցի հարցումների քանակը վայրկյանում (կամ րոպեում):

Բեռնավորման գործակալի կարևոր հատկանիշն այն է, թե քանի հարցում կարող է առաջացնել:
Իրականում սա վիրտուալ օգտատերերի կողմից հավելված մուտք գործելու իմիտացիա է
Պատասխաններ վայրկյանում (րոպե)
- ցանցի պատասխանների քանակը վայրկյանում (կամ րոպեում):

Թիրախային ծառայության կարևոր բնութագիրը՝ որքան
ստեղծել և ուղարկել հարցումների պատասխանները
բեռնման գործակալ

HTTP պատասխանի կարգավիճակը- տարբեր պատասխանների կոդերի քանակը
բեռնման գործակալի կողմից ստացված հավելվածի սերվերից:
Օրինակ, 200 OK նշանակում է հաջող զանգ,
իսկ 404 - որ ռեսուրսը չի գտնվել

Ժամկետանցություն (արձագանքման ժամանակ) - վերջից ժամանակը
հարցում (հարցում) ուղարկելուց առաջ պատասխան (պատասխան) ​​ստանալը.
Սովորաբար չափվում է միլիվայրկյաններով (ms)

Գործարքի արձագանքման ժամանակը- մեկ ամբողջական գործարքի ժամանակը,
հարցում-պատասխան ցիկլի ավարտը:
Սա հարցումն (հարցում) ուղարկելու սկզբից սկսած ժամանակն է
մինչև պատասխանի (պատասխանի) ստացման ավարտը։

Գործարքի ժամանակը կարող է չափվել վայրկյաններով (կամ րոպեներով)
մի քանի առումներով՝ հաշվի առեք նվազագույնը,
առավելագույնը, միջինը և, օրինակ, 90-րդ տոկոսը։
Նվազագույն և առավելագույն ցուցանիշները ծայրահեղ են
համակարգի աշխատանքի կարգավիճակը.
Իննսուներորդ տոկոսը ամենատարածվածն է,
ինչպես ցույց է տալիս օգտվողների մեծ մասը,
հարմարավետ աշխատել համակարգի կատարողականի շեմին

Գործարքներ վայրկյանում (րոպե) - ամբողջականների թիվը
գործարքներ վայրկյանում (րոպե),
այն է՝ ինչքանով է կարողացել ընդունել դիմումը և
մշակել հարցումները և թողարկել պատասխանները:
Իրականում սա համակարգի թողունակությունն է

Գործարքի կարգավիճակը , Անցել է / Չհաջողվեց / Ընդհանուր - համարը
հաջող, անհաջող և գործարքների ընդհանուր թիվը:

Իրական օգտվողների համար անհաջող
գործարքը իրականում կնշանակի
բեռի տակ համակարգի հետ աշխատելու անկարողությունը

Բեռնման փորձարկման սխեմատիկ դիագրամ

Բեռի փորձարկման հայեցակարգը շատ պարզ է և բաղկացած է երեք հիմնական փուլից, որոնք ես արդեն նշեցի. Պատրաստել-Թեստ-Զեկույց, այսինքն՝ փորձարկման նպատակների պատրաստում և բեռնվածության աղբյուրների պարամետրերի սահմանում, այնուհետև կատարում բեռնվածության թեստեր և վերջում՝ ստեղծելով և հրապարակելով փորձարկման հաշվետվություն։

Սխեմատիկ նշումներ.

• QA.Tester-ը բեռի փորձարկման փորձագետ է,
• Թիրախը այն թիրախային ծրագիրն է, որի համար ցանկանում եք իմանալ դրա վարքագիծը ծանրաբեռնվածության տակ:

Դիագրամի սուբյեկտների, փուլերի և քայլերի դասակարգիչ

Փուլեր և քայլեր
Ինչ է կատարվում
Ինչ կա մուտքի մոտ
Ինչ է ելքը

Պատրաստել՝ փորձարկման նախապատրաստական ​​փուլ

LoadParameters
Կարգավորում և սկզբնավորում
օգտվող
բեռնվածության պարամետրերը,
չափումների ընտրություն և
թեստի պլանի պատրաստում
(բեռնել պրոֆիլը)
Պատվերով ընտրանքներ համար
բեռնման գործակալի սկզբնավորում
Փորձարկման պլան
Փորձարկման նպատակը

VM
Ամպի տեղակայում
վիրտուալ մեքենայի հետ
պահանջվող բնութագրերը
VM կարգավորումներ բեռնման գործակալի համար
Ավտոմատացման սցենարներ համար
VM-ի ստեղծում
VM-ը կազմաձևված է
ամպ

Նախանձ
ՕՀ-ի կարգավորում և պատրաստում
միջավայրի համար
բեռի գործակալի աշխատանք
Շրջակա միջավայրի պարամետրերը
բեռնման գործակալ
Ավտոմատացման սցենարներ համար
շրջակա միջավայրի կարգավորումները
Պատրաստված միջավայր.
ՕՀ, ծառայություններ և հավելվածներ,
աշխատանքի համար անհրաժեշտ
բեռնման գործակալ

LoadAgents
Տեղադրում, կոնֆիգուրացիա և պարամետրիզացիա
բեռնման գործակալ.
Կամ դոկերի պատկերը ներբեռնելով
նախապես կազմաձևված բեռնման աղբյուր
Բեռնել աղբյուրի դոկերի պատկերը
(YAT, JM կամ ինքնուրույն գրված շրջանակ)
Կարգավորումներ
բեռնման գործակալ
Ստեղծեք և պատրաստ
աշխատել բեռի գործակալ

Փորձարկում՝ բեռի փորձարկումների կատարման փուլ: Աղբյուրները բեռնման գործակալներ են, որոնք տեղակայված են հատուկ գործակալների լողավազաններում GitLab CI-ի համար

Բեռ
Բեռնման գործակալի գործարկում
ընտրված թեստային պլանով
և բեռի պարամետրերը
Օգտագործողի ընտրանքներ
սկզբնավորման համար
բեռնման գործակալ
Փորձարկման պլան
Փորձարկման նպատակը
Կատարման տեղեկամատյաններ
բեռնվածության թեստեր
Համակարգի տեղեկամատյաններ
Նպատակների չափման և բեռի գործակալի փոփոխությունների դինամիկան

Գործարկեք գործակալները
Գործակալի կատարում
թեստային սցենարների բեռներ
ըստ էության
բեռնել պրոֆիլը
Բեռնավորող գործակալի փոխազդեցություն
փորձարկման նպատակով
Փորձարկման պլան
Փորձարկման նպատակը

Տեղեկամատյաններ
«Հում» գերանների հավաքածու
բեռի փորձարկման ժամանակ.
բեռնել գործակալի գործունեության գրառումները,
փորձարկման թիրախի վիճակը
և VM-ն, որը ղեկավարում է գործակալը

Կատարման տեղեկամատյաններ
բեռնվածության թեստեր
Համակարգի տեղեկամատյաններ

Չափման համակարգ
Թեստավորման ընթացքում «հում» չափումների հավաքում

Նպատակների չափումների փոփոխությունների դինամիկան
և բեռնման գործակալ

Հաշվետվություն՝ թեստային հաշվետվության պատրաստման փուլ

Գեներատոր
Հավաքված վերամշակում
բեռնման համակարգ և
մոնիտորինգի համակարգ «հում»
չափումներ և տեղեկամատյաններ
Հաշվետվության ձևավորումը
մարդու ընթեռնելի ձև
հնարավոր է տարրերով
վերլուծաբաններ
Կատարման տեղեկամատյաններ
բեռնվածության թեստեր
Համակարգի տեղեկամատյաններ
Մետրիկայի փոփոխությունների դինամիկան
թիրախ և բեռի գործակալ
Մշակված «հում» տեղեկամատյաններ
համար հարմար ձևաչափով
վերբեռնումներ արտաքին պահեստում
Ստատիկ բեռի հաշվետվություն,
մարդ ընթեռնելի

Հրատարակել
Զեկույցի հրապարակում
բեռի մասին
փորձարկում արտաքինում
սպասարկում
Մշակված «հում»
տեղեկամատյանները համապատասխան ձևաչափով
արտաքին բեռնաթափման համար
պահոցներ
Պահպանված է արտաքին
պահեստավորման մասին հաշվետվություններ
բեռ, հարմար
մարդկային վերլուծության համար

Բեռնման աղբյուրների միացում CI ձևանմուշում

Անցնենք գործնական մասին։ Ես ուզում եմ ցույց տալ, թե ինչպես է որոշ նախագծերի վրա ընկերության Դրական տեխնոլոգիաներ մենք որպես ծառայություն իրականացրել ենք բեռի փորձարկման հայեցակարգը:

Նախ, մեր DevOps ինժեներների օգնությամբ մենք GitLab CI-ում ստեղծեցինք գործակալների հատուկ լողավազան՝ բեռնվածության թեստերն իրականացնելու համար: Որպեսզի դրանք կաղապարներում չշփոթենք այլոց հետ, ինչպիսիք են հավաքման լողավազանները, մենք պիտակներ ավելացրեցինք այս գործակալներին, Tags: բեռ. Դուք կարող եք օգտագործել ցանկացած այլ հասկանալի պիտակներ: Հարցնում են գրանցման ժամանակ GitLab CI Runners.

Ինչպե՞ս պարզել անհրաժեշտ հզորությունը սարքաշարի միջոցով: Բեռնված գործակալների բնութագրերը՝ բավարար թվով vCPU, RAM և Disk, կարելի է հաշվարկել՝ հիմնվելով այն փաստի վրա, որ գործակալի վրա պետք է գործարկվեն Docker-ը, Python-ը (Yandex.Tank-ի համար), GitLab CI գործակալը, Java-ն (Apache JMeter-ի համար): . JMeter-ի տակ գտնվող Java-ի համար խորհուրդ է տրվում նաև օգտագործել նվազագույնը 512 ՄԲ RAM և, որպես վերին սահման, 80% հասանելի հիշողություն.

Այսպիսով, մեր փորձից ելնելով, խորհուրդ ենք տալիս օգտագործել առնվազն 4 vCPU, 4 ԳԲ օպերատիվ հիշողություն, 60 ԳԲ SSD բեռնման գործակալների համար: Ցանցային քարտի թողունակությունը որոշվում է բեռի պրոֆիլի պահանջների հիման վրա:

Մենք հիմնականում օգտագործում ենք բեռնման երկու աղբյուր՝ Apache JMeter և Yandex.Tank docker պատկերներ։

Yandex.Tank բաց կոդով գործիք է Yandex-ից բեռնվածության փորձարկման համար: Դրա մոդուլային ճարտարապետությունը հիմնված է Phantom-ի բարձր արդյունավետության ասինխրոն հիթային HTTP հարցումների գեներատորի վրա: Տանկն ունի SSH արձանագրության միջոցով փորձարկման ենթակա սերվերի ռեսուրսների ներկառուցված մոնիտորինգ, կարող է ավտոմատ կերպով դադարեցնել թեստը նշված պայմաններում, կարող է արդյունքները ցուցադրել ինչպես վահանակում, այնպես էլ գծապատկերների տեսքով, կարող եք միացնել ձեր մոդուլները: ֆունկցիոնալությունը ընդլայնելու համար: Ի դեպ, մենք օգտագործել ենք Tank-ը, երբ այն դեռ մեյնսթրիմ չէր: Հոդվածում «Yandex.Tank-ի և բեռների փորձարկման ավտոմատացում»կարող եք կարդալ պատմությունը, թե ինչպես ենք մենք դրա հետ բեռնվածության փորձարկում կատարել 2013 թվականին PT հավելվածի Firewall մեր ընկերության արտադրանքներից մեկն է:

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 թեստային հաշվետվություն:

Մեր ընկերությունում հեշտ օգտագործման համար, որպեսզի փորձարկողներն իրենք կարողանան փոխել և ավելացնել շրջակա միջավայրը, մենք հավաքել ենք GitLab CI-ում բեռնվածության աղբյուրների դոկերի պատկերները՝ հրապարակելով ներքին: docker ռեեստր Artifactory-ում. Սա թույլ է տալիս ավելի արագ և հեշտ միացնել դրանք խողովակաշարերում ծանրաբեռնվածության փորձարկումների համար: Ինչպես կատարել docker push դեպի ռեեստր GitLab CI-ի միջոցով - տես հրահանգներ.

Մենք վերցրել ենք այս հիմնական docker ֆայլը Yandex.Tank-ի համար.

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

Իսկ Apache JMeter-ի համար սա.

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

Ինչպես է աշխատում մեր շարունակական ինտեգրման համակարգը, կարող եք կարդալ հոդվածում «Զարգացման գործընթացների ավտոմատացում. ինչպես ենք մենք իրականացրել DevOps գաղափարները Positive Technologies-ում.

Կաղապար և խողովակաշար

Նախագծում առկա է բեռի փորձարկումների անցկացման կաղապարի օրինակ ցուցադրական բեռ: Մեջ readme ֆայլ Դուք կարող եք կարդալ կաղապարի օգտագործման հրահանգները: Ինքն ձևանմուշում (ֆայլ .gitlab-ci.yml) կան նշումներ այն մասին, թե ինչի համար է պատասխանատու յուրաքանչյուր քայլ:

Կաղապարը շատ պարզ է և ցույց է տալիս վերը նշված դիագրամում նկարագրված բեռնվածության փորձարկման երեք փուլերը՝ հաշվետվությունների պատրաստում, փորձարկում և հրապարակում: Սրա համար պատասխանատու փուլերը: Պատրաստել, փորձարկել և զեկուցել.

1. Փուլ Պատրաստել պետք է օգտագործվի փորձարկման թիրախները նախապես կազմաձևելու կամ դրանց հասանելիությունը ստուգելու համար: Բեռնման աղբյուրների միջավայրը կարգավորելու կարիք չունի, դրանք նախապես կառուցված են որպես դոկերի պատկերներ և տեղադրվում են դոկերի ռեեստրում. պարզապես նշեք ցանկալի տարբերակը փորձարկման փուլում: Բայց դուք կարող եք վերակառուցել դրանք և ստեղծել ձեր սեփական փոփոխված պատկերները:
2. Փուլ փորձարկում օգտագործվում է բեռնվածքի աղբյուրը նշելու, թեստերը գործարկելու և փորձնական արտեֆակտները պահելու համար: Դուք կարող եք ընտրել ցանկացած բեռնման աղբյուր՝ Yandex.Tank, Apache JMeter, ձեր սեփականը կամ բոլորը միասին: Ավելորդ աղբյուրներն անջատելու համար պարզապես մեկնաբանեք կամ ջնջեք աշխատանքը: Բեռի աղբյուրների մուտքի կետեր.
   • Yandex.Tank-ի գործարկման պարամետրերը նշված են ./tests/yandextank.sh,
   • Apache JMeter-ի գործարկման պարամետրերը նշված են ֆայլում ./tests/jmeter.sh.

   Նշում. Հավաքման կազմաձևման ձևանմուշը օգտագործվում է CI համակարգի հետ փոխազդեցություն ստեղծելու համար և չի ենթադրում դրա մեջ թեստային տրամաբանության տեղադրում: Թեստերի համար նշվում է մուտքի կետը, որտեղ գտնվում է կառավարման bash սցենարը: Թեստերի գործարկման մեթոդը, հաշվետվություններ ստեղծելը և թեստային սցենարներն իրենք պետք է իրականացվեն QA ինժեներների կողմից: Դեմո տարբերակում, երկու բեռնման աղբյուրների համար, Yandex-ի գլխավոր էջի հարցումն օգտագործվում է որպես ամենապարզ թեստ: Սցենարները և փորձարկման պարամետրերը գրացուցակում են ./թեստեր.

3. Բեմում հաշվետվություն դուք պետք է նկարագրեք, թե ինչպես կարելի է հրապարակել թեստի արդյունքները, որոնք ստացվել են փորձարկման փուլում արտաքին պահեստներում, օրինակ՝ GitLab Pages-ում կամ հաշվետվությունների հատուկ համակարգերում: GitLab Pages-ը պահանջում է, որ ./public տեղեկատուը դատարկ չլինի և պարունակի առնվազն index.html ֆայլ՝ փորձարկումների ավարտից հետո: Դուք կարող եք կարդալ GitLab Pages ծառայության նրբությունների մասին: по ссылке.

   Տվյալների արտահանման օրինակներ.

   • JMeter-ից մինչև GitLab էջեր,
   • Yandex.Tank-ից մինչև InfluxDB և Grafana.

   Տեղադրման կարգաբերման հրահանգներ.

   • HTML ստատիկա մեջ GitLab էջեր,
   • դեպի InfluxDB և ապա դեպի Գրաֆանա.

Դեմո օրինակում բեռնման փորձարկումներով և երկու բեռնման աղբյուրներով խողովակաշարը (կարող եք անջատել ավելորդը) այսպիսի տեսք ունի.

Apache JMeter-ը կարող է ինքնուրույն ստեղծել HTML հաշվետվություն, ուստի ավելի շահավետ է այն պահել GitLab էջերում՝ օգտագործելով ստանդարտ գործիքներ: Ահա, թե ինչպես է Apache JMeter զեկույցը նման.

Yandex.Tank-ի ցուցադրական օրինակում դուք միայն կտեսնեք կեղծ տեքստային հաշվետվություն GitLab Pages բաժնում: Փորձարկման ընթացքում Tank-ը կարող է արդյունքները պահել InfluxDB տվյալների բազայում, և այնտեղից դրանք կարող են ցուցադրվել, օրինակ, Grafana-ում (կոնֆիգուրացիան կատարվում է ֆայլում ./tests/example-yandextank-test.yml) Ահա թե ինչպես է Թանկի զեկույցը նայում Grafana-ում.

Ամփոփում

Հոդվածում ես խոսեցի «բեռնվածության թեստավորում որպես ծառայություն» հասկացության մասին (բեռնվածության թեստավորումը որպես ծառայություն): Հիմնական գաղափարն է օգտագործել բեռնման գործակալների նախապես կազմաձևված լողավազանների ենթակառուցվածքը, բեռնման աղբյուրների դոկերի պատկերները, հաշվետվությունների համակարգերը և խողովակաշարը, որը միավորում է դրանք GitLab CI-ում պարզ .gitlab-ci.yml ձևանմուշի հիման վրա (օրինակ по ссылке) Այս ամենը աջակցվում է ավտոմատացման ինժեներների փոքր թիմի կողմից և կրկնօրինակվում է արտադրանքի թիմերի խնդրանքով: Հուսով եմ, որ սա կօգնի ձեզ պատրաստել և իրականացնել նմանատիպ սխեմա ձեր ընկերությունում: Շնորհակալություն ուշադրության համար!

Հ.Գ. Ուզում եմ մեծ շնորհակալություն հայտնել իմ գործընկերներին՝ Սերգեյ Կուրբանովին և Նիկոլայ Յուսևին, մեր ընկերությունում բեռնվածության թեստավորման հայեցակարգի իրականացման համար տեխնիկական աջակցության համար:

Հեղինակ: Թիմուր Գիլմուլլին - Պատգամավոր Positive Technologies-ի տեխնոլոգիաների և զարգացման գործընթացների (DevOps) ղեկավար

Source: www.habr.com