• Lista e mësimeve të testimit të API
• Përmbledhje e udhëzuesve në këtë seri testimi API
  • • (ii) Testimi i ngarkesës dhe performancës
  • Si të prezantoni testimin API në organizatën tuaj
  • Sfidat e zakonshme dhe mënyrat për t'i zbutur ato
    • #1) Zgjedhja e mjetit të duhur
    • #2) Mungojnë specifikimet e testit
    • #3) Kurba e të mësuarit
    • #4) Kompleti ekzistues i aftësive
  • Studim rasti
• Përfundim
• Udhëzues Testimi API
  • Testimi Shift Majtas
  • Cikli jetësor i zhvillimit të softuerit (SDLC) Para Shift Left Testimi
  • Fazat e testimit të zhvendosjes majtas
  • Web API
  • Si funksionon një API?
  • Shërbimet e uebit
  • Shërbimeve të uebit vs Web API
• Prezantimi i testimit të API-së në organizatën tuaj
  • Fokusohu te testimi API
  • Spektri i plotë i testimit të API-së
    • (i) Testimi funksional

Ky tutorial i thelluar i testimit të API shpjegon gjithçka rreth testimit të API-së, shërbimeve në internet dhe si të prezantoni testimin e API në organizatën tuaj:

Fitoni një pasqyrë të thellë në testimin e API-së së bashku me koncepti i testimit me zhvendosje në të majtë dhe shërbimeve të uebit nga ky tutorial hyrës.

Konceptet si Web API, si funksionon API (me shembullin e botës reale) dhe si është i ndryshëm nga Shërbimet e Uebit shpjegohen mirë me shembuj në këtë tutorial.

Lista e mësimeve të testimit të API

Tutorial #1: Udhëzues për testimin e API: Një udhëzues i plotë për fillestarët

Tutorial #2: Udhëzues i Shërbimeve të Uebit: Komponentët, Arkitektura, Llojet & Shembuj

Tutorial #3: 35 pyetjet më të mira të intervistës ASP.Net dhe API me përgjigje me përgjigje

Tutorial #4: Udhëzues POSTMAN: Testimi i API Përdorimi i POSTMAN

Tutorial #5: Testimi i shërbimeve në ueb duke përdorur klientin Apache HTTP

Përmbledhje e udhëzuesve në këtë seri testimi API

