Tutorial API de testare: un ghid complet pentru începători

api testing tutorial

Acest tutorial de testare API în profunzime explică totul despre testarea API, serviciile web și modul de introducere a testării API în organizația dvs.:

Obțineți o perspectivă profundă asupra testării API împreună cu conceptul de testare shift-stânga și servicii web din acest tutorial introductiv.

Concepte precum API-ul web, modul în care funcționează API (cu exemple din lumea reală) și în ce fel este diferit de serviciile web sunt bine explicate cu exemple în acest tutorial.

=>DERULEAZA IN JOSpentru a vedea întreaga listă de 5 tutoriale de testare API în profunzime pentru începători

Ce veți învăța:

• Lista tutorialelor de testare API
• Prezentare generală a tutorialelor din această serie de testare API
• Tutorial de testare API
  • Testare Shift Stânga
  • Ciclul de viață al dezvoltării software-ului (SDLC) înainte de testarea Shift la stânga
  • Fazele testării schimbării la stânga
  • API Web
  • Cum funcționează un API?
  • Servicii Web
  • Servicii Web vs API Web
• Vă prezentăm testarea API în organizația dvs.
  • Focus Shift to API Testing
  • Spectru complet de testare API
    • (i) Testarea funcțională
    • (ii) Testarea sarcinii și performanței
    • (iii) Testarea securității
  • Cum să introduceți testarea API în organizația dvs.
  • Provocări comune și modalități de a le atenua
    • # 1) Alegerea instrumentului potrivit
    • # 2) Specificațiile testului lipsesc
    • # 3) Curba de învățare
    • # 4) Set de abilități existente
  • Studiu de caz
• Concluzie
  • Lectură recomandată

Lista tutorialelor de testare API

Tutorial nr. 1: Tutorial API de testare: un ghid complet pentru începători
Tutorial nr. 2: Tutorial Servicii Web: componente, arhitectură, tipuri și exemple
Tutorial nr. 3: Top 35 ASP.Net și API-uri Web Interviu întrebări cu răspunsuri
Tutorial # 4: Tutorial POSTMAN: Testarea API folosind POSTMAN
Tutorial # 5: Testarea serviciilor web utilizând clientul Apache HTTP

Prezentare generală a tutorialelor din această serie de testare API

Tutorial de testare API

Această secțiune vă va ajuta să obțineți o înțelegere de bază a serviciilor web și a API-ului web, care, la rândul său, vă va fi de ajutor în înțelegerea conceptelor majore din tutorialele viitoare din această serie de testare API.

API (Application Programming Interface) este un set de toate procedurile și funcțiile care ne permit să creăm o aplicație accesând datele sau caracteristicile sistemului de operare sau al platformelor. Testarea unor astfel de proceduri este cunoscută sub numele de API Testing.

Testare Shift Stânga

Unul dintre tipurile importante de testare care se solicită în prezent în interviurile de testare API este Testarea Shift Stânga. Acest tip de testare este practicat în aproape toate proiectele care urmează o metodologie agilă.

Înainte de a fi introdus Shift Left Testing, testarea software-ului a intrat în imagine doar după finalizarea codificării și codul a fost livrat testerilor. Această practică a condus la agitația de ultim moment în respectarea termenului limită și, de asemenea, a împiedicat calitatea produsului într-o mare măsură.

În afară de aceasta, eforturile depuse (când au fost raportate defecte în ultima fază înainte de producție) au fost uriașe, deoarece dezvoltatorii au trebuit să treacă din nou atât prin faza de proiectare, cât și de codare.

Ciclul de viață al dezvoltării software-ului (SDLC) înainte de testarea Shift la stânga

Fluxul tradițional SDLC a fost: Cerință -> Proiectare -> Codificare -> Testare.

Dezavantaje ale testării tradiționale

• Testarea este la extremă dreapta. O mulțime de costuri sunt suportate atunci când un bug este identificat în ultimul moment.
• Timpul consumat pentru rezolvarea bug-ului și retestarea acestuia înainte de promovarea acestuia la producție este imens.

