- Listă de tutoriale de testare API
- Prezentare generală a tutorialelor din această serie de testare API
- Tutorial de testare API
- Introducerea testării API în organizația dvs.
- Concluzie
Acest tutorial aprofundat de testare API explică totul despre testarea API, serviciile web și cum să introduceți testarea API în organizația dumneavoastră:
Obțineți o perspectivă profundă asupra testării API, împreună cu conceptul de testare shift-left și servicii web din acest tutorial introductiv.
Concepte precum API Web, cum funcționează API-ul (cu exemple din lumea reală) și care este diferența față de serviciile Web sunt bine explicate cu exemple în acest tutorial.
Listă de tutoriale de testare API
Tutorial #1: Tutorial de testare API: Un ghid complet pentru începători
Tutorial #2: Tutorial Servicii Web: Componente, Arhitectură, Tipuri & Exemple
Tutorial #3: Top 35 ASP.Net și Web API Întrebări de interviu cu răspunsuri
Tutorial #4: Tutorial POSTMAN: Testarea API folosind POSTMAN
Tutorial #5: Testarea serviciilor web utilizând Apache HTTP Client
Prezentare generală a tutorialelor din această serie de testare API
Tutorial # | Ce veți învăța |
---|---|
Tutorial_#1: | Tutorial de testare API: Un ghid complet pentru începători Acest tutorial aprofundat de testare API va explica totul despre testarea API și serviciile web în detaliu și, de asemenea, vă va învăța cum să introduceți testarea API în organizația dumneavoastră. |
Tutorial_#2: | Tutorial Servicii Web: Componente, Arhitectură, Tipuri & Exemple Acest tutorial despre serviciile web explică arhitectura, tipurile și componentele serviciilor web, împreună cu terminologiile importante și diferențele dintre SOAP și REST. |
Tutorial_#3: | Top 35 ASP.Net și Web API Întrebări de interviu cu răspunsuri Puteți explora lista celor mai populare întrebări de interviu ASP.Net și Web API cu răspunsuri & exemple pentru începători și profesioniști cu experiență în acest tutorial. |
Tutorial_#4: | Tutorial POSTMAN: Testarea API folosind POSTMAN Acest tutorial pas cu pas va explica testarea API folosind POSTMAN, împreună cu elementele de bază ale POSTMAN, componentele sale și exemple de cerere și răspuns în termeni simpli pentru o înțelegere ușoară. |
Tutorial_#5: | Testarea serviciilor web utilizând Apache HTTP Client Acest tutorial API este despre efectuarea diferitelor operații CRUD pe serviciile web și testarea serviciilor web utilizând Apache HTTP Client. |
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-urilor Web, care, la rândul său, vă va fi de ajutor în înțelegerea conceptelor majore din următoarele tutoriale din această serie de teste API.
API (Application Programming Interface) este un set de toate procedurile și funcțiile care ne permit să creăm o aplicație prin accesarea datelor sau a funcțiilor sistemului de operare sau ale platformelor. Testarea acestor proceduri este cunoscută sub numele de testare API.
Testul Shift Left
Unul dintre tipurile importante de testare care se cere în zilele noastre în interviurile de testare API este testarea Shift Left Testing. Acest tip de testare este practicat în aproape toate proiectele care urmează o metodologie Agile.
Înainte de introducerea Shift Left Testing, testarea software-ului apărea doar după ce codificarea era completă și codul era livrat testeriștilor. Această practică a dus la o grabă de ultim moment pentru a respecta termenul limită și a împiedicat în mare măsură calitatea produsului.
În afară de aceasta, eforturile depuse (atunci când defectele erau raportate în ultima fază înainte de producție) erau uriașe, deoarece dezvoltatorii trebuiau să parcurgă din nou atât faza de proiectare, cât și cea de codare.
Ciclul de viață al dezvoltării de software (SDLC) Înainte de schimbarea la stânga Testare
Fluxul tradițional SDLC a fost: Cerință -> Proiectare -> Codificare -> Testare.
Dezavantajele testării tradiționale
- Testarea este la extrema dreaptă. Multe costuri sunt suportate atunci când un bug este identificat în ultimul moment.
- Timpul consumat pentru rezolvarea erorilor și retestarea acestora înainte de a le promova în producție este imens.
Prin urmare, a apărut o nouă idee, aceea de a muta faza de testare spre stânga, ceea ce a dus la Shift Left Testing.
Sugestii de lectură => Testarea Shift Left: O mantră secretă pentru succesul software-ului
Fazele de testare a schimbului de stânga
Testarea de tip Left Shift a dus la o migrare de succes de la detectarea defectelor la prevenirea defectelor. De asemenea, a ajutat software-ul să eșueze rapid și să remedieze toate defectele cât mai devreme.
API web
În termeni generali, un API web poate fi definit ca fiind ceva care preia 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 faceț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 afișa 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țurile, disponibilitatea etc. a diferitelor hoteluri dintr-un anumit oraș. Acest site comunică cu API-urile mai multor hoteluri pentru a accesa baza de date și listează prețurile și disponibilitatea de pe site-ul acestora.
Astfel, un API web poate fi definit ca fiind "o interfață care facilitează comunicarea între un client și serverul web".
Servicii Web
Serviciile web sunt (ca și API-urile web) servicii care servesc de la o mașină la alta, dar diferența majoră între API și serviciile web este că serviciile web utilizează o rețea.
Se poate spune că toate serviciile Web sunt API-uri Web, dar nu toate API-urile Web sunt servicii Web (explicate în ultima parte a articolului). Astfel, serviciile Web sunt un subset al API-urilor Web. Consultați diagrama de mai jos pentru a afla mai multe despre API-urile Web și serviciile Web.
API web vs Servicii web
Servicii Web vs API Web
Atât Web API, cât și serviciile web sunt utilizate pentru a facilita comunicarea dintre client și server. Diferența majoră constă doar în modul în care comunică.
Fiecare dintre ele necesită un corp al cererii acceptabil într-o anumită limbă, diferențele dintre ele în ceea ce privește asigurarea unei conexiuni sigure, viteza de comunicare cu serverul și de răspuns către client etc.
Diferențele dintre serviciile web și API-ul web sunt enumerate 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 oferă SSL (Secure Socket Layer) în timpul transmiterii datelor, dar oferă și WSS (Web Services Security).
- Serviciul web este un subset al API-ului web. De exemplu, Serviciile Web se bazează doar pe trei stiluri de utilizare, și anume. SOAP, REST și XML-RPC.
- Serviciile web au întotdeauna nevoie de o rețea pentru a funcționa.
- Serviciile web acceptă "un singur cod pentru aplicații diferite", ceea ce înseamnă că se scrie un cod mai generic pentru diferite aplicații.
API web
- Un API web utilizează î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 un superset al serviciilor web. De exemplu, Toate cele trei stiluri de servicii web sunt prezente și în API-ul web, dar, în afară de acestea, se folosesc și 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ă susțină interoperabilitatea în funcție de natura sistemului sau a aplicației.
Introducerea testării API în organizația dvs.
În viața noastră de zi cu zi, suntem cu toții atât de obișnuiți să interacționăm cu aplicațiile prin intermediul API-urilor, dar nici măcar nu ne gândim la procesele back-end care determină funcționalitatea de bază.
De exemplu, Să ne gândim că navigați printre produsele de pe Amazon.com și vedeți un produs/ofertă care vă place foarte mult și doriți să îl distribuiți rețelei dvs. de Facebook.
În momentul în care faceți clic pe pictograma Facebook din secțiunea de partajare a paginii și introduceți datele de identificare ale contului dumneavoastră de Facebook pentru a partaja, interacționați cu un API care conectează în mod transparent site-ul Amazon cu Facebook.
Schimbarea accentului către testarea API
Înainte de a discuta mai mult 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, iar câteva dintre ele sunt enumerate 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 aceeași API poate servi mai multe cereri fără modificări majore de cod sau de infrastructură.
#2) Echipele de dezvoltare nu trebuie să înceapă să codifice de la zero de fiecare dată când încep să lucreze la dezvoltarea unei funcții sau aplicații. API-urile reutilizează cel mai adesea funcții, biblioteci, proceduri stocate etc. existente și repetabile și, prin urmare, acest proces le poate face mai productive în general.
De exemplu, Dacă sunteți un dezvoltator care lucrează la un site de comerț electronic și doriți să adăugați Amazon ca procesor de plăți, 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 chei de integrare și să apelați Amazon API pentru procesarea plăților în timpul plății.
#3) API-urile permit o integrare ușoară cu alte sisteme, atât pentru aplicațiile autonome acceptate, cât și pentru produsele software bazate pe API.
De exemplu Să considerăm că doriți să trimiteți un transport din Toronto la New York, intrați pe internet, navigați pe un site bine cunoscut de transport de marfă sau de logistică și introduceți informațiile necesare.
După ce furnizați informațiile obligatorii, când faceți clic pe butonul "Obțineți tarifele" - în partea din spate, acest site web de logistică se poate conecta cu mai mulți furnizori de transport și de servicii API și aplicații pentru a obține tarifele dinamice pentru combinația de locații de la origine la destinație.
Spectrul complet de testare API
Testarea API-urilor nu se limitează doar la trimiterea unei cereri către API și analizarea răspunsului pentru corectitudine. API-urile trebuie să fie testate pentru performanța lor sub diferite sarcini pentru a detecta vulnerabilitățile.
Să discutăm acest lucru în detaliu.
(i) Testarea funcțională
Testarea funcțională poate fi o sarcină dificilă din cauza lipsei unei interfețe GUI.
Să vedem cum diferă abordarea testării funcționale pentru API-uri față de cea a aplicațiilor bazate pe GUI și vom discuta și câteva exemple în acest sens.
a) Cea mai evidentă diferență este că nu există o interfață grafică cu care să interacționeze. Testerii care fac de obicei teste funcționale bazate pe interfață grafică consideră că este puțin mai greu să treacă la testarea aplicațiilor fără interfață grafică, în comparație cu cineva care este deja familiarizat cu aceasta.
Inițial, chiar înainte de a începe să testați API-ul, va trebui să testați și să verificați procesul de autentificare în sine. Metoda de autentificare va varia de la un API la altul și va implica un fel de cheie sau token pentru autentificare.
În cazul în care nu vă puteți conecta cu succes la API, nu puteți continua testarea. Acest proces poate fi considerat comparabil cu autentificarea utilizatorului în aplicațiile standard, unde aveți nevoie de acreditări valide pentru a vă conecta și a utiliza aplicația.
b) Testarea validărilor de câmp sau a validării datelor de intrare este foarte importantă în timpul testării API-urilor. Dacă ar fi disponibilă o interfață reală 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ă utilizatorului nu i se permite să introducă valori de câmp invalide.
De exemplu, Dacă o aplicație are nevoie ca formatul datei să fie DD/MM/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ă.
Trebuie să ne asigurăm că API-ul este bine scris și este capabil să aplice toate aceste validări, să facă distincția între datele valide și cele invalide și să returneze codul de stare și mesajul de eroare de validare utilizatorului final printr-un răspuns.
c) Testarea corectitudinii răspunsurilor de la API pentru răspunsuri valide și invalide este într-adevăr crucială. Dacă se primește un cod de stare 200 (ceea ce înseamnă că totul este în regulă) ca răspuns de la API de testare, dar dacă textul de răspuns spune că a fost întâlnită o eroare, atunci acesta este un defect.
În plus, dacă mesajul de eroare în sine este incorect, atunci 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 o greutate invalidă, care este mai mare decât greutatea acceptabilă de 2267 kg. API răspunde cu codul de stare de eroare și mesajul de eroare. Cu toate acestea, mesajul de eroare menționează în mod incorect unitățile de greutate ca fiind lbs în loc de KG. Acesta este un defect care poate deruta clientul final.
(ii) Testarea sarcinii și a performanței
API-urile sunt concepute pentru a fi scalabile.
Acest lucru, la rândul său, face ca testele de încărcare și de performanță să fie esențiale, mai ales dacă se așteaptă ca sistemul proiectat să deservească mii de solicitări pe minut sau pe oră, în funcție de cerințe. Efectuarea în mod regulat a testelor de încărcare și de performanță pe API poate ajuta la evaluarea comparativă a performanței, a vârfurilor de sarcină și a punctului de rupere.
Aceste date sunt utile atunci când se planifică extinderea unei aplicații. Disponibilitatea acestor informații va ajuta la sprijinirea deciziilor și a planificării, în special dacă organizația intenționează să adauge mai mulți clienți, ceea ce ar însemna mai multe cereri primite.
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 lansarea oricărui alt instrument și cadru de testare.
Tabelul de mai jos rezumă principalele etape, împreună cu rezultatul așteptat pentru fiecare etapă.
Faza | Pasul | Rezultatul așteptat |
---|---|---|
Selecția instrumentelor | Colectarea cerințelor și identificarea constrângerilor | Înțelegerea cerințelor de cercetare a pieței pentru un instrument de testare API adecvat. De exemplu. Ce fel de API este testat - SOAP sau REST? Trebuie să angajăm un tester pentru acest rol sau să instruim testerul existent? Ce fel de teste vor fi efectuate - teste funcționale, teste de performanță etc. Care este bugetul pentru punerea în aplicare? |
Evaluați instrumentele disponibile | Comparați instrumentele disponibile și alegeți 1 sau 2 instrumente care îndeplinesc cel mai bine cerințele. | |
Dovada conceptului | Puneți în aplicare un subset de teste cu ajutorul instrumentului preselectat. Prezentarea constatărilor părților interesate. Finalizarea instrumentului care urmează să fie implementat. | |
Implementare | Noțiuni introductive | În funcție de instrumentul ales, va trebui să instalați instrumentul necesar pe un PC, o mașină virtuală sau un server. Dacă instrumentul ales este bazat pe abonament, creați conturile de echipă necesare. Formarea echipei, dacă este necesar. |
Pleacă | Creați teste Executarea testelor Raportați defectele |
Provocări comune și modalități de atenuare a acestora
Să discutăm câteva dintre provocările comune cu care se confruntă echipele de asigurare a calității atunci când încearcă să implementeze un cadru de testare API într-o organizație.
#1) Alegerea instrumentului potrivit
Selectarea instrumentului corect pentru această sarcină este cea mai frecventă provocare. Există mai multe instrumente de testare API disponibile pe piață.
Poate părea foarte atrăgător să implementezi cel mai nou și 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" în funcție de nevoile organizației dumneavoastră.
Iată un exemplu de matrice de evaluare a instrumentelor pentru instrumentele API disponibile
Instrument | Stabilirea prețurilor | Note |
---|---|---|
UI de săpun | Versiune gratuită disponibilă pentru SoapUI Open Source (Testare funcțională) | * REST, SOAP și alte protocoale API și IoT populare. * Inclus în versiunea gratuită Teste ad-hoc SOAP și REST Afirmarea mesajului Trageți & Creație de testare Drop Jurnalele de testare Configurația de testare Test din înregistrări Unitatea de raportare. * Lista completă a caracteristicilor poate fi găsită pe site-ul lor. |
Poștașul | Aplicație gratuită Postman disponibilă | * Cel mai utilizat pentru REST. * Caracteristicile pot fi găsite pe site-ul lor. |
Parasoft | Este un instrument plătit, necesită achiziționarea unei licențe și apoi instalarea înainte de a putea fi utilizat. | * Testarea completă a API-urilor: teste funcționale, de încărcare, de securitate, gestionarea datelor de testare |
vREST | Pe baza numărului de utilizatori | * Testarea automatizată a API-urilor REST. * Înregistrare și reluare. * Îndepărtează dependența de frontend și backend folosind API-uri simulate. * Validare puternică a răspunsului. * Funcționează pentru aplicațiile de testare implementate pe localhost/intranet/internet. * Integrare JIRA, Integrare Jenkins Importuri din Swagger, Postman. |
HttpMaster | Express Edition: Descărcare gratuită Versiunea profesională: Pe baza numărului de utilizatori | * Ajută la testarea site-urilor web, precum și la testarea API. * Alte caracteristici includ capacitatea de a defini parametri globali, oferă utilizatorului posibilitatea de a crea verificări pentru validarea răspunsurilor la date prin utilizarea setului mare de tipuri de validare pe care le acceptă. |
Runscope | În funcție de numărul de utilizatori și de tipurile de planuri | * Pentru monitorizarea și testarea API-urilor. * Poate fi utilizat pentru validarea datelor pentru a se asigura că sunt returnate date corecte. * Conține o funcție de urmărire și notificare în cazul în care orice tranzacție API eșuează (dacă aplicația dvs. necesită validarea plății, atunci acest instrument se poate dovedi a fi o alegere bună). |
LoadFocus | În funcție de numărul de utilizatori și de tipurile de planuri | * Poate fi folosit pentru testarea încărcării API - permite rularea câtorva teste pentru a afla numărul de utilizatori pe care îl poate suporta un API. * Simplu de utilizat - permite rularea testelor în browser. |
PingAPI | Gratuit pentru 1 proiect (1.000 de cereri) | * Benefic pentru testarea și monitorizarea automatizată a API-urilor. |
#2) Lipsa specificațiilor de testare
În calitate de testeri, trebuie să cunoaștem rezultatele așteptate pentru a testa în mod eficient o aplicație. Acest lucru reprezintă adesea o provocare, deoarece pentru a cunoaște rezultatele așteptate, trebuie să avem cerințe clare și precise - ceea ce nu este cazul.
De exemplu , luați în considerare cerințele furnizate mai jos:
"Aplicația ar trebui să accepte doar o dată de expediere validă și toate cerințele nevalabile ar trebui să fie respinse"
Din aceste cerințe lipsesc detalii cheie și sunt foarte ambigue - cum definim o dată validă? Cum rămâne cu formatul? Trimitem vreun mesaj de respingere utilizatorului final etc.?
Exemplu de cerințe clare:
1) Aplicația ar trebui să accepte doar o dată de expediere valabilă.
Data de expediere este considerată valabilă dacă este
- Nu în trecut
- Mai mare sau egală cu data de astăzi
- Este în format acceptabil: DD/MM/AAAA
2)
Răspuns Cod de stare = 200
Mesaj: OK
3) Data de expediere care nu îndeplinește criteriile de mai sus trebuie să fie considerată invalidă. Dacă un client trimite o dată de expediere invalidă, atunci trebuie să răspundă cu următorul (următoarele) mesaj(e) de eroare:
3.1
Răspuns Cod de stare NOT 200
Eroare: Data de expediere furnizată nu este validă; vă rugăm să vă asigurați că data este în format DD/MM/AAAA
3.2
Răspuns Cod de stare NOT 200
Eroare: Data de expediere furnizată este în trecut
#3) Curba de învățare
După cum s-a menționat anterior, abordarea pentru testarea API este diferită în comparație cu abordarea urmată la testarea aplicațiilor bazate pe GUI.
Dacă angajați specialiști, fie interni, fie 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.
În cazul în care un membru existent al echipei este desemnat să învețe testarea API, atunci, în funcție de instrumentul ales, curba de învățare poate fi medie spre mare, împreună cu schimbarea abordării de testare. Curba de învățare pentru produsul sau aplicația în sine poate fi scăzută-mediană, în funcție de faptul dacă acest tester a testat sau nu aplicația respectivă înainte.
#4) Setul de competențe existent
Acest lucru se leagă direct de punctul anterior referitor la curba de învățare.
În cazul în care un tester trece de la testarea bazată pe GUI, atunci acesta va 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 trebuie să învețe 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 GUI standard. Echipei de asigurare a calității i s-a cerut să furnizeze un plan de acoperire a testelor pentru a se asigura că este pregătită să se adapteze la testele API în afară de testele obișnuite bazate pe GUI.
Provocări
- Niciunul dintre celelalte produse software nu avea o arhitectură bazată pe API, prin urmare, pentru a adapta testarea la această sarcină, 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, ceea ce înseamnă că echipa a trebuit să aleagă un instrument de testare a API-urilor gratuit sau open-source și că 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 au fost "ar trebui să funcționeze la fel ca aplicația GUI corespunzătoare".
Abordarea urmată de echipă pentru a atenua riscurile și pentru a soluționa provocările.
- Echipa QA a lucrat cu echipa de proiect pentru a identifica următoarele cerințe:
- Tipul de API (REST/SOAP ): REST
- Testele necesare (funcționale, de încărcare, de securitate): Numai testarea funcțională
- Sunt necesare teste automatizate (Da/Nu): Opțional pentru moment
- Rapoarte de testare (Da/Nu): Necesar
- Echipa QA a făcut o evaluare a instrumentelor de testare API disponibile, pe baza cerințelor obligatorii. Instrumentul API Postman a fost finalizat ca fiind instrumentul ales, deoarece era gratuit și ușor de utilizat, minimizând astfel curba de învățare, și avea potențialul de a automatiza testele și a venit cu rapoarte bune încorporate.
- Același tester care a testat aplicația a fost instruit pentru a utiliza Postman pentru a crea testele inițiale, eliminând astfel orice lacună de cunoaștere a produsului.
- Pentru a face față cerințelor lipsă, echipa de proiect a construit documentația de nivel înalt la nivel de câmp folosind Swagger. Totuși, acest lucru a lăsat unele lacune în ceea ce privește formatele de date acceptabile, iar acest aspect a fost abordat cu echipa de proiect și 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-urile tradiționale și permit o integrare mai ușoară cu alte API-uri sau aplicații.
Acest tutorial de testare API a explicat totul despre testarea API, testarea Shift Left, serviciile web și API web în detaliu. De asemenea, am explorat diferențele dintre serviciile web și API web cu exemple.
În a doua parte a tutorialului, am discutat despre întregul spectru al testării API, despre cum să introduceți testarea API în organizația dumneavoastră și despre unele 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!!!
Următorul tutorial