Водич за тестирање АПИ-ја: Комплетан водич за почетнике

api testing tutorial

Овај детаљни водич за АПИ тестирање објашњава све о АПИ тестирању, веб услугама и како представити АПИ тестирање у својој организацији:

Стекните дубок увид у АПИ тестирање заједно са концептом тестирања померањем улево и веб услугама из овог уводног водича.

Концепти попут Веб АПИ-ја, како АПИ функционише (на примеру из стварног света) и по чему се разликује од Веб Сервицес-а добро су објашњени примерима у овом водичу.

=>ПОМЕРАЈТЕ ДОЉЕда бисте видели целу листу од 5 детаљних водича за тестирање АПИ-ја за почетнике

Шта ћете научити:

• Списак лекција за тестирање АПИ-ја
• Преглед лекција у овој серији за тестирање АПИ-ја
• Водич за тестирање АПИ-ја
  • Тестирање Схифт Лефт
  • Животни циклус развоја софтвера (СДЛЦ) пре тестирања померања улево
  • Фазе испитивања леве смене
  • Веб АПИ
  • Како АПИ функционише?
  • Веб сервиси
  • Веб услуге у односу на веб АПИ
• Представљамо АПИ тестирање у вашој организацији
  • Преусмерите фокус на тестирање АПИ-ја
  • Пун спектар АПИ испитивања
    • (и) Функционално испитивање
    • (ии) Испитивање оптерећења и перформанси
    • (иии) Испитивање сигурности
  • Како увести АПИ тестирање у вашу организацију
  • Уобичајени изазови и начини њиховог ублажавања
    • # 1) Избор правог алата
    • # 2) Недостају спецификације теста
    • # 3) Крива учења
    • # 4) Постојећи сет вештина
  • Истраживање случаја
• Закључак
  • Препоручено читање

Списак лекција за тестирање АПИ-ја

Туториал # 1: Водич за АПИ тестирање: Комплетан водич за почетнике
Туториал # 2: Водич за веб услуге: Компоненте, архитектура, типови и примери
Туториал # 3: Најпопуларнијих 35 питања о интервјуима са одговорима за АСП.Нет и Веб АПИ
Туториал # 4: Водич за ПОСТМАН: Испитивање АПИ-ја помоћу ПОСТМАН-а
Водич бр. 5: Тестирање веб услуга коришћењем Апацхе ХТТП клијента

Преглед лекција у овој серији за тестирање АПИ-ја

Водич за тестирање АПИ-ја

Овај одељак ће вам помоћи да стекнете основно разумевање веб услуга и веб АПИ-ја, што ће заузврат бити корисно за разумевање главних концепата у предстојећим водичима у овој серији тестирања АПИ-ја.

АПИ (Апплицатион Программинг Интерфаце) је скуп свих процедура и функција које нам омогућавају да креирамо апликацију приступом подацима или карактеристикама оперативног система или платформи. Тестирање таквих поступака познато је као АПИ тестирање.

Тестирање Схифт Лефт

Једна од важних врста тестирања која се данас тражи у АПИ испитивању интервјуа је Схифт Лефт тестирање. Ова врста тестирања практикује се у готово свим пројектима који следе агилну методологију.

Пре него што је уведено Схифт Лефт Тестирање, тестирање софтвера се појавило тек након завршетка кодирања и испоруке кода тестерима. Ова пракса довела је до журбе у последњем тренутку како би се испоштовао рок, а такође је у великој мери отежала квалитет производа.

Поред тога, уложени напори (када су недостаци пријављени у последњој фази пре производње) били су огромни јер су програмери морали поново проћи кроз фазу дизајнирања и кодирања.

Животни циклус развоја софтвера (СДЛЦ) пре тестирања померања улево

Традиционални СДЛЦ ток био је: Захтев -> Дизајн -> Кодирање -> Тестирање.

Мане традиционалног испитивања

• Тестирање је крајње десно. Много трошкова настаје када се грешка идентификује у последњем тренутку.
• Време потребно за решавање грешке и поновно тестирање пре него што се промовише у производњу је огромно.

Стога се појавила нова идеја за померање фазе тестирања улево, што је довело до тестирања Схифт Лефт.

Предложено читање => Тестирање померањем улево: Тајна мантра за успех софтвера

Фазе испитивања леве смене

Тестирање померања улево је довело до успешне миграције са откривања дефеката на превенцију дефеката. Такође је помогло софтверу да брзо откаже и што раније отклони све кварове.

Веб АПИ

