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

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

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

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

ტესტი მოდელის გაშუქება

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

სკრიპტის ხარისხი

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

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

ტესტის შემთხვევების აღწერის შესაძლო დონეები:

მე-4 დონეზე მომხმარებელთან შეთანხმება შეიძლება შეიცვალოს შეთანხმებით.

ტესტის შემთხვევების აღწერის ხარისხის კრიტერიუმები შეიძლება იყოს შემდეგი:

• სატესტო შემთხვევები უნდა დაიწეროს მოთხოვნების შესაბამისად

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

• გამოიყენეთ დეტალური წინაპირობები

როგორ დაზოგოთ დრო ტესტის შემთხვევებზე?

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

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

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

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

სკრიპტის ხარისხის კონტროლის პროცესი შეიძლება ჩატარდეს ტესტის მოდელის კონტროლით- სპეციალურად მომზადებული შაბლონი.

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

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

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

ტესტის მოდელის კონტროლი:

• საცდელი ლიანდაგი
• ტესტის ლინკი
• ჯირა+ზეფირი
• Microsoft ტესტის მენეჯერი (MTM)
• excel

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

ტესტირების პროცესის მიზნები

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

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

ტესტირების პროცესის მახასიათებლები RUP-ში

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

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

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

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

არტეფაქტები

ტესტირების დროს იქმნება შემდეგი დოკუმენტები:

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

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

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

Ტესტის პასუხებიდა ტესტების შესრულებისას მიღებული მონაცემები.

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

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

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

პროექტში შესვლის ეტაპი. ამ ეტაპზე მზადება ტესტირებისთვის. Ეს შეიცავს:

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

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

• ტესტის სცენარების შემუშავება.
• ტესტის სკრიპტების შექმნა.
• საკონტროლო ამოცანების შემუშავება.
• ტესტის მეთოდების შემუშავება.
• სამუშაო დატვირთვის მოდელის შემუშავება.

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

• შექმენით ტესტის გეგმა თითოეული გამეორებისთვის.
• ტესტირების მოდელის დახვეწა და დამატება.
• ტესტების შესრულება.
• აღმოჩენილი დეფექტების აღწერა.
• ტესტის შედეგების აღწერა.
• ტესტის შედეგების შეფასება.

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

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

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

ინსტრუმენტული მხარდაჭერა

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

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

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

ჩანჩქერის მოდელი (ხაზოვანი თანმიმდევრული პროგრამული უზრუნველყოფის სიცოცხლის ციკლის მოდელი)

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

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

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

შეიტყვეთ მეტი ჩანჩქერის მოდელის შესახებ წინა სტატიიდან..

V-მოდელი (ვერიფიკაციისა და ვალიდაციის მოდელი)

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

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

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

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

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

დამატებითი მოდელი

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

1. დიზაინი და განვითარება
2. ტესტირება
3. განხორციელება.

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

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

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

სპირალური მოდელი

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

1. დაგეგმვა
2. რისკის ანალიზი
3. განვითარება
4. შეფასება

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

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

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

სწრაფი

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

შეიტყვეთ მეტი Agile-ის შესახებ(შენიშვნა - სტატია ინგლისურად).

ექსტრემალური პროგრამირება (XP, ექსტრემალური პროგრამირება)

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

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

სკრამი

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

• Scrum-ის დაგეგმვაში მონაწილეობა
• ერთეულის ტესტირების მხარდაჭერა
• მომხმარებლის ისტორიის ტესტირება
• ითანამშრომლეთ მომხმარებელთან და პროდუქტის მფლობელთან მიღების კრიტერიუმების დასადგენად
• ავტომატური ტესტირების უზრუნველყოფა

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

ამავდროულად, Agile მეთოდოლოგიის პრინციპები Scrum-ში იწვევს სპეციფიკური მახასიათებლების გაჩენას:

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

შეიტყვეთ მეტი Scrum მეთოდოლოგიის შესახებ წინა სტატიიდან..

დასკვნა

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

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

ვებ სერვისის ტესტირება

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

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

რატომ შეაფასეთ?

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

