Μενού

Οδηγός δοκιμών API: Ένας πλήρης οδηγός για αρχάριους

  • Κύριος
  • Αλλα
  • Οδηγός δοκιμών API: Ένας πλήρης οδηγός για αρχάριους

api testing tutorial

Δοκιμάστε Το Όργανο Μας Για Την Εξάλειψη Των Προβλημάτων

Αυτό το σεμινάριο δοκιμών API σε βάθος εξηγεί τα πάντα σχετικά με τη δοκιμή API, τις υπηρεσίες Web και τον τρόπο εισαγωγής δοκιμών API στον οργανισμό σας:

Αποκτήστε μια βαθιά εικόνα σχετικά με τις δοκιμές API μαζί με την έννοια της δοκιμής στροφής αριστερά και των υπηρεσιών ιστού από αυτό το εισαγωγικό σεμινάριο.

Έννοιες όπως το Web API, πώς λειτουργεί το API (με παράδειγμα πραγματικού κόσμου) και πώς διαφέρει από τις Υπηρεσίες Web εξηγούνται καλά με παραδείγματα σε αυτό το σεμινάριο.

=>ΜΕΤΑΚΙΝΗΘΕΙΤΕ ΠΡΟΣ ΤΑ ΚΑΤΩγια να δείτε ολόκληρη τη λίστα των 5 Σεμινάριο δοκιμών API σε βάθος για αρχάριους

Δοκιμή API

Τι θα μάθετε:

Λίστα οδηγών δοκιμών API

Εκμάθηση # 1: Οδηγός δοκιμών API: Ένας πλήρης οδηγός για αρχάριους
Εκμάθηση # 2: Εκμάθηση Υπηρεσιών Ιστού: Στοιχεία, Αρχιτεκτονική, Τύποι & Παραδείγματα
Εκμάθηση # 3: Κορυφαίες 35 ερωτήσεις συνέντευξης ASP.Net και Web API με απαντήσεις
Εκμάθηση # 4: Tutorial POSTMAN: Δοκιμή API χρησιμοποιώντας το POSTMAN
Εκμάθηση # 5: Δοκιμή Web Services με χρήση του Apache HTTP Client

Επισκόπηση των εκπαιδευτικών σε αυτήν τη σειρά δοκιμών API

Εκμάθηση #Τι θα μάθετε
Φόρτωση εστίασης Με βάση τον αριθμό των χρηστών και τους τύπους σχεδίων* Μπορεί να χρησιμοποιηθεί για δοκιμές φόρτωσης API - επιτρέπει την εκτέλεση λίγων δοκιμών για να μάθετε τον αριθμό των χρηστών που μπορεί να υποστηρίξει ένα API.
* Απλό στη χρήση - επιτρέπει την εκτέλεση δοκιμών στο πρόγραμμα περιήγησης.
Εκμάθηση_ # 1: Οδηγός δοκιμών API: Ένας πλήρης οδηγός για αρχάριους
Αυτό το σεμινάριο δοκιμών API σε βάθος θα εξηγήσει τα πάντα σχετικά με τη δοκιμή API και τις υπηρεσίες Web λεπτομερώς και θα σας εκπαιδεύσει σχετικά με τον τρόπο εισαγωγής δοκιμών API στον οργανισμό σας.
Εκμάθηση_ # 2: Εκμάθηση Υπηρεσιών Ιστού: Στοιχεία, Αρχιτεκτονική, Τύποι & Παραδείγματα
Αυτό το σεμινάριο Web Services εξηγεί την Αρχιτεκτονική, τους τύπους και τα στοιχεία των Web Services μαζί με τις σημαντικές ορολογίες και τις διαφορές μεταξύ του SOAP έναντι του REST.
Εκμάθηση_ # 3: Κορυφαίες 35 ερωτήσεις συνέντευξης ASP.Net και Web API με απαντήσεις
Μπορείτε να εξερευνήσετε τη λίστα με τις πιο δημοφιλείς ερωτήσεις συνέντευξης ASP.Net και Web API με απαντήσεις και παραδείγματα για αρχάριους και έμπειρους επαγγελματίες σε αυτό το σεμινάριο.
Εκμάθηση_ # 4: Tutorial POSTMAN: Δοκιμή API χρησιμοποιώντας το POSTMAN
Αυτό το βήμα προς βήμα εκπαιδευτικό πρόγραμμα θα εξηγήσει το API Testing Using POSTMAN μαζί με τα βασικά στοιχεία του POSTMAN, τα συστατικά του και το δείγμα αίτημα και απάντηση με απλούς όρους για την εύκολη κατανόησή σας.
Εκμάθηση_ # 5: Δοκιμή Web Services με χρήση του Apache HTTP Client
Αυτός ο οδηγός API αφορά την εκτέλεση διαφόρων λειτουργιών CRUD σε υπηρεσίες Web και τον έλεγχο υπηρεσιών Web χρησιμοποιώντας το Apache HTTP Client

Οδηγός δοκιμών API

Αυτή η ενότητα θα σας βοηθήσει να αποκτήσετε μια βασική κατανόηση των Υπηρεσιών Ιστού και του Web API, τα οποία, με τη σειρά τους, θα σας βοηθήσουν να κατανοήσετε τις βασικές έννοιες στα επερχόμενα σεμινάρια αυτής της σειράς Δοκιμών API.

Το API (Interface Programming Interface) είναι ένα σύνολο όλων των διαδικασιών και λειτουργιών που μας επιτρέπουν να δημιουργήσουμε μια εφαρμογή, αποκτώντας πρόσβαση στα δεδομένα ή τις λειτουργίες του λειτουργικού συστήματος ή των πλατφορμών. Ο έλεγχος τέτοιων διαδικασιών είναι γνωστός ως API Testing.

