Apache JMeter — საწყისები: Assertion-ები

Performance Testing-ის მნიშვნელოვანი ნაწილის, მონაცემების შენახვის დროს პრინციპულად მნიშვნელოვანია ვალიდაცია, თუ რა response-ებთან გვაქვს საქმე.
მთავარი კითხვის, “რა არის ჩვენი მოლოდინი ან სასურველი შედეგი?” პასუხად რიგ შემთახვევებში აუცილებელია გაიზომოს ოპერაციების შედეგები.

მარტივი მაგალითი: გვაქვს 10 000 მომხმარებლიანი სია, რომლის გამოძახებაც უნდა მოხდეს წუთში 1 000-ჯერ და Load time-ის დასაშვები, მაქსიმალური ზღვარია 400ms.

Load ტესტის ფარგლებში წუთში 1 000 request-ზე, ყველა response დაბრუნდა code 200-ით. ანუ ყველაფერი “მწვანე”-ა (response-ები წარმატებული შედეგებითაა) და ერთი შეხედვით “გაიგზავნა, დაბრუნდა, არ ყოფილა შეფერხება”. თუმცა random-ად შემოწმებული რამდენიმე response-ში აღმოვაჩინეთ 400ms-ზე მაღალი response time.

სწორედ ასეთი შემთხვევებისთვის JMeter-ს გააჩნია ელემენტების გატეგორია “Assertions”.

რამდენიმე სიტყვით: რა ფუნქციას ასრულებს Assertion?
response-ების ვალიდაცია/ფილტრაცია. წინასწარ გაწერილი პირობების მიხედვით მოწმდება ჩვენი request-ების შედეგად მიღებული response-ები, თუ რამდენად ემთხვევა რეალურ მოთხოვნებს.

განვიხილოთ 3 ყველაზე ხშირად გამოყენებადი Assertion

Duration Assertion —მოწმდება response-ის დრო, რამდენად ჯდება გაწერილ მოთხოვნებში. Sempler-ზე გვაძლევს შეცდომას თუკი response-ის ხანრგძლიობა აღემატება წინასწარ მითითებულ დროს.

Response Assertion — მოწმდება შემდეგი პარამეტრები: Response text, Response code, Response Message, Response Headers, Request Headers, URL Sampled, Document (text), Request data.
ყველა პარამეტრისთვის გააჩნია 4 პირობა: Contains, Matches, Equals, Substring.

Size Assertion —Response-ის ზომის შემოწმება. თუ რა მოცულობისაა მიღებული პასუხი კონკრეტულ sampler-ზე.

პრაქტიკული ნაწილი კონკრეტული მაგალითის ჭრილში
GET request მომხმარებლების სიაზე მისამართიდან https://reqres.in/api/users?page=2.
სიმულაცია: 100 მომხმარებელი, 5 “წრე”-ზე 10 წამის განმავლობაში. ვნახოთ response-ები Duration Assertion-ით, სადაც მაქსიმალური დასაშვები დრო იქნება 150ms.

ტესტის შედეგად გაიგზავნა 500 request, რომელთაგან 33.4%-ზე დაბრუნებული Response-ების Load time იყოს 150ms-ზე მეტი.

კითვაზე: ამ შედეგს ვერ მივიღებდი ფილტრაციით შენახულ CV ფაილში?
პასუხი: ერთი პრაქტიკული მაგალითიც 🙂

ისევ GET Request და მისამართი https://reqres.in/api/users, მაგრამ ამჯერად გამოვიყენებთ Response Assertion-ს. მეორე გვერდის(წინა Link-ში პარამეტრად Page=2) ნაცვლად ვამოწმებთ 6 განსხვავებულ გვერდს. ჯამში 100 request.

Response Assertion-ში ვირჩევთ Test Response, contains და pattern-ში ვუთითებთ ტექსტის ნაწილს(ამ შემთხვევაში მომხმარებლების სიის მასივში აუცილებლად არის: {“id” ) რაც გვხვდება სასურველ შედეგში.

როგორც ტესტში გამოჩნდა მომხმარებლების სია მოცემულია გვერდებზე 0, 1, და 2. სხვა გვერდებზე არ გვხვდება ჩანაწერი {“id” და Response Assertion-ის მეშვეობით ეს response-ები “გაწითლდა”.
P.S. დაკვირგებული თვალი ვიდეოშ შეამჩნევს Thread Group-ს გარეთ Page Number ელემენტს. ამ და მსგავს ელემენტებს განვიხილავთ ერთერთ შემდეგ სტატიაში.

ზემოთ მოყვანილი ორი პრაქტიკული მაგალითის დამატებად:
Assertion-ებთან მუშაობისას მთავარი მომენტია ვიცოდეთ ზუტად რა განსხვავებაა ჩვენთვის სასურველ და არასასურველ შედეგს შორის. განსაკუთრებით საყურადღებაო Response Assertion-ის პარამეტრები.

რა გავიგეთ ამ სტატიიდან?

Load Testing-ის დროს დიდი რაოდენობის request-ებზე response-ების ფილტრაცია manual მეთოთოდით არის არაეფექტური და რიგ ემთხვევაბში შეუძლებელი. Apache JMeter-ის გამოყენებისას assertion-ები ყველაზე მნიშვნელოვანი ელემენტებია ტესტის შედეგის ანალიზისთვის.

ზოგადად, Performance testing-ში ერთერთი გადამწყვეტი მნიშვნელობის მოცემულობაა ერთმანეთისგან განსხვავებული request-ების გაგზავნა. ამავე სტატიაში მოცემული მეორე მაგალითის გამარტივება შესაძლებელია იყო ცვლადის შემოტანით. აქედან გამომდინარე, მომდევნო სტატიაში განხილული იქნება ცვლადები და ფუნქციები.

ერთმანეთს შევხვდებით მომდევო სერიაში 🙂