ჩატვირთეთ ტესტირება, როგორც CI სერვისი დეველოპერებისთვის

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

იმის ნაცვლად, რომ შეასრულონ თავიანთი პირდაპირი მოვალეობები და გამოიყენონ თავიანთი უნიკალური გამოცდილება დატვირთვის ტესტირების პროცესის შესაქმნელად, აირჩიონ მეთოდოლოგია, ოპტიმალური მეტრიკა და ჩაწერონ ავტოტესტები დატვირთვის პროფილების შესაბამისად, ინჟინრებს ხშირად უწევთ სატესტო ინფრასტრუქტურის ნულიდან განლაგება, დატვირთვის ხელსაწყოების კონფიგურაცია და მათი ჩასმა. თავად CI სისტემებში, დააწესეს მონიტორინგი და ანგარიშების გამოქვეყნება.

თქვენ შეგიძლიათ იპოვოთ ზოგიერთი ორგანიზაციული პრობლემის გადაწყვეტა ტესტირებისას, რომლებსაც ჩვენ ვიყენებთ პოზიტიურ ტექნოლოგიებში სხვა სტატია. და ამ ერთში მე ვისაუბრებ დატვირთვის ტესტების ინტეგრირების შესაძლებლობაზე საერთო CI მილსადენში "ჩატვირთვის ტესტირების როგორც სერვისის" კონცეფციის გამოყენებით (ჩატვირთვის ტესტირება როგორც სერვისი). თქვენ შეიტყობთ, თუ როგორ და რომელი დოკერის გამოსახულება შეიძლება გამოყენებულ იქნას დატვირთვის წყაროების CI მილსადენში; როგორ დააკავშიროთ დატვირთვის წყაროები თქვენს CI პროექტს build შაბლონის გამოყენებით; როგორ გამოიყურება დემო მილსადენი დატვირთვის ტესტების გასაშვებად და შედეგების გამოქვეყნებისთვის. სტატია შეიძლება სასარგებლო იყოს პროგრამული უზრუნველყოფის ტესტირების ინჟინრებისთვის და CI-ში ავტომატიზაციის ინჟინრებისთვის, რომლებიც ფიქრობენ თავიანთი დატვირთვის სისტემის არქიტექტურაზე.

კონცეფციის არსი

დატვირთვის ტესტირების კონცეფცია, როგორც სერვისი, გულისხმობს დატვირთვის ინსტრუმენტების Apache JMeter, Yandex.Tank და თქვენი საკუთარი ჩარჩოების ინტეგრირების შესაძლებლობას თვითნებურ უწყვეტ ინტეგრაციის სისტემაში. დემო იქნება GitLab CI-სთვის, მაგრამ პრინციპები საერთოა ყველა CI სისტემისთვის.

დატვირთვის ტესტირება, როგორც სერვისი, არის ცენტრალიზებული სერვისი დატვირთვის ტესტირებისთვის. ჩატვირთვის ტესტები ტარდება სპეციალურ აგენტურ აუზებში, შედეგები ავტომატურად ქვეყნდება GitLab Pages-ში, Influx DB-სა და Grafana-ში ან ტესტის მოხსენების სისტემებში (TestRail, ReportPortal და ა.შ.). ავტომატიზაცია და მასშტაბირება ხორციელდება რაც შეიძლება მარტივად - GitLab CI პროექტში ჩვეულებრივი gitlab-ci.yml შაბლონის დამატებით და პარამეტრიზაციით.

ამ მიდგომის უპირატესობა ის არის, რომ მთელი CI ინფრასტრუქტურა, დატვირთვის აგენტები, დატვირთვის წყაროების დოკერის სურათები, ტესტირების მილსადენები და ანგარიშების გამოქვეყნება ინახება ცენტრალიზებული ავტომატიზაციის დეპარტამენტის მიერ (DevOps ინჟინრები), ხოლო დატვირთვის ტესტირების ინჟინრებს შეუძლიათ თავიანთი ძალისხმევა ტესტის განვითარებაზე გაამახვილონ. და მათი შედეგების ანალიზი, ინფრასტრუქტურული საკითხების გარეშე.