Prin urmare, a apărut o nouă idee pentru a muta faza de testare spre stânga, ceea ce a dus la Shift Left Testing.

Citire sugerată => Testare Shift la stânga: o mantră secretă pentru succesul software-ului

Fazele testării schimbării la stânga

Testarea schimbării la stânga a dus la o migrare reușită de la detectarea defectelor la prevenirea defectelor. De asemenea, a ajutat software-ul să eșueze rapid și să remedieze cel mai devreme toate eșecurile.

API Web

În termeni generali, un API Web poate fi definit ca ceva care duce cererea de la un sistem client la un server web și trimite înapoi răspunsul de la un server web la un computer client.

Cum funcționează un API?

Să luăm un scenariu foarte comun de rezervare a unui zbor pe www.makemytrip.com, care este un serviciu de călătorie online care agregă informații de la mai multe companii aeriene. Când alegeți o rezervare de zbor, introduceți informații precum data călătoriei / data întoarcerii, clasa etc. și faceți clic pe căutare.

Aceasta vă va arăta prețul mai multor companii aeriene și disponibilitatea acestora. În acest caz, aplicația interacționează cu API-urile mai multor companii aeriene și oferă astfel acces la datele companiei aeriene.

Un alt exemplu este www.trivago.com, care compară și listează prețul, disponibilitatea etc. ale diferitelor hoteluri dintr-un anumit oraș. Acest site web comunică cu API-urile mai multor hoteluri pentru a accesa baza de date și listează prețurile și disponibilitatea de pe site-ul lor web.

Astfel, un API Web poate fi definit ca „o interfață care facilitează comunicarea între o mașină client și serverul web”.

Servicii Web

Serviciile Web sunt (cum ar fi API-ul Web) serviciile care servesc de la o mașină la alta. Dar diferența majoră care apare între API și Serviciile Web este că Serviciile Web utilizează o rețea.

Este sigur să spunem că toate serviciile web sunt API-uri web, dar toate API-urile web nu sunt servicii web (explicat în ultima parte a articolului). Astfel, Serviciile Web sunt un subset de API Web. Consultați diagrama de mai jos pentru a afla mai multe despre API-ul web și serviciile web.

API Web vs Servicii Web

Servicii Web vs API Web

Atât API-ul web, cât și Serviciile web sunt utilizate pentru a facilita comunicarea dintre client și server. Diferența majoră vine doar în modul în care comunică.

Fiecare dintre aceștia necesită un corp de solicitare care este acceptabil într-o limbă specifică, diferențele lor în furnizarea unei conexiuni sigure, viteza lor de comunicare către server și de răspuns la client etc.

Diferențele dintre serviciile web și API-ul web sunt listate mai jos pentru referință.

Serviciu web

• Serviciile Web utilizează în general XML (Extensible Markup Language), ceea ce înseamnă că sunt mai sigure.
• Serviciile Web sunt mai sigure, deoarece atât Serviciile Web, cât și API-urile furnizează SSL (Secure Socket Layer) în timpul transmiterii datelor, dar oferă și WSS (Securitatea serviciilor web).
• Serviciul Web este un subset de API Web. De exemplu, Serviciile Web se bazează numai pe trei stiluri de utilizare, adică SOAP, REST și XML-RPC.
• Serviciile Web au întotdeauna nevoie de o rețea pentru a funcționa.
• Serviciile Web acceptă „One Code different applications”. Aceasta înseamnă că un cod mai generic este scris în diferite aplicații.

API Web

• Un API Web folosește în general JSON (JavaScript Object Notation), ceea ce înseamnă că API-ul Web este mai rapid.
• API-ul web este mai rapid, deoarece JSON este ușor, spre deosebire de XML.
• API-urile web sunt supersetul serviciilor web. De exemplu, Toate cele trei stiluri de servicii web sunt prezente și în API-ul web, dar în afară de aceasta, folosește alte stiluri, cum ar fi JSON - RPC.
• API-ul web nu necesită neapărat o rețea pentru a funcționa.
• API-ul web poate sau nu să accepte interoperabilitatea în funcție de natura sistemului sau a aplicației.

