Tutorial de proves API: una guia completa per a principiants

api testing tutorial

Aquest tutorial de proves d'API en profunditat explica tot sobre les proves d'API, els serveis web i com introduir les proves d'API a la vostra organització:

Obteniu una visió profunda de les proves API juntament amb el concepte de proves de desplaçament cap a l’esquerra i serveis web d’aquest tutorial introductori.

Conceptes com l'API web, el funcionament de l'API (amb exemples del món real) i la diferència dels serveis web s'expliquen bé amb exemples en aquest tutorial.

=>DESPLAÇA CAP AVALLper veure la llista completa de 5 tutorials de proves API en profunditat per a principiants

Què aprendreu:

• Llista de tutorials de proves API
• Visió general dels tutorials d'aquesta sèrie de proves de l'API
• Tutorial de proves API
  • Prova de desplaçament cap a l'esquerra
  • Cicle de vida del desenvolupament de programari (SDLC) abans de la prova de desplaçament cap a l'esquerra
  • Fases de la prova de desplaçament a l'esquerra
  • API web
  • Com funciona una API?
  • Serveis web
  • Serveis web vs API web
• Presentació de les proves API a la vostra organització
  • Focus de canvi a la prova d'API
  • Espectre complet de proves API
    • (i) Proves funcionals
    • (ii) Proves de càrrega i rendiment
    • (iii) Proves de seguretat
  • Com introduir les proves API a la vostra organització
  • Desafiaments comuns i maneres de mitigar-los
    • # 1) Escollir l'eina adequada
    • # 2) Falten les especificacions de la prova
    • # 3) Corba d'aprenentatge
    • # 4) Conjunt d’habilitats existent
  • Cas pràctic
• Conclusió
  • Lectura recomanada

Llista de tutorials de proves API

Tutorial # 1: Tutorial de proves API: una guia completa per a principiants
Tutorial # 2: Tutorial de serveis web: components, arquitectura, tipus i exemples
Tutorial # 3: Top 35 de les preguntes d'entrevistes d'API ASP.Net i web amb respostes
Tutorial # 4: Tutorial POSTMAN: proves d'API mitjançant POSTMAN
Tutorial # 5: Proves de serveis web mitjançant client HTTP Apache

Visió general dels tutorials d'aquesta sèrie de proves de l'API

Tutorial de proves API

Aquesta secció us ajudarà a obtenir una comprensió bàsica dels serveis web i de l'API web, que, al seu torn, us serà útil per comprendre els conceptes principals dels propers tutorials d'aquesta sèrie de proves d'API.

L’API (Application Programming Interface) és un conjunt de tots els procediments i funcions que ens permeten crear una aplicació accedint a les dades o funcions del sistema operatiu o plataformes. La prova d’aquests procediments es coneix com a prova API.

Prova de desplaçament cap a l'esquerra

Un dels tipus importants de proves que es fan avui en dia a les entrevistes de proves API és la prova de desplaçament a l’esquerra. Aquest tipus de proves es practiquen en gairebé tots els projectes que segueixen una metodologia àgil.

Abans d’introduir la prova de desplaçament cap a l’esquerra, les proves de programari només apareixien quan la codificació s’havia completat i el codi es lliurava als verificadors. Aquesta pràctica va conduir a la pressa d’última hora a complir el termini i també va dificultar en gran mesura la qualitat del producte.

A part d'això, els esforços realitzats (quan es van informar de defectes a l'última fase abans de la producció) van ser enormes, ja que els desenvolupadors van haver de tornar a passar tant pel disseny com per la codificació.

Cicle de vida del desenvolupament de programari (SDLC) abans de la prova de desplaçament cap a l'esquerra

El flux SDLC tradicional era: Requisit -> Disseny -> Codificació -> Proves.

Inconvenients de les proves tradicionals

• Les proves són a l’extrema dreta. Es produeixen molts costos quan s’identifica un error a l’últim moment.
• El temps consumit en resoldre l’error i tornar-lo a provar abans de promocionar-lo a la producció és enorme.

Per tant, va aparèixer una nova idea per desplaçar la fase de proves cap a l'esquerra, cosa que va conduir a la prova de desplaçament cap a l'esquerra.

Lectura suggerida => Prova de desplaçament cap a l'esquerra: un mantra secret per a l'èxit del programari

Fases de la prova de desplaçament a l'esquerra

Les proves de desplaçament a l'esquerra van provocar una migració amb èxit de la detecció de defectes a la prevenció de defectes. També va ajudar al programari a fallar ràpidament i solucionar tots els errors com més aviat millor.

API web

