პროგრამული უზრუნველყოფის ტესტირება

5 გაკვეთილი
 ტესტირების დონეები (Test levels)

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

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

ტესტირების ყველა დონე განთავსებულია test

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

არსებობს ტესტირების 4 დონე :

★ Component level of testing (Unit, Module )

★ Integration level of testing
★ System level of testing
★ Acceptance level of testing
 Test levels
Component level of testing - component/unit/module ეს არის სისტემის ან აპლიკაციის უმცირესი
ნაწილი, რომელიც შესაძლებელია, რომ გავტესტოთ, შევასრულოთ (execute). შეგვიძლია თითოეული
კომპონენტი გავტესტოთ ცალ-ცალკე და მოწმდება კომპინენტი ასრულებს თუ არა მასზე დაკისრებულ
ფუნქციას.

კონპონენტის მზაობის დონეზე ტესტირებას ძირითადად ასრულებენ დეველოპერები და ტექნიკებიდან

ძირითადად გამოიყენება თეთრი ყუთის ტესტირების ტექნიკები

Მაგ: ლიფტის ღილაკის ტესტირება ლიფტის გარეშე.

Მაგ: რაიმე ველის ფუნქციონალის გატესტვა, მანამ სანამ ეს ველი დაემატება ვებ-გვერდზე.
 Test levels
Integration level of testing - ინტეგრაცია ნიშნავს გაერთიანებას. Მაგ, ტესტირების ამ დონეზე ხდება
მოდულების გაერთიანება და მათი გატესტვა ერთანად.

ინტეგრაციული ტესტირების დონეზე ხდება მონაცემების გადაცემის სისწორის გადამოწმება ერთი

მოდულიდან სხვა მოდულებისკენ.

ამ სახის ტესტირებას ახორციელებენ დეველოპერებიც და ტესტეტები.

სილაბუსის მიხედვით გვაქვს 2 ინტეგრაციული ტესტირების დონე:

● Component integration testing - ფოკუსირებულია ინტეგრირებული კომპონენტების

ურთიერთდამოკიდებულებაზე. Მორციელდება კომპონენტური ტესტირების შემდე და, ძირითადად
ავტომატიზირებულია .
● System integration testing - ფოკუსირდება სისტემებს შორის ურთიერთკავშირებზე. Მორციელდება
სისტემური ტესტირების შემდეგ ან პარალელურად.
 Test levels
System level of testing - ტესტის დონე, რომელიც ფოკუსირდება იმის დასადასტურებლად, რომ სისტემა
მთლიანობაში აკმაყოფილებს განსაზღვრულ მოთხოვნებს.

ხდება end to end ტესტირება. ტესტირებამ უნდა აღმოაჩინოს როგორც ფუნქციონალური , ასევე
არაფუნქციონალური ხარვეზები.

მოიცავს მოთხოვნების დოკუმენტაციის და use-case -ესბის ტესტირებას.

ხორციელდება როგორც შიდა ასევე შეიძლება დამოუკიდებელი ტესტერების მიერ.

 Test levels
Acceptance level of testing - ტესტის დონე, რომელიც ფოკუსირდება იმაზე, თუ რამდენად მისაღებია
სისტემა. ტარდება დამკვეთის ან საბოლოო იუზერის(end-user) მიერ.

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

ტესტავს.

არსებობს რამდენიმე სახის acceptance testing:

★ User acceptance testing

★ Operational acceptance testing
★ Contractual and regulatory acceptance testing
★ Alpha and beta testing
 Test levels
★ User acceptance testing - ფოკუსირებულია იმის ვალიდაციაზე, რამდენად ვარგისია და
გამოყენებადია სისტემა მომხმარებლების მიერ რეალურ ან სიმულირებულ რეალურ გარემოში.

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

საჭიროებისამებრ, მოთხოვნებთან თანხვედრაშია და ასრულებს ბიზნეს პროცესებს ნაკლები
ძალისხმევით, ხარჯით და რისკით

★ Operational acceptance testing - ეს არის პროდაქშენზე ტესტირება და უმეტესად ახორციელებენ

დევოპსები. Მქტივობებია: Testing of backup and restore, Installing, Uninstalling, upgrading …

