• Popis vodiča za testiranje API-ja
• Pregled udžbenika u ovoj seriji testiranja API-ja
  • • (ii) Testiranje opterećenja i performansi
  • Kako uvesti testiranje API-ja u svoju organizaciju
  • Uobičajeni izazovi i načini njihovog ublažavanja
    • #1) Odabir pravog alata
    • #2) Nedostaju specifikacije testa
    • #3) Krivulja učenja
    • #4) Postojeći skup vještina
  • Studija slučaja
• Zaključak
• Vodič za testiranje API-ja
  • Testiranje pomaka ulijevo
  • Životni ciklus razvoja softvera (SDLC) Prije testiranja pomaka ulijevo
  • Faze testiranja lijevog pomaka
  • Web API
  • Kako radi API?
  • Web usluge
  • Web usluga naspram Web API
• Predstavljanje API testiranja u vašoj organizaciji
  • Prijelaz fokusa na testiranje API-ja
  • Cijeli spektar testiranja API-ja
    • (i) Funkcionalno testiranje

Ovaj detaljni vodič za testiranje API-ja objašnjava sve o testiranju API-ja, web uslugama i kako uvesti testiranje API-ja u svoju organizaciju:

Steknite duboki uvid u testiranje API-ja zajedno s koncept testiranja shift-lijevo i web-usluga iz ovog uvodnog vodiča.

Koncepti kao što je Web API, kako API radi (s primjerom iz stvarnog svijeta) i kako se razlikuje od web-usluga dobro su objašnjeni s primjerima u ovom vodič.

Popis vodiča za testiranje API-ja

Vodič #1: Vodič za testiranje API-ja: potpuni vodič za početnike

Vodič #2: Vodič za web usluge: komponente, arhitektura, vrste & Primjeri

Tutorial #3: Top 35 ASP.Net i Web API pitanja za intervjue s odgovorima

Tutorial #4: POSTMAN Tutorial: API testiranje Korištenje POSTMAN

Vodič br. 5: Testiranje web usluga pomoću Apache HTTP klijenta

Pregled udžbenika u ovoj seriji testiranja API-ja