Δοκιμή Shift αριστερά

Ένας από τους σημαντικούς τύπους δοκιμών που ζητείται σήμερα στις συνεντεύξεις δοκιμών API είναι το Shift Left Testing. Αυτός ο τύπος δοκιμών εφαρμόζεται σε σχεδόν όλα τα έργα που ακολουθούν μια ευέλικτη μεθοδολογία.

Πριν από την εισαγωγή του Shift Left Testing, οι δοκιμές λογισμικού εμφανίστηκαν μόνο μετά την ολοκλήρωση της κωδικοποίησης και την παράδοση κώδικα στους δοκιμαστές. Αυτή η πρακτική οδήγησε στο τελευταίο λεπτό βιασύνης να τηρήσει την προθεσμία και εμπόδισε επίσης την ποιότητα του προϊόντος σε μεγάλο βαθμό.

Εκτός από αυτό, οι προσπάθειες που έγιναν (όταν αναφέρθηκαν ελαττώματα στην τελευταία φάση πριν από την παραγωγή) ήταν τεράστιες, καθώς οι προγραμματιστές έπρεπε να περάσουν από τη φάση σχεδιασμού και κωδικοποίησης ξανά.

Κύκλος ζωής ανάπτυξης λογισμικού (SDLC) πριν από το Shift Left Testing

Η παραδοσιακή ροή SDLC ήταν: Απαίτηση -> Σχεδιασμός -> Κωδικοποίηση -> Δοκιμή.

Μειονεκτήματα της παραδοσιακής δοκιμής

  • Η δοκιμή είναι στα δεξιά. Πολλά κόστη προκύπτουν όταν εντοπιστεί ένα σφάλμα την τελευταία στιγμή.
  • Ο χρόνος που απαιτείται για την επίλυση του σφάλματος και την επανεξέταση πριν από την προώθηση του στην παραγωγή είναι τεράστιος.

Ως εκ τούτου, εμφανίστηκε μια νέα ιδέα για τη μετατόπιση της δοκιμαστικής φάσης προς τα αριστερά, η οποία οδήγησε έτσι στο Shift Left Testing.

Προτεινόμενη ανάγνωση => Shift Left Testing: Ένα μυστικό μάντρα για επιτυχία στο λογισμικό

Φάσεις δοκιμής Αριστεράς Μετατόπισης

Φάσεις δοκιμής Αριστεράς Μετατόπισης

Ο έλεγχος Left Shift οδήγησε σε μια επιτυχημένη μετεγκατάσταση από το Detect Detect στο Defect Prevention. Βοήθησε επίσης το λογισμικό να αποτύχει γρήγορα και να διορθώσει όλες τις αποτυχίες το νωρίτερο.

API Ιστού

Σε γενικές γραμμές, ένα Web API μπορεί να οριστεί ως κάτι που μεταφέρει το αίτημα από ένα σύστημα πελάτη σε έναν διακομιστή ιστού και στέλνει πίσω την απόκριση από έναν διακομιστή ιστού σε έναν υπολογιστή-πελάτη.

Πώς λειτουργεί ένα API;

Ας πάρουμε ένα πολύ συνηθισμένο σενάριο κράτησης πτήσης στο www.makemytrip.com, η οποία είναι μια διαδικτυακή ταξιδιωτική υπηρεσία που συγκεντρώνει πληροφορίες από πολλές αεροπορικές εταιρείες. Όταν πηγαίνετε για κράτηση πτήσης, εισάγετε πληροφορίες όπως ημερομηνία ταξιδιού / ημερομηνία επιστροφής, τάξη κ.λπ. και κάντε κλικ στην αναζήτηση.

Αυτό θα σας δείξει την τιμή πολλαπλών αεροπορικών εταιρειών και τη διαθεσιμότητά τους. Σε αυτήν την περίπτωση, η εφαρμογή αλληλεπιδρά με API πολλαπλών αεροπορικών εταιρειών και έτσι παρέχει πρόσβαση στα δεδομένα της αεροπορικής εταιρείας.

Ένα άλλο παράδειγμα είναι το www.trivago.com που συγκρίνει και απαριθμεί την τιμή, τη διαθεσιμότητα κ.λπ. διαφορετικών ξενοδοχείων από μια συγκεκριμένη πόλη. Αυτός ο ιστότοπος επικοινωνεί με API πολλαπλών ξενοδοχείων για πρόσβαση στη βάση δεδομένων και παραθέτει τις τιμές και τη διαθεσιμότητα από τον ιστότοπό τους.

Έτσι, ένα Web API μπορεί να οριστεί ως «μια διεπαφή που διευκολύνει την επικοινωνία μεταξύ ενός υπολογιστή-πελάτη και του διακομιστή διαδικτύου».

Υπηρεσίες διαδικτύου

Οι Υπηρεσίες Ιστού είναι (όπως το Web API) οι υπηρεσίες που εξυπηρετούνται από το ένα μηχάνημα στο άλλο. Αλλά η κύρια διαφορά που προκύπτει μεταξύ API και Web Services είναι ότι οι Υπηρεσίες Web χρησιμοποιούν ένα δίκτυο.

Είναι ασφαλές να πούμε ότι όλες οι Υπηρεσίες Ιστού είναι API Ιστού, αλλά όλα τα API Ιστού δεν είναι Υπηρεσίες Ιστού (εξηγείται στο τελευταίο μέρος του άρθρου). Έτσι, οι Υπηρεσίες Ιστού είναι ένα υποσύνολο του Web API. Ανατρέξτε στο παρακάτω διάγραμμα για να μάθετε περισσότερα για το Web API και τις Υπηρεσίες Web.

