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

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

იხსნება ფაილის ამომრჩეველი, ტესტი ირჩევს ფაილს და კომპლექტი აცხადებს, რომ ატვირთვა დასრულებულია. აპლიკაციამ მიიღო მხოლოდ შეყვანის არჩევანი. მან შეიძლება მაინც უარყოს ფორმატი, ვერ დადასტურდეს ან არასოდეს დაასრულოს დამუშავება. მწვანე შერჩევის ნაბიჯი უფრო ვიწრო შედეგია, ვიდრე გამოსაყენებელი ატვირთული დოკუმენტი.
ეს სახელმძღვანელო იყენებს Playwright-ის შეყვანის დოკუმენტაციას მცირე ლოკალური ტექსტური ფაილების შესაქმნელად. ფაილი შეიცავს გამოგონილ შინაარსს. ეს არ არის მომხმარებლის დანართი, პირადობის დამადასტურებელი დოკუმენტი ან პროდუქტის მაგალითი. ჩვენ გამოვყოფთ ბრაუზერის შეყვანის კონტრაქტს ნებისმიერი დამუშავებისგან, რომელსაც განახორციელებს აპლიკაცია.
მიეცით მოწყობილობას წაკითხვადი იდენტურობა
სატესტო მოწყობილობაში უნდა იყოს მითითებული მისი სახელი, MIME ტიპი და შინაარსი. მცირე ტექსტის მაგალითისთვის, მეხსიერებაში არსებული დატვირთვის გადახედვა უფრო ადვილია, ვიდრე აუხსნელი ორობითი საცავში. გამოიყენეთ რეალისტური მოქმედი მონაცემები თქვენი პროდუქტისთვის, მაგრამ მოერიდეთ პირადი წყაროს დოკუმენტებს, როდესაც კონტროლირებადი ნიმუში უპასუხებს კითხვას.
await page.getByLabel('Demo attachment').setInputFiles({
name: 'demo-note.txt',
mimeType: 'text/plain',
buffer: Buffer.from('Invented demo note\n', 'utf8')
});
await expect(page.getByRole('status')).toHaveText('Selected: demo-note.txt');ფრაგმენტი ითვალისწინებს ფაილის ხელმისაწვდომ შეყვანას და ადგილობრივ ინტერფეისის ქცევას, რომელიც აცნობებს მის არჩეულ ფაილის სახელს. მტკიცება ადგენს, რომ ქცევა, არა წარმატებული სერვერის შენახვა. შეინახეთ ეს ზღვარი ტესტის სათაურში და განმარტებით ფიგურაში.
Playwright დოკუმენტებს ბილიკებს, მრავალ ფაილს, დატვირთვის ობიექტებს და არჩევს setInputFiles-ის მეშვეობით. აირჩიეთ ყველაზე პატარა შეყვანის ფორმა, რომელიც შეესაბამება საქმეს. მრავალფაილიან ტესტს სჭირდება მოთხოვნა შეკვეთის, ლიმიტებისა და ინდივიდუალური შეცდომების შესახებ; ეს არ არის უბრალოდ იგივე ბედნიერი გზა, რომელიც მეორდება მეტი სახელებით.
გამოიყენეთ ამომრჩევის ღონისძიება მხოლოდ მაშინ, როდესაც ის არის საჭირო საზღვარი
ზოგიერთი ინტერფეისი ქმნის შეყვანას დინამიურად ღილაკზე დაჭერის შემდეგ. შეყვანის სახელმძღვანელო აღწერს ველოდები filechooser მოვლენას მოქმედებამდე და შემდეგ გამოიძახებს setFiles დაბრუნებულ ამომრჩეველზე. დააყენეთ მოვლენის მოლოდინი პირველ რიგში, რათა სწრაფი ამომრჩეველი კვლავ იყოს დაკავშირებული ინიცირების კონტროლთან.
const pendingChooser = page.waitForEvent('filechooser');
await page.getByRole('button', { name: 'Choose demo file' }).click();
const chooser = await pendingChooser;
await chooser.setFiles({
name: 'demo-note.txt',
mimeType: 'text/plain',
buffer: Buffer.from('Invented demo note\n', 'utf8')
});ეს არის ალტერნატიული შერჩევის მიდგომები სხვადასხვა ინტერფეისისთვის და არა ორი აუცილებელი ნაბიჯი ერთ ატვირთვაში. ნუ ავტომატიზირებთ მშობლიურ ოპერაციული სისტემის დიალოგს გამოცნობილი ეკრანის კოორდინატებით, როდესაც დოკუმენტირებული შეყვანა ან ამომრჩეველი საზღვრები პირდაპირ გამოხატავს მოქმედებას.
შერჩევა, მიღება და დამუშავება ცალკე მდგომარეობაა
შერჩევის შემდეგ, აპლიკაციას შეუძლია შეამოწმოს ფაილი, გაგზავნოს სერვერზე და გაუშვას ფონური პროცესორი. დაწერეთ მოსალოდნელი მდგომარეობა თითოეული შესაბამისი ფენისთვის. მომხმარებლის წინაშე მიმღები შეტყობინება უნდა ნიშნავდეს იმას, რასაც ის ამბობს. თუ დამუშავება ჯერ კიდევ ელოდება, ტესტმა არ უნდა დაასახელოს მთელი ფუნქცია დასრულებული.
ატვირთვის ფაქტობრივი მოგზაურობისთვის გამოიყენეთ დამტკიცებული საცავი და გადაამოწმეთ საბოლოო კონტროლირებადი ჩანაწერი პროდუქტის მხარდაჭერილი მტკიცებულებების მეშვეობით. შეამოწმეთ, რომ სწორი დოკუმენტი ხელმისაწვდომია და არა მხოლოდ ის, რომ სპინერი გაქრა. არ ატვირთოთ გამოგონილი ტესტები ცოცხალი მომხმარებლის საქაღალდეში მხოლოდ იმიტომ, რომ UI ამარტივებს.
ფაილის სახელი და MIME ტიპი შეყვანილია და არა ფაილის შინაარსის დამოუკიდებელი მტკიცებულება. ტექსტური დატვირთვა სახელად image.png არ არის სწორი სურათი. უარის ტესტირებისას აირჩიეთ მიზანმიმართული არასწორი ეგზემპლარები და მიღებისას მოქმედი ნიმუშები. ახსენით, რომელ კონტრაქტს ითვალისწინებს თითოეული ნიმუში.
შეინახეთ არასწორი შემთხვევები მცირე და სასარგებლო
პროდუქტმა შეიძლება უარყოს მხარდაჭერილი ფორმატი, დიდი ზომის შეყვანა, ცარიელი ფაილი ან დუბლიკატი. ჩამოაყალიბეთ მოსალოდნელი პოლიტიკა განაცხადის გუნდისგან ამ განცხადებების დაწერამდე. ნუ გამოიგონებთ მაქსიმალურ ზომას ან არ ჩავთვალოთ, რომ ბრაუზერის მიღების ატრიბუტი უსაფრთხოების მთელი წესია.
გადაამოწმეთ ახსნა და უსაფრთხო შემდეგი ქმედება უარყოფილი ფაილისთვის. მომხმარებელს უნდა შეეძლოს აირჩიოს სხვა ფაილი ან წაშალოს არჩევანი, თუ ეს არის განკუთვნილი დიზაინი. ტესტის გასუფთავება ასევე მნიშვნელოვანია: მიღებული ეტაპობრივი ატვირთვა შეიძლება დარჩეს ბრაუზერის დახურვის შემდეგ, ამიტომ მოაწყეთ ჩანაწერის ამოღება დამტკიცებული მარშრუტით.
შეინახეთ მოწყობილობები და შედეგად მიღებული წარუმატებლობის არტეფაქტები კონფიდენციალურობის განხილვის ქვეშ. მცირე გამოგონილი შენატანები უფრო ადვილი შესამოწმებელია და უფრო უსაფრთხოა გავრცელება, ვიდრე გადაღებული რეალური დოკუმენტები. სკრინშოტებმა და კვალმა შეიძლება გამოავლინოს არჩეული ფაილის სახელები მაშინაც კი, როდესაც ფაილის ბაიტი არ არის მიმაგრებული.
AnyTest აღწერს აგენტებს, რომლებიც იკვლევენ ვებ აპს და ქმნიან ბოლომდე ტესტებს ადამიანის განსახილველად. გამოიყენეთ ეს საზღვრები ნებისმიერი შემოთავაზებული ფაილის გადასახედად: შერჩეული, მიღებული, დამუშავებული და ხელმისაწვდომი. ეს სახელმძღვანელო არ ამტკიცებს კონკრეტულ AnyTest ატვირთვის ინტერფეისს ან ვალიდაციის ინტეგრაციას. სარგებელი არის მკაფიო არტეფაქტის კონტრაქტი, რომელიც ხელს უშლის წარმატებული შეყვანის ქმედებას სერვერის შედეგების ცრუ დაპირებად.
საერთო კითხვები
ადასტურებს თუ არა ფაილის არჩევა ატვირთვის დასრულებას?
არა. შერჩევა, მიღება და საბოლოო სერვერის დამუშავება ცალკე მტკიცებულებაა.
შეუძლია თუ არა მოწყობილობას რეალური მომხმარებლის დოკუმენტის გამოყენება?
გამოიყენეთ გამოგონილი ან დამტკიცებული დადგმის ნიმუშები. მოერიდეთ პირად ფაილებს, როდესაც კონტროლირებადი კონტენტი პასუხობს ტესტის კითხვას.