ამ პოსტში მინდა შევეხო ისეთ საკითხს როგორიც არის გასაუბრებაზე ხშირად დასმული რუტინული კითხვები დამწყებთათვის და საორიენტაციო პასუხები.
ჩამოთვლილი კითხვები ხშირად ტრიალებს ხოლმე (ძირითადად არაქართულ ბაზარზე და შეიძლება ქართულზეც), მაგრამ ეს არ ნიშნავს იმას რომ აუცილებლად ეს კითხვები შეგხვდებათ, მაგრამ ხშირად შაბლონურად იყენებენ ამ კითხვებს ასე რომ გქონდეთ მაინც წარმოდგენა და რაც მთავარია გახსოვდეთ ეს ინფორმაცია შესაძლებელია არ იყოს 100% სწორი პასუხები ვინაიდან და რადგან უშეცდომო არავინაა 🙂 პ.ს.
წარმატებას გისურვებთ 🙂
დავიწყოთ API ტესტირების საკითხებით
რა განსხვავებაა PUT და POST მეთოდებს შორის?
–POST მოთხოვნის დროს სერვერზე ხდება ახალი ობიექტის შექმნა.
–PUT მოთხოვნის დროს ხდება სერვერზე არსებული ობიექტის მნიშვნელობის განახლება
ძირითადად რა მეთოდები გამოიყენება HTTP მოთხოვნის დროს?
–GET: – რომელიც იძლევა საშუალებას სერვერიდან მივიღოთ ინფორმაცია სერვერიდან
–POST: – გვაძლევს საშუალებას დავამატოთ მონაცემები სერვერზე არსებულ ფაილზე/რესურსზე
–PUT: – გვაძლევს საშუალებას შევცვალოთ მონაცემები სერვერზე არსებულ ფაილზე/რესურსზე
–DELETE: – გვაძლევს საშუალებას წავშალოთ მონაცემები სერვერიდან
ავტორიზაციის ტიპები რომელიც გამოიყენება API-თან მუშაობის დროს?
Basic Authentication
Digest Authentication
OAuth
რა არის API?
აპლიკაციის პროგრამირების ინტერფეისი (ინგ : Application Programming Interface) არის სერვერთან მომხმარებლის დაკავშირების ერთ-ერთი ინტერფეისი, პროტოკოლი, კლასების, ფუნქციების, პროცედურების მზა კომპლექტი, რომელიც ამარტივებს პროგრამული პროდუქტის შექმნას და ასევე სხვადასხვა პროგრამული უზრუნველყოფების ურთიერთკავშირსაც. მომხმარებელი აგზავნის მოთხოვნას წინასწარგანსაზღვრული ფორმატით და სერვერიდან ღებულობს პასუხს ასევე კონკრეტული ფორმატით.
რა არის REST API?
ინგ : Representational State Transfer, ანუ წარმოდგენის, პრეზენტაციის მდგომარეობის ტრანსფერი. მომხმარებელმა გაგზავნა მოთხოვნა სერვერზე (მაგ: მაუსი დააჭირა ბმულს, ღილაკს, აკრიფა რომელიმე ვებ-გვერდის მისამართი ბრაუზერის სამისამართო ველში და ა.შ). სერვერმა პასუხად დააბრუნა წყარო, რესურსი, ინფორმაცია (resource). აღსანიშნავია, რომ ხშირ შემთხვევაში შეუძლებელია ამ რესურსის მომხმარებელთან იმ სახით მიტანა, რომლითაც სერვერზეა შენახული. იგი აუცილებლად ადვილად წაკითხვადი და გარჩევადი უნდა იყოს მისთვის, მაგალითად ბრაუზერში უნდა იხილოს ფოტო, ან მიიღოს ინფორმაცია მისთვის სასურველ ფორმატში (JSON, XML …). სწორედ ამიტომ საჭიროა პასუხად წამოსული ინფორმაციის დამუშავება (მაგალითად HTML-ის მიერ). პროცესს რომლის დასრულების შემდეგაც ეს რესურსი ხდება მომხმარებლისათვის ადვილად წაკითხვადი და ასევე ფორმატდება მისთვის სასურველ ფორმატში, ეწოდება რეპრეზენტაცია.
კონკრეტულად რა უნდა შემოწმდეს API ტესტირებაში?
- ვამოწმებთ მონაცემების სიზუსტეს
- http სტატუს კოდს
- პასუხის დაბრუნების დროს (response time)
- შეცდომის კოდები (თუ აბრუნებს API შეცდომის კოდებს მხოლოდ ამ შემთხვევაში)
- ავტორიზაცია
- არაფუნქციური ტესტირება (პერფორმანსის ტესტირება, უსაფრთხოების ტესტირება)
რა არის HTTP მოთხოვნის ძირითადი კომპონენტები?
1. HTTP მოთხოვნის მეთოდები, როგორიცაა:, PUT, POST, DELETE.
2. Uniform Resource Identifier (URI)
3. რესურსები და პარამეტრები
4. ეგრედწოდებული ჰიდერები (პარამეტრები და მათი მნიშვნელობები)
5. ეგრედწოდებული ბადი (Request Body), რომელიც მიუთითებს შეტყობინების შინაარსს.
რა განსხვავებაა API ტესტირებასა და UI ტესტირებას შორის?
UI (მომხმარებლის ინტერფეისის) ტესტირება ნიშნავს მომხმარებლის გრაფიკული ინტერფეისის ტესტირებას. UI ტესტირების აქცენტი კეთდება აპლიკაციის ვიზუალზე და ვიზუალით განსაზღვრულ ქმედებებზე. მომხმარებლის ინტერფეისის ტესტირებისას მთავარი აქცენტი კეთდება იმაზე, თუ როგორ შეუძლიათ მომხმარებლებს ურთიერთქმედება აპის ელემენტებთან, როგორიცაა სურათები, შრიფტები, განლაგება და ა.შ.
API ტესტირება საშუალებას აძლევს კომუნიკაციას ორ პროგრამულ სისტემას შორის. API ტესტირება მუშაობს backend-ზე, რომელიც ასევე ცნობილია როგორც “backend ტესტირება”.
რა პროტოკოლს იყენებს RESTFUL ვებ სერვისები?
RESTFUL ვებ სერვისები იყენებს HTTP პროტოკოლს. ისინი იყენებენ HTTP პროტოკოლს, როგორც კლიენტსა და სერვერს შორის კომუნიკაციის საშუალებას.
რა არის Soap WebServices?
SOAP ნიშნავს მარტივ ობიექტზე წვდომის პროტოკოლს. ეს არის XML დაფუძნებული შეტყობინებების პროტოკოლი. ის ეხმარება კომპიუტერებს შორის ინფორმაციის გაცვლას.
შეგიძლიათ გამოიყენოთ GET მოთხოვნა PUT-ის ნაცვლად რესურსის შესაქმნელად?
არა, GET მოთხოვნა მხოლოდ წაკითხვის უფლებას იძლევა. ეს გაძლევთ საშუალებას მიიღოთ მონაცემები სერვერიდან, მაგრამ არ შექმნათ რესურსი. რესურსის შესაქმნელად გამოყენებული უნდა იყოს PUT ან POST მეთოდები.
შეგიძლიათ გამოიყენოთ POST მოთხოვნა PUT-ის ნაცვლად რესურსის შესაქმნელად?
დიახ, რადგან POST არის “მაგარი ტიპი” ფაქტიურად ყველაფერი შეუძლია (შესაძლებელია შეგხვდეს ისეთი ქეისები რაც არ არის POST ის საქმე მაგრამ მაინც POST იქნას გამოყენებული).
ფუნქციური ტესტირება:
1) რა არის და რას წარმოადგენს ტესტირების დაგეგმარება, გეგმა (Test Plan):
ტესტირების გეგმა (Test Plan) არის დოკუმენტი, რომელიც გვთავაზობს საიტის, აპლიკაციის ან სხვა პროგრამული პროდუქტის ტესტირების გეგმას, ეს დოკუმენტი აღწერს ტესტირების სტრატეგიას, ტესტების განსაზღვრას, ტესტირების განვითარებას და სხვა ტესტირების კომპონენტებს. რომელ მეთოდოლოგიას ან პროცესს ვიყენებთ ტესტირებისთვის, როგორ დაგვეხმარება ტესტირება, როგორ განსაზღვროთ სწორი ტესტების კრიტერიუმები.
2) განმარტეთ ბაგის სასიცოცხლო ციკლი:
ბაგის სასიცოცხლო ციკლი იწყება ბაგის აღმოჩენით და სრულდება მისი გამოსწორებული ვერსიის გადამოწმებით. საერთო ჯამში კი მოიცავს შემდეგ ეტაპებს:
აღმოჩენა
დახარისხება(მისი მნიშვნელობის და პრიორიტეტის განსაზღვრება),
დარეპორტება
შესაბამის პირზე (გუნდზე) პასუხისმგებლობის გადაბარება
ბაგის (ხარვეზის აღმოფხვრა შესაბამისი პირის ან ჯგუფის მიერ)
ახლიდან გადამოწმება
3) რა სხვაობა ვალიდაციას და ვერიფიკაციის შორის?
ვალიდაცია უზრუნველყოფს, რომ პროდუქტი ეთანადებოდეს მომხმარებლის მოთხოვნებს. ვერიფიკაცია კი უზრონველყოფს, რომ პროდუქტი შეიქმნას მოთხოვნების შესაბამისად.
ვალიდაცია და ვერიფიკაცია
4) რა არის ADHOC ტიპის ტესტირება
ადჰოკ ტესტირება არის ინფორმალური ტესტირების ტიპი, რომელიც ტარდება ტესტ ქეისების და დაგეგმარების გარეშე. გამოიყენება მაშინ როდესაც გვაქვს შეზღუდული დრო ან რესურსები ფორმალური ტესტირებისთვის.
5) თუ მოცემულია ტესტ ქეისების შემდეგი პრიორიტეტებით (-2, 1, 5, 3) რა თანმიმდევრობით უნდა მოხდეს ტესტ ქეისების გაშვება/შესრულება
თანმიმდევრობა იქნება შემდეგი: -2, 1, 3, 5
6) ეჯაილ გუნდში ვინ უნდა მიიღოს გადაწყვეტილება რომელი საკითხები (ქეისები) უნდა იყოს დაავტომატიზირებული და რის მიხედვით უნდა განისაზღვროს ის.
1) ტესტერები, რომლებიც პასუხისმგებელნი არიან ტესტ ქეისების დიზაინსა და შესრულებაზე, მნიშვნელოვან როლს ასრულებენ იმის განსაზღვრაში, თუ რომელი ტესტის შემთხვევები უნდა იყოს ავტომატიზირებული. ისინი ფლობენ აპლიკაციისა და მისი ფუნქციონალურობის ცოდნას, რაც მათ საშუალებას აძლევს მიიღონ გადაწყვეტილება დასაავტომატირიზირებელ ქეისების იდენტიფიცირებაში.
2) ტესტირების ავტომატიზაციის ინჟინრები: ტესტის ავტომატიზაციის ინჟინრები არიან გუნდის წევრები, რომლებიც ახდენენ ტესტ ქეისების დაავტომატიზირებას შესაბამისი ხელსაწყოების და სკრიპტების გამოყენებით. ისინი ხელს უწყობენ თავიანთი ტექნიკურ ცოდნით კონკრეტული ქეისების შემთხვევების ავტომატიზაციის მიზანშეწონილობისა და სირთულის შესაფასებლად.
3) პროდუქტის მფლობელი: პროდუქტის მფლობელი, რომელიც წარმოადგენს მომხმარებელს ან დაინტერესებულ მხარეს, უზრუნველყოფს ღირებულ ინფორმაციას გადაწყვეტილების მიღების პროცესში. ისინი უპირატესობას ანიჭებენ ისეთ ფუნქციების ტესტირებას, რომლებიც დაფუძნებულია ბიზნეს ღირებულებაზე, რამაც შეიძლება გავლენა მოახდინოს დასაავტომატიზირებული ტესტ ქეისების პრიორიტეტებზე.
4) სქრამი: დეველოპერების და სხვა ტექნიკური წევრების ჩათვლით, თანამშრომლობს ტესტერებთან და ავტომატიზაციის ინჟინრებთან აპლიკაციის ტექნიკური ასპექტების გასაგებად. ისინი აწვდიან ინფორმაციას სხვადასხვა ფუნქციების სირთულესა და სტაბილურობაზე, რაც განსაზღვრავს, თუ რომელი ტესტის შემთხვევების ავტომატიზაცია.
საბოლოო ჯამში, გადაწყვეტილების მიღება, თუ რომელი ტესტ ქეისების ავტომატიზაცია მოხდება, არის გუნდური ძალისხმევა, ისეთი ფაქტორების გათვალისწინებით, როგორიცაა ტესტის პრიორიტეტი, სირთულე, სტაბილურობა და ბიზნეს ღირებულება.
