- API પરીક્ષણ ટ્યુટોરિયલ્સની સૂચિ
- આ API પરીક્ષણ શ્રેણીમાં ટ્યુટોરિયલ્સની ઝાંખી
- નિષ્કર્ષ
- API પરીક્ષણ ટ્યુટોરીયલ
- તમારી સંસ્થામાં API પરીક્ષણ રજૂ કરી રહ્યું છે
આ ઊંડાણપૂર્વકનું API પરીક્ષણ ટ્યુટોરીયલ API પરીક્ષણ, વેબ સેવાઓ અને તમારી સંસ્થામાં API પરીક્ષણ કેવી રીતે રજૂ કરવું તે વિશે બધું સમજાવે છે:
એપીઆઈ પરીક્ષણની સાથે સાથે ઊંડી સમજ મેળવો આ પ્રારંભિક ટ્યુટોરીયલમાંથી શિફ્ટ-ડાબે પરીક્ષણ અને વેબ સેવાઓનો ખ્યાલ.
વેબ API, API કેવી રીતે કાર્ય કરે છે (વાસ્તવિક-વિશ્વના ઉદાહરણ સાથે) અને તે વેબ સેવાઓથી કેવી રીતે અલગ છે તે આમાં ઉદાહરણો સાથે સારી રીતે સમજાવવામાં આવ્યું છે. ટ્યુટોરીયલ.
API પરીક્ષણ ટ્યુટોરિયલ્સની સૂચિ
ટ્યુટોરીયલ #1: API પરીક્ષણ ટ્યુટોરીયલ: નવા નિશાળીયા માટે સંપૂર્ણ માર્ગદર્શિકા
ટ્યુટોરીયલ #2: વેબ સેવાઓ ટ્યુટોરીયલ: ઘટકો, આર્કિટેક્ચર, પ્રકારો & ઉદાહરણો
ટ્યુટોરીયલ #3: જવાબો સાથે ટોચના 35 ASP.Net અને વેબ API ઇન્ટરવ્યુ પ્રશ્નો
ટ્યુટોરીયલ #4: પોસ્ટમેન ટ્યુટોરીયલ: API પરીક્ષણ પોસ્ટમેનનો ઉપયોગ કરવો
ટ્યુટોરીયલ #5: અપાચે HTTP ક્લાયંટનો ઉપયોગ કરીને વેબ સેવાઓનું પરીક્ષણ
આ API પરીક્ષણ શ્રેણીમાં ટ્યુટોરિયલ્સની ઝાંખી
| ટ્યુટોરીયલ # | તમે શું શીખશો | |||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ટ્યુટોરીયલ_#1: | API પરીક્ષણ ટ્યુટોરીયલ : નવા નિશાળીયા માટે સંપૂર્ણ માર્ગદર્શિકા આ ઊંડાણપૂર્વકનું API પરીક્ષણ ટ્યુટોરીયલ API પરીક્ષણ અને વેબ સેવાઓ વિશે વિગતવાર સમજાવશે અને તમારી સંસ્થામાં API પરીક્ષણ કેવી રીતે રજૂ કરવું તે વિશે તમને શિક્ષિત કરશે. | |||||||||||||||||||||||||||||||||||||||||||||
| ટ્યુટોરીયલ_#2: | વેબ સર્વિસીસ ટ્યુટોરીયલ: ઘટકો, આર્કિટેક્ચર, પ્રકારો & ઉદાહરણો આ વેબમાન્ય અને અમાન્ય પ્રતિસાદ માટે API ના પ્રતિસાદોની શુદ્ધતા ખરેખર નિર્ણાયક છે. જો ટેસ્ટ API તરફથી પ્રતિભાવ તરીકે 200 નો સ્ટેટસ કોડ (એટલે કે બધુ ઠીક છે) પ્રાપ્ત થાય છે, પરંતુ જો પ્રતિભાવ ટેક્સ્ટ કહે છે કે ભૂલ આવી છે, તો આ એક ખામી છે. વધુમાં, જો ભૂલ સંદેશ તે પોતે જ ખોટું છે, તો પછી આ API સાથે સંકલન કરવાનો પ્રયાસ કરી રહેલા અંતિમ ગ્રાહક માટે તે ખૂબ જ ભ્રામક હોઈ શકે છે. નીચેના સ્ક્રીનશોટમાં, વપરાશકર્તાએ અમાન્ય વજન દાખલ કર્યું છે, જે સ્વીકાર્ય 2267 Kgs કરતાં વધુ છે. API ભૂલ સ્થિતિ કોડ અને ભૂલ સંદેશ સાથે જવાબ આપે છે. જો કે, ભૂલ સંદેશમાં KG ને બદલે lbs તરીકે વજનના એકમોનો ખોટી રીતે ઉલ્લેખ કરવામાં આવ્યો છે. આ એક ખામી છે જે અંતિમ ગ્રાહકને મૂંઝવણમાં મૂકી શકે છે. (ii) લોડ અને પ્રદર્શન પરીક્ષણAPI એ ડિઝાઇન દ્વારા માપી શકાય તેવું છે. આ, બદલામાં, લોડ અને પર્ફોર્મન્સ ટેસ્ટિંગને આવશ્યક બનાવે છે, ખાસ કરીને જો સિસ્ટમ ડિઝાઇન કરવામાં આવી રહી હોય તો તે જરૂરિયાતના આધારે, મિનિટ અથવા કલાક દીઠ હજારો વિનંતીઓની સેવા આપે તેવી અપેક્ષા હોય. API પર નિયમિતપણે લોડ અને પરફોર્મન્સ પરીક્ષણો કરવાથી પ્રદર્શન, પીક લોડ અને બ્રેકિંગ પોઈન્ટ બેન્ચમાર્ક કરવામાં મદદ મળી શકે છે. એપ્લિકેશનને સ્કેલ કરવાની યોજના કરતી વખતે આ ડેટા ઉપયોગી છે. આ માહિતી ઉપલબ્ધ રાખવાથી નિર્ણયો અને આયોજનને સમર્થન આપવામાં મદદ મળશે, ખાસ કરીને જો સંસ્થા વધુ ગ્રાહકો ઉમેરવાનું આયોજન કરી રહી હોય, જેનો અર્થ વધુ ઇનકમિંગ થશે.વિનંતીઓ. તમારી સંસ્થામાં API પરીક્ષણ કેવી રીતે રજૂ કરવુંકોઈપણ સંસ્થામાં API પરીક્ષણ રજૂ કરવાની પ્રક્રિયા અન્ય કોઈપણ પરીક્ષણ સાધન અને ફ્રેમવર્કને અમલમાં મૂકવા અથવા રોલઆઉટ કરવા માટે વપરાતી પ્રક્રિયા જેવી જ છે. નીચેનું કોષ્ટક દરેક પગલાના અપેક્ષિત પરિણામ સાથે મુખ્ય પગલાઓનો સારાંશ આપે છે.
સામાન્ય પડકારો અને તેને ઘટાડવાની રીતોચાલો આપણે QA ટીમો દ્વારા આવતા કેટલાક સામાન્ય પડકારોની ચર્ચા કરીએ સંસ્થામાં API પરીક્ષણ ફ્રેમવર્ક લાગુ કરવાનો પ્રયાસ કરતી વખતે સામનો કરવો પડે છે. #1) યોગ્ય સાધન પસંદ કરવુંજોબ માટે યોગ્ય સાધન પસંદ કરવું એ સૌથી સામાન્ય પડકાર છે. ઘણા API ટેસ્ટ ટૂલ્સ છે જે બજારમાં ઉપલબ્ધ છે. બજારમાં ઉપલબ્ધ નવીનતમ, સૌથી મોંઘા ટૂલનો અમલ કરવો તે ખૂબ જ આકર્ષક લાગે છે- પરંતુ જો તે ઇચ્છિત પરિણામો લાવતું નથી, તો તે સાધન કોઈ કામનું નથી. તેથી, હંમેશા તમારી સંસ્થાકીય જરૂરિયાતોને આધારે 'હોવી જોઈએ' જરૂરિયાતોને સંબોધતું સાધન પસંદ કરો. અહીં એક નમૂના સાધન મૂલ્યાંકન મેટ્રિક્સ છે ઉપલબ્ધ API સાધનો
#2) ખૂટે છે પરીક્ષણ વિશિષ્ટતાઓપરીક્ષકો તરીકે, આપણે જાણવાની જરૂર છે એપ્લિકેશનને અસરકારક રીતે ચકાસવા માટે અપેક્ષિત પરિણામો. આ ઘણીવાર એક પડકાર હોય છે, કારણ કે અપેક્ષિત પરિણામો જાણવા માટે, અમારી પાસે સ્પષ્ટ ચોક્કસ જરૂરિયાતો હોવી જરૂરી છે – જે એવું નથી. ઉદાહરણ તરીકે , નીચે આપેલી આવશ્યકતાઓને ધ્યાનમાં લો: “એપ્લિકેશન માત્ર એક માન્ય શિપિંગ તારીખ જ સ્વીકારવી જોઈએ અને બધી અમાન્ય આવશ્યકતાઓને નકારી કાઢવી જોઈએ” આ આવશ્યકતાઓમાં મુખ્ય વિગતો ખૂટે છે અને તે ખૂબ જ અસ્પષ્ટ છે – અમે માન્ય તારીખ કેવી રીતે વ્યાખ્યાયિત કરીએ છીએ? ફોર્મેટ વિશે શું? શું અમે અંતિમ-વપરાશકર્તાને કોઈ અસ્વીકાર સંદેશ પરત કરી રહ્યા છીએ, વગેરે.? સ્પષ્ટ આવશ્યકતાઓનું ઉદાહરણ: 1) એપ્લિકેશન માત્ર હોવી જોઈએ માન્ય શિપિંગ તારીખ સ્વીકારો. શિપિંગ તારીખ માન્ય ગણવામાં આવે છે જો તેછે
2) પ્રતિસાદ સ્થિતિ કોડ = 200 સંદેશ: ઓકે 3) શિપિંગ તારીખ ઉપરોક્ત માપદંડોને પૂર્ણ કરતું નથી તે અમાન્ય ગણવું જોઈએ. જો કોઈ ગ્રાહક અમાન્ય શિપિંગ તારીખ મોકલે છે, તો તેણે નીચેના ભૂલ સંદેશ(ઓ) સાથે પ્રતિસાદ આપવો જોઈએ: 3.1 પ્રતિસાદ સ્થિતિ કોડ 200 નથી ભૂલ: પ્રદાન કરેલ શિપિંગ તારીખ અમાન્ય છે; કૃપા કરીને ખાતરી કરો કે તારીખ DD/MM/YYYY ફોર્મેટમાં છે 3.2 પ્રતિસાદ સ્થિતિ કોડ 200 નથી ભૂલ: પ્રદાન કરેલ શિપિંગ તારીખ છે ભૂતકાળ #3) લર્નિંગ કર્વઅગાઉ ઉલ્લેખ કર્યો છે તેમ, GUI આધારિત એપ્લિકેશનનું પરીક્ષણ કરતી વખતે અનુસરવામાં આવતા અભિગમની સરખામણીમાં API પરીક્ષણ માટેનો અભિગમ અલગ છે. જો તમે એપીઆઈ ટેસ્ટિંગ માટે ઈન-હાઉસ અથવા કન્સલ્ટન્ટની નિમણૂક કરી રહ્યાં છે, તો પછી એપીઆઈ ટેસ્ટ એપ્રોચ અથવા એપીઆઈ ટેસ્ટ ટૂલનું લર્નિંગ કર્વ ન્યૂનતમ હોઈ શકે છે. કોઈપણ શીખવાની કર્વ, આ કિસ્સામાં, ઉત્પાદન અથવા એપ્લિકેશન જ્ઞાન પ્રાપ્ત કરવા સાથે સંકળાયેલ હશે. જો કોઈ વર્તમાન ટીમ સભ્યને API પરીક્ષણ શીખવા માટે સોંપવામાં આવે છે, તો પસંદગીના સાધનના આધારે, શીખવાની કર્વ હોઈ શકે છે. પરીક્ષણ અભિગમ બદલવાની સાથે મધ્યમથી ઉચ્ચ. આ પરીક્ષકે પરીક્ષણ કર્યું છે કે કેમ તેના આધારે ઉત્પાદન અથવા એપ્લિકેશન માટે શીખવાની કર્વ નીચી-મધ્યમ હોઈ શકે છેતે એપ્લિકેશન પહેલાં કે નહીં. #4) હાલનો કૌશલ્ય સમૂહઆ શીખવાની કર્વ વિશેના અગાઉના મુદ્દા સાથે સીધો સંબંધ ધરાવે છે. જો કોઈ પરીક્ષક અહીંથી સંક્રમિત થઈ રહ્યો હોય GUI આધારિત પરીક્ષણ, પછી પરીક્ષકને પરીક્ષણ અભિગમ બદલવાની જરૂર પડશે અને આવશ્યકતા મુજબ નવું સાધન અથવા ફ્રેમવર્ક શીખવું પડશે. દા.ત. જો API JSON ફોર્મેટમાં વિનંતીઓ સ્વીકારે છે, તો પરીક્ષણો બનાવવાનું શરૂ કરવા માટે, પરીક્ષકને JSON શું છે તે જાણવાની જરૂર પડશે. કેસ સ્ટડીટાસ્ક હાલની એપ્લિકેશનને વધારવા માટે, કંપની API તેમજ પ્રમાણભૂત GUI એપ્લિકેશનમાં ઉત્પાદન ઓફર કરવા માંગતી હતી. QA ટીમને એ સુનિશ્ચિત કરવા માટે ટેસ્ટ કવરેજ પ્લાન પ્રદાન કરવા માટે કહેવામાં આવ્યું હતું કે તેઓ નિયમિત GUI આધારિત પરીક્ષણો ઉપરાંત API પરીક્ષણને સમાવવા માટે તૈયાર છે. પડકો
જોખમોને ઘટાડવા અને પડકારોની આસપાસ કામ કરવા માટે ટીમ દ્વારા અનુસરવામાં આવેલ અભિગમ
| |||||||||||||||||||||||||||||||||||||||||||||
| ટ્યુટોરીયલ_#3: | જવાબો સાથે ટોચના 35 ASP.Net અને વેબ API ઇન્ટરવ્યુ પ્રશ્નો તમે સૌથી વધુ લોકપ્રિય વારંવાર પૂછાતા ASP.Net અને વેબ API ઇન્ટરવ્યુ પ્રશ્નોની યાદીને જવાબો સાથે શોધી શકો છો & આ ટ્યુટોરીયલમાં નવા નિશાળીયા અને અનુભવી વ્યાવસાયિકો માટે ઉદાહરણો POSTMAN આ સ્ટેપ બાય સ્ટેપ ટ્યુટોરીયલ પોસ્ટમેનની મૂળભૂત બાબતો, તેના ઘટકો અને નમૂના વિનંતી & તમારી સરળ સમજણ માટે સરળ શબ્દોમાં પ્રતિસાદ આપો. | |||||||||||||||||||||||||||||||||||||||||||||
| ટ્યુટોરીયલ_#5: | અપાચે HTTP ક્લાયંટનો ઉપયોગ કરીને વેબ સેવાઓનું પરીક્ષણ આ API ટ્યુટોરીયલ વેબ સેવાઓ પર વિવિધ CRUD ઓપરેશન્સ કરવા અને Apache HTTP ક્લાયંટનો ઉપયોગ કરીને વેબ સેવાઓનું પરીક્ષણ કરવા વિશે છે |
API પરીક્ષણ ટ્યુટોરીયલ
આ વિભાગ તમને વેબ સેવાઓ અને વેબ API ની મૂળભૂત સમજ મેળવવામાં મદદ કરશે, જે બદલામાં, આ API પરીક્ષણ શ્રેણીના આગામી ટ્યુટોરિયલ્સમાં મુખ્ય ખ્યાલોને સમજવામાં મદદરૂપ થશે.
API ( એપ્લીકેશન પ્રોગ્રામિંગ ઈન્ટરફેસ) એ બધી પ્રક્રિયાઓ અને કાર્યોનો સમૂહ છે જે અમને ડેટા અથવા સુવિધાઓને ઍક્સેસ કરીને એપ્લિકેશન બનાવવાની મંજૂરી આપે છે.ઓપરેટિંગ સિસ્ટમ અથવા પ્લેટફોર્મ. આવી પ્રક્રિયાઓના પરીક્ષણને API ટેસ્ટિંગ તરીકે ઓળખવામાં આવે છે.
શિફ્ટ લેફ્ટ ટેસ્ટિંગ
આજકાલ API ટેસ્ટિંગ ઇન્ટરવ્યુમાં પૂછવામાં આવતા મહત્ત્વના પ્રકારનાં પરીક્ષણોમાંનું એક શિફ્ટ લેફ્ટ ટેસ્ટિંગ છે. ચપળ પદ્ધતિને અનુસરતા લગભગ તમામ પ્રોજેક્ટ્સમાં આ પ્રકારનું પરીક્ષણ પ્રેક્ટિસ કરવામાં આવે છે.
શિફ્ટ લેફ્ટ ટેસ્ટિંગ રજૂ કરવામાં આવે તે પહેલાં, કોડિંગ પૂર્ણ થયા પછી અને ટેસ્ટર્સને કોડ વિતરિત કરવામાં આવ્યા પછી જ સૉફ્ટવેર પરીક્ષણ ચિત્રમાં આવ્યું હતું. આ પ્રથાને કારણે સમયમર્યાદા પૂરી કરવા માટે છેલ્લી ઘડીની ઉતાવળ થઈ અને તે ઉત્પાદનની ગુણવત્તાને પણ ઘણી હદ સુધી અવરોધે છે.
તે સિવાય, કરવામાં આવેલા પ્રયત્નો (જ્યારે ઉત્પાદન પહેલાંના છેલ્લા તબક્કામાં ખામીની જાણ કરવામાં આવી હતી) વિકાસકર્તાઓએ ફરીથી ડિઝાઇન અને કોડિંગ બંને તબક્કામાંથી પસાર થવું પડ્યું હતું.
સોફ્ટવેર ડેવલપમેન્ટ લાઇફ સાયકલ (SDLC) શિફ્ટ લેફ્ટ ટેસ્ટિંગ પહેલાં
પરંપરાગત SDLC પ્રવાહ હતો: જરૂરિયાત – > ડિઝાઇન –> કોડિંગ –> પરીક્ષણ.
પરંપરાગત પરીક્ષણના ગેરફાયદા
- પરીક્ષણ અત્યંત જમણી બાજુએ છે. જ્યારે છેલ્લી ઘડીએ બગ ઓળખવામાં આવે છે ત્યારે ઘણો ખર્ચ થાય છે.
- બગને ઉકેલવામાં અને તેને પ્રોડક્શનમાં પ્રમોટ કરતા પહેલા તેનું પુનઃ પરીક્ષણ કરવામાં ઘણો સમય લાગે છે.
તેથી, ટેસ્ટિંગના તબક્કાને ડાબી તરફ શિફ્ટ કરવા માટે એક નવો વિચાર આવ્યો જેનાથી લેફ્ટ ટેસ્ટિંગ શિફ્ટ થઈ.
સૂચિત રીડ => લેફ્ટ ટેસ્ટિંગ શિફ્ટ કરો: Aસૉફ્ટવેર સફળતા માટેનો ગુપ્ત મંત્ર
લેફ્ટ શિફ્ટ ટેસ્ટિંગના તબક્કાઓ
ડાબી પાળી પરીક્ષણને કારણે ખામી શોધમાંથી ખામી નિવારણ તરફ સફળ સ્થળાંતર થયું. તે સૉફ્ટવેરને ઝડપથી નિષ્ફળ થવામાં અને તમામ નિષ્ફળતાઓને વહેલી તકે ઠીક કરવામાં પણ મદદ કરે છે.
Web API
સામાન્ય શબ્દોમાં, વેબ API ને એવી વસ્તુ તરીકે વ્યાખ્યાયિત કરી શકાય છે જે ક્લાયન્ટની વિનંતીને સ્વીકારે છે. સિસ્ટમ વેબ સર્વર પર મોકલે છે અને વેબ સર્વરથી ક્લાયંટ મશીન પર પ્રતિભાવ પાછો મોકલે છે.
API કેવી રીતે કાર્ય કરે છે?
ચાલો www.makemytrip.com પર ફ્લાઇટ બુક કરાવવાનું એક ખૂબ જ સામાન્ય દૃશ્ય લઈએ, જે એક ઓનલાઈન ટ્રાવેલ સર્વિસ છે જે બહુવિધ એરલાઈન્સની માહિતી એકત્ર કરે છે. જ્યારે તમે ફ્લાઇટ બુકિંગ માટે જાઓ છો, ત્યારે તમે મુસાફરીની તારીખ/વાપસીની તારીખ, વર્ગ વગેરે જેવી માહિતી દાખલ કરો છો અને શોધ પર ક્લિક કરો છો.
આ તમને બહુવિધ એરલાઇન્સની કિંમત અને તેમની ઉપલબ્ધતા બતાવશે. આ કિસ્સામાં, એપ્લિકેશન બહુવિધ એરલાઇન્સના API સાથે ક્રિયાપ્રતિક્રિયા કરે છે અને ત્યાંથી એરલાઇનના ડેટાની ઍક્સેસ આપે છે.
બીજું ઉદાહરણ છે www.trivago.com જે વિવિધ હોટલોની કિંમત, ઉપલબ્ધતા વગેરેની તુલના કરે છે અને સૂચિબદ્ધ કરે છે. ચોક્કસ શહેરમાંથી. આ વેબસાઈટ ડેટાબેઝને એક્સેસ કરવા માટે બહુવિધ હોટલના API સાથે સંચાર કરે છે અને તેમની વેબસાઈટ પરથી કિંમતો અને ઉપલબ્ધતાની યાદી આપે છે.
આ રીતે, વેબ API ને "એક ઈન્ટરફેસ તરીકે વ્યાખ્યાયિત કરી શકાય છે જે ક્લાઈન્ટ મશીન અને વચ્ચે સંચારની સુવિધા આપે છે. આwebserver”.
વેબ સેવાઓ
વેબ સેવાઓ (વેબ API જેવી) એવી સેવાઓ છે જે એક મશીનથી બીજા મશીનમાં સેવા આપે છે. પરંતુ API અને વેબ સેવાઓ વચ્ચે જે મુખ્ય તફાવત ઉદ્ભવે છે તે એ છે કે વેબ સેવાઓ નેટવર્કનો ઉપયોગ કરે છે.
એ કહેવું સલામત છે કે બધી વેબ સેવાઓ વેબ API છે પરંતુ તમામ વેબ API વેબ સેવાઓ નથી (માં સમજાવેલ છે. લેખનો પછીનો ભાગ). આમ, વેબ સેવાઓ એ વેબ API નો સબસેટ છે. વેબ API અને વેબ સેવાઓ વિશે વધુ જાણવા માટે નીચેના રેખાકૃતિનો સંદર્ભ લો.
વેબ API vs વેબ સેવાઓ
વેબ સેવાઓ વિ. વેબ API
વેબ API અને વેબ સેવાઓ બંનેનો ઉપયોગ ક્લાયંટ અને સર્વર વચ્ચેના સંચારને સરળ બનાવવા માટે થાય છે. મુખ્ય તફાવત ફક્ત તેઓ જે રીતે સંચાર કરે છે તેમાં આવે છે.
તેમાંના દરેકને એક વિનંતી સંસ્થાની જરૂર હોય છે જે ચોક્કસ ભાષામાં સ્વીકાર્ય હોય, સુરક્ષિત કનેક્શન પ્રદાન કરવામાં તેમના તફાવતો, સર્વર સાથે વાતચીત કરવાની અને જવાબ આપવાની તેમની ઝડપ. ક્લાયન્ટને, વગેરે.
વેબ સેવાઓ અને વેબ API વચ્ચેના તફાવતો તમારા સંદર્ભ માટે નીચે સૂચિબદ્ધ છે.
વેબ સેવા
- વેબ સેવાઓ સામાન્ય રીતે XML (એક્સ્ટેન્સિબલ માર્કઅપ લેંગ્વેજ) નો ઉપયોગ કરે છે, જેનો અર્થ છે કે તેઓ વધુ સુરક્ષિત છે.
- વેબ સેવાઓ વધુ સુરક્ષિત છે કારણ કે વેબ સેવાઓ અને API બંને ડેટા ટ્રાન્સમિશન દરમિયાન SSL (સિક્યોર સોકેટ લેયર) પ્રદાન કરે છે. , પરંતુ તે WSS (વેબ સેવાઓ સુરક્ષા) પણ પ્રદાન કરે છે.
- વેબ સેવા એ વેબ API નો સબસેટ છે. ઉદાહરણ તરીકે, વેબ સેવાઓ માત્ર ઉપયોગની ત્રણ શૈલીઓ પર આધારિત છે એટલે કે SOAP, REST અને XML-RPC.
- વેબ સેવાઓને ઓપરેટ કરવા માટે હંમેશા નેટવર્કની જરૂર હોય છે.
- વેબ સેવાઓ "વન કોડ વિવિધ એપ્લિકેશનો" ને સપોર્ટ કરે છે. આનો અર્થ એ છે કે વિવિધ એપ્લિકેશનોમાં વધુ સામાન્ય કોડ લખવામાં આવે છે.
વેબ API
- એક વેબ API સામાન્ય રીતે JSON (જાવાસ્ક્રિપ્ટ ઑબ્જેક્ટ નોટેશન) નો ઉપયોગ કરે છે. જેનો અર્થ છે કે વેબ API ઝડપી છે.
- વેબ API ઝડપી છે કારણ કે JSON હળવા વજનનું છે, XMLથી વિપરીત.
- વેબ API એ વેબ સેવાઓનો સુપરસેટ છે. ઉદાહરણ તરીકે, વેબ એપીઆઈમાં વેબ સેવાઓની ત્રણેય શૈલીઓ પણ હાજર છે, પરંતુ તે સિવાય, તે JSON – RPC જેવી અન્ય શૈલીઓનો ઉપયોગ કરે છે.
- વેબ API જરૂરી નથી. ઓપરેટ કરવા માટેનું નેટવર્ક.
- વેબ API સિસ્ટમ અથવા એપ્લિકેશનની પ્રકૃતિને આધારે આંતરસંચાલનક્ષમતાને સમર્થન આપી શકે છે અથવા ન પણ કરી શકે છે.
તમારી સંસ્થામાં API પરીક્ષણ રજૂ કરી રહ્યું છે
આપણા રોજિંદા જીવનમાં, આપણે બધા એપીઆઈ સાથેની એપ્લિકેશનો સાથે ક્રિયાપ્રતિક્રિયા કરવા માટે એટલા ટેવાયેલા છીએ અને તેમ છતાં આપણે બેક-એન્ડ પ્રક્રિયાઓ વિશે વિચારતા પણ નથી જે અંતર્ગત કાર્યક્ષમતાને ચલાવે છે.
ઉદાહરણ તરીકે , ચાલો આપણે ધ્યાનમાં લઈએ કે તમે Amazon.com પર પ્રોડક્ટ્સ બ્રાઉઝ કરી રહ્યાં છો અને તમને ખરેખર ગમતી પ્રોડક્ટ/ડીલ દેખાય છે અને તમે તેને તમારા Facebook નેટવર્ક સાથે શેર કરવા માંગો છો.
તમે ક્લિક કરો છો તે જ ક્ષણે. પૃષ્ઠના શેર વિભાગ પરના Facebook આઇકોન પર અને તમારું દાખલ કરોશેર કરવા માટે Facebook એકાઉન્ટ ઓળખપત્રો, તમે એક API સાથે ક્રિયાપ્રતિક્રિયા કરી રહ્યાં છો જે એકીકૃત રીતે Amazon વેબસાઇટને Facebook સાથે જોડે છે.
API પરીક્ષણ પર ફોકસ શિફ્ટ કરો
API પરીક્ષણ પર વધુ ચર્ચા કરતા પહેલા, ચાલો કારણોની ચર્ચા કરીએ જેના માટે API આધારિત એપ્લીકેશનોએ તાજેતરના સમયમાં લોકપ્રિયતા મેળવી છે.
સંસ્થાઓ API આધારિત ઉત્પાદનો અને એપ્લીકેશનોમાં સંક્રમણ કરી રહી છે તેવા ઘણા કારણો છે. અને તેમાંથી થોડા તમારા સંદર્ભ માટે નીચે સૂચિબદ્ધ છે.
#1) પરંપરાગત એપ્લિકેશન/સોફ્ટવેરની સરખામણીમાં API આધારિત એપ્લીકેશન વધુ સ્કેલેબલ છે. કોડ ડેવલપમેન્ટનો દર વધુ ઝડપી છે અને સમાન API કોઈપણ મોટા કોડ અથવા ઈન્ફ્રાસ્ટ્રક્ચરલ ફેરફારો વિના વધુ વિનંતીઓ કરી શકે છે.
#2) ડેવલપમેન્ટ ટીમોએ દરેક શરૂઆતથી કોડિંગ શરૂ કરવાની જરૂર નથી જ્યારે તેઓ કોઈ સુવિધા અથવા એપ્લિકેશન વિકસાવવા પર કામ કરવાનું શરૂ કરે છે. API મોટાભાગે અસ્તિત્વમાંના, પુનરાવર્તિત કાર્યો, લાઇબ્રેરીઓ, સંગ્રહિત પ્રક્રિયાઓ વગેરેનો પુનઃઉપયોગ કરે છે અને તેથી આ પ્રક્રિયા તેમને એકંદરે વધુ ઉત્પાદક બનાવી શકે છે.
ઉદાહરણ તરીકે, જો તમે વિકાસકર્તા છો ઈ-કોમર્સ વેબસાઈટ અને તમે એમેઝોનને પેમેન્ટ પ્રોસેસર તરીકે ઉમેરવા માંગો છો - તો તમારે શરૂઆતથી કોડ લખવાની જરૂર નથી.
તમારે ફક્ત તમારી વેબસાઈટ અને એમેઝોન API નો ઉપયોગ કરીને એકીકરણ સેટ કરવાનું છે. ચેકઆઉટ દરમિયાન ચૂકવણીની પ્રક્રિયા કરવા માટે એકીકરણ કીઓ અને એમેઝોન API પર કૉલ કરો.
#3) API મંજૂરી આપે છેસપોર્ટેડ સ્ટેન્ડઅલોન એપ્લીકેશન તેમજ API આધારિત સોફ્ટવેર ઉત્પાદનો બંને માટે અન્ય સિસ્ટમો સાથે સરળ સંકલન.
ઉદાહરણ તરીકે , ચાલો આપણે ધ્યાનમાં લઈએ કે તમે ટોરોન્ટોથી ન્યૂયોર્ક સુધી શિપમેન્ટ મોકલવા માંગો છો. . તમે ઓનલાઈન જાઓ, સારી રીતે જાણીતી ફ્રેઈટ અથવા લોજિસ્ટિક્સ વેબસાઈટ પર નેવિગેટ કરો અને જરૂરી માહિતી દાખલ કરો.
ફરજિયાત માહિતી આપ્યા પછી, જ્યારે તમે ગેટ રેટ્સ બટન પર ક્લિક કરો છો - પાછળના ભાગમાં, આ લોજિસ્ટિક્સ વેબસાઈટ કનેક્ટ થઈ શકે છે. સ્થાનોના મૂળથી ગંતવ્ય સંયોજન માટે ગતિશીલ દરો મેળવવા માટે ઘણા વાહક અને સેવા પ્રદાતા API અને એપ્લિકેશનો સાથે.
API પરીક્ષણનું સંપૂર્ણ સ્પેક્ટ્રમ
API નું પરીક્ષણ વિનંતી મોકલવા માટે પ્રતિબંધિત નથી API માટે અને માત્ર શુદ્ધતા માટે પ્રતિભાવનું વિશ્લેષણ. નબળાઈઓ માટે અલગ-અલગ લોડ હેઠળ તેમના પ્રદર્શન માટે API ને પરીક્ષણ કરવાની જરૂર છે.
ચાલો આની વિગતવાર ચર્ચા કરીએ.
(i) કાર્યાત્મક પરીક્ષણ
GUI ઈન્ટરફેસના અભાવને કારણે કાર્યાત્મક પરીક્ષણ એ એક પડકારરૂપ કાર્ય હોઈ શકે છે.
ચાલો જોઈએ કે API માટે કાર્યાત્મક પરીક્ષણ અભિગમ GUI આધારિત એપ્લિકેશનથી કેવી રીતે અલગ છે અને અમે તેની આસપાસના કેટલાક ઉદાહરણોની પણ ચર્ચા કરીશું.
a) સૌથી સ્પષ્ટ તફાવત એ છે કે ક્રિયાપ્રતિક્રિયા કરવા માટે કોઈ GUI નથી. સામાન્ય રીતે GUI આધારિત ફંક્શનલ ટેસ્ટિંગ કરતા પરીક્ષકોને તેની સરખામણીમાં બિન-GUI એપ્લિકેશન પરીક્ષણમાં સંક્રમણ કરવું થોડું મુશ્કેલ લાગે છે.કોઈ વ્યક્તિ જે પહેલાથી જ તેનાથી પરિચિત છે.
શરૂઆતમાં, તમે API નું પરીક્ષણ કરવાનું શરૂ કરો તે પહેલાં પણ, તમારે પ્રમાણીકરણ પ્રક્રિયાને જ ચકાસવાની અને ચકાસવાની જરૂર પડશે. પ્રમાણીકરણ પદ્ધતિ એક API થી બીજા API માં બદલાશે અને પ્રમાણીકરણ માટે અમુક પ્રકારની કી અથવા ટોકનનો સમાવેશ કરશે.
જો તમે API સાથે સફળતાપૂર્વક કનેક્ટ કરવામાં અસમર્થ છો, તો પછી આગળનું પરીક્ષણ આગળ વધી શકશે નહીં. આ પ્રક્રિયાને પ્રમાણભૂત એપ્લિકેશન્સમાં વપરાશકર્તા પ્રમાણીકરણ સાથે તુલનાત્મક ગણી શકાય જ્યાં તમને લૉગ ઇન કરવા અને એપ્લિકેશનનો ઉપયોગ કરવા માટે માન્ય ઓળખપત્રોની જરૂર હોય.
b) ફીલ્ડ માન્યતા અથવા ઇનપુટ ડેટા માન્યતાનું પરીક્ષણ કરવું ખૂબ જ મહત્વપૂર્ણ છે પરીક્ષણ APIs દરમિયાન. જો વાસ્તવિક ફોર્મ-આધારિત (GUI) ઈન્ટરફેસ ઉપલબ્ધ હોત, તો ફીલ્ડ માન્યતાને આગળના છેડે અથવા પાછળના છેડે અમલમાં મૂકી શકાય છે, જેનાથી ખાતરી થાય છે કે વપરાશકર્તાને અમાન્ય ફીલ્ડ મૂલ્યો દાખલ કરવાની મંજૂરી નથી.
ઉદાહરણ તરીકે, જો કોઈ એપ્લિકેશનને DD/MM/YYYY હોવા માટે તારીખ ફોર્મેટની જરૂર હોય, તો અમે અરજી એક માન્ય તારીખ પ્રાપ્ત કરી રહી છે અને તેની પ્રક્રિયા કરી રહી છે તેની ખાતરી કરવા માટે માહિતી એકત્રિત કરતા ફોર્મ પર આ માન્યતા લાગુ કરી શકીએ છીએ.
જોકે, આ API એપ્લિકેશન્સ માટે સમાન નથી. અમારે એ સુનિશ્ચિત કરવાની જરૂર છે કે API સારી રીતે લખાયેલું છે અને આ તમામ માન્યતાઓને લાગુ કરવામાં સક્ષમ છે, માન્ય અને અમાન્ય ડેટા વચ્ચે તફાવત કરી શકે છે અને પ્રતિસાદ દ્વારા અંતિમ વપરાશકર્તાને સ્ટેટસ કોડ અને માન્યતા ભૂલ સંદેશ પરત કરી શકે છે.
c) પરીક્ષણ