Tutoriali #	Çfarë do të mësoni
Tutorial_#1:	Udhëzues për testimin e API : Një udhëzues i plotë për fillestarët Ky tutorial i Thelluar i Testimit të API-së do të shpjegojë gjithçka në lidhje me Testimin e API-së dhe Shërbimet e Uebit në detaje dhe gjithashtu do t'ju edukojë se si të prezantoni Testimin API në organizatën tuaj.
Tutorial_#2:	Udhëzues për shërbimet në internet: Komponentët, Arkitektura, Llojet & Shembuj Ky Uebkorrektësia e përgjigjeve nga API për përgjigje të vlefshme dhe të pavlefshme është me të vërtetë thelbësore. Nëse një kod statusi prej 200 (që do të thotë gjithçka në rregull) merret si përgjigje nga API-ja e testit, por nëse teksti i përgjigjes thotë se është hasur një gabim, atëherë ky është një defekt. Për më tepër, nëse mesazhi i gabimit në vetvete është e pasaktë, atëherë kjo mund të jetë shumë mashtruese për klientin fundor që po përpiqet të integrohet me këtë API. Në pamjen e ekranit më poshtë, përdoruesi ka futur peshën e pavlefshme, e cila është më shumë se 2267 kg e pranueshme. API përgjigjet me kodin e statusit të gabimit dhe mesazhin e gabimit. Megjithatë, mesazhi i gabimit i përmend gabimisht njësitë e peshës si lbs në vend të KG. Ky është një defekt që mund të ngatërrojë klientin përfundimtar. (ii) Testimi i ngarkesës dhe performancës API-të janë menduar të jenë të shkallëzueshme nga dizajni. Kjo, nga ana tjetër, e bën testimin e ngarkesës dhe performancës thelbësore, veçanërisht nëse sistemi që po projektohet pritet të shërbejë mijëra kërkesa në minutë ose orë, në varësi të kërkesës. Kryerja e rregullt e testeve të ngarkesës dhe performancës në API mund të ndihmojë në krahasimin e performancës, ngarkesave maksimale dhe pikës së thyerjes. Këto të dhëna janë të dobishme gjatë planifikimit të rritjes së një aplikacioni. Pasja e këtij informacioni në dispozicion do të ndihmojë për të mbështetur vendimet dhe planifikimin, veçanërisht nëse organizata planifikon të shtojë më shumë klientë, që do të nënkuptonte më shumë hyrjekërkesave. Si të prezantoni testimin API në organizatën tuaj Procesi për prezantimin e testimit API në çdo organizatë është i ngjashëm me procesin e përdorur për zbatimin ose nxjerrjen e çdo mjeti dhe kornizë tjetër testimi. Tabela e mëposhtme përmbledh hapat kryesorë së bashku me rezultatin e pritur të secilit hap. Faza Hapi Rezultati i pritshëm Zgjedhja e mjeteve Mblidhni kërkesat dhe identifikoni kufizimet Të kuptoni kërkesat për kërkimin tregu për mjetin e duhur të testit API. P.sh. Çfarë lloj API po testohet - SOAP apo REST? A duhet të punësojmë testues për këtë rol apo të trajnojmë testuesin ekzistues? Çfarë lloj testesh do të kryhen - teste funksionale, të performancës etj. Sa është buxheti për zbatim? Vlerëso mjetet e disponueshme Krahaso mjetet e disponueshme dhe zgjedh 1 ose 2 mjete që plotësojnë më mirë kërkesat. Proof of Concept Zbatoni një nëngrup testesh me mjetin e përzgjedhur. Paraqisni gjetjet tek palët e interesuara. Finalizoni mjetin që do të zbatohet. Implementimi Fillimi Në varësi të mjetit të zgjedhur, do t'ju vyshket nevoja për të instaluar mjetin e kërkuar në një kompjuter, makinë virtuale ose server. Nëse mjeti i zgjedhur është i bazuar në pajtim , krijoni ekipin e kërkuarllogaritë. Trajnoni ekipin nëse kërkohet. Vazhdoni Krijoni teste Ekzekutoni teste Raportoni defektet Sfidat e zakonshme dhe mënyrat për t'i zbutur ato Le të diskutojmë disa nga sfidat e zakonshme që ekipet e SC përballen gjatë përpjekjes për të zbatuar një kornizë testimi API në një organizatë. #1) Zgjedhja e mjetit të duhur Zgjedhja e mjetit të duhur për punën është sfida më e zakonshme. Ka disa mjete testimi API që janë të disponueshme në treg. Mund të duket shumë tërheqëse të zbatosh mjetin më të fundit, më të shtrenjtë të disponueshëm në treg - por nëse nuk sjell rezultatet e dëshiruara, atëherë ai mjet është e padobishme. Prandaj, zgjidhni gjithmonë mjetin që adreson kërkesat 'të domosdoshme' bazuar në nevojat tuaja organizative. Këtu është një mostër matricë e vlerësimit të mjetit për Mjetet e disponueshme API Mjeti Çmimi Shënime Soap UI Versioni falas i disponueshëm për SoapUI Open Source (Testim funksional) * REST, SOAP dhe protokolle të tjera të njohura API dhe IoT. * Përfshirë në versionin falas SAPUN dhe REST testimi ad-hoc Pohimi i mesazhit Zvarrit & Hiq krijimin e testit Regjistrimet e testeve Konfigurimi i testit Testimi nga regjistrimet Raportimi i njësisë. * Lista e plotë e veçorive mund të jetë gjetur në të tyrewebsite. Postman Aplikacioni falas Postman ofrohet * Më i përdoruri për REST. * Veçoritë mund të gjenden në faqen e tyre të internetit. Parasoft Është një mjet me pagesë, kërkon blerjen e një licence dhe më pas kërkon instalim përpara se mjeti të mund të përdoret. * Testimi gjithëpërfshirës API: testimi funksional, ngarkesa, siguria, menaxhimi i të dhënave të testit vREST Bazuar në numrin e përdoruesve * Testimi i automatizuar i API-së REST. * Regjistro dhe riluaje. * Heq varësinë nga pjesa e përparme dhe pjesa e pasme duke përdorur API-të mashtruese. * Vërtetim i fuqishëm i përgjigjes. * Funksionon për aplikacionet testuese të vendosura në localhost/intranet/internet. * Integrimi JIRA, Integrimi Jenkins Importet nga Swagger, Postman. HttpMaster Edicioni Express: Pa pagesë për shkarkim Versioni profesional: Bazuar në numrin e përdoruesve * Ndihmon në testimin e faqes në internet, si dhe në testimin e API. * Karakteristika të tjera përfshijnë aftësinë për të përcaktuar parametrat globalë, i ofron përdoruesit një aftësi për të krijuar kontrolle për vërtetimin e përgjigjes së të dhënave duke përdorur grupin e madh të llojeve të vërtetimit që ai mbështet. Runscope Bazuar në numrin e përdoruesve dhe llojet e planeve * Për monitorimin dhe testimin e API-ve. * Mund të përdoret për vërtetimin e të dhënave për të siguruar kthimin e të dhënave të sakta. * Përmban veçori tëgjurmimi dhe njoftimi në rast të ndonjë dështimi të transaksionit API (nëse aplikacioni juaj kërkon vërtetimin e pagesës, atëherë ky mjet mund të jetë një zgjedhje e mirë). LoadFocus Bazuar në numrin e përdoruesve dhe llojet e planit * Mund të përdoret për testimin e ngarkesës së API - lejon kryerjen e disa testeve për të zbuluar numrin e përdoruesve që mund të mbështesë një API. * E thjeshtë për t'u përdorur - lejon ekzekutimin e testeve brenda shfletuesit. PingAPI Pa pagesë për 1 projekt (1000 kërkesa ) * E dobishme për testimin dhe monitorimin e automatizuar të API. #2) Mungojnë specifikimet e testit Si testues, ne duhet të dimë rezultatet e pritura për të testuar në mënyrë efektive një aplikacion. Kjo është shpesh një sfidë, pasi për të ditur rezultatet e pritura, ne duhet të kemi kërkesa të qarta të sakta – gjë që nuk është kështu. Për shembull , merrni parasysh kërkesat e dhëna më poshtë: "Aplikimi duhet të pranojë vetëm një datë të vlefshme transporti dhe të gjitha kërkesat e pavlefshme duhet të refuzohen" Këtyre kërkesave u mungojnë detajet kryesore dhe janë shumë të paqarta - si e përcaktojmë një datë të vlefshme? Po formati? A po kthejmë ndonjë mesazh refuzimi te përdoruesi fundor, etj.? Shembull i Kërkesave të Qarta: 1) Aplikacioni duhet vetëm pranoni një datë të vlefshme transporti. Data e dërgesës konsiderohet e vlefshme nëse është e vlefshmeështë Jo në të kaluarën Më e madhe ose e barabartë me datën e sotme Është në format të pranueshëm: DD/MM/VVVVV 2) Kodi i statusit të përgjigjes = 200 Mesazhi: OK 3) Data e dërgimit që nuk plotëson kriteret e mësipërme duhet të konsiderohet i pavlefshëm. Nëse një klient dërgon një datë të pavlefshme transporti, atëherë ai duhet të përgjigjet me mesazhet e mëposhtme të gabimit: 3.1 Kodi i statusit të përgjigjes NOT 200 Gabim: Data e dërgimit e dhënë është e pavlefshme; ju lutemi sigurohuni që data të jetë në formatin DD/MM/VVVV 3.2 Kodi i statusit të përgjigjes NUK 200 Gabim: Data e dërgimit është dhënë në e kaluara #3) Kurba e të mësuarit Siç u përmend më parë, qasja për testimin e API është e ndryshme kur krahasohet me qasjen e ndjekur gjatë testimit të aplikacioneve të bazuara në GUI. Nëse ju po punësojnë specialistë brenda ose konsulentë për testimin API, atëherë kurba e të mësuarit e qasjes së testit API ose mjetit të testimit API mund të jetë minimale. Çdo kurbë mësimi, në këtë rast, do të shoqërohet me marrjen e njohurive të produktit ose aplikimit. Nëse një anëtar i ekipit ekzistues caktohet për të mësuar testimin e API-së, atëherë në varësi të mjetit të zgjedhur, kurba e të mësuarit mund të jetë mesatare në të lartë, së bashku me ndryshimin e qasjes së testimit. Kurba e të mësuarit për vetë produktin ose aplikacionin mund të jetë e ulët e mesme në varësi të faktit nëse ky testues ka testuarai aplikim më parë ose jo. #4) Kompleti ekzistues i aftësive Kjo lidhet drejtpërdrejt me pikën e mëparshme rreth kurbës së të mësuarit. Nëse një testues po kalonte nga Testimi i bazuar në GUI, atëherë testuesi do të duhet të ndryshojë qasjen e testimit dhe të mësojë mjetin ose kornizën e re sipas nevojës. P.sh. Nëse API pranon kërkesat në formatin JSON, atëherë testuesi duhet të mësojë se çfarë është JSON, në mënyrë që të fillojë krijimin e testeve. Studim rasti Detyra Për të rritur shkallën e një aplikacioni ekzistues, një kompani donte të ofronte një produkt në API si dhe një aplikacion standard GUI. Ekipit të QA iu kërkua të siguronte një Plan të Mbulimit të Testit për t'u siguruar që ata janë gati të akomodojnë testimin e API përtej testeve të rregullta të bazuara në GUI. Sfidat Asnjë nga produktet e tjera softuerike kishin arkitekturë të bazuar në API, prandaj për të akomoduar testimin rreth kësaj detyre, ekipi duhet të vendosë procesin e testimit API nga e para. Kjo do të thotë që mjetet duhej të vlerësoheshin, të përzgjidheshin, të finalizoheshin dhe ekipi duhej të trajnohej për testet. Nuk kishte buxhet shtesë për blerjen dhe zbatimin e mjetit. Kjo do të thotë që ekipi duhej të zgjidhte një mjet testimi API pa pagesë ose me burim të hapur dhe dikush nga ekipi ekzistues duhej të trajnohej për të kryer këtë detyrë. Nuk kishte kërkesa për fushat dhe të dhënat e API-sëvërtetimi. Kërkesat ishin "duhet të funksionojnë njësoj si aplikacioni përkatës GUI". Qasja e ndjekur nga ekipi për të zbutur rreziqet dhe për të punuar rreth sfidave Ekipi i QA ka punuar me ekipin e projektit për të identifikuar kërkesat e mëposhtme: Lloji i API (REST/SOAP): REST Testet e kërkuara (Funksionale, Ngarkesa, siguria): Vetëm testimi funksional Kërkohen teste të automatizuara (Po/Jo): Opsionale për momentin Raportet e testimit (Po/Jo ): Kërkohet Ekipi i QA bëri vlerësimin e mjeteve në mjetet e disponueshme të testimit të API bazuar në kërkesat e domosdoshme. Postman API Tool u finalizua si një mjet sipas zgjedhjes së tyre pasi ishte falas dhe i lehtë për t'u përdorur gjithashtu, duke minimizuar kështu kurbën e të mësuarit dhe kishte potencialin për të automatizuar testet dhe erdhi me raporte të mira të integruara. I njëjti testues që testoi aplikacionin u trajnua për përdorimin e Postman për të krijuar teste fillestare, duke eliminuar kështu çdo boshllëk në njohuritë e produktit. Për t'u marrë me kërkesat që mungojnë, ekipi i projektit ndërtoi dokumentacionin e nivelit të lartë në terren duke përdorur Swagger . Megjithatë, kjo la disa boshllëqe për sa i përket formateve të pranueshme të të dhënave dhe kjo u mor me ekipin e projektit dhe formatet e pritshme u dakorduan dhe u dokumentuan. Përfundim Aplikacionet e bazuara në API kanë fitoi popullaritet në kohët e fundit. Këto aplikacione janë më shumëi shkallëzuar në krahasim me aplikacionet/softuerët tradicionalë dhe lejon integrim më të lehtë me API-të ose aplikacionet e tjera. Ky tutorial i Testimit të API shpjegoi në detaje gjithçka rreth Testimit të API-së, Testimit Shift Majtas, Shërbimeve të Uebit dhe API-së së Uebit. Ne gjithashtu eksploruam ndryshimet midis Shërbimeve Ueb dhe API-së së Uebit me shembuj. Në pjesën e dytë të tutorialit, diskutuam spektrin e plotë të Testimit të API, si të prezantoni Testimin API në organizatën tuaj dhe disa sfida të zakonshme në ky proces së bashku me zgjidhjet për to. Shikoni tutorialin tonë të ardhshëm për të ditur më shumë rreth Shërbimeve të Uebit së bashku me shembuj!! Tutoriali TJETËR Tutoriali i shërbimeve shpjegon Arkitekturën, Llojet & Komponentët e Shërbimeve të Uebit së bashku me Terminologjitë e Rëndësishme dhe Dallimet midis SOAP kundër REST.
Tutorial_#3:	35 pyetjet kryesore të intervistës ASP.Net dhe Web API me përgjigje Mund të eksploroni listën e pyetjeve më të njohura të intervistave të ASP.Net dhe Web API të intervistës me përgjigje & shembuj për fillestarët dhe profesionistët me përvojë në këtë tutorial.
Tutorial_#4:	Tutorial POSTMAN: API Testing Using POSTMAN Ky tutorial hap pas hapi do të shpjegojë Testimin e API duke përdorur POSTMAN së bashku me bazat e POSTMAN, komponentët e tij dhe kërkesën e mostrës & Përgjigju me fjalë të thjeshta për kuptueshmërinë tuaj të lehtë.
Tutorial_#5:	Testimi i shërbimeve të uebit duke përdorur Apache HTTP Client Ky udhëzues API ka të bëjë me kryerjen e operacioneve të ndryshme CRUD në shërbimet e uebit dhe testimin e shërbimeve të uebit duke përdorur Apache HTTP Client

