ვფიქრობ ამ ეტაპზე ქართულ “IT სივრცეში“ QA, განსაკუთრებით Performance testing ახალია და ამ სტატიით დამწყებებს მინიმუმ შეექმნებათ წარმოდგენა, თუ „რა ხდება ჩვენს თავს“ 😊
უშუალოდ საკითხის განხილვამდე, პატარა შესავალი:
10+ და უფრო ზუსტად, ამ ეტაპისთვის 12 წლიანი სამუშაო გამოცდილების ფონზე ყველაზე ხშირი მოთხოვნა ყველაფრის მიმართ იყო: „მთავარია იმუშაოს გამართულად“.
ანუ, უმეტესად დამკვეთი კმაყოფილია პროდუქტით (არ აქვს მნიშვნელობა კომპლექსური საიტია, 1 გვედრი თუ excel-ში გამოყენებული მარტივი ფუნქცია), რომელიც მისთვის, როგორც მომხმარებლისთვის მუშაობს ისე, როგორც წარმოედგინა იდეის დონეზე. თუმცა რეალურ გარემოში, სადაც მომხმარებლებისა და მათ მიერ გამოგზავნილი request-ების რაოდენობა იზრდება, ხშირად „კი, მზადაა და გავუშვათ“ პროდუქტი ვერ მუშაობს ისე, როგორც ეს იყო ჩვენთან(ერთ მომხმარებელთან, ჩვენივე წარმოდგენით ნორმალურ პირობებში).
ახლა კი ამ სტატიის სათაურიდან:
Performance testing — არის ტესტირების ტიპი, რომელიც ფოკუსირებულია დაადგინოს, როგორ მოიქცევა სისტემა დატვირთვის დროს. ეს არაა ტესტირება, სადაც ხდება ბაგებისა და დეფექტების ძება. ტესტირების ამ მეთოდით ჩვენ გვექმნება წარმოდგენა თუ რა არის მიმდინარე ეტაპზე სისტემის მაქსიმუმი, რა დატვირთვაზე მუშაობს გამართულად და როდის იწყება შეფერხებები ან ითიშება გარკვეული სერვისები, სადაა სუსტი წერტილები.
მთავარი ამოცანაა გაიზომოს სისტემის შესაძლებლობები და დეველოპმენტის ეტაპზე მოხდეს მისი ოპტიმიზაცია performance-ის კუთხით.
ძირითადი კითხვები, რაზეც უნდა გვქონდეს პასუხი:
- Reliability: რამდენად ხშირად მივდივართ error-მდე და რა იცვლება დატვირთვის შემთხვევაში?
- Stability: რა მოსდის RAM და CPU-ს, როგორ მუშაობს ქსელი?
- Response time: AVG, რა დროში ბრუნდება პასუხები?
- Scalability: რა ხდება სხვადასხვა დატვირთვის დროს?
თავის მხვრივ Performance testing, იყოფა 6(სხვადასხვა სტატიაში/გუნდში 7+) ტიპად.
ძირითადი განსხვავება და იდეოლოგიურად გაერთიანება შეიძლება 2 მიმართულებაში:
Load testing და Stress testing.
მათთვის ვისაც გაუჩნდებოდა კითხვა: დანარჩენი არაა მნიშვნელოვანი?
პასუხია: Spike testing, Endurance testing, Scalability testing, Volume testing — არის სხვადასხვა მიდგომა, რომელიც ითვალისწინებს დატვირთვის განსხვავებულად ცვლილებას.
მაგალითად Spike testing არის Stress test-ის ვარიანტი, როცა ხდება request-ების რაოდენობის სწრაფი ზრდა და განმეორებადობა. უფრო მარტივ ენაზე DoS და DDoS შეტევების მოდელირება.
მოკლე აღწერა თუ რა სხვაობაა Load და Stress ტესტებს შორის:
Load testing — ეს არის პროექტის ფარგლებში მოლოდინის მიხედვით დატვირთვის სიმულაცია და დაკვირვება თუ რამდენად გამართულად იმუშავებს ყველა კომპონენტი.
მაგალითი: ბილეთების შეძენის გვერდი, სადაც გათვლილია 1 წუთში 100 მომხმარბელის შემოსვლა.
ამ შემთხვევაში იტესტება ყველა კომპონენტი და სერვისი, რომელიც პასუხისმგებელია ყველა ეტაპზე გვერდის ჩატვირთვიდან ბილეთის ყიდვის ჩათვლით. გვერდის ჩატვირთვის სიჩქარე, შესაბამისი ფორმის ყველა ველის შევსებისას შესაბამისი request-ები და response time, ფორმის გაგზავნის request და ა.შ. — ეს ყველაფერი X100, განაწილებული 1 წუთის ინტერვალზე.
რა ტიპის პრობლემას შეიძლება წავაწყდეთ და როგორ მოვაგვაროთ ეს საკითხი პროდუქტის გაშვებამდე?
ერთი კონკრეტული შემთხვევა: თუ მომხმარებლის პირადი ნომრის შესავსები ველი ამოწმებს უნიკალურობას და შეკვეთის ფორმაში ეს ველი აუცილებელია, ბილეთის ყიდვა იქნება შეუძლებელი. ანუ, უშუალოდ ფორმის გაგზავნის სერვისი მუშაობს, ბილეთის გაყიდვის სერვისს არ აქვს შეფერხება, მაგრამ მაგ ეტაპამდე პირადი ნომრის ველის ხარვეზი აფერხებს პროცესს.
რა დასკვნამდე მივყავვართ ამ ტესტს?
— სტანდარტული QA პროცესის პირობებში, ფუნქციონალი იყო გამართული, ყველა კომპონენტი დამოუკიდებლად და ერთიანობაში მუშაობდა, ვიზუალები, ფუნქციური ნაწილი იყო გამართული 1 კონკრეტული QA თანამშრომლისთვის, მაგრამ როცა დადგა მომენტი და საჭირო გახდა წუთში 100 მომხმარებლის პირადი ნომრის შემოწმება, ზოგადად ბილეთების ყიდვა გაჩერდა.
Stress testing — ტესტირების ვარიანტი, როცა მოწმდება რა მოუვა სერვისებს იმ შემთხვევაში თუკი იქნება იმაზე მეტი request, ვიდრე ეს არის მოსალოდნელი პროექტის ფარგლებში. რა ტიპის შეფერხებებს ექნება ადგილი და როდის გაჩერდება/აღდგება სერვისები პერიოდული ან უწყვეტი stress-ის დროს.
მაგალითი ისევ ბილეთების შესყიდვაზე:
100 მომხმარებელი 1 წუთში შედის გვერდზე, ყიდულობს ბილეთს და ეს დატვირვა არ ქმნის არავითარ პრობლემას. მაგრამ მოხდება თუკი იგივე პირადი ნომრის შემოწმებაზე გაიგზავნება 10 000 request?
რამდენიმე ვერსია: ეტაპობრივად გაიზრდება response time, აღარ დაბრუნდება პასუხი, დაბრუნდება არასწორი error(ეს დამოკიდებულია იმაზე თუ რა ტიპის მესიჯები იქნება გათვალისწინებული დეველოპმენტის დროს). ამ კონკრტული შემთხვევის თავიდან ასაწილებლად არსებობს უამრავი მეთდი, მათ შორის:
Backed არ ატარებს დუბლირებულ (ეს ძაან პრიმიტიული ვარიანტი) request-ებს და აბრუნებს მაგალითაც Error Code 429-ს(too many requests) და მაგის შემდეგ მნიშვნელობა აღარ აქვს რა რაოდენობის request იგზავნება(სისტემა აღარ იტვირთება).
ქსელის დონეზე ხდება არ ტარდება დუბლირებული request-ები(საუბარია payload-ზე), არ გადის ერთი კონკრეტული მისამართიდან გარკვეულ რაოდენობაზე მეტი request გარკვეული დროის ინტერვალში.
თუ საუბარია Front-დან დატვირთვაზე(იშვიათად, ეს უფრო Load-ის მიმართულებაა. მომხმარებლების დიდი რაოდენობის ან არანორმალური ქცევის შემთხვევაში) და არა პირდაპირი request-ები კონკრტულ მისამარტებზე, შეიძლება გაკეთდეს ხელოვნური დაყოვნება. მაგალითისთვის ღილაკი გახდეს არააქტიური რამდენიმე წამით, ყოველი click-შემდეგ.
შეჯამება: Performance testing — არის რეალური/შესაძლო გარემოს სიმულაცია დიდი რაოდენობის request-ებით, სადაც მნიშვნელოვანია: ტესტირების დაგეგმარება, მონაცემების შენახვა და ანალიზი.
ამ ყველაფრისთვის არსებობს უამრავი ხელსაწყო(tool), მათ შორის: LoadNinja, Apache JMeter, WebLOAD და ა.შ.
მომდევნო სტატიაში განხილული იქნება პრაქტიკული ნაწილი. Performance testing-ის საწყისები Apache JMeter-ის გამოყენებით.
„Apache JMeter — საწყისები: რა და როგორ“ 😊
ავტორი: anri.phutkaradze