Vodič #	Što ćete naučiti
Vodič_#1:	Vodič za testiranje API-ja : Potpuni vodič za početnike Ovaj vodič za dubinsko testiranje API-ja detaljno će objasniti sve o testiranju API-ja i web-uslugama te vas također educirati o tome kako uvesti testiranje API-ja u svoju organizaciju.
Vodič_#2:	Vodič za web usluge: komponente, arhitektura, vrste & Primjeri Ovaj webispravnost odgovora API-ja za valjane i nevažeće odgovore doista je ključna. Ako je statusni kod 200 (što znači da je sve u redu) primljen kao odgovor testnog API-ja, ali ako tekst odgovora kaže da je došlo do pogreške, tada je to kvar. Osim toga, ako poruka o pogrešci sam po sebi netočan, onda to može dovesti u zabludu krajnjeg kupca koji se pokušava integrirati s ovim API-jem. Na snimci zaslona ispod, korisnik je unio nevažeću težinu, koja je veća od prihvatljivih 2267 kg. API odgovara kodom statusa pogreške i porukom o pogrešci. Međutim, poruka pogreške netočno spominje jedinice težine kao lbs umjesto KG. Ovo je nedostatak koji može zbuniti krajnjeg korisnika. (ii) Testiranje opterećenja i performansi API-ji su dizajnirani da budu skalabilni. Ovo pak čini testiranje opterećenja i performansi ključnim, posebno ako se očekuje da će sustav koji se dizajnira opsluživati ​​tisuće zahtjeva po minuti ili satu, ovisno o zahtjevu. Rutinsko izvođenje testova opterećenja i izvedbe na API-ju može pomoći u usporedbi performansi, vršnih opterećenja i prijelomne točke. Ovi su podaci korisni pri planiranju povećanja aplikacije. Raspolaganje ovim informacijama pomoći će pri donošenju odluka i planiranju, posebno ako organizacija planira dodati više kupaca, što bi značilo više dolaznihzahtjeva. Kako uvesti testiranje API-ja u svoju organizaciju Proces uvođenja testiranja API-ja u bilo kojoj organizaciji sličan je procesu koji se koristi za implementaciju ili uvođenje bilo kojeg drugog alata i okvira za testiranje. Tablica u nastavku sažima glavne korake zajedno s očekivanim ishodom svakog koraka. Faza Korak Očekivani ishod Odabir alata Prikupiti zahtjeve i identificirati ograničenja Razumijevanje zahtjeva za istraživanje tržište za odgovarajući alat za testiranje API-ja. Npr. Koja vrsta API-ja se testira - SOAP ili REST? Trebamo li angažirati testera za ovu ulogu ili obučiti postojećeg testera? Kakvi će se testovi provoditi - funkcionalni, testovi performansi itd. Koji je proračun za implementaciju? Procijenite dostupne alate Usporedite dostupne alate i odaberite 1 ili 2 alata koji najbolje ispunjavaju zahtjeve. Dokaz koncepta Implementirajte podskup testova s ​​alatom koji je ušao u uži izbor. Predstavite nalaze zainteresiranim stranama. Dovršite alat koji će se implementirati. Implementacija Početak Ovisno o vašem izboru alata, morat ćete instalirati potrebni alat na osobno računalo, virtualni stroj ili poslužitelj. Ako se alat po izboru temelji na pretplati , stvoriti potreban timračune. Obučite tim ako je potrebno. Krenite Stvorite testove Izvršite testove Prijavite nedostatke Uobičajeni izazovi i načini njihovog ublažavanja Razgovarajmo o nekim od uobičajenih izazova s ​​kojima se timovi za osiguranje kvalitete suočavaju suočavaju dok pokušavaju implementirati okvir za testiranje API-ja u organizaciji. #1) Odabir pravog alata Odabir pravog alata za posao je najčešći izazov. Postoji nekoliko alata za testiranje API-ja koji su dostupni na tržištu. Možda se čini vrlo privlačnim implementirati najnoviji, najskuplji alat dostupan na tržištu - ali ako ne donosi željene rezultate, onda taj alat nema koristi. Stoga, uvijek odaberite alat koji ispunjava zahtjeve koje morate imati na temelju vaših organizacijskih potreba. Ovdje je primjer matrice za procjenu alata za dostupni API alati Alat Cijene Napomene Soap UI Besplatna verzija dostupna za SoapUI Open Source (funkcionalno testiranje) * REST, SOAP i drugi popularni API i IoT protokoli. * Uključeno u besplatnu verziju SOAP i REST ad-hoc testiranje Tvrdnja poruke Povucite & Stvaranje testa ispuštanja Zapisi testa Konfiguracija testa Test iz snimaka Izvješćivanje jedinice. * Kompletan popis značajki može se pronađeno u njihovimweb stranica. Poštar Dostupna besplatna aplikacija za poštare * Najčešće korištena za REST. * Značajke se mogu pronaći na njihovoj web stranici. Parasoft To je alat koji se plaća, zahtijeva kupnju licence, a zatim instalaciju prije nego što se alat može koristiti. * Sveobuhvatno API testiranje: funkcionalno, opterećenje, sigurnosno testiranje, upravljanje testnim podacima vREST Na temelju broja korisnika * Automatizirano testiranje REST API-ja. * Snimanje i reprodukcija. * Uklanja ovisnost o sučelju i pozadini pomoću lažnih API-ja. * Snažna provjera valjanosti odgovora. * Radi za testne aplikacije postavljene na lokalnom hostu/intranetu/internetu. * JIRA integracija, Jenkins integracija uvozi od Swagger, Postman. HttpMaster Express Edition: Besplatno preuzimanje Profesionalna verzija: Na temelju broja korisnika * Pomaže u testiranju web-mjesta kao i testiranju API-ja. * Ostale značajke uključuju mogućnost definiranja globalnih parametara, pruža korisniku mogućnost stvaranja provjera za provjeru valjanosti odgovora pomoću velikog skupa vrsta provjere valjanosti koje podržava. Runscope Na temelju broja korisnika i vrsta plana * Za nadzor i testiranje API-ja. * Može se koristiti za provjeru valjanosti podataka kako bi se osiguralo vraćanje točnih podataka. * Sadrži značajkupraćenje i obavještavanje u slučaju neuspjeha API transakcije (ako vaša aplikacija zahtijeva potvrdu plaćanja, onda se ovaj alat može pokazati kao dobar izbor). LoadFocus Na temelju broja korisnika i vrsta planova * Može se koristiti za testiranje opterećenja API-ja - omogućuje pokretanje nekoliko testova kako bi se saznao broj korisnika koji API može podržati. * Jednostavan za korištenje - omogućuje pokretanje testova unutar preglednika. PingAPI Besplatno za 1 projekt (1000 zahtjeva ) * Korisno za automatsko API testiranje i praćenje. #2) Nedostaju specifikacije testa Kao testeri, moramo znati očekivane rezultate za učinkovito testiranje aplikacije. To je često izazov, jer da bismo znali očekivane rezultate, moramo imati jasne i precizne zahtjeve – što nije slučaj. Na primjer , razmotrite zahtjeve navedene u nastavku: "Aplikacija treba prihvatiti samo važeći datum otpreme, a svi nevažeći zahtjevi trebaju biti odbijeni" Ovim zahtjevima nedostaju ključni detalji i vrlo su dvosmisleni – kako definiramo važeći datum? Što je s formatom? Vraćamo li krajnjem korisniku poruku o odbijanju itd.? Primjer jasnih zahtjeva: 1) Aplikacija bi trebala samo prihvatite važeći datum otpreme. Datum otpreme smatra se važećim ako jeje Nije u prošlosti Veći ili jednak današnjem datumu U prihvatljivom je formatu: DD/MM/GGGG 2) Šifra statusa odgovora = 200 Poruka: OK 3) Datum otpreme koji ne ispunjava gore navedene kriterije treba smatrati nevažećim. Ako kupac pošalje nevažeći datum otpreme, mora odgovoriti sljedećom porukom(ama) o pogrešci: 3.1 Šifra statusa odgovora NIJE 200 Pogreška: Navedeni datum otpreme je nevažeći; provjerite je li datum u formatu DD/MM/GGGG 3.2 Šifra statusa odgovora NIJE 200 Pogreška: Navedeni datum otpreme je u prošlost #3) Krivulja učenja Kao što je prethodno spomenuto, pristup testiranju API-ja drugačiji je u usporedbi s pristupom testiranja aplikacija temeljenih na GUI-ju. Ako zapošljavaju interne stručnjake ili konzultante za testiranje API-ja, krivulja učenja API testnog pristupa ili API testnog alata može biti minimalna. Bilo koja krivulja učenja, u ovom slučaju, bila bi povezana sa stjecanjem znanja o proizvodu ili aplikaciji. Ako je postojećem članu tima dodijeljeno učenje testiranja API-ja, ovisno o alatu po izboru, krivulja učenja može biti srednje do visoke, uz promjenu pristupa testiranju. Krivulja učenja za sam proizvod ili aplikaciju može biti niska do srednja ovisno o tome je li ovaj ispitivač testiraotu aplikaciju prije ili ne. #4) Postojeći skup vještina Ovo je izravno povezano s prethodnom točkom o krivulji učenja. Ako je ispitivač prelazio s Testiranje temeljeno na GUI-u, tada bi ispitivač trebao promijeniti pristup testiranju i naučiti novi alat ili okvir prema potrebi. Npr. Ako API prihvaća zahtjeve u JSON formatu, ispitivač bi trebao naučiti što je JSON kako bi počeo stvarati testove. Studija slučaja Zadatak Kako bi se povećala postojeća aplikacija, tvrtka je htjela ponuditi proizvod u API-ju kao i standardnu ​​GUI aplikaciju. QA tim je zamoljen da osigura plan pokrivenosti testom kako bi se osiguralo da su spremni prihvatiti API testiranje izvan uobičajenih GUI testova. Izazovi Ništa Ostali softverski proizvodi imali su arhitekturu temeljenu na API-ju, stoga da bi se prilagodilo testiranju oko ovog zadatka, tim treba uspostaviti postupak testiranja API-ja od nule. To znači da su alati trebali biti ocijenjeni, uvršteni u uži izbor, finalizirani, a tim je morao biti obučen za testove. Nije bilo dodatnog proračuna dodijeljenog za nabavu i implementaciju alata. To znači da je tim morao odabrati besplatni ili otvoreni alat za testiranje API-ja i da je netko iz postojećeg tima morao biti obučen da preuzme ovaj zadatak. Nije bilo zahtjeva za API polja i podatkevalidacija. Zahtjevi su bili "trebao bi raditi isto kao i odgovarajuća GUI aplikacija". Pristup koji je tim slijedio kako bi ublažio rizike i zaobišao izazove QA tim je radio s projektnim timom na identificiranju sljedećih zahtjeva: API vrsta (REST/SOAP): REST Potrebni testovi (funkcionalni, Opterećenje, sigurnost): Samo funkcionalno testiranje Potrebni su automatizirani testovi (Da/Ne): Opcionalno za sada Izvješća o ispitivanju (Da/Ne) ): Obavezno QA tim je izvršio procjenu alata na dostupnim alatima za testiranje API-ja na temelju obaveznih zahtjeva. Postman API Tool finaliziran je kao alat po njihovom izboru budući da je bio besplatan i jednostavan za korištenje, čime je minimizirana krivulja učenja, imao je potencijal za automatizaciju testova i dolazio je s dobrim ugrađenim izvješćima. Isti ispitivač koji je testirao aplikaciju bio je obučen za korištenje Postmana za izradu početnih testova čime su eliminirani svi nedostaci u poznavanju proizvoda. Kako bi se pozabavili nedostajućim zahtjevima, projektni tim izradio je terensku dokumentaciju visoke razine koristeći Swagger . To je međutim ostavilo neke praznine u pogledu prihvatljivih formata podataka i to je razmatrano s projektnim timom i očekivani formati su dogovoreni i dokumentirani. Zaključak Aplikacije temeljene na API-ju imaju stekao popularnost u novije vrijeme. Ove aplikacije su višeskalabilan u usporedbi s tradicionalnim aplikacijama/softverom i omogućuje lakšu integraciju s drugim API-jima ili aplikacijama. Ovaj vodič za testiranje API-ja detaljno je objasnio sve o testiranju API-ja, testiranju pomaka ulijevo, web uslugama i web API-ju. Također smo s primjerima istražili razlike između web usluga i web API-ja. U drugom dijelu vodiča razgovarali smo o cijelom spektru testiranja API-ja, kako uvesti testiranje API-ja u svoju organizaciju i nekim uobičajenim izazovima u ovaj proces zajedno s rješenjima za njih. Pogledajte naš nadolazeći vodič kako biste saznali više o web uslugama zajedno s primjerima!! SLJEDEĆI vodič Vodič za usluge objašnjava arhitekturu, vrste & Komponente web usluga zajedno s važnim terminologijama i razlikama između SOAP-a i REST-a.
Vodič_#3:	Top 35 ASP.Net i Web API pitanja za intervju s odgovorima Možete istražiti popis najpopularnijih često postavljanih ASP.Net i Web API pitanja za intervju s odgovorima & primjeri za početnike i iskusne profesionalce u ovom vodiču.
Tutorial_#4:	POSTMAN Tutorial: API testiranje pomoću POSTMAN Ovaj vodič korak po korak objasnit će testiranje API-ja korištenjem POSTMAN-a zajedno s osnovama POSTMAN-a, njegovih komponenti i uzorka zahtjeva & Odgovorite jednostavnim riječima za lakše razumijevanje.
Tutorial_#5:	Testiranje web usluga pomoću Apache HTTP klijenta Ovaj vodič za API govori o izvođenju različitih CRUD operacija na web uslugama i testiranju web servisa pomoću Apache HTTP klijenta