Udhëzues Testimi API

Ky seksion do t'ju ndihmojë të kuptoni bazën e Shërbimeve të Uebit dhe API-së së Uebit, të cilat, nga ana tjetër, do të jenë të dobishme për të kuptuar konceptet kryesore në mësimet e ardhshme në këtë seri Testimi API.

API ( Ndërfaqja e programimit të aplikacionit) është një grup i të gjitha procedurave dhe funksioneve që na lejojnë të krijojmë një aplikacion duke aksesuar të dhënat ose veçoritë esistemit operativ ose platformave. Testimi i procedurave të tilla njihet si Testimi API.

Testimi Shift Majtas

Një nga llojet e rëndësishme të testimit që kërkohet në ditët e sotme në Intervistat e Testimit të API është Testimi Shift Majtas. Ky lloj testimi praktikohet pothuajse në të gjitha projektet që ndjekin një Metodologji Agile.

Para se të prezantohej Shift Left Testimi, testimi i softuerit u shfaq vetëm pasi ishte përfunduar kodimi dhe kodi iu dorëzua testuesve. Kjo praktikë çoi në nxitimin e minutës së fundit për të përmbushur afatin dhe gjithashtu pengoi në një masë të madhe cilësinë e produktit.

Përveç kësaj, përpjekjet e bëra (kur u raportuan defekte në fazën e fundit para prodhimit) ishin i madh pasi zhvilluesit duhej të kalonin përsëri në fazën e projektimit dhe të kodimit.

