api ტესტირებას რა უნდა – მარტივია :)

ხშირად მსმენია რომ API ტესტირებას მარტივია, რა უნდა api ტესტირებას და ათასი მსგავსი რამ 🙂
მაგალითისთვის განვიხილოთ რომ გვაქვს ერთი ენდფოინთი რომელიც აბრუნებს ძალიან მარტივ რესპონს
მაგ:
{ “name”: “John”}
სადაც შესამოწმებელია მხოლოდ name მნიშვნელობა ხო? და ვითომ ასე მარტივად არის ყველაფერი? 🙂 მითუმეტეს იმის გათვალისწინებით რომ შესაძლებელია name მნიშვნელობა ისედაც მოწმდებოდეს დეველოპერის მიერ შესაბამისი ტიპის ტესტირებების დროს და შესაბამისად აღარ იყოს საჭირო მისი შემოწმება.
ანუ რა გამოდის რომ აღარ გვიჭრდება არაფრის შემოწმება ? 🙂
ხოდა მოდი დღეს ვისაუბროთ ამ საკითხზე.
განვიხილოთ ძირითადი ქეისები თუ რა შეიძლება შემოწმდეს api ტესტირების დროს?
მოდი ჩამოვთვალოთ საკითხები რისი შესაძლებლობები არსებობს (რა თქმა უნდა ყველა სავალდებულო არ არის და დამოკიდებულია გარემოპირობებზე), აქ არის არასრული ჩამონათვალი თუ რისი შემოწმება შეიძლება მოგვიწიოს API ტესტირების დროს.
პ.ს. მინიმუმ ალბათ ერთი ამდენი ვარიანტი კიდევ არსებობს 🙂