Уопштено говорећи, Веб АПИ се може дефинисати као нешто што преузима захтев са клијентског система на веб сервер и шаље одговор са веб сервера на клијентску машину.

Како АПИ функционише?

Узмимо врло чест сценарио резервације лета на ввв.макемитрип.цом, која је мрежна путничка услуга која обједињује информације више авио-компанија. Када идете по резервацију лета, уносите информације попут датума путовања / датума повратка, класе итд. И кликните на претрагу.

Ово ће вам показати цену више авио-компанија и њихову доступност. У овом случају, апликација комуницира са АПИ-јевима више авио-компанија и на тај начин даје приступ подацима авио-компаније.

Још један пример је ввв.триваго.цом који упоређује и наводи цене, расположивост итд. Различитих хотела из одређеног града. Ова веб локација комуницира са АПИ-има више хотела за приступ бази података и наводи цене и доступност са њихове веб локације.

Стога се Веб АПИ може дефинисати као „интерфејс који олакшава комуникацију између клијентске машине и веб сервера“.

Веб сервиси

Веб услуге су (попут веб АПИ-ја) услуге које служе са једне машине на другу. Али главна разлика која настаје између АПИ-ја и Веб услуга је та што Веб услуге користе мрежу.

Сигурно је рећи да су све веб услуге веб АПИ, али сви веб АПИ нису веб услуге (објашњено у другом делу чланка). Дакле, веб услуге су подскуп веб АПИ-ја. Погледајте доњи дијаграм да бисте сазнали више о Веб АПИ-ју и веб услугама.

Веб АПИ вс Веб Сервицес

Веб услуге у односу на веб АПИ

И веб АПИ и веб услуге се користе за олакшавање комуникације између клијента и сервера. Главна разлика долази само у начину на који комуницирају.

Сваком од њих је потребно тело захтева које је прихватљиво на одређеном језику, њихове разлике у обезбеђивању сигурне везе, брзина комуникације са сервером и одговор клијенту итд.

Разлике између веб услуга и веб АПИ-ја наведене су у наставку за вашу референцу.

Веб сервис

• Веб услуге обично користе КСМЛ (прошириви језик за означавање), што значи да су сигурније.
• Веб услуге су сигурније јер и веб услуге и АПИ пружају ССЛ (Сецуре Соцкет Лаиер) током преноса података, али такође пружају и ВСС (Веб Сервицес Сецурити).
• Веб услуга је подскуп Веб АПИ-ја. На пример, Веб услуге се заснивају само на три стила употребе, тј. САПУН, ОСТАТАК и КСМЛ-РПЦ.
• Веб услугама је увек потребна мрежа за рад.
• Веб услуге подржавају „Оне Цоде различите апликације“. То значи да се генерички код пише у различитим апликацијама.

Веб АПИ

• Веб АПИ обично користи ЈСОН (ЈаваСцрипт Објецт Нотатион), што значи да је Веб АПИ бржи.
• Веб АПИ је бржи јер је ЈСОН мало пондерисан, за разлику од КСМЛ-а.
• Веб АПИ-ји су суперсет Веб услуга. На пример, Сва три стила веб услуга су присутна и у веб АПИ-ју, али осим тога користи и друге стилове попут ЈСОН - РПЦ.
• Веб АПИ не захтева нужно мрежу за рад.
• Веб АПИ може или не мора подржавати интероперабилност у зависности од природе система или апликације.

Представљамо АПИ тестирање у вашој организацији

У нашем свакодневном животу сви смо толико навикли да комуницирамо са апликацијама помоћу АПИ-ја, а да ни не размишљамо о позадинским процесима који покрећу основну функционалност.

На пример, Дозволите нам да узмемо у обзир да прегледавате производе на Амазон.цом и видите производ / понуду који вам се заиста свиђа и желите да је поделите са вашом Фацебоок мрежом.

Оног тренутка када кликнете на икону Фацебоок у одељку за дељење странице и унесете акредитиве за свој Фацебоок налог за дељење, ступате у интеракцију са АПИ-јем који Амазон-ову веб страницу неприметно повезује са Фацебооком.

Преусмерите фокус на тестирање АПИ-ја

Пре него што разговарамо више о АПИ тестирању, разговарајмо о разлозима због којих су апликације засноване на АПИ-у стекле популарност у последње време.

Постоји неколико разлога због којих организације прелазе на производе и апликације засноване на АПИ-ју. И неколико њих је наведено у наставку за вашу референцу.

# 1) Апликације засноване на АПИ-у су скалабилније у поређењу са традиционалним апликацијама / софтвером. Стопа развоја кода је бржа и исти АПИ може сервисирати више захтева без икаквих већих кода или инфраструктурних промена.

