QA The Other Wayხარისხის უზრუნველყოფა AI ავტომატიზაციის ეპოქაში. QA The Other Way.
პრაქტიკული QA

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

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

5 კითხვა: წუთიQA The Other Way
ორი Apply ღილაკი, ერთი კვირის განახლებების არეში.
ავტორის სარედაქციო ილუსტრაცია.
საილუსტრაციო ვიდეო ამ სტატიისთვის. ინგლისური ტექსტი ეკრანზე; აირჩიეთ სუბტიტრები ამ ენისთვის.

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

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

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

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

ორივე დამთხვევა ნახეთ

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

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

const weekly = page.getByRole('region', { name: 'Weekly updates' });
const apply = weekly.getByRole('button', { name: 'Apply', exact: true });
await expect(apply).toHaveCount(1);
await apply.click();
await expect(weekly.getByRole('status')).toHaveText('Applied');

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

არის არჩევანს მიზეზი ჰქონდეს

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

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

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

პოზიციას რიგის შეთანხმება სჭირდება

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

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

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

საერთო კითხვები

ზუსტი ტექსტი ერთნაირ სახელებს განასხვავებს?

არა. საჭირო არე ან ჩანაწერიც შეზღუდეთ.

first() ყოველთვის შეცდომაა?

არა. საჭიროა თანმიმდევრობის აშკარა მოთხოვნა და შემოწმებული ვინაობა.

წყაროები