Vodič za testiranje API-ja

Ovaj odjeljak pomoći će vam da steknete osnovno razumijevanje web usluga i web API-ja, što će vam zauzvrat pomoći u razumijevanju glavnih koncepata u nadolazećim vodičima u ovoj seriji testiranja API-ja.

API ( Application Programming Interface) skup je svih postupaka i funkcija koje nam omogućuju stvaranje aplikacije pristupanjem podacima ili značajkamaoperativni sustav ili platforme. Testiranje takvih postupaka poznato je kao API testiranje.

Testiranje pomaka ulijevo

Jedna od važnih vrsta testiranja koja se danas postavlja u intervjuima za testiranje API-ja je testiranje pomaka ulijevo. Ova vrsta testiranja prakticira se u gotovo svim projektima koji slijede agilnu metodologiju.

Prije nego što je uvedeno Shift Left Testing, testiranje softvera dolazilo je u obzir tek nakon što je kodiranje dovršeno i kod isporučen testerima. Ova praksa dovela je do gužve u zadnji čas da se ispuni rok, a također je u velikoj mjeri ugrozila kvalitetu proizvoda.

Osim toga, uloženi napori (kada su nedostaci prijavljeni u posljednjoj fazi prije proizvodnje) bili su ogroman jer su programeri morali iznova prolaziti i kroz fazu dizajna i kodiranja.

