პროგრამული გადამოწმების მეთოდებში. გადამოწმების ადგილი პროგრამული უზრუნველყოფის განვითარების პროცესებს შორის. შემოწმებისა და კვალიფიკაციის დაგეგმვა
20. შემოწმება და დამოწმება პროგრამული უზრუნველყოფა
გადამოწმება და ვალიდაცია არის ტესტირებისა და განხილვის პროცესები, რომლებიც ადასტურებენ, რომ პროგრამული უზრუნველყოფა აკმაყოფილებს მის სპეციფიკაციებსა და მომხმარებლის მოთხოვნებს. გადამოწმება და სერტიფიცირება მოიცავს პროგრამული უზრუნველყოფის სრულ სასიცოცხლო ციკლს - ისინი იწყება მოთხოვნების ანალიზის ეტაპზე და მთავრდება პროგრამის კოდის გადამოწმებით მზა პროგრამული სისტემის ტესტირების ეტაპზე.
გადამოწმება და სერტიფიცირება არ არის იგივე, თუმცა მათი აღრევა ადვილია. მოკლედ, მათ შორის განსხვავება შეიძლება განისაზღვროს შემდეგნაირად:
ვერიფიკაცია პასუხობს კითხვას, სწორად შეიქმნა თუ არა სისტემა;
სერთიფიკატი პასუხობს კითხვას, მუშაობს თუ არა სისტემა სწორად.
ამ განმარტებების მიხედვით, ვერიფიკაცია ამოწმებს პროგრამული უზრუნველყოფის შესაბამისობას სისტემის სპეციფიკაციებთან, კერძოდ, ფუნქციურ და არაფუნქციონალურ მოთხოვნებთან. სერტიფიცირება უფრო ზოგადი პროცესია. სერტიფიცირების დროს აუცილებელია იმის უზრუნველყოფა, რომ პროგრამული პროდუქტი აკმაყოფილებს მომხმარებლის მოლოდინებს. სერტიფიცირება მოჰყვება შემოწმებას, რათა დადგინდეს, რამდენად აკმაყოფილებს სისტემა არა მხოლოდ სპეციფიკაციებს, არამედ მომხმარებლის მოლოდინებსაც.
როგორც უკვე აღვნიშნეთ, პროგრამული უზრუნველყოფის განვითარების ადრეულ ეტაპებზე, სისტემის მოთხოვნების სერტიფიცირება ძალიან მნიშვნელოვანია. მოთხოვნებში ხშირია შეცდომები და ხარვეზები; ასეთ შემთხვევებში, საბოლოო პროდუქტი სავარაუდოდ არ დააკმაყოფილებს მომხმარებლის მოლოდინს. მაგრამ, რა თქმა უნდა, მოთხოვნების ვალიდაცია ვერ განსაზღვრავს ყველა პრობლემას მოთხოვნების სპეციფიკაციაში. ზოგჯერ მოთხოვნების ხარვეზები და შეცდომები აღმოჩენილია მხოლოდ სისტემის დანერგვის დასრულების შემდეგ.
გადამოწმებისა და სერტიფიცირების პროცესები იყენებს ორ ძირითად ტექნიკას სისტემების გადამოწმებისა და ანალიზისთვის.
1. პროგრამული უზრუნველყოფის შემოწმება.გაანალიზეთ და გადაამოწმეთ სხვადასხვა სისტემის წარმოდგენები, როგორიცაა მოთხოვნების სპეციფიკაციის დოკუმენტაცია, არქიტექტურული დიაგრამები ან პროგრამის საწყისი კოდი. ინსპექტირება ხორციელდება პროგრამული სისტემის განვითარების პროცესის ყველა ეტაპზე. შემოწმების პარალელურად შეიძლება განხორციელდეს ავტომატური ანალიზიპროგრამების წყაროს კოდი და მასთან დაკავშირებული დოკუმენტები. ინსპექტირება და ავტომატური ანალიზი არის სტატიკური შემოწმებისა და ვალიდაციის მეთოდები, რადგან ისინი არ საჭიროებენ შესრულებად სისტემას.
2. პროგრამული უზრუნველყოფის ტესტირება.გაუშვით შესრულებადი კოდი ტესტის მონაცემებით და შეამოწმეთ პროგრამული პროდუქტის გამომავალი და შესრულების მახასიათებლები, რათა დაადასტუროთ, რომ სისტემა მუშაობს სწორად. ტესტირება არის გადამოწმებისა და სერტიფიცირების დინამიური მეთოდი, რადგან ის გამოიყენება გაშვებულ სისტემაზე.
ნახ. ნახაზი 20.1 გვიჩვენებს ინსპექტირებისა და ტესტირების ადგილს პროგრამული უზრუნველყოფის დამუშავების პროცესში. ისრები მიუთითებს განვითარების პროცესის იმ ეტაპებზე, რომლებზეც შესაძლებელია ამ მეთოდების გამოყენება. ამ სქემის მიხედვით, ინსპექტირება შეიძლება განხორციელდეს სისტემის განვითარების პროცესის ყველა ეტაპზე, ხოლო ტესტირება შეიძლება განხორციელდეს იმ შემთხვევებში, როდესაც შეიქმნა პროტოტიპი ან შესრულებადი პროგრამა.
ინსპექტირების მეთოდები მოიცავს: პროგრამის შემოწმებას, წყაროს კოდის ავტომატურ ანალიზს და ოფიციალურ გადამოწმებას. მაგრამ სტატიკურ მეთოდებს შეუძლიათ მხოლოდ შეამოწმონ პროგრამების შესაბამისობა სპეციფიკაციებთან; მათი გამოყენება შეუძლებელია სისტემის სწორი ფუნქციონირების შესამოწმებლად. გარდა ამისა, არაფუნქციური მახასიათებლები, როგორიცაა შესრულება და საიმედოობა, არ შეიძლება გადამოწმდეს სტატიკური მეთოდების გამოყენებით. ამიტომ, არაფუნქციური მახასიათებლების შესაფასებლად, ტარდება სისტემის ტესტირება.
ბრინჯი. 20.1. სტატიკური და დინამიური გადამოწმება და სერტიფიცირება
მიუხედავად პროგრამული უზრუნველყოფის ინსპექტირების ფართო გამოყენებისა, ტესტირება კვლავ გადამოწმებისა და სერტიფიცირების უპირატესი მეთოდია. ტესტირება არის პროგრამების მუშაობის ტესტი რეალური მონაცემების მსგავსი მონაცემებით, რომლებიც დამუშავდება სისტემის მუშაობის დროს. პროგრამაში დეფექტებისა და შეუსაბამობების არსებობა გამოვლენილია გამომავალი მონაცემების შესწავლით და მათ შორის ანომალიების გამოვლენით. ტესტირება ტარდება სისტემის დანერგვის ეტაპზე (შესამოწმებლად, რომ სისტემა აკმაყოფილებს დეველოპერების მოლოდინებს) და მისი დანერგვის დასრულების შემდეგ.
პროგრამული უზრუნველყოფის განვითარების პროცესის სხვადასხვა ეტაპზე გამოიყენება სხვადასხვა ტიპის ტესტირება.
1. დეფექტების ტესტირებახორციელდება პროგრამასა და მის სპეციფიკაციას შორის შეუსაბამობების გამოსავლენად, რომლებიც გამოწვეულია პროგრამების შეცდომებით ან დეფექტებით. ასეთი ტესტები შექმნილია სისტემაში არსებული შეცდომების იდენტიფიცირებისთვის და არა მისი მუშაობის სიმულაციისთვის.
2. სტატისტიკური ტესტირებააფასებს პროგრამების მუშაობას და საიმედოობას, ასევე სისტემის მუშაობას სხვადასხვა ოპერაციულ რეჟიმში. ტესტები შექმნილია რეალური სისტემის მუშაობის სიმულაციისთვის რეალური შეყვანის მონაცემებით. სისტემის საიმედოობა ფასდება პროგრამების ფუნქციონირებისას დაფიქსირებული წარუმატებლობების რაოდენობით. შესრულება ფასდება ოპერაციების სრული შესრულების დროისა და სისტემის რეაგირების დროის გაზომვით ტესტის მონაცემების დამუშავებისას.
შემოწმებისა და კვალიფიკაციის მთავარი მიზანია უზრუნველყოს, რომ სისტემა არის „მიზანშეწონილი“. პროგრამული სისტემის შესაბამისობა მის დანიშნულ დანიშნულებასთან არ ნიშნავს, რომ ის სრულიად უშეცდომოდ უნდა იყოს. პირიქით, სისტემა კარგად უნდა ემსახურებოდეს იმ მიზნებს, რისთვისაც ის იყო განკუთვნილი. საჭიროების დონე შესაბამისობის საიმედოობადამოკიდებულია სისტემის დანიშნულებაზე, მომხმარებლის მოლოდინებსა და პირობებზე პროგრამული უზრუნველყოფის ბაზარზე.
1. პროგრამული უზრუნველყოფის დანიშნულება.შესაბამისობაში ნდობის დონე დამოკიდებულია იმაზე, თუ რამდენად კრიტიკულია შემუშავებული პროგრამული უზრუნველყოფა გარკვეული კრიტერიუმების მიხედვით. მაგალითად, უსაფრთხოების კრიტიკული სისტემების ნდობის დონე მნიშვნელოვნად უნდა იყოს უფრო მაღალი, ვიდრე პროტოტიპის პროგრამული სისტემების ნდობის დონე, რომელიც შემუშავებულია ახალი იდეების დემონსტრირებისთვის.
2. მომხმარებლის მოლოდინები.სამწუხაროა იმის აღნიშვნა, რომ ამჟამად მომხმარებელთა უმეტესობას დაბალი პროგრამული მოთხოვნები აქვს. მომხმარებლები იმდენად არიან მიჩვეულები პროგრამების გაშვების დროს წარმოქმნილ წარუმატებლობებს, რომ მათ ეს არ უკვირს. ისინი მზად არიან მოითმინონ სისტემის უკმარისობა, თუ მისი გამოყენების სარგებელი აღემატება მინუსებს. თუმცა, 1990-იანი წლების დასაწყისიდან, მომხმარებლის ტოლერანტობა პროგრამულ სისტემებში წარუმატებლობის მიმართ თანდათან მცირდება. ბოლო დროს არასანდო სისტემების შექმნა პრაქტიკულად მიუღებელი გახდა, ამიტომ პროგრამული პროდუქტების შემქმნელმა კომპანიებმა სულ უფრო მეტი ყურადღება უნდა მიაქციონ პროგრამული უზრუნველყოფის შემოწმებას და სერტიფიცირებას.
3. პროგრამული უზრუნველყოფის ბაზრის პირობები.პროგრამული სისტემის შეფასებისას, გამყიდველმა უნდა იცოდეს კონკურენტი სისტემები, ფასი, რომელიც მყიდველს სურს გადაიხადოს სისტემაში და სისტემის ბაზარზე გამოშვების მიზნობრივი თარიღი. თუ დეველოპერულ კომპანიას ჰყავს რამდენიმე კონკურენტი, აუცილებელია სისტემის ბაზარზე შესვლის თარიღის დადგენა სრული ტესტირებისა და გამართვის დასრულებამდე, წინააღმდეგ შემთხვევაში კონკურენტები შეიძლება იყვნენ პირველები ბაზარზე. თუ მომხმარებელს არ სურს შეიძინოს პროგრამული უზრუნველყოფა მაღალ ფასად, მათ შეიძლება მოითმინონ მეტი სისტემის უკმარისობა. ყველა ეს ფაქტორი უნდა იყოს გათვალისწინებული შემოწმებისა და სერტიფიცირების პროცესის ხარჯების განსაზღვრისას.
როგორც წესი, გადამოწმებისა და სერტიფიცირების დროს სისტემაში აღმოჩენილია შეცდომები. სისტემაში ცვლილებები ხდება შეცდომების გამოსასწორებლად. ეს გამართვის პროცესიროგორც წესი, ინტეგრირებულია სხვა გადამოწმებისა და კვალიფიკაციის პროცესებთან. თუმცა, ტესტირება (ან უფრო ზოგადად, გადამოწმება და სერტიფიცირება) და გამართვა არის სხვადასხვა პროცესი, რომელსაც აქვს განსხვავებული მიზნები.
1. დამოწმება და სერტიფიცირება არის პროგრამული სისტემის ხარვეზების გამოვლენის პროცესი.
2. გამართვა არის დეფექტების (შეცდომების) ლოკალიზაციის და მათი გამოსწორების პროცესი (ნახ. 20.2).
ბრინჯი. 20.2. გამართვის პროცესი
პროგრამების გამართვის მარტივი მეთოდები არ არსებობს. გამოცდილი გამმართველები აღმოაჩენენ შეცდომებს ტესტის გამომავალი შაბლონების შესამოწმებელი სისტემების გამომავალთან შედარების გზით. შეცდომის პოვნა მოითხოვს შეცდომების ტიპების, გამომავალი შაბლონების, პროგრამირების ენისა და პროგრამირების პროცესის ცოდნას. ძალიან მნიშვნელოვანია პროგრამული უზრუნველყოფის განვითარების პროცესის ცოდნა. გამართავებმა იციან პროგრამისტის ყველაზე გავრცელებული შეცდომები (მაგალითად, ის, რაც დაკავშირებულია მრიცხველის მნიშვნელობის გაზრდასთან). ასევე მხედველობაში მიიღება გარკვეული პროგრამირების ენებისთვის დამახასიათებელი შეცდომები, მაგალითად ის, რაც დაკავშირებულია მაჩვენებლების გამოყენებასთან C ენაში.
პროგრამის კოდში შეცდომების დადგენა ყოველთვის არ არის მარტივი პროცესი, რადგან შეცდომა აუცილებლად არ არის განლაგებული პროგრამის კოდის იმ ადგილის მახლობლად, სადაც პრობლემა წარმოიშვა. შეცდომების ლოკალიზაციისთვის, გამართვის პროგრამისტი ავითარებს დამატებით პროგრამულ ტესტებს, რომლებიც ხელს უწყობენ პროგრამის შეცდომის წყაროს იდენტიფიცირებას. შეიძლება საჭირო გახდეს პროგრამის შესრულების ხელით თვალყურის დევნება.
ინტერაქტიული გამართვის ხელსაწყოები არის ენის მხარდაჭერის ინსტრუმენტების ნაკრების ნაწილი, რომლებიც ინტეგრირებულია კოდის შედგენის სისტემასთან. ისინი უზრუნველყოფენ პროგრამის შესრულების სპეციალურ გარემოს, რომლის მეშვეობითაც შესაძლებელია იდენტიფიკატორების ცხრილისა და იქიდან ცვლადის მნიშვნელობების წვდომა. მომხმარებლები ხშირად აკონტროლებენ პროგრამის შესრულებას ეტაპობრივად, თანმიმდევრულად გადადიან განცხადებიდან განცხადებაში. ყოველი განცხადების შესრულების შემდეგ მოწმდება ცვლადების მნიშვნელობები და გამოვლენილია შესაძლო შეცდომები.
პროგრამაში აღმოჩენილი შეცდომა გამოსწორებულია, რის შემდეგაც საჭიროა პროგრამის ხელახლა შემოწმება. ამისათვის შეგიძლიათ კვლავ შეამოწმოთ პროგრამა ან გაიმეოროთ წინა ტესტირება. ხელახალი ტესტირება გამოიყენება იმის უზრუნველსაყოფად, რომ პროგრამაში განხორციელებულმა ცვლილებებმა სისტემაში ახალი შეცდომები არ შეიტანა, რადგან პრაქტიკაში „შეცდომის გამოსწორების“ მაღალი პროცენტი ან მთლიანად ვერ ხერხდება, ან პროგრამაში ახალი შეცდომები შემოდის.
პრინციპში, ყოველი შესწორების შემდეგ ხელახალი ტესტირებისას, ყველა ტესტი ხელახლა უნდა ჩატარდეს, მაგრამ პრაქტიკაში ეს მიდგომა ძალიან ძვირია. ამიტომ, ტესტირების პროცესის დაგეგმვისას, განისაზღვრება სისტემის ნაწილებს შორის დამოკიდებულებები და თითოეულ ნაწილს ენიჭება ტესტები. ამის შემდეგ შესაძლებელია პროგრამული უზრუნველყოფის ელემენტების მიკვლევა ამ ელემენტებზე მორგებული სპეციალური სატესტო შემთხვევების (ტესტის მონაცემების) გამოყენებით. თუ კვალის შედეგები დოკუმენტირებულია, მაშინ ტესტის მონაცემების მთელი ნაკრების მხოლოდ ქვეჯგუფი შეიძლება გამოყენებულ იქნას შეცვლილი პროგრამული ელემენტისა და მისი დამოკიდებული კომპონენტების შესამოწმებლად.
ვერიფიკაცია (სისწორის დადასტურება) - მოიცავს შემუშავებული პროგრამის სისწორის შემოწმებას და დადასტურებას სპეციფიკაციაში წარმოდგენილ ფორმალურ განცხადებებთან მიმართებაში და ამ პროგრამის შეყვანისა და გამომავალი მონაცემების ურთიერთკავშირის სრულად განსაზღვრას. ამ შემთხვევაში, ცვლადებს შორის კავშირი პროგრამის შეყვანასა და გამომავალში გაანალიზებულია არა მნიშვნელობების სახით, როგორც ტესტირებისას, არამედ მათი თვისებების აღწერის სახით, რომლებიც ვლინდება ამ კონტროლირებადი ცვლადების ნებისმიერი დამუშავების დროს. პროგრამაში.
პროგრამის გადამოწმება, პრინციპში, გამორიცხავს ტესტირებისა და გამართვის აუცილებლობას, რადგან ამავდროულად, ყველა ცვლადის კონცეფციისა და აღწერილობის უფრო მაღალ დონეზე დადგენილია პროცესების სისწორე, მათი დამუშავება და გარდაქმნები.
თითოეული პროგრამის არსი შეიძლება წარმოდგენილი იყოს შეყვანისა და გამომავალი მონაცემების ურთიერთობის აღწერით. ეს ურთიერთობები ფორმალურია 1 პროგრამული სპეციფიკაციით. რეალურ მოვლენებში ამ ურთიერთობების ფორმალიზაცია ცუდი არ არის და ზოგიერთი ურთიერთობა ირკვევა პროგრამის შემუშავების პროცესში. ასეთი არასრულად განსაზღვრული არ არის საკმარისი პროგრამების სისწორის დასამტკიცებლად. მხოლოდ შეყვანისა და გამომავალი მონაცემების ყველა პირობისა და კავშირის სრული და ზუსტი ფორმალიზაციით არის შესაძლებელი მათი გამოყენება ავტომატური გადამოწმებისთვის.
ინდუქციური განცხადებების მეთოდი.
ამ მეთოდის შესასწავლად პროგრამას მიეწოდება განცხადებები მისი ცვლადების თვისებების შესახებ გარკვეულ წერტილებში:
ა) შეყვანის ცვლადები არ იცვლება პროგრამის შესრულებისას;
ბ) აღწერილია ცვლადების მდგომარეობა შუალედურ წერტილებში;
გ) გამომავალი ცვლადები აღწერილია პროგრამის დასრულების შემდეგ ცვლადებს შორის ურთიერთობის გამოყენებით.
გადამოწმება შედგება თანმიმდევრული დემონსტრირებისგან, რომ შეყვანის ცვლადები და პირველ ეტაპზე შესრულებული გარდაქმნებიდან გამომდინარეობს მომდევნო შუალედურ წერტილში ჩამოყალიბებული განცხადების ჭეშმარიტება.
პროგრამების შესამოწმებლად საჭიროა სამი ენა:
· პროგრამული ტექსტების წერის ენა;
· ვერიფიკაციის პირობების ფორმულირების ენა;
· ფორმირების ენა და სისწორის დადასტურება.
ვინაიდან ეს ენები მნიშვნელოვნად განსხვავდება, ეს გარემოება გადამოწმების ერთ-ერთი აპლიკაციაა.
სისწორის დადასტურებას აქვს შემდეგი უპირატესობები:
1. წარმოადგენს მკაფიო ფორმალიზებულ პროცესს.
2. საჭიროებს ანალიზს. სისწორის დადასტურების პროცესი შესაძლებელს ხდის პროგრამების ნაწილების შესწავლას, რომლებიც სხვაგვარად გაანალიზებული იქნებოდა მხოლოდ შემთხვევით.
3. აზუსტებს გამოთვლების შუალედურ შედეგებს. გამონათქვამების ჩაწერა აიძულებს პროგრამისტს მკაფიოდ ჩამოაყალიბოს თავისი ვარაუდები პროგრამის შერჩეულ წერტილებზე გამოთვლების შედეგების შესახებ.
4. ამოიცნობს დამოკიდებულებებს. პროგრამების დადასტურების პროცესში, ადამიანი იწყებს იმის გაგებას, თუ რა ვარაუდები შეყვანის მონაცემების შესახებ არ არის აშკარად ტესტირება პროგრამის სხვადასხვა ნაწილში.
მეთოდის ნაკლოვანებები:
1. სირთულე; თუნდაც პატარებისთვის მარტივი პროგრამებიგამოთვლები ძალიან რთულია, რამაც შეიძლება გამოიწვიოს შეცდომები.
2. შეცდომები მეთოდის სირთულიდან გამომდინარე, ადვილია შეცდომების დაშვება როგორც დასამტკიცებელი დებულებების ფორმირებაში, ასევე მტკიცებულებაში.
3. სირთულეები მასივებთან მუშაობისას.
4. ძლიერი მათემატიკური აპარატის ნაკლებობა.
5. შრომის მაღალი ინტენსივობა პროგრამის ტესტირება უფრო მეტ შრომას მოითხოვს, ვიდრე მის დაწერას (2-დან 6-ჯერ).
6. გამომსახველობის ნაკლებობა. ხშირად ადვილი არ არის მომგებიანი განცხადების ჩამოყალიბება, რაც ინტუიციურად ძალიან მარტივი გამოთვლაა:
7. გაგების სირთულე.
8. ტრენინგის საჭიროება. ეს მეთოდი მოითხოვს ვრცელ მომზადებას და მომზადებას.
ამ კურსის მიზანია პროგრამული უზრუნველყოფის გადამოწმების პროცესის ყოვლისმომცველი წარმოდგენა. განხილვის საგანია სხვადასხვა მიდგომები და მეთოდები, რომლებიც გამოიყენება ვერიფიკაციის და, კერძოდ, პროგრამული ტესტირების სფეროში. ვარაუდობენ, რომ შემუშავებული პროგრამული უზრუნველყოფა უფრო მეტის ნაწილია საერთო სისტემა. ასეთი სისტემა მოიცავს აპარატურულ, საინფორმაციო და ორგანიზაციულ (ადამიანის მომხმარებელი, ადამიანის ოპერატორი და ა.შ.) კომპონენტებს, რომლებიც შესაძლოა შემუშავდეს სხვადასხვა გუნდის მიერ. აქედან გამომდინარე, საჭიროა განვითარების დოკუმენტები, რომლებიც განსაზღვრავს მოთხოვნებს სისტემის სხვადასხვა კომპონენტების მიმართ და მათი ურთიერთქმედების წესებს. გარდა ამისა, ვარაუდობენ, რომ სისტემის გაუმართაობამ შეიძლება გამოიწვიოს ამა თუ იმ სიმძიმის შედეგები, შესაბამისად, პროგრამული უზრუნველყოფის შემუშავების დროს, ფარული დეფექტების იდენტიფიცირებაზე დახარჯული ძალისხმევა აუცილებელია და გამართლებულია. უპირველეს ყოვლისა, ეს ეხება პროგრამული უზრუნველყოფის გადამოწმების ინსტრუმენტებსა და პროცედურებს. კურსი მოიცავს რიგს პრაქტიკული გაკვეთილები, ასახავს მარტივი სისტემის, როგორც მაგალითის გამოყენებით, პროგრამული უზრუნველყოფის შემოწმების ტექნიკას და მეთოდებს Microsoft Visual Studio 2005 Team Edition პროგრამული ტესტერებისთვის გარემოში. ეს პუბლიკაცია არის კურსის ბიბლიოთეკის ნაწილი, რომელიც ვითარდება MSDN აკადემიური ალიანსის (MSDN AA) აკადემიური თანამშრომლობის პროგრამის ფარგლებში.
ქვემოთ მოყვანილი ტექსტი მიღებულია ორიგინალური PDF დოკუმენტიდან ავტომატური ამოღებით და გამიზნულია, როგორც გადახედვა.
არ არის სურათები (სურათები, ფორმულები, გრაფიკები).
ბრინჯი. 7 ტესტირება, დადასტურება და ვალიდაციის პროგრამული უზრუნველყოფის შემოწმება – მეტი ზოგადი კონცეფციავიდრე ტესტირება. შემოწმების მიზანია უზრუნველყოს, რომ შემოწმებული ელემენტი (მოთხოვნები ან პროგრამის კოდი) აკმაყოფილებს მოთხოვნებს, განხორციელებულია არასასურველი ფუნქციების გარეშე და აკმაყოფილებს დიზაინის სპეციფიკაციებსა და სტანდარტებს. გადამოწმების პროცესი მოიცავს ინსპექტირებას, კოდის ტესტირებას, ტესტის შედეგების ანალიზს, პრობლემის ანგარიშების გენერირებას და ანალიზს. ამრიგად, ზოგადად მიღებულია, რომ ტესტირების პროცესი არის შემადგენელი ნაწილიაგადამოწმების პროცესი, იგივე ვარაუდი კეთდება ამ სასწავლო კურსზე. პროგრამული სისტემის ვალიდაცია არის პროცესი, რომლის მიზანია დაამტკიცოს, რომ სისტემის განვითარების შედეგად ჩვენ მივაღწიეთ იმ მიზნებს, რის მიღწევასაც ვგეგმავდით მისი გამოყენებით. სხვა სიტყვებით რომ ვთქვათ, ვალიდაცია არის იმის შემოწმება, რომ სისტემა აკმაყოფილებს მომხმარებლის მოლოდინებს. ვალიდაციასთან დაკავშირებული საკითხები სცილდება ამ სფეროს სავარჯიშო კურსიდა წარმოადგენს ცალკე საინტერესო თემას შესასწავლად. თუ შეხედავთ ამ სამ პროცესს იმ კითხვის თვალსაზრისით, რომელსაც ისინი პასუხობენ, ტესტირება პასუხობს კითხვას "როგორ კეთდება ეს?" ან „შემუშავებული პროგრამის ქცევა აკმაყოფილებს მოთხოვნებს?“, გადამოწმება – „რა გაკეთდა?“ ან „აკმაყოფილებს თუ არა განვითარებული სისტემა მოთხოვნებს?“ და ვალიდაცია არის „გააკეთა ის, რაც სჭირდებოდა?“ ან "აკმაყოფილებს თუ არა განვითარებული სისტემა მომხმარებლის მოლოდინებს?" 1.7. სასიცოცხლო ციკლის სხვადასხვა ეტაპზე შექმნილი დოკუმენტაცია განვითარების ყველა ეტაპის სინქრონიზაცია ხდება დოკუმენტების დახმარებით, რომლებიც იქმნება თითოეულ ეტაპზე. დოკუმენტაცია ასევე იქმნება სწორ ხაზზე ცხოვრების ციკლი– პროგრამული სისტემის შემუშავებისას და პირიქით – მისი გადამოწმებისას. ვცადოთ V- ფორმის სასიცოცხლო ციკლის მაგალითის გამოყენებით დავაკვირდეთ, თუ რა ტიპის დოკუმენტები იქმნება თითოეულ სეგმენტზე და რა კავშირები არსებობს მათ შორის (ნახ. 8). სისტემური მოთხოვნების შემუშავების ეტაპის შედეგია ფორმულირებული სისტემური მოთხოვნები - აღწერის დოკუმენტი ზოგადი პრინციპებისისტემის მუშაობა, მისი ურთიერთქმედება " გარემო» - სისტემის მომხმარებლები, ასევე პროგრამული უზრუნველყოფა და აპარატურა, რომლებიც უზრუნველყოფენ მის მუშაობას. როგორც წესი, სისტემის მოთხოვნების პარალელურად, იქმნება ვერიფიკაციის გეგმა და განისაზღვრება ვერიფიკაციის სტრატეგია. ეს დოკუმენტები განსაზღვრავს ზოგადი მიდგომა როგორ ჩატარდება ტესტირება, რა ტექნიკა იქნება გამოყენებული, მომავალი სისტემის რა ასპექტები უნდა დაექვემდებაროს ფრთხილად ტესტირებას. გადამოწმების სტრატეგიის განსაზღვრით გადაჭრილი კიდევ ერთი ამოცანა არის სხვადასხვა გადამოწმების პროცესის ადგილმდებარეობის და განვითარების პროცესებთან მათი კავშირის დადგენა. 20 სისტემის მოთხოვნებთან მუშაობის გადამოწმების პროცესი არის მოთხოვნების ვალიდაციის პროცესი და მათი შედარება მომხმარებლის რეალურ მოლოდინებთან. წინ რომ ვიხედოთ, ვთქვათ, რომ ვალიდაციის პროცესი განსხვავდება მზა სისტემის მომხმარებლისთვის გადაცემისას ჩატარებული მიღების ტესტებისგან, თუმცა ის შეიძლება ჩაითვალოს ასეთი ტესტების ნაწილად. ვალიდაცია არის არა მხოლოდ სისტემის დანერგვის სისწორის დამკვეთის თვალსაზრისით, არამედ მის შემუშავების საფუძვლად მყოფი პრინციპების სისწორის დასამტკიცებელი საშუალება. ბრინჯი. 8 პროგრამული სისტემების შემუშავების პროცესები და დოკუმენტები სისტემური მოთხოვნები არის ფუნქციონალური მოთხოვნებისა და პროექტის არქიტექტურის შემუშავების პროცესის საფუძველი. ამ პროცესის დროს მუშავდება ზოგადი მოთხოვნები სისტემური პროგრამული უზრუნველყოფის მიმართ და ფუნქციები, რომლებიც მან უნდა შეასრულოს. ფუნქციური მოთხოვნები ხშირად მოიცავს სისტემის ქცევის ნიმუშების განსაზღვრას ნორმალურ და არანორმალურ სიტუაციებში, მონაცემთა დამუშავების წესებს და მომხმარებლის ინტერფეისის განმარტებებს. მოთხოვნის ტექსტი, როგორც წესი, შეიცავს სიტყვებს „უნდა, უნდა“ და აქვს ფორმის სტრუქტურა „თუ ABC სენსორზე ტემპერატურის მნიშვნელობა აღწევს 30 გრადუს ცელსიუსს ან მეტს, სისტემამ უნდა შეწყვიტოს აუდიო სიგნალის გაცემა. ” ფუნქციური მოთხოვნები წარმოადგენს სისტემის არქიტექტურის შემუშავების საფუძველს - აღწერს მის სტრუქტურას იმ ენის ქვესისტემებისა და სტრუქტურული ერთეულების მიხედვით, რომლებშიც ხორციელდება განხორციელება - სფეროები, კლასები, მოდულები, ფუნქციები და ა.შ. ფუნქციონალური მოთხოვნებიდან გამომდინარე, იწერება ტესტის მოთხოვნები - დოკუმენტები, რომლებიც შეიცავს ძირითადი პუნქტების განსაზღვრას, რომლებიც უნდა შემოწმდეს ფუნქციური მოთხოვნების სწორად შესრულების უზრუნველსაყოფად. ხშირად ტესტის მოთხოვნები იწყება სიტყვებით "Test That" და შეიცავს მითითებებს მათ შესაბამის ფუნქციურ მოთხოვნებზე. ზემოაღნიშნული ფუნქციონალური მოთხოვნილების ტესტის მოთხოვნების მაგალითი იქნება „დაამოწმეთ, რომ ABC სენსორზე ტემპერატურა 30 გრადუს ცელსიუსზე დაბლა ეცემა, სისტემა გამოსცემს გამაფრთხილებელ სიგნალს“ და „დაამოწმეთ, რომ როდესაც ტემპერატურის მნიშვნელობა ABC სენსორზე 30-ზე მეტია. გრადუსი ცელსიუსით“, სისტემა არ აწარმოებს ხმოვან სიგნალს. 21 ერთ-ერთი პრობლემა, რომელიც წარმოიქმნება ტესტის მოთხოვნების დაწერისას, არის ზოგიერთი მოთხოვნის ფუნდამენტური შეუმოწმებლობა, მაგალითად, მოთხოვნა „მომხმარებლის ინტერფეისი უნდა იყოს ინტუიციური“ არ შეიძლება შემოწმდეს მკაფიო განმარტების გარეშე, თუ რას წარმოადგენს ინტუიციური ინტერფეისი. ასეთი არასპეციფიკური ფუნქციონალური მოთხოვნები, როგორც წესი, შემდგომში იცვლება. სისტემის არქიტექტურული მახასიათებლები ასევე შეიძლება გახდეს სატესტო მოთხოვნების შექმნის წყარო, რომელიც ითვალისწინებს სისტემის პროგრამული უზრუნველყოფის დანერგვის მახასიათებლებს. ასეთი მოთხოვნის მაგალითია, მაგალითად, „შეამოწმეთ, რომ ტემპერატურის მნიშვნელობა ABC სენსორზე არ აღემატებოდეს 255-ს“. ფუნქციონალური მოთხოვნებისა და არქიტექტურიდან გამომდინარე, იწერება სისტემის კოდი და მის შესამოწმებლად, მზადდება ტესტის გეგმა ტესტის მოთხოვნების საფუძველზე - ტესტის შემთხვევების თანმიმდევრობის აღწერა, რომელიც ამოწმებს სისტემის განხორციელების შესაბამისობას მოთხოვნებთან. თითოეული ტესტის შემთხვევა შეიცავს სისტემის შეყვანისთვის მიწოდებული მნიშვნელობების სპეციფიკურ აღწერას, გამოსავალზე მოსალოდნელ მნიშვნელობებს და ტესტის შესრულების სცენარის აღწერას. ტესტის ობიექტიდან გამომდინარე, ტესტის გეგმა შეიძლება მომზადდეს ან პროგრამის სახით რომელიმე პროგრამირების ენაზე, ან შეყვანის მონაცემთა ფაილის სახით ინსტრუმენტთა ნაკრებისთვის, რომელიც ახორციელებს ტესტირების სისტემას და გადასცემს მას მნიშვნელობებს. მითითებულია ტესტის გეგმაში, ან მომხმარებლის სისტემის ინსტრუქციის სახით, რომელიც აღწერს აუცილებელ მოქმედებებს, რომლებიც უნდა განხორციელდეს სისტემის სხვადასხვა ფუნქციების შესამოწმებლად. ყველა სატესტო შემთხვევის განხორციელების შედეგად გროვდება სტატისტიკა ტესტირების წარმატებულობის შესახებ - ტესტის შემთხვევების პროცენტული მაჩვენებელი, რომლისთვისაც რეალური გამომავალი მნიშვნელობები ემთხვევა მოსალოდნელს, ე.წ. წარუმატებელი ტესტები არის საწყისი მონაცემები შეცდომების მიზეზების ანალიზისა და მათი შემდგომი გამოსწორების მიზნით. ინტეგრაციის ეტაპზე, სისტემის ცალკეული მოდულები იკრიბება ერთ მთლიანობაში და ტარდება სატესტო შემთხვევები, რომლებიც ამოწმებს სისტემის მთელ ფუნქციონირებას. ბოლო ეტაპზე მზა სისტემა მიეწოდება მომხმარებელს. დანერგვამდე, კლიენტების სპეციალისტები, დეველოპერებთან ერთად, ატარებენ მიღების ტესტებს - ისინი ამოწმებენ მომხმარებლისთვის კრიტიკულ ფუნქციებს წინასწარ დამტკიცებული ტესტის პროგრამის შესაბამისად. თუ ტესტები წარმატებით დასრულდა, სისტემა გადაეცემა მომხმარებელს, წინააღმდეგ შემთხვევაში იგზავნება გადასინჯვისთვის. 1.8. ტესტირებისა და შემოწმების პროცესების სახეები და მათი ადგილი სასიცოცხლო ციკლის სხვადასხვა მოდელებში 1.8.1. ერთეულის ტესტირება მცირე მოდულები (პროცედურები, კლასები და ა.შ.) ექვემდებარება ერთეულ ტესტირებას. 100-1000 სტრიქონიანი ზომით შედარებით მცირე მოდულის ტესტირებისას შესაძლებელია თუ არა ყველა, მაშინ მაინც ბევრი ლოგიკური ფილიალის შემოწმება, მონაცემთა დამოკიდებულების გრაფიკის სხვადასხვა ბილიკები და პარამეტრების სასაზღვრო მნიშვნელობები. ამის შესაბამისად აგებულია ტესტის დაფარვის კრიტერიუმები (დაფარულია ყველა ოპერატორი, ყველა ლოგიკური განშტოება, ყველა სასაზღვრო წერტილი და ა.შ.). . ერთეულის ტესტირება, როგორც წესი, ტარდება თითოეულ დამოუკიდებელ პროგრამულ მოდულზე და, ალბათ, ყველაზე გავრცელებული ტიპის ტესტირებაა, განსაკუთრებით მცირე და საშუალო ზომის სისტემებისთვის. 1.8.2. ინტეგრაციის ტესტირება ყველა მოდულის სისწორის შემოწმება, სამწუხაროდ, არ იძლევა მოდულების სისტემის სწორად ფუნქციონირების გარანტიას. ლიტერატურა ზოგჯერ განიხილავს 22 მოდულების სისტემის ტესტირების არასათანადო ორგანიზების „კლასიკურ“ მოდელს, რომელსაც ხშირად უწოდებენ „დიდი ნახტომის“ მეთოდს. მეთოდის არსი არის ჯერ თითოეული მოდულის ცალ-ცალკე ტესტირება, შემდეგ მათი გაერთიანება სისტემაში და მთელი სისტემის ტესტირება. დიდი სისტემებისთვის ეს არარეალურია. ამ მიდგომით, დიდი დრო დაიხარჯება შეცდომების ლოკალიზაციაზე, ხოლო ტესტირების ხარისხი დაბალი დარჩება. „დიდი ნახტომის“ ალტერნატივა არის ინტეგრაციის ტესტირება, როდესაც სისტემა ეტაპობრივად შენდება, თანდათან ემატება მოდულების ჯგუფები. 1.8.3. სისტემის ტესტირება სრულად დანერგილი პროგრამული პროდუქტი ექვემდებარება სისტემის ტესტირებას. ამ ეტაპზე ტესტერი დაინტერესებულია არა ინდივიდუალური პროცედურებისა და მეთოდების სწორად განხორციელებით, არამედ მთლიანი პროგრამით, როგორც ამას საბოლოო მომხმარებელი ხედავს. ტესტები ეფუძნება Ძირითადი მოთხოვნებიპროგრამას, რომელიც მოიცავს არა მხოლოდ ფუნქციების სწორად შესრულებას, არამედ შესრულებას, რეაგირების დროს, წარუმატებლობის წინააღმდეგობას, შეტევებს, მომხმარებლის შეცდომებს და ა.შ. სისტემისა და კომპონენტის ტესტირებისთვის გამოიყენება ტესტის დაფარვის კრიტერიუმების სპეციფიკური ტიპები (მაგალითად, დაფარულია ყველა ტიპიური სამუშაო სცენარი, ყველა სცენარი არანორმალური სიტუაციებით, სცენარების წყვილი კომპოზიციები და ა.შ.). 1.8.4. დატვირთვის ტესტირება დატვირთვის ტესტირება არა მხოლოდ უზრუნველყოფს პროგნოზირებულ მონაცემებს დატვირთვის ქვეშ სისტემის მუშაობის შესახებ, რომელიც წარმართავს არქიტექტურულ გადაწყვეტილებებს, არამედ ოპერატიულ ინფორმაციას აწვდის ტექნიკური მხარდაჭერის გუნდებს, ასევე პროექტისა და კონფიგურაციის მენეჯერებს, რომლებიც პასუხისმგებელნი არიან ყველაზე პროდუქტიული აპარატურის და პროგრამული უზრუნველყოფის კონფიგურაციების შექმნაზე. დატვირთვის ტესტირება საშუალებას აძლევს განვითარების გუნდს მიიღოს უფრო ინფორმირებული გადაწყვეტილებები, რომლებიც მიმართულია ოპტიმალური არქიტექტურული კომპოზიციების შემუშავებაზე. მომხმარებელი, თავის მხრივ, იღებს შესაძლებლობას ჩაატაროს მისაღები ტესტები რეალურთან მიახლოებულ პირობებში. 1.8.5. ფორმალური ინსპექტირება ფორმალური შემოწმება არის პროგრამული უზრუნველყოფის შემუშავების პროცესში შექმნილი დოკუმენტებისა და პროგრამის კოდის გადამოწმების ერთ-ერთი გზა. ფორმალური შემოწმების დროს სპეციალისტთა ჯგუფი დამოუკიდებლად ამოწმებს შემოწმებული დოკუმენტების შესაბამისობას ორიგინალ დოკუმენტებთან. შემოწმების დამოუკიდებლობას უზრუნველყოფს ის ფაქტი, რომ მას ახორციელებენ ინსპექტორები, რომლებიც არ მონაწილეობდნენ შესამოწმებელი დოკუმენტის შემუშავებაში. 1.9. სერტიფიცირებული პროგრამული უზრუნველყოფის შემოწმება მოდით მივცეთ რამდენიმე განმარტება, რომლებიც განსაზღვრავს ზოგადი სტრუქტურაპროგრამული უზრუნველყოფის სერტიფიცირების პროცესი: პროგრამული უზრუნველყოფის სერტიფიცირება არის პროცესი, რომელიც ადგენს და ოფიციალურად აღიარებს, რომ პროგრამული უზრუნველყოფის დამუშავება განხორციელდა განსაზღვრული მოთხოვნების შესაბამისად. სერტიფიცირების პროცესში ხდება ურთიერთქმედება განმცხადებელს, სერტიფიცირების ორგანოსა და სამეთვალყურეო ორგანოს შორის.განმცხადებელი არის ორგანიზაცია, რომელიც წარუდგენს განაცხადს შესაბამის სერტიფიცირების ორგანოს სერტიფიკატის (შესაბამისობის, ხარისხის, ვარგისიანობის და ა.შ.) მისაღებად. პროდუქტი. სერტიფიცირების ორგანო არის ორგანიზაცია, რომელიც განიხილავს განმცხადებლის განაცხადს პროგრამული უზრუნველყოფის სერტიფიკაციისთვის და დამოუკიდებლად ან სპეციალური კომისიის ფორმირებით ახორციელებს პროცედურების კომპლექსს, რომელიც მიმართულია განმცხადებლის პროგრამული უზრუნველყოფის სერტიფიცირების პროცესის განსახორციელებლად. 23 სამეთვალყურეო ორგანო - სერტიფიცირების აპლიკანტის განვითარების პროცესების მონიტორინგის სპეციალისტთა კომისია. საინფორმაციო სისტემადა ამ პროცესის გარკვეულ მოთხოვნებთან შესაბამისობის შესახებ დასკვნის მიცემა, რომელიც განსახილველად წარედგინება სერტიფიცირების ორგანოს. სერტიფიცირება შეიძლება მიმართული იყოს შესაბამისობის სერტიფიკატის ან ხარისხის სერტიფიკატის მოპოვებაზე. პირველ შემთხვევაში, სერტიფიცირების შედეგი არის განვითარების პროცესების შესაბამისობის აღიარება გარკვეულ კრიტერიუმებთან, ხოლო სისტემის ფუნქციონალურობა გარკვეულ მოთხოვნებთან. ასეთი მოთხოვნების მაგალითი შეიძლება იყოს სახელმძღვანელო დოკუმენტები ფედერალური სამსახური ტექნიკური და საექსპორტო კონტროლის შესახებ პროგრამული სისტემების უსაფრთხოების სფეროში. მეორე შემთხვევაში, შედეგი არის განვითარების პროცესების შესაბამისობის აღიარება გარკვეულ კრიტერიუმებთან, რომლებიც უზრუნველყოფენ წარმოებული პროდუქტის ხარისხის შესაბამის დონეს და მის ვარგისიანობას გარკვეულ პირობებში გამოსაყენებლად. ასეთი სტანდარტების მაგალითია ხარისხის საერთაშორისო სტანდარტების სერია ISO 9000:2000 (GOST R ISO 9000-2001) ან საავიაციო სტანდარტები DO-178B, AS9100, AS9006. სერტიფიცირებადი პროგრამული უზრუნველყოფის ტესტირებას აქვს ორი დამატებითი მიზანი: პირველი მიზანია იმის დემონსტრირება, რომ პროგრამული უზრუნველყოფა აკმაყოფილებს მის მოთხოვნებს. მეორე მიზანი არის მაღალი დონის დარწმუნებით დემონსტრირება, რომ ტესტირების პროცესში გამოვლენილია შეცდომები, რომლებმაც შეიძლება გამოიწვიოს მიუღებელი წარუმატებლობის სიტუაციები, როგორც ეს განსაზღვრულია სისტემის გაუმართაობის უსაფრთხოების შეფასების პროცესით. მაგალითად, DO-178B მოითხოვს შემდეგს პროგრამული უზრუნველყოფის ტესტირების მიზნების დასაკმაყოფილებლად: ტესტები პირველ რიგში უნდა ეფუძნებოდეს პროგრამულ მოთხოვნებს; ტესტები უნდა იყოს შემუშავებული სწორი ფუნქციონირების შესამოწმებლად და პოტენციური შეცდომების გამოსავლენად. პროგრამული უზრუნველყოფის მოთხოვნილებებზე დაფუძნებული ტესტების სისრულის ანალიზმა უნდა განსაზღვროს რომელი მოთხოვნები არ არის შემოწმებული. პროგრამის კოდის სტრუქტურაზე დაფუძნებული ტესტების სისრულის ანალიზმა უნდა განსაზღვროს რომელი სტრუქტურები არ იყო შესრულებული ტესტირების დროს. ეს სტანდარტი ასევე საუბრობს მოთხოვნებზე დაფუძნებულ ტესტირებაზე. აღმოჩნდა, რომ ეს სტრატეგია ყველაზე ეფექტურია შეცდომების იდენტიფიცირებისთვის. მოთხოვნების მიხედვით სატესტო შემთხვევების შერჩევის სახელმძღვანელო მოიცავს შემდეგს: პროგრამული უზრუნველყოფის ტესტირების მიზნების მისაღწევად, უნდა ჩატარდეს ორი კატეგორიის ტესტები: ტესტები ნორმალური სიტუაციებისთვის და ტესტები არანორმალური (არამოთხოვნილი, ძლიერი) სიტუაციებისთვის. უნდა შემუშავდეს სპეციფიკური სატესტო შემთხვევები პროგრამული უზრუნველყოფის მოთხოვნებისა და პროგრამული უზრუნველყოფის განვითარების პროცესში თანდაყოლილი შეცდომების წყაროებისთვის. ტესტების მიზანი ნორმალური სიტუაციებისთვის არის პროგრამული უზრუნველყოფის უნარის დემონსტრირება ნორმალურ შეყვანებსა და პირობებზე საჭიროებისამებრ. 24 არანორმალურ სიტუაციებში ტესტების მიზანია აჩვენოს პროგრამული უზრუნველყოფის უნარი ადეკვატურად რეაგირებდეს არანორმალურ შეყვანებსა და პირობებზე, სხვა სიტყვებით რომ ვთქვათ, ეს არ უნდა გამოიწვიოს სისტემის მარცხი. სისტემის გაუმართაობის კატეგორიები დგინდება თვითმფრინავისა და მისი მგზავრების ავარიის სიმძიმის განსაზღვრით. პროგრამული უზრუნველყოფის ნებისმიერმა შეცდომამ შეიძლება გამოიწვიოს მარცხი, რაც ხელს უწყობს წარუმატებლობის მდგომარეობას. ამრიგად, უსაფრთხო მუშაობისთვის საჭირო პროგრამული უზრუნველყოფის მთლიანობის დონე დაკავშირებულია სისტემის წარუმატებლობის სიტუაციებთან. არსებობს წარუმატებლობის 5 დონე, მცირედან კრიტიკულამდე. ამ დონეების მიხედვით შემოღებულია პროგრამული უზრუნველყოფის კრიტიკულობის დონის კონცეფცია. კრიტიკულობის დონე განსაზღვრავს სერტიფიკაციის ორგანოსთვის მიწოდებული დოკუმენტაციის შემადგენლობას და, შესაბამისად, სისტემის განვითარებისა და გადამოწმების პროცესების სიღრმეს. მაგალითად, DO-178B კრიტიკულობის ყველაზე დაბალ დონეზე სერტიფიცირებისთვის საჭირო დოკუმენტების ტიპების რაოდენობა და სისტემის შემუშავების სამუშაოების რაოდენობა შეიძლება განსხვავდებოდეს სიდიდის ერთი ან ორი რიგით, სერტიფიცირებისთვის საჭირო რაოდენობისა და მოცულობის მაქსიმუმამდე. მაღალი დონე. სპეციფიკური მოთხოვნები განისაზღვრება სტანდარტით, რომლითაც იგეგმება სერტიფიცირება. 25 თემა 2. ტესტირების პროგრამის კოდი (ლექციები 2-5) 2.1. პროგრამის კოდის ტესტირების ამოცანები და მიზნები პროგრამული კოდის ტესტირება არის პროგრამის კოდის შესრულების პროცესი, რომელიც მიზნად ისახავს მასში არსებული დეფექტების იდენტიფიცირებას. დეფექტი აქ გაგებულია, როგორც პროგრამის კოდის ნაწილი, რომლის შესრულებაც, გარკვეულ პირობებში, იწვევს სისტემის მოულოდნელ ქცევას (ანუ ქცევა, რომელიც არ აკმაყოფილებს მოთხოვნებს). სისტემის მოულოდნელმა ქცევამ შეიძლება გამოიწვიოს გაუმართაობა და წარუმატებლობა; ამ შემთხვევაში ისინი საუბრობენ პროგრამის კოდში მნიშვნელოვან დეფექტებზე. ზოგიერთი დეფექტი იწვევს მცირე პრობლემებს, რომლებიც არ არღვევს სისტემის მუშაობას, მაგრამ გარკვეულწილად ართულებს მასთან მუშაობას. ამ შემთხვევაში ისინი საუბრობენ საშუალო ან მცირე დეფექტებზე. ამ მიდგომით ტესტირების ამოცანაა იმის დადგენა, თუ რა პირობებში ჩნდება სისტემის დეფექტები და აღრიცხოს ეს პირობები. ტესტირების ამოცანები, როგორც წესი, არ მოიცავს პროგრამის კოდის კონკრეტული დეფექტური სექციების იდენტიფიცირებას და არასოდეს მოიცავს დეფექტების გამოსწორებას - ეს არის გამართვის ამოცანა, რომელიც შესრულებულია სისტემის ტესტირების შედეგების საფუძველზე. პროგრამის კოდის ტესტირების პროცედურის გამოყენების მიზანია მინიმუმამდე დაიყვანოს დეფექტების რაოდენობა, განსაკუთრებით მნიშვნელოვანი, საბოლოო პროდუქტში. მხოლოდ ტესტირება არ იძლევა გარანტიას სრული არარსებობახარვეზები სისტემის კოდში. თუმცა, შემოწმებისა და ვალიდაციის პროცესებთან ერთად, რომლებიც მიმართულია შეუსაბამობისა და არასრულყოფილების აღმოფხვრაზე პროექტის დოკუმენტაცია(კერძოდ, სისტემის მოთხოვნები), კარგად ორგანიზებული ტესტირება უზრუნველყოფს, რომ სისტემა აკმაყოფილებს მოთხოვნებს და იქცევა მათ შესაბამისად ყველა დანიშნულ სიტუაციაში. გაზრდილი საიმედოობის სისტემების შემუშავებისას, მაგალითად, საავიაციო, საიმედოობის გარანტიები მიიღწევა ტესტირების პროცესის მკაფიო ორგანიზებით, მისი კავშირის განსაზღვრით სხვა სასიცოცხლო ციკლის პროცესებთან და რაოდენობრივი მახასიათებლების შემოღებით, რაც საშუალებას იძლევა შეაფასოს ტესტირების წარმატება. უფრო მეტიც, რაც უფრო მაღალია მოთხოვნები სისტემის საიმედოობაზე (მისი კრიტიკულობის დონე), მით უფრო მკაცრია მოთხოვნები. ამრიგად, პირველ რიგში, ჩვენ განვიხილავთ არა კონკრეტული სისტემის ტესტირების კონკრეტულ შედეგებს, არამედ ზოგადი ორგანიზაცია ტესტირების პროცესი მიდგომის გამოყენებით „კარგად ორგანიზებული პროცესი იძლევა ხარისხის შედეგს“. ეს მიდგომა საერთოა მრავალი საერთაშორისო და ინდუსტრიის ხარისხის სტანდარტებისთვის, რომლებიც უფრო დეტალურად იქნება განხილული ამ კურსის ბოლოს. ამ მიდგომით შემუშავებული სისტემის ხარისხი ორგანიზებული განვითარებისა და ტესტირების პროცესის შედეგია და არა დამოუკიდებელი უკონტროლო შედეგი. ვინაიდან თანამედროვე პროგრამული სისტემები საკმაოდ დიდია, მათი პროგრამის კოდის შემოწმებისას გამოიყენება ფუნქციური დაშლის მეთოდი. სისტემა დაყოფილია ცალკეულ მოდულებად (კლასები, სახელთა სივრცე და ა.შ.), რომლებსაც გააჩნიათ მოთხოვნებით განსაზღვრული ფუნქციონალობა და ინტერფეისები. ამის შემდეგ, თითოეული მოდული ცალ-ცალკე ტესტირება ხდება - ტარდება ერთეულის ტესტირება. შემდეგ ცალკეული მოდულები იკრიბება უფრო დიდ კონფიგურაციებში - შესრულებულია ინტეგრაციის ტესტირება და ბოლოს ხდება მთლიანი სისტემის ტესტირება - ხდება სისტემის ტესტირება. კოდის თვალსაზრისით, ერთეულს, ინტეგრაციას და სისტემის ტესტირებას ბევრი რამ აქვთ საერთო, ამიტომ ეს თემა ყურადღებას გაამახვილებს ერთეულების ტესტირებაზე, ინტეგრაციისა და სისტემის ტესტირების მახასიათებლებზე, რომლებიც მოგვიანებით განიხილება. 26 ერთეულის ტესტირების დროს, თითოეული მოდული შემოწმდება როგორც მოთხოვნებთან შესაბამისობისთვის, ასევე პროგრამის კოდის პრობლემური უბნების არარსებობისთვის, რამაც შეიძლება გამოიწვიოს გაუმართაობა და გაუმართაობა სისტემაში. როგორც წესი, მოდულები არ მუშაობენ სისტემის გარეთ - ისინი იღებენ მონაცემებს სხვა მოდულებიდან, ამუშავებენ და შემდგომ გადასცემენ. იმისათვის, რომ, ერთის მხრივ, მოდული იზოლირდეს სისტემიდან და აღმოიფხვრას სისტემის პოტენციური შეცდომების გავლენა, ხოლო მეორე მხრივ, მოდულისთვის ყველა საჭირო მონაცემით უზრუნველყოფა, გამოიყენება სატესტო გარემო. სატესტო გარემოს ამოცანაა შექმნას გაშვების გარემო მოდულისთვის და ყველა გარე ინტერფეისის ემულაცია, რომელსაც მოდული წვდება. სატესტო გარემოს ორგანიზების თავისებურებები ამ თემაში იქნება განხილული. ტიპიური ტესტირების პროცედურა შედგება ტესტის შემთხვევის მომზადებასა და შესრულებაში (ასევე უწოდებენ უბრალოდ ტესტებს). თითოეული ტესტის მაგალითი ამოწმებს ერთ „სიტუაციას“ მოდულის ქცევაში და შედგება მოდულის შეყვანაზე გადაცემული მნიშვნელობების სიისგან, მონაცემთა დამუშავების გაშვებისა და შესრულების აღწერილობისგან - ტესტის სკრიპტისა და ჩამონათვალისგან. მნიშვნელობები, რომლებიც მოსალოდნელია მოდულის გამოსავალზე, თუ ის სწორად იქცევა. სატესტო სკრიპტები შედგენილია ისე, რომ გამორიცხოს წვდომა მოდულის შიდა მონაცემებზე; ყველა ურთიერთქმედება უნდა მოხდეს მხოლოდ მისი გარე ინტერფეისის საშუალებით. სატესტო ქეისის შესრულებას მხარს უჭერს სატესტო გარემო, რომელიც მოიცავს ტესტის სკრიპტის პროგრამულ განხორციელებას. შესრულება იწყება შეყვანის მონაცემების მოდულზე გადაცემით და სკრიპტის გაშვებით. სკრიპტის შესრულების შედეგად მოდულიდან მიღებული ფაქტობრივი გამომავალი მონაცემები ინახება და შედარებულია მოსალოდნელთან. თუ ისინი ემთხვევა, ტესტი ჩაითვლება ჩაბარებულად, წინააღმდეგ შემთხვევაში ჩაითვლება წარუმატებლად. ყოველი წარუმატებელი ტესტი მიუთითებს ან დეფექტზე შესამოწმებელ მოდულში, ან ტესტის გარემოში, ან ტესტის აღწერაში. სატესტო შემთხვევების აღწერილობების ნაკრები ქმნის ტესტის გეგმას - მთავარ დოკუმენტს, რომელიც განსაზღვრავს პროგრამული მოდულის ტესტირების პროცედურას. ტესტის გეგმაში მითითებულია არა მხოლოდ თავად ტესტის შემთხვევები, არამედ მათი გამოჩენის თანმიმდევრობა, რაც ასევე შეიძლება იყოს მნიშვნელოვანი. ამ თემაში განხილული იქნება ტესტის გეგმების სტრუქტურა და მახასიათებლები, ტესტის შემთხვევების თანმიმდევრობასთან დაკავშირებული პრობლემები განხილული იქნება თემაში "ტესტი განმეორებადობა". ტესტირებისას ხშირად საჭიროა გავითვალისწინოთ არა მხოლოდ სისტემის მოთხოვნები, არამედ შემოწმებული მოდულის პროგრამის კოდის სტრუქტურა. ამ შემთხვევაში, ტესტები შექმნილია ისე, რომ აღმოაჩინოს ტიპიური შეცდომებიპროგრამისტები გამოწვეული მოთხოვნების არასწორი ინტერპრეტაციით. გამოიყენება სასაზღვრო მდგომარეობის შემოწმება და ეკვივალენტობის კლასის შემოწმება. სისტემაში შესაძლებლობების არარსებობა, რომლებიც არ არის განსაზღვრული მოთხოვნებით, გარანტირებულია პროგრამის კოდის დაფარვის სხვადასხვა შეფასებით ტესტებით, ე.ი. ყველა ტესტის მაგალითის შესრულების შედეგად დასრულებულია გარკვეული ენის კონსტრუქტების რამდენი პროცენტის შეფასება. ეს ყველაფერი ამ თემის ბოლოს იქნება განხილული. 2.2. ტესტის მეთოდები 2.2.1. შავი ყუთი სისტემის, როგორც შავი ყუთის ტესტირების მთავარი იდეა არის ის, რომ ყველა მასალა, რომელიც ხელმისაწვდომია ტესტერისთვის, არის სისტემის მოთხოვნები, აღწერს მის ქცევას და თავად სისტემას, რომლებთანაც მას შეუძლია მუშაობა მხოლოდ გარკვეული გარე გავლენის გამოყენებით. მისი შეყვანები და შედეგების დაკვირვება გარკვეულ შედეგზე. სისტემის დანერგვის ყველა შიდა მახასიათებელი დამალულია ტესტერისგან, ამდენად სისტემა არის „შავი ყუთი“, რომლის სწორი ქცევა მოთხოვნებთან მიმართებაში უნდა შემოწმდეს. 27 პროგრამული კოდის თვალსაზრისით, შავი ყუთი შეიძლება იყოს კლასების (ან მოდულების) ნაკრები ცნობილი გარე ინტერფეისებით, მაგრამ მიუწვდომელი წყარო კოდებით. ამ ტესტირების მეთოდის ტესტერის მთავარი ამოცანაა თანმიმდევრულად გადაამოწმოს, რომ სისტემის ქცევა აკმაყოფილებს მოთხოვნებს. გარდა ამისა, ტესტერმა უნდა შეამოწმოს სისტემის მუშაობა კრიტიკულ სიტუაციებში - რა მოხდება, თუ არასწორი შეყვანის მნიშვნელობები მიეწოდება. იდეალურ სიტუაციაში, კრიტიკული სიტუაციების ყველა ვარიანტი უნდა იყოს აღწერილი სისტემის მოთხოვნებში და ტესტერს შეუძლია მხოლოდ ამ მოთხოვნების სპეციფიკური ტესტების გამომუშავება. თუმცა, რეალურად, ტესტირების შედეგად, ჩვეულებრივ გამოვლინდება ორი ტიპის სისტემური პრობლემა: 1. სისტემის ქცევის შეუსაბამობა მოთხოვნებთან 2. სისტემის არაადეკვატური ქცევა მოთხოვნებით გაუთვალისწინებელ სიტუაციებში. ორივე ტიპის პრობლემა ეცნობება და ეცნობება დეველოპერებს. ამავდროულად, პირველი ტიპის პრობლემები ჩვეულებრივ იწვევს პროგრამის კოდის ცვლილებას, უფრო იშვიათად - მოთხოვნების ცვლილებას. მოთხოვნების შეცვლა ამ შემთხვევაში შეიძლება საჭირო გახდეს მათი შეუსაბამობის გამო (რამდენიმე განსხვავებული მოთხოვნა აღწერს სისტემის ქცევის სხვადასხვა მოდელს ერთსა და იმავე სიტუაციაში) ან არასწორად (მოთხოვნები არ შეესაბამება რეალობას). მეორე ტიპის პრობლემები აშკარად მოითხოვს მოთხოვნების შეცვლას მათი არასრულყოფილების გამო - მოთხოვნები აშკარად გამოტოვებს სიტუაციას, რომელიც იწვევს სისტემის არაადეკვატურ ქცევას. ამ შემთხვევაში, შეუსაბამო ქცევა შეიძლება გავიგოთ, როგორც სისტემის სრული კოლაფსი, ან ზოგადად ნებისმიერი ქცევა, რომელიც არ არის აღწერილი მოთხოვნებში. შავი ყუთის ტესტირებას ასევე უწოდებენ მოთხოვნების ტესტირებას, რადგან ... ეს არის ინფორმაციის ერთადერთი წყარო ტესტის გეგმის შესაქმნელად. 2.2.2. შუშის (თეთრი) ყუთი სისტემის, როგორც შუშის ყუთის ტესტირებისას, ტესტერს აქვს წვდომა არა მხოლოდ სისტემის მოთხოვნებზე, მის შეყვანასა და გამომავალზე, არამედ მის შიდა სტრუქტურაზეც - ის ხედავს მის პროგრამულ კოდს. პროგრამის კოდის ხელმისაწვდომობა აფართოებს ტესტერის შესაძლებლობებს იმით, რომ მას შეუძლია დაინახოს მოთხოვნების შესაბამისობა პროგრამის კოდის სექციებთან და ამით დაინახოს არის თუ არა მოთხოვნები მთელი პროგრამის კოდისთვის. პროგრამის კოდს, რომლისთვისაც არ არსებობს მოთხოვნები, ეწოდება კოდი, რომელიც არ არის დაფარული მოთხოვნებით. ასეთი კოდი არის სისტემის არასათანადო ქცევის პოტენციური წყარო. გარდა ამისა, სისტემის გამჭვირვალობა საშუალებას გაძლევთ გააღრმავოთ მისი იმ სფეროების ანალიზი, რომლებიც პრობლემებს იწვევს - ხშირად ერთი პრობლემა ანეიტრალებს მეორეს და ისინი არასოდეს წარმოიქმნება ერთდროულად. 2.2.3. მოდელის ტესტირება მოდელის ტესტირება გარკვეულწილად განსხვავდება პროგრამული უზრუნველყოფის შემოწმების კლასიკური მეთოდებისგან. უპირველეს ყოვლისა, ეს გამოწვეულია იმით, რომ ტესტირების ობიექტი არ არის თავად სისტემა, არამედ მისი მოდელი, რომელიც შექმნილია ფორმალური საშუალებებით. თუ გვერდით დავტოვებთ თავად მოდელის სისწორისა და გამოსაყენებლად შემოწმების საკითხებს (ითვლება, რომ მისი სისწორე და თავდაპირველ სისტემასთან შესაბამისობა შეიძლება დადასტურდეს ფორმალური საშუალებებით), მაშინ ტესტერს აქვს საკმაოდ მძლავრი ინსტრუმენტი ანალიზისთვის. სისტემის საერთო მთლიანობა. მოდელთან მუშაობისას თქვენ შეგიძლიათ შექმნათ სიტუაციები, რომლებიც არ შეიძლება შეიქმნას სატესტო ლაბორატორიაში რეალური სისტემისთვის. სისტემის პროგრამის კოდის მოდელთან მუშაობისას შეგიძლიათ გაანალიზოთ მისი თვისებები და სისტემის ისეთი პარამეტრები, როგორიცაა ალგორითმების ოპტიმალური ან სტაბილურობა. 28 თუმცა, მოდელის ტესტირება არ გავრცელებულა ზუსტად სისტემის ქცევის ფორმალური აღწერის შემუშავებისას წარმოქმნილი სირთულეების გამო. გამონაკლისებიდან ერთ-ერთია საკომუნიკაციო სისტემები, რომელთა ალგორითმული და მათემატიკური აპარატურა საკმაოდ კარგად არის განვითარებული. 2.2.4. პროგრამის კოდის ანალიზი (ინსპექტირება) ბევრ სიტუაციაში შეუძლებელია სისტემის ქცევის ტესტირება მთლიანად - პროგრამის კოდის ცალკეული სექციები შეიძლება არასოდეს შესრულდეს, მაგრამ ისინი დაფარული იქნება მოთხოვნებით. ასეთი კოდის სექციების მაგალითია გამონაკლისის დამმუშავებლები. თუ, მაგალითად, ორი მოდული ერთმანეთს გადასცემს რიცხვით მნიშვნელობებს და მნიშვნელობის შემოწმების ფუნქციები მუშაობს ორივე მოდულში, მაშინ მიმღები მოდულის შემოწმების ფუნქცია არასოდეს გააქტიურდება, რადგან გადამცემში ყველა მცდარი მნიშვნელობა შეწყდება. ამ შემთხვევაში, ხორციელდება პროგრამის კოდის ხელით ანალიზი სისწორისთვის, რომელსაც ასევე უწოდებენ კოდის მიმოხილვას ან შემოწმებას. თუ შემოწმების შედეგად გამოვლინდა პრობლემური სფეროები, მაშინ ამის შესახებ ინფორმაცია გადაეცემა დეველოპერებს გამოსწორებისთვის, რეგულარული ტესტების შედეგებთან ერთად. 2.3. სატესტო გარემო თითქმის ნებისმიერი რთული სისტემის ტესტირების ძირითადი ნაწილი ჩვეულებრივ ავტომატურ რეჟიმში ხორციელდება. გარდა ამისა, ტესტირებადი სისტემა ჩვეულებრივ იყოფა ცალკეულ მოდულებად, რომელთაგან თითოეული ტესტირება ხდება ჯერ სხვებისგან ცალკე, შემდეგ მთლიანად. ეს ნიშნავს, რომ ტესტირების ჩასატარებლად აუცილებელია ისეთი გარემოს შექმნა, რომელიც უზრუნველყოფს სატესტო მოდულის გაშვებას და შესრულებას, გადასცემს მას შეყვანის მონაცემებს და შეაგროვებს მოცემულ სისტემაზე მოქმედი სისტემის შედეგად მიღებულ რეალურ გამომავალ მონაცემებს. შესაყვანი მონაცემები. ამის შემდეგ გარემომ უნდა შეადაროს ფაქტობრივი გამომავალი მონაცემები მოსალოდნელს და ამ შედარების საფუძველზე გააკეთოს დასკვნა მოდულის ქცევის შესაბამისობაში მითითებულთან (ნახ. 9). ტესტის დრაივერი მოსალოდნელი გამომავალი ტესტირება დამუშავება შეყვანის მონაცემთა შედეგის მოდული რეალური გამომავალი მონაცემები Stubs ნახ. 9 სატესტო გარემოს განზოგადებული დიაგრამა სატესტო გარემო ასევე შეიძლება გამოყენებულ იქნას ცალკეული სისტემის მოდულების მთელი სისტემისგან გასასხვისებლად. სისტემის მოდულების გამოყოფა ტესტირების ადრეულ ეტაპზე საშუალებას გაძლევთ უფრო ზუსტად მოაწყოთ პრობლემები, რომლებიც წარმოიქმნება მათ პროგრამულ კოდში. სისტემისგან იზოლირებულ მოდულის ფუნქციონირების მხარდასაჭერად, სატესტო გარემომ უნდა მოახდინოს ყველა მოდულის ქცევის სიმულაცია, რომლის ფუნქციებსა თუ მონაცემებზე წვდომა აქვს სატესტო მოდულმა. 29
ტერმინები ვერიფიკაცია და დადასტურება დაკავშირებულია პროგრამული უზრუნველყოფის ხარისხის შემოწმებასთან. ჩვენ ვიყენებთ ამ ტერმინებს ჩვენს სტატიებსა და ანგარიშებში. ჩვენ არაერთხელ მოვისმინეთ სხვადასხვა კომენტარი და არგუმენტი იმის შესახებ, უნდა იყოს თუ არა პროგრამის წყაროს კოდის სტატიკური ანალიზი კლასიფიცირებული, როგორც გადამოწმება და ვალიდაცია და რა განსხვავებაა ამ ცნებებს შორის. ზოგადად, იქმნება შთაბეჭდილება, რომ ამ ტერმინებში ყველა საკუთარ ცნებებს აყენებს და ეს იწვევს ურთიერთ გაუგებრობას.
ჩვენ გადავწყვიტეთ გაგვეგო ტერმინოლოგია, რათა დავეცვა ამ ცნებების ყველაზე სწორი ინტერპრეტაცია. კვლევის დროს აღმოვაჩინეთ ვ.ვ. კულიამინი "პროგრამული უზრუნველყოფის შემოწმების მეთოდები". იგი გთავაზობთ ამ ტერმინების დეტალურ აღწერას და ჩვენ გადავწყვიტეთ შემდგომში დავეყრდნოთ ამ ნაშრომში მოცემულ განმარტებებს. აქ მოცემულია რამდენიმე ნაწყვეტი ამ ნამუშევრიდან, რომელიც დაკავშირებულია გადამოწმებასა და დადასტურებასთან.
გადამოწმება და დადასტურებაარის აქტივობები, რომლებიც მიმართულია პროგრამული უზრუნველყოფის ხარისხის მონიტორინგსა და მასში არსებული შეცდომების გამოვლენისკენ. საერთო მიზნის მქონე, ისინი განსხვავდებიან თავიანთი კურსის განმავლობაში შემოწმებული თვისებების, წესებისა და შეზღუდვების წყაროებით, რომელთა დარღვევა შეცდომად ითვლება.
შემდგომი გამოფენისთვის, ჩვენ უნდა შემოვიტანოთ ტერმინი „პროგრამული უზრუნველყოფის სასიცოცხლო ციკლის არტეფაქტი“. პროგრამული უზრუნველყოფის სასიცოცხლო ციკლის არტეფაქტები არის სხვადასხვა საინფორმაციო ერთეულები, დოკუმენტები და მოდელები, რომლებიც შექმნილია ან გამოიყენება პროგრამული უზრუნველყოფის შემუშავებისა და შენარჩუნების დროს. ამრიგად, არტეფაქტები არის ტექნიკური მახასიათებლები, არქიტექტურის აღწერა, მოდელი საგნობრივი სფერონებისმიერ გრაფიკულ ენაზე, წყაროს კოდით, მომხმარებლის დოკუმენტაციაში და ა.შ. ცალკეული დეველოპერების მიერ გამოყენებული სხვადასხვა მოდელები პროგრამული უზრუნველყოფის შექმნისა და ანალიზის დროს, მაგრამ არ არის ჩაწერილი სხვა ადამიანებისთვის ხელმისაწვდომი დოკუმენტების სახით, არ შეიძლება ჩაითვალოს არტეფაქტებად.
ვერიფიკაცია ამოწმებს პროგრამული უზრუნველყოფის შემუშავებისა და შენარჩუნების დროს შექმნილი ზოგიერთი არტეფაქტის შესაბამისობას სხვებთან, რომლებიც ადრე შექმნილ ან გამოყენებულ იქნა შეყვანის მონაცემად, ასევე ამ არტეფაქტების და მათი განვითარების პროცესების შესაბამისობას წესებთან და სტანდარტებთან. კერძოდ, გადამოწმება ამოწმებს სტანდარტებს შორის შესაბამისობას, მოთხოვნების აღწერას ( მითითების პირობები) პროგრამულ უზრუნველყოფას, დიზაინის გადაწყვეტილებებს, წყაროს კოდს, მომხმარებლის დოკუმენტაციას და თავად პროგრამული უზრუნველყოფის ფუნქციონირებას. გარდა ამისა, მოწმდება, რომ მოთხოვნები, საპროექტო გადაწყვეტილებები, დოკუმენტაცია და კოდი შედგენილია მოცემულ ქვეყანაში, ინდუსტრიაში და ორგანიზაციაში მიღებული ნორმებისა და სტანდარტების შესაბამისად, პროგრამული უზრუნველყოფის შემუშავებისას და ასევე, რომ მათი შექმნისას გათვალისწინებულია ყველა ოპერაცია. სტანდარტები შესრულდა საჭირო თანმიმდევრობით. შემოწმების დროს გამოვლენილი შეცდომები და დეფექტები არის შეუსაბამობები ან წინააღმდეგობები რამდენიმე ჩამოთვლილ დოკუმენტს შორის, დოკუმენტებსა და პროგრამის რეალურ ფუნქციონირებას შორის, სტანდარტებსა და პროგრამული უზრუნველყოფის განვითარებისა და შენარჩუნების რეალურ პროცესებს შორის. ამავდროულად, გადაწყვეტილების მიღება, თუ რომელი დოკუმენტი ექვემდებარება შესწორებას (შესაძლოა ორივე) ცალკე ამოცანაა.
ვალიდაცია ამოწმებს პროგრამული უზრუნველყოფის შემუშავებისა და შენარჩუნების დროს შექმნილი ან გამოყენებული ნებისმიერი არტეფაქტის შესაბამისობას ამ პროგრამული უზრუნველყოფის მომხმარებელთა და მომხმარებელთა საჭიროებებთან და მოთხოვნებთან. . ეს საჭიროებები და მოთხოვნები ყველაზე ხშირად არ არის დოკუმენტირებული - როდესაც ჩაიწერება, ისინი იქცევა მოთხოვნების აღწერად, პროგრამული უზრუნველყოფის განვითარების პროცესის ერთ-ერთ არტეფაქტად. ამიტომ, ვალიდაცია ნაკლებად ფორმალიზებული აქტივობაა, ვიდრე ვერიფიკაცია. ის ყოველთვის ტარდება მომხმარებლების, მომხმარებლების, ბიზნეს ანალიტიკოსების ან საგნის ექსპერტების მონაწილეობით - მათ, ვისი მოსაზრებაც შეიძლება ჩაითვალოს მომხმარებლების, მომხმარებლების და სხვა დაინტერესებული მხარეების რეალური საჭიროებებისა და მოთხოვნების საკმარისად კარგ გამოხატულებად. მისი განხორციელების მეთოდები ხშირად იყენებს კონკრეტულ ტექნიკას მონაწილეთა ცოდნისა და რეალური საჭიროებების დასადგენად.
განსხვავება გადამოწმებასა და ვალიდაციას შორის ილუსტრირებულია ნახაზ 1-ში.
მოცემული განმარტებები მიღებულია IEEE 1012 სტანდარტის განმარტებების გარკვეული გაფართოებით შემოწმებისა და ვალიდაციის პროცესებისთვის. 1990 წლის IEEE 610.12 პროგრამული ინჟინერიის ტერმინების სტანდარტულ ლექსიკონში, გადამოწმების განმარტება დაახლოებით იგივეა, მაგრამ ვალიდაციის განმარტება გარკვეულწილად განსხვავებულია - ნათქვამია, რომ ვალიდაციამ უნდა შეამოწმოს განვითარების შედეგად მიღებული პროგრამული უზრუნველყოფის შესაბამისობა ორიგინალთან. მოთხოვნები მასზე. ამ შემთხვევაში, ვალიდაცია იქნება გადამოწმების განსაკუთრებული შემთხვევა, რომელიც არსად არის აღნიშნული პროგრამული უზრუნველყოფის ინჟინერიის ლიტერატურაში, ამიტომ და ასევე იმის გამო, რომ იგი შესწორებულია 2004 წლის IEEE 1012-ში, ეს განმარტება უნდა ჩაითვალოს არაზუსტად. ბ.ბოემის ფრაზის ხშირი გამოყენება:
ვერიფიკაცია პასუხობს კითხვას „ვამზადებთ თუ არა პროდუქტს სწორად?“ და ვალიდაცია პასუხობს კითხვას „ვამზადებთ თუ არა სწორ პროდუქტს?“
დაბნეულობასაც ამატებს, რადგან ამ განცხადების აფორიზმი, სამწუხაროდ, გაურკვევლობასთან არის შერწყმული. თუმცა, მისი ავტორის მრავალი ნაშრომი ვარაუდობს, რომ შემოწმებითა და დადასტურებით იგი გულისხმობდა დაახლოებით იგივე ცნებებს, რაც ზემოთ იყო განსაზღვრული. ეს შეუსაბამობები ასევე შეიძლება გამოიკვეთოს პროგრამული უზრუნველყოფის ინჟინერიის სტანდარტების შინაარსში. ამრიგად, ISO 12207 სტანდარტი მიიჩნევს ტესტირებას, როგორც ვალიდაციის ტიპს, მაგრამ არა შემოწმებას, რაც, როგორც ჩანს, არის სტანდარტული ლექსიკონიდან არაზუსტი განმარტების გამოყენების შედეგი.
დასასრულს, მინდა აღვნიშნო, რომ ზემოაღნიშნული განმარტებების მიხედვით, პროგრამის საწყისი კოდის სტატიკური ანალიზი შეესაბამება პროგრამული უზრუნველყოფის შემოწმებას, როგორიცაა პროგრამის კოდის შესაბამისობის შემოწმება სხვადასხვა კოდირების სტანდარტებთან. სტატიკური ანალიზი ამოწმებს პროგრამული სისტემის დიზაინის ეტაპის შედეგების შესაბამისობას ადრე ჩამოყალიბებულ მოთხოვნებთან და შეზღუდვებთან.
ბიბლიოგრაფია
- ვ.ვ. კულიამინი "პროგრამული უზრუნველყოფის შემოწმების მეთოდები". სისტემური პროგრამირების ინსტიტუტი RAS 109004, მოსკოვი, ქ. ბ.კომუნისჩესკაია, No25.
http://www.ict.edu.ru/ft/005645/62322e1-st09.pdf - IEEE 1012-2004 სტანდარტი პროგრამული უზრუნველყოფის შემოწმებისა და ვალიდაციისთვის. IEEE, 2005 წ.
- IEEE 610.12-1990 პროგრამული ინჟინერიის ტერმინოლოგიის სტანდარტული ლექსიკონი, კორექტირებული გამოცემა. IEEE, 1991 წლის თებერვალი.
- B. W. Boehm. პროგრამული უზრუნველყოფის ინჟინერია; R&D ტენდენციები და თავდაცვის საჭიროებები. რ.ვეგნერში, რედ. Კვლევა. მიმართულებები პროგრამულ ტექნოლოგიაში. კემბრიჯი, MA:MIT Press, 1979 წ.
- ISO/IEC 12207 სისტემები და პროგრამული ინჟინერია - პროგრამული უზრუნველყოფის სასიცოცხლო ციკლის პროცესები. ჟენევა, შვეიცარია: ISO, 2008 წ.
თეთრი ყუთის ტესტირება
გამოყენებადობის ტესტირება
ა) დატვირთვის ტესტირება
შესრულების ტესტირება
ფუნქციური ტესტირება
პროგრამული უზრუნველყოფის ტესტირება
ტესტირება არის პროგრამის (ან პროგრამის ნაწილის) შესრულების პროცესი შეცდომების აღმოჩენის განზრახვით (ან მიზანი).
არსებობს რამდენიმე კრიტერიუმი, რომლითაც ჩვეულებრივ ხდება ტესტირების ტიპების კლასიფიკაცია. როგორც წესი, გამოვლენილია შემდეგი სიმპტომები:
ი) საცდელი ობიექტით:
(პროგრამული და აპარატურის სისტემის ან მოწყობილობის შესრულების ინდიკატორების და რეაგირების დროის განსაზღვრა ან შეგროვება გარე მოთხოვნის საპასუხოდ, მოცემული სისტემის მოთხოვნებთან შესაბამისობის დადგენის მიზნით)
ბ) სტრეს ტესტირება
(აფასებს სისტემის საიმედოობას და სტაბილურობას ნორმალური მუშაობის საზღვრების გადაჭარბებისას.)
გ) სტაბილურობის ტესტირება
4) მომხმარებლის ინტერფეისის ტესტირება
5) უსაფრთხოების ტესტირება
6) ლოკალიზაციის ტესტირება
7) თავსებადობის ტესტირება
II) სისტემის ცოდნით:
1) შავი ყუთის ტესტირება
(შემოწმებულია ობიექტი, რომლის შიდა სტრუქტურა უცნობია)
(შემოწმებულია პროგრამის შიდა სტრუქტურა, ტესტის მონაცემები მიიღება პროგრამის ლოგიკის ანალიზით)
III) ავტომატიზაციის ხარისხით:
1) ხელით ტესტირება
2) ავტომატური ტესტირება
3) ნახევრად ავტომატური ტესტირება
IV) კომპონენტების იზოლაციის ხარისხის მიხედვით:
1) კომპონენტის (ერთეულის) ტესტირება
2) ინტეგრაციის ტესტირება
3) სისტემის ტესტირება
V) ტესტირების დროით:
1) ალფა ტესტირება– პროგრამის ტესტირების დახურული პროცესი სრულ განაკვეთზე დეველოპერების ან ტესტერების მიერ. ალფა პროდუქტი ყველაზე ხშირად მხოლოდ 50%-ით არის დასრულებული; პროგრამის კოდი არსებობს, მაგრამ დიზაინის მნიშვნელოვანი ნაწილი აკლია.
2) ბეტა ტესტირება- პროგრამის თითქმის დასრულებული ვერსიის ინტენსიური გამოყენება, რათა გამოავლინოს შეცდომების მაქსიმალური რაოდენობა მის მუშაობაში, მათი შემდგომი აღმოფხვრის მიზნით, ბაზარზე, მასობრივ მომხმარებელზე საბოლოო გამოშვებამდე. მოხალისეები რიგითი მომავალი მომხმარებლებიდან რეკრუტირდებიან ტესტირებისთვის.
პროგრამული უზრუნველყოფის შემოწმება უფრო ზოგადი კონცეფციაა, ვიდრე ტესტირება. შემოწმების მიზანია უზრუნველყოს, რომ შემოწმებული ელემენტი (მოთხოვნები ან პროგრამის კოდი) აკმაყოფილებს მოთხოვნებს, განხორციელებულია არასასურველი ფუნქციების გარეშე და აკმაყოფილებს დიზაინის სპეციფიკაციებსა და სტანდარტებს ( ISO 9000-2000). გადამოწმების პროცესი მოიცავს ინსპექტირებას, კოდის ტესტირებას, ტესტის შედეგების ანალიზს, პრობლემის ანგარიშების გენერირებას და ანალიზს. ამრიგად, ზოგადად მიღებულია, რომ ტესტირების პროცესი გადამოწმების პროცესის განუყოფელი ნაწილია.