აღწერის სიმარტივისთვის, ჩვენ ვივარაუდებთ, რომ ტესტირებადი სამიზნე აპლიკაცია ან სერვერი უკვე განლაგებულია და კონფიგურირებულია წინასწარ (ამისთვის შეიძლება გამოვიყენოთ ავტომატური სკრიპტები Python-ში, SaltStack-ში, Ansible-ში და ა.შ.). შემდეგ დატვირთვის ტესტირების მთელი კონცეფცია, როგორც სერვისი, ჯდება სამ ეტაპად: ანგარიშების მომზადება, ტესტირება, გამოქვეყნება. დამატებითი დეტალები დიაგრამაზე (ყველა სურათის დაწკაპუნება შესაძლებელია):

ძირითადი ცნებები და განმარტებები დატვირთვის ტესტირებაში

დატვირთვის ტესტების ჩატარებისას ჩვენ ვცდილობთ დავიცვათ ISTQB სტანდარტები და მეთოდოლოგიაგამოიყენეთ შესაბამისი ტერმინოლოგია და რეკომენდებული მეტრიკა. მე მივცემ ძირითადი ცნებებისა და განმარტებების მოკლე ჩამონათვალს დატვირთვის ტესტირებაში.

დატვირთვის აგენტი - ვირტუალური მანქანა, რომელზეც აპლიკაცია ამოქმედდება - დატვირთვის წყარო (Apache JMeter, Yandex.Tank ან თვითნაწერი დატვირთვის მოდული).

ტესტის მიზანი (სამიზნე) - სერვერზე დაინსტალირებული სერვერი ან აპლიკაცია, რომელიც დაექვემდებარება დატვირთვას.

ტესტის სცენარი (სატესტო შემთხვევა) - პარამეტრიზებული ნაბიჯების ნაკრები: მომხმარებლის ქმედებები და მოსალოდნელი რეაქციები ამ ქმედებებზე, ფიქსირებული ქსელის მოთხოვნებით და პასუხებით, მითითებული პარამეტრების მიხედვით.

პროფილი ან ჩატვირთვის გეგმა (პროფილი) - ში ISTQB მეთოდოლოგია (ნაწილი 4.2.4, გვ. 43) დატვირთვის პროფილები განსაზღვრავენ მეტრიკას, რომელიც კრიტიკულია კონკრეტული ტესტისთვის და ტესტის დროს დატვირთვის პარამეტრების შეცვლის ვარიანტებს. პროფილების მაგალითები შეგიძლიათ იხილოთ ფიგურაში.

ტესტი - სცენარი წინასწარ განსაზღვრული პარამეტრების ნაკრებით.

ტესტის გეგმა (ტესტი-გეგმა) - ტესტების ნაკრები და დატვირთვის პროფილი.

ტესტრანი (ტესტრუნი) - ერთი ტესტის გაშვების ერთი გამეორება სრულად შესრულებული დატვირთვის სცენარით და მიღებული ანგარიშით.

ქსელის მოთხოვნა (მოთხოვნა) — აგენტისგან სამიზნეზე გაგზავნილი HTTP მოთხოვნა.

ქსელის პასუხი (პასუხი) - HTTP პასუხი, რომელიც გაგზავნილია სამიზნედან აგენტისთვის.
HTTP პასუხის კოდი (HTTP პასუხების სტატუსი) - სტანდარტული პასუხის კოდი განაცხადის სერვერიდან.
ტრანზაქცია არის მოთხოვნა-პასუხის სრული ციკლი. ტრანზაქცია ითვლება მოთხოვნის (მოთხოვნის) გაგზავნის დაწყებიდან პასუხის (პასუხის) მიღების დასრულებამდე.

ტრანზაქციის სტატუსი - შესაძლებელი იყო თუ არა მოთხოვნა-პასუხის ციკლის წარმატებით დასრულება. თუ ამ ციკლში იყო რაიმე შეცდომა, მაშინ მთელი ტრანზაქცია ჩაითვლება წარუმატებლად.

რეაგირების დრო (დაყოვნება) - დრო მოთხოვნის (მოთხოვნის) გაგზავნის დასრულებიდან პასუხის (პასუხის) მიღების დაწყებამდე.

ჩატვირთვა მეტრიკა — დატვირთვის ტესტირების პროცესში განსაზღვრული დატვირთული სერვისისა და დატვირთვის აგენტის მახასიათებლები.

ძირითადი მეტრიკა დატვირთვის პარამეტრების გაზომვისთვის

