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

  • გადააქციეთ მომხმარებლის გამოხმაურება მოქმედებად ტესტირებისა და შეცდომების გამოსწორების გეგმად სისტემატური ჩარჩოს გამოყენებით
  • გამოიყენეთ ხელოვნური ინტელექტის დახმარებით გამართვა და გამოიყენეთ „მასწავლე“ ნიმუში გამოსწორებების გასაგებად.
  • დაწერეთ მარტივი ტესტები, რათა დაადასტუროთ გამოსწორებული შეცდომების მუშაობა და აღმოაჩინოთ პოტენციური რეგრესიული პრობლემები.
  • გამოიყენეთ ბრაუზერის DevTools პრობლემების იდენტიფიცირებისა და დიაგნოსტიკისთვის
  • გამართული MVP: თქვენი MVP აპლიკაცია P0/P1 შეცდომებით გამოსწორებულია
  • უკუკავშირის ტრიაჟის სისტემა: პრიორიტეტული სამოქმედო გეგმა 3-კითხვიანი ჩარჩოსა და MoSCoW მეთოდის გამოყენებით
  • პრობლემების თვალთვალი: შეცდომების, ძირითადი მიზეზების და გამოსწორებების სტრუქტურირებული დოკუმენტაცია
  • ტესტის საკონტროლო სია: დოკუმენტაცია რეგრესიის პრევენციისა და პრობლემების თვალყურის დევნებისთვის
  • სტუდენტებმა დაასრულეს სამუშაო MVP (ეკრანები, ნავიგაცია, ხელოვნური ინტელექტის ფუნქცია) თქვენი ხელოვნური ინტელექტით აღჭურვილი პროტოტიპის შექმნის საკითხში.
  • სტუდენტებმა დაასრულეს თქვენი MVP-ის იტერაცია და დახვეწა 5-10 მომხმარებლის ტესტირების უკუკავშირის გამოყენებით.

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

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

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

უკუკავშირიდან სამოქმედო გეგმამდე

მომხმარებლის გამოხმაურება ფასდაუდებელია, მაგრამ ხშირად ის არასასიამოვნო ფორმით მოდის.

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

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

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

აქტივობა 1

შექმენით თქვენი უკუკავშირის ტრიაჟის სისტემა

სავარაუდო დრო: 20 წუთი

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

გახსენით თქვენი საცავი Github-ზე და გახსენით თქვენი Codespace. 

თუ ჯერ კიდევ გაქვთ ღია საცავის ფილიალი, გამოიყენეთ ეს ფილიალი და კოდური სივრცე.

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

git pull origin main

git checkout ახალი ფილიალის სახელი

git checkout -b ახალი ფილიალის სახელი

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

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

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

  1. თქვენს კოდურ სივრცეში შექმენით ახალი საქაღალდე სახელწოდებით test და ახალი ფაილი სახელწოდებით issue_tracker.md . ამის გაკეთება შეგიძლიათ ფაილების მკვლევარის პანელში (დააწკაპუნეთ ახალი ფაილის ხატულაზე).
  2. სთხოვეთ Github Copilot-ს, მოგაწოდოთ სტრუქტურირებული და კატეგორიზებული პრობლემების ნაკრები, მიუთითეთ მას თქვენი ტესტირების შედეგად მიღებული ყველაზე გავრცელებული P0/P1 პრობლემები. შეგიძლიათ გამოიყენოთ ეს შაბლონი:

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

ქვემოთ მოცემული თითოეული საკითხისთვის მიუთითეთ:

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

აქ არის ჩემი პრობლემები:

  1. დააკოპირეთ და ჩასვით თქვენი ყველაზე გავრცელებული P0/P1 პრობლემები შეკითხვის ბოლოში. შეგიძლიათ სამუშაო ფურცელში ჩართოთ ის, რაც უკვე გაქვთ ცხრილში.
  2. წაიკითხეთ, რას ქმნის Copilot. თითოეული პრობლემისთვის ჰკითხეთ საკუთარ თავს:
    • შესაძლო ძირეული მიზეზების აღწერას აზრი აქვს ჩემი აპლიკაციისთვის?
    • „სად უნდა ვეძებოთ პირველ რიგში“ ჩემი კოდის სწორ ნაწილზე მიუთითებს?
  3. თუ რამე არასწორად მოგეჩვენებათ, აცნობეთ Copilot-ს. მაგალითად: „პრობლემა 1-ისთვის, ჩემი აპლიკაცია იყენებს React-ს და Groq API-ს. შეცდომა ხდება მაშინ, როდესაც მომხმარებელი აგზავნის ფორმას. შეგიძლიათ შეცვალოთ ძირითადი მიზეზები?“
  4. როგორც კი კმაყოფილი დარჩებით, დააკოპირეთ დაზუსტებული აღწერილობები თქვენს issue_tracker.md ფაილში და შეინახეთ ფაილი.