1. იპოვნეთ თქვენი სუსტი ადგილები.ბუნებრივია, გვჭირდება ეს? არა მხოლოდ მწუხარება, არამედ იმის ცოდნა, თუ სად არის საჭირო გაუმჯობესება. რომელი ფუნქციური სფეროები არ არის დაფარული ტესტებით? რა არ შევამოწმეთ? სად არის შეცდომების გამოტოვების ყველაზე დიდი რისკი?
2. იშვიათად ვიღებთ 100%-იან დაფარვას შეფასების შედეგებიდან. რა გავაუმჯობესოთ? სად წავიდეთ? რა პროცენტია ახლა? როგორ გავზარდოთ იგი ნებისმიერი ამოცანებით? რამდენად სწრაფად შეგვიძლია მივიდეთ 100-მდე? ყველა ეს კითხვა ჩვენს პროცესს გამჭვირვალობასა და სიცხადეს ანიჭებს., და მათზე პასუხები მოცემულია დაფარვის შეფასებით.
3. ყურადღების ფოკუსირება.ვთქვათ, ჩვენს პროდუქტს აქვს დაახლოებით 50 სხვადასხვა ფუნქციური სფერო. გამოდის ახალი ვერსია, და ვიწყებთ მათგან 1-ის ტესტირებას და იქ ვპოულობთ ბეჭდურ შეცდომებს და ღილაკებს, რომლებმაც გადაიტანეს რამდენიმე პიქსელი და სხვა წვრილმანები... ახლა კი დამთავრდა ტესტირების დრო და ეს ფუნქციონალობა დეტალურად იქნა გამოცდილი.. და დარჩენილი 50? დაფარვის შეფასება საშუალებას გვაძლევს დავადგინოთ ამოცანების პრიორიტეტი მიმდინარე რეალობისა და ვადების მიხედვით.

როგორ შევაფასოთ?

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

მოთხოვნების დაფარვის შეფასება ტესტებით

ვთქვათ, გყავთ ანალიტიკოსები თქვენს გუნდში და ისინი უშედეგოდ არ ხარჯავენ დროს. სამუშაო დრო. მათი მუშაობის შედეგებიდან გამომდინარე შეიქმნა მოთხოვნები RMS-ში (Requirements Management System) - HP QC, MS TFS, IBM Doors, Jira (დამატებითი დანამატებით) და ა.შ. ამ სისტემაში ისინი აყენებენ მოთხოვნებს, რომლებიც შეესაბამება მოთხოვნების მოთხოვნებს (ბოდიში ტავტოლოგიისთვის). ეს მოთხოვნები არის ატომური, მიკვლევადი, სპეციფიკური… ზოგადად, იდეალური პირობები ტესტირებისთვის. რა ვქნათ ასეთ შემთხვევაში? სკრიპტირებული მიდგომის გამოყენებისას, ბმული მოთხოვნები და ტესტები. ჩვენ ვატარებთ ტესტებს იმავე სისტემაში, ვაკეთებთ მოთხოვნა-ტესტი კავშირს და ნებისმიერ დროს შეგვიძლია ვნახოთ ანგარიში, თუ რომელ მოთხოვნებს აქვს ტესტები, რომელს არა, როდის ჩააბარა ეს ტესტები და რა შედეგით.
ვიღებთ დაფარვის რუკას, ვფარავთ ყველა დაუფარავ მოთხოვნას, ყველა ბედნიერი და კმაყოფილია, შეცდომებს არ ვუშვებთ...

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

პრობლემა: მოთხოვნები არ არის ატომური.