#два) Развојни тимови не морају да започињу са кодирањем испочетка сваки пут када почну да раде на развоју функције или апликације. АПИ-ји најчешће поново користе постојеће, поновљиве функције, библиотеке, ускладиштене процедуре итд., Те их стога овај процес може у целини учинити продуктивнијим.

који је најбољи мп3 довнлоадер за андроид

На пример, Ако сте програмер који ради на веб локацији за е-трговину и желите да додате Амазон као процесор плаћања - онда не морате да пишете код испочетка.

Све што треба да урадите је да подесите интеграцију између ваше веб локације и Амазон АПИ-ја помоћу интеграционих кључева и позовете Амазон АПИ за обраду плаћања током плаћања.

# 3) АПИ-ји омогућавају лаку интеграцију са осталим системима како за подржане самосталне апликације, тако и са софтверским производима заснованима на АПИ-ју.

На пример , Узмимо у обзир да желите да пошљете пошиљку из Торонта у Њујорк. Идите на мрежу, дођите до добро познате веб странице за терет или логистику и унесите потребне информације.

Након пружања обавезних информација, када кликнете на дугме Преузми цене - на крају, ова веб локација за логистику се можда повезује са неколико АПИ-ја и апликација добављача услуга и добављача услуга како би добила динамичке стопе за комбинацију локација од почетка до одредишта.

Пун спектар АПИ испитивања

Тестирање АПИ-ја није ограничено само на слање захтева АПИ-ју и само анализу одговора ради исправности. АПИ-је треба тестирати на перформансе под различитим оптерећењима због рањивости.

Размотримо ово детаљно.

(и) Функционално испитивање

Функционално тестирање може бити изазован задатак због недостатка ГУИ интерфејса.

Да видимо како приступ функционалног испитивања фор АПИс разликује се од апликације засноване на ГУИ-у, а ми ћемо такође размотрити неке примере око ње.

до) Најочигледнија разлика је у томе што не постоји ГУИ за интеракцију. Тестерима који обично раде функционално тестирање засновано на ГУИ-ју је мало теже прећи на тестирање апликација које нису ГУИ у поређењу са неким ко га већ познаје.

У почетку, чак и пре него што започнете тестирање АПИ-ја, мораћете да тестирате и верификујете сам поступак потврде идентитета. Метода потврде идентитета ће се разликовати од једног до другог АПИ-ја и подразумеваће неку врсту кључа или токена за потврду идентитета.

Ако не можете успешно да се повежете са АПИ-јем, даље испитивање не може да се настави. Овај процес се може сматрати упоредивим са аутентификацијом корисника у стандардним апликацијама где су вам потребни важећи акредитиви за пријаву и употребу апликације.

б) Тестирање валидације поља или валидације улазних података је веома важно током тестирања АПИ-ја. Ако је био доступан стварни интерфејс заснован на обрасцу (ГУИ), тада би се провјере ваљаности поља могле имплементирати на предњем или задњем крају, осигуравајући тиме да корисник не смије уносити неважеће вриједности поља.

На пример, Ако апликацији треба формат датума да буде ДД / ММ / ГГГГ, онда можемо да применимо ову проверу на обрасцу за прикупљање информација како бисмо били сигурни да апликација прима и обрађује важећи датум.

То, међутим, није исто за АПИ апликације. Морамо да осигурамо да је АПИ добро написан и да је у стању да спроведе све ове провере ваљаности, направи разлику између важећих и неважећих података и да одговором врати крајњи корисник статусном шифром и поруком о грешци провере.

ц) Тестирање исправности одговора из АПИ-ја за ваљане и неваљане одговоре је заиста пресудно. Ако се статусни код од 200 (што значи да је све у реду) прими као одговор од тест АПИ-ја, али ако се у тексту одговора каже да је дошло до грешке, онда је ово квар.

Поред тога, ако је сама порука о грешци нетачна, онда то може бити веома обмањујуће за крајњег купца који покушава да се интегрише са овим АПИ-јем.

јава прослеђивање низа методи

На снимку екрана испод корисник је унео неважећу тежину, што је више од прихватљивих 2267 кг. АПИ одговара кодом статуса грешке и поруком о грешци. Међутим, порука о грешци погрешно наводи јединице тежине као кг уместо КГ. Ово је квар који може збунити крајњег купца.

(ии) Испитивање оптерећења и перформанси

АПИ-ји су дизајнирани за скалабилност.