Web API έναντι Web Services

Web API έναντι WEB Services

ποια προγράμματα χρησιμοποιούν το c ++

Υπηρεσίες Ιστού έναντι API Ιστού

Τόσο το Web API όσο και οι υπηρεσίες Web χρησιμοποιούνται για τη διευκόλυνση της επικοινωνίας μεταξύ του πελάτη και του διακομιστή. Η μεγάλη διαφορά έρχεται μόνο στον τρόπο που επικοινωνούν.

Καθένα από αυτά απαιτεί ένα σώμα αίτησης που είναι αποδεκτό σε μια συγκεκριμένη γλώσσα, τις διαφορές τους στην παροχή ασφαλούς σύνδεσης, την ταχύτητα επικοινωνίας τους με τον διακομιστή και την ανταπόκριση στον πελάτη κ.λπ.

Οι διαφορές μεταξύ των Υπηρεσιών Ιστού και του API Ιστού παρατίθενται παρακάτω για αναφορά σας.

Υπηρεσία Ιστού

  • Οι Υπηρεσίες Ιστού χρησιμοποιούν γενικά XML (Extensible Markup Language), που σημαίνει ότι είναι πιο ασφαλείς.
  • Οι Υπηρεσίες Ιστού είναι πιο ασφαλείς, καθώς τόσο οι Υπηρεσίες Ιστού όσο και τα API παρέχουν SSL (Secure Socket Layer) κατά τη μετάδοση δεδομένων, αλλά παρέχει επίσης WSS (Web Services Security).
  • Η Υπηρεσία Ιστού είναι ένα υποσύνολο του API Ιστού. Για παράδειγμα, Οι Υπηρεσίες Ιστού βασίζονται μόνο σε τρία στυλ χρήσης, δηλαδή SOAP, REST και XML-RPC.
  • Οι Υπηρεσίες Ιστού χρειάζονται πάντα ένα δίκτυο για να λειτουργήσουν.
  • Οι Υπηρεσίες Ιστού υποστηρίζουν «διαφορετικές εφαρμογές ενός κώδικα». Αυτό σημαίνει ότι ένας γενικότερος κώδικας γράφεται σε διαφορετικές εφαρμογές.

API Ιστού

  • Ένα Web API χρησιμοποιεί γενικά το JSON (Σημείωση αντικειμένου JavaScript), που σημαίνει ότι το Web API είναι πιο γρήγορο.
  • Το Web API είναι ταχύτερο καθώς το JSON είναι ελαφρύ, σε αντίθεση με το XML.
  • Τα API Ιστού είναι το υπερσύνολο των Υπηρεσιών Ιστού. Για παράδειγμα, Και τα τρία στυλ των Υπηρεσιών Ιστού υπάρχουν και στο API Ιστού, αλλά εκτός από αυτό, χρησιμοποιεί άλλα στυλ όπως το JSON - RPC.
  • Το Web API δεν απαιτεί απαραίτητα να λειτουργεί ένα δίκτυο.
  • Το Web API ενδέχεται ή όχι να υποστηρίζει τη διαλειτουργικότητα ανάλογα με τη φύση του συστήματος ή της εφαρμογής.

Εισαγωγή δοκιμών API στον οργανισμό σας

Στην καθημερινή μας ζωή, όλοι μας συνηθίζουμε να αλληλεπιδρούμε με τις Εφαρμογές με API και όμως δεν σκεφτόμαστε καν τις διεργασίες back-end που οδηγούν στην υποκείμενη λειτουργικότητα.

Για παράδειγμα, Ας υποθέσουμε ότι περιηγείστε στα προϊόντα στο Amazon.com και βλέπετε ένα προϊόν / συμφωνία που σας αρέσει πραγματικά και θέλετε να το μοιραστείτε με το δίκτυό σας στο Facebook.

Τη στιγμή που κάνετε κλικ στο εικονίδιο Facebook στην ενότητα κοινής χρήσης της σελίδας και εισάγετε τα διαπιστευτήρια του λογαριασμού σας στο Facebook για κοινή χρήση, αλληλεπιδράτε με ένα API που συνδέει απρόσκοπτα τον ιστότοπο του Amazon στο Facebook.

Εστίαση Shift to API Testing

Πριν συζητήσουμε περισσότερα σχετικά με τις δοκιμές API, ας συζητήσουμε τους λόγους για τους οποίους οι εφαρμογές που βασίζονται σε API έχουν αποκτήσει δημοτικότητα τα τελευταία χρόνια.

Υπάρχουν διάφοροι λόγοι για τους οποίους οι οργανισμοί μεταβαίνουν σε προϊόντα και εφαρμογές που βασίζονται σε API. Και λίγα από αυτά εγγράφονται παρακάτω για αναφορά σας.

# 1) Οι εφαρμογές που βασίζονται σε API είναι πιο επεκτάσιμες σε σύγκριση με τις παραδοσιακές εφαρμογές / λογισμικό. Ο ρυθμός ανάπτυξης κώδικα είναι ταχύτερος και το ίδιο API μπορεί να εξυπηρετήσει περισσότερα αιτήματα χωρίς σημαντικές αλλαγές κώδικα ή υποδομής.

#δύο) Οι ομάδες ανάπτυξης δεν χρειάζεται να αρχίζουν να κωδικοποιούν από το μηδέν κάθε φορά που αρχίζουν να εργάζονται για την ανάπτυξη μιας δυνατότητας ή μιας εφαρμογής. Τα API επαναχρησιμοποιούν συχνά τις υπάρχουσες, επαναλαμβανόμενες συναρτήσεις, βιβλιοθήκες, αποθηκευμένες διαδικασίες κ.λπ. και ως εκ τούτου αυτή η διαδικασία μπορεί να τα κάνει πιο παραγωγικά συνολικά.