En termes generals, una API web es pot definir com una cosa que transmet la sol·licitud d'un sistema client a un servidor web i envia la resposta d'un servidor web a una màquina client.

Com funciona una API?

Prenem un escenari molt comú de reservar un vol a www.makemytrip.com, que és un servei de viatges en línia que agrupa informació de diverses companyies aèries. Quan opteu per fer una reserva de vol, introduïu informació com la data del viatge / data de retorn, classe, etc. i feu clic a Cerca.

Això us mostrarà el preu de diverses companyies aèries i la seva disponibilitat. En aquest cas, l’aplicació interactua amb API de diverses línies aèries i, per tant, dóna accés a les dades de la companyia aèria.

Un altre exemple és www.trivago.com que compara i enumera el preu, la disponibilitat, etc. de diferents hotels d’una ciutat concreta. Aquest lloc web es comunica amb les API de diversos hotels per accedir a la base de dades i enumera els preus i la disponibilitat del seu lloc web.

Per tant, una API web es pot definir com 'una interfície que facilita la comunicació entre una màquina client i el servidor web'.

Serveis web

Els serveis web són (com ara l'API web) els serveis que serveixen d'una màquina a una altra. Però la principal diferència que sorgeix entre l'API i els serveis web és que els serveis web utilitzen una xarxa.

És segur dir que tots els serveis web són API web, però totes les API web no són serveis web (s’explica a la darrera part de l’article). Per tant, els serveis web són un subconjunt de l'API web. Consulteu el diagrama següent per obtenir més informació sobre l'API web i els serveis web.

API web vs serveis web

Serveis web vs API web

Tant l'API web com els serveis web s'utilitzen per facilitar la comunicació entre el client i el servidor. La diferència principal només ve en la manera de comunicar-se.

Cadascun d’ells requereix un cos de sol·licitud que sigui acceptable en un idioma específic, les seves diferències en proporcionar una connexió segura, la seva rapidesa de comunicació al servidor i resposta al client, etc.

A continuació es detallen les diferències entre els serveis web i l'API web com a referència.

Servei web

• Els serveis web utilitzen generalment XML (Extensible Markup Language), cosa que significa que són més segurs.
• Els serveis web són més segurs, ja que tant els serveis web com les API proporcionen SSL (Secure Socket Layer) durant la transmissió de dades, però també proporciona WSS (Web Services Security).
• El servei web és un subconjunt de l'API web. Per exemple, Els serveis web es basen només en tres estils d’ús, és a dir, SOAP, REST i XML-RPC.
• Els serveis web sempre necessiten una xarxa per funcionar.
• Els serveis web admeten 'Un codi diferent d'aplicacions'. Això significa que s’escriu un codi més genèric en diferents aplicacions.

API web

• Una API web utilitza generalment JSON (JavaScript Object Notation), el que significa que l’API web és més ràpida.
• L'API web és més ràpida, ja que JSON és lleuger, a diferència de XML.
• Les API web són el superconjunt de serveis web. Per exemple, Els tres estils de serveis web també estan presents a l'API web, però a part d'això, utilitza altres estils com JSON-RPC.
• L'API web no necessàriament requereix una xarxa per funcionar.
• L'API web pot o no admetre la interoperabilitat en funció de la naturalesa del sistema o de l'aplicació.

Presentació de les proves API a la vostra organització

En el nostre dia a dia, tots estem tan acostumats a interactuar amb les aplicacions amb les API i, tanmateix, ni tan sols pensem en els processos de fons que impulsen la funcionalitat subjacent.

Per exemple, Tingueu en compte que esteu navegant pels productes a Amazon.com i que veieu un producte / oferta que us agrada i que voleu compartir amb la vostra xarxa de Facebook.

En el moment que feu clic a la icona de Facebook a la secció per compartir de la pàgina i introduïu les credencials del vostre compte de Facebook per compartir-les, esteu interactuant amb una API que connecta perfectament el lloc web d’Amazon a Facebook.

Focus de canvi a la prova d'API

Abans de discutir més sobre les proves de l'API, analitzem els motius pels quals les aplicacions basades en l'API han guanyat popularitat en els darrers temps.

Hi ha diverses raons per les quals les organitzacions fan una transició cap a productes i aplicacions basats en API. I pocs d’ells es detallen a continuació com a referència.

# 1) Les aplicacions basades en API són més escalables en comparació amb les aplicacions / programari tradicionals. La velocitat de desenvolupament del codi és més ràpida i la mateixa API pot atendre més sol·licituds sense canvis importants en el codi ni en la infraestructura.

# 2) Els equips de desenvolupament no necessiten començar a codificar des de zero cada vegada que comencen a treballar en el desenvolupament d’una funció o aplicació. Les API reutilitzen sovint funcions repetibles, biblioteques, procediments emmagatzemats, etc., per tant, aquest procés els pot fer més productius en general.

Per exemple, Si sou un desenvolupador que treballa en un lloc web de comerç electrònic i voleu afegir Amazon com a processador de pagaments, no cal que escriviu el codi des de zero.

Tot el que heu de fer és configurar la integració entre el vostre lloc web i l'API d'Amazon mitjançant claus d'integració i trucar a l'API d'Amazon per processar els pagaments durant el pagament.

# 3) Les API permeten una fàcil integració amb els altres sistemes, tant per a aplicacions autònomes compatibles com per a productes de programari basats en API.

Per exemple , Considerem que voleu enviar un enviament de Toronto a Nova York. Aneu en línia, aneu a un lloc web de transport o logística ben conegut i introduïu la informació necessària.

Després d’haver proporcionat la informació obligatòria, quan feu clic al botó Obtén tarifes, a la part posterior, aquest lloc web de logística pot estar connectant-se amb diverses API i aplicacions de proveïdor de serveis i proveïdors de serveis per obtenir les tarifes dinàmiques de la combinació d’ubicacions d’origen a destinació.

Espectre complet de proves API

La prova d'APIs no es limita a enviar una sol·licitud a l'API i analitzar la resposta només per obtenir la correcció. Cal que les API es comprovin el seu rendiment sota diferents càrregues de vulnerabilitats.

Analitzem-ho en detall.

(i) Proves funcionals

Les proves funcionals poden ser una tasca difícil a causa de la manca d'una interfície GUI.

Vegem com enfocament de proves funcionals per a les API és diferent de l’aplicació basada en GUI i també parlarem d’alguns exemples al seu voltant.

a) La diferència més òbvia és que no hi ha cap interfície gràfica amb la qual interactuar. Els provadors que solen fer proves funcionals basades en GUI els costa una mica més passar a proves d’aplicacions que no són GUI en comparació amb algú que ja ho coneix.