ზოგიერთი ყველაზე ხშირად გამოყენებული და რეკომენდებული მეთოდოლოგიაში ISTQB (გვ. 36, 52) მეტრიკა ნაჩვენებია ქვემოთ მოცემულ ცხრილში. აგენტისა და სამიზნის მსგავსი მეტრიკა ჩამოთვლილია იმავე ხაზზე.

მეტრიკა დატვირთვის აგენტისთვის
დატვირთვის ქვეშ მყოფი სამიზნე სისტემის ან აპლიკაციის მეტრიკა

ხმების  vCPU და მეხსიერება RAM,
Disk - დატვირთვის აგენტის "რკინის" მახასიათებლები
CPU, მეხსიერება, დისკის გამოყენება - პროცესორის, მეხსიერების და დისკის ჩატვირთვის დინამიკა
ტესტირების პროცესში. ჩვეულებრივ იზომება პროცენტულად
მაქსიმალური ხელმისაწვდომი მნიშვნელობები

ქსელის გამტარუნარიანობა (დატვირთვის აგენტზე) - გამტარუნარიანობა
ქსელის ინტერფეისი სერვერზე,
სადაც დაყენებულია დატვირთვის აგენტი.
ჩვეულებრივ იზომება ბაიტები წამში (bps)
ქსელის გამტარუნარიანობა(სამიზნეზე) - ქსელის ინტერფეისის გამტარუნარიანობა
სამიზნე სერვერზე. ჩვეულებრივ იზომება ბაიტები წამში (bps)

ვირტუალური მომხმარებლები- ვირტუალური მომხმარებლების რაოდენობა,
დატვირთვის სცენარების განხორციელება და
რეალური მომხმარებლის ქმედებების იმიტაცია
ვირტუალური მომხმარებლის სტატუსი, გავლილი/ჩავარდნილი/სულ — წარმატებულთა რიცხვი და
ვირტუალური მომხმარებლების წარუმატებელი სტატუსები
დატვირთვის სცენარებისთვის, ისევე როგორც მათი საერთო რაოდენობა.

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

მოთხოვნები წამში (წუთში)- ქსელის მოთხოვნის რაოდენობა წამში (ან წუთში).

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

მიზნობრივი სერვისის მნიშვნელოვანი მახასიათებელი: რამდენი
შეკითხვებზე პასუხების გენერირება და გაგზავნა
ჩამტვირთავი აგენტი

HTTP პასუხის სტატუსი- სხვადასხვა საპასუხო კოდების რაოდენობა
დატვირთვის აგენტის მიერ მიღებული აპლიკაციის სერვერიდან.
მაგალითად, 200 OK ნიშნავს წარმატებულ ზარს,
და 404 - რომ რესურსი არ მოიძებნა

შეყოვნება (პასუხის დრო) - დრო ბოლოდან
მოთხოვნის (მოთხოვნის) გაგზავნა პასუხის (პასუხის) მიღებამდე.
ჩვეულებრივ იზომება მილიწამებში (ms)

ტრანზაქციის რეაგირების დრო- ერთი სრული ტრანზაქციის დრო,
მოთხოვნა-პასუხის ციკლის დასრულება.
ეს არის მოთხოვნის (მოთხოვნის) გაგზავნის დაწყებიდან
პასუხის (პასუხის) მიღების დასრულებამდე.

ტრანზაქციის დრო შეიძლება გაიზომოს წამებში (ან წუთებში)
რამდენიმე გზით: გაითვალისწინეთ მინიმალური,
მაქსიმალური, საშუალო და, მაგალითად, 90-ე პროცენტული.
მინიმალური და მაქსიმალური მაჩვენებლები უკიდურესია
სისტემის მუშაობის სტატუსი.
ოთხმოცდამეათე პროცენტი ყველაზე ხშირად გამოიყენება,
როგორც ეს აჩვენებს მომხმარებელთა უმეტესობას,
კომფორტულად მუშაობს სისტემის მუშაობის ზღურბლზე

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

ტრანზაქციის სტატუსი , გავლილი / წარუმატებელი / სულ - ნომერი
წარმატებული, წარუმატებელი და ტრანზაქციების საერთო რაოდენობა.

რეალური მომხმარებლებისთვის წარუმატებელი
გარიგება რეალურად ნიშნავს
სისტემასთან მუშაობის უუნარობა დატვირთვის ქვეშ

