ერთეულის ტესტები DBMS-ში - როგორ ვაკეთებთ ამას Sportmaster-ში, ნაწილი მეორე

Პირველი ნაწილი - აქ.

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

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

1. ძველი ერთეულის ტესტების აღდგენა. აღდგენა ნიშნავს ტესტების ადაპტირებას ლოიალობის სისტემის არსებულ მდგომარეობასთან და ტესტების ადაპტაციას utPLSQL სტანდარტებთან.
2. პრობლემის გადაჭრა იმის გაგებით, თუ რა ზუსტად, რა მეთოდები და პროცესებია დაფარული ავტოტესტებით. თქვენ ან უნდა შეინახოთ ეს ინფორმაცია თქვენს თავში, ან გამოიტანოთ დასკვნები უშუალოდ ავტოტესტის კოდის საფუძველზე. ამიტომ, გადავწყვიტეთ შეგვექმნა კატალოგი. თითოეულ ავტოტესტს მივაკუთვნეთ უნიკალური მნემონური კოდი, შევქმენით აღწერა და ჩავწერეთ პარამეტრები (მაგალითად, რა პირობებში უნდა გაშვებულიყო, ან რა უნდა მოხდეს, თუ ტესტის გაშვება ვერ მოხერხდა). არსებითად, ჩვენ შევავსეთ მეტამონაცემები ავტოტესტების შესახებ და მოვათავსეთ ეს მეტამონაცემები სტანდარტულ utPLSQL სქემის ცხრილებში.
3. გაფართოების სტრატეგიის განსაზღვრა, ე.ი. ფუნქციონირების შერჩევა, რომელიც ექვემდებარება შემოწმებას ავტომატური ტესტებით. ჩვენ გადავწყვიტეთ, რომ ყურადღება მივაქციოთ სამ რამეს: ახალი სისტემის გაუმჯობესება, წარმოების ინციდენტები და ძირითადი სისტემის პროცესები. ამრიგად, ჩვენ ვვითარდებით გამოშვების პარალელურად, უზრუნველვყოფთ მის მაღალ ხარისხს, პარალელურად ვაფართოებთ რეგრესიის ფარგლებს და უზრუნველვყოფთ სისტემის საიმედოობას კრიტიკულ ადგილებში. პირველი ასეთი შეფერხება იყო ჩეკზე ფასდაკლებებისა და ბონუსების განაწილების პროცესი.
4. ბუნებრივია, დავიწყეთ ახალი ავტოტესტების შემუშავება. ერთ-ერთი პირველი გამოშვების ამოცანა იყო ლოიალობის სისტემის წინასწარ განსაზღვრული ნიმუშების მუშაობის შეფასება. ჩვენს პროექტს აქვს მტკიცედ დაფიქსირებული SQL მოთხოვნების ბლოკი, რომელიც ირჩევს კლიენტებს პირობების მიხედვით. მაგალითად, მიიღეთ ყველა კლიენტის სია, რომელთა ბოლო შესყიდვა იყო კონკრეტულ ქალაქში, ან იმ მომხმარებლების სია, რომელთა საშუალო შესყიდვის თანხა აღემატება გარკვეულ ღირებულებას. წერილობითი ავტოტესტების შემდეგ, ჩვენ შევამოწმეთ წინასწარ განსაზღვრული ნიმუშები, ჩავწერეთ საორიენტაციო შესრულების პარამეტრები და დამატებით გვქონდა დატვირთვის ტესტირება.
5. ავტოტესტებთან მუშაობა მოსახერხებელი უნდა იყოს. ორი ყველაზე გავრცელებული მოქმედებაა ავტომატური ტესტების გაშვება და ტესტის მონაცემების შექმნა. ასე გამოჩნდა ჩვენს სისტემაში ორი დამხმარე მოდული: გაშვების მოდული და მონაცემთა გენერირების მოდული.

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

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

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

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

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

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

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

   DBMS დონეზე იქმნება სპეციალური ცხრილი, რომელშიც Liquibase ინახავს rollover log-ს. თითოეულ ცვლილებას აქვს გამოთვლილი ჰეში, რომელიც ყოველ ჯერზე შედარებულია პროექტსა და მონაცემთა ბაზაში არსებულ მდგომარეობას შორის. Liquibase-ის წყალობით, ჩვენ შეგვიძლია მარტივად გავავრცელოთ ცვლილებები ჩვენს სისტემაში ნებისმიერ წრეში. ავტომატური ტესტები ახლა გაშვებულია სატესტო და გამოშვების სქემებზე, ასევე კონტეინერებზე (დეველოპერების პირადი სქემები).

ასე რომ, მოდით ვისაუბროთ ჩვენი ერთეულის ტესტირების სისტემის გამოყენების შედეგებზე.