დააინსტალირეთ და დააკოპირეთ თქვენი ცვლილებები თქვენს საცავის ფილიალში.

„მასწავლე“-ს ნიმუში

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

„მასწავლე“-ს ნიმუშს შეუძლია ამის შეცვლა. ხელოვნური ინტელექტისთვის პრობლემის გადაჭრის თხოვნის ნაცვლად, თქვენ სთხოვთ მას ჯერ პრობლემის ახსნა. თქვენს მითითებებს ერთ ინსტრუქციას უმატებთ:

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

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

„მასწავლე“ ნიმუშის გარეშე

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

ხელოვნური ინტელექტი: დაემატა 3 ხაზი 61-ე ხაზზე. განახლდა ბექენდი, რათა შეამოწმოს Groq API შეცდომები პასუხში და დააბრუნოს შეცდომის დეტალები (შეცდომის კოდების ჩათვლით) წინა პლანზე, ნაგულისხმევად „პასუხის არარსებობის“ ნაცვლად.

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

„მასწავლე“ ნიმუშით

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

AI: მთავარი საკითხი:

fetch HTTP შეცდომებს არ აჩვენებს.

ასე რომ, ეს კოდი:

const groqResponse = await fetch(groqUrl, { ... })
const groqData = await groqResponse.json()

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

  • 401 (API გასაღები არასწორია)

  • 429 (ტარიფის ლიმიტი)

  • 400 (მოდელის სახელი არასწორია)

ასეთ შემთხვევებში, Groq აბრუნებს შეცდომა JSON, არა choices, ამიტომ ეს ხაზი:

const text = groqData.choices?.[0]?.message?.content || 'No response.'

უკან ბრუნდება "No response."

აპლიკაცია აჩვენებს შეტყობინებას „Groq-მა არ უპასუხა “ , სინამდვილეში კი უპასუხა , თუმცა შეცდომით.

გამოსწორება: მოძიებისთანავე დაამატეთ სტატუსის შემოწმების ფუნქცია:

 
if (!groqResponse.ok) {
const errorText = await groqResponse.text()
console.error('Groq API HTTP error:', groqResponse.status, errorText)
return res.status(500).json({
error: 'Groq API request failed',
status: groqResponse.status,
details: errorText,
})
}

შემდეგ JSON-ის გაანალიზება მხოლოდ იმ შემთხვევაში მოახდინეთ, თუ ის ნორმალურია .

DevTools

ყველა ბრაუზერს აქვს ჩაშენებული Developer Tools , რომელიც საშუალებას გაძლევთ ნახოთ, რა ხდება კულისებში. თქვენ ცოტა ხნით გამოიყენეთ DevTools Founder's Toolkit-ში localStorage-ის სანახავად. ახლა თქვენ დამატებით ჩანართებს გამოიყენებთ:

  • კონსოლის ჩანართი – აჩვენებს JavaScript-ის შეცდომებს და თქვენი აპლიკაციის მიერ წარმოქმნილ ჟურნალის შეტყობინებებს. წითელი შეტყობინებები შეცდომებს აღნიშნავს, ყვითელი კი გაფრთხილებებს.
  • ქსელის ჩანართი – აჩვენებს ყველა მოთხოვნას, რომელსაც თქვენი აპლიკაცია გარე სერვისებს უგზავნის (მაგალითად, Groq API). ავლენს სტატუსის კოდებს და რეაგირების მონაცემებს.
  • ელემენტების ჩანართი – აჩვენებს თქვენი გვერდის HTML სტრუქტურას და CSS სტილებს. სასარგებლოა განლაგებისა და ვიზუალური პრობლემების დიაგნოსტიკისთვის.

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

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

აქტივობა 2

„მასწავლე“ გამართვის ნიმუში