Για παράδειγμα, Εάν είστε προγραμματιστής που εργάζεται σε έναν ιστότοπο ηλεκτρονικού εμπορίου και θέλετε να προσθέσετε την Amazon ως επεξεργαστή πληρωμών - τότε δεν χρειάζεται να γράψετε τον κώδικα από την αρχή.

Το μόνο που χρειάζεται να κάνετε είναι να ρυθμίσετε την ενοποίηση μεταξύ του ιστότοπού σας και του Amazon API χρησιμοποιώντας κλειδιά ολοκλήρωσης και να καλέσετε το Amazon API για την επεξεργασία πληρωμών κατά την ολοκλήρωση της αγοράς.

# 3) Τα API επιτρέπουν την εύκολη ενσωμάτωση με τα άλλα συστήματα τόσο για υποστηριζόμενες αυτόνομες εφαρμογές όσο και με προϊόντα λογισμικού που βασίζονται σε API.

Για παράδειγμα Ας σκεφτούμε ότι θέλετε να στείλετε μια αποστολή από το Τορόντο στη Νέα Υόρκη. Πηγαίνετε στο διαδίκτυο, μεταβείτε σε έναν γνωστό ιστότοπο Εμπορευματικών μεταφορών και εισαγάγετε τις απαιτούμενες πληροφορίες.

Αφού δώσετε τις υποχρεωτικές πληροφορίες, όταν κάνετε κλικ στο κουμπί Λήψη τιμών - στο πίσω μέρος, αυτός ο ιστότοπος logistics ενδέχεται να συνδέεται με διάφορα API και εφαρμογές παρόχου υπηρεσιών και παρόχου υπηρεσιών για να λάβετε τις δυναμικές τιμές για τον συνδυασμό τοποθεσιών προέλευσης προς προορισμό.

Πλήρες φάσμα δοκιμών API

Ο έλεγχος των API δεν περιορίζεται στην αποστολή αιτήματος στο API και στην ανάλυση της απάντησης μόνο για ορθότητα. Τα API πρέπει να δοκιμαστούν για την απόδοσή τους με διαφορετικά φορτία για ευπάθειες.

Ας το συζητήσουμε λεπτομερώς.

(i) Λειτουργική δοκιμή

Η λειτουργική δοκιμή μπορεί να είναι μια δύσκολη εργασία λόγω της έλλειψης διεπαφής GUI.

Ας δούμε πώς το λειτουργική προσέγγιση δοκιμών για τα APIs διαφέρει από την εφαρμογή που βασίζεται στο GUI και θα συζητήσουμε επίσης μερικά παραδείγματα γύρω από αυτό.

προς την) Η πιο προφανής διαφορά είναι ότι δεν υπάρχει GUI για αλληλεπίδραση. Οι υπεύθυνοι δοκιμών που συνήθως κάνουν λειτουργικές δοκιμές με βάση το GUI το βρίσκουν λίγο πιο δύσκολο να μεταβούν σε δοκιμές εφαρμογών χωρίς GUI σε σύγκριση με κάποιον που είναι ήδη εξοικειωμένος με αυτό.

Αρχικά, ακόμη και πριν ξεκινήσετε τη δοκιμή του API, θα πρέπει να δοκιμάσετε και να επαληθεύσετε την ίδια τη διαδικασία ελέγχου ταυτότητας. Η μέθοδος ελέγχου ταυτότητας θα διαφέρει από το ένα API στο άλλο API και θα περιλαμβάνει κάποιο είδος κλειδιού ή διακριτικού για έλεγχο ταυτότητας.

Εάν δεν μπορείτε να συνδεθείτε με επιτυχία στο API, δεν είναι δυνατή η περαιτέρω δοκιμή. Αυτή η διαδικασία μπορεί να θεωρηθεί συγκρίσιμη με τον έλεγχο ταυτότητας χρήστη στις τυπικές εφαρμογές όπου χρειάζεστε έγκυρα διαπιστευτήρια για να συνδεθείτε και να χρησιμοποιήσετε την εφαρμογή.

σι) Η επικύρωση πεδίου δοκιμών ή η επικύρωση δεδομένων εισαγωγής είναι πολύ σημαντική κατά τη δοκιμή API. Εάν ήταν διαθέσιμη μια πραγματική διεπαφή βασισμένη σε φόρμα (GUI), τότε οι επικυρώσεις πεδίων θα μπορούσαν να εφαρμοστούν στο εμπρόσθιο ή στο πίσω μέρος, διασφαλίζοντας έτσι ότι δεν επιτρέπεται στον χρήστη να εισάγει μη έγκυρες τιμές πεδίου.

Για παράδειγμα, Εάν μια εφαρμογή χρειάζεται τη μορφή ημερομηνίας να είναι ΗΗ / ΜΜ / ΕΕΕΕ, τότε μπορούμε να εφαρμόσουμε αυτήν την επικύρωση στη φόρμα συλλογής πληροφοριών για να διασφαλίσουμε ότι η εφαρμογή λαμβάνει και επεξεργάζεται μια έγκυρη ημερομηνία.

Αυτό, ωστόσο, δεν είναι το ίδιο για εφαρμογές API. Πρέπει να διασφαλίσουμε ότι το API είναι καλά γραμμένο και είναι σε θέση να επιβάλει όλες αυτές τις επικυρώσεις, να διακρίνει μεταξύ έγκυρων και μη έγκυρων δεδομένων και να επιστρέψει τον κωδικό κατάστασης και το μήνυμα σφάλματος επικύρωσης στον τελικό χρήστη μέσω μιας απάντησης.