ჩატვირთვის ტესტირების სქემატური დიაგრამა

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

სქემატური შენიშვნები:

• QA.Tester არის ექსპერტი დატვირთვის ტესტირებაში,
• Target არის სამიზნე აპლიკაცია, რომლისთვისაც გსურთ იცოდეთ მისი ქცევა დატვირთვის ქვეშ.

ერთეულების, ეტაპების და საფეხურების კლასიფიკატორი დიაგრამაში

ეტაპები და ნაბიჯები
რა ხდება?
რა არის შესასვლელში
რა არის გამომავალი

მომზადება: ტესტირებისთვის მოსამზადებელი ეტაპი

LoadParameters
დაყენება და ინიციალიზაცია
მომხმარებელი
დატვირთვის პარამეტრები,
მეტრიკის არჩევანი და
ტესტის გეგმის მომზადება
(ჩატვირთეთ პროფილი)
მორგებული ვარიანტები
დატვირთვის აგენტის ინიციალიზაცია
ტესტის გეგმა
ტესტირების მიზანი

VM
ღრუბლის განლაგება
ვირტუალური მანქანასთან ერთად
საჭირო მახასიათებლები
VM პარამეტრები დატვირთვის აგენტისთვის
ავტომატიზაციის სკრიპტები ამისთვის
VM შექმნა
VM კონფიგურირებულია
ღრუბელი

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

LoadAgents
ინსტალაცია, კონფიგურაცია და პარამეტრიზაცია
ჩამტვირთავი აგენტი.
ან ჩამოტვირთეთ დოკერის სურათი
წინასწარ კონფიგურირებული დატვირთვის წყარო
წყაროს დოკერის სურათის ჩატვირთვა
(YAT, JM ან თვითნაწერი ჩარჩო)
პარამეტრები
დატვირთვის აგენტი
დააყენეთ და მზადაა
სამუშაო დატვირთვის აგენტი

ტესტი: დატვირთვის ტესტების შესრულების ეტაპი. წყაროები არის დატვირთვის აგენტები, რომლებიც განლაგებულია სპეციალურ აგენტურ აუზებში GitLab CI-ისთვის

Load
ჩატვირთვის აგენტის გაშვება
შერჩეული ტესტის გეგმით
და დატვირთვის პარამეტრები
მომხმარებლის პარამეტრები
ინიციალიზაციისთვის
დატვირთვის აგენტი
ტესტის გეგმა
ტესტირების მიზანი
შესრულების ჟურნალები
დატვირთვის ტესტები
სისტემის ჟურნალები
მიზნების მეტრიკისა და დატვირთვის აგენტის ცვლილებების დინამიკა

გაუშვით აგენტები
აგენტის აღსრულება
უამრავი ტესტის სკრიპტი
შესაბამისად
პროფილის ჩატვირთვა
დატვირთვის აგენტის ურთიერთქმედება
ტესტირების მიზნით
ტესტის გეგმა
ტესტირების მიზანი

ლოგები
"ნედლი" მორების კოლექცია
დატვირთვის ტესტირების დროს:
აგენტის საქმიანობის ჩანაწერების ჩატვირთვა,
ტესტის სამიზნის მდგომარეობა
და VM მართავს აგენტს

შესრულების ჟურნალები
დატვირთვის ტესტები
სისტემის ჟურნალები

Metrics
ტესტირების დროს "ნედლი" მეტრიკის შეგროვება

მიზნების მეტრიკის ცვლილებების დინამიკა
და დატვირთვის აგენტი

ანგარიში: ტესტის ანგარიშის მომზადების ეტაპი

გენერატორი
შეგროვებული დამუშავება
ჩატვირთვის სისტემა და
მონიტორინგის სისტემა "ნედლეული"
მეტრიკა და ჟურნალი
ანგარიშის ფორმირება ქ
ადამიანის წასაკითხი ფორმა
შესაძლებელია ელემენტებით
ანალიტიკოსები
შესრულების ჟურნალები
დატვირთვის ტესტები
სისტემის ჟურნალები
მეტრიკის ცვლილებების დინამიკა
სამიზნე და დატვირთვის აგენტი
დამუშავებული „ნედლი“ მორები
შესაფერისი ფორმატით
ატვირთვები გარე მეხსიერებაში
სტატიკური დატვირთვის ანგარიში,
ადამიანისთვის წასაკითხი