Inicialment, fins i tot abans de començar a provar l'API, haureu de provar i verificar el propi procés d'autenticació. El mètode d'autenticació variarà d'una API a una altra API i implicaria algun tipus de clau o testimoni per a l'autenticació.

Si no podeu connectar-vos a l'API correctament, no podreu continuar amb la prova. Aquest procés es pot considerar comparable a l'autenticació d'usuari a les aplicacions estàndard on necessiteu credencials vàlides per iniciar la sessió i utilitzar l'aplicació.

b) La prova de validacions de camp o la validació de dades d’entrada és molt important durant la prova de les API. Si hi hagués una interfície basada en formularis (GUI) real, es podrien implementar validacions de camp a la part frontal o posterior, garantint així que un usuari no pot introduir valors de camp no vàlids.

Per exemple, Si una sol·licitud necessita que el format de data sigui DD / MM / AAAA, podem aplicar aquesta validació al formulari que recopila informació per assegurar-nos que l’aplicació rep i processa una data vàlida.

Això, però, no és el mateix per a les aplicacions API. Hem de garantir que l’API estigui ben escrita i sigui capaç d’aplicar totes aquestes validacions, distingir entre dades vàlides i no vàlides i retornar el codi d’estat i el missatge d’error de validació a l’usuari final mitjançant una resposta.

c) De fet, és crucial provar la correcció de les respostes de l'API per obtenir respostes vàlides i no vàlides. Si es rep un codi d'estat de 200 (que significa que tot està bé) com a resposta de l'API de prova, però si el text de la resposta diu que s'ha produït un error, es tracta d'un defecte.

A més, si el missatge d'error en si és incorrecte, pot resultar molt enganyós per al client final que intenta integrar-se amb aquesta API.

A la captura de pantalla següent, l'usuari ha introduït un pes no vàlid, que supera els 2267 kg acceptables. L'API respon amb el codi d'estat d'error i el missatge d'error. Tanmateix, el missatge d'error esmenta incorrectament les unitats de pes com a lliures en lloc de KG. Es tracta d’un defecte que pot confondre el client final.

(ii) Proves de càrrega i rendiment

Les API estan dissenyades per ser escalables.

Això, al seu torn, fa que Load i Proves de rendiment essencial, sobretot si s’espera que el sistema que es dissenyi atengui milers de sol·licituds per minut o hora, segons el requisit. La realització habitual de proves de càrrega i rendiment a l’API pot ajudar a comparar el rendiment, les càrregues màximes i el punt de ruptura.

