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

ჰეი ჰაბრ!

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

მე ვარ Sportmaster-ის გუნდში სულ რაღაც წელიწადზე მეტი და ვამუშავებ ავტომატიზირებულ ტესტირებას ერთ-ერთ მთავარ პროექტზე. აპრილში მე და Sportmaster Lab-ის ბიჭებმა ვისაუბრეთ კრასნოდარში გამართულ კონფერენციაზე, ჩემს მოხსენებას ერქვა "ერთეულის ტესტები DBMS-ში" და ახლა მინდა გაგიზიაროთ. ბევრი ტექსტი იქნება, ამიტომ გადავწყვიტე ანგარიში ორ პოსტად დავყო. პირველში ვისაუბრებთ ავტოტესტებზე და ზოგადად ტესტირებაზე, მეორეში კი უფრო დეტალურად ვისაუბრებ ჩვენი ერთეულის ტესტირების სისტემაზე და მისი გამოყენების შედეგებზე.

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

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

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

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

ერთგულების ტესტირება

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

თუ თქვენი კომპანია საკმარისად დიდია, მაშინ თქვენს ლოიალობის სისტემას ექნება სამი სტანდარტული თვისება:

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

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

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

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

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

აღწერილი თვისებები სტანდარტულია თითქმის ნებისმიერი ლოიალობის სისტემისთვის. მოდით ვისაუბროთ ჩვენი პროექტის მახასიათებლებზე.

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

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

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

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

utPLSQL მოდის სამაშველოში

სტივენ ფოიერშტეინის შესახებ იცით რამე?

ეს არის ჭკვიანი ბიჭი, რომელმაც თავისი კარიერის დიდი ნაწილი მიუძღვნა Oracle-თან და PL/SQL-თან მუშაობას და დაწერა საკმაოდ დიდი რაოდენობით ნამუშევარი ამ თემაზე. მის ერთ-ერთ ცნობილ წიგნს ჰქვია: „Oracle PL/SQL. პროფესიონალებისთვის." სწორედ სტივენმა შეიმუშავა utPLSQL გადაწყვეტა, ან, როგორც ეს ნიშნავს, Unit Testing Framework Oracle PL/SQL-ისთვის. utPLSQL გადაწყვეტა შეიქმნა 2016 წელს, მაგრამ მასზე აქტიურად მიმდინარეობს მუშაობა და გამოდის ახალი ვერსიები. მოხსენების დროს, უახლესი ვერსია თარიღდება 24 წლის 2019 მარტს.
Რა არის ეს. ეს არის ცალკე ღია კოდის პროექტი. ის იწონის რამდენიმე მეგაბაიტს, მაგალითებისა და დოკუმენტაციის ჩათვლით. ფიზიკურად, ეს არის ცალკე სქემა ORACLE-ის მონაცემთა ბაზაში პაკეტებისა და ცხრილების ნაკრებით ერთეულების ტესტირების ორგანიზებისთვის. ინსტალაციას რამდენიმე წამი სჭირდება. utPLSQL-ის გამორჩეული თვისება არის მისი მარტივი გამოყენება.
გლობალურად, utPLSQL არის ერთეულის ტესტების გაშვების მექანიზმი, სადაც ერთეულის ტესტი გაგებულია, როგორც ჩვეულებრივი Oracle-ის სერიის პროცედურები, რომელთა ორგანიზება გარკვეულ წესებს მიჰყვება. გაშვების გარდა, utPLSQL ინახავს თქვენი ყველა სატესტო გაშვების ჟურნალს და ასევე აქვს შიდა მოხსენების სისტემა.

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

ასე რომ, ეკრანზე ნაჩვენებია ტიპიური პაკეტის სპეციფიკაციის კოდი ერთეულის ტესტებით. რა არის სავალდებულო მოთხოვნები? პაკეტს უნდა ჰქონდეს პრეფიქსი "utp_". ყველა პროცედურას ტესტებით უნდა ჰქონდეს ზუსტად იგივე პრეფიქსი. პაკეტი უნდა შეიცავდეს ორ სტანდარტულ პროცედურას: "utp_setup" და "utp_teardown". პირველი პროცედურა იწოდება თითოეული ერთეულის ტესტის გადატვირთვით, მეორე - გაშვების შემდეგ.

"utp_setup", როგორც წესი, ამზადებს ჩვენს სისტემას ერთეულის ტესტის გასაშვებად, მაგალითად, ტესტის მონაცემების შესაქმნელად. "utp_teardown" - პირიქით, ყველაფერი უბრუნდება თავდაპირველ პარამეტრებს და აღადგენს გაშვების შედეგებს.

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

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

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

ასე ტარდება ერთეულის ტესტები. გაშვების ორი შესაძლო ვარიანტია: ყველა ერთეულის ტესტის გაშვება კონკრეტული პაკეტიდან ან კონკრეტული ერთეულის ტესტის გაშვება კონკრეტულ პაკეტში.

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

ავტოტესტების 6 წესი

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

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

მეორე პოსტში კი რამდენიმე დღეში გეტყვით რა გავაკეთეთ და რა შედეგს მივაღწიეთ.

წყარო: www.habr.com