გამოქვეყნება
ანგარიშის გამოქვეყნება
დატვირთვის შესახებ
გარე ტესტირება
მომსახურება
დამუშავებული "ნედლი"
ჟურნალი შესაფერის ფორმატში
გარედან გადმოტვირთვისთვის
საცავები
შენახულია გარე
შენახვის ანგარიშები
დატვირთვა, შესაფერისი
ადამიანის ანალიზისთვის

დატვირთვის წყაროების დაკავშირება CI შაბლონში

გადავიდეთ პრაქტიკულ ნაწილზე. მე მინდა ვაჩვენო, თუ როგორ ხდება რამდენიმე პროექტზე კომპანიაში პოზიტიური ტექნოლოგიები ჩვენ განვახორციელეთ დატვირთვის ტესტირების კონცეფცია, როგორც სერვისი.

პირველი, ჩვენი DevOps ინჟინრების დახმარებით, ჩვენ შევქმენით აგენტების გამოყოფილი აუზი GitLab CI-ში დატვირთვის ტესტების გასატარებლად. იმისათვის, რომ არ აგვერიოს ისინი შაბლონებში სხვებთან, როგორიცაა ასამბლეის აუზები, ჩვენ დავამატეთ ტეგები ამ აგენტებს, ტეგები: დატვირთვა. თქვენ შეგიძლიათ გამოიყენოთ ნებისმიერი სხვა გასაგები ტეგი. ეკითხებიან რეგისტრაციის დროს GitLab CI Runners.

როგორ გავარკვიოთ საჭირო სიმძლავრე ტექნიკით? დატვირთვის აგენტების მახასიათებლები - vCPU, RAM და დისკის საკმარისი რაოდენობა - შეიძლება გამოითვალოს იმ ფაქტზე დაყრდნობით, რომ აგენტზე უნდა მუშაობდეს Docker, Python (Yandex.Tank-ისთვის), GitLab CI აგენტი, Java (Apache JMeter-ისთვის). . Java-სთვის JMeter-ის ქვეშ, ასევე რეკომენდებულია მინიმუმ 512 მბ ოპერატიული მეხსიერების გამოყენება და, როგორც ზედა ზღვარი, 80% ხელმისაწვდომი მეხსიერება.

ამრიგად, ჩვენი გამოცდილებიდან გამომდინარე, ჩვენ გირჩევთ გამოიყენოთ მინიმუმ 4 vCPU, 4 GB ოპერატიული მეხსიერება, 60 GB SSD დატვირთვის აგენტებისთვის. ქსელის ბარათის გამტარუნარიანობა განისაზღვრება დატვირთვის პროფილის მოთხოვნების საფუძველზე.

ჩვენ ძირითადად ვიყენებთ დატვირთვის ორ წყაროს - Apache JMeter და Yandex.Tank docker images.

Yandex.Tank არის Yandex-ის ღია კოდის ინსტრუმენტი დატვირთვის ტესტირებისთვის. მისი მოდულური არქიტექტურა ეფუძნება Phantom-ის მაღალი ხარისხის ასინქრონულ ჰიტზე დაფუძნებულ HTTP მოთხოვნის გენერატორს. ტანკს აქვს ჩაშენებული სერვერის რესურსების მონიტორინგი SSH პროტოკოლის საშუალებით, შეუძლია ავტომატურად შეაჩეროს ტესტი მითითებულ პირობებში, შეუძლია შედეგების ჩვენება როგორც კონსოლში, ასევე გრაფიკის სახით, შეგიძლიათ დააკავშიროთ თქვენი მოდულები მას ფუნქციონირების გაფართოება. სხვათა შორის, ჩვენ ვიყენებდით ტანკს, როდესაც ის ჯერ კიდევ არ იყო მეინსტრიმი. სტატიაში "Yandex.Tank და დატვირთვის ტესტირების ავტომატიზაცია» შეგიძლიათ წაიკითხოთ ამბავი იმის შესახებ, თუ როგორ ჩავატარეთ დატვირთვის ტესტირება მასთან 2013 წელს PT განაცხადის Firewall არის ჩვენი კომპანიის ერთ-ერთი პროდუქტი.