სავარაუდო დრო: 30 წუთი

  1. გახსენით თქვენი კოდური სივრცე აქტივობა 1-დან. 
  2. იპოვეთ issue_tracker.md ფაილი, სადაც ჩამოთვლილია თქვენი P0 და P1 პრობლემები და გახსენით იგი.
  3. დაიწყეთ თქვენი ყველაზე გავრცელებული P0 პრობლემით, რომელიც კატეგორიზებულია, როგორც შეცდომა. თუ არ გაქვთ P0, დაიწყეთ თქვენი ყველაზე გავრცელებული P1 პრობლემით, მაგრამ ეს უნდა იყოს ისეთი რამ, რაც იდენტიფიცირებულია, როგორც შეცდომა ან შეცდომა.
    1. აპლიკაციის გასაშვებად ტერმინალის ფანჯარაში აკრიფეთ npm run dev (თუ აპლიკაცია React/JS-ია).
    2. თუ შეცდომა/პრობლემა დაკავშირებულია რომელიმე ბექენდ პრობლემასთან, მაგალითად, API გამოძახებასთან, ასევე ჩართეთ თქვენი ბექენდ სერვერი. ტერმინალის სხვა ფანჯარაში, სერვერის საქაღალდიდან აკრიფეთ npm run dev .
    3. შეეცადეთ პრობლემის რეპროდუცირება ზუსტად იმის გაკეთებით, რაც ტესტერმა ან თქვენს შენიშვნებში თქვა, რამაც პრობლემა გამოიწვია. 
    4. ზუსტად დაწერე რა ხდება:
      • გვერდი ცარიელი რჩება?
      • ღილაკი არაფერს აკეთებს?
      • შეცდომის შეტყობინება ჩნდება?
    5. თუ შეცდომის შეტყობინებას თავად აპლიკაციაში ან ტერმინალის ფანჯარაში (აპლიკაციის ან სერვერის) ხედავთ, დააკოპირეთ ზუსტი ტექსტი. ეს დეტალი შემდეგ ნაბიჯებს გაცილებით პროდუქტიულს ხდის.
  1. აპლიკაციის ბრაუზერის ფანჯარაში გახსენით DevTools (F12 ან მარჯვენა ღილაკით დააწკაპუნეთ -> Inspect).
  2. ნებისმიერი პრობლემის შემთხვევაში, დაიწყეთ კონსოლიდან:
    1. დააწკაპუნეთ კონსოლის ჩანართზე.
    2. ძველი შეტყობინებების წასაშლელად აკრიფეთ „clear“ .
    3. შეცდომის რეპროდუცირება.
    4. დააკოპირეთ ნებისმიერი წითელი შეცდომის შეტყობინება.
  3. თუ ეს ხელოვნურ ინტელექტს ან მონაცემებს ეხება, შეამოწმეთ ქსელი:
    1. დააჭირეთ ქსელის ჩანართს.
    2. შეცდომის რეპროდუცირება.
    3. იპოვეთ თქვენი API მოთხოვნა (მოძებნეთ თქვენი API-ს დომენი).
    4. შეამოწმეთ სტატუსის კოდი და პასუხი.
  4. თუ ეს ხელოვნურ ინტელექტს ან მონაცემებს ეხება და აპლიკაციის ფანჯრის დეველოპერულ ინსტრუმენტებში ვერაფერს ხედავთ:
    1. გახსენით DevTools ბრაუზერის ფანჯარაში, სადაც გაშვებულია თქვენი ბექენდ სერვერი.
    2. დააწკაპუნეთ კონსოლის ჩანართზე.
    3. ძველი შეტყობინებების წასაშლელად აკრიფეთ „clear“ .
    4. შეცდომის რეპროდუცირება.
    5. დააკოპირეთ ნებისმიერი წითელი შეცდომის შეტყობინება.

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

  1. გახსენით თქვენი პრობლემების თვალთვალი.
  2. იმ პრობლემის ქვეშ, რომელსაც ამჟამად ხელახლა ქმნით, მოძებნეთ ამ პრობლემის შესაძლო ძირითადი მიზეზი.
  3. შეგიძლიათ ჩამოთვლილი შესაძლო ძირეული მიზეზი დააკოპიროთ ან საკუთარი ჰიპოთეზა ჩაწეროთ, მაგრამ რაღაც მაინც.
    „ვფიქრობ, ეს იმიტომ ხდება, რომ _______________“

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