Životni ciklus razvoja softvera (SDLC) Prije testiranja pomaka ulijevo

Tradicionalni tijek SDLC-a bio je: Zahtjev – > Dizajn –> Kodiranje –> Testiranje.

Nedostaci tradicionalnog testiranja

• Testiranje je krajnje desno. Mnogi troškovi nastaju kada se greška identificira u zadnjem trenutku.
• Vrijeme potrebno za rješavanje greške i njegovo ponovno testiranje prije promicanja u proizvodnju je ogromno.

Stoga, pojavila se nova ideja da se faza testiranja pomakne ulijevo što je dovelo do testiranja pomaka ulijevo.

Predloženo za čitanje => Testiranje pomaka ulijevo: ATajna mantra za uspjeh softvera

Faze testiranja lijevog pomaka

Testiranje lijevog pomaka dovelo je do uspješne migracije s otkrivanja nedostataka na sprječavanje nedostataka. Također je pomogao softveru da brzo otkaže i popravi sve kvarove što je prije moguće.

Web API

Općenito, Web API može se definirati kao nešto što preuzima zahtjev od klijenta sustava na web poslužitelj i šalje natrag odgovor s web poslužitelja na klijentski stroj.

Kako radi API?

Uzmimo vrlo uobičajeni scenarij rezerviranja leta na www.makemytrip.com, internetskoj putničkoj usluzi koja objedinjuje informacije više zrakoplovnih prijevoznika. Kada idete na rezervaciju leta, unosite informacije kao što su datum putovanja/datum povratka, klasa itd. i kliknite na pretraživanje.