★ Contractual and regulatory acceptance testing - რამდენად შეესაბამება სისტემა ხელშეკრულების

მოთხოვნებს, რამდენად შეესაბამება სისტემა კანონებს, კომპანიის პოლიტიკას და რეგულაციებს
 Test levels
★ Alpha and beta testing -

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

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

მიზნები:

დარწმუნდნენ, რომ ჩვეულებრივ გარემოში, ჩვეულებრივი აქტივობების და ოპერაციების დროს სისტემა

შეუფერხებლად მუშაობს

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

(დარეპროდუსირება) არის რთული დეველოპმენტის გუნდისთვის
Classification
 სტატიკური და დინამიური ტესტირება
Static testing -სტატიკური ტესტირება, ტესტავს work products კოდის შესრულების (გაშვების) გარეშე,
განსხვავებით დინამიური ტესტირებისგან, რომელის დროსაც პორგრამული კოდის შესრულება არის
აუცილებელი.

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

Dynamic testing - დინამიური ტესტირება ტესტავს პროგრამულ პროდუქტს კოდის შესრულების დახმარებით.

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

სტატიკურ და დინამიურ ტესტირებას აქვს

ერთი და იგივე მიზანი: Work Product-ის
ხარისხის შეფასება და რაც შეიძლება
ადრეულ ეტაპზე ხარვეზების გამოვლენა.

მთავარი სხვაობა არის ის, რომ სტატიკური

ტესტირება პოულობს ხარვეზებს Work
Product -ში(defect), ხოლო დინამიური
ტესტირება პოულობს ხარვეზებს
პროგრამულ უზრუნველყოფაში (failure).
 სტატიკური ტესტირების დამატებითი უპირატესობები
★ ხარვეზების აღმოჩენა და გასწორება არის მეტად ნაყოფიერი და ეს შესაძლებელია დინამიური ტესტირების დაწყებამდე
★ შესაძლებელია აღმოვაჩინოთ ისეთი ხარვეზები, რომლის აღმოჩენაც დინამიური ტესტირებისას არ არის მარტივი
★ ავირიდოთ ხარვეზები დიზაინში ან კოდში შეუსაბამობების, გაურკვევლობების და უზრუსტობების გამოაშკარავებით
მოთხოვნებში.
★ გავზარდოთ დეველოპმენტის პროდუქტიულობა
★ შევამციროთ დეველოპმენტის ღირებულება და დრო
★ შევამციროთ ტესტირების ღირებულება და დრო
★ კომუნიკაციის გაუმჯობესება გუნდის წევრებს შორის Review-ებში მონაწილეობის პროცესში.

სქრინებზე მოცემულია შემთხვევა, როდესაც მომხმარებელს შეჰყავს 8000 ლარზე მეტი

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

სტატიკური ტესტირების დროს, ვიდრე დეველოპერი დაიწყებდა კოდის წერას,

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

Review-ს პროცესი იყოფა ორ ტიპად:

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

Review -ს პროცესი მოიცავს შემდეგ ძირითად აქტივობებს:

ტიპიური ფორმალური მიმოხილვა შეიცავს შემდეგ როლებს:

★ Author
★ Management
★ Facilitator (Moderator)
★ Review Leader
★ Reviewers
★ Scribe (Recorder)
 სტატიკური ტესტირება
Review -ები შეიძლება კლასიფიცირდეს სხვადასხვა ატრიბუტის მიხედვით. ქვემოთ ჩამოთვლილია
მიმოხილვების ოთხი ყველაზე გავრცელებული ტიპი და მათთან დაკავშირებული ატრიბუტები :

★ Informal Review(e.g. buddy check, pairing, pair review)

★ Walkthrough
★ Technical Review
★ Inspection
 პროდუქტის კოდთან და არქიტექტურასთან
