Բեռի փորձարկման հնարավորությունների մի փունջ միայն մեկ գործիքով
Իրերի փորձարկումը լի է հմայքով: Հատկապես, եթե մենք փորձարկում ենք մեր սեփական ստեղծագործությունը: Համենայն դեպս, ինչ-որ բան կոդավորելուց հետո մենք այն նախ ձեռքով փորձարկում ենք սովորական դեպքերի մի շարքով: Եթե այն լավ է աշխատում, ապա մենք ներկայացնում ենք կոդը։
Բայց կա մի պահ, երբ մենք պետք է համոզվենք, որ մենք կատարել ենք հուսալի ստեղծագործություն։ Ենթադրենք, որ այն լավ է աշխատում որոշակի վիճակում, ինչպես, որ մենք այն ձեռքով փորձարկել ենք: Այնուամենայնիվ, ինչպե՞ս կարող ենք համոզվել, որ մեր ծածկագիրը նույն կերպ է վարվում ցանկացած այլ պայմաններում, ինչպես օրինակ, երբ այն ռմբակոծվում է բազմաթիվ հարցումներով: Այն փորձարկելու ավելի լավ միջոց պետք է լինի՝ առանց ձեր ընկերներին խնդրելու, որ օգնեն ձեզ ձեռքով (և զուգահեռաբար) հարցումներ կատարել ձեր դիմումին: Բարեբախտաբար, կա: Մենք կսովորենք, թե ինչպես բեռնել մեր հավելվածը k6-ի միջոցով մի քանի պայմաններում:
Տեղադրում
K6-ը տեղադրելու մի քանի եղանակ կա՝ կախված ձեր օպերացիոն համակարգից կամ համակարգի միջավայրից: Բայց այս հոդվածում ես կանդրադառնամ միայն դրանցից երկուսին, Linux/Ubuntu-ին և Docker-ին:
Ուղղակի մեջբերված k6 փաստաթղթերից: Դուք կարող եք տեղադրել k6-ը Linux Ubuntu-ում՝ գործարկելով այս հրամանը ձեր տերմինալում.
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys C5AD17C747E3415A3642D57D77C6C491D6AC1D69 echo "deb https://dl.k6.io/deb stable main" | sudo tee /etc/apt/sources.list.d/k6.list sudo apt-get update sudo apt-get install k6
Docker-ի հետ ամեն ինչ մի փոքր ավելի հեշտ է դառնում: Դուք կարող եք տեղադրել այն՝ օգտագործելով այս հրամանը.
docker pull loadimpact/k6
Քանի որ Docker-ի օգտագործումը շատ ավելի հեշտ է դարձնում մեր կյանքը: Այս հոդվածում ես հաճախ կօգտագործեմ Docker-ը: Բայց էությունը դեռ նույնը կլիներ։ Ամբողջական բացատրությունը կարող եք գտնել այստեղ https://k6.io/docs/getting-started/installation/:
Հիմունքներ
Այս հոդվածի նպատակով ես կբեռնեմ իմ փորձնական նախագծերից մեկը: Բայց ես նաև կբացատրեմ API-ի մանրամասները, այնպես որ դուք դեռ կարող եք հետևել դրան:
Եթե ցանկանում եք ճշգրիտ հետևել այս հոդվածին, կարող եք գտնել այն հավելվածը, որը կփորձարկվի այստեղ: Հավելվածն ինքնին պարզ ֆինանսական մենեջեր է, որտեղ կարող եք գրանցվել, մուտք գործել, ստեղծել եկամուտների կամ ծախսերի կատեգորիաներ և գրել ձեր եկամուտը կամ ծախսը: Դուք մանրամասն տեղեկություններ կստանաք, թե ինչպես կարգավորել սերվերը readme ֆայլում:
Եկեք սկսենք փորձարկել բազային URL-ը: Ենթադրենք, որ հիմնական URL-ը http://localhost:3000 է և վերադարձնում է «Բարի գալուստ API» հաղորդագրություն: Թեստի սցենարը կլինի.
Նախ, մենք ներմուծեցինք կախվածությունը վերևում: Նկատի ունեցեք, որ հետին պլանում k6-ը չի աշխատում NodeJS-ում, քանի որ ընդհանուր առմամբ JavaScript-ը հարմար չէ բարձր կատարողականության համար։ Այն գրված է Go-ում՝ ցանկալի բարձր արդյունավետության թեստավորման հասնելու համար:
Փորձարկումն ինքնին աշխատում է արտահանված լռելյայն ֆունկցիայի ներսում: Կոդի այս հատվածն այն է, ինչ մենք սովորաբար անվանում ենք VU Code: Այսպիսով, թեստն անցկացվում է մեկ անգամ և լռելյայն օգտագործում է միայն մեկ վիրտուալ օգտատեր (կարծեք սա որպես իրական օգտատեր, բայց մոդելավորված), բայց դուք կարող եք փոխել այն՝ օգտագործելով options-ը: Մենք կխոսենք VU օրենսգրքի և տարբերակների մասին ավելի ուշ:
Եթե դուք բախվում եք ինչ-որ խնդրի, ինչպիսին է Docker-ն օգտագործելիս միացումը մերժվել է: Դուք պետք է փոխեք localhost-ը հոսթի IP հասցեին: Դուք կարող եք դա ստուգել՝ օգտագործելով docker inspect <container_id_or_name>-ը: Սովորաբար, հասցեի հոսթինգը ծառայության անվան իրական հասցեն է, երբ հղվում է: Կամ եթե դուք օգտագործում եք Linux համակարգ, կարող եք օգտագործել hostname -I: Դուք կստանաք 192.xxx.xxx.xx-ի նման մի բան: Այնուհետև localhost-ը փոխարինեք այդ IP հասցեով:
Այս թեստը կարող եք գործարկել՝ գործարկելով հրամանը.
// CLI k6 run script.js // Docker docker run -i loadimpact/k6 run - <script.js
Դուք անմիջապես կտեսնեք թեստի արդյունքը տերմինալում: Սրա նման մի բան.
Տեսեք, որ եթե մենք տարբերակներ չենք տրամադրում այս թեստի համար, այն կաշխատի մեկ անգամ և օգտագործում է միայն մեկ վիրտուալ օգտվող: Ներքևում գտնվող մի շարք թվեր կան ներկառուցված չափումներ, ինչպիսիք են data_received, http_req_duration, http_req_failed, vus և այլն: Օրինակ՝ http_req_failed-ը ձախողված հարցումների ցուցանիշն է՝ ըստ setResponseCallback: Լռելյայնորեն 200-ից 399-ի կարգավիճակի կոդերով հարցումները համարվում են սպասված: Մենք կտեսնենք, թե ինչպես կատարել անհատական չափումներ ավելի ուշ:
Կյանքի ցիկլ
Թեստի չորս փուլ կա. Առաջինը init է, այնուհետև setup, VU և teardown:
Ընդհանուր առմամբ, օրինաչափությունն այսպիսին է
init կոդը գործում է յուրաքանչյուր վիրտուալ օգտագործողի համար մեկ անգամ: Կարելի է մտածել, որ վիրտուալ օգտատերը նման է իրական օգտատիրոջը: Բայց դա սիմուլյացված է, և նրանք բոլորն անում են նույն բանը, նրանց վարքագիծը սահմանվում է լռելյայն ֆունկցիայի ներսում (VU Code): Դուք կարող եք ներմուծել մոդուլներ այստեղ՝ հետագայում օգտագործելու համար setup, VU կամ teardown ներսում:
setup-ը և teardown-ը գրեթե նույնն են, ինչ ցանկացած այլ փորձարկման գործիքում: Դրանք ձեզ պետք կգան, եթե ցանկանում եք ինչ-որ բան անել թեստի ավարտից առաջ և հետո: setup-ը կոչվում է init-ից հետո, բայց VU-ից առաջ, իսկ teardown_ը կանչվում է վերջին VU կրկնությունից հետո:
Այնուհետեւ մենք ունենք VU կոդը: Մենք այստեղ սահմանել ենք վիրտուալ օգտատիրոջ վարքագիծը. զանգահարելով API, ստուգելով, թե արդյոք ստացված պատասխանը ճիշտ է, արդյունքը պահելով չափման մեջ և այլն: Հիմնականում այս բաժինն այն է, որտեղ տեղի է ունենում իրական փորձարկումը: Այն աշխատում է ցիկլով յուրաքանչյուր վիրտուալ օգտագործողի համար սահմանված տևողության կամ փուլերի համար (Դուք կարող եք սա կարգավորել ընտրանքներում)
Իրական թեստեր
Այս բաժնում մենք կխոսենք իրական փորձարկման իրականացման տարբերակների, չափումների, շեմերի և կյանքի ցիկլի մասին:
Սկսեք տեղադրման գործառույթից:
Կարգավորման այս գործառույթում մենք գրանցում ենք մեր կեղծ օգտագործողին, այնուհետև մուտք ենք գործում մուտքի նշան ստանալու համար: Քանի որ բոլոր API-ները, որոնք մենք ցանկանում ենք ավելի ուշ փորձարկել, պաշտպանված են նույնականացման միջին ծրագրով:
Նախքան եկամուտների կամ ծախսերի պատմություն կազմելը, մենք պետք է ստեղծենք դրա կատեգորիաները, օրինակ՝ գնումներ, ներդրումներ, հարկեր և այլն:
Այն բանից հետո, երբ մենք ստանում ենք նշանը (ներառյալ id-ը և ցուցադրման էլեկտրոնային փոստը) և նոր ստեղծված եկամուտների/ծախսերի տեսակները, այնուհետև մենք կարող ենք վերադարձնել այս արժեքները: Այսպիսով, այն կարող է օգտագործվել ավելի ուշ՝ փորձարկվելիք API մուտք գործելու համար:
Նկատի ունեցեք, որ մենք պետք է խստացնենք ծանրաբեռնվածությունը և տրամադրենք պարամների բովանդակության տիպի JSON, հակառակ դեպքում լռելյայնորեն ուղարկվող տվյալները կլինեն ձևա-տվյալների ձևաչափով:
Հաջորդը քայքայման գործառույթն է:
Թուլացման գործառույթը համեմատաբար պարզ է: Այն, ինչ մենք անում ենք այստեղ, ներարկված աղյուսակի կրճատումն է, որպեսզի այն հետագայում օգտագործվի թեստավորման հաջորդ նիստի համար: Բայց տվյալների բազան մաքրելու համար մեզ անհրաժեշտ է մուտքի նշան: Բարեբախտաբար, մենք դա ունենք տվյալների օբյեկտի ներսում:
Այժմ ժամանակն է փորձարկել հիմնական API-ները:
Լավ, մենք նոր բան ունենք այստեղ: Ինչպես ասացի, մենք կանդրադառնանք ընտրանքներին և չափորոշիչներին: Նկատի ունեցեք, որ ես բաց թողեցի տեղադրման և անջատման գործառույթները, դրանք դեռ կան իրական թեստային սցենարի ֆայլում:
Նախ, մենք ունենք տարբերակներ.
vus. վիրտուալ օգտագործողների առավելագույն քանակը, որոնք պետք է մոդելավորվենduration՝ թեստի տևողությունըthresholds՝ թեստի չափանիշներ
Մենք ասում ենք, որ թեստն անցնում է, եթե թեստի արդյունքը դեռ գտնվում է մեր սահմանված շեմերի սահմաններում։ Վերոնշյալ օրինակից, HTTP հարցումների բոլոր տևողությունները պետք է լինեն 2 վայրկյանից ցածր 75%-ով: Եթե ոչ, ապա թեստը կդադարեցվի:
Ակնհայտ է, որ կան ավելի շատ տարբերակներ, որոնք կարող եք օգտագործել: Ամբողջական ցանկը կարող եք ստանալ այստեղ:
Հաջորդը՝ check ֆունկցիան: Նայելով 46-ից 49-րդ տողերին՝ կարո՞ղ եք գուշակել, թե ինչ է դա անում: Այո, դա որոշ պահանջներ ստուգելու մասին է: Եթե վերադարձված պատասխանը հաջողված չէ, և HTTP զանգի տևողությունը 2 վայրկյանից բարձր է, ապա ստուգումները ձախողվելու են: Արդյունքը, որը դուք կստանաք, նման կլինի.
Տեսեք, որ 298 ստուգումները ձախողվել են, ինչը նշանակում է, որ HTTP հարցման տևողությունը 2 վայրկյանից ավելի է տևում:
Ինչպես գիտեք, թեստն ավարտելուց հետո մենք ստանում ենք արդյունքը։ Ինչպիսիք են http_req_duration, http_req_failed, http_req_waiting և այլն: Սրանք ներկառուցված չափումներ են, բայց դուք կարող եք նաև կատարել ձեր սեփական չափումները՝ օգտագործելով Trend և Rate (կան նաև Gauge և Counter):
6-րդ և 7-րդ տողերում մենք օրինակ ենք բերել չափումները և տվել նրանց անունները: Այնուհետև 52 և 56 տողերում մենք ավելացնում ենք HTTP հարցման տևողության արդյունքը Rate և Trend-ին: Բայց սպասե՛ք։ Որոնք են տոկոսադրույքը և միտումը:
Դրույքաչափը ավելացված արժեքների տոկոսն է, որոնք զրոյական չեն: Պատկերացրեք այնպես, ինչպես երբ գումարում եք զրո կամ մեկ թիվ: Եթե կրկնում եք՝ ավելացնելով այս պատահական թիվը օղակի մեջ, ապա արդյունքը բաժանում եք օղակների թվի վրա: Ապա դուք ստանում եք տոկոսադրույքը:
Մինչդեռ Trend-ը նման է թեստի վիճակագրությանը։ Այն ձեզ տալիս է միջինը, նվազագույնը, առավելագույնը և տոկոսը:
Բեռնման փորձարկման տատանումներ
Այս բաժնում մենք կխոսենք ծանրաբեռնվածության թեստերի որոշ տատանումների մասին, դրանք են՝ բեռնվածության փորձարկումը, ծխի փորձարկումը, սթրեսի թեստը, ցցերի փորձարկումը և ներծծման փորձարկումը:
Բեռնման փորձարկում
Այն, ինչ մենք արել ենք մինչ այժմ, բեռնվածության փորձարկումն է: Որովհետև մենք ցանկանում ենք գնահատել մեր համակարգի աշխատանքը: Սովորաբար, մեզ անհրաժեշտ է բեռնվածության փորձարկում՝ որոշելու համար, թե մեր համակարգը ինչպես կվարվի երկու պայմաններում՝ նորմալ և առավելագույն երթևեկության պայմաններում: Նաև բավականին սովորական է շարունակաբար կատարել բեռնվածության փորձարկում՝ համոզվելու համար, որ մեր համակարգի կատարումը դեռևս ցանկալի արժեքի սահմաններում է:
Ընդհանրապես, դուք միայն պետք է փոխեք options-ը՝ բեռնվածության փորձարկման տատանումները կատարելու համար: Օրինակ, options-ը, որը ձեզ հարկավոր է, նման բան է.
stages-ի մասին մինչև հիմա չենք խոսել: stages-ը նման է նախատեսված տրաֆիկի: Օրինակ, 5 րոպեի ընթացքում կա ընդամենը 100 օգտվող: Այնուհետև հաջորդ 10 րոպեների ընթացքում այն մնում է 100 օգտագործողների մեջ: Վերջապես, այն իջնում է մինչև 0 օգտվող՝ վերականգնումը մոդելավորելու համար:
Ծխի փորձարկում
Թեստային սցենար գրելիս կլինեն առողջական վիճակի ստուգումներ: Արդյո՞ք թեստի սցենարն արդեն ճի՞շտ է: Արդյո՞ք նա անում է այն, ինչ մենք ուզում ենք:
Ակնհայտ է, որ դուք չեք ցանկանում սահմանել թեստի տևողությունը մեկ ժամ, երբ գրում եք ձեր թեստային սցենարը: Պարզապես ժամանակ է վատնում մեկ ժամ սպասելու համար, որպեսզի տեսնենք, թե արդյոք մենք ճիշտ թեստային սցենար ենք գրում:
Ահա թե ինչու, ընդհանուր առմամբ, options ծխի փորձարկման համար այսպիսին կլիներ
Դուք պետք է նվազագույնի հասցնեք օգտագործողների թիվը և տևողությունը:
Սթրեսի թեստավորում
Ենթադրենք, որ դուք աշխատում եք էլեկտրոնային առևտրի ընկերությունում և ցանկանում եք իմանալ, թե ինչպես է ձեր համակարգը վարվում մեծ վաճառքի թրաֆիկի պայմաններում: Այն, ինչ դուք պետք է անեք, ձեր համակարգի վրա սթրես-թեստավորումն է:
Երբ դուք սթրես-թեստավորում եք անում, դուք դուրս կգաք ձեր սովորական տրաֆիկից: Այսպիսով, անշուշտ ռիսկային է սթրես-թեստավորում կատարել արտադրական միջավայրում: Լավ է այն փորձարկել ձեր տեղական մեքենայի կամ բեմադրության միջավայրում:
Spike Testing
Spike-ի թեստը նման է սթրես-թեստավորմանը, մենք ցանկանում ենք փորձարկել մեր համակարգը ծայրահեղ պայմաններում: Տարբերությունը կայանում է նրանում, որ սթրես-թեստավորումն անցնում է ավելի երկար փուլերով՝ թիրախը բարձրացնելու համար, հասկի թեստը պարզապես անցնում է մինչև ծայրահեղ վիճակ: Երթևեկության հանկարծակի աճի մոդելավորում:
Ներծծում փորձարկում
Soak-ի փորձարկումը երկարաժամկետ ժամանակահատվածում գնահատում է համակարգի հուսալիությունը: Ներծծման թեստը բացահայտում է աշխատանքի և հուսալիության խնդիրները, որոնք բխում են համակարգի երկար ժամանակ ճնշման տակ գտնվելուց:
Հուսալիության խնդիրները սովորաբար կապված են վրիպակների, հիշողության արտահոսքի, պահեստավորման անբավարար քվոտաների, սխալ կազմաձևման կամ ենթակառուցվածքի խափանումների հետ: Արդյունավետության խնդիրները սովորաբար կապված են տվյալների բազայի սխալ կարգավորման, հիշողության արտահոսքի, ռեսուրսների արտահոսքի կամ մեծ քանակությամբ տվյալների հետ:
Եզրակացություն
K6-ում ավելին կա, քան մենք խոսել ենք այս հոդվածում: Կան շատ տարբերակներ, որոնք կարող եք օգտագործել, սցենարներ, եթե Ձեզ անհրաժեշտ է առաջադեմ օգտատիրոջ վարքագիծ, թեստի արդյունքը պահել CSV կամ JSON ֆայլում, ունենալ ցուցատախտակ՝ ներկայացման համար և այլն:
Ես կասեի, որ k6 փաստաթղթերը հեշտ է նավարկելու և հասկանալի: Մեզ համար ամեն ինչ կոկիկ գրված է։ Այսպիսով, մի հապաղեք ուղղակիորեն կարդալ պաշտոնական փաստաթղթերը:
Ի վերջո, ես միշտ խոսել եմ այս մասին, երբ խոսում էի ներկայացման մասին: Մենք չպետք է կատարողականի ճշգրտումներ կատարենք նախքան ծածկագրի ամբողջական գործարկումը: Նախ համոզվեք, որ կոդը մաքուր է և պահպանելի, այնուհետև ժամանակն է շտկելու և ավելի լավ լուծումներ գտնելու արդյունավետությունը բարելավելու համար: Հակառակ դեպքում, ինչպես ասաց Դոնալդ Կնուտը, մենք կհայտնվենք վաղաժամ օպտիմալացման թակարդում:
Ամբողջական թեստային սցենարը կարող եք ունենալ այստեղ՝ https://github.com/agusrichard/javascript-workbook/tree/master/k6-article-material
Շնորհակալություն ընթերցանության և ուրախ փորձարկման համար:
