ტესტირება თეთრი ყუთი
გამოყენებადობის ტესტირება
ა) დატვირთვის ტესტირება
შესრულების ტესტირება
ფუნქციური ტესტირება
ტესტირება პროგრამული უზრუნველყოფა
ტესტირება არის პროგრამის (ან პროგრამის ნაწილის) შესრულების პროცესი შეცდომების აღმოჩენის განზრახვით (ან მიზნით).
არსებობს რამდენიმე კრიტერიუმი, რომლითაც ჩვეულებრივ ხდება ტესტირების ტიპების კლასიფიკაცია. ჩვეულებრივ, შემდეგი ნიშნები გამოირჩევა:
ი) ტესტირების ობიექტის მიხედვით:
(პროგრამული და აპარატურის სისტემის ან მოწყობილობის მუშაობისა და რეაგირების დროის ინდიკატორების განსაზღვრა ან შეგროვება გარე მოთხოვნის საპასუხოდ, ამ სისტემის მოთხოვნებთან შესაბამისობის დადგენის მიზნით)
ბ) სტრეს ტესტირება
(აფასებს სისტემის საიმედოობას და სტაბილურობას ნორმალური მუშაობის საზღვრების გადაჭარბების პირობებში.)
გ) სტაბილურობის ტესტირება
4) მომხმარებლის ინტერფეისის ტესტირება
5) უსაფრთხოების ტესტირება
6) ლოკალიზაციის ტესტირება
7) თავსებადობის ტესტირება
II) სისტემის ცოდნით:
1) შავი ყუთის ტესტირება
(მიმდინარეობს ტესტირების ობიექტი, რომლის შიდა სტრუქტურა უცნობია)
(შემოწმებულია პროგრამის შიდა სტრუქტურა, ტესტის მონაცემები მიიღება პროგრამის ლოგიკის ანალიზით)
III) ავტომატიზაციის ხარისხით:
1) ხელით ტესტირება
2) ავტომატური ტესტირება
3) ნახევრად ავტომატური ტესტირება
IV) კომპონენტების იზოლაციის ხარისხის მიხედვით:
1) კომპონენტის (ერთეულის) ტესტირება
2) ინტეგრაციის ტესტირება
3) სისტემის ტესტირება
V) ტესტირების დროისთვის:
1) ალფა ტესტირება- პროგრამის დახურული ტესტირების პროცესი სრულ განაკვეთზე დეველოპერების ან ტესტერების მიერ. ალფა პროდუქტი ყველაზე ხშირად მხოლოდ 50%-ით არის დასრულებული, არის პროგრამის კოდი, მაგრამ დიზაინის მნიშვნელოვანი ნაწილი აკლია.
2) ბეტა ტესტირება- მძიმე გამოყენება დასრულებული ვერსიაპროგრამები, რათა გამოავლინოს შეცდომების მაქსიმალური რაოდენობა მის მუშაობაში, მათი შემდგომი აღმოფხვრის მიზნით, ბაზარზე საბოლოო შესვლამდე, მასობრივი მომხმარებლისთვის. ტესტირებაში ჩართული არიან მოხალისეები რიგითი მომავალი მომხმარებლებიდან.
პროგრამული უზრუნველყოფის შემოწმება უფრო ზოგადი კონცეფციაა, ვიდრე ტესტირება. შემოწმების მიზანია უზრუნველყოს, რომ შემოწმებული ობიექტი (მოთხოვნები ან პროგრამის კოდი) აკმაყოფილებს მოთხოვნებს, განხორციელებულია არასასურველი ფუნქციების გარეშე და აკმაყოფილებს დიზაინის სპეციფიკაციებსა და სტანდარტებს. ISO 9000-2000). გადამოწმების პროცესი მოიცავს ინსპექტირებას, კოდის ტესტირებას, ტესტის შედეგების ანალიზს, პრობლემის ანგარიშების გენერირებას და ანალიზს. ამრიგად, ზოგადად მიღებულია, რომ ტესტირების პროცესი არის შემადგენელი ნაწილიაგადამოწმების პროცესი.
სანქტ-პეტერბურგი
სახელმწიფო ელექტროტექნიკური უნივერსიტეტი
MOEM დეპარტამენტი
დისციპლინის მიხედვით
"პროგრამული უზრუნველყოფის განვითარების პროცესი"
"პროგრამული უზრუნველყოფის შემოწმება"
პეტერბურგი
შემოწმების მიზანი………………………………………………………………… გვერდი 3
შესავალი შენიშვნები……………………………………………………………….. გვერდი 3
სპეციალური და ზოგადი მიზნები………………………………………….. გვერდი 4
მოსალოდნელი პრაქტიკა მიზნების მიხედვით…………………………………… გვერდი 4
SG1 მზადება ვერიფიკაციისთვის…………………………………………………… გვერდი 4
SG2 გამოცდების ჩატარება (თანატოლების შეფასება)………………………… გვერდი 7
SG3 ვერიფიკაციის განხორციელება…………………………………………………….. გვერდი 9
დანართი 1. გადამოწმების პროცესის ავტომატიზაციის ხელსაწყოების მიმოხილვა………….. გვერდი 11
დანართი 2. მთავარი თანამედროვე მიდგომებიშესამოწმებლად…………….. გვერდი 12
გამოყენებული ლიტერატურის სია…………………………………………….. გვერდი 14
ბრწყინვალებისა და სიმწიფის ინტეგრირებული მოდელი
დადასტურება (სიმწიფის დონე 3)
სამიზნე
შემოწმების მიზანიაუზრუნველყოფს გარანტიას, რომ შერჩეული შუა პროგრამა ან საბოლოო პროდუქტი აკმაყოფილებს მითითებულ მოთხოვნებს.
წყლის შენიშვნები
პროგრამული პროდუქტების შემოწმება არის მზა პროდუქტის ან მისი შუალედური ვერსიების შემოწმებაორიგინალური მოთხოვნების დასაკმაყოფილებლად. ეს გულისხმობს არა მხოლოდ თავად პროგრამის ტესტირებას, არამედ პროექტის, მომხმარებლის და ტექნიკური დოკუმენტაციის აუდიტს და ა.შ.
პროგრამული სისტემის შემოწმების მიზანია შეცდომების იდენტიფიცირება და მოხსენება, რომლებიც შეიძლება დაშვებული იყოს სასიცოცხლო ციკლის ეტაპებზე. გადამოწმების ძირითადი ამოცანები:
მაღალი დონის მოთხოვნების სისტემის მოთხოვნებთან შესაბამისობის დადგენა;
სისტემის არქიტექტურაში მაღალი დონის მოთხოვნების გათვალისწინებით;
შესაბამისობა არქიტექტურასთან და მის მოთხოვნებთან საწყის კოდში;
შესრულებადი კოდის სისტემის მოთხოვნებთან შესაბამისობის დადგენა;
ზემოაღნიშნული ამოცანების გადასაჭრელად გამოყენებული საშუალებების განსაზღვრა, რომლებიც ტექნიკურად გამართულია და საკმარისად დასრულებული.
ვერიფიკაცია მოიცავს მზა პროდუქციის შემოწმებას და შუალედური პროდუქტების შემოწმებას ყველა შერჩეული მოთხოვნის შესაბამისად, მომხმარებელთა მოთხოვნების ჩათვლით, მზა პროდუქციის მოთხოვნები და მოთხოვნები მისი ცალკეული კომპონენტების მიმართ.
გადამოწმება არსებითად არის ინკრემენტული (ინკრემენტული) პროცესი მისი დაწყების მომენტიდან პროდუქციის განვითარებისა და პროდუქტებზე მუშაობის მთელი პერიოდის განმავლობაში. გადამოწმება იწყება მოთხოვნების შემოწმებით, შემდეგ მოჰყვება ყველა შუალედური პროდუქტის შემოწმებას მათი განვითარებისა და წარმოების სხვადასხვა ეტაპზე და მთავრდება საბოლოო პროდუქტის შემოწმებით.
შუალედური პროდუქტების გადამოწმება მათი განვითარებისა და წარმოების თითოეულ ეტაპზე მნიშვნელოვნად ზრდის ალბათობას, რომ საბოლოო პროდუქტი დააკმაყოფილებს მომხმარებლის მოთხოვნებს, მზა პროდუქტის მოთხოვნებს და მის ცალკეულ კომპონენტებს.
პროცესების გადამოწმება და ვალიდაცია არსებითად დაკავშირებული პროცესებია, თუმცა მიზნად ისახავს განსხვავებული შედეგების მიღებას. ვალიდაციის მიზანია იმის დემონსტრირება, რომ მზა პროდუქტი რეალურად ასრულებს თავის თავდაპირველ დანიშნულებას. შემოწმება მიზნად ისახავს დარწმუნდეს, რომ პროდუქტი ზუსტად აკმაყოფილებს გარკვეულ მოთხოვნებს. სხვა სიტყვებით რომ ვთქვათ, გადამოწმება უზრუნველყოფს, რომ ” სწორად აკეთებ", და დადასტურება არის ის, რომ " თქვენ სწორად აკეთებთ”.
გადამოწმება უნდა განხორციელდეს რაც შეიძლება ადრე შესაბამის პროცესებში (როგორიცაა მიწოდება, განვითარება, ექსპლუატაცია ან ტექნიკური მომსახურება) ხარჯების ეფექტურობისა და შესრულების შესაფასებლად. ეს პროცესი შეიძლება მოიცავდეს ანალიზს, გადამოწმებას და ტესტირებას (ტესტირებას).
ეს პროცესი შეიძლება შესრულდეს შემსრულებლების დამოუკიდებლობის სხვადასხვა ხარისხით. შემსრულებელთა დამოუკიდებლობის ხარისხი შეიძლება განაწილდეს როგორც თავად ორგანიზაციის სხვადასხვა სუბიექტს, ასევე სხვა ორგანიზაციის სუბიექტებს შორის, პასუხისმგებლობების განაწილების სხვადასხვა ხარისხით. ამ პროცესს ეწოდება პროცესი დამოუკიდებელი შემოწმებათუ განმახორციელებელი ორგანიზაცია დამოუკიდებელია გამყიდველისგან, დეველოპერისგან, ოპერატორის ან შემსრულებლისგან.
ექსპერტთა შეფასებები (ექსპერტიზა) წარმოადგენს გადამოწმების მნიშვნელოვან ნაწილს, როგორც კარგად ჩამოყალიბებულ ინსტრუმენტს დეფექტების ეფექტური აღმოფხვრისთვის. ამისგან მნიშვნელოვანი გამოსავალია პროდუქტის სამუშაო ვერსიების უფრო ღრმა გაგებისა და გაგების აუცილებლობა, ისევე როგორც სამუშაო პროცესები, რომლებიც გამოიყენება შესაძლო დეფექტების გამოსავლენად და საჭიროების შემთხვევაში გაუმჯობესების შესაძლებლობის შესაქმნელად.
გამოცდები მოიცავს ექსპერტების მიერ შესრულებული სამუშაოს მეთოდურ შესწავლას დეფექტების და სხვა საჭირო ცვლილებების გამოვლენის მიზნით.
ექსპერტიზის შეფასების ძირითადი მეთოდებია:
შემოწმება
ბოლოდან ბოლომდე სტრუქტურული კონტროლი
დადასტურებისა და გადამოწმების ორი ცნება ხშირად ერთმანეთში აირია. გარდა ამისა, სისტემური მოთხოვნების დადასტურება ხშირად აირია სისტემის ვალიდაციასთან. მე გთავაზობთ ამ საკითხის შესწავლას.
სტატიაში განვიხილე ობიექტების მოდელირების ორი მიდგომა: მთლიანობაში და როგორც სტრუქტურაში. მიმდინარე სტატიაში დაგვჭირდება ეს დაყოფა.
დავუშვათ, რომ გვაქვს შექმნილი ფუნქციური ობიექტი. მოდით ეს ობიექტი ჩვენ მიერ ჩაითვალოს სხვა ფუნქციური ობიექტის კონსტრუქციის ნაწილად. დაე, იყოს ობიექტის კონსტრუქციის აღწერა, ისეთი, რომ იგი შეიცავს ობიექტის აღწერას. ასეთ აღწერილობაში ობიექტს აქვს აღწერილობა მთლიანობაში, ანუ მისი ურთიერთქმედების ინტერფეისები სხვა ობიექტებთან აღწერილია ობიექტის კონსტრუქციის ფარგლებში. მიეცით ობიექტის, როგორც სტრუქტურის აღწერა. დაე, არსებობდეს საინფორმაციო ობიექტი, რომელიც შეიცავს მოთხოვნებს ობიექტის, როგორც სტრუქტურის აღწერის დიზაინისთვის. დაე არსებობდეს ცოდნის ერთობლიობა, რომელიც შეიცავს დასკვნის წესებს, რომელთა საფუძველზეც ობიექტის, როგორც სტრუქტურის აღწერა მიიღება მთლიანი ობიექტის აღწერიდან. ცოდნის მთლიანობა არის ის, რასაც დიზაინერებს ასწავლიან ინსტიტუტებში - ბევრი, ბევრი ცოდნა. ისინი საშუალებას აძლევს, ობიექტის შესახებ ცოდნის საფუძველზე, შეიმუშაონ მისი სტრუქტურა.
ასე რომ, შეგიძლიათ დაიწყოთ. შეგვიძლია ვთქვათ, რომ თუ ობიექტი მთლიანობაში სწორად არის აღწერილი, თუ ცოდნის მთლიანობა სწორია და თუ დაცული იყო დასკვნის წესები, მაშინ ობიექტის კონსტრუქციის შედეგად მიღებული აღწერა სწორი იქნება. ანუ, ამ აღწერილობის საფუძველზე, შესაბამისი ფუნქციური ობიექტი რეალური პირობებიოპერაცია. რა რისკები შეიძლება წარმოიშვას:
1. ობიექტის შესახებ არასწორი ცოდნის გამოყენება. ობიექტის მოდელი ხალხის გონებაში შეიძლება არ შეესაბამებოდეს რეალობას. მათ არ იცოდნენ, მაგალითად, მიწისძვრების რეალური საფრთხე. შესაბამისად, ობიექტების მოთხოვნები შეიძლება არასწორად იყოს ჩამოყალიბებული.
2. ობიექტის შესახებ ცოდნის არასრული ჩანაწერი - რაღაც გამოტოვებულია, დაშვებულია შეცდომები. მაგალითად, მათ იცოდნენ ქარების შესახებ, მაგრამ დაავიწყდათ ამის ხსენება. ამან შეიძლება გამოიწვიოს ობიექტის მოთხოვნების არასაკმარისად სრული აღწერა.
3. არასწორი ცოდნა. გვასწავლეს მასის უპირატესობა სხვა პარამეტრებთან შედარებით, მაგრამ აღმოჩნდა, რომ სიჩქარის გაზრდა მოგვიწია.
4. დასკვნის წესების არასწორი გამოყენება ობიექტის აღწერილობაში. ლოგიკური შეცდომები, რაღაც აკლია ობიექტის დიზაინის მოთხოვნებს, მოთხოვნების კვალი გატეხილია.
5. სისტემის დიზაინის შესახებ მიღებული დასკვნების არასრული ჩანაწერი. ყველაფერი გათვალისწინებული იყო, ყველაფერი გათვლილი იყო, მაგრამ დაწერა დაავიწყდათ.
6. შექმნილი სისტემა არ ემთხვევა აღწერილობას.
ცხადია, რომ პროექტის ყველა არტეფაქტი, როგორც წესი, დასრულებული სახით ჩნდება მხოლოდ პროექტის ბოლოს, და მაშინაც კი, არა ყოველთვის. მაგრამ, თუ ჩავთვლით, რომ განვითარება ჩანჩქერია, მაშინ რისკები ისეთია, როგორიც აღვწერე. თითოეული რისკის შემოწმება არის სპეციფიკური ოპერაცია, რომელსაც შეიძლება დაერქვას სახელი. თუ ვინმეს აინტერესებს, შეგიძლიათ სცადოთ მოიფიქროთ და გაახმოვანოთ ეს პირობები.
რა არის გადამოწმება? რუსულად, გადამოწმება არის წესების დაცვის შემოწმება. წესები დოკუმენტის სახითაა. ანუ უნდა არსებობდეს დოკუმენტი დოკუმენტაციის მოთხოვნებით. თუ დოკუმენტაცია აკმაყოფილებს ამ დოკუმენტის მოთხოვნებს, მაშინ მან გაიარა შემოწმება.
რა არის დადასტურება? რუსულად, დადასტურება არის დასკვნების სისწორის შემოწმება. ანუ, უნდა არსებობდეს ცოდნის მთელი რიგი, რომელიც აღწერს, თუ როგორ უნდა მივიღოთ დიზაინის აღწერა ობიექტის მონაცემებზე დაყრდნობით. ამ დასკვნების გამოყენების სისწორის შემოწმება დადასტურებაა. ვალიდაცია, სხვა საკითხებთან ერთად, არის აღწერილობის შემოწმება თანმიმდევრულობის, სისრულისა და გასაგებად.
მოთხოვნების დადასტურება ხშირად აირია ამ მოთხოვნებზე აგებული პროდუქტის ვალიდაციასთან. არ ღირს ამის გაკეთება.
გუნდში შედის ორზე მეტი ადამიანი, აუცილებლად აყენებს საკითხს გუნდში როლების, უფლებებისა და მოვალეობების განაწილების შესახებ. როლების კონკრეტული ნაკრები განისაზღვრება მრავალი ფაქტორით - განვითარების მონაწილეთა რაოდენობა და მათი პირადი პრეფერენციები, განვითარების მეთოდოლოგია, პროექტის მახასიათებლები და სხვა ფაქტორები. განვითარების თითქმის ნებისმიერ გუნდში შეიძლება გამოიყოს შემდეგი როლები. ზოგიერთი მათგანი შეიძლება სრულიად არ იყოს, ხოლო ცალკეულ ადამიანებს შეუძლიათ ერთდროულად შეასრულონ რამდენიმე როლი, მაგრამ საერთო შემადგენლობა ოდნავ იცვლება.კლიენტი (განმცხადებელი). ეს როლი ეკუთვნის ორგანიზაციის წარმომადგენელს, რომელმაც შეუკვეთა სისტემის განვითარება. როგორც წესი, განმცხადებელი შეზღუდულია ურთიერთქმედებაში და ურთიერთობს მხოლოდ პროექტის მენეჯერებთან და სერტიფიცირების ან განხორციელების სპეციალისტთან. ჩვეულებრივ, მომხმარებელს უფლება აქვს შეცვალოს პროდუქტის მოთხოვნები (მხოლოდ მენეჯერებთან თანამშრომლობით), წაიკითხოს დიზაინისა და სერტიფიცირების დოკუმენტაცია, რომელიც გავლენას ახდენს შემუშავებული სისტემის არატექნიკურ მახასიათებლებზე.
Პროექტის მენეჯერი. ეს როლი უზრუნველყოფს კომუნიკაციის არხს მომხმარებელსა და პროექტის გუნდს შორის. პროდუქტის მენეჯერი მართავს მომხმარებლის მოლოდინებს და ავითარებს და ინარჩუნებს ბიზნეს კონტექსტს პროექტისთვის. მისი მუშაობა პირდაპირ არ არის დაკავშირებული გაყიდვასთან, ის ორიენტირებულია პროდუქტზე, მისი ამოცანაა განსაზღვროს და უზრუნველყოს მომხმარებლის მოთხოვნები. პროექტის მენეჯერს უფლება აქვს შეცვალოს პროდუქციის მოთხოვნები და პროდუქტის საბოლოო დოკუმენტაცია.
Პროგრამული მენეჯერი. ეს როლი მართავს კომუნიკაციებსა და ურთიერთობებს პროექტის გუნდში, მოქმედებს როგორც კოორდინატორი, ავითარებს და მართავს ფუნქციურ სპეციფიკაციებს, ინახავს პროექტის განრიგს და ანგარიშებს პროექტის სტატუსზე და იწყებს პროექტისთვის კრიტიკულ გადაწყვეტილებებს.
ტესტირება- პროგრამის შესრულების პროცესი შეცდომის აღმოსაჩენად.
ტესტის მონაცემები- შეყვანები, რომლებიც გამოიყენება სისტემის შესამოწმებლად.
ტესტის სიტუაცია (ტესტის შემთხვევა)- შეყვანები სისტემის შესამოწმებლად და მოსალოდნელი გამომავალი შეყვანის მიხედვით, თუ სისტემა მუშაობს მოთხოვნების სპეციფიკაციის შესაბამისად.
კარგი საცდელი შემთხვევა- სიტუაცია, რომელსაც აქვს ჯერ კიდევ გამოუცნობი შეცდომის გამოვლენის დიდი ალბათობა.
იღბლიანი ტესტი- ტესტი, რომელიც აღმოაჩენს ჯერ კიდევ გამოუვლენელ შეცდომას.
შეცდომა- პროგრამისტის მოქმედება განვითარების ეტაპზე, რაც იწვევს იმ ფაქტს, რომ პროგრამული უზრუნველყოფა შეიცავს შიდა დეფექტს, რომელიც პროგრამის მუშაობის დროს შეიძლება გამოიწვიოს არასწორი შედეგი.
უარი- სისტემის არაპროგნოზირებადი ქცევა, რაც იწვევს მოულოდნელ შედეგს, რაც შეიძლება გამოწვეული იყოს მასში არსებული დეფექტებით.
ამრიგად, პროგრამული უზრუნველყოფის ტესტირების პროცესში, როგორც წესი, მოწმდება შემდეგი.
გადამოწმება და დადასტურება ( შემოწმება და დადასტურება-V& v)შექმნილია პროგრამული უზრუნველყოფის სწორი შესრულებისა და კლიენტის სპეციფიკაციებთან და მოთხოვნებთან შესაბამისობის გასაანალიზებლად, შესამოწმებლად. პროგრამებისა და სისტემების სისწორის შემოწმების ეს მეთოდები შესაბამისად ნიშნავს:
- გადამოწმება არის სისტემის შექმნის სისწორის შემოწმება მისი სპეციფიკაციის შესაბამისად;
- ვალიდაცია არის სისტემისთვის მითითებული მოთხოვნების შესრულების სისწორის შემოწმება.
გადამოწმება ხელს უწყობს დასკვნის გაკეთებას შექმნილი სისტემის სისწორის შესახებ მისი დიზაინისა და განვითარების დასრულების შემდეგ. ვალიდაცია საშუალებას გაძლევთ დაადგინოთ მითითებული მოთხოვნების მიზანშეწონილობა და მოიცავს უამრავ მოქმედებას სწორი პროგრამებისა და სისტემების მისაღებად, კერძოდ:
- ინსპექტირებისა და კონტროლის პროცედურების დაგეგმვა დიზაინის გადაწყვეტილებებიდა მოთხოვნები;
- პროგრამის დიზაინის ავტომატიზაციის დონის უზრუნველყოფა CASE- საშუალებებით;
- პროგრამების სწორი ფუნქციონირების შემოწმება სამიზნე ტესტების კომპლექტებზე ტესტირების მეთოდებით;
- პროდუქტის ადაპტაცია სამუშაო გარემოსთან და ა.შ.
ვალიდაცია ახორციელებს ამ აქტივობებს სასიცოცხლო ციკლის ეტაპებზე სპეციფიკაციებისა და დიზაინის შედეგების განხილვითა და შემოწმებით, რათა დაადასტუროს, რომ არსებობს საწყისი მოთხოვნების სწორად შესრულება და რომ მითითებული პირობები და შეზღუდვები დაკმაყოფილებულია. შემოწმებისა და ვალიდაციის ამოცანები მოიცავს მოთხოვნების სპეციფიკაციის სისრულის, თანმიმდევრულობისა და გაურკვევლობის შემოწმებას და სისტემის ფუნქციების შესრულების სისწორეს.
შემოწმება და დადასტურება ექვემდებარება:
- სისტემის ძირითადი კომპონენტები;
- კომპონენტების (პროგრამული, ტექნიკური და საინფორმაციო) ინტერფეისები და ობიექტების ურთიერთქმედება (პროტოკოლები და შეტყობინებები), რომლებიც უზრუნველყოფენ სისტემის დანერგვას განაწილებულ გარემოში;
- მონაცემთა ბაზასა და ფაილებზე წვდომის საშუალებები (ტრანზაქციები და შეტყობინებები) და დაცვის საშუალებების შემოწმება სხვადასხვა მომხმარებლის მონაცემებზე არასანქცირებული წვდომისგან;
- დოკუმენტაცია პროგრამული უზრუნველყოფის და მთლიანად სისტემისთვის;
- ტესტები, ტესტირების პროცედურები და შეყვანის მონაცემები.
სხვა სიტყვებით რომ ვთქვათ, პროგრამის სისწორის ძირითადი სისტემატური მეთოდებია:
- გადამოწმება PS კომპონენტების და მოთხოვნების სპეციფიკაციის ვალიდაცია;
- PS შემოწმებაპროგრამის შესაბამისობის დადგენა მოცემულ სპეციფიკაციებთან;
- ტესტირება PS-ის გამომავალი კოდი ტესტის მონაცემებზე კონკრეტულ საოპერაციო გარემოში, რათა გამოავლინოს სხვადასხვა ხარვეზებით, ანომალიებით, აღჭურვილობის გაუმართაობით ან სისტემის ავარიით გამოწვეული შეცდომები და დეფექტები (იხ. თავი 9).
ISO/IEC 3918-99 და 12207 მოიცავს გადამოწმებისა და ვალიდაციის პროცესებს. მათთვის განსაზღვრულია მიზნები, ამოცანები და მოქმედებები შექმნილი პროდუქტის (მათ შორის სამუშაო, შუალედური პროდუქტების) სისწორის სასიცოცხლო ციკლის ეტაპებზე და მის მოთხოვნებთან შესაბამისობის შესამოწმებლად.
გადამოწმებისა და ვალიდაციის პროცესების მთავარი ამოცანაა შეამოწმეთ და დაადასტურეთრომ საბოლოო პროგრამული უზრუნველყოფა შეესაბამება დანიშნულებას და აკმაყოფილებს მომხმარებლის მოთხოვნებს. ეს პროცესები საშუალებას გაძლევთ იდენტიფიციროთ შეცდომები სასიცოცხლო ციკლის ეტაპების სამუშაო პროდუქტებში, მათი წარმოშობის მიზეზების გარკვევის გარეშე, ასევე დაადგინოთ პროგრამული უზრუნველყოფის სისწორე მის სპეციფიკაციასთან მიმართებაში.
ეს პროცესები ურთიერთდაკავშირებულია და განისაზღვრება ერთი ტერმინით - „დამოწმება და დადასტურება“ (V&V 7).
შემოწმება ხორციელდება:
- ცალკეული კომპონენტების გამომავალ კოდში თარგმნის სისწორის შემოწმება, აგრეთვე ინტერფეისის აღწერილობები კომპონენტების ურთიერთობის კვალიფიკაციის გზით დამკვეთის განსაზღვრული მოთხოვნების შესაბამისად;
- ფაილებზე ან მონაცემთა ბაზაზე წვდომის სისწორის ანალიზი, მონაცემების მანიპულირებისა და შედეგების გადაცემისთვის გამოყენებული სისტემის ინსტრუმენტებში მიღებული პროცედურების გათვალისწინებით;
- კომპონენტების დაცვის საშუალებების შემოწმება მომხმარებლის მოთხოვნებთან შესაბამისობისთვის და მათი მიკვლევა.
სისტემის ცალკეული კომპონენტების შემოწმების შემდეგ ხდება მათი ინტეგრაცია, ასევე ინტეგრირებული სისტემის შემოწმება და ვალიდაცია. სისტემა ტესტირებულია მრავალ სატესტო კომპლექტზე, რათა დადგინდეს, არის თუ არა საცდელი კომპლექტები ადეკვატური და საკმარისი ტესტის დასასრულებლად და სისტემის სისწორის დასადგენად.
ოფიციალური ვერიფიკაციის შესახებ საერთაშორისო პროექტის შექმნის იდეა შემოგვთავაზა ტ. ჰოარემ, იგი განიხილეს დამოწმებული პროგრამული უზრუნველყოფის სიმპოზიუმზე 2005 წლის თებერვალში კალიფორნიაში. შემდეგ, იმავე წლის ოქტომბერში, ციურიხში გამართულ IFIP კონფერენციაზე, მიღებულ იქნა საერთაშორისო პროექტი 15 წლის ვადით, რათა შეემუშავებინა "ინსტრუმენტების ჰოლისტიკური ავტომატური ნაკრები PS-ის სისწორის შესამოწმებლად".
მან ჩამოაყალიბა შემდეგი ძირითადი ამოცანები:
- აგების ერთიანი თეორიის შემუშავება და პროგრამების ანალიზი;
- ყველა საწარმოო ეტაპისთვის დამადასტურებელი ინსტრუმენტების ყოვლისმომცველი ინტეგრირებული ნაკრების შექმნა, მათ შორის სპეციფიკაციების შემუშავება და მათი გადამოწმება, ტესტის შემთხვევების გენერირება, პროგრამების დახვეწა, ანალიზი და გადამოწმება;
- ფორმალური სპეციფიკაციებისა და დამოწმებული პროგრამული ობიექტების საცავის შექმნა განსხვავებული ტიპებიდა ტიპები.
ეს პროექტი ვარაუდობს, რომ გადამოწმება მოიცავს პროგრამული უზრუნველყოფის სისწორის შექმნისა და შემოწმების ყველა ასპექტს და გახდება პანაცეა ყველა უსიამოვნებისთვის, რომელიც დაკავშირებულია შექმნილ პროგრამებში შეცდომების მუდმივ წარმოშობასთან.
განსაზღვრული პროგრამების დადასტურებისა და გადამოწმების მრავალი ფორმალური მეთოდი გამოცდილია პრაქტიკაში. შესრულებულია დიდი სამუშაოსაერთაშორისო კომიტეტი ISO/IEC ფარგლებში ISO სტანდარტი/ IEC 12207:2002 პროგრამული უზრუნველყოფის შემოწმებისა და ვალიდაციის პროცესების სტანდარტიზაციის შესახებ. სხვადასხვა პროგრამირების ობიექტების ფორმალური მეთოდებით სისწორის შემოწმება პერსპექტიულია.
საცავი არის პროგრამების, სპეციფიკაციებისა და ხელსაწყოების საცავი, რომლებიც გამოიყენება შემუშავებისა და ტესტირების, მზა კომპონენტების, ხელსაწყოებისა და მეთოდების ბლანკების შეფასებისას. მას აქვს შემდეგი ზოგადი ამოცანები:
- დამოწმებული სპეციფიკაციების, მტკიცებულების მეთოდების, პროგრამის ობიექტების და კოდის დანერგვა რთული აპლიკაციებისთვის;
- სხვადასხვა გადამოწმების მეთოდების დაგროვება, მათი დიზაინი იმ ფორმით, რომელიც შესაფერისია ძიებისა და რეალიზებული თეორიული იდეის შემდგომი გამოყენებისთვის შერჩევისთვის;
- სხვადასხვა პროგრამირების ობიექტების, აგრეთვე ხელსაწყოებისა და მზა სისტემების ფორმალური სპეციფიკაციების დაყენებისა და გაცვლის სტანდარტული ფორმების შემუშავება;
- თავსებადობისა და ურთიერთქმედების მექანიზმების შემუშავება მზა დამოწმებული პროდუქტების საცავიდან ახალ განაწილებულ და ქსელურ გარემოში გადასატანად ახალი PS-ების შესაქმნელად.
ეს პროექტი 50 წლის განმავლობაში უნდა განვითარდეს. ადრინდელი პროექტები მსგავს მიზნებს ადგენდნენ: პროგრამული უზრუნველყოფის ხარისხის გაუმჯობესება, სერვისის მოდელების ფორმალიზება, სირთულის შემცირება PIC-ის გამოყენებით, შეცდომების ვიზუალური დიაგნოსტიკისა და აღმოფხვრის გამართვის ხელსაწყოების შექმნა და ა.შ. ვიზუალური გამართვის ან მიღწევის გრძნობა Მაღალი ხარისხიჩართულია. განვითარების პროცესი გრძელდება.
ახალი საერთაშორისო პროგრამული უზრუნველყოფის გადამოწმების პროექტი თავისი მონაწილეებისგან მოითხოვს არა მხოლოდ ცოდნას თეორიული ასპექტებიპროგრამის სპეციფიკაციები, არამედ მაღალკვალიფიციური პროგრამისტები მისი განხორციელებისთვის უახლოეს წლებში.