Cikli jetësor i zhvillimit të softuerit (SDLC) Para Shift Left Testimi

Rrjedha tradicionale SDLC ishte: Kërkesa - > Dizajni –> Kodimi –> Testimi.

Disavantazhet e testimit tradicional

• Testimi është në ekstremin e djathtë. Shumë kosto shkaktohen kur një defekt është identifikuar në minutën e fundit.
• Koha e harxhuar në zgjidhjen e defektit dhe ritestimin e tij përpara se ta promovojë atë në prodhim është e madhe.

Prandaj, u shfaq një ide e re për të zhvendosur fazën e testimit në të majtë, gjë që çoi në testimin e zhvendosjes majtas.

Leximi i sugjeruar => Testimi i zhvendosjes majtas: AMantra sekrete për suksesin e softuerit

Fazat e testimit të zhvendosjes majtas

Testimi i zhvendosjes majtas çoi në një migrim të suksesshëm nga Zbulimi i defekteve në Parandalimin e defekteve. Ai gjithashtu ndihmoi softuerin të dështonte shpejt dhe të rregullonte të gjitha dështimet sa më shpejt.

Web API

Në terma të përgjithshëm, një API Web mund të përkufizohet si diçka që merr kërkesën nga një klient sistemi në një server në internet dhe dërgon përgjigjen nga një server në internet në një makinë klienti.