Vă prezentăm testarea API în organizația dvs.

În viața noastră de zi cu zi, toți suntem atât de obișnuiți să interacționăm cu aplicațiile cu API-uri și totuși nici măcar nu ne gândim la procesele back-end care conduc funcționalitatea de bază.

De exemplu, Lăsați-ne să considerăm că navigați prin produsele de pe Amazon.com și vedeți un produs / ofertă care vă place cu adevărat și doriți să îl partajați cu rețeaua dvs. Facebook.

În momentul în care faceți clic pe pictograma Facebook din secțiunea de partajare a paginii și introduceți acreditările contului dvs. Facebook pentru a le partaja, interacționați cu un API care conectează perfect site-ul Amazon la Facebook.

Focus Shift to API Testing

Înainte de a discuta mai multe despre testarea API, să discutăm motivele pentru care aplicațiile bazate pe API au câștigat popularitate în ultima vreme.

Există mai multe motive pentru care organizațiile trec la produse și aplicații bazate pe API. Și câteva dintre ele sunt înscrise mai jos pentru referință.

# 1) Aplicațiile bazate pe API sunt mai scalabile în comparație cu aplicațiile / software-ul tradițional. Rata de dezvoltare a codului este mai rapidă și același API poate deservi mai multe cereri fără modificări majore de cod sau de infrastructură.

#Două) Echipele de dezvoltare nu trebuie să înceapă codarea de la zero de fiecare dată când încep să lucreze la dezvoltarea unei caracteristici sau a unei aplicații. API-urile reutilizează cel mai adesea funcțiile existente, repetabile, bibliotecile, procedurile stocate etc. și, prin urmare, acest proces le poate face mai productive în general.

De exemplu, Dacă sunteți un dezvoltator care lucrează pe un site de comerț electronic și doriți să adăugați Amazon ca procesator de plăți - atunci nu trebuie să scrieți codul de la zero.

Tot ce trebuie să faceți este să configurați integrarea între site-ul dvs. web și Amazon API folosind cheile de integrare și să apelați Amazon API pentru procesarea plăților în timpul plății.

# 3) API-urile permit integrarea ușoară cu celelalte sisteme, atât pentru aplicații independente acceptate, cât și cu produse software bazate pe API.

De exemplu , Să luăm în considerare faptul că doriți să trimiteți o expediere de la Toronto la New York. Mergeți online, navigați la un site de marfă sau logistică bine cunoscut și introduceți informațiile solicitate.

După furnizarea informațiilor obligatorii, când faceți clic pe butonul Obțineți tarife - în partea din spate, acest site web logistic se poate conecta cu mai multe API-uri și aplicații ale operatorilor și furnizorilor de servicii pentru a obține tarifele dinamice pentru combinația de locații de la origine la destinație.

Spectru complet de testare API

Testarea API-urilor nu se limitează la trimiterea unei cereri către API și analizarea răspunsului numai pentru corectitudine. API-urile trebuie să fie testate pentru performanța lor în funcție de sarcini diferite pentru vulnerabilități.

Să discutăm acest lucru în detaliu.

(i) Testarea funcțională

Testarea funcțională poate fi o sarcină provocatoare din cauza lipsei unei interfețe GUI.

Să vedem cum abordarea testării funcționale pentru API este diferit de aplicația bazată pe GUI și vom discuta, de asemenea, câteva exemple în jurul acesteia.

java add to end of array

la) Cea mai evidentă diferență este că nu există nici o interfață grafică cu care să interacționați. Testerii care efectuează de obicei teste funcționale bazate pe interfața grafică găsesc un pic mai greu să treacă la testarea aplicației non-GUI în comparație cu cineva care este deja familiarizat cu aceasta.

Inițial, chiar înainte de a începe testarea API-ului, va trebui să testați și să verificați procesul de autentificare în sine. Metoda de autentificare va varia de la un API la alt API și ar implica un fel de cheie sau simbol pentru autentificare.

