სმოუქ VS სანითი VS რეგრესიული ტესტირება

სმოუქ VS სანითი VS რეგრესიული ტესტირება

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

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

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

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

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

რატომ არის მნიშვნელოვანი?

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

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

  1. უფრო მძლავრი ძრავის დამონტაჟების შემთხვევაში:

    1. მიწის ფართობის ტენიანობა შესაძლოა საგრძნობლად გაიზარდოს;
    2. მომატებული ტენიანობა გამოიწვევს არასასურველ გავლენას მცენარეებზე;
    3. წყლის გაზრდილი წნევა დროთა განმავლობაში დააზიანებს უშუალოდ წყლის სადინარ მილებს და ხვრელებს საიდანაც ხდება წყლის გამოდინება.

  2. ნაკლებად მძლავრი ძრავის დამონტაჟების შემთხვევაში:

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

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

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

უფრო მეტი, თუ როგორ უნდა დაგეგმო რეგრესიული ტესტირება, შეგიძლია გაიგო სტატიიდან "ტესტ ქეისების შერჩევა რეგრესიული ტესტირებისათვის".

როდის უნდა მოხდეს რეგრესიული ტესტირება?

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

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

სმოუქ (smoke) ტესტირება

რა არის სმოუქ (smoke) ტესტირება?

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

რატომ არის მნიშვნელოვანი?

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

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

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

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

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

როდის უნდა მოხდეს სმოუქ ტესტირება?

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

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

სანითი (sanity) ტესტირება

რა არის სანითი (sanity) ტესტირება?

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

რატომ არის მნიშვნელოვანი?

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

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

როდის უნდა მოდეს სანითი ტესტირება?

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

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

რეგრესია VS სმოუქ VS სანითი ტესტირება

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

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

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

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

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

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

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

დასაწყისში დაბრუნება

ვებ გვერდი იყენებს ქუქი-ფაილებს. დეტალურად