То заузврат чини Лоад и Тестирање перформанси од суштинске важности, посебно ако се очекује да систем који се пројектује опслужује хиљаде захтева у минути или на сат, у зависности од захтева. Рутинско извођење тестова оптерећења и перформанси на АПИ-ју може помоћи у одређивању перформанси, вршних оптерећења и тачке прекида.

Ови подаци су корисни док планирате проширивање апликације. Доступност ових информација помоћи ће у подршци одлукама и планирању, посебно ако организација планира да дода више купаца, што би значило више долазних захтева.

На пример , рецимо да на основу пружених захтева знамо да АПИ који је дизајниран треба да сервисира најмање 500 захтева на сат и да одржи просечно време одзива мање од .01 секунде.

На основу тестова оптерећења и перформанси открили смо да све док АПИ прима мање од 500 захтева на сат, у стању је да одржи СЛА за просечно време одзива. Међутим, ако прими још 200 захтева, тада се просечно време одзива повећава и тачка прекида се достиже када долазни захтев премаши 1200 на сат.

Обично се види да је током почетних фаза дизајна акценат често на функционалним аспектима АПИ-ја. Како време пролази, производ почиње да подржава више активних клијената, тада се тестирање перформанси АПИ-ја и тестирање учитавања појављују на рутинскији начин.

(иии) Испитивање сигурности

Интерфејси за програмирање апликација или АПИ-ји су рањиви и представљају најлакшу приступну тачку злонамерним хакерима који желе приступ подацима или стекну контролу над апликацијом.

То може довести било коју компанију у правне проблеме, где су због кршења безбедности ненамерни људи и / или организације у могућности да приступе подацима клијента путем часног АПИ-ја.

Испитивање сигурности је специјализована грана испитивања и њиме би требало да се баве стручњаци. Ресурси за испитивање сигурности могу бити из организације или од независних консултаната.

Такође прочитајте = >> Шта је то уговорно тестирање

Како увести АПИ тестирање у вашу организацију

Процес увођења АПИ тестирања у било којој организацији сличан је процесу који се користи за примену или увођење било ког другог алата и оквира за тестирање.

Табела у наставку резимира главне кораке заједно са очекиваним исходом сваког корака.

Уобичајени изазови и начини њиховог ублажавања

Размотримо неке од уобичајених изазова са којима се КА тимови суочавају док покушавају да примене АПИ тестни оквир у организацији.

# 1) Избор правог алата

Избор исправног алата за посао је најчешћи изазов. Постоји неколико алата за тестирање АПИ-ја који су доступни на тржишту.

Можда делује врло привлачно за примену најновијег, најскупљег алата доступног на тржишту, али ако не доноси жељене резултате, онда тај алат неће бити од користи.

Стога, увек изаберите алат који се бави захтевима који се морају имати на основу ваших организационих потреба.

Ево примера матрице за процену алата за доступне АПИ алате

# 2) Недостају спецификације теста

Као тестери, морамо знати очекиване резултате да бисмо ефикасно тестирали апликацију. То је често изазов, јер да бисмо знали очекиване резултате, морамо имати јасне прецизне захтеве - што није случај.

На пример , размотрите доленаведене захтеве:

„Пријава треба да прихвати само важећи датум отпреме и сви неважећи захтеви треба да буду одбијени“

Овим захтевима недостају кључни детаљи и врло су двосмислени - како дефинишемо важећи датум? Шта је са форматом? Враћамо ли крајњу кориснику поруку одбијања итд.?

Пример јасних захтева:

1) Пријава треба да прихвати само важећи датум отпреме.

Датум испоруке сматра се важећим ако јесте

• Не у прошлости
• Већи или једнак данашњем датуму
• Је у прихватљивом формату: ДД / ММ / ГГГГ

два)

Шифра статуса одговора = 200
Порука: ОК

3) Датум отпреме који не испуњава горе наведене критеријуме треба сматрати неважећим. Ако купац пошаље неважећи датум испоруке, мора одговорити следећом поруком (порукама) о грешци:

3.1

Шифра статуса одговора НЕ 200
Грешка: Наведени датум испоруке је неважећи; Молимо уверите се да је датум у формату ДД / ММ / ГГГГ

3.2

Шифра статуса одговора НЕ 200
Грешка: Наведени датум испоруке је у прошлости

# 3) Крива учења

Као што је претходно поменуто, приступ тестирању АПИ-ја је другачији у поређењу са приступом који се примењује током тестирања апликација заснованих на ГУИ-у.

Ако унајмљујете специјалисте или интерно или консултанте за тестирање АПИ-ја, тада би крива учења приступа АПИ тестирања или АПИ алата за тестирање могла бити минимална. Свака крива учења, у овом случају, била би повезана са стицањем знања о производу или апликацији.