ντο) Ο έλεγχος της ορθότητας των απαντήσεων από το API για έγκυρη και μη έγκυρη απόκριση είναι πράγματι ζωτικής σημασίας. Εάν ληφθεί κωδικός κατάστασης 200 (που σημαίνει όλα εντάξει) ως απάντηση από το δοκιμαστικό API, αλλά εάν το κείμενο απόκρισης αναφέρει ότι έχει παρουσιαστεί σφάλμα, τότε αυτό είναι ένα ελάττωμα.

Επιπλέον, εάν το ίδιο το μήνυμα σφάλματος είναι εσφαλμένο, τότε αυτό μπορεί να είναι πολύ παραπλανητικό για τον τελικό πελάτη που προσπαθεί να ενσωματωθεί σε αυτό το API.

Στο παρακάτω στιγμιότυπο οθόνης, ο χρήστης έχει εισαγάγει μη έγκυρο βάρος, το οποίο υπερβαίνει τα αποδεκτά 2267 Kgs. Το API αποκρίνεται με τον κωδικό κατάστασης σφάλματος και το μήνυμα σφάλματος. Ωστόσο, το μήνυμα σφάλματος αναφέρει λανθασμένα τις μονάδες βάρους ως λίβρες αντί για KG. Αυτό είναι ένα ελάττωμα που μπορεί να προκαλέσει σύγχυση στον τελικό πελάτη.

Δοκιμή API - λάθος μήνυμα σφάλματος

(ii) Δοκιμή φορτίου και απόδοσης

Τα API προορίζονται να είναι κλιμακούμενα από το σχεδιασμό.

Αυτό, με τη σειρά του, κάνει Load και Δοκιμή απόδοσης απαραίτητο, ειδικά εάν το σύστημα που σχεδιάζεται αναμένεται να εξυπηρετεί χιλιάδες αιτήματα ανά λεπτό ή ώρα, ανάλογα με την απαίτηση. Οι τακτικές δοκιμές φόρτωσης και απόδοσης στο API μπορούν να βοηθήσουν στη συγκριτική αξιολόγηση της απόδοσης, των μέγιστων φορτίων και του σημείου θραύσης.

Αυτά τα δεδομένα είναι χρήσιμα ενώ σχεδιάζετε να κλιμακώσετε μια εφαρμογή. Η διαθεσιμότητα αυτών των πληροφοριών θα βοηθήσει στην υποστήριξη αποφάσεων και προγραμματισμού, ειδικά εάν ο οργανισμός σχεδιάζει να προσθέσει περισσότερους πελάτες, κάτι που θα σήμαινε περισσότερα εισερχόμενα αιτήματα.

Για παράδειγμα , ας πούμε ότι με βάση τις παρεχόμενες απαιτήσεις, γνωρίζουμε ότι το API που έχει σχεδιαστεί πρέπει να εξυπηρετεί τουλάχιστον 500 αιτήσεις ανά ώρα και να διατηρεί τον μέσο χρόνο απόκρισης μικρότερο από 0,01 δευτερόλεπτα.

Με βάση τις δοκιμές φόρτωσης και απόδοσης, ανακαλύψαμε ότι όσο το API λαμβάνει λιγότερα από 500 αιτήματα ανά ώρα, είναι σε θέση να διατηρήσει το SLA για μέσο χρόνο απόκρισης. Ωστόσο, εάν λάβει άλλα 200 αιτήματα, τότε ο μέσος χρόνος απόκρισης αυξάνεται και το σημείο διακοπής επιτυγχάνεται όταν το εισερχόμενο αίτημα υπερβαίνει τα 1200 ανά ώρα.

Συνήθως, φαίνεται ότι κατά τη διάρκεια των αρχικών φάσεων σχεδιασμού, η έμφαση δίνεται συχνά στις λειτουργικές πτυχές του API. Με την πάροδο του χρόνου, ένα προϊόν αρχίζει να υποστηρίζει πολλούς ζωντανούς πελάτες, δηλαδή όταν η δοκιμή για απόδοση API και δοκιμή φόρτωσης έρχεται στην εικόνα με πιο συνηθισμένο τρόπο.

(iii) Δοκιμή ασφαλείας

Οι διεπαφές προγραμματισμού εφαρμογών ή τα API είναι ευάλωτα και αποτελούν το ευκολότερο σημείο πρόσβασης για κακόβουλους εισβολείς που θέλουν πρόσβαση σε δεδομένα ή να αποκτήσουν έλεγχο μιας εφαρμογής.

Αυτό μπορεί να οδηγήσει οποιαδήποτε εταιρεία σε νομικό πρόβλημα, όπου λόγω παραβίασης της ασφάλειας, ακούσια άτομα ή / και οργανισμοί μπορούν να έχουν πρόσβαση στα δεδομένα του πελάτη μέσω ενός σεβαστού API.

Δοκιμή ασφαλείας είναι ένας εξειδικευμένος κλάδος δοκιμών και θα πρέπει να γίνεται από ειδικούς. Οι πόροι ελέγχου ασφάλειας μπορούν να προέρχονται από τον οργανισμό ή από ανεξάρτητους συμβούλους.

Διαβάστε επίσης = >> Τι είναι ο έλεγχος σύμβασης Pact

Πώς να εισαγάγετε δοκιμές API στον οργανισμό σας

Η διαδικασία για την εισαγωγή δοκιμών API σε οποιονδήποτε οργανισμό είναι παρόμοια με τη διαδικασία που χρησιμοποιείται για την εφαρμογή ή την ανάπτυξη οποιουδήποτε άλλου εργαλείου και πλαισίου δοκιμών.