Dacă nu vă puteți conecta la API cu succes, testarea ulterioară nu poate continua. Acest proces poate fi considerat comparabil cu autentificarea utilizatorului în aplicațiile standard în care aveți nevoie de acreditări valide pentru a vă conecta și utiliza aplicația.

b) Testarea validărilor de câmp sau validarea datelor de intrare este foarte importantă în timpul testării API-urilor. Dacă era disponibilă o interfață bazată pe formular (GUI), atunci validările de câmp ar putea fi implementate în front-end sau back-end, asigurându-se astfel că un utilizator nu are voie să introducă valori de câmp nevalide.

De exemplu, Dacă o cerere are nevoie ca formatul de dată să fie ZZ / LL / AAAA, atunci putem aplica această validare pe formularul de colectare a informațiilor pentru a ne asigura că aplicația primește și procesează o dată validă.

Totuși, acest lucru nu este același pentru aplicațiile API. Trebuie să ne asigurăm că API-ul este bine scris și este capabil să aplice toate aceste validări, să facem distincția între date valide și nevalide și să returnăm utilizatorul final codul de stare și mesajul de eroare de validare printr-un răspuns.

c) Testarea corectitudinii răspunsurilor de la API pentru un răspuns valid și invalid este crucială într-adevăr. Dacă un cod de stare de 200 (adică totul în regulă) este primit ca răspuns de la testul API, dar dacă textul răspunsului spune că a fost întâlnită o eroare, atunci acesta este un defect.

În plus, dacă mesajul de eroare în sine este incorect, atunci acest lucru poate fi foarte înșelător pentru clientul final care încearcă să se integreze cu acest API.

În captura de ecran de mai jos, utilizatorul a introdus greutate nevalidă, care depășește 2267 kg acceptabile. API-ul răspunde cu codul de stare al erorii și mesajul de eroare. Cu toate acestea, mesajul de eroare menționează incorect unitățile de greutate ca lbs în loc de KG. Acesta este un defect care poate deruta clientul final.

(ii) Testarea sarcinii și performanței

API-urile sunt menite să fie scalabile prin design.

Acest lucru, la rândul său, face ca Load și Test de performanta esențial, mai ales dacă sistemul proiectat este de așteptat să deservească mii de solicitări pe minut sau oră, în funcție de cerință. Efectuarea de rutină a testelor de încărcare și performanță pe API poate ajuta la compararea performanței, a sarcinilor de vârf și a punctului de rupere.

Aceste date sunt utile în timp ce planificați extinderea unei aplicații. Disponibilitatea acestor informații va ajuta la sprijinirea deciziilor și a planificării, mai ales dacă organizația intenționează să adauge mai mulți clienți, ceea ce ar însemna mai multe solicitări primite.

De exemplu , să presupunem că, pe baza cerințelor furnizate, știm că API-ul proiectat trebuie să servească cel puțin 500 de solicitări pe oră și să mențină timpul mediu de răspuns de mai puțin de 0,01 secunde.

Pe baza testelor noastre de încărcare și performanță, am aflat că atât timp cât API primește mai puțin de 500 de cereri pe oră, este capabil să mențină SLA pentru un timp mediu de răspuns. Cu toate acestea, dacă primește alte 200 de cereri, atunci timpul mediu de răspuns crește și se atinge punctul de rupere atunci când solicitarea primită depășește 1200 pe oră.

De obicei, se vede că în timpul fazelor inițiale de proiectare, accentul este adesea pus pe aspectele funcționale ale API-ului. Odată cu trecerea timpului, un produs începe să susțină mai mulți clienți live, atunci când testarea pentru performanța API și testarea încărcării intră în imagine într-o manieră mai obișnuită.

(iii) Testarea securității

Interfețele de programare a aplicațiilor sau API-urile sunt vulnerabile și sunt cel mai ușor punct de acces pentru hackerii rău intenționați care doresc acces la date sau obțin controlul unei aplicații.

c ++ funcții încorporate

Acest lucru poate duce orice companie în probleme legale, în cazul în care, din cauza unei încălcări de securitate, persoane și / sau organizații neintenționate pot accesa datele clientului printr-un venerabil API.