Ако је постојећем члану тима додељено да научи тестирање АПИ-ја, тада, у зависности од изабраног алата, крива учења може бити средња до висока, заједно са променом приступа тестирања. Крива учења за сам производ или апликацију може бити ниска-средња, у зависности од тога да ли је овај испитивач претходно тестирао ту апликацију или не.

# 4) Постојећи сет вештина

Ово се директно везује за претходну тачку о кривуљи учења.

Ако је тестер прелазио са тестирања заснованог на ГУИ-у, тада би тестер морао да промени приступ тестирања и научи нови алат или оквир по потреби. На пример. Ако АПИ прихвати захтеве у ЈСОН формату, тестер ће морати да научи шта је ЈСОН да би започео прављење тестова.

Истраживање случаја

Задатак

Да би проширила постојећу апликацију, компанија је желела да понуди производ у АПИ-у, као и стандардну ГУИ апликацију. Од КА тима је затражено да пружи план покривања тестом како би се осигурало да су спремни да приме АПИ тестирање изван редовних тестова заснованих на ГУИ.

Изазови

• Ниједан од осталих софтверских производа није имао архитектуру засновану на АПИ-ју, стога, како би се прилагодио тестирању око овог задатка, тим треба да успостави процес тестирања АПИ-ја од нуле. То значи да је алат требало оценити, ући у ужи избор, довршити и тим је требало обучити за тестове.
• Није набављен додатни буџет за набавку и примену алата. То значи да је тим морао да изабере бесплатни алат за тестирање АПИ-ја отвореног кода и да је неко из постојећег тима требало да буде обучен да преузме овај задатак.
• Нису постојали захтеви за АПИ поља и проверу података. Захтеви су били „треба да раде исто као и одговарајућа ГУИ апликација“.

Приступ који тим следи за ублажавање ризика и заобилажење изазова

• КА тим је радио са пројектним тимом да би идентификовао следеће захтеве:
  • Тип АПИ-ја (РЕСТ / СОАП): ОСТАЛО
  • Потребни тестови (функционални, оптерећени, сигурносни): Само функционално тестирање
  • Потребни аутоматизовани тестови (Да / Не): За сада необавезна
  • Извештаји о испитивању (да / не): Потребан
• КА тим је извршио процену алата на располагању Алати за тестирање АПИ-ја заснован на обавезним захтевима. Постман АПИ Тоол финализиран је као алат по њиховом избору, јер је био бесплатан и једноставан за употребу, на тај начин минимизирајући криву учења, имао је потенцијал за аутоматизацију тестова и испоручио је са добрим уграђеним извештајима.
• Исти испитивач који је тестирао апликацију, обучен је за употребу Поштара за креирање почетних тестова, чиме се елиминишу празнине у знању о производу.
• Да би се решио недостајућих захтева, пројектни тим је направио Сваггер-ову документацију на високом нивоу. Ово је, међутим, оставило неке празнине у погледу прихватљивих формата података, што је преузето са пројектним тимом и договорени су и документовани очекивани формати.

Закључак

Апликације засноване на АПИ-у стекле су популарност у новије време. Ове апликације су скалабилније у поређењу са традиционалним апликацијама / софтвером и омогућавају лакшу интеграцију са другим АПИ-има или апликацијама.

У овом водичу за АПИ тестирање детаљно је објашњено све о АПИ тестирању, Схифт Лефт тестирању, Веб услугама и Веб АПИ-ју. Такође смо истражили разлике између веб услуга и веб АПИ-ја са примерима.

У другом делу упутства разговарали смо о читавом спектру АПИ тестирања, начину увођења АПИ тестирања у вашу организацију и неким уобичајеним изазовима у овом процесу, као и решењима за њих.

Погледајте наш предстојећи водич да бисте сазнали више о веб услугама заједно са примерима !!

СЛЕДЕЋА Лекција

Препоручено читање

• Алфа тестирање и бета тестирање (потпун водич)
• Функционално тестирање вс нефункционално тестирање
• Водич за испитивање употребљивости: Комплетан водич за почетак
• Комплетни водич за тестирање верификације израде (БВТ тестирање)
• Водич за тестирање ДевОпс-а: Како ће ДевОпс утицати на КА тестирање?
• Водич за тестирање приступачности (потпун водич по корацима)
• Најбољи алати за тестирање софтвера 2021. године (КА Тест Аутоматион Тоолс)
• Шта је тестирање софтвера? 100+ бесплатних упутстава за ручно тестирање