Si funksionon një API?

Le të marrim një skenar shumë të zakonshëm të rezervimit të një fluturimi në www.makemytrip.com, i cili është një shërbim udhëtimi në internet që grumbullon informacione nga shumë linja ajrore. Kur shkoni për një rezervim fluturimi, futni informacione si data e udhëtimit/data e kthimit, klasa, etj. dhe klikoni në kërkim.

Kjo do t'ju tregojë çmimin e linjave ajrore të shumta dhe disponueshmërinë e tyre. Në këtë rast, aplikacioni ndërvepron me API-të e linjave ajrore të shumta dhe në këtë mënyrë jep akses në të dhënat e linjës ajrore.

Një shembull tjetër është www.trivago.com i cili krahason dhe rendit çmimin, disponueshmërinë, etj. të hoteleve të ndryshëm nga një qytet i caktuar. Kjo faqe interneti komunikon me API-të e shumë hoteleve për të hyrë në bazën e të dhënave dhe rendit çmimet dhe disponueshmërinë nga faqja e tyre e internetit.

Kështu, një API Web mund të përkufizohet si “një ndërfaqe që lehtëson komunikimin ndërmjet një makinerie klienti dhe tëwebserver”.

Shërbimet e uebit

Shërbimet e uebit janë (si Web API) shërbimet që shërbejnë nga një makinë në tjetrën. Por ndryshimi kryesor që lind midis API-së dhe Shërbimeve të Uebit është se Shërbimet e Uebit përdorin një rrjet.