ანალიტიკოსები ზოგჯერ სცოდავენ თავში სალათით და, როგორც წესი, ეს სავსეა პრობლემებით მთელ პროექტთან დაკავშირებით. მაგალითად, თქვენ ავითარებთ ტექსტურ რედაქტორს და შეიძლება გქონდეთ ორი მოთხოვნა თქვენს სისტემაში (სხვათა შორის): „html ფორმატირება უნდა იყოს მხარდაჭერილი“ და „მხარდაჭერილი ფორმატის ფაილის გახსნისას, ამომხტარი ფანჯარა შეკითხვით. უნდა გამოჩნდეს." რამდენი ტესტია საჭირო პირველი მოთხოვნის ძირითადი გადამოწმებისთვის? და მე-2-სთვის? პასუხებში განსხვავება, დიდი ალბათობით, დაახლოებით ასჯერა!!! ჩვენ ვერ ვიტყვით, რომ თუ არის მინიმუმ 1 ტესტი პირველ მოთხოვნაზე, ეს საკმარისია - მაგრამ დაახლოებით მე-2, სავარაუდოდ, მთლიანად.

ამდენად, მოთხოვნის ტესტის ჩატარება საერთოდ არაფრის გარანტიას არ გვაძლევს! რას ნიშნავს ჩვენი დაფარვის სტატისტიკა ამ შემთხვევაში? Თითქმის არაფერი! ჩვენ უნდა გადავწყვიტოთ!

1. ამ შემთხვევაში, ტესტებით მოთხოვნების დაფარვის ავტომატური გაანგარიშება შეიძლება მოიხსნას - ის მაინც არ ატარებს სემანტიკურ დატვირთვას.
2. თითოეული მოთხოვნისთვის, უმაღლესი პრიორიტეტით დაწყებული, ვამზადებთ ტესტებს. მომზადებისას ვაანალიზებთ რა ტესტები იქნება საჭირო ამ მოთხოვნისთვის, რამდენი იქნება საკმარისი? ჩვენ ვატარებთ სრულფასოვან ტესტის ანალიზს და არ განვთავისუფლდეთ "ერთი ტესტია, მაგრამ კარგი".
3. გამოყენებული სისტემიდან გამომდინარე, ჩვენ ვაწარმოებთ ტესტებს მოთხოვნისამებრ და… ვამოწმებთ ამ ტესტებს! საკმარისია ისინი? იდეალურ შემთხვევაში, რა თქმა უნდა, ასეთი ტესტირება უნდა ჩატარდეს ანალიტიკოსთან და ამ ფუნქციის შემქმნელთან. დაბეჭდეთ ტესტები, ჩაკეტეთ თქვენი კოლეგები შეხვედრების ოთახში და არ გაუშვათ ხელი, სანამ არ იტყვიან „დიახ, ეს ტესტები საკმარისია“ (ეს ხდება მხოლოდ წერილობითი შეთანხმებით, როდესაც ეს სიტყვები წარმოითქმის გამოწერის გასაუქმებლად, თუნდაც ტესტების გაანალიზების გარეშე. ზეპირი დისკუსიის დროს თქვენი კოლეგები გამოაქვეყნებენ კრიტიკას, გამოტოვებულ ტესტებს, არასწორად გაგებულ მოთხოვნებს და ა.შ. - ეს ყოველთვის არ არის სასიამოვნო, მაგრამ ძალიან სასარგებლოა ტესტირებისთვის!)
4. ტესტების მოთხოვნით დასრულება და მათ სისრულეზე შეთანხმების შემდეგ, სისტემაში ეს მოთხოვნა შეიძლება მონიშნოს სტატუსით „დაფარულია ტესტებით“. ეს ინფორმაცია ბევრად მეტს ნიშნავს, ვიდრე "აქ არის მინიმუმ 1 ტესტი".

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

პრობლემა: საერთოდ არ არსებობს მოთხოვნები.

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

