სანამ გადავალთ უშუალოდ JMeter-ის დაყენებაზე და საბაზისო ტესტებზე, გავარკვიოთ:
რა არის JMeter?
Apache JMeter არის open-source, Java-ზე შექმნილი(დაწერილი, აწყობილი, როგორც გაგიხარდებათ :)) ინსტრუმენტი.
ძირითადად გამოიყენება web აპლიკაციების performance და functional ტესტირებისთვის.
კარგი ინსტრუმენტი დატვირთვის სიმულაციისა და აპლიკაციის ქცევის დაკვირვებისთვის. JMeter შესაძლებელს ხდის უზარმაზარი რაოდენობის request-ის (განსხვავებული მომხმარებლების/requeste-ების/განმეორებადობის გათვალისწინებით) გაგზავნას და response-ის მიღება/შენახვას.
რატომ JMeter?
- უფასოა და აქვს მარტივი ინტერფეისი;
- სრულდება როგორც სტატიკური, ასევე დინამიური performance ტესტები.
სტატიკურის მაგალითი: HTML და JavaScript.
დინამიური — JSP, Servlets, და AJAX - Load Testing and Stress Testing.
ერთერთი საუკეთესოა ჩვენი თემის ირგვლივ გამოსაყენებელ ინსტრუმენტებს შორის, რადგანაც იყენებს მინიმალურ რესურსს(განსაკუთრებით command line-დან გაშვების შემთხვევაში). იდეალურია დიდი მასშტაბის ტესტირებისთვის - Framework
მოქნილი და გათვლილი როგორც ერთდროულად რამდენიმე ტესტის გაშვებაზე, ასევე პარალელური ტესტირებისთვის - დახვეწილი და მოქნილი რეპორტინგი.
ტესტების შედეგების შენახვა გრაფკების, ცხრილების, სიების სახით. - Platform Independent
მუშაობს ყველა გარემოში სადაც ეშვება Java.
ახლა კი პრაქტიკა და მეტწილად პრაქტიკა 🙂
Apache JMeter-ის ინსტალირება
- 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 ყველაზე მნიშვნელოვანი პარამეტრი:
- Number of Threads (users) — მომხმარებლების(სიმულირებული) რაოდენობა, რომლებიც შეასრულებენ ამ Tread-ში დამატებული მოქმედებებს
- Ramp-up period (seconds) — დრო, რაც იქნება საჭირო ყველა მოთხოვნის შესასრულებლად. ზემოთ მოცემული screenshot-დან, ყველა ოპერაცია რაც უნდა შესრულდეს მოცემულ thread-ში, განხორციელდება 10 წამში.
P.S. 0 წამი ნიშნავს მოწყობილობის/ქსელის მაქსიმუმის გამოყენებას, ანუ რაც შეუძლია device-ს, რომ გაგზავნოს მინიმალურ დროში. მაგალითად საჭიროა 100 000-ის გაგზავნა მინიმალურ დროში(strass test). აქ დრო დამოკიდებულია მხოლოდ მოწყობილობისა და ქსელის წარამდობაზე, შეიძლება ყველა ეს მოთხოვნა გაიგზავნოს 5 წამში ან უფრო მეტში/ნაკლებში. - Loop Count — ციკლების რაოდენობა. ისევ screen-დან: 5 მომხმარებელი აგზავნის თითო მოთხოვნას 3-ჯერ. ანუ გვექნება 15-ჯერ გამეორებული ოპერაცია.
infinite აკეთებს უსასრულო ციკლს და ტესტი მუშაობს სანამ ჩვენ არ გავაჩერებთ პროცესს.
P.S. infinite-სთან ფრთხილად, “უთო ჩართული არ დაგრჩეთ” 🙂
Sampler — მოქმედება/ოპერაცია/request, უშუალოდ რა უნდა მოხდეს Tread group-ის ფრგლებში. განვიხილოთ ყველაზე გამოყენებადი, HTTP Request
როგორც სტატიის დასაწყისში იყო ნახსენები, ინტერფესი მარტივი და ინტუიტიურია. ძირითადი/საბაზისო პარამეტრები რაც აუცილებელია პირველი სატესტო request-თვის:
- HTTP request — მოთხოვნის ტიპის (GET, POST, PUT, DELETE და ა.შ.)
Performance Testing-ის დროს უმეტესწილად გამოიყენება GET და POST request-ები. ანუ იმ ტიპის ოპერაციები რაც გვაქვს request/response მოქმედებებში მომხმარებელთან(front-ზე) მონაცემების მისატანად. - 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