Ο παρακάτω πίνακας συνοψίζει τα κύρια βήματα μαζί με το αναμενόμενο αποτέλεσμα κάθε βήματος.

ΦάσηΒήμαΑναμενόμενο αποτέλεσμα
Επιλογή εργαλείουΣυγκεντρώστε τις απαιτήσεις και προσδιορίστε τους περιορισμούς
Κατανοήστε τις απαιτήσεις για έρευνα αγοράς για το κατάλληλο εργαλείο δοκιμών API.
Π.χ.
Τι είδους API δοκιμάζεται - SOAP ή REST;
Πρέπει να προσλάβουμε ελεγκτή για αυτόν τον ρόλο ή να εκπαιδεύσουμε τον υπάρχοντα ελεγκτή;
Τι είδους δοκιμές θα εκτελεστούν - λειτουργικές, δοκιμές απόδοσης κ.λπ.
Ποιος είναι ο προϋπολογισμός για εκτέλεση;
Αξιολογήστε τα διαθέσιμα εργαλείαΣυγκρίνετε τα διαθέσιμα εργαλεία και τα σύντομα 1 ή 2 εργαλεία που πληρούν καλύτερα τις απαιτήσεις.
Απόδειξη της έννοιαςΕφαρμόστε ένα υποσύνολο δοκιμών με το εργαλείο της σύντομης λίστας.
Παρουσιάστε ευρήματα στους ενδιαφερόμενους.
Οριστικοποιήστε το εργαλείο που θα εφαρμοστεί.
ΕκτέλεσηΞεκινώνταςΑνάλογα με το εργαλείο επιλογής σας, θα χρειαστεί να εγκαταστήσετε το απαιτούμενο εργαλείο σε υπολογιστή, εικονική μηχανή ή διακομιστή.
Εάν το εργαλείο επιλογής βασίζεται στη συνδρομή, δημιουργήστε τους απαιτούμενους λογαριασμούς ομάδας.
Εκπαιδεύστε την ομάδα εάν απαιτείται.
ΞεκίναΔημιουργήστε δοκιμές
Εκτελέστε δοκιμές
Αναφορά ελαττωμάτων

Κοινές προκλήσεις και τρόποι μετριασμού τους

Ας συζητήσουμε μερικές από τις κοινές προκλήσεις που αντιμετωπίζουν οι ομάδες QA ενώ προσπαθούν να εφαρμόσουν ένα πλαίσιο δοκιμών API σε έναν οργανισμό.

# 1) Επιλογή του σωστού εργαλείου

Η επιλογή του σωστού εργαλείου για την εργασία είναι η πιο κοινή πρόκληση. Υπάρχουν πολλά εργαλεία δοκιμών API που διατίθενται στην αγορά.

Μπορεί να φαίνεται πολύ ελκυστικό για την εφαρμογή του πιο πρόσφατου, ακριβότερου εργαλείου που διατίθεται στην αγορά - αλλά εάν δεν φέρει τα επιθυμητά αποτελέσματα, τότε αυτό το εργαλείο δεν έχει καμία χρησιμότητα.

Ως εκ τούτου, επιλέξτε πάντα το εργαλείο που καλύπτει τις απαιτήσεις «πρέπει να έχετε» με βάση τις οργανωτικές σας ανάγκες.

Ακολουθεί ένα δείγμα μήτρας αξιολόγησης εργαλείων για τα διαθέσιμα Εργαλεία API

ΕργαλείοΤιμολόγησηΣημειώσεις
UI σαπουνιού Διατίθεται δωρεάν έκδοση για το SoapUI Open Source (Λειτουργικές δοκιμές)* REST, SOAP και άλλα δημοφιλή πρωτόκολλα API και IoT.

* Περιλαμβάνεται στην δωρεάν έκδοση
Ad-hoc δοκιμές SOAP και REST
Επιβεβαίωση μηνύματος
Δημιουργία δοκιμής μεταφοράς και απόθεσης
Δοκιμαστικά αρχεία καταγραφής
Διαμόρφωση δοκιμής
Δοκιμή από ηχογραφήσεις
Αναφορά μονάδας.

* Πλήρης κατάλογος χαρακτηριστικών μπορείτε να βρείτε στον ιστότοπό τους.
Ταχυδρόμος Διατίθεται δωρεάν εφαρμογή Postman* Χρησιμοποιείται περισσότερο για REST.
* Τα χαρακτηριστικά μπορούν να βρεθούν στον ιστότοπό τους.
Parasoft Είναι ένα εργαλείο επί πληρωμή, απαιτεί την αγορά άδειας και, στη συνέχεια, απαιτείται εγκατάσταση πριν μπορέσει να χρησιμοποιηθεί το εργαλείο.* Περιεκτική δοκιμή API: λειτουργική, φόρτωση, έλεγχος ασφαλείας, διαχείριση δεδομένων δοκιμών
vREST Με βάση τον αριθμό χρηστών* Αυτοματοποιημένη δοκιμή API REST.
* Εγγραφή και αναπαραγωγή.
* Αφαιρεί την εξάρτηση από το frontend και το backend χρησιμοποιώντας πλαστά API.
* Ισχυρή επικύρωση απόκρισης.
* Λειτουργεί για δοκιμαστικές εφαρμογές που αναπτύσσονται στο localhost / intranet / internet.
* JIRA Integration, Jenkins Integration Imports από την Swagger, Postman.
HttpMaster Express Edition: Δωρεάν λήψη
Επαγγελματική έκδοση: Με βάση τον αριθμό χρηστών
* Βοηθά στη δοκιμή ιστότοπων καθώς και στη δοκιμή API.
* Άλλα χαρακτηριστικά περιλαμβάνουν τη δυνατότητα καθορισμού καθολικών παραμέτρων, παρέχει στον χρήστη τη δυνατότητα να δημιουργεί ελέγχους για επικύρωση απόκρισης δεδομένων χρησιμοποιώντας το μεγάλο σύνολο τύπων επικύρωσης που υποστηρίζει.
Runscope Με βάση τον αριθμό των χρηστών και τους τύπους σχεδίων
* Για παρακολούθηση και δοκιμή API.
* Μπορεί να χρησιμοποιηθεί για επικύρωση δεδομένων για να διασφαλιστεί η επιστροφή των σωστών δεδομένων.
* Περιέχει δυνατότητα παρακολούθησης και ειδοποίησης σε περίπτωση αποτυχίας συναλλαγής API (εάν η εφαρμογή σας απαιτεί επικύρωση πληρωμής, τότε αυτό το εργαλείο μπορεί να αποδειχθεί καλή επιλογή).
PingAPI Δωρεάν για 1 έργο (1.000 αίτημα)* Ευεργετικό για αυτοματοποιημένες δοκιμές και παρακολούθηση API.