Ovo će vam pokazati cijene više zrakoplovnih prijevoznika i njihovu dostupnost. U ovom slučaju, aplikacija komunicira s API-jima više zrakoplovnih prijevoznika i na taj način daje pristup podacima zrakoplovnog prijevoznika.

Još jedan primjer je www.trivago.com koji uspoređuje i navodi cijene, dostupnost itd. različitih hotela iz određenog grada. Ova web stranica komunicira s API-jima više hotela za pristup bazi podataka i ispisuje cijene i dostupnost s njihove web stranice.

Dakle, Web API može se definirati kao "sučelje koje olakšava komunikaciju između klijentskog računala i theweb poslužitelj”.

Web usluge

Web usluge su (poput Web API-ja) usluge koje služe s jednog stroja na drugi. Ali glavna razlika koja se javlja između API-ja i web-usluga je ta da web-usluge koriste mrežu.

Sigurno je reći da su sve web-usluge web-API-ji, ali svi web-API-ji nisu web-usluge (objašnjeno u posljednji dio članka). Stoga su web usluge podskup web API-ja. Pogledajte donji dijagram kako biste saznali više o web API-ju i web uslugama.

Web API naspram web usluga

Web usluga naspram Web API

I Web API i Web usluge koriste se za olakšavanje komunikacije između klijenta i poslužitelja. Glavna razlika dolazi samo u načinu na koji komuniciraju.