Apache JMeter არის ღია კოდის დატვირთვის ტესტირების ინსტრუმენტი Apache-სგან. ის შეიძლება გამოყენებულ იქნას თანაბრად კარგად როგორც სტატიკური, ასევე დინამიური ვებ აპლიკაციების შესამოწმებლად. JMeter მხარს უჭერს უამრავ პროტოკოლს და აპლიკაციებთან ურთიერთობის გზებს: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET და ა.შ.), SOAP / REST ვებსერვისებს, FTP, TCP, LDAP, SMTP(S), POP3( S) ) და IMAP(S), მონაცემთა ბაზებს JDBC-ის საშუალებით, შეუძლიათ შეასრულონ shell ბრძანებები და იმუშაონ Java ობიექტებთან. JMeter-ს აქვს IDE ტესტის გეგმების შესაქმნელად, გამართვისა და შესრულებისთვის. ასევე არსებობს CLI ბრძანების ხაზის მუშაობისთვის ნებისმიერ Java-თან თავსებად ოპერაციულ სისტემაზე (Linux, Windows, Mac OS X). ხელსაწყოს შეუძლია დინამიურად შექმნას HTML ტესტის ანგარიში.

ჩვენს კომპანიაში გამოყენების სიმარტივისთვის, თავად ტესტერების შესაძლებლობისთვის, შეცვალონ და დაამატონ გარემო, ჩვენ გავაკეთეთ GitLab CI-ზე დატვირთვის წყაროების დოკერის სურათების კონსტრუქციები, გამოქვეყნებით შიდა დოკერის რეესტრი Artifactory-ში. ეს აადვილებს მათ დაკავშირებას მილსადენებში დატვირთვის ტესტებისთვის. როგორ გავაკეთოთ docker push რეესტრის მეშვეობით GitLab CI - იხ ინსტრუქციები.

ჩვენ ავიღეთ ეს ძირითადი დოკერის ფაილი Yandex.Tank-ისთვის:

Dockerfile 
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]

და Apache JMeter-ისთვის ეს:

Dockerfile 
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]

როგორ მუშაობს ჩვენი უწყვეტი ინტეგრაციის სისტემა, შეგიძლიათ წაიკითხოთ სტატიაში "განვითარების პროცესების ავტომატიზაცია: როგორ განვახორციელეთ DevOps იდეები Positive Technologies-ში".

შაბლონი და მილსადენი

დატვირთვის ტესტების ჩატარების შაბლონის მაგალითი ხელმისაწვდომია პროექტში დემო დატვირთვა. In readme ფაილი შეგიძლიათ წაიკითხოთ შაბლონის გამოყენების ინსტრუქცია. თავად შაბლონში (ფაილი .gitlab-ci.yml) არის შენიშვნები იმის შესახებ, თუ რაზეა პასუხისმგებელი თითოეული ნაბიჯი.

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

1. ეტაპი მომზადება უნდა იქნას გამოყენებული სატესტო მიზნების წინასწარ კონფიგურაციისთვის ან მათი ხელმისაწვდომობის შესამოწმებლად. დატვირთვის წყაროების გარემო არ საჭიროებს კონფიგურაციას, ისინი წინასწარ არის აშენებული დოკერის გამოსახულების სახით და განთავსებულია დოკერის რეესტრში: უბრალოდ მიუთითეთ სასურველი ვერსია ტესტის ეტაპზე. მაგრამ თქვენ შეგიძლიათ აღადგინოთ ისინი და შექმნათ თქვენი საკუთარი შეცვლილი სურათები.
2. ეტაპი ტესტი გამოიყენება დატვირთვის წყაროს დასაზუსტებლად, ტესტების გასაშვებად და ტესტის არტეფაქტების შესანახად. თქვენ შეგიძლიათ აირჩიოთ ნებისმიერი დატვირთვის წყარო: Yandex.Tank, Apache JMeter, საკუთარი ან ყველა ერთად. არასაჭირო წყაროების გამორთვისთვის, უბრალოდ დატოვეთ კომენტარი ან წაშალეთ სამუშაო. შესვლის წერტილები დატვირთვის წყაროებისთვის:
   • Yandex.Tank-ის გაშვების პარამეტრები მითითებულია ./tests/yandextank.sh,
   • Apache JMeter-ის გაშვების პარამეტრები მითითებულია ფაილში ./tests/jmeter.შ.

   შენიშვნა: ასამბლეის კონფიგურაციის შაბლონი გამოიყენება CI სისტემასთან ურთიერთქმედების დასაყენებლად და არ გულისხმობს მასში ტესტის ლოგიკის განთავსებას. ტესტებისთვის მითითებულია შესვლის წერტილი, სადაც მდებარეობს საკონტროლო bash სკრიპტი. ტესტების გაშვების, მოხსენებების გენერირების მეთოდი და თავად ტესტის სკრიპტები უნდა განხორციელდეს QA ინჟინრების მიერ. დემო ვერსიაში, ორივე დატვირთვის წყაროსთვის, Yandex-ის მთავარი გვერდის მოთხოვნა გამოიყენება როგორც უმარტივესი ტესტი. სკრიპტები და ტესტის პარამეტრები დირექტორიაშია ./ტესტები.