Testarea securității este o ramură specializată a testării și ar trebui tratată de specialiști. Resursele de testare a securității pot fi din interiorul organizației sau consultanți independenți.

Citiți și = >> Ce este testarea contractului de pact

Cum să introduceți testarea API în organizația dvs.

Procesul de introducere a testării API în orice organizație este similar cu procesul utilizat pentru implementarea sau implementarea oricărui alt instrument și cadru de testare.

Tabelul de mai jos rezumă pașii principali împreună cu rezultatul așteptat al fiecărui pas.

Provocări comune și modalități de a le atenua

Să discutăm câteva dintre provocările comune cu care se confruntă echipele de asigurare a calității în timp ce încearcă să implementeze un cadru de testare API într-o organizație.

# 1) Alegerea instrumentului potrivit

Alegerea instrumentului corect pentru job este cea mai frecventă provocare. Există mai multe instrumente de testare API care sunt disponibile pe piață.

Poate părea foarte atrăgător să implementăm cel mai recent și cel mai scump instrument disponibil pe piață - dar dacă nu aduce rezultatele dorite, atunci acel instrument nu este de nici un folos.

Prin urmare, alegeți întotdeauna instrumentul care răspunde cerințelor „obligatorii” pe baza nevoilor dvs. organizaționale.

Iată un exemplu de matrice de evaluare a instrumentelor pentru Instrumentele API disponibile

# 2) Specificațiile testului lipsesc

În calitate de testeri, trebuie să cunoaștem rezultatele așteptate pentru a testa eficient o aplicație. Aceasta este adesea o provocare, deoarece pentru a cunoaște rezultatele așteptate, trebuie să avem cerințe precise clare - ceea ce nu este cazul.

De exemplu , luați în considerare cerințele furnizate mai jos:

„Aplicația trebuie să accepte doar o dată validă de expediere și toate cerințele nevalide ar trebui respinse”

Aceste cerințe lipsesc detaliile cheie și sunt foarte ambigue - cum definim o dată validă? Dar formatul? Retrimitem vreun mesaj de respingere utilizatorului final etc.?

Exemplu de cerințe clare:

1) Aplicația trebuie să accepte doar o dată validă de expediere.

Data de expediere este considerată valabilă dacă este

• Nu în trecut
• Mai mare sau egal cu data de astăzi
• Este într-un format acceptabil: ZZ / LL / AAAA

Două)

Cod de stare de răspuns = 200
Mesaj: OK

3) Data de expediere care nu îndeplinește criteriile de mai sus trebuie considerată nevalidă. Dacă un client trimite o dată de expediere nevalidă, atunci acesta trebuie să răspundă cu următoarele mesaje de eroare:

3.1

Cod de stare de răspuns NU 200
Eroare: Data de livrare furnizată este nevalidă; vă rugăm să vă asigurați că data este în format ZZ / LL / AAAA

3.2

Cod de stare de răspuns NU 200
Eroare: data de livrare prevăzută este în trecut

# 3) Curba de învățare

După cum sa menționat anterior, abordarea pentru testarea API este diferită în comparație cu abordarea urmată în timpul testării aplicațiilor bazate pe GUI.

Dacă angajați specialiști interni sau consultanți pentru testarea API, atunci curba de învățare a abordării de testare API sau a instrumentului de testare API poate fi minimă. Orice curbă de învățare, în acest caz, ar fi asociată cu dobândirea cunoștințelor despre produs sau aplicație.

Dacă un membru al echipei existent este desemnat să învețe testarea API, atunci în funcție de instrumentul ales, curba de învățare poate fi medie spre înaltă, împreună cu schimbarea abordării de testare. Curba de învățare pentru produsul sau aplicația în sine poate fi scăzută-medie, în funcție de faptul dacă acest tester a testat anterior aplicația respectivă sau nu.

# 4) Set de abilități existente

Acest lucru se leagă direct de punctul anterior despre curba de învățare.

Dacă un tester trecea de la testarea bazată pe GUI, atunci testerul ar trebui să schimbe abordarea de testare și să învețe noul instrument sau cadru, după cum este necesar. De exemplu. Dacă API acceptă solicitările în format JSON, atunci testerul ar trebui să afle ce este JSON, pentru a începe să creeze testele.

