ტესტი ავტომატიზაციის სტრატეგია სწრაფი პროექტებისთვის

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

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

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




რეზიუმე

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

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


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

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

დაკავშირებული:



ტესტის ავტომატიზაციის სტრატეგიის მიმოხილვა

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


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

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

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

ერთეულის ტესტები ქმნის ტესტის ავტომატიზაციის საფუძვლებს მაღალ დონეზე.


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



რეგრესიული პაკეტის განმარტება

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

კვამლის რეგრესიის პაკეტი

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

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


კვამლის ტესტის პაკეტი მუშაობს ყველა განლაგებაზე და ის შეიძლება იყოს API და / ან GUI ტესტების ნარევი.

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

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

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


რადგან ეს ფუნქციური ტესტები უფრო დეტალურადაა გატარებული, მათ უფრო დიდი დრო დასჭირდება, ამიტომ მნიშვნელოვანია, რომ ფუნქციური ტესტების უმეტესობა გვქონდეს API ფენაზე, სადაც ტესტების შესრულება შეიძლება უფრო სწრაფად, ასე რომ, 15-დან 30 წუთამდე დროის ლიმიტი.

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

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

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



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

ტესტი_ავტომატიზაციის_სტრატეგია_გონილი

ავტომატიზირებული ერთეულის ტესტები

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

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

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

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

ავტომატური ინტეგრაციის / API ან მომსახურების ტესტები

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

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

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

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

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

განაცხადის ტესტირება

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

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

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

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

ბოლოდან ბოლოს სცენარის ტესტები

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



ტესტის ავტომატიზაციის პირამიდის ინვერსია

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

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

მყიფე

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

შეზღუდული ტესტირება

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

ნელი

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

მინიმუმ ROI

ზემოხსენებული საკითხების გამო, GUI ავტომატიზირებული ტესტები უზრუნველყოფს მინიმუმ ROI- ს.

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

საინტერესო სტატიები