# 2) Λείπουν προδιαγραφές δοκιμής

Ως υπεύθυνοι δοκιμών, πρέπει να γνωρίζουμε τα αναμενόμενα αποτελέσματα για να δοκιμάσουμε αποτελεσματικά μια εφαρμογή. Αυτό είναι συχνά μια πρόκληση, καθώς για να γνωρίζουμε τα αναμενόμενα αποτελέσματα, πρέπει να έχουμε σαφείς ακριβείς απαιτήσεις - κάτι που δεν ισχύει.

Για παράδειγμα , λάβετε υπόψη τις παρακάτω απαιτήσεις:

'Η αίτηση πρέπει να αποδεχτεί μόνο μια έγκυρη ημερομηνία αποστολής και όλες οι μη έγκυρες απαιτήσεις πρέπει να απορριφθούν'

Αυτές οι απαιτήσεις δεν έχουν βασικές λεπτομέρειες και είναι πολύ ασαφείς - πώς καθορίζουμε μια έγκυρη ημερομηνία; Τι γίνεται με τη μορφή; Επιστρέφουμε κάποιο μήνυμα απόρριψης στον τελικό χρήστη κ.λπ.;

Παράδειγμα σαφών απαιτήσεων:

1) Η αίτηση θα πρέπει να δέχεται μόνο μια έγκυρη ημερομηνία αποστολής.

Η ημερομηνία αποστολής θεωρείται έγκυρη εάν είναι

  • Όχι στο παρελθόν
  • Μεγαλύτερη ή ίση με τη σημερινή ημερομηνία
  • Είναι σε αποδεκτή μορφή: ΗΗ / ΜΜ / ΕΕΕΕ

δύο)

Κωδικός κατάστασης απόκρισης = 200
Μήνυμα: ΟΚ

3) Η ημερομηνία αποστολής που δεν πληροί τα παραπάνω κριτήρια θα πρέπει να θεωρείται άκυρη. Εάν ένας πελάτης στέλνει μια μη έγκυρη ημερομηνία αποστολής, τότε πρέπει να απαντήσει με τα ακόλουθα μηνύματα σφάλματος:

3.1

Κωδικός κατάστασης απόκρισης ΟΧΙ 200
Σφάλμα: Η ημερομηνία αποστολής δεν είναι έγκυρη. βεβαιωθείτε ότι η ημερομηνία είναι σε μορφή ΗΗ / ΜΜ / ΕΕΕΕΕ

3.2

Κωδικός κατάστασης απόκρισης ΟΧΙ 200
Σφάλμα: Η παρεχόμενη ημερομηνία αποστολής έχει παρέλθει

# 3) Καμπύλη εκμάθησης

Όπως αναφέρθηκε προηγουμένως, η προσέγγιση για δοκιμές API είναι διαφορετική σε σύγκριση με την προσέγγιση που ακολουθήθηκε κατά τη δοκιμή εφαρμογών με βάση το GUI.

Εάν προσλαμβάνετε ειδικούς είτε εσωτερικούς είτε συμβούλους για δοκιμές API, τότε η καμπύλη εκμάθησης της προσέγγισης δοκιμών API ή του εργαλείου δοκιμής API μπορεί να είναι ελάχιστη. Οποιαδήποτε καμπύλη μάθησης, σε αυτήν την περίπτωση, θα σχετίζεται με την απόκτηση των γνώσεων του προϊόντος ή της εφαρμογής.

Εάν ένα υπάρχον μέλος της ομάδας έχει ανατεθεί να μάθει δοκιμές API, τότε ανάλογα με το εργαλείο επιλογής, η καμπύλη εκμάθησης μπορεί να είναι μεσαία έως υψηλή, μαζί με την αλλαγή της προσέγγισης δοκιμής. Η καμπύλη εκμάθησης για το ίδιο το προϊόν ή την εφαρμογή μπορεί να είναι χαμηλού μέσου, ανάλογα με το αν αυτός ο υπεύθυνος δοκιμών έχει δοκιμάσει αυτήν την εφαρμογή πριν ή όχι.

# 4) Υφιστάμενο σύνολο δεξιοτήτων

Αυτό συνδέεται άμεσα με το προηγούμενο σημείο σχετικά με την καμπύλη μάθησης.

Εάν ένας δοκιμαστής άλλαζε από δοκιμές με βάση το GUI, τότε ο υπεύθυνος δοκιμών θα πρέπει να αλλάξει την προσέγγιση δοκιμής και να μάθει το νέο εργαλείο ή πλαίσιο όπως απαιτείται. Π.χ. Εάν το API αποδέχεται τα αιτήματα σε μορφή JSON, τότε ο υπεύθυνος δοκιμών θα πρέπει να μάθει τι είναι το JSON, προκειμένου να ξεκινήσει η δημιουργία των δοκιμών.