სთხოვეთ Copilot-ს ან სხვა სამართლის მაგისტრს დახმარება შეცდომების გამართვაში. შეგიძლიათ გამოიყენოთ ეს შაბლონი და შეცვალოთ იგი თქვენი კონკრეტული პრობლემებით:

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

პრობლემა: [დააკოპირეთ და ჩასვით პრობლემა, მათ შორის შეჯამება, კატეგორია, შესაძლო ძირითადი მიზეზები, სად უნდა ვეძებოთ პირველ რიგში და შემოთავაზებული გამოსწორების მიდგომა]. LLM-ისთვის რაც შეიძლება მეტი კონტექსტის მიცემა დაგეხმარებათ მის რეაგირებაში.

ჩემი ჰიპოთეზა: [თქვენი აზრით, რა იწვევს ამას]

მოსალოდნელი შედეგები: [რაც მე ვფიქრობ, რომ უნდა მოხდეს]

  1. ნებისმიერი შესწორების გამოყენებამდე წაიკითხეთ Copilot-ის რეკომენდაცია.
    ეს არის მთავარი ნაბიჯი.     როდესაც Copilot გიპასუხებთ, ჯერ ახსნა წაიკითხეთ. დარწმუნდით, რომ გესმით და შეგიძლიათ ამ კითხვებზე პასუხის გაცემა:
    • რა არის ძირეული მიზეზი?
    • რატომ აგვარებს შემოთავაზებული შესწორებები მიზეზს?
    • შეიძლება თუ არა იგივე ტიპის პრობლემა სხვაგანაც გამოჩნდეს ჩემს აპლიკაციაში?
  2. თუ ახსნა-განმარტებაში რამე გაუგებარია, დასვით დამატებითი კითხვები, მაგალითად, „შეგიძლიათ ახსნათ, რას ნიშნავს ეს ამ კონტექსტში“?

როგორც კი პრობლემას გაიგებთ და გამოსწორების გეგმას დაეთანხმებით, შეგიძლიათ გამოიყენოთ გამოსწორებები. შეგიძლიათ:

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

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

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

პრობლემა კვლავ იჩენს თავს? 

თუ ასეა, გაიმეორეთ ნაბიჯები და გაიმეორეთ.

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

  1. დასრულების შემდეგ, დარწმუნდით, რომ დოკუმენტირებული გაქვთ issue-tracker.md . შეგიძლიათ დაამატოთ ეს დოკუმენტაცია თქვენს მიერ მოგვარებული პრობლემის ქვეშ.

მაგალითად::

    • საკითხი 1: [პრობლემის აღწერა]
    • ძირითადი მიზეზი: [რა იყო სინამდვილეში არასწორი]
    • რა შევცვალე კოდში [შესწორების მოკლე აღწერა]
    • შემოწმებულია: [დიახ/არა — გადაჭრა თუ არა პრობლემა შესწორებამ?]
    • თარიღი: [დღეს]
    1. გადაიტანეთ ეს შესწორება GitHub-ში სწორი commit აღწერით, როგორიცაა:

„გამოსწორება: [მოკლე აღწერა იმისა, თუ რა გამოასწორეთ]“

კარგი commit შეტყობინებები აღწერს გამოსწორებას და არა შეცდომას:

კარგი მაგალითები:

        • გამოსწორება: ცარიელი API პასუხის დამუშავება შედეგების ჩვენებაში
        •  გამოსწორება: დაამატეთ ჩატვირთვის მდგომარეობა ორმაგი გაგზავნის თავიდან ასაცილებლად

ცუდი მაგალითები:

      • გამოსწორდა შეცდომა
      • კოდის განახლება

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

ჰიპოთეზა → „მასწავლე“ → გაგება → გამოსწორება → ტესტირება → დადასტურება

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

UI vs API პრობლემების გამართვა DevTools-ის გამოყენებით

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

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

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

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

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

გახსენით GitHub-ის კოდური სივრცე და დეველოპერული ინსტრუმენტები
  1. გადადით GitHub-ზე და გადადით თქვენს MVP საცავში.
  2. გახსენით ახალი ფილიალი (ან გამოიყენეთ არსებული dev ფილიალი). გახსენით ნებისმიერი არსებული კოდური სივრცე და დარწმუნდით, რომ სწორ ფილიალზე გადახვალთ.
  3. გაუშვით თქვენი აპლიკაცია Codespaces-დან.
  4. ბრაუზერის ჩანართში, დააწკაპუნეთ მაუსის მარჯვენა ღილაკით გვერდზე ნებისმიერ ადგილას და აირჩიეთ „შემოწმება“ (ან დააჭირეთ F12) დეველოპერის ხელსაწყოების პანელის გასახსნელად.

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