Është e sigurt të thuhet se të gjitha Shërbimet e Uebit janë API Ueb, por të gjitha API-të e Uebit nuk janë Shërbime Ueb (shpjegohet në pjesa e fundit e artikullit). Kështu, Shërbimet e Uebit janë një nëngrup i Ueb API-së. Referojuni diagramit të mëposhtëm për të ditur më shumë rreth API-së së Uebit dhe Shërbimeve të Uebit.

API në internet kundrejt shërbimeve të uebit

Shërbimeve të uebit vs Web API

Si Web API dhe Web Services përdoren për të lehtësuar komunikimin midis klientit dhe serverit. Dallimi kryesor vjen vetëm në mënyrën se si ata komunikojnë.

Secili prej tyre kërkon një organ kërkese që është i pranueshëm në një gjuhë specifike, dallimet e tyre në sigurimin e një lidhjeje të sigurt, shpejtësinë e tyre të komunikimit me serverin dhe përgjigjen te klienti, etj.

Dallimet ndërmjet shërbimeve të uebit dhe API-së së uebit janë renditur më poshtë për referencën tuaj.

Shërbimi i uebit

• Shërbimet e uebit në përgjithësi përdorin XML (Extensible Markup Language), që do të thotë se ato janë më të sigurta.
• Shërbimet e uebit janë më të sigurta pasi si shërbimet e uebit ashtu edhe API-të ofrojnë SSL (Secure Socket Layer) gjatë transmetimit të të dhënave , por gjithashtu ofron WSS (Siguria e Shërbimeve të Uebit).
• Shërbimi i Uebit është një nëngrup i Ueb API-së. Për shembull, Shërbimet e Uebit bazohen vetëm në tre stile përdorimi, p.sh. SOAP, REST dhe XML-RPC.
• Shërbimet e uebit gjithmonë kanë nevojë për një rrjet për të funksionuar.
• Shërbimet në internet mbështesin “Aplikacione të ndryshme me një kod”. Kjo do të thotë se një kod më gjenerik është shkruar nëpër aplikacione të ndryshme.