Μελέτη περίπτωσης

Εργο

Προκειμένου να αναβαθμίσει μια υπάρχουσα εφαρμογή, μια εταιρεία ήθελε να προσφέρει ένα προϊόν σε API καθώς και μια τυπική εφαρμογή GUI. Ζητήθηκε από την ομάδα QA να παράσχει ένα σχέδιο κάλυψης δοκιμών για να διασφαλίσει ότι είναι έτοιμοι να φιλοξενήσουν δοκιμές API πέρα ​​από τις κανονικές δοκιμές που βασίζονται στο γραφικό περιβάλλον.

Προκλήσεις

  • Κανένα από τα άλλα προϊόντα λογισμικού δεν είχε αρχιτεκτονική βάσει API, επομένως για να διευκολύνει τις δοκιμές γύρω από αυτήν την εργασία, η ομάδα πρέπει να δημιουργήσει τη διαδικασία δοκιμής API από το μηδέν. Αυτό σημαίνει ότι τα εργαλεία έπρεπε να αξιολογηθούν, να επιλεγούν σύντομα, να οριστικοποιηθούν και ότι η ομάδα έπρεπε να εκπαιδευτεί για τις δοκιμές.
  • Δεν διατέθηκε επιπλέον προϋπολογισμός για την απόκτηση και εφαρμογή του εργαλείου. Αυτό σημαίνει ότι η ομάδα έπρεπε να επιλέξει ένα δωρεάν εργαλείο δοκιμής API ανοικτού κώδικα και κάποιος από την υπάρχουσα ομάδα έπρεπε να εκπαιδευτεί για να αναλάβει αυτό το έργο.
  • Δεν υπήρχαν απαιτήσεις για πεδία API και επικύρωση δεδομένων. Οι απαιτήσεις ήταν «πρέπει να λειτουργούν το ίδιο με την αντίστοιχη εφαρμογή GUI».

Η προσέγγιση που ακολούθησε η ομάδα για τον μετριασμό των κινδύνων και την αντιμετώπιση των προκλήσεων

  • Η ομάδα QA συνεργάστηκε με την ομάδα του έργου για να προσδιορίσει τις ακόλουθες απαιτήσεις:
    • Τύπος API (REST / SOAP): ΥΠΟΛΟΙΠΟ
    • Απαιτούμενες δοκιμές (Λειτουργικό, Φορτίο, Ασφάλεια): Μόνο λειτουργικές δοκιμές
    • Απαιτούνται αυτοματοποιημένες δοκιμές (Ναι / Όχι): Προαιρετικό για τώρα
    • Αναφορές δοκιμών (Ναι / Όχι): Απαιτείται
  • Η ομάδα QA έκανε αξιολόγηση εργαλείου σχετικά με τα διαθέσιμα Εργαλεία δοκιμών API με βάση τις απαιτήσεις που πρέπει να έχετε. Το Postman API Tool ολοκληρώθηκε ως εργαλείο της επιλογής τους, καθώς ήταν δωρεάν, και εύκολο στη χρήση, ελαχιστοποιώντας έτσι την καμπύλη εκμάθησης και είχε τη δυνατότητα αυτοματοποίησης των δοκιμών και συνοδεύτηκε από καλές ενσωματωμένες αναφορές.
  • Ο ίδιος υπεύθυνος δοκιμών που δοκίμασε την εφαρμογή εκπαιδεύτηκε για τη χρήση του Postman για τη δημιουργία αρχικών δοκιμών, εξαλείφοντας έτσι τυχόν κενά γνώσης προϊόντων.
  • Για να αντιμετωπίσει τις απαιτήσεις που λείπουν, η ομάδα του έργου δημιούργησε την τεκμηρίωση επιπέδου πεδίου υψηλού επιπέδου χρησιμοποιώντας το Swagger. Αυτό, ωστόσο, άφησε ορισμένα κενά όσον αφορά τις αποδεκτές μορφές δεδομένων και αυτό αναλήφθηκε με την ομάδα του έργου και οι αναμενόμενες μορφές συμφωνήθηκαν και τεκμηριώθηκαν.

συμπέρασμα

Οι εφαρμογές που βασίζονται σε API έχουν αποκτήσει δημοτικότητα τα τελευταία χρόνια. Αυτές οι εφαρμογές είναι πιο επεκτάσιμες σε σύγκριση με τις παραδοσιακές εφαρμογές / λογισμικό και επιτρέπουν ευκολότερη ενσωμάτωση με τα άλλα API ή εφαρμογές.

Αυτό το σεμινάριο δοκιμών API εξήγησε τα πάντα σχετικά με τη δοκιμή API, τη δοκιμή Shift Left, τις υπηρεσίες ιστού και το Web API. Εξετάσαμε επίσης τις διαφορές μεταξύ των Υπηρεσιών Ιστού έναντι του API Ιστού με παραδείγματα.

Στο δεύτερο μέρος του σεμιναρίου, συζητήσαμε για το πλήρες φάσμα των δοκιμών API, τον τρόπο εισαγωγής της δοκιμής API στον οργανισμό σας και ορισμένες κοινές προκλήσεις σε αυτήν τη διαδικασία μαζί με λύσεις για αυτούς.

Ρίξτε μια ματιά στο επερχόμενο σεμινάριό μας για να μάθετε περισσότερα για τις Υπηρεσίες Web μαζί με παραδείγματα !!

ΕΠΟΜΕΝΟ Φροντιστήριο

Συνιστώμενη ανάγνωση

^