1. რა თქმა უნდა, პირველ რიგში, ჩვენ დარწმუნებული ვართ, რომ დავიწყეთ უკეთესი პროგრამული უზრუნველყოფის შემუშავება. ავტომატური ტესტები ყოველდღიურად იწყება და ათობით შეცდომა გვხვდება ყოველ გამოშვებაში. უფრო მეტიც, ამ შეცდომებიდან ზოგიერთი მხოლოდ ირიბად არის დაკავშირებული იმ ფუნქციონალთან, რომლის შეცვლაც ჩვენ ნამდვილად გვინდოდა. არსებობს სერიოზული ეჭვი, რომ ეს შეცდომები აღმოჩენილია ხელით ტესტირებით.
2. გუნდს ახლა აქვს დარწმუნებული, რომ კონკრეტული ფუნქციონირება სწორად მუშაობს... პირველ რიგში, ეს ეხება ჩვენს კრიტიკულ პროცესებს. მაგალითად, ბოლო ექვსი თვის განმავლობაში ჩვენ არ გვქონია არანაირი პრობლემა ქვითრებზე ფასდაკლებებისა და ბონუსების განაწილებასთან დაკავშირებით, მიუხედავად გამოშვების ცვლილებისა, თუმცა წინა პერიოდებში შეცდომები გარკვეული სიხშირით ხდებოდა.
3. ჩვენ შევძელით ტესტირების გამეორებების რაოდენობის შემცირება. იმის გამო, რომ ავტოტესტები იწერება ახალი ფუნქციონირებისთვის, ანალიტიკოსები და ნახევარ განაკვეთზე ტესტერები იღებენ უფრო მაღალი ხარისხის კოდს, რადგან უკვე შემოწმებულია.
4. ავტომატური ტესტირების ზოგიერთი განვითარება გამოიყენება დეველოპერების მიერ. მაგალითად, სატესტო მონაცემები კონტეინერებზე იქმნება ობიექტის გენერირების მოდულის გამოყენებით.
5. მნიშვნელოვანია, რომ ჩვენ შევიმუშავეთ ავტომატური ტესტირების სისტემის „მიღება“ დეველოპერების მხრიდან. არსებობს გაგება, რომ ეს მნიშვნელოვანი და სასარგებლოა. მაგრამ ჩემი საკუთარი გამოცდილებიდან შემიძლია ვთქვა, რომ ეს შორს არის საქმისგან. ავტოტესტები უნდა დაიწეროს, მათ მხარდაჭერა და განვითარება სჭირდება, შედეგები უნდა გაანალიზდეს და ხშირად ეს დროის ხარჯები უბრალოდ არ ღირს. ბევრად უფრო ადვილია წარმოებაზე წასვლა და იქ პრობლემების მოგვარება. აქ, დეველოპერები დგანან და გვთხოვენ, დავფაროთ მათი ფუნქციონირება ავტოტესტებით.

რა არის შემდეგი

მოდით ვისაუბროთ ავტომატური ტესტირების პროექტის განვითარების გეგმებზე.

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

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

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

1. ამჟამად ავტოტესტის მართვა ხორციელდება DBMS დონეზე, ე.ი. წარმატებული მუშაობისთვის საჭიროა PL/SQL-ის ცოდნა. საჭიროების შემთხვევაში, სისტემის მენეჯმენტი (მაგალითად, მეტამონაცემების გაშვება ან შექმნა), შეგიძლიათ შექმნათ რაიმე სახის ადმინისტრაციული პანელი ჯენკინსის ან მსგავსი რამის გამოყენებით.
2. ყველას უყვარს რაოდენობრივი და ხარისხობრივი მაჩვენებლები. ავტომატური ტესტირებისთვის, ასეთი უნივერსალური მაჩვენებელია კოდის დაფარვის ან კოდის დაფარვის მეტრიკა. ამ ინდიკატორის გამოყენებით შეგვიძლია განვსაზღვროთ ჩვენი ტესტირების სისტემის კოდის რამდენი პროცენტი დაფარულია ავტოტესტებით. 12.2 ვერსიიდან დაწყებული, Oracle უზრუნველყოფს ამ მეტრიკის გამოთვლის შესაძლებლობას და გთავაზობთ სტანდარტული DBMS_PLSQL_CODE_COVERAGE პაკეტის გამოყენებას.

   ჩვენი ავტოტესტის სისტემა ერთ წელზე მეტი ხნისაა და ალბათ ახლა არის დრო, რომ შევაფასოთ ჩვენი გაშუქება. ჩემს ბოლო პროექტში (არა Sportmaster პროექტში) ასე მოხდა. ავტოტესტებზე მუშაობიდან ერთი წლის შემდეგ მენეჯმენტმა დაისახა დავალება შეაფასოს კოდის რამდენ პროცენტს ვფარავთ. 1%-ზე მეტი გაშუქებით მენეჯმენტი ბედნიერი იქნება. ჩვენ, დეველოპერები, ველოდით შედეგს დაახლოებით 10%. ჩვენ დავაყენეთ კოდის დაფარვა, გავზომეთ და მივიღეთ 20%. აღსანიშნავად წავედით პრიზის ასაღებად, მაგრამ როგორ წავედით მის მისაღებად და სად წავედით მოგვიანებით, ეს სულ სხვა ამბავია.

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

დასკვნები

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

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

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

გამოკითხვაში მონაწილეობა შეუძლიათ მხოლოდ დარეგისტრირებულ მომხმარებლებს. Შებრძანდითგთხოვთ

ამაზე მეტი დავწეროთ?

• Კი, რა თქმა უნდა

• Არა გმადლობთ

მისცა ხმა 12 მომხმარებელმა. 4 მომხმარებელმა თავი შეიკავა.

წყარო: www.habr.com