BA / SE

SE#8.1 საინფორმაციო სისტემის ტესტირება (Software Testing)

Reference: Sommerville, Software Engineering, 10 ed., Chapter 8

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

საინფორმაციო სისტემის ტესტირება –  System Testing

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

Image result for sdlc pictureSDLC – Software Development Life Cycle

სიტემის ტესტირების პროცესი, შეიძლება მიმდინარეობდეს, პროგრამული სისტემის შექმნის საციცოცხლო ციკლის (SDLC – Software Development Life Cycle ) ნებისმიერ ეტაპზე. პრაქტიკული გამოცდილება კი გვიჩვენებს,  სისტემის შექმნის, მატერიალური და არამატერიალური ხარჯების, სისტემური ხარვეზების შემცირების თვალსაზრისით, ტესტირების პროცესი უნდა დაიწყოს სისტემის მოთხოვნების ჩამოყალიბების ეტაპზე და  ამოცანების შესაბამისი სიღრმით გაგრძელდეს მის საბოლოო დასრულებამდე.

სისტემის ტესტირების მიზნებია, სისტემის მომხმარებლისთვის (Customer) და შემქნელისთვის (Developer), ფაქტიურად შექმნილი სისტემის, დაგეგმილ მოთხოვნებთან (System Reqirements) შესაბამისობის დადგენა, სისტემური (defects/errors/bugs) და ოპერაციული ხარვეზების გამოვლენა.

In simple words, testing is executing a system in order to identify any gaps, errors, or missing requirements in contrary to the actual requirements. #1

სისტემის ტესტირების ტიპები – Testing Types

საინფორმაციო სისტემის ტესტირება ხორციელდება არაავტომატური (Manual) და ავტომატური (Automated) სცენარებით (#1).

არაავტომატური (Manual) ტესტირება

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

  1. ტესტირების გეგმას – (Test Plan);
  2.  ტესტირების სტანდარტულ და ალტერნატიულ ალგორითმებს – (Test Cases);
  3. ტესტირების სცენარებს – (Test Scenerios).

და ახდენს ახდენს სისტემის ტესტირებას შემდეგი მიმართულებებით:

  1. Unit testing – სისტემის ცალკეული მოდულების ტესტირება;
  2. Integration testing – სისტემის მოდულებს შორის ურთიერთქმედეების ტესტირება;
  3. System testing – მთლიანი სისტემის ტესტიტება
  4. User Acceptance testing – სისტემის ტესტირება, მისი მომხმარებლის მიერ დაფიქსირებული მოთხოვნებთან შესაბამისობაზე.

ავტომატური (Automated) ტესტირება

ავტომატური მეთოდით სისტემის ტესტირების დროს,  ტესტერი წინასწარ ამზადებს სისტემის ტესტირებისთვის საჭირო სცენარებს, მათ საფუძველზე ქმნის სკრიპტებს (Script) და მათ საფუძველზე, სპეციალიზირებული ავტომატიზირებული  ტესტირების სისტემების (Automated Software Testing Tools) დახმარებით ახდენს სისტემის ტესტირებას.

automated_testing

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

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

Manual Testing Automated Testing
Executing test cases manually without any tool support is known as manual testing. Taking tool support and executing the test cases by using an automation tool is known as automation testing.
Time-consuming and tedious − Since test cases are executed by human resources, it is very slow and tedious. Fast − Automation runs test cases significantly faster than human resources.
Huge investment in human resources − As test cases need to be executed manually, more testers are required in manual testing. Less investment in human resources − Test cases are executed using automation tools, so less number of testers are required in automation testing.
Less reliable − Manual testing is less reliable, as it has to account for human errors. More reliable − Automation tests are precise and reliable.
Non-programmable − No programming can be done to write sophisticated tests to fetch hidden information. Programmable − Testers can program sophisticated tests to bring out hidden information.

ტესტირების მეთოდები –  Testing Methods

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

  1. Black Box Testing – შავი ყუთის ტესტირება;
  2. White Box Testing – თეთრი ყუთის ტესტირება;
  3. Grey Box Testing – ნაცრისფერი ყუთის ტესტირება;

Black Box Testing ( Glass testing or Open box testing) – ტესტირების მეთოდი, იმ შემთხვევაში გამოიყენება, როდესაც ტესტერს არ გააჩნია ინფორმაცია სისტემაში მიმდინარე პროცესების შესახებ. მისთვის ცნობილია ინფორმაცია რომელიც გადაეცემა სისტემას დასამუშავებლად და რას უნდა ელოდეს სისტემისგან.

Black Box Testing-ის მახასიათებელი ფაქტები შემდგომი ანალიზისთვის:

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

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

White Box Testing-ის მახასიათებელი ფაქტები შემდგომი ანალიზისთვის:

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

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

Grey Box Testing-ის მახასიათებელი ფაქტები შემდგომი ანალიზისთვის:

  • წარმოადგენს  Black და White Box ტესტირების კომბინირებას. მათი თანაფარდობა დამოკიდებულია, სისტემის ტესტირებაში მონაწილეთა არსებულ კვალიფიკაციაზე;
  • სისტემის ტესტირების ხარისხი დამოკიდებულია, ტესტირებაში მონაწილეთა,  სისტემის კოდის და არქიტექტურის ცოდნაზე;
  • ტესტირების სცენარები იქმნება სისტემის მომხმარებლების (და არა სისტემის დიზაინერის) მოთხოვნების შესაბამისად;

ტესტირების დონეები – levels of Testing

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

  1. Functional Testing – სისტემის ფუნქციონალური ტესტირება;
  2. Non- functional Testing – სისტემის არაფუნქციონალური ტესტირება.

Functional Testing

Functional Testing  წარმოადგენს,  Black Box –  ტესტირების მეთოდს, რომელიც დაფუძნებულია სისტემის მოთხოვნების (System Requirement) შედარებაზე რეალურად მიღებულ შედეგთან. ამ დროს წინანსწარ მომზადებული მონაცემების საფუძველზე ხდება, სისტემის ფუნქციონირების ფაქტიური შედეგების შედარება მოთხოვნილთან. სისტემის ფუნქციონალის შესამოწმებლად გამოიყენება 5 ნაბიჯიანი პროცესი:

  1. სისტემის მიერ შესასრულებელი ფუნქციონალის მომზადება;
  2. სისტემის ფუნქციონალის შესაბამისად, ტესტირებისთვის საჭირო მონაცემების მომზადება;
  3. სისტემის ოპერირების შედეგად, მოსალოდნელი მონაცემების მომზადება;
  4. მოგროვილი ინფორმაციის საფუძველზე, ტესტირების სცენარების მომზადება;
  5. სისტემის ფუნქციონირების შედეგად, ფაქტიურად მიღებული მონაცემების, მოსალოდნელ მონაცემებთან შედარება.

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

ფუნქციონალური ტესტირების მაგალითებია: Unit Testing, Integration Testing, System Testing, Regression Testing, Acceptance Testing;

სისტემის მოდულების ტესტირება – Unit Testing

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

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

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

  1. Positive test –  ტესტირება კორექტული მონაცემებით – სისტემის წინასწარ მომზადებული,  ნორმალური მონაცემებით და სცენარებით ტესტირება;
  2. Negative Test – ტესტირება სისტემისთვის არაკორექტული მონაცემებით –  სისტემის ტესტირება წინასწარ მომზადებული,  არაკორექტული მონაცემებით და სცენარებით;

კორექტული და არაკორექტული მონაცემებით ტესტირება

In simple words, testing is executing a system in order to identify any gaps, errors, or missing requirements in contrary to the actual requirements. #1

 

სისტემის მოდულების ინტეგრაციის ტესტირება – Integration Testing

საინფორმაციო სისტემის ცალკეული კომპონენტების ურთიერთფუნქციონირების შესამოწმებლად გამოიყენება – Integration Testing. რომელიც ხასიათდება ორი მეთოდით:

  1. Bottom-up integration testing – იწყება სისტემის მცირე კომპონენტების ტესტირებით, შემდეგ ხდება მცირე კომპონენტების შემცველი მოდულების ტესტირება, შემდეგ უფრო მაღალი დონის მოდულების ტესტირება. ტესტირების პროცესი სრულდება მთლიან სისტემის ტესტირებით;
  2. Top-Down integration testing,-პირველად ხდება მაღალი დონის მოდულების ტესტირება, შემდეგ ხდება მათი დაშლა მცირე მოდულებად და მათი ტესტირება. ტესტირების პროცესი სრულდება დაბალი დონის კომპონენტების ტესტირებით.

სრული საინფორმაციო სისტემის ტესტირება – System Testing

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

აღნიშნული ეტაპი, ზემოთ ნახსენები პროგრამული სისტემის შექმნის საციცოცხლო ციკლის (SDLC – Software Development Life Cycle ) მნიშვნელოვანი ნაწილია, რადგან ამ დროს ფასდება შესრულებული პროდუქტის ხარისხი, მისი ოპერირებისთვის განკუთვნილ გარემოსთან მაქსიმალურად მიახლოებულ პირობებში (ფაქტიური პროდუქტის დაგეგმილათან შესაბამისობის ხარისხი – #1).

ცვლილების ზეგავლენის ტესტირება –  Regression Testing (#)

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

Regression testing is a type of software testing which verifies that software which was previously developed and tested still performs correctly after it was changed or interfaced with other software #

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

სიტემის შესაბამისობის ტესტირება – Acceptance Testing

Acceptance Testing – საინფორმაციო სისტემების ხარისხის მართვის ერთ ერთი მნიშვნელოვანი კომპონენტია. აღნიშნული ტიპის ტესტირების დროს, დგინდება სისტემის შექმნისთვის, შეთანხმებული შესაძლებლობების და სერვისის დონის (Quality Management) მოთხოვნების,  რეალურად მიღებული შედეგებთან შედარება, ერთობლივად სისტემის დამკვეთის და შემსრულებელის მიერ (მხარეებს შორის კონტრაქტის საგანი).

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

  • დამკვეთის რეალური  საჭიროებების არევა მის სურვილებში;
  • სისტემის ძირითადი მიზნის არევა ტექნლოგიურ და დიზაინერულ შესაძლებლობებში;
  • სისტემის ან შემკვეთის ძირეული პრობლემის (Root Cause Analysis) არაზუსტად  იდენტიფიცირება;

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

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

აღნიშნული შესასაძლებლობები შედეგად იძლევა, სიტემის შესაბამისობის (Acceptance Testing) ტესტირების გაადვილებას.

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

  • Alpha Testing- სისტემას ტესტავენ, სამუშაო ჯგუფის წევრები. წარმოებს სისტემის ან მისი კომპონენტის, პირველის საცდელი ვერსიის ტესტირება,  სარედაქციო შეცდომების და სისტემის კომპონენტებს შორის დარღვეული კავშირების (Broken Links) კორექტირება.  დაბალი ტექნიკური წარმადობს გარემოში, სიტემის წარმადობის შემოწმება;
  • Beta Testing – სისტემას ტესტავენ და შედეგებს აფიქსირებენ, სისტემის მომხმარებლების სხვადასხვა ჯგუფის წევრები, წარმოებს  სისტემის ფუნქციონალის, რეალურთან მიახლოებულ სცენარებით შემოწმება.

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

სისტემის არა ფუნქციონალური ტესტირება – Non-Functional Testing

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

Non-Functional – არა ფუნქციონალური ტესტირების მაგალითებია:  სისტემის წარმადობის ტესტირება (Performance Testing),   სისტემის სიმარტივის და მომხმარებლისთვის მოსახერხებლობის (Usability Testing) ტესტირება, სისტემის უსაფრთხოების და კიბერ უსაფრთხოების სტანდარტებთან შესაბამისობა (Security and Cyber Security),  სისტემის ან მისი კომპონენტების მრავალჯერადად გამოყენების შესაძლებლობა (Portability Testing).

სისტემის წარმადობის ტესტირება – Performance Testing

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

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

სისტემის მოდელირების (System Modeling) და არქიტექტული დიზაინის შექმნის დროს (Architectural Design) მისი შემდგომი წარმატებული ტესტირებისთვის საჭიროა თვლადი კრიტერიუმების დადგენა შეფასების შემდეგი საზომებით:

  • Quantitative –   რაოდენობრივი, რიცხვითი,  თვლადი – მაგ, ზუსტად 50 გადარიცხვა წამში, 10%-ით მეტი;
  • Qualitative  – არა რიცხვითი, ხარისხობრივი –  – მაგ,  არა ნაკლებ 50 გადარიცხვა წამში; არა ნაკლებ 10%-ით მეტი;
  • Load testing –  სისტემის წარმადობის შეფასება მისთვის მაქსიმალური დატვირთვის შემნით,  ნორმალური და პიკური დატვირთვების მიწოდებით. ამ შემთხვევაში ტესტირების გარემო უმჯობესია განხორციელდეს ავტომატური ტესტირების ინსტრუმენტების საშუალებით.
  • Stress testing – სისტემის წარმადობის შეფასება მისთვის არაკორექტული მონაცემების მიწოდებით, სისტემის არასწორად ავარიულად ფუნქციონირების ინიცირებით. მაგ. საინფორმაციო ქსელის პარამეტრების, ცვლილება, ისეთი პროცესების გაშვება რომელიც იყენებენ დიდი დოზით საინფორმაციო სიტემის რესურსებს. (პროცესორი, მეხსიერება, დისკური მასივი …).

სისტემის სიმარტივე და მომხმარებლისთვის მოსახერხებლობა – Usability Testing

Usability Testing – სისტემის სიმარტივე და მისი მომხმარებლისთვის მოსახერხებლობა, მნიშვნელოვანი საკითხია თანამედროვე ციფრულ სამყაროში. მასზე (User experience (UX)) მნიშვნელოვნადაა დამოკიდებული სისტემის და ბიზნესის განვიტარების წარმატება.

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

  • Efficiency of use – გამოყენების ეფექტურობა;
  • Learn-ability  – შესწავლის სიადვილე;
  • Memorability – სარგებლობის დამახსოვრების სიმარტივე;
  • Errors/safety – სისტემით სარგებლობის დროს შეცდომების არ არსებობა;
  • satisfaction – მომხმარებლის კმაყოფილება;
  • Understund – სისტემის აღქმადობის სიადვილე.

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

აქ უნდა ვთქვათ, რომ, მომხმარებლის ინტერფეისის (User Interface) ტესტირება ამოწმებს, სისტემის გრაფიკული ინტერფეისის შესაბამისობას დიზაინით მოთხოვნილ პარამეტრებთან (System Design). Usability Testing – კი  ტესტავს სისტემის, მომხმარებელთან ურთიერთობის ყველა გზას ზემოთ ნახსენები ხარისხის მართვის კრიტერიუმებით. პირველი წამოადგენს მეორის შემადგენელ ნაწილს.

სისტემის უსაფრთხოების ტესტირება – Security Testing

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

  1. Confidentiality – მონაცემების კონფიდენციალობა;
  2. Integrity – მონაცების მთლიანობა;
  3. Authentication -მონაცემებთან წვდომის კონტროლი;
  4. Availability – მონაცემების გაცემის უზრუნველყოფა;
  5. Authorization – სისტემაში მომხმარებლისთვის მისთვის დადგენილი უფლებების მინიჭება;
  6. Non-repudiation  –  მომხმარებლის მიერ, სისტემაში განხორციელებული ქმედების უარყოფის პრევენციის მექანიზმი;
  7. The software is secure against known and unknown vulnerabilities – სისტემის მდგრადობა ცნობილ  და უცნობ საფრთხეების მიმართ;
  8. Software data is secure – მონაცემთა განთავსების და წვდომის მართვა;
  9. The software is according to all security regulations – სისტემის საინფორმაციო სისტემების უსაფრთხოების სტანდარტებთანშესაბამისობა;
  10. Input checking and validation – სისტემისათვის დასამუშავებლად დამახინჯებული ინფორმაცის გადაცემის პრევენცია და კონტროლი;
  11. SQL insertion attacks –  მონაცემთა ბაზებთან ურთიერთობის საშუალებების კონტროლი;
  12. Injection flaws – მონაცემთა ბაზებთან ურთიერთობის კოდებში, უცხო კოდების ცასმის პრევენცია;
  13. Session management issues – სისტემასტან ურთიერთობის არხების მონიტორინგი და კონტროლი;
  14. Cross-site scripting attacks –  სისტემებს შორის ურთიერთობის არხების უსაფრთხოება და კონტროლი;
  15. Buffer overflows vulnerabilities – მონაცემთა დამუშავების, შუალედური მოდულების გადავსების კონტროლი;
  16. Directory traversal attacks – HTTP  კოდი, რომელიც ცდილობს სისტემის, მონაცემთა სტრუქტურის შესწავლას (#).

ამ კუთხით აქტუალური ხდება, სისტემის საინფორმაციო უსაფრთხოების შემადგენელი კომპონენტის, კიბერ უსაფრთხოების (Cyber Security) გამოწვევებთან მდგრადობა. აღნიშნულ საკითხს განვიხილავთ სპეციალურ სტატიაში (Information Security and Cyber Security)

Image result

მრავალჯერადი გამოყენების ტესტირება – Portability Testing

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

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

სისტემის კომპონენტების შემოწმება და დადასტურება – Verification & Validation

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

S.N. Verification (შემოწმება) Validation  (დადასტურება)
1 Verification addresses the concern: “Are you building it right?”

ვაკეთებთ თუ არა სწორად?

Validation addresses the concern: “Are you building the right thing?”

ვაკეთებთ თუ არა სწორ პროდუქტს?

2 Ensures that the software system meets all the functionality.

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

Ensures that the functionalities meet the intended behavior.

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

3 Verification takes place first and includes the checking for documentation, code, etc.

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

Validation occurs after verification and mainly involves the checking of the overall product.

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

4 Done by developers.

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

Done by testers.

ასრულებს სისტემის ტესტერი.

5 It has static activities, as it includes collecting reviews, walkthroughs, and inspections to verify a software.

მოიცავს, სტანდარტულ და სტატიკურ აქტივობებს.

It has dynamic activities, as it includes executing the software against the requirements.

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

6 It is an objective process and no subjective decision should be needed to verify a software.

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

It is a subjective process and involves subjective decisions on how well a software works.

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

დამატებითი მასალა:

  • Software Testing Tools #1, #2, #3, #4
  • Software Testing Standards #1, #2, #3
  • SDLC – Software Development Life Cycle  #1, #2
  • Software Testing  #1, #2, #3, #4, #5, #6, #7, #8
  • Software Testing  Fundamentals   #1
  • Regression Testing #1
  • Software Codding Online Terminals – CodingGround;
  • Software testing methods, levels, and types #1#2

  • How to Write a Test Plan #1

  • SDLC – Software Development Life Cycle  #1#2
  • Quality Management #1
  • Risk Management #1
  • UAT – User Acceptance Testing #1, #2
  • Root Cause Analysis #1
  • Qualitative vs. Quantitative #1, #2, #3
  • Information Security and Cyber Security #1, #2, #3, #4

კითხვები:

  1. აღწერეთ პროგრამული სისტემის ტესტირების პროცესი –  SOFTWARE TESTING LIFE CYCLE (STLC)
  2. მოახდინეთ სისტემების არაავომატიზირებული (Manual) და ავტომატიზირებული (Automated) სცენარების შედარებითი ანალიზი;
  3. როდის შეიძლება დაიწყოს სისტემის ტესტირებაზე მუშაობა?
  4. როდის არის უმჯობესი სისტემის ტესტირებაზე მუშაობა და რატომ?
  5. დაასახელეთ სისტემის ტესტირების მეთოდები და მოახდინეთ მათი შედარებითი ანალიზი.
  6. ჩამოთვალეთ და დაახასიათეთ, ფუნქციონალური ტესტირების საშუალებები;
  7. ჩამოთვალეთ და დაახასიათეთ, არა ფუნქციონალური ტესტირების საშუალებები;
  8. როგორ გესმით სტატიაში არსებული შემდეგი წინადადება “პროდუქტის, მისი ოპერირებისთვის განკუთვნილ გარემოში, ფუნქციონირების ხარისხი”. რამდენად კორექტულია იგი, რას უნდა ნიშნავდეს იგი და თქვენ როგორ მოახდენდით მის ფუნქციონირებას?
  9. მოახდინეთ Verification და Validation –  დახასიათება, გამოყენების სფერო და შედარებითი ანალიზი.
Advertisements

4 thoughts on “SE#8.1 საინფორმაციო სისტემის ტესტირება (Software Testing)

  1. Pingback: SE# Information Security | The Digital Times

  2. Pingback: SE#9.1 Software evolution | The Digital Times

  3. Pingback: SE#10.1 System Dependability | IN@TIMES

  4. Pingback: SE#2.1 საინფორმაციო სისტემების შექმნის პროცესი – Software Processes | IN@TIMES

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s