Aquestes dades són útils quan es planeja ampliar una aplicació. Tenir aquesta informació disponible ajudarà a donar suport a les decisions i la planificació, especialment si l’organització té previst afegir més clients, cosa que significaria més sol·licituds entrants.

Per exemple , suposem que, segons els requisits proporcionats, sabem que l'API dissenyada ha de donar servei com a mínim a 500 sol·licituds per hora i mantenir el temps de resposta mitjà de menys de 0,01 segons.

Basant-nos en les nostres proves de càrrega i rendiment, hem descobert que, sempre que l’API rebi menys de 500 sol·licituds per hora, és capaç de mantenir l’SLA durant el temps de resposta mitjà. Tot i això, si rep altres 200 sol·licituds, el temps de resposta mitjà augmenta i s’arriba al punt de ruptura quan la sol·licitud entrant supera els 1200 per hora.

el millor netejador de registre gratuït de Windows 8.1

Normalment, es veu que durant les fases inicials de disseny sovint es posa èmfasi en els aspectes funcionals de l'API. A mesura que passa el temps, un producte comença a donar suport a múltiples clients actius, és llavors quan les proves de rendiment de l'API i les proves de càrrega entren a la imatge d'una manera més rutinària.

(iii) Proves de seguretat

Les interfícies o API de programació d’aplicacions són vulnerables i són el punt d’accés més fàcil per als pirates informàtics maliciosos que volen accedir a dades o obtenir el control d’una aplicació.

Això pot provocar problemes legals a qualsevol empresa, en què, a causa d’un incompliment de seguretat, persones o organitzacions no desitjades poden accedir a les dades del client mitjançant una venerable API.

Proves de seguretat és una branca especialitzada en proves i ha de ser manejada per especialistes. Els recursos de proves de seguretat poden provenir de l’organització o de consultors independents.

Llegiu també = >> Què és la prova de contracte de pacte?

Com introduir les proves API a la vostra organització

El procés per introduir proves API a qualsevol organització és similar al procés utilitzat per implementar o implementar qualsevol altra eina i marc de proves.

La taula següent resumeix els passos principals juntament amb el resultat esperat de cada pas.

Desafiaments comuns i maneres de mitigar-los

Parlem d'alguns dels reptes habituals als quals s'enfronten els equips de control de qualitat en intentar implementar un marc de proves API en una organització.

# 1) Escollir l'eina adequada

Seleccionar l'eina correcta per al treball és el repte més comú. Hi ha diverses eines de prova API disponibles al mercat.

Pot semblar molt atractiu implementar l’última eina més cara disponible al mercat, però si no aporta els resultats desitjats, aquesta eina no serveix de res.

Per tant, trieu sempre l'eina que compleixi els requisits 'imprescindibles' en funció de les vostres necessitats organitzatives.

Aquí teniu un exemple de matriu d’avaluació d’eines per a les eines API disponibles

# 2) Falten les especificacions de la prova

Com a provadors, hem de conèixer els resultats esperats per provar eficaçment una aplicació. Sovint és un repte, ja que per conèixer els resultats esperats cal tenir uns requisits precisos clars, cosa que no és així.

Per exemple , tingueu en compte els requisits que es proporcionen a continuació:

'L'aplicació només ha d'acceptar una data d'enviament vàlida i s'han de rebutjar tots els requisits no vàlids'

Falten detalls clau en aquests requisits i són molt ambigus: com definim una data vàlida? Què passa amb el format? Tornarem a l’usuari final algun missatge de rebuig, etc.?

Exemple de requisits clars:

1) L’aplicació només ha d’acceptar una data d’enviament vàlida.

La data d’enviament es considera vàlida si és així

• No en el passat
• Major o igual a la data d’avui
• Té un format acceptable: DD / MM / AAAA

2)

Codi d’estat de resposta = 200
Missatge: D'acord

3) La data d’enviament que no compleixi els criteris anteriors s’ha de considerar invàlida. Si un client envia una data d’enviament no vàlida, ha de respondre amb els missatges d’error següents:

3.1

Codi d’estat de resposta NO 200
Error: la data d’enviament proporcionada no és vàlida; assegureu-vos que la data estigui en format DD / MM / AAAA

3.2

Codi d’estat de resposta NO 200
Error: la data d’enviament proporcionada és anterior

# 3) Corba d'aprenentatge

Com es va esmentar anteriorment, l'enfocament per a la prova de l'API és diferent en comparació amb l'enfocament seguit mentre es provaven les aplicacions basades en GUI.

Si contracteu especialistes interns o consultors per a proves API, la corba d’aprenentatge de l’enfocament de prova API o de l’eina de prova API pot ser mínima. Qualsevol corba d’aprenentatge, en aquest cas, s’associaria a l’adquisició del coneixement del producte o de l’aplicació.

