Apache JMeter — საწყისები: რა და როგორ

სანამ გადავალთ უშუალოდ JMeter-ის დაყენებაზე და საბაზისო ტესტებზე, გავარკვიოთ:

რა არის JMeter?
Apache JMeter არის open-source, Java-ზე შექმნილი(დაწერილი, აწყობილი, როგორც გაგიხარდებათ :)) ინსტრუმენტი.
ძირითადად გამოიყენება web აპლიკაციების performance და functional ტესტირებისთვის.

კარგი ინსტრუმენტი დატვირთვის სიმულაციისა და აპლიკაციის ქცევის დაკვირვებისთვის. JMeter შესაძლებელს ხდის უზარმაზარი რაოდენობის request-ის (განსხვავებული მომხმარებლების/requeste-ების/განმეორებადობის გათვალისწინებით) გაგზავნას და response-ის მიღება/შენახვას.

რატომ JMeter?

1. უფასოა და აქვს მარტივი ინტერფეისი;
2. სრულდება როგორც სტატიკური, ასევე დინამიური performance ტესტები.
   სტატიკურის მაგალითი: HTML და JavaScript.
   დინამიური — JSP, Servlets, და AJAX
3. Load Testing and Stress Testing.
   ერთერთი საუკეთესოა ჩვენი თემის ირგვლივ გამოსაყენებელ ინსტრუმენტებს შორის, რადგანაც იყენებს მინიმალურ რესურსს(განსაკუთრებით command line-დან გაშვების შემთხვევაში). იდეალურია დიდი მასშტაბის ტესტირებისთვის
4. Framework
   მოქნილი და გათვლილი როგორც ერთდროულად რამდენიმე ტესტის გაშვებაზე, ასევე პარალელური ტესტირებისთვის
5. დახვეწილი და მოქნილი რეპორტინგი.
   ტესტების შედეგების შენახვა გრაფკების, ცხრილების, სიების სახით.
6. Platform Independent
   მუშაობს ყველა გარემოში სადაც ეშვება Java.

ახლა კი პრაქტიკა და მეტწილად პრაქტიკა 🙂

Apache JMeter-ის ინსტალირება

1. Apache JMeter-ის დაყენებამდე, მოწმდება არის თუ არა დაინსტალირებული Java: ბრძანება CMD-ში — “java -version”

თუმცა ყოველგვარი გართულების გარეშე, შევდივართ java.com-ზე და მოგვაქვს ბოლო ვერსია, რადგან თუ არ გაქვთ java, საბოლოოს მაინც აქ გიწევთ მოსვლა 🙂

2. შევდივართ jmeter.apache.org-ზე და ვტვირთავთ Binaries განყოფილებიდან apache-jmeter-5.5.zip-ს(ამ ეტაპზე უახლესი ვერსია)

3. ჩამოტვირთულ Zip-ს “გავშლით”(ამოვაარქივებთ) საქაღალდეში და გადავდივართ bin-ში

double click ფაილზე apache-jmeter-5.5\bin\jmeter.bat და ჩვენთვის უკვე ნაცნობ ფანჯარაში(cmd) დავინახავთ ფაილების ჩაწერის პროცესს რის შემდეგაც “ის ადგილზეა” 🙂

პირველი ტესტი — 1 და 100 გამარჯობა 🙂

JMeter-ში ნებისმიერი ტესტისთვის მინიმალური მოთხოვნაა დამატებული იყოს:

Test Plan(JMeter-ის გასხნისას გვხვდება ავტომატურად დამატებული, ცარიელი ტესტი სახელით Test Plan). შედარებისთვის ესაა მიწის ნაკვეთი სადაც უნდა ააშენოთ სახლი.

Thread group — ოპერაციების რაოდენობის, განმეორებადობის სამართავი ელემენტი. აქ წყდება რამდენჯერ, რა სიხშირით, რამდენი მომხმარებლის მიერ შესრულდეს ოპერაცის სიმულაციასთან გვექნება საქმე.

3 ყველაზე მნიშვნელოვანი პარამეტრი:

1. Number of Threads (users) — მომხმარებლების(სიმულირებული) რაოდენობა, რომლებიც შეასრულებენ ამ Tread-ში დამატებული მოქმედებებს
2. Ramp-up period (seconds) — დრო, რაც იქნება საჭირო ყველა მოთხოვნის შესასრულებლად. ზემოთ მოცემული screenshot-დან, ყველა ოპერაცია რაც უნდა შესრულდეს მოცემულ thread-ში, განხორციელდება 10 წამში.
   P.S. 0 წამი ნიშნავს მოწყობილობის/ქსელის მაქსიმუმის გამოყენებას, ანუ რაც შეუძლია device-ს, რომ გაგზავნოს მინიმალურ დროში. მაგალითად საჭიროა 100 000-ის გაგზავნა მინიმალურ დროში(strass test). აქ დრო დამოკიდებულია მხოლოდ მოწყობილობისა და ქსელის წარამდობაზე, შეიძლება ყველა ეს მოთხოვნა გაიგზავნოს 5 წამში ან უფრო მეტში/ნაკლებში.
3. Loop Count — ციკლების რაოდენობა. ისევ screen-დან: 5 მომხმარებელი აგზავნის თითო მოთხოვნას 3-ჯერ. ანუ გვექნება 15-ჯერ გამეორებული ოპერაცია.
   infinite აკეთებს უსასრულო ციკლს და ტესტი მუშაობს სანამ ჩვენ არ გავაჩერებთ პროცესს.
   P.S. infinite-სთან ფრთხილად, “უთო ჩართული არ დაგრჩეთ” 🙂

Sampler — მოქმედება/ოპერაცია/request, უშუალოდ რა უნდა მოხდეს Tread group-ის ფრგლებში. განვიხილოთ ყველაზე გამოყენებადი, HTTP Request

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

1. HTTP request — მოთხოვნის ტიპის (GET, POST, PUT, DELETE და ა.შ.)
   Performance Testing-ის დროს უმეტესწილად გამოიყენება GET და POST request-ები. ანუ იმ ტიპის ოპერაციები რაც გვაქვს request/response მოქმედებებში მომხმარებელთან(front-ზე) მონაცემების მისატანად.
2. Path — მისამართი სადაც უნდა გაიგზავნოს მოთხოვნა.
   აქ “basic” ჩანარში web server-ში ჩაშლილია პროტოკოლი, სერვერის სახელი და პორტი, თუმცა უმეტეს შემთხვევაში მარტივის პარამეტრების გატანაც შესაძლებელია path-ში და არ საჭიროებს ლინკის დაყოფას ცალკეულ ნაწილებად.

Listener — request/response-ის გამოტანა/ჩაწერა.
საბაზისო “View Results Tree” აჩვენებს ყოველ მოთხოვნას სათითაოდ, აბრუნებს შედეგს, აჩვენებს request-ის დეტალებს და response-ის ჩანაწერს. გამოტანილი ფაილების შენახვა შესაძლებელია “Write result to file” ველში არჩეულ ფაილში. უმეტესწილად გამოიყენება CSV ფორმატი.

ახლა კი პირველი 100 GET request მისამართიზე: https://reqres.in/api/users?page=2

ვიდეოში ჩანს ელემენტების დამატება(მაუსის მარჯვენა ღილაკით გამოსული მენიუდან) და ეშვება პირველი ტესტი 1 request-ის ფარგლებში. ვამოწმებთ რამდენად სწორად მუშაობს ყველაფერი და შემდეგ ვზრდით რაოდენობას. ამ შემთხვევაში ნაჩვენებია 10 მომხმარებლის მიერ გაგზავნილი GET 10-ჯერ, ჯამში 100 request, რომელიც ამოწმებს სიას კონკრეტული მისამართიდან.
ვიდეოში დამატებულია 2 Listener: Results in Table და Summary Report, რომლებიც აჩვენებს respose-ების დეტალებს(request-ის დრო, response-ის დრო, რომელი tread group-იდანაა გაგზავნილი და სხვა კონფიგურირებად მონაცემს)ცხრილის სახით და ტესტის შეჯამებას.

უკვე იცით როგორ გაჩნდეს თქვენთან JMeter და როგორ გააგზავნოთ განმეორებადი/სასურველი რაოდენობის request-ები.
ექსპერიმენტების ჩატარების დროა 🙂

P.S. JMeter არის საკმაოდ “საშიში” ინსტრუმენტია თუკი ვინმე გადაწყვეტს მის გამოყენებას რომელიმე კომპანიაზე ზიანის მიყენების მიზნით 🙂

მომდევნო სტატიაში: რეპორტინგი — უფრო მეტი Listener-ების შესახებ.

ავტორი: anri.phutkaradze