• შევამოწმოთ, რომ API-ის პასუხის სტატუსის კოდი არის 200 OK. // ნუ შესაძლებელია 201 (დოკუმენტაციის მიხედვით)
• შევამოწმოთ, რომ API-ის პასუხი არის მოსალოდნელ ფორმატში // (მაგალითად, JSON, XML)
• შევამოწმოთ, რომ API-ის პასუხი შეიცავს ყველა მოსალოდნელ ველს. // (რაც ზემოთაც ვახსენეთ -თუ საჭიროა რა თქმა უნდა )
• შევამოწმოთ, რომ API-ის პასუხი შეიცავს სწორ მონაცემებს თითოეული ველისათვის. // ანალოგიურად
• შევამოწმოთ, რომ API-ის პასუხის დრო არის მისაღებ დროში. // მაგ: რამდენ წამში ბრუნდება პასუხი
• შევამოწმოთ, რომ API-ის მოთხოვნის პარამეტრები სწორად გადაეცემა API-ს. // ხშირად ამას ყოველთვის ვერ ვამოწმებთ.
• შევამოწმოთ, რომ API-ის მოთხოვნის მეთოდი სწორია (მაგალითად, GET, POST, PUT, DELETE).
• შევამოწმოთ, რომ API-ის ბოლო წერტილის (endpoint) URL სწორია.
• შევამოწმოთ, რომ API-ის პასუხის (response) ჰედერები სწორია.
• შევამოწმოთ, რომ API აბრუნებს შეცდომის შეტყობინებას, თუ მოთხოვნა არასწორადაა შექმნილი.
• შევამოწმოთ, რომ API აბრუნებს შეცდომის შეტყობინებას, თუ ავთენტიფიკაცია ვერ ხერხდება.
• შევამოწმოთ, რომ API აბრუნებს შეცდომის შეტყობინებას, თუ მოთხოვნილი რესურსი არ არსებობს.
• შევამოწმოთ, რომ API აბრუნებს შეცდომის შეტყობინებას, თუ მოთხოვნილი რესურსი არ არის ავტორიზებული.
• შევამოწმოთ, რომ API აბრუნებს შეცდომის შეტყობინებას, თუ მოთხოვნის მეთოდი არ არის დაშვებული რესურსისთვის.
• შევამოწმოთ, რომ API აბრუნებს შესაბამის შეტყობინებას, თუ რესურსი წარმატებით შეიქმნა.
• შევამოწმოთ, რომ API აბრუნებს შესაბამის შეტყობინებას, თუ რესურსი წარმატებით განახლდა.
• შევამოწმოთ, რომ API აბრუნებს შესაბამის შეტყობინებას, თუ რესურსი წარმატებით წაიშალა.
• შევამოწმოთ, რომ API აბრუნებს შესაბამის შეტყობინებას, თუ რესურსი წარმატებით იქნა მიღებული.
• შევამოწმოთ, რომ API აბრუნებს სწორ რესურსს მოცემული რესურსის იდენტიფიკატორის მიხედვით.
• შევამოწმოთ, რომ API აბრუნებს სწორ რესურსს მოცემული ძებნის პარამეტრების მიხედვით.
• შევამოწმოთ, რომ API-ის პასუხი შეიცავს სწორ  ინფორმაციას (გვერდების შესახებ) თუ ინფორმაცია გადანაწილებულია რამდენიმე გვერდზე.
• შევამოწმოთ, რომ API-ის პასუხში მოცემული ინფორმაცია სწორედ არის დასორტირებული სორტირების პარამეტრის მიხედვით.
• შევამოწმოთ, რომ API-ის პასუხი შეიცავს სწორ ფილტრაციის ინფორმაციას მოცემული ფილტრის პარამეტრების მიხედვით.
• შევამოწმოთ, რომ API აბრუნებს სწორ შედეგებს ნაწილობრივი სტრიქონის ძებნისას.
• შევამოწმოთ, რომ API აბრუნებს სწორ შედეგებს რეგისტრირებისადმი დამოუკიდებელი სტრიქონის ძებნისას.
• შევამოწმოთ, რომ API აბრუნებს სწორ შედეგებს სპეციალური სიმბოლოებით სტრიქონის ძებნისას.
• შევამოწმოთ, რომ API აბრუნებს სწორ შედეგებს მრავალსიტყვიანი სტრიქონის ძებნისას.
• შევამოწმოთ, რომ API აბრუნებს სწორ შედეგებს ასოების და რიცხვების კომბინაციით სტრიქონის ძებნისას.
• შევამოწმოთ, რომ API აბრუნებს სწორ შედეგებს ცარიელი ადგილებით სტრიქონის ძებნისას.
• შევამოწმოთ, რომ API აბრუნებს სწორ შედეგებს შერეული სიმბოლოების ტიპებით სტრიქონის ძებნისას (მაგალითად, ასოები, რიცხვები, სიმბოლოები).
• შევამოწმოთ, რომ API აბრუნებს სწორ შედეგებს HTML ტეგებით სტრიქონის ძებნისას
• შევამოწმოთ, რომ API-ის პასუხი შეკუმშულია, როდესაც მომხმარებელი მოთხოვნაში აგზავნის “Accept-Encoding” ჰედერს “gzip” მნიშვნელობით.
• შევამოწმოთ, რომ API-ის პასუხი არ არის შეკუმშული, თუ მომხმარებელი არ აგზავნის “Accept-Encoding” ჰედერს.
• შევამოწმოთ, რომ API-ის პასუხი არ არის შეკუმშული, თუ მომხმარებელი აგზავნის “Accept-Encoding” ჰედერს “gzip”-ისგან განსხვავებული მნიშვნელობით.
• შევამოწმოთ, რომ API-ის პასუხი შეიცავს სწორ რესურსის წარმოდგენას მითითებული ენის მიხედვით (მაგალითად, ქართული , ესპანური, ფრანგული, ინგლისური).
• შევამოწმოთ, რომ API-ის პასუხი შეიცავს სწორ ინფორმაციას მითითებული დროის ზონის მიხედვით.
• შევამოწმოთ, რომ API-ის პასუხი შეიცავს სწორ რესურს, როდესაც რესურსი შეიცავს ჩადგმულ ობიექტებს ან მასივებს.
• შევამოწმოთ, რომ API აბრუნებს პასუხს მომხმარებლის სპეციფიური HTTP ჰედერის გაგზავნისას.
• შევამოწმოთ, რომ API სწორად უმკლავდება ფაილების ატვირთვასა და ჩამოტვირთვას.
• შევამოწმოთ, რომ API სწორად უმკლავდება სიჩქარის შეზღუდვას (როგორია ქცევა ცუდი ხარისხის ინტერნეტის დროს) და აბრუნებს სწორ HTTP სტატუს კოდს.
• შევამოწმოთ, რომ API სწორად უმკლავდება განმეორებებს და აბრუნებს სწორ HTTP სტატუს კოდს.
• შევამოწმოთ, რომ API სწორად უმკლავდება გადამისამართებებს და აბრუნებს სწორ HTTP სტატუს კოდს.
• შევამოწმოთ, რომ API სწორად უმკლავდება ქუქებს და აბრუნებს სწორ HTTP სტატუს კოდს.
• შევამოწმოთ, რომ API სწორად უმკლავდება ქეშირებას და აბრუნებს სწორ HTTP სტატუს კოდს.
• შევამოწმოთ, რომ API სწორად უმკლავდება CSRF ტოკენებს და აბრუნებს სწორ HTTP სტატუს კოდს.
• შევამოწმოთ, რომ API სწორად უმკლავდება XSS შეტევებს და აბრუნებს სწორ HTTP სტატუს კოდს.
• შევამოწმოთ, რომ API სწორად უმკლავდება SQL ინექციის შეტევებს და აბრუნებს სწორ HTTP სტატუს კოდს.
• შევამოწმოთ, რომ API სწორად უმკლავდება CSRF შეტევებს და აბრუნებს სწორ HTTP სტატუს კოდს.
• შევამოწმოთ, რომ API სწორად უმკლავდება შეყვანის ვალიდაციას და აბრუნებს სწორ HTTP სტატუს კოდს.
• შევამოწმოთ, რომ API სწორად უმკლავდება SSL/TLS სერტიფიკატებს და აბრუნებს სწორ HTTP სტატუს კოდს.
• შევამოწმოთ, რომ API სწორად უმკლავდება ავთენტიფიკაციას და ავტორიზაციას და აბრუნებს სწორ HTTP სტატუს კოდს.
• შევამოწმოთ, რომ API სწორად უმკლავდება შეცდომების პირობებს და აბრუნებს სწორ HTTP სტატუს კოდს და შეცდომის შეტყობინებას.
• შევამოწმოთ, რომ API სწორად უმკლავდება სხვადასხვა ტიპის ავტორიზაციას, როგორიცაა როლებზე ფუძნებული ავტორიზაცია.
• შევამოწმოთ, რომ API აბრუნებს სწორ HTTP სტატუს კოდს მოთხოვნებზე, რომლებიც არ არის მხარდაჭერილი (მაგალითად, HTTP 405 Method Not Allowed).
• შევამოწმოთ, რომ API აბრუნებს სწორ HTTP სტატუს კოდს არასწორი მოთხოვნებისათვის (მაგალითად, HTTP 400 Bad Request).
• შევამოწმოთ, რომ API აბრუნებს სწორ HTTP სტატუს კოდს არაუფლებამოსილი მოთხოვნებისათვის (მაგალითად, HTTP 401 Unauthorized).
• შევამოწმოთ, რომ API აბრუნებს სწორ HTTP სტატუს კოდს აკრძალული მოთხოვნებისთვის (მაგალითად, HTTP 403 Forbidden).
• შევამოწმოთ, რომ API აბრუნებს სწორ HTTP სტატუს კოდს, თუ რესურსი ვერ მოიძებნა (მაგალითად, HTTP 404 Not Found).
• შევამოწმოთ, რომ API სწორად უმკლავდება სერვერულ ვალიდაციას და აბრუნებს სწორ HTTP სტატუს კოდს და შეცდომის შეტყობინებას.
• შევამოწმოთ, რომ API სწორად უმკლავდება კლიენტურ ვალიდაციას და აბრუნებს სწორ HTTP სტატუს კოდს და შეცდომის შეტყობინებას.
• შევამოწმოთ, რომ API სწორად უმკლავდება ველის დონეზე ვალიდაციას და აბრუნებს სწორ HTTP სტატუს კოდს და შეცდომის შეტყობინებას.
• შევამოწმოთ, რომ API სწორად უმკლავდება მონაცემთა ბაზის ტრანზაქციებს და აბრუნებს სწორ HTTP სტატუს კოდს და შეცდომის შეტყობინებას.
• შევამოწმოთ, რომ API სწორად უმკლავდება მონაცემების დაშიფვრასა და დეკოდირებას.
• შევამოწმოთ, რომ API სწორად უმკლავდება მონაცემების შეკუმშვას და დეკომპრესირებას.
• შევამოწმოთ, რომ API სწორად უმკლავდება ჯვარედინი რესურსების წვდომას (CORS) და აბრუნებს სწორ HTTP სტატუს კოდს და შეცდომის შეტყობინებას.
• შევამოწმოთ, რომ API აბრუნებს სწორ პასუხის დროს სხვადასხვა ტიპის მოთხოვნებისათვის (მაგალითად, GET, POST, PUT, DELETE).