წვდომის მიხედვით
განასხვავებენ :
● White-box testing - კომპონენტის ან სისტემის შიდა სტრუქტურის ანალიზზე დაფუძნებული ტესტიირება. Მნუ ხდება კოდის
ტესტირება და ძირითადად ტესტავს დეველოპერი.
● Black-box testing - ფუნქციონალური ან არაფუნქციონალური ტესტირება სისტემის ან კომპონენტის შიდა სტრუქტურის
ტესტირების გარეშე. Მს არის სპეციფიკაციაზე და სისტემის ქცევაზე დაფუძნებული ტესტირება. Მაგ: ვებ-გვერდს ტესტერი
ტესტავს ისე, რომ არ იცი მისი რეალიზაციის სპეციფიკაცია, ტესტავს მხოლოდ დეველოპერის მიერ მოწოდებულ ველებს ,
მოსალოდნელი შედეგის წყარი არის სპეციფიკაცია (ამოცანა, დიზაინი).
● Grey-box testing - ეს არის შავი და თეთრი ყუთის ტესტირების ერთობლიობა, ანუ ნაწილობრივ ცნობილია შიდა
სტრუქტურაც. მაგ: ვიცით, რომ ღილკაზე „რეგისტრაცია“ დაჭერის დროს, მონაცემები იგზავნება back-ში და იწერება მონაცემთა
ბაზაში არსებულ ცხრილში Users. ასევე გვაქვს წვდომა ბაზაზე და შეგვიძლია დავწერო SELECT ბრძანება, რათა დავრწმუნდე
სისტემის კორექტულად მუშაობაში.
 Test Types

ISTQB-ს მიხედვით არსებობს ტესტირების ტიპების 4 ძირითადი ჯგუფი (ისინი დაჯგუფებულია ხარისხის
მახასიათებლების მიხედვით ):

● Functional
● Non-functional
● White-box (Structural)
● Change related
 Test Types

● ფუნქციონალური - ტესტირების ასეთი ტიპებით ხდება ფუნქციონალური მახასიათებლების შეფასება:

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

მაგალითად:

● აპლიკაციის ძირითადი ფუნქციონალის გადამოწმება

● ძებნის ფუნქციონალი
● მესიჯის მიწერის ფუნქციონალი
● სწორი ერორ-კოდების ჩვენება
● ავტორიზაცია…
 Test Types
● არა-ფუნქციონალური ტესტირება - არა-ფუნქციონალური მახასიათებლების შეფასება: სანდოობა,
performance-ის ეფექტურობა, უსაფრთხოება, გამოყენებადობა (usability). პასუხობს კითხვაზე რამდენად
კარგად, სანდოდ, სწრაფად, დაცულად, მოსახერხებლად ასრულებს ფუნქციონალს პროგრამა.
Non-functional ტესტირება მოიცავს შემდეგ მახასიათებლებს:
Security,
Compatibility,
Cross-browser,
Portability,
Usability /UI,
GUI,
Performance /Efficiency - Load, Stress, Volume, Capacity, Scalability
Reliability,
Localization,
Accessibility,
Installation,
 Test Types
Non-functional testing - Localization testing