Web API

• Një Web API në përgjithësi përdor JSON (JavaScript Object Notation), që do të thotë Web API është më i shpejtë.
• Web API është më i shpejtë pasi JSON është me peshë të lehtë, ndryshe nga XML.
• API-të e uebit janë superbashkësia e Shërbimeve Ueb. Për shembull, Të tre stilet e Shërbimeve të Uebit janë të pranishme edhe në API-në e Uebit, por përveç kësaj, ai përdor stile të tjera si JSON - RPC.
• API-ja e uebit nuk kërkon domosdoshmërisht një rrjet për të operuar.
• API-ja e uebit mund ose nuk mund të mbështesë ndërveprimin në varësi të natyrës së sistemit ose aplikacionit.

Prezantimi i testimit të API-së në organizatën tuaj

Në jetën tonë të përditshme, të gjithë ne jemi mësuar të ndërveprojmë me aplikacionet me API dhe megjithatë as që mendojmë për proceset e fundit që drejtojnë funksionalitetin themelor.

Për shembull , Le të marrim parasysh se po shfletoni produktet në Amazon.com dhe shihni një produkt/marrëveshje që ju pëlqen vërtet dhe dëshironi ta ndani me rrjetin tuaj Facebook.

Momenti kur klikoni në ikonën e Facebook në seksionin e ndarjes së faqes dhe futni tuajinKredencialet e llogarisë në Facebook për t'i ndarë, ju po ndërveproni me një API që po lidh pa probleme faqen e internetit të Amazon me Facebook.

Fokusohu te testimi API

Para se të diskutojmë më shumë për testimin e API, le të diskutojmë arsyet për të cilat aplikacionet e bazuara në API kanë fituar popullaritet kohët e fundit.

Ka disa arsye për të cilat organizatat po kalojnë në produktet dhe aplikacionet e bazuara në API. Dhe pak prej tyre janë renditur më poshtë për referencën tuaj.

#1) Aplikacionet e bazuara në API janë më të shkallëzueshme kur krahasohen me aplikacionet/softuerët tradicionalë. Shpejtësia e zhvillimit të kodit është më e shpejtë dhe e njëjta API mund të shërbejë më shumë kërkesa pa ndonjë kod të madh ose ndryshim infrastrukturor.

#2) Ekipet e zhvillimit nuk kanë nevojë të fillojnë kodimin nga e para çdo kur fillojnë të punojnë për zhvillimin e një veçorie ose aplikacioni. API-të më shpesh ripërdorin funksionet ekzistuese, të përsëritshme, bibliotekat, procedurat e ruajtura, etj. dhe për rrjedhojë ky proces mund t'i bëjë ato më produktive në përgjithësi.

Për shembull, Nëse jeni një zhvillues që punon në një uebsajti i tregtisë elektronike dhe ju dëshironi të shtoni Amazon si një procesor pagese – atëherë nuk keni pse ta shkruani kodin nga e para.