1. შექმენით ფუნქციების სია. სამი! google-ტაბლეტის სახით, PBI ფორმატში TFS - აირჩიეთ ნებისმიერი, სანამ ის არ არის ტექსტის ფორმატი. ჩვენ ჯერ კიდევ გვჭირდება სტატუსების შეგროვება! ჩვენ შევიტანთ პროდუქტის ყველა ფუნქციურ სფეროს ამ სიაში და ვცდილობთ ავირჩიოთ დაშლის ერთი ზოგადი დონე (შეგიძლიათ ჩაწეროთ პროგრამული უზრუნველყოფის ობიექტები, ან მომხმარებლის სკრიპტები, ან მოდულები, ან ვებ გვერდები, ან API მეთოდები, ან ეკრანის ფორმები .. .) - მაგრამ ეს ყველაფერი ერთდროულად არა! დაშლის ერთი ფორმატი, რომელიც გაგიადვილებთ და ნათელს გახდის მნიშვნელოვანი ნივთების გამოტოვებას.
2. ჩვენ კოორდინაციას ვუწევთ ამ სიის სრულყოფილებას ანალიტიკოსებთან, დეველოპერებთან, ბიზნესთან, ჩვენი გუნდის ფარგლებში... ეცადეთ, ყველაფერი გააკეთოთ ისე, რომ არ დაკარგოთ პროდუქტის მნიშვნელოვანი ნაწილები! რამდენად ღრმა გაანალიზება თქვენზეა დამოკიდებული. ჩემს პრაქტიკაში იყო მხოლოდ რამდენიმე პროდუქტი, რომლისთვისაც ჩვენ შევქმენით 100-ზე მეტი გვერდი ცხრილში და ეს იყო გიგანტური პროდუქტები. ყველაზე ხშირად, 30-50 ხაზი არის მიღწევადი შედეგი შემდგომი ფრთხილად დამუშავებისთვის. პატარა გუნდში ერთგული ტესტის ანალიტიკოსების გარეშე მეტი fichelista ელემენტების შენარჩუნება ძალიან რთული იქნება.
3. ამის შემდეგ, ჩვენ გავდივართ პრიორიტეტებს და ვამუშავებთ ფიჩელისტის თითოეულ ხაზს, როგორც ზემოთ აღწერილი მოთხოვნების განყოფილებაში. ვწერთ ტესტებს, განვიხილავთ, ვთანხმდებით საკმარისობაზე. ჩვენ აღვნიშნავთ სტატუსებს, რისთვისაც არის საკმარისი ტესტები. ჩვენ ვიღებთ სტატუსს, პროგრესს და ტესტების გაფართოებას გუნდთან კომუნიკაციის გზით. ყველა ბედნიერია!

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

პრობლემა: მოთხოვნები არ არის მიკვლევადი.

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

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

მაგრამ… არც ისე დიდი ხნით… როგორც ჩანს, ბოლო კვირაში ანალიტიკოსებმა განაახლეს 4 განსხვავებული სპეციფიკაცია მომხმარებელთა მოთხოვნიდან გამომდინარე!!!

პრობლემა: მოთხოვნები მუდმივად იცვლება.

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

1. ვთქვათ, თქვენ უკვე შეაგროვეთ ბმულები TK-ზე და სპეციფიკაციები ფუნქციების სიის სახით, PBI, მოთხოვნები, ვიკი შენიშვნები და ა.შ. ვთქვათ, თქვენ უკვე გაქვთ ტესტები ამ მოთხოვნებისთვის. ახლა კი მოთხოვნა იცვლება! ეს შეიძლება ნიშნავდეს ცვლილებას RMS-ში, ან ამოცანას TMS-ში (Task Management System) ან წერილს ფოსტით. ნებისმიერ შემთხვევაში, ეს იწვევს იმავე შედეგს: თქვენი ტესტები მოძველებულია! ან ისინი შეიძლება იყოს შეუსაბამო. ეს ნიშნავს, რომ მათ სჭირდებათ განახლება (დაფარვა ტესტებით ძველი ვერსიაპროდუქტი რატომღაც დიდად არ განიხილება, არა?)
2. ფუნქციების სიაში, RMS-ში, TMS-ში (ტესტი მენეჯმენტის სისტემა - testails, sitechco და ა.შ.) ტესტები დაუყოვნებლივ და უშეცდომოდ უნდა იყოს მონიშნული, როგორც შეუსაბამო! HP QC-ში ან MS TFS-ში ეს შეიძლება გაკეთდეს ავტომატურად მოთხოვნების განახლებისას, ხოლო google-ტაბლეტში ან ვიკიში მოგიწევთ კალმების დადება. მაგრამ თქვენ დაუყოვნებლივ უნდა ნახოთ: ტესტები შეუსაბამოა! ეს ნიშნავს, რომ ჩვენ ველოდებით სრულ ხელახლა გზას: განახლება, ხელახლა გაშვება ტესტის ანალიზს, ხელახლა ჩაწერა ტესტები, შეთანხმება ცვლილებებზე და მხოლოდ ამის შემდეგ მონიშნეთ ფუნქცია/მოთხოვნა ხელახლა, როგორც „დაფარულია ტესტებით“.

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