Svaki od njih zahtijeva tijelo zahtjeva koje je prihvatljivo na određenom jeziku, njihove razlike u pružanju sigurne veze, njihovoj brzini komuniciranja s poslužiteljem i povratnog odgovora klijentu, itd.

Razlike između web usluga i web API-ja navedene su u nastavku za vašu referencu.

Web usluga

• Web usluge općenito koriste XML (Extensible Markup Language), što znači da su sigurnije.
• Web usluge su sigurnije jer i web usluge i API-ji pružaju SSL (Secure Socket Layer) tijekom prijenosa podataka , ali također pruža WSS (Web Services Security).
• Web usluga je podskup Web API-ja. Na primjer, Web usluge temelje se samo na tri stila upotrebe, tj. SOAP, REST i XML-RPC.
• Web usluge uvijek trebaju mrežu za rad.
• Web usluge podržavaju “Jedan kod različitih aplikacija”. To znači da je generički kod napisan u različitim aplikacijama.

Web API

• Web API općenito koristi JSON (JavaScript Object Notation), što znači da je Web API brži.
• Web API je brži jer je JSON lagan, za razliku od XML-a.
• Web API-ji su nadskup web usluga. Na primjer, Sva tri stila web usluga također su prisutna u web API-ju, ali osim toga, on koristi druge stilove kao što je JSON – RPC.
• Web API ne zahtijeva nužno mreža za rad.
• Web API može ili ne mora podržavati interoperabilnost ovisno o prirodi sustava ili aplikacije.

Predstavljanje API testiranja u vašoj organizaciji

U našem svakodnevnom životu, svi smo toliko navikli na interakciju s aplikacijama s API-jima, a ipak uopće ne razmišljamo o pozadinskim procesima koji pokreću temeljnu funkcionalnost.

Na primjer , Uzmimo u obzir da pregledavate proizvode na Amazon.com i vidite proizvod/ponudu koji vam se stvarno sviđa i želite ga podijeliti sa svojom Facebook mrežom.

U trenutku kada kliknete na Facebook ikoni u dijelu stranice za dijeljenje i unesite svojeVjerodajnice Facebook računa za dijeljenje, vi komunicirate s API-jem koji neprimjetno povezuje web stranicu Amazon s Facebookom.

Prijelaz fokusa na testiranje API-ja

Prije nego što raspravljamo o testiranju API-ja, raspravimo o razlozima za koje su aplikacije temeljene na API-ju u posljednje vrijeme stekle popularnost.

Postoji nekoliko razloga zbog kojih organizacije prelaze na proizvode i aplikacije temeljene na API-ju. Nekoliko njih je navedeno u nastavku za vašu referencu.

#1) Aplikacije temeljene na API-ju su skalabilnije u usporedbi s tradicionalnim aplikacijama/softverom. Stopa razvoja koda je brža i isti API može opsluživati ​​više zahtjeva bez većih promjena koda ili infrastrukture.

