TestRail - ინდივიდუალური პარამეტრები პროექტისთვის

შესავალი

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

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

დასაბუთების გეგმა (რა განხორციელდება)

1. ზოგადი მოთხოვნები

   1. აბსოლუტურად ნებისმიერს უნდა შეეძლოს საქმის გავლა.

   2. საქმეები უნდა დარჩეს აქტუალური რაც შეიძლება დიდხანს

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

2. დაიყო TestCase და TestScenario

3. სხვადასხვა ტიპის TestRun-ის სწრაფი თაობა

   1. მოწევა

   2. უკუსვლა

   3. ზემოქმედების ტესტირება და ა.შ.

4. საქმის მხარდაჭერის ოპტიმიზაცია

   1. „მკვდარი“ მყარი კოდირებული ეკრანის ანაბეჭდების მიტოვება და „მოძრავ მონაცემებზე“ გადასვლა

მოთხოვნები

ველების რედაქტირებისთვის დაგჭირდებათ ადმინისტრატორის წვდომა

პროექტის ტიპის შერჩევა

არსებობს სამი ტიპის პროექტის არჩევანი:

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

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

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

თქვენ ასევე შეგიძლიათ დაამატოთ სხვა ველები.

სატესტო საქმის ველების და ტეგების დაყენება

გახსენით პარამეტრების მენიუ:

დაგვჭირდება შემდეგი ველები:

ველი „შეჯამება“ (სატესტო შემთხვევის სათაური)

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

ტესტის სცენარი:

მაგალითი: TestScenario - მობილური აპლიკაციის გამოყენების ძირითადი სცენარი

ტესტის შემთხვევა:

მაგალითი: MainScreen - ავტორიზაციის განყოფილება - შეიყვანეთ შესვლა

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

"StartScreen" ტეგი (ეკრანი, საიდანაც იწყება TestScenario; ასევე, ბევრ სატესტო შემთხვევას შეუძლია შეეხოს მიმდებარე ეკრანებს)

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

შექმენით ახალი ველი:

შეავსეთ ახალი ველის კომპონენტები:

ამ შემთხვევაში, ჩვენ ვქმნით შერჩეულ ველს მნიშვნელობების სიიდან. შეიყვანეთ ამ ველის მნიშვნელობები:

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

და ამის შემდეგ დაგვჭირდება მესამე ეკრანის შექმნა ორ არსებულს შორის,

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

მონიშნეთ „ეკრანი“ (ეკრანის სახელი, რომელიც გავლენას ახდენს TestCase-ზე)

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

მაგალითი: საწყისი_ეკრანი, MapScreen, PayScreen და ა.შ.

ველი „MovableData“ (ბმული პროქსი მონაცემთა ბაზასთან ცვალებადი ტესტის მონაცემებით)

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

1. ბმულები მიმდინარე განლაგებებზე (ეს ბევრად უკეთესია, ვიდრე მკვდარი ეკრანის ანაბეჭდების გადაღება)

2. ტიპიური ნაბიჯები ტესტის სიტუაციით ეკრანზე მისასვლელად

3. SQL მოთხოვნები

4. ბმულები გარე მონაცემებთან და სხვა მონაცემებთან

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

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

იყიდება Google Sheet შეგიძლიათ გამოიყენოთ SQL მოთხოვნები. მაგალითი:

=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'")

იყიდება Excel თქვენ შეგიძლიათ დააყენოთ მოსახერხებელი მყისიერი საძიებო მაკროები. (გაფილტვრა) მაგალითი по ссылке.

სინამდვილეში, იდეა ახალი არ არის და აღწერილია პირველი ტესტერის წიგნში "Testing dot com". (ავტორი Savin Roman) ჩვენ უბრალოდ ვაერთიანებთ რომან სავინის მიერ შემოთავაზებულ მეთოდებს TestRail-ში. ამისათვის შექმენით ველი შექმნილი ფაილის ბმულით:

შეავსეთ ბმულის ნაგულისხმევი მნიშვნელობა ისე, რომ ყოველ ახალ სატესტო შემთხვევას უკვე ჰქონდეს ბმული:

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

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

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

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

მონიშნეთ „კომპონენტი“ (მობილური აპლიკაციის კომპონენტი)

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

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

ტეგი "TAG" (სხვა თეგები ფილტრაციისთვის)

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

ძალიან სასარგებლოა: 

1. TestRun-ის სწრაფად შედგენა სხვადასხვა ტიპიური ამოცანებისთვის: კვამლი, რეგრესია და ა.შ.

2. ტესტები ავტომატიზირებული იქნება თუ უკვე ავტომატიზირებული?

3. ნებისმიერი სხვა ტეგი

მაგალითი: Smoke, Automated, WhiteLabel, ForDelete და ა.შ.

ტესტის შემთხვევაში ველების ჩვენების რიგის დაყენება

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

TestRun-ის შექმნა

ახლა ჩვენ შევქმნით ახალ ტესტირებას მიმდინარე შემთხვევებით კვამლის ტესტირების ჩასატარებლად სამი დაწკაპუნებით:

სხვა სასარგებლო რჩევები

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

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

3. ანგარიშების გაზიარება შესაძლებელია. მაგალითად: ერთი ადმინისტრატორი, რამდენიმე მომხმარებელი.

დასკვნა

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

ბმულები:

TestRail გამყიდველის ვებსაიტი

Წიგნი: "ტესტირება .COM" (ავტორი რომან სავინი)

Დიდი მადლობა ყურადღებისთვის!

წყარო: www.habr.com