- API-ի փորձարկման ձեռնարկների ցանկ
- Այս API-ի թեստավորման շարքի ձեռնարկների ակնարկ
- Եզրակացություն
- API-ի փորձարկման ձեռնարկ
- Ներկայացնելով API-ի փորձարկումը ձեր կազմակերպությունում
API-ի թեստավորման այս խորը ձեռնարկը բացատրում է ամեն ինչ API-ի թեստավորման, վեբ ծառայությունների և ինչպես ներդնել ձեր կազմակերպությունում API-ի թեստավորում. Shift-left թեստավորման և վեբ ծառայությունների հայեցակարգը այս ներածական ձեռնարկից:
Հասկացությունները, ինչպիսիք են Web API-ն, ինչպես է API-ն աշխատում (իրական օրինակով) և ինչպես է այն տարբերվում Վեբ ծառայություններից, լավ բացատրվում են այս օրինակներով: ձեռնարկ:
API-ի փորձարկման ձեռնարկների ցանկ
Ձեռնարկ #1: API-ի փորձարկման ձեռնարկ. ամբողջական ուղեցույց սկսնակների համար
Ձեռնարկ #2: Վեբ ծառայությունների ձեռնարկ. Բաղադրիչներ, ճարտարապետություն, տեսակներ և amp; Օրինակներ
Ձեռնարկ #3: Լավագույն 35 ASP.Net-ի և վեբ API-ի հարցազրույցի հարցերը պատասխաններով
Ուսուցում #4: POSTMAN ձեռնարկ. API-ի փորձարկում Օգտագործելով POSTMAN
Ձեռնարկ #5: Վեբ ծառայությունների փորձարկում Apache HTTP հաճախորդի կիրառմամբ
Այս API-ի թեստավորման շարքի ձեռնարկների ակնարկ
| Ձեռնարկ # | Ինչ կսովորեք | |||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Ձեռնարկ #1: | API-ի փորձարկման ձեռնարկ Ամբողջական ուղեցույց սկսնակների համար API-ի փորձարկման այս խորը ձեռնարկը մանրամասն կբացատրի API-ի թեստավորման և վեբ ծառայությունների մասին, ինչպես նաև կսովորեցնի ձեզ, թե ինչպես ներդնել API-ի թեստավորում ձեր կազմակերպությունում: | |||||||||||||||||||||||||||||||||||||||||||||
| Ուսուցում_#2: | Վեբ ծառայությունների ձեռնարկ. Բաղադրիչներ, ճարտարապետություն, տեսակներ և amp; Օրինակներ Այս վեբAPI-ից ստացված պատասխանների ճշգրտությունը վավերական և անվավեր պատասխանների համար իսկապես կարևոր է: Եթե 200 կարգավիճակի կոդը (նշանակում է բոլորը Okay) ստացվում է որպես պատասխան թեստային API-ից, բայց եթե պատասխանի տեքստում ասվում է, որ սխալ է տեղի ունեցել, ապա սա թերություն է: Բացի այդ, եթե սխալի հաղորդագրությունը ինքնին սխալ է, ապա դա կարող է շատ մոլորեցնող լինել վերջնական հաճախորդի համար, ով փորձում է ինտեգրվել այս API-ին: Սքրինշոթում ներքևում օգտատերը մուտքագրել է անվավեր քաշ, որն ավելին է, քան ընդունելի 2267 կգ: API-ն պատասխանում է սխալի կարգավիճակի կոդով և սխալի հաղորդագրությամբ: Այնուամենայնիվ, սխալի հաղորդագրությունը սխալ է նշում քաշի միավորները որպես ֆունտ KG-ի փոխարեն: Սա թերություն է, որը կարող է շփոթության մեջ գցել վերջնական հաճախորդին: (ii) Բեռնվածության և կատարողականի փորձարկումAPI-ները նախատեսված են նախագծով մասշտաբային: Սա, իր հերթին, կարևոր է դարձնում բեռնվածության և կատարողականի փորձարկումը, հատկապես, եթե նախագծվող համակարգը սպասարկելու է հազարավոր հարցումներ րոպեում կամ ժամում՝ կախված պահանջից: API-ի վրա բեռնվածության և կատարողականի թեստերի կանոնավոր կատարումը կարող է օգնել համեմատել կատարողականը, առավելագույն բեռնվածությունը և ճեղքման կետը: Այս տվյալները օգտակար են հավելվածի մեծացման պլանավորման ժամանակ: Այս տեղեկատվության հասանելիությունը կօգնի աջակցել որոշումներին և պլանավորմանը, հատկապես, եթե կազմակերպությունը նախատեսում է ավելացնել ավելի շատ հաճախորդներ, ինչը կնշանակի ավելի շատ ներգնա:հարցումներ: Ինչպես ներդնել API-ի թեստավորում ձեր կազմակերպությունումAPI-ի թեստավորման ներդրման գործընթացը ցանկացած կազմակերպությունում նման է գործընթացին, որն օգտագործվում է ցանկացած այլ փորձարկման գործիք և շրջանակ: Ստորև բերված աղյուսակը ամփոփում է հիմնական քայլերը յուրաքանչյուր քայլի ակնկալվող արդյունքի հետ միասին:
Ընդհանուր մարտահրավերներ և դրանք մեղմելու ուղիներԵկեք քննարկենք QA թիմերի ընդհանուր մարտահրավերները Կազմակերպությունում API-ի թեստավորման շրջանակը ներդնելու փորձ կատարելիս: #1) Ճիշտ գործիք ընտրելըԱշխատանքի համար ճիշտ գործիք ընտրելը ամենատարածված խնդիրն է: Կան մի քանի API փորձարկման գործիքներ, որոնք հասանելի են շուկայում: Կարող է շատ գրավիչ թվալ շուկայում առկա ամենավերջին, ամենաթանկ գործիքի ներդրումը, բայց եթե այն չի բերում ցանկալի արդյունքները, ապա այդ գործիքը ոչ մի օգուտ չի տալիս: Այսպիսով, միշտ ընտրեք այն գործիքը, որը համապատասխանում է «անհրաժեշտ» պահանջներին՝ ելնելով ձեր կազմակերպչական կարիքներից: Ահա գործիքի գնահատման մատրիցայի նմուշը հասանելի API Գործիքներ
#2) Բացակայում են թեստի բնութագրերըՈրպես փորձարկողներ, մենք պետք է իմանանք ակնկալվող արդյունքները՝ հայտը արդյունավետ փորձարկելու համար: Սա հաճախ մարտահրավեր է, քանի որ ակնկալվող արդյունքները իմանալու համար մենք պետք է ունենանք հստակ հստակ պահանջներ, ինչը այնպես չէ: Օրինակ , հաշվի առեք ստորև ներկայացված պահանջները. «Դիմումը պետք է ընդունի միայն վավեր առաքման ամսաթիվ, և բոլոր անվավեր պահանջները պետք է մերժվեն»: Այս պահանջները բացակայում են հիմնական մանրամասներից և շատ երկիմաստ են. ինչպե՞ս ենք մենք սահմանում վավեր ամսաթիվ: Ինչ վերաբերում է ձևաչափին: Արդյո՞ք մենք վերադարձնում ենք որևէ մերժման հաղորդագրություն վերջնական օգտագործողին և այլն: Մաքուր պահանջների օրինակ. 1) Դիմումը պետք է միայն ընդունել վավեր առաքման ամսաթիվ: Առաքման ամսաթիվը համարվում է վավեր, եթե այնէ
2) Պատասխանի կարգավիճակի կոդը = 200 Հաղորդագրություն՝ OK 3) Առաքման ամսաթիվը, որը չի համապատասխանում վերը նշված չափանիշներին, պետք է համարել անվավեր: Եթե հաճախորդն ուղարկում է անվավեր առաքման ամսաթիվ, ապա նա պետք է պատասխանի հետևյալ սխալի հաղորդագրություն(ներ)ով. 3.1 Պատասխանի կարգավիճակի կոդը NOT 200 Սխալ. տրամադրված առաքման ամսաթիվը անվավեր է. խնդրում ենք համոզվեք, որ ամսաթիվը DD/MM/YYYY ֆորմատով է 3.2 Պատասխանի կարգավիճակի կոդը ՉԻ 200 Սխալ․ առաքման ամսաթիվը նշված է անցյալը #3) Ուսուցման կորըԻնչպես նշվեց նախկինում, API-ի փորձարկման մոտեցումը տարբերվում է GUI-ի վրա հիմնված հավելվածների փորձարկման ժամանակ օգտագործվող մոտեցման համեմատությամբ: Եթե դուք աշխատանքի են հրավիրում մասնագետների՝ կա՛մ ներքին, կա՛մ խորհրդատուների API-ի թեստավորման համար, ապա API թեստի մոտեցման կամ API թեստային գործիքի ուսուցման կորը կարող է նվազագույն լինել: Ցանկացած ուսուցման կոր, այս դեպքում, կապված կլինի արտադրանքի կամ կիրառական գիտելիքների ձեռքբերման հետ: Եթե թիմի գոյություն ունեցող անդամին հանձնարարված է սովորել API թեստավորում, ապա կախված ընտրված գործիքից, ուսուցման կորը կարող է լինել. միջինից բարձր՝ փորձարկման մոտեցումը փոխելու հետ մեկտեղ: Արտադրանքի կամ հավելվածի ուսուցման կորը կարող է լինել ցածր միջին՝ կախված նրանից, թե արդյոք այս փորձարկիչը փորձարկվել էայդ հավելվածը նախկինում, թե ոչ: #4) Առկա հմտությունների հավաքածուՍա ուղղակիորեն կապված է ուսուցման կորի վերաբերյալ նախորդ կետի հետ: Եթե փորձարկողը անցնում էր GUI-ի վրա հիմնված թեստավորում, այնուհետև փորձարկողը պետք է փոխի թեստավորման մոտեցումը և ըստ պահանջի սովորի նոր գործիքը կամ շրջանակը: Օրինակ. Եթե API-ն ընդունում է հարցումները JSON ձևաչափով, ապա փորձարկողը պետք է իմանա, թե ինչ է JSON-ը, որպեսզի սկսի թեստեր ստեղծել: Case StudyԱռաջադրանք Գոյություն ունեցող հավելվածը մեծացնելու համար ընկերությունը ցանկանում էր առաջարկել արտադրանք API-ում, ինչպես նաև ստանդարտ GUI հավելված: QA թիմին խնդրել են տրամադրել փորձարկման ծածկույթի պլան՝ համոզվելու համար, որ նրանք պատրաստ են հարմարեցնել API-ի թեստավորումը սովորական GUI-ի վրա հիմնված թեստերից դուրս: Մարտահրավերներ
Մոտեցումը, որին հետևում է թիմի կողմից ռիսկերը մեղմելու և մարտահրավերների շուրջ աշխատելու համար
ԵզրակացությունAPI-ի վրա հիմնված հավելվածները ունեն ժողովրդականություն է ձեռք բերել վերջին ժամանակներում: Այս հավելվածներն ավելի շատ ենընդլայնելի՝ համեմատած ավանդական հավելվածների/ծրագրերի հետ և թույլ է տալիս ավելի հեշտ ինտեգրվել այլ API-ների կամ հավելվածների հետ: API-ի փորձարկման այս ձեռնարկը մանրամասն բացատրում է API-ի փորձարկման, Shift Left Testing-ի, Web Services-ի և Web API-ի մասին: Մենք նաև օրինակներով ուսումնասիրեցինք Web Services-ի և Web API-ի միջև եղած տարբերությունները: Ուսուցման երկրորդ մասում մենք քննարկեցինք API-ի փորձարկման ամբողջ սպեկտրը, ինչպես ներմուծել API-ի թեստավորումը ձեր կազմակերպությունում և որոշ ընդհանուր մարտահրավերներ այս գործընթացը և դրանց լուծումները: Ստուգեք մեր առաջիկա ձեռնարկը, որպեսզի ավելին իմանաք Վեբ ծառայությունների մասին օրինակների հետ միասին: ՀԱՋՈՐԴ ձեռնարկը Ծառայությունների ձեռնարկը բացատրում է Ճարտարապետություն, տեսակներ և AMP; Վեբ ծառայությունների բաղադրիչները կարևոր տերմինաբանությունների հետ միասին և տարբերությունները SOAP-ի ընդդեմ REST-ի միջև: | |||||||||||||||||||||||||||||||||||||||||||||
| Ձեռնարկ #3: | Լավագույն 35 ASP.Net և Web API հարցազրույցի հարցերը պատասխաններով Դուք կարող եք ուսումնասիրել ամենատարածված ASP.Net-ի և Web API-ի հարցազրույցի հարցերի ցանկը պատասխաններով & օրինակներ սկսնակների և փորձառու մասնագետների համար այս ձեռնարկում: | |||||||||||||||||||||||||||||||||||||||||||||
| Ուսուցում_#4: | POSTMAN ձեռնարկ. API-ի փորձարկում Օգտագործելով POSTMAN Այս քայլ առ քայլ ձեռնարկը կբացատրի API-ի փորձարկումը POSTMAN-ի կիրառմամբ, ինչպես նաև POSTMAN-ի հիմունքների, դրա բաղադրիչների և նմուշի հարցումը և այլն: Պատասխանեք պարզ բառերով՝ ձեր հեշտ հասկանալու համար: | |||||||||||||||||||||||||||||||||||||||||||||
| Ձեռնարկ #5: | Վեբ ծառայությունների փորձարկում Apache HTTP հաճախորդի միջոցով Այս API ձեռնարկը վեբ ծառայությունների վրա տարբեր CRUD գործողություններ կատարելու և վեբ ծառայությունների փորձարկման մասին է՝ օգտագործելով Apache HTTP Client |
API-ի փորձարկման ձեռնարկ
Այս բաժինը կօգնի ձեզ ստանալ հիմնական պատկերացում վեբ ծառայությունների և վեբ API-ի մասին, որոնք, իր հերթին, օգտակար կլինեն այս API թեստավորման շարքի առաջիկա ձեռնարկների հիմնական հասկացությունները հասկանալու համար:
API ( Application Programming Interface) բոլոր ընթացակարգերի և գործառույթների մի շարք է, որոնք թույլ են տալիս մեզ ստեղծել հավելված՝ մուտք գործելով տվյալներ կամ առանձնահատկություններ:օպերացիոն համակարգ կամ հարթակներ: Նման ընթացակարգերի թեստավորումը հայտնի է որպես API-ի թեստավորում:
Shift Left Testing
Թեստավորման կարևոր տեսակներից մեկը, որն այժմ հարցվում է API-ի թեստավորման հարցազրույցներում, Shift Left Testing-ն է: Այս տեսակի թեստավորումը կիրառվում է գրեթե բոլոր նախագծերում, որոնք հետևում են Արագաշարժ մեթոդաբանությանը:
Մինչ Shift Left Testing-ի ներդրումը, ծրագրային ապահովման փորձարկումն ի հայտ եկավ միայն կոդավորման ավարտից և կոդը հանձնելուց հետո փորձարկողներին: Այս պրակտիկան հանգեցրեց վերջնաժամկետին հասնելու վերջին րոպեին և այն նաև մեծապես խոչընդոտեց արտադրանքի որակին:
Բացի այդ, գործադրված ջանքերը (երբ արտադրությունից առաջ վերջին փուլում արձանագրվեցին թերություններ) հսկայական, քանի որ մշակողները ստիպված էին նորից անցնել ինչպես նախագծման, այնպես էլ կոդավորման փուլը:
Ծրագրային ապահովման մշակման կյանքի ցիկլը (SDLC) Նախքան Shift Left Testing
Ավանդական SDLC հոսքը հետևյալն էր. > Դիզայն –> Կոդավորում –> Թեստավորում:
Ավանդական թեստավորման թերությունները
- Թեստավորումը ծայրահեղ աջ կողմում է: Բազմաթիվ ծախսեր են կատարվում, երբ սխալը հայտնաբերվում է վերջին պահին:
- Սխալը լուծելու և այն նորից փորձարկելու համար ծախսված ժամանակը հսկայական է:
Ուստի, ի հայտ եկավ նոր գաղափար՝ թեստավորման փուլը ձախ տեղափոխելու համար, որն այդպիսով հանգեցրեց Shift Left թեստավորման:
Առաջարկվող կարդալ => Shift Left Testing.Ծրագրային ապահովման հաջողության գաղտնի մանտրան
Ձախ հերթափոխի փորձարկման փուլերը
Ձախ հերթափոխի փորձարկումը հանգեցրեց դեֆեկտի հայտնաբերումից դեպի թերությունների կանխարգելման հաջող միգրացիայի: Այն նաև օգնեց ծրագրաշարին արագ ձախողել և շուտափույթ շտկել բոլոր խափանումները:
Web API
Ընդհանուր ձևով, Web API-ն կարող է սահմանվել որպես մի բան, որը վերցնում է հաճախորդի հարցումը: համակարգը վեբ սերվերին և վեբ սերվերից պատասխանը ուղարկում է հաճախորդի մեքենային:
Ինչպե՞ս է գործում API-ն:
Եկեք ընդունենք www.makemytrip.com-ով թռիչքի ամրագրման շատ տարածված սցենարը, որն առցանց ճանապարհորդական ծառայություն է, որը հավաքում է բազմաթիվ ավիաընկերությունների տեղեկությունները: Երբ գնում եք թռիչքի ամրագրման, մուտքագրում եք տեղեկություններ, ինչպիսիք են ճանապարհորդության ամսաթիվը/վերադարձի ամսաթիվը, դասը և այլն, և սեղմում եք որոնումը:
Սա ձեզ ցույց կտա մի քանի ավիաընկերությունների գինը և դրանց հասանելիությունը: Այս դեպքում հավելվածը փոխազդում է բազմաթիվ ավիաընկերությունների API-ների հետ և դրանով իսկ հնարավորություն է տալիս մուտք գործել ավիաընկերության տվյալները:
Մեկ այլ օրինակ է www.trivago.com-ը, որը համեմատում և թվարկում է տարբեր հյուրանոցների գինը, մատչելիությունը և այլն: կոնկրետ քաղաքից: Այս կայքը շփվում է բազմաթիվ հյուրանոցների API-ների հետ տվյալների բազա մուտք գործելու համար և ցուցակագրում է գներն ու հասանելիությունը նրանց կայքից:
Այսպիսով, Web API-ն կարող է սահմանվել որպես «ինտերֆեյս, որը հեշտացնում է կապը հաճախորդի մեքենայի և որվեբ սերվեր»:
Վեբ ծառայություններ
Վեբ ծառայությունները (ինչպես վեբ API-ն) այն ծառայություններն են, որոնք ծառայում են մի մեքենայից մյուսը: Բայց հիմնական տարբերությունը, որն առաջանում է API-ի և վեբ ծառայությունների միջև այն է, որ Վեբ ծառայություններն օգտագործում են ցանց:
Կարելի է վստահորեն ասել, որ բոլոր վեբ ծառայությունները վեբ API-ներ են, բայց բոլոր վեբ API-ները վեբ ծառայություններ չեն (բացատրված է. հոդվածի վերջին մասը): Այսպիսով, Վեբ ծառայությունները Web API-ի ենթաբազմություն են: Վեբ API-ի և վեբ ծառայությունների մասին ավելին իմանալու համար տես ստորև ներկայացված գծապատկերը:
Վեբ API ընդդեմ վեբ ծառայությունների
Վեբ ծառայություններ ընդդեմ վեբ ծառայությունների Web API
Եվ Web API-ն և Web Services-ն օգտագործվում են հաճախորդի և սերվերի միջև հաղորդակցությունը հեշտացնելու համար: Հիմնական տարբերությունը կապված է միայն նրանց հաղորդակցման ձևի մեջ:
Նրանցից յուրաքանչյուրը պահանջում է հարցումների մարմին, որը ընդունելի է որոշակի լեզվով, նրանց տարբերությունները անվտանգ կապ ապահովելու, սերվերի հետ հաղորդակցվելու և պատասխանելու արագության մեջ: հաճախորդին և այլն:
Վեբ ծառայությունների և վեբ API-ի միջև եղած տարբերությունները ստորև նշված են ձեր հղումների համար:
Վեբ ծառայություն
- Վեբ ծառայությունները սովորաբար օգտագործում են XML (Extensible Markup Language), ինչը նշանակում է, որ դրանք ավելի ապահով են:
- Վեբ ծառայություններն ավելի ապահով են, քանի որ և՛ վեբ ծառայությունները, և՛ API-ները տվյալների փոխանցման ժամանակ ապահովում են SSL (Secure Socket Layer) , բայց այն նաև ապահովում է WSS (Web Services Security):
- Վեբ ծառայությունը Web API-ի ենթաբազմություն է: Օրինակ՝ Վեբ ծառայությունները հիմնված են օգտագործման միայն երեք ոճերի վրա, այսինքն՝ SOAP, REST և XML-RPC:
- Վեբ ծառայություններին միշտ անհրաժեշտ է ցանց՝ գործելու համար:
- Վեբ ծառայություններն աջակցում են «Մեկ կոդ տարբեր հավելվածներ»: Սա նշանակում է, որ ավելի ընդհանուր կոդը գրված է տարբեր հավելվածներում:
Վեբ API
- Վեբ API-ն սովորաբար օգտագործում է JSON (JavaScript Object Notation), ինչը նշանակում է, որ Web API-ն ավելի արագ է:
- Վեբ API-ն ավելի արագ է, քանի որ JSON-ը թեթև է, ի տարբերություն XML-ի:
- Վեբ API-ները Web Services-ի գերհամակարգն են: Օրինակ, Վեբ ծառայությունների բոլոր երեք ոճերը նույնպես առկա են Web API-ում, բայց բացի դրանից, այն օգտագործում է այլ ոճեր, ինչպիսիք են JSON – RPC:
- Վեբ API-ն պարտադիր չէ, որ պահանջի ցանց, որը պետք է գործի:
- Վեբ API-ն կարող է աջակցել կամ չաջակցել փոխգործունակությանը` կախված համակարգի կամ հավելվածի բնույթից:
Ներկայացնելով API-ի փորձարկումը ձեր կազմակերպությունում
Մեր առօրյա կյանքում մենք բոլորս այնքան սովոր ենք API-ներով հավելվածների հետ շփվելուն, և, այնուամենայնիվ, չենք էլ մտածում հետին գործընթացների մասին, որոնք առաջ են մղում հիմքում ընկած ֆունկցիոնալությունը:
Օրինակ: , Եկեք համարենք, որ դուք զննում եք ապրանքները Amazon.com-ում և տեսնում եք մի ապրանք/գործարք, որը ձեզ իսկապես դուր է գալիս և ցանկանում եք այն կիսել ձեր Facebook ցանցի հետ:
Այն պահին, երբ դուք սեղմում եք էջի համօգտագործման բաժնում Facebook պատկերակի վրա և մուտքագրեք ձերFacebook-ի հաշվի հավատարմագրերը՝ կիսվելու համար, դուք շփվում եք API-ի հետ, որն անխափան կերպով միացնում է Amazon-ի կայքը Facebook-ին:
Կենտրոնանալ Shift to API Testing
Նախքան API թեստավորման մասին ավելին քննարկելը, եկեք քննարկենք պատճառները: որոնց համար API-ի վրա հիմնված հավելվածները վերջին ժամանակներս ժողովրդականություն են ձեռք բերել:
Կան մի քանի պատճառ, որոնց համար կազմակերպությունները անցնում են API-ի վրա հիմնված արտադրանքներին և հավելվածներին: Եվ դրանցից քչերը ներկայացված են ստորև՝ ձեր տեղեկանքի համար:
#1) API-ի վրա հիմնված հավելվածներն ավելի լայնածավալ են, երբ համեմատվում են ավանդական հավելվածների/ծրագրերի հետ: Կոդի մշակման արագությունն ավելի արագ է, և նույն API-ն կարող է սպասարկել ավելի շատ հարցումներ՝ առանց որևէ լուրջ կոդի կամ ենթակառուցվածքային փոփոխությունների:
#2) Մշակող թիմերը կարիք չունեն ամեն անգամ սկսել կոդավորումը զրոյից: այն ժամանակ, երբ նրանք սկսում են աշխատել գործառույթի կամ հավելվածի մշակման վրա: API-ները ամենից հաճախ վերօգտագործում են գոյություն ունեցող, կրկնվող գործառույթները, գրադարանները, պահված ընթացակարգերը և այլն, և, հետևաբար, այս գործընթացը կարող է դրանք ընդհանուր առմամբ ավելի արդյունավետ դարձնել:
Օրինակ, Եթե դուք մշակող եք, որն աշխատում է էլեկտրոնային առևտրի կայք, և դուք ցանկանում եք ավելացնել Amazon-ը որպես վճարային պրոցեսոր, այնուհետև ստիպված չեք լինի զրոյից գրել կոդը:
Այն ամենը, ինչ դուք պետք է անեք, ձեր կայքի և Amazon API-ի միջև ինտեգրումն է, օգտագործելով Ինտեգրման բանալիներ և զանգահարեք Amazon API՝ վճարումների ժամանակ վճարումները մշակելու համար:
#3) API-ները թույլ են տալիսհեշտ ինտեգրում այլ համակարգերի հետ ինչպես աջակցվող անկախ հավելվածների, այնպես էլ API-ի վրա հիմնված ծրագրային արտադրանքների հետ:
Օրինակ , Եկեք համարենք, որ դուք ցանկանում եք առաքում ուղարկել Տորոնտոյից Նյու Յորք . Դուք գնում եք առցանց, նավարկվում եք բեռնափոխադրումների կամ լոգիստիկայի հայտնի վեբկայք և մուտքագրում եք անհրաժեշտ տեղեկատվությունը:
Պարտադիր տեղեկատվությունը տրամադրելուց հետո, երբ սեղմում եք Ստանալ սակագներ կոճակը, հետևի վերջում, այս լոգիստիկ կայքը կարող է միանալ: մի քանի օպերատորների և ծառայություններ մատուցողների API-ների և հավելվածների հետ՝ սկզբնաղբյուրից մինչև նպատակակետ վայրերի համակցության դինամիկ դրույքաչափերը ստանալու համար:
API-ի փորձարկման ամբողջական սպեկտրը
API-ների փորձարկումը չի սահմանափակվում հարցում ուղարկելով API-ին և վերլուծելով պատասխանը միայն ճշտության համար: API-ները պետք է փորձարկվեն իրենց կատարողականության համար տարբեր բեռների տակ՝ խոցելիության համար:
Եկեք մանրամասն քննարկենք դա:
(i) Ֆունկցիոնալ փորձարկում
Ֆունկցիոնալ թեստավորումը կարող է բարդ խնդիր լինել՝ GUI ինտերֆեյսի բացակայության պատճառով:
Եկեք տեսնենք, թե ինչպես է API-ների ֆունկցիոնալ փորձարկման մոտեցումը տարբերվում GUI-ի վրա հիմնված հավելվածից, և մենք նաև կքննարկենք դրա շուրջ որոշ օրինակներ:
ա) Ամենաակնառու տարբերությունն այն է, որ չկա միջերեսային միջերես, որի հետ փոխգործակցելու համար չկա: Փորձարկողները, ովքեր սովորաբար կատարում են GUI-ի վրա հիմնված ֆունկցիոնալ թեստավորում, մի փոքր ավելի դժվար է անցում կատարել ոչ GUI հավելվածի թեստավորման՝ համեմատածմեկը, ով արդեն ծանոթ է դրան:
Սկզբում, նույնիսկ API-ի փորձարկումը սկսելուց առաջ, դուք պետք է փորձարկեք և հաստատեք նույնականացման գործընթացը: Նույնականացման մեթոդը տարբերվում է API-ից մյուս API-ից և կներառի նույնականացման ինչ-որ բանալի կամ նշան:
Եթե դուք չեք կարողանում հաջողությամբ միանալ API-ին, ապա հետագա փորձարկումը չի կարող շարունակվել: Այս գործընթացը կարելի է համեմատել սովորական հավելվածներում օգտագործողի նույնականացման հետ, որտեղ ձեզ անհրաժեշտ են վավեր հավատարմագրեր՝ մուտք գործելու և հավելվածն օգտագործելու համար:
բ) Փորձարկման դաշտի վավերացումները կամ մուտքային տվյալների վավերացումը շատ կարևոր է: API-ների փորձարկման ժամանակ: Եթե առկա էր իրական ձևի վրա հիմնված (GUI) ինտերֆեյս, ապա դաշտի վավերացումները կարող էին իրականացվել առջևի կամ հետևի վերջում, դրանով իսկ ապահովելով, որ օգտվողին թույլ չի տրվի մուտքագրել դաշտի անվավեր արժեքներ:
Օրինակ՝ Եթե հայտին անհրաժեշտ է, որ ամսաթվի ձևաչափը լինի DD/MM/YYYY, ապա մենք կարող ենք կիրառել այս վավերացումը տեղեկատվություն հավաքող ձևի վրա՝ համոզվելու համար, որ հայտը ստանում և մշակում է վավեր ամսաթիվ:
Սա, սակայն, նույնը չէ API հավելվածների համար: Մենք պետք է ապահովենք, որ API-ն լավ գրված է և ի վիճակի է կիրառել այս բոլոր վավերացումները, տարբերակել վավեր և անվավեր տվյալները և պատասխանի միջոցով վերջնական օգտագործողին վերադարձնել կարգավիճակի կոդը և վավերացման սխալի հաղորդագրությունը:
գ) Փորձարկում է