#2) Razvojni timovi ne moraju svaki put početi kodirati ispočetka kada počnu raditi na razvoju značajke ili aplikacije. API-ji najčešće ponovno koriste postojeće, ponovljive funkcije, biblioteke, pohranjene procedure itd. i stoga ih ovaj proces može učiniti produktivnijima u cjelini.

Na primjer, Ako ste programer koji radi na web-mjesto za e-trgovinu i želite dodati Amazon kao procesor plaćanja – tada ne morate pisati kod od nule.

Sve što trebate učiniti je postaviti integraciju između vašeg web-mjesta i Amazon API-ja pomoću Integracijski ključevi i pozivanje Amazon API-ja za obradu plaćanja tijekom naplate.

#3) API-ji dopuštajujednostavna integracija s drugim sustavima i za podržane samostalne aplikacije kao i za softverske proizvode temeljene na API-ju.

Na primjer , uzmimo u obzir da želite poslati pošiljku iz Toronta u New York . Idete na internet, idite na dobro poznatu web-stranicu za teret ili logistiku i unesite tražene informacije.

Nakon unosa obaveznih informacija, kada kliknete na gumb Dohvati cijene – u stražnjem dijelu, ova se logistička web-stranica možda povezuje s nekoliko API-ja i aplikacija operatera i pružatelja usluga kako biste dobili dinamičke stope za kombinaciju lokacija od polazišta do odredišta.

Cijeli spektar testiranja API-ja

Testiranje API-ja nije ograničeno na slanje zahtjeva API-ju i analiziranje samo ispravnosti odgovora. API-je je potrebno testirati na njihovu izvedbu pod različitim opterećenjima na ranjivosti.

Razpravimo ovo u detalje.

(i) Funkcionalno testiranje

Funkcionalno testiranje može biti izazovan zadatak zbog nedostatka GUI sučelja.

Pogledajmo kako se pristup funkcionalnom testiranju za API-je razlikuje od aplikacije temeljene na GUI-ju, a također ćemo raspraviti neke primjere oko toga.

a) Najočitija razlika je u tome što ne postoji GUI za interakciju. Testerima koji obično rade funkcionalno testiranje temeljeno na GUI-u malo je teže prijeći na testiranje aplikacija bez GUI-a u usporedbi snetko tko je već upoznat s tim.

U početku, čak i prije nego počnete testirati API, morat ćete testirati i potvrditi sam proces autentifikacije. Metoda provjere autentičnosti razlikovat će se od jednog API-ja do drugog API-ja i uključivat će neku vrstu ključa ili tokena za provjeru autentičnosti.

Ako se ne možete uspješno povezati s API-jem, daljnje testiranje se ne može nastaviti. Ovaj se proces može smatrati usporedivim s autentifikacijom korisnika u standardnim aplikacijama gdje su vam potrebne valjane vjerodajnice za prijavu i korištenje aplikacije.

b) Provjera valjanosti polja ili validacija ulaznih podataka vrlo je važna tijekom testiranja API-ja. Ako je stvarno sučelje temeljeno na obrascima (GUI) bilo dostupno, tada bi se provjere valjanosti polja mogle implementirati u prednjem ili stražnjem dijelu, čime bi se osiguralo da korisniku nije dopušten unos nevažećih vrijednosti polja.

Na primjer, Ako aplikacija treba da format datuma bude DD/MM/GGGG, tada možemo primijeniti ovu provjeru valjanosti na obrazac za prikupljanje informacija kako bismo osigurali da aplikacija prima i obrađuje važeći datum.

To, međutim, nije isto za API aplikacije. Moramo osigurati da je API dobro napisan i da je u stanju provesti sve te provjere valjanosti, razlikovati valjane od nevažećih podataka i vratiti statusni kod i poruku o pogrešci validacije krajnjem korisniku putem odgovora.

c) Ispitivanje