შექმენით თქვენი ბრაუზერის მატრიცა რისკისგან და არა ჩამრთველიდან

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

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

გამოყავით სამი გადაწყვეტილება

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

Playwright დოკუმენტების მხარდაჭერა Chromium-ის, Firefox-ისა და WebKit-ისთვის, პლუს ბრენდირებული Chromium არხებისთვის, როგორიცაა Chrome და Edge. მისი WebKit build არ არის ბრენდირებული Safari. ამიტომ, მწვანე WebKit შედეგი უნდა იყოს აღწერილი, როგორც WebKit მტკიცებულება და არა პრეტენზია, რომ Safari-ის ყველა ვერსია გავიდა ყველა iPhone-ზე.

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

შეადგინეთ მოგზაურობა იმ რისკისკენ, რომელსაც ის შეიცავს

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

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

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

გააკეთეთ პროექტების სახელები, რომ თქვან რას აწარმოებენ

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

import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  projects: [
    { name: 'chromium-desktop', use: { ...devices['Desktop Chrome'] } },
    { name: 'firefox-desktop', use: { ...devices['Desktop Firefox'] } },
    { name: 'webkit-phone-emulation', use: { ...devices['iPhone 13'] } }
  ]
});

დააინსტალირეთ შესაბამისი ბრაუზერის ორობითი ფაილები თქვენს სატესტო გარემოში. გაუშვით დასახელებული პროექტი npx დრამატურგის ტესტით --project=webkit-phone-emulation. ეს სახელები აღწერს კონფიგურაციას და არა პროდუქტის გარანტიას. კოდი არის ამოსავალი წერტილი თქვენი საკუთარი მხარდაჭერის პოლიტიკისთვის და არა უნივერსალური რეკომენდებული მატრიცა.

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

დაადგინეთ განსხვავება კონფიგურაციის წაშლის ნაცვლად

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

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

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

სადაც ჯდება გენერირებული კვლევა

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

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