(https://www.youtube.com/watch?v=WMQqfdEjcAY)

ასეთი ტიპის ტესტირებას მიმართავენ მაშინ, როდესაც

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

მაგ: სურათზე ნაჩვენებია სხვა ენაზე ველის

დასახელება განსხვავებული სიგრძისაა და ფარავს
ტექსტის შესაყვან ადგილს.
შევცვალე ენა ქართულიდან->ინგლისურზე, მაგრამ გარკვეული წარწერები დარჩა წართულ ენაზე
 Test Types
Non-functional testing - Performance testing :

Load testing - performance ტესტირების ჯგუფს მიეკუთვნება და ეს არის ეტაპობრივად დატვირთვის ტესტირება დასაშვები საზღვრების
ფარგლებში. პროდუქტი შეიძლება დავტვირთოთ ქმედებებით ან მონაცემებით. (მონაცემებით პროდუქტის ეტაპობრივ დატვირთვას ეწოდება
Volume testing ). Load testing იზომება დროიში. Მაგ: საიტზე ერთდროულად იმყოფება 100 მომხმარებელი., ვამოწმებთ 100 მომხმარებლის
მომსახურებას რა დროში ახორციელებს პროგრამა , 200 მომხმარებლის მომსახურებას რა დროში და ა.შ.

Stress testing - ესეც performance ტესტირების ჯგუფს მიეკუთვნება და ვამოწმებთ როგორ იქცევა პროგრამა ძალიან დიდი დატვირთვის
შემთხვევაში (დატვირთვის ზღვარს საკმაოდ მაღლა). Მაგ: თუ დასაშვები მომხმარებლების რეალური რაოდენობა არის 100000 მომხმარებელი
ერთდროულად, ჩვენ ვამოწმებთ 100 მილიონი მომხმარებლის ერთდროულად შემოსვლის დროს რა მოხდება, რა მოუვათ იმ მომხმარებლებს
ვინც უკვე იყვნენ საიტზე შემოსულები, რას დაინახავენ ისინი ვინც ზღვარს ზემოთ შემოვლენ, რა მოუვა მონაცემებს, რომლებზე მუშაობაც
დაწყებული ჰქონდათ მომხმარებლებს?

Capacity testing - ესეც performance ტესტირების ჯგუფს მიეკუთვნება. რეალურად დასაშვები დატვირთვის ზღვარი განსხვავდება
ოფიციალური დასაშვები დატვირთვის ზღვარისგან. ამ ტიპის ტესტირებით დგინდება რეალური დატვირთვის ზღვარი, ანუ რა დატვირთვის
შემდეგ გაფუჭდება რეალურად პროდუქტი. მაგ: ლიფტს აწერია დასაშვები წონა არის 600 კგ, რა თქმა უნდა 601, 602.. კილოგრამ
დატვირთვაზე ლიფტი არ გაფუჭდება, მაგრამ ეტაპობრივი დატვირთვით ვამოწმებთ სად არის რეალური ზღვარი პროდუქტის მწყობრიდან
გამოსვლლის. ეს იმისთვისაც გვჭირდება, რომ შევასრულოთ სტრეს ტესტები.
 Test Types
Non-functional testing - Security testing

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

არაავტორიზებულ მომმარებელს რამდენად აქვს წვდომა პროდუქტთან,

Მამდენად ძლიერია აუტენტიფიკაცია,

რამდენად ინარჩენებს პროგრამული უზრუნველყოფა მონაცემების კონფიდენციალურიბას,

რამდენად დაცულია გარე ჰაკერული თავდასხმებისგან…

უსაფრთხოების ტესტირების სცენარებია:

● პაროლი უნდა იყოს დაშიფრულ ფორმატში

● პროგრამაში არ უნდა იყოს დაშვებული არავალიდური მომხმარებლები
● მოწმდებოდეს ქუქები და სესიის დრო პროგრამისთვის
● ფინანსური გვერდებისთვის არ უნდა იყოს დასაშვები ბრაუზერის უკან დაბრუნების ღილაკით უკან დაბრუნება.
 Test Types
Non-functional testing - Compatibility testing

Compatibility testing ეს არის ტესტირების ტიპი, რომელიც ამოწმებს ჩვენს პროგრამულ

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

● Operating Systems: ჩვენი პროდუქტი რამდენად თავსებადია სხვადასხვა

ოპერატიულ სისტემებზე Windows, Unix, Mac OS,
● Software: რამდენად თავსებადია სხვადასხვა პროგრამულ პროდუქტებთან მაგ MS
Outlook, MS Excel …
● Browser: რამდენად თავსებადია სხვადასხვა ბრაზუზერებთან Firefox, Google
Chrome, Internet Explorer
● Devices: USB port Devices, Printers and Scanners, Other media devices and
Blue tooth.
● Mobile: რამდენად თავსებადია მობილურ პლატფორმებთან Android, iOS
 Test Types
Change-related testing : ცვლილებებთან დკავშირებული ტესტირება

● Re-testing / Confirmation testing - ნიშნავს იმას რომ აღმოჩენილი და აღწერილი ხარვეზი, რომელიც გაასწორა
პროგრამისტმა უნდა გავტესტოთ თავიდან და დავრწმუნდეთ მის სისწორეში. (გავიხსენოთ ბაგ-რეპორტის
სასიცოცხლო ციკლი)

● Regression testing - არის ცვლილების შემდეგ ტესტირება, მაგრამ იტესტება ის ნაწილი, რმელშიც ცვლილება არ
შესულა . ანუ უნდა გადავამოწმოთ, რომ 1 კომპონენტში შესულმა ცვლილებამ ნამდვილად არანაირი იმფაქტი არ
მოახდინა 2 კომპინენტზე, რომელიც საერთოდ არანაირად არ არის 1 კომპინენტთან დაკავშირებული.

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