Gjithçka që duhet të bëni është të konfiguroni integrimin midis faqes suaj të internetit dhe Amazon API duke përdorur Çelësat e integrimit dhe telefononi Amazon API për përpunimin e pagesave gjatë përfundimit të blerjes.

#3) API-të lejojnëintegrim i lehtë me sistemet e tjera si për aplikacione të pavarura të mbështetura ashtu edhe me produkte softuerësh të bazuar në API.

Për shembull , Le të konsiderojmë se dëshironi të dërgoni një dërgesë nga Toronto në Nju Jork . Hyni në internet, navigoni në një faqe interneti të njohur të Transportit ose Logjistikës dhe futni informacionin e kërkuar.

Pas dhënies së informacionit të detyrueshëm, kur klikoni në butonin Merr Çmimet - në fund, kjo faqe interneti logjistike mund të jetë e lidhur me disa API dhe aplikacione të operatorëve dhe ofruesve të shërbimit për të marrë tarifat dinamike për kombinimin e vendndodhjeve nga fillimi në destinacion.

Spektri i plotë i testimit të API-së

Testimi i API-ve nuk kufizohet në dërgimin e një kërkese në API dhe duke analizuar përgjigjen vetëm për korrektësinë. API-të duhet të testohen për performancën e tyre nën ngarkesa të ndryshme për dobësi.

Le ta diskutojmë këtë në detaje.

(i) Testimi funksional

Testimi funksional mund të jetë një detyrë sfiduese për shkak të mungesës së një ndërfaqeje GUI.

Le të shohim se si qasja e testimit funksional për API-të është e ndryshme nga aplikacioni i bazuar në GUI dhe do të diskutojmë gjithashtu disa shembuj rreth tij.

a) Dallimi më i dukshëm është se nuk ka GUI për të bashkëvepruar. Testuesit që zakonisht bëjnë testimin funksional të bazuar në GUI e kanë pak më të vështirë të kalojnë në testimin e aplikacioneve jo-GUI kur krahasohen medikush që tashmë është i njohur me të.

Fillimisht, edhe para se të filloni testimin e API-së, do t'ju duhet të testoni dhe verifikoni vetë procesin e vërtetimit. Metoda e vërtetimit do të ndryshojë nga një API në një API tjetër dhe do të përfshijë një lloj çelësi ose token për vërtetim.

Nëse nuk jeni në gjendje të lidheni me API-në me sukses, atëherë testimi i mëtejshëm nuk mund të vazhdojë. Ky proces mund të konsiderohet i krahasueshëm me vërtetimin e përdoruesit në aplikacionet standarde ku ju nevojiten kredenciale të vlefshme për t'u identifikuar dhe përdorur aplikacionin.

b) Testimi i verifikimeve të fushës ose vërtetimi i të dhënave hyrëse është shumë i rëndësishëm gjatë testimit të API-ve. Nëse ekzistonte një ndërfaqe aktuale e bazuar në forma (GUI), atëherë verifikimet e fushës mund të zbatoheshin në pjesën e përparme ose të pasme, duke siguruar kështu që një përdorues të mos lejohet të fusë vlera të pavlefshme fushash.

Për shembull, Nëse një aplikacion ka nevojë që formati i datës të jetë DD/MM/VVVV, atëherë ne mund ta zbatojmë këtë vërtetim në formularin që mbledh informacion për të siguruar që aplikacioni po merr dhe po përpunon një datë të vlefshme.

Megjithatë, kjo nuk është e njëjtë për aplikacionet API. Ne duhet të sigurohemi që API të jetë shkruar mirë dhe të jetë në gjendje të zbatojë të gjitha këto vërtetime, të bëjë dallimin midis të dhënave të vlefshme dhe të pavlefshme dhe t'i kthejë përdoruesit fundor kodin e statusit dhe mesazhin e gabimit të vlefshmërisë përmes një përgjigjeje.

c) Testimi i