3. სცენაზე ანგარიში თქვენ უნდა აღწეროთ, თუ როგორ უნდა გამოაქვეყნოთ ტესტის ეტაპზე მიღებული ტესტის შედეგები გარე საცავებში, მაგალითად, GitLab გვერდებზე ან სპეციალურ საანგარიშო სისტემებზე. GitLab Pages მოითხოვს, რომ ./public დირექტორია არ იყოს ცარიელი და შეიცავდეს მინიმუმ index.html ფაილს ტესტების დასრულების შემდეგ. შეგიძლიათ წაიკითხოთ GitLab Pages სერვისის ნიუანსების შესახებ. по ссылке.

   მონაცემების ექსპორტის მაგალითები:

   • JMeter-დან GitLab გვერდები,
   • Yandex.Tank-დან InfluxDB და Grafana.

   დაყენების ინსტრუქციების გამოქვეყნება:

   • HTML სტატიკაში GitLab გვერდები,
   • InfluxDB-ზე და შემდეგ გრაფანა.

დემო მაგალითში, მილსადენი დატვირთვის ტესტებით და ორი დატვირთვის წყაროებით (შეგიძლიათ გამორთოთ არასაჭირო) ასე გამოიყურება:

Apache JMeter-ს შეუძლია თავად შექმნას HTML ანგარიში, ამიტომ უფრო მომგებიანია მისი შენახვა GitLab გვერდებზე სტანდარტული ხელსაწყოების გამოყენებით. ასე გამოიყურება Apache JMeter ანგარიში:

Yandex.Tank-ის დემო მაგალითში მხოლოდ ნახავთ ყალბი ტექსტური ანგარიში GitLab გვერდების განყოფილებაში. ტესტირების დროს ტანკს შეუძლია შედეგების შენახვა InfluxDB მონაცემთა ბაზაში და იქიდან მათი ჩვენება, მაგალითად, Grafana-ში (კონფიგურაცია ხდება ფაილში ./tests/example-yandextank-test.yml). ასე გამოიყურება ტანკის ანგარიში Grafana-ში:

რეზიუმე

სტატიაში მე ვისაუბრე კონცეფციაზე „load testing as a service“ (load testing as a service). მთავარი იდეა არის დატვირთვის აგენტების წინასწარ კონფიგურირებული აუზების ინფრასტრუქტურის გამოყენება, დატვირთვის წყაროების დოკერის სურათები, საანგარიშო სისტემები და მილსადენი, რომელიც აერთიანებს მათ GitLab CI-ში მარტივი .gitlab-ci.yml შაბლონის საფუძველზე (მაგალითი по ссылке). ამ ყველაფერს მხარს უჭერს ავტომატიზაციის ინჟინრების მცირე გუნდი და იმეორებს პროდუქტის გუნდების მოთხოვნით. ვიმედოვნებ, რომ ეს დაგეხმარებათ მსგავსი სქემის მომზადებასა და განხორციელებაში თქვენს კომპანიაში. Მადლობა ყურადღებისთვის!

PS მინდა დიდი მადლობა გადავუხადო ჩემს კოლეგებს, სერგეი კურბანოვს და ნიკოლაი იუსევს, ტექნიკური დახმარებისთვის ჩვენს კომპანიაში დატვირთვის ტესტირების კონცეფციის, როგორც სერვისის განხორციელებაში.

ავტორი: ტიმურ გილმულინი - მოადგილე Positive Technologies-ის ტექნოლოგიებისა და განვითარების პროცესების (DevOps) ხელმძღვანელი

წყარო: www.habr.com