პრობლემა: არ არის საკმარისი დრო ტესტების დასაბუთებისთვის.

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

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

მაგრამ… კიდევ რა "გარდა"? რომელი???

თქვით, ჩვენ ყველაფერს შემოვივლით და შეიძლება ჩვენთან იყოს მაღალი ხარისხის პროდუქტები!

| სასწავლო წლის გაკვეთილების დაგეგმვა | მოდელირების ძირითადი ეტაპები

გაკვეთილი 2
მოდელირების ძირითადი ეტაპები

ამ თემის შესწავლით თქვენ გაიგებთ:

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

კომპიუტერული ექსპერიმენტი

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

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

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

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

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

ექსპერიმენტის გეგმა

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

ტესტირება არის აგებული მოდელის სისწორის შემოწმების პროცესი.

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

მიღებული მოდელირების შედეგების სისწორეში დასარწმუნებლად საჭიროა: ♦ მოდელის ასაგებად შემუშავებული ალგორითმის შემოწმება; ♦ დარწმუნდით, რომ აგებული მოდელი სწორად ასახავს ორიგინალის თვისებებს, რაც გათვალისწინებული იყო სიმულაციისას.

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

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

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

კვლევის ჩატარება

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

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

კომპიუტერული ექსპერიმენტის მომზადებისა და ჩატარების სქემა ნაჩვენებია ნახაზზე 11.7.

ბრინჯი. 11.7. კომპიუტერული ექსპერიმენტის სქემა

სიმულაციის შედეგების ანალიზი

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

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

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

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

აკონტროლეთ კითხვები და ამოცანები

1. რა არის მოდელირების პრობლემის განცხადების ორი ძირითადი ტიპი.

2. გ.ოსტერის ცნობილ „პრობლემათა წიგნში“ შემდეგი პრობლემაა:

ბოროტი ჯადოქარი, რომელიც დაუღალავად მუშაობს, დღეში 30 პრინცესას ქიაყად აქცევს. რამდენი დღე დასჭირდება მას, რომ 810 პრინცესა ქიაყელებად აქციოს? დღეში რამდენი პრინცესა უნდა გადაიქცეს მუხლუხოებად, რომ საქმე 15 დღეში შესრულდეს?
რომელი კითხვა შეიძლება მივაკუთვნოთ ტიპს "რა მოხდება, თუ ..." და რომელი - "როგორ გავაკეთოთ ისე, რომ ..."?

3. ჩამოთვალეთ მოდელირების ყველაზე ცნობილი მიზნები.

4. გააფორმეთ სათამაშო პრობლემა გ.ოსტერის "პრობლემების წიგნიდან":

ერთმანეთისგან 27 კმ-ის დაშორებით მდებარე ორი ჯიხურიდან ერთმანეთისკენ ერთდროულად გადმოხტა ორი ჯიუტი ძაღლი. პირველი დადის 4 კმ/სთ სიჩქარით, ხოლო მეორე - 5 კმ/სთ.
როდემდე დაიწყება ბრძოლა?

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

6. მოზარდის რა მახასიათებლებია აუცილებელი პროფესიის არჩევის რეკომენდაციისთვის?

7. რატომ არის კომპიუტერი ფართოდ გამოყენებული სიმულაციაში?

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

9. რა არის კომპიუტერული ექსპერიმენტი? მიეცი მაგალითი.

10. რა არის მოდელის ტესტირება?

11. რა შეცდომები გვხვდება მოდელირების პროცესში? რა უნდა გაკეთდეს შეცდომის აღმოჩენისას?

12. როგორია სიმულაციის შედეგების ანალიზი? რა დასკვნები კეთდება ჩვეულებრივ?