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

მწვანე ნიშანი მტკიცებულება არ არის

AI აგენტებს შეუძლიათ end-to-end ტესტების დაწერა, მაგრამ წარმატების შეტყობინება ჯერ კიდევ არ ამტკიცებს, რომ მონაცემები შეინახა. შედეგი დამოუკიდებელი გზით გადაამოწმეთ.

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

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

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

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

ორაკულის პრობლემა, ერთ აბზაცში

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

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

რატომ მიდის AI-ით დაწერილი ტესტები სუსტი ორაკებისკენ

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

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

Oracle-ის სამი განახლება, რომლებიც დღეს მუშაობს

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

დააყენეთ ერთი ფენა ქვემოთ. დრამატურგს შეუძლია დაელოდოს ქსელის პასუხს, რომელზეც დამოკიდებულია UI. დააწყვილეთ UI მტკიცება expect(response).toBeOK()-თან API გამოძახებისას, რომელიც რეალურად ინახავს, ​​ან მიმართეთ API-ს უშუალოდ UI ნაკადის შემდეგ და შეადარეთ შენახული მნიშვნელობა.

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

მიმოხილვის კითხვა, რომელიც ყველაფერს ცვლის

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

ეს არის ასევე პატიოსანი გზა გამოიყენოს ინსტრუმენტი, როგორიცაა AnyTest. მისი აგენტები იკვლევენ თქვენს აპს URL-დან, ქმნიან end-to-end ტესტებს და ტოვებენ მათ განსახილველად. განხილვის ზედაპირი აჩვენებს თითოეულ ნაბიჯს და მის შედეგს. კარგად გამოყენებული, ეს მიმოხილვა არის ადგილი, სადაც ხდება ორაკულის შემოწმება: არა "აგენტმა დააწკაპუნა სწორ რამეებზე", არამედ "დაამტკიცებს თუ არა მის მიერ დაწერილმა ტესტმა რამე". გამყიდველის საკუთარი მასალა ამბობს, რომ ადამიანები მაინც გადაწყვეტენ. ეს არის გადაწყვეტილება, რომელიც მნიშვნელოვანია.

მწვანე გამშვები ნიშანი გეუბნებათ, რომ ტესტი გაიქცა. ის არასოდეს გეუბნებათ, რომ ტესტი სწორი იყო.

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

რა არის საცდელი ორაკული?

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

ადასტურებს თუ არა ჩაბარებული ტესტირება, რომ ფუნქცია მუშაობს?

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

როგორ გავაკონტროლო AI აგენტის მიერ დაწერილი ტესტები?

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

წყაროები