Studiu de caz

Sarcină

Pentru a extinde o aplicație existentă, o companie a dorit să ofere un produs în API, precum și o aplicație standard GUI. Echipa QA a fost rugată să furnizeze un plan de acoperire a testelor pentru a se asigura că este gata să accepte testarea API dincolo de testele obișnuite bazate pe GUI.

Provocări

• Niciunul dintre celelalte produse software nu avea arhitectură bazată pe API, prin urmare, pentru a găzdui testarea în jurul acestei sarcini, echipa trebuie să stabilească procesul de testare API de la zero. Aceasta înseamnă că instrumentele trebuiau evaluate, selectate, finalizate și echipa trebuia instruită pentru teste.
• Nu a existat un buget suplimentar alocat pentru achiziționarea și implementarea instrumentului. Aceasta înseamnă că echipa a trebuit să aleagă un instrument de testare API gratuit sau open-source și cineva din echipa existentă a trebuit să fie instruit pentru a prelua această sarcină.
• Nu au existat cerințe pentru câmpurile API și validarea datelor. Cerințele „ar trebui să funcționeze la fel ca aplicația GUI corespunzătoare”.

Abordarea urmată de echipă pentru a atenua riscurile și pentru a rezolva provocările

• Echipa QA a lucrat cu echipa de proiect pentru a identifica următoarele cerințe:
  • Tipul API (REST / SOAP): ODIHNĂ
  • Teste necesare (funcțional, încărcare, securitate): Numai testarea funcțională
  • Sunt necesare teste automate (da / nu): Opțional pentru moment
  • Rapoarte de testare (Da / Nu): Necesar
• Echipa QA a făcut evaluarea instrumentelor disponibile Instrumente de testare API pe baza cerințelor obligatorii. Instrumentul API Postman a fost finalizat ca un instrument la alegere, deoarece era gratuit și ușor de utilizat, minimizând astfel curba de învățare, având potențialul de a automatiza testele și a venit cu rapoarte încorporate bune.
• Același tester care a testat aplicația a fost instruit pentru utilizarea Postman pentru a crea teste inițiale, eliminând astfel orice lacune de cunoștințe despre produs.
• Pentru a face față cerințelor lipsă, echipa de proiect a construit documentația la nivel înalt de teren folosind Swagger. Cu toate acestea, acest lucru a lăsat unele lacune în ceea ce privește formatele de date acceptabile și acest lucru a fost luat în considerare de echipa de proiect, iar formatele așteptate au fost convenite și documentate.

Concluzie

Aplicațiile bazate pe API au câștigat popularitate în ultima vreme. Aceste aplicații sunt mai scalabile în comparație cu aplicațiile / software-ul tradițional și permit integrarea mai ușoară cu celelalte API-uri sau aplicații.

Acest tutorial de testare API a explicat în detaliu totul despre testarea API, testarea Shift la stânga, serviciile web și API-ul web. De asemenea, am explorat diferențele dintre serviciile web și API-ul web cu exemple.

În a doua parte a tutorialului, am discutat despre spectrul complet de testare API, despre cum să introduceți testarea API în organizația dvs. și despre câteva provocări comune în acest proces, împreună cu soluții pentru acestea.

Consultați următorul nostru tutorial pentru a afla mai multe despre serviciile web împreună cu exemple !!

NEXT Tutorial

Lectură recomandată

• Testarea alfa și testarea beta (un ghid complet)
• Testarea funcțională Vs testarea nefuncțională
• Tutorial de testare a utilizabilității: un ghid complet de inițiere
• Test de verificare a construcției (testare BVT) Ghid complet
• Tutorial DevOps Testing: Cum va afecta DevOps testarea QA?
• Tutorial de testare a accesibilității (un ghid complet pas cu pas)
• Cele mai bune instrumente de testare software 2021 (Instrumente de automatizare a testelor de calitate)
• Ce este testarea software-ului? 100+ Tutoriale gratuite de testare manuală