Si un membre de l’equip existent està assignat per aprendre proves d’API, en funció de l’eina escollida, la corba d’aprenentatge pot ser mitjana a alta, juntament amb canviar l’enfocament de la prova. La corba d’aprenentatge del producte o de l’aplicació en si pot ser baixa-mitjana en funció de si aquest provador ha provat aquesta aplicació abans o no.

# 4) Conjunt d’habilitats existent

Això es relaciona directament amb el punt anterior sobre la corba d’aprenentatge.

Si un provador passava de les proves basades en la GUI, el provador hauria de canviar l'enfocament de les proves i aprendre la nova eina o marc segons sigui necessari. Per exemple. Si l'API accepta les sol·licituds en format JSON, el provador hauria d'aprendre què és JSON per començar a crear les proves.

Cas pràctic

Tasca

Per tal d’ampliar una aplicació existent, una empresa volia oferir un producte en API, així com una aplicació estàndard de GUI. Es va demanar a l'equip de control de qualitat que proporcionés un pla de cobertura de proves per assegurar-se que estiguin preparats per adaptar-se a les proves de l'API més enllà de les proves habituals basades en la GUI.

Desafiaments

• Cap dels altres productes de programari tenia arquitectura basada en API, per tant, per acomodar les proves al voltant d’aquesta tasca, l’equip ha d’establir el procés de prova de l’API des de zero. Això vol dir que les eines havien de ser avaluades, preseleccionades, finalitzades i que s’havia de formar l’equip per a les proves.
• No es va assignar cap pressupost addicional per adquirir i implementar l'eina. Això vol dir que l’equip havia de triar una eina de prova d’API gratuïta o de codi obert i que algú de l’equip existent havia de formar-se per dur a terme aquesta tasca.
• No hi havia requisits per als camps de l'API i la validació de dades. Els requisits eren 'haurien de funcionar igual que l'aplicació GUI corresponent'.

L'enfocament seguit per l'equip per mitigar els riscos i solucionar els reptes

• L’equip de control de qualitat va treballar amb l’equip del projecte per identificar els requisits següents:
  • Tipus d'API (REST / SOAP): DESCANS
  • Proves necessàries (funcionals, de càrrega, de seguretat): Només proves funcionals
  • Es requereixen proves automatitzades (Sí / No): Opcional per ara
  • Informes de proves (Sí / No): Obligatori
• L'equip de control de qualitat va fer l'avaluació de les eines disponibles Eines de proves API en funció dels requisits imprescindibles. L'eina Postman API es va finalitzar com a eina que van triar, ja que era gratuïta i fàcil d'utilitzar, minimitzant així la corba d'aprenentatge i tenint el potencial d'automatitzar proves i va comptar amb bons informes integrats.
• El mateix provador que va provar l’aplicació va rebre formació per utilitzar Postman per crear proves inicials, eliminant així els buits de coneixement del producte.
• Per fer front als requisits que falten, l’equip del projecte va construir la documentació d’alt nivell de camp mitjançant Swagger. Tanmateix, això va deixar algunes llacunes en termes de formats de dades acceptables i això es va assumir amb l'equip del projecte i es van acordar i documentar els formats esperats.

Conclusió

Les aplicacions basades en API han guanyat popularitat en els darrers temps. Aquestes aplicacions són més escalables en comparació amb les aplicacions / programari tradicionals i permeten una integració més fàcil amb les altres API o aplicacions.

Aquest tutorial de proves API explica detalladament tot sobre les proves API, Shift Left Testing, serveis web i API web. També hem explorat les diferències entre serveis web i API web amb exemples.

A la segona part del tutorial, vam discutir tot l'espectre de les proves API, com introduir les proves API a la vostra organització i alguns reptes habituals en aquest procés juntament amb solucions per a ells.

Consulteu el nostre proper tutorial per obtenir més informació sobre els serveis web juntament amb exemples.

NEXT Tutorial

Lectura recomanada

• Proves alfa i proves beta (guia completa)
• Proves funcionals contra proves no funcionals
• Tutorial de proves d'usabilitat: una guia d'introducció completa
• Guia completa de proves de verificació de compilació (proves BVT)
• Tutorial de proves DevOps: com impactarà DevOps en les proves de control de qualitat?
• Tutorial de proves d'accessibilitat (una guia completa pas a pas)
• Les millors eines de prova de programari 2021 (Eines d'automatització de proves de control de qualitat)
• Què són les proves de programari? Més de 100 tutorials gratuïts sobre proves manuals