რას ხედავთ

ტიპი

სად უნდა ვეძებოთ DevTools პანელში

ელემენტი აკლია, არასწორად არის გასწორებული ან გადაფარავს ერთმანეთს

ინტერფეისის პრობლემა

ელემენტების ჩანართი

ღილაკი არაფერს აკეთებს ან არასწორი მონაცემები ჩნდება

ლოგიკური პრობლემა

კონსოლის ჩანართი

ხელოვნური ინტელექტის ფუნქცია არ აბრუნებს პასუხს ან შეცდომებს

API-ის პრობლემა

ქსელის ჩანართი

გვერდის განლაგება შესწორების შემდეგ გაუმართავად გამოიყურება

ინტერფეისის პრობლემა

ელემენტების ჩანართი

„განუსაზღვრელი თვისების წაკითხვა შეუძლებელია“

ლოგიკური პრობლემა

კონსოლის ჩანართი

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

  1.  დააწკაპუნეთ DevTools-ში ელემენტების ჩანართზე
  2. გამოიყენეთ ელემენტის შერჩევის ინსტრუმენტი (კურსორის ხატულა DevTools-ის ზედა მარცხენა კუთხეში ან დააჭირეთ Ctrl+Shift+C / Cmd+Shift+C). 
  3. HTML ელემენტის მოსანიშნად და მისი CSS სტილების საჩვენებლად, გადაიტანეთ მაუსი თქვენს გვერდზე პრობლემურ არეალზე.

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

  1. დააწკაპუნეთ კონსოლის ჩანართზე. 
  2. ძველი შეტყობინებების წაშლა შესაძლებელია „წაშლის“ ღილაკზე დაწკაპუნებით, რათა თავიდან დაიწყოთ.
  3. ახლა გაიმეორეთ შეცდომა აპლიკაციაში და დაიწყეთ ახალი შეტყობინებების ნახვა.
  4. დააკვირდით ახალ შეტყობინებებს: მაგალითად:
    • წითელი შეტყობინებები არის შეცდომები, რომლებიც ხშირად მოიცავს ფაილის სახელს, ხაზის ნომერს და აღწერას.
    • ყვითელი შეტყობინებები გაფრთხილებებია. ეს გასათვალისწინებელია, თუმცა ყოველთვის პრობლემებს არ იწვევს. 
  5. თუ შეცდომის შეტყობინება გამოჩნდება, დააკოპირეთ იგი.
  6. თუ კონსოლში შეცდომა არ გამოჩნდება, გადადით ქსელის ჩანართზე. 
  7. არსებული ჩანაწერების გასუფთავება და შეცდომის ხელახლა რეპროდუცირება (გაითვალისწინეთ, რომ ქსელის ჩანართი მხოლოდ გახსნის დროს გაკეთებულ მოთხოვნებს იწერს).
  8. მოძებნეთ თქვენი API გამოძახება. ის, როგორც წესი, ნაჩვენებია, როგორც პოსტი:
    • მოძებნეთ analyze ან /api/analyze
  9. თუ მოთხოვნა ვერ შესრულდება, სტატუსი წითლად გამოჩნდება.
  10. მაშინაც კი, თუ სტატუსი მწვანეა (200), დააწკაპუნეთ მოთხოვნისა და პასუხის ველებზე მარჯვენა კუთხეში და შეამოწმეთ ეს დეტალები ქვემოთ.
  11. დააკოპირეთ სტატუსის კოდი, მოთხოვნისა და პასუხის ტექსტი და ნებისმიერი შეცდომის შეტყობინება. ეს თქვენი მტკიცებულებაა.

რა უნდა შემოწმდეს

სად ვიპოვოთ ის

რას ნიშნავს ეს

სტატუსის კოდი

სტატუსის სვეტი ან სათაურების ჩანართი

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

მოთხოვნა

დააჭირეთ მოთხოვნის ჩანართს (მარჯვნივ)

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

პასუხი

დააჭირეთ პასუხის ჩანართს (მარჯვნივ)

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

აქ მოცემულია რამდენიმე საერთო სტატუსის კოდი:

სტატუსის კოდი

მნიშვნელობა

საერთო მიზეზი

200

წარმატება

ყველაფერი მუშაობდა (თუ შედეგები კვლავ არასწორია, შეამოწმეთ, რა გაგზავნეთ და რა პასუხი მიიღეთ)

400

არასწორი მოთხოვნა

თქვენი API გასაღები დაკარგულია, ვადაგასულია ან არასწორია

401

არაავტორიზებული

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

403

აკრძალული

თქვენს API გასაღებს არ აქვს ამ მოქმედების ნებართვა

429

ძალიან ბევრი მოთხოვნა

თქვენ მიაღწიეთ ლიმიტს - დაელოდეთ ერთი წუთით და სცადეთ ხელახლა

500

სერვერის შეცდომა

API სერვისს პრობლემა აქვს თავის მხრივ — სცადეთ მოგვიანებით

  1. DevTools-ის დასკვნების Copilot-ში გადასატანად, დაბრუნდით Codespaces-ში. ეს მტკიცებულება თქვენს გამართვის მოთხოვნებს ბევრად უფრო სპეციფიკურს ხდის.
  2. შეიყვანეთ თქვენი მტკიცებულებები ამ შაბლონის გამოყენებით:

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

**პრობლემა:** [რა მოხდა, როდესაც მომხმარებელმა ფუნქცია გაააქტიურა] 

**DevTools-ის მტკიცებულება:** 

– კონსოლის შეცდომა: [ჩასმის შეცდომის შეტყობინება, ან „კონსოლის შეცდომა არ არის“] 

– ქსელის სტატუსის კოდი: [მაგ., 401] 

– მოთხოვნა: [ასეთის არსებობის შემთხვევაში, ჩასვით თქვენი აპლიკაციის მიერ გამოგზავნილი ინფორმაცია]

– პასუხი: [API-დან შეცდომის ან შინაარსის პასუხის ჩასმა] 

 

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

მას შემდეგ, რაც Copilot აგიხსნით პრობლემას და თქვენც გაიგებთ მას, გამოიყენეთ გამოსწორება თქვენს Codespace-ში. შემდეგ დაადასტურეთ აპლიკაციის გაშვებით და პრობლემის გამომწვევი ნაბიჯების ხელახლა შექმნით. თქვენ უნდა შეძლოთ დადასტურება თავად აპლიკაციაში, მაგრამ ასევე შეგიძლიათ დაადასტუროთ DevTools-ის გამოყენებით:

  • API-ის შესწორებებისთვის: გახსენით ბექენდის ქსელის ჩანართი, გაააქტიურეთ იგივე მოქმედება, რომელიც ადრე ვერ მოხერხდა. შეამოწმეთ:
    • მოთხოვნა ახლა 200-ს აბრუნებს (წარმატება)? 
    • აჩვენებს თუ არა „პასუხის“ ჩანართი მოსალოდნელ მონაცემებს?
  • ინტერფეისის პრობლემების მოსაგვარებლად: გამოიყენეთ ელემენტების ჩანართი (frontend) იმის დასადასტურებლად, რომ ელემენტი ახლა ხილულია და სწორად არის სტილიზებული.
  • ლოგიკური შეცდომების გამოსასწორებლად: შეამოწმეთ კონსოლი (წინა მხარე) მოქმედების გააქტიურებისას ახალი წითელი შეცდომების არარსებობაზე.

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

ვერიფიკაცია და დოკუმენტირების ტესტირება

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

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

აქტივობა 3

შეამოწმეთ, დაადასტურეთ და დოკუმენტირეთ თქვენი შესწორებები

სავარაუდო დრო: 25 წუთი

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

  1. გადადით GitHub-ზე და გადადით თქვენს MVP საცავში.
  2. გადადით თქვენს dev ფილიალში (ან შექმენით ახალი ფილიალი) და გახსენით ნებისმიერი არსებული კოდის სივრცე არსებული აქტივობიდან.
  3. გახსენით თქვენი კოდური სივრცე.
  4. დარწმუნდით, რომ გადახვალთ dev ფილიალზე. 
  5. შექმენით ფაილი სახელწოდებით test-checklist.md თქვენს Codespace-ის ტესტის საქაღალდეში.
  6. ამ შაბლონის გამოყენებით, Copilot-ს თქვენი მტკიცებულებები მოსთხოვეთ:

დაამატეთ კონტენტი test_checklist.md ფაილს [თქვენი აპლიკაციის სახელი]-ის სატესტო საქაღალდეში შემდეგი სტრუქტურით:

– სათაური აპლიკაციის სახელით, ბოლო ტესტირების თარიღით და ტესტერის სახელის ჩანაცვლებით

– ძირითადი ფუნქციონალურობის განყოფილება, რომელიც მოიცავს შემდეგ ძირითად მახასიათებლებს: [ჩამოთვალეთ თქვენი 2-3 ძირითადი მახასიათებელი]

– Edge Cases-ის განყოფილება გავრცელებული სცენარებით: ცარიელი შეყვანა, გრძელი შეყვანა (100+ სიტყვა), სწრაფი დაწკაპუნებები, მობილური ხედვის ფანჯრის ტესტირება

– ბოლო შეცდომების გამოსწორების განყოფილება

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

ტესტის შემთხვევები უნდა იყოს კონკრეტული და ქმედითი – სხვას უნდა შეეძლოს მათი გაშვება კითხვების დასმის გარეშე.

გადახედეთ შედგენილ საკონტროლო სიას და ჰკითხეთ საკუთარ თავს:

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

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

სისტემატურად იმუშავეთ თითოეულ რიგზე:

  1. ზუსტად შეასრულეთ ჩამოთვლილი ნაბიჯები.
  2. შეადარეთ რა მოხდება მოსალოდნელ შედეგთან.
  3. მონიშნეთ „გაიარეთ ან ვერ მოხვდით“.
  4. თუ რამე ვერ მოხერხდა, აღნიშნეთ, რა შეცდომა დაუშვით.

რჩევები საფუძვლიანი ტესტირებისთვის:

  • ქეშირებული მონაცემების თავიდან ასაცილებლად, შეამოწმეთ ახალ ინკოგნიტო/პირად ბრაუზერის ფანჯარაში.
  • ჯერ გამოსცადეთ ბედნიერი გზა (ყველაფერი მოსალოდნელი შედეგით მუშაობს).
  • შემდეგ შეამოწმეთ კიდის შემთხვევები (ცარიელი შეყვანა, ძალიან გრძელი შეყვანა, სწრაფი დაწკაპუნებები).
  • მობილური ხედვის არეალში ტესტირება (DevTools → მოწყობილობის რეჟიმი, ან თქვენს ტელეფონზე ტესტირება)

თუ ტესტი წარუმატებელია:

  • ეს რეგრესიის პრობლემაა - ეს ნიშნავს, რომ გამოსწორებამ სხვა რამ დააზიანა.
  • დაუბრუნდით მე-2 აქტივობას და გამოიყენეთ „მასწავლე“ ნიმუში.
  • ზოგჯერ პირველი გამოსავალი სიმპტომს აგვარებს და არა ძირეულ მიზეზს.
  1. ყველა ტესტის გაშვებისა და შედეგების შევსების შემდეგ, დააყენეთ ცვლილებები თქვენს ფილიალში (stage) და დააკომენტეთ (commit).
  2. გადადით Github-ზე და გააერთიანეთ თქვენი ფილიალი მთავარ ფილიალთან.

ანარეკლი

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

Sunset and reflection over lake
01

გამართვის პროცესი
თქვენ მიჰყევით პროცესს, კატეგორიზაცია → ჰიპოთეზა → დიაგნოსტიკა → გამოსწორება → შემოწმება → დადასტურება. რომელი ნაბიჯი იყო თქვენთვის ყველაზე ღირებული? რომელი მოგეჩვენათ არასაჭიროდ?
02

"მასწავლე"
როდესაც თქვენ სთხოვეთ ხელოვნურ ინტელექტს ახსნა-განმარტების მიცემა პრობლემის გამოსწორებამდე, შეცვალა თუ არა ახსნამ თქვენი მიდგომა პრობლემის გამოსწორებისადმი? იყო თუ არა მომენტი, როდესაც ახსნამ გაგაოცათ?
03

DevTools-ის აღმოჩენა
რა ისწავლეთ Console, Network ან Elements ჩანართებიდან, რასაც თავად აპლიკაციაში ვერ ხედავთ? როგორ შეიძლება ამან შეცვალოს შეცდომების გამოსწორების პროცესი მომავალში?
04

მტკიცებულებებზე დაფუძნებული გამართვა
როგორ შეცვალა Copilot-ისთვის კონკრეტული შეცდომის შეტყობინებებისა და სტატუსის კოდების მიწოდებამ მისი შემოთავაზებების ხარისხი ბუნდოვან „გაფუჭებულია“ შეტყობინებასთან შედარებით?
05

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

ძირითადი ტერმინები

  • შეცდომა: თქვენი აპლიკაციის დეფექტი, რომლის დროსაც ის არ მუშაობს ისე, როგორც მოსალოდნელი იყო. შეცდომები, არასწორი შედეგები და დამაბნეველი ქცევა შეცდომების ერთ-ერთი სახეობაა.
  • P0 / P1 / P2 / P3: პრობლემების პრიორიტეტულობის დონეები. P0 არის კრიტიკული (ბლოკავს მომხმარებლებს), P1 არის მნიშვნელოვანი (მტკივნეული, მაგრამ ეფექტური), P2 არის უმნიშვნელო (დაბალი სიხშირით), P3 არის კოსმეტიკური (გაპრიალება).
  • MoSCoW მეთოდი: პრიორიტეტიზაციის ჩარჩო, რომელიც მოცემული იტერაციისთვის ელემენტებს აჯგუფებს Must (საჭირო), Should (შესაძლო), Could (შეუძლია) და Won't (არ უნდა) კატეგორიებად.
  • ძირითადი მიზეზი: შეცდომის წარმოქმნის ძირითადი მიზეზი — არა მხოლოდ ის, რასაც მომხმარებელი ხედავს, არამედ ის, თუ რატომ ხდება ეს კოდში. ძირითადი მიზეზების გამოსწორება ხელს უშლის მისი განმეორებას.
  • „მასწავლე“-ს ნიმუში: გამართვის მიდგომა, სადაც თქვენ სთხოვთ ხელოვნურ ინტელექტს, აგიხსნათ პრობლემა, სანამ გამოსწორების საშუალებას მოგვცემთ. კოპირება-ჩასმის გადაწყვეტილებების ნაცვლად, ეს ხელს უწყობს გაგებას.
  • DevTools: ბრაუზერის შემქმნელის ინსტრუმენტები (F12 ან მარჯვენა ღილაკით დააწკაპუნეთ → შემოწმება). მოიცავს შეცდომების კონსოლს, API გამოძახებების ქსელს და განლაგების შემოწმების ელემენტებს.
  • კონსოლის ჩანართი: აჩვენებს JavaScript-ის შეცდომებს, გაფრთხილებებს და ჟურნალის შეტყობინებებს. წითელი ჩანაწერები არის შეცდომები, რომელთა ფაილების სახელები და ხაზის ნომრები მიუთითებს პრობლემაზე.
  • ქსელის ჩანართი: აჩვენებს თქვენი აპლიკაციის მიერ განხორციელებულ ყველა HTTP მოთხოვნას, მათ შორის API გამოძახებებს. ავლენს სტატუსის კოდებს, მოთხოვნის დეტალებს და პასუხის მონაცემებს.
  • ელემენტების ჩანართი: აჩვენებს თქვენი გვერდის HTML სტრუქტურას და CSS სტილებს. სასარგებლოა განლაგებისა და ვიზუალური პრობლემების დიაგნოსტიკისთვის.
  • სტატუსის კოდი: სერვერის მიერ დაბრუნებული რიცხვი, რომელიც მიუთითებს წარმატებაზე (200), კლიენტის შეცდომაზე (400-499) ან სერვერის შეცდომაზე (500-599).
  • პრობლემების თვალთვალი: დოკუმენტი, რომელიც აღრიცხავს შეცდომებს, მათ პრიორიტეტს, ძირეულ მიზეზებსა და გამოსწორებებს. ორგანიზებულად ინახავს გამართვას და იძლევა ცვლილებების ისტორიას.
  • რეგრესია: როდესაც ერთი პრობლემის გამოსწორება შემთხვევით აფუჭებს სხვა ფუნქციას, რომელიც ადრე მუშაობდა. ტესტირების საკონტროლო სიები ხელს უწყობს რეგრესიების აღმოჩენას.

დამატებითი რესურსები

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