- Листа водича за тестирање АПИ-ја
- Преглед водича у овој серији тестирања АПИ-ја
- Закључак
- Упутство за тестирање АПИ-ја
- Увођење АПИ тестирања у вашу организацију
Овај детаљан водич за тестирање АПИ-ја објашњава све о тестирању АПИ-ја, веб услугама и како да уведете АПИ тестирање у своју организацију:
Стекните дубљи увид у тестирање АПИ-ја заједно са концепт тестирања померања улево и веб сервиса из овог уводног туторијала.
Концепти као што су Веб АПИ, како АПИ функционише (са примером из стварног света) и како се разликује од веб услуга добро су објашњени примерима у овом водич.
Листа водича за тестирање АПИ-ја
Водич #1: Упутство за тестирање АПИ-ја: Комплетан водич за почетнике
Водич #2: Водич за веб услуге: Компоненте, архитектура, типови &амп; Примери
Туториал #3: Топ 35 АСП.Нет и Веб АПИ питања за интервју са одговорима
Водич #4: ПОСТМАН Водич: АПИ тестирање Коришћење ПОСТМАН
Водич #5: Тестирање веб услуга коришћењем Апацхе ХТТП клијента
Преглед водича у овој серији тестирања АПИ-ја
| Водич # | Шта ћете научити | |||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Водич_#1: | Упутство за тестирање АПИ-ја : Комплетан водич за почетнике Овај детаљни водич за тестирање АПИ-ја ће детаљно објаснити све о АПИ тестирању и веб услугама и такође ће вас образовати о томе како да уведете АПИ тестирање у своју организацију. | |||||||||||||||||||||||||||||||||||||||||||||
| Водич_#2: | Водич за веб услуге: компоненте, архитектура, типови &амп; Примери Овај вебисправност одговора АПИ-ја за валидан и неважећи одговор је заиста кључна. Ако је статусни код 200 (што значи све у реду) примљен као одговор од тест АПИ-ја, али ако текст одговора каже да је наишла на грешку, онда је ово дефект. Поред тога, ако се порука о грешци сама по себи није тачна, онда то може бити веома обмањујуће за крајњег купца који покушава да се интегрише са овим АПИ-јем. На снимку екрана испод, корисник је унео неважећу тежину, што је више од прихватљивих 2267 кг. АПИ одговара кодом статуса грешке и поруком о грешци. Међутим, порука о грешци нетачно помиње јединице тежине као лбс уместо КГ. Ово је недостатак који може збунити крајњег купца. (ии) Тестирање оптерећења и перформансиАПИ-ји су дизајнирани да буду скалабилни. Ово, заузврат, чини тестирање оптерећења и перформанси неопходним, посебно ако се очекује да ће систем који се дизајнира сервисирати хиљаде захтева у минути или сату, у зависности од захтева. Рутинско извођење тестова оптерећења и перформанси на АПИ-ју може помоћи у поређивању перформанси, вршних оптерећења и тачке лома. Ови подаци су корисни приликом планирања повећања апликације. Доступне ове информације ће помоћи у доношењу одлука и планирању, посебно ако организација планира да дода још купаца, што би значило вишезахтева. Како увести АПИ тестирање у своју организацијуПроцес за увођење АПИ тестирања у било којој организацији сличан је процесу који се користи за имплементацију или увођење било ког другог алата и оквира за тестирање. Табела у наставку сумира главне кораке заједно са очекиваним исходом сваког корака.
Уобичајени изазови и начини за њихово ублажавањеХајде да разговарамо о неким од уобичајених изазова са којима се суочавају КА тимови суочите се док покушавате да имплементирате оквир за тестирање АПИ-ја у организацији. #1) Одабир правог алатаОдабир исправног алата за посао је најчешћи изазов. Постоји неколико алата за тестирање АПИ-ја који су доступни на тржишту. Може изгледати веома привлачно имплементирати најновији, најскупљи алат доступан на тржишту – али ако не донесе жељене резултате, онда тај алат нема користи. Стога, увек бирајте алатку која испуњава 'неопходне' захтеве на основу ваших организационих потреба. Овде је пример матрице за процену алата за доступне АПИ алатке
#2) Недостају спецификације тестаКао тестери, морамо да знамо очекиване резултате за ефикасно тестирање апликације. Ово је често изазов, јер да бисмо знали очекиване резултате, морамо да имамо јасне прецизне захтеве – што није случај. На пример , размотрите захтеве наведене у наставку: „Апликација треба да прихвати само важећи датум испоруке и све неважеће захтеве треба одбити“ Овим захтевима недостају кључни детаљи и веома су двосмислени – како дефинишемо важећи датум? Шта је са форматом? Враћамо ли било какву поруку о одбијању крајњем кориснику итд.? Пример јасних захтева: 1) Апликација треба само прихватите важећи датум испоруке. Датум испоруке се сматра важећим ако јеје
2) Код статуса одговора = 200 Порука: ОК 3) Датум испоруке који не испуњава горе наведене критеријуме треба сматрати неважећим. Ако купац пошаље неважећи датум испоруке, онда мора да одговори следећим порукама о грешци: 3.1 Код статуса одговора НЕ 200 Грешка: Наведени датум испоруке је неважећи; уверите се да је датум у формату ДД/ММ/ГГГГ 3.2 Код статуса одговора НИЈЕ 200 Грешка: Наведен датум испоруке је у прошлост #3) Крива учењаКао што је раније поменуто, приступ тестирању АПИ-ја је другачији у поређењу са приступом који се примењује приликом тестирања апликација заснованих на ГУИ-у. Ако ангажују специјалисте или интерне или консултанте за тестирање АПИ-ја, онда крива учења приступа АПИ тесту или алата за тестирање АПИ-ја може бити минимална. Било која крива учења, у овом случају, била би повезана са стицањем знања о производу или апликацији. Ако је постојећи члан тима одређен да учи АПИ тестирање, онда у зависности од алата за избор, крива учења може бити средње до високе, заједно са променом приступа тестирању. Крива учења за сам производ или апликацију може бити ниска-средња у зависности од тога да ли је овај тестер тестираоту апликацију пре или не. #4) Постојећи скуп вештинаОво је директно повезано са претходном тачком о криву учења. Ако је тестер прелазио са Тестирање засновано на ГУИ, онда би тестер морао да промени приступ тестирању и научи нови алат или оквир према потреби. Нпр. Ако АПИ прихвата захтеве у ЈСОН формату, тестер би морао да научи шта је ЈСОН да би почео да креира тестове. Студија случајаЗадатак Да би повећала постојећу апликацију, компанија је желела да понуди производ у АПИ-ју као и стандардну ГУИ апликацију. Од КА тима је затражено да обезбеди план покривености тестом како би се осигурало да су спремни да прилагоде тестирање АПИ-ја изван редовних тестова заснованих на ГУИ-ју. Изазови
Приступ који је следио тим за ублажавање ризика и заобилажење изазова
ЗакључакАпликације засноване на АПИ-ју имају стекао популарност у последње време. Ове апликације су вишескалабилан у поређењу са традиционалним апликацијама/софтвером и омогућава лакшу интеграцију са другим АПИ-јима или апликацијама. Овај водич за тестирање АПИ-ја детаљно је објаснио све о тестирању АПИ-ја, тестирању померања улево, веб услугама и веб АПИ-ју. Такође смо истражили разлике између веб услуга и веб АПИ-ја на примерима. У другом делу водича, разговарали смо о пуном спектру АПИ тестирања, како да уведете АПИ тестирање у вашој организацији и неким уобичајеним изазовима у овај процес заједно са решењима за њих. Погледајте наш предстојећи водич да бисте сазнали више о веб услугама заједно са примерима!! СЛЕДЕЋИ Водич Водич за услуге објашњава архитектуру, типове и ампер; Компоненте веб услуга заједно са важним терминологијама и разликама између СОАП-а и РЕСТ-а. | |||||||||||||||||||||||||||||||||||||||||||||
| Туториал_#3: | Топ 35 АСП.Нет и Веб АПИ питања за интервју са одговорима Можете истражити листу најпопуларнијих често постављаних АСП.Нет и Веб АПИ питања за интервју са одговорима &амп; примери за почетнике и искусне професионалце у овом водичу. | |||||||||||||||||||||||||||||||||||||||||||||
| Туториал_#4: | ПОСТМАН Водич: АПИ тестирање коришћењем ПОСТМАН Овај водич корак по корак ће објаснити АПИ тестирање коришћењем ПОСТМАН-а заједно са основама ПОСТМАН-а, његовим компонентама и захтевом за узорке &амп; Одговорите једноставним терминима ради лакшег разумевања. | |||||||||||||||||||||||||||||||||||||||||||||
| Туториал_#5: | Тестирање веб услуга помоћу Апацхе ХТТП клијента Овај водич за АПИ се бави извођењем различитих ЦРУД операција на веб услугама и тестирању веб услуга користећи Апацхе ХТТП клијент |
Упутство за тестирање АПИ-ја
Овај одељак ће вам помоћи да стекнете основно разумевање веб услуга и веб АПИ-ја, што ће, заузврат, бити од помоћи у разумевању главних концепата у предстојећим туторијалима у овој серији тестирања АПИ-ја.
АПИ ( Програмски интерфејс апликације) је скуп свих процедура и функција које нам омогућавају да креирамо апликацију приступом подацима или карактеристикамаоперативни систем или платформе. Тестирање таквих процедура је познато као АПИ тестирање.
Тестирање са помаком улево
Једна од важних врста тестирања која се данас поставља у интервјуима за тестирање АПИ-ја је тестирање са помаком улево. Ова врста тестирања се практикује у скоро свим пројектима који прате Агилну методологију.
Пре него што је уведено тестирање Схифт Лефт, тестирање софтвера се појавило тек након што је кодирање завршено и код испоручен тестерима. Ова пракса је довела до гужве у последњем тренутку да се испоштује рок и такође је у великој мери ометала квалитет производа.
Осим тога, уложени напори (када су недостаци пријављени у последњој фази пре производње) су били огроман јер су програмери морали изнова да прођу кроз фазу пројектовања и кодирања.
Животни циклус развоја софтвера (СДЛЦ) Пре тестирања померања улево
Традиционални СДЛЦ ток је био: Захтев – &гт; Дизајн –&гт; Кодирање –&гт; Тестирање.
Недостаци традиционалног тестирања
- Тестирање је крајње десно. Много трошкова настаје када се грешка идентификује у последњем тренутку.
- Време утрошено на решавање грешке и поновно тестирање пре него што је промовишемо у производњу је огромно.
Стога, појавила се нова идеја да се фаза тестирања помери улево, што је довело до тестирања са помаком улево.
Предложено читање =&гт; Тестирање са помаком улево: АТајна мантра за успех софтвера
Фазе тестирања померања улево
Тестирање померања улево довело је до успешног преласка са откривања дефекта на превенцију дефеката. Такође је помогло софтверу да брзо откаже и отклони све грешке што је пре могуће.
Веб АПИ
Уопштено говорећи, Веб АПИ се може дефинисати као нешто што преузима захтев од клијента система на веб сервер и шаље одговор са веб сервера на клијентску машину.
Како функционише АПИ?
Узмимо врло уобичајен сценарио резервације лета на ввв.макемитрип.цом, која је онлајн услуга путовања која обједињује информације од више авио-компанија. Када идете на резервацију лета, уносите информације као што су датум путовања/датум повратка, класа итд. и кликните на претрагу.
Ово ће вам показати цену више авио-компанија и њихову доступност. У овом случају, апликација је у интеракцији са АПИ-јима више авио-компанија и на тај начин даје приступ подацима авио-компаније.
Још један пример је ввв.триваго.цом који пореди и наводи цене, доступност итд. различитих хотела из одређеног града. Ова веб локација комуницира са АПИ-јима више хотела како би приступила бази података и наводи цене и доступност са њихове веб локације.
Дакле, веб АПИ се може дефинисати као „интерфејс који олакшава комуникацију између клијентске машине и тхевеб сервер”.
Веб услуге
Веб услуге су (као Веб АПИ) услуге које служе са једне машине на другу. Али главна разлика која се јавља између АПИ-ја и веб услуга је у томе што веб услуге користе мрежу.
Може се рећи да су све веб услуге веб АПИ-ји, али сви веб АПИ-ји нису веб услуге (објашњено у последњи део чланка). Дакле, веб услуге су подскуп веб АПИ-ја. Погледајте дијаграм у наставку да бисте сазнали више о веб АПИ-ју и веб услугама.
Веб АПИ наспрам веб услуга
Веб услуге вс Веб АПИ
И Веб АПИ и Веб услуге се користе за олакшавање комуникације између клијента и сервера. Главна разлика је само у начину на који комуницирају.
Сваком од њих је потребно тело захтева које је прихватљиво на одређеном језику, њихове разлике у обезбеђивању безбедне везе, брзина комуникације са сервером и одговора клијенту итд.
Разлике између веб услуга и веб АПИ-ја су наведене испод за вашу референцу.
Веб услуга
- Веб услуге генерално користе КСМЛ (Ектенсибле Маркуп Лангуаге), што значи да су безбедније.
- Веб услуге су безбедније пошто и Веб услуге и АПИ-ји пружају ССЛ (Сецуре Соцкет Лаиер) током преноса података , али такође обезбеђује ВСС (Безбедност веб услуга).
- Веб услуга је подскуп веб АПИ-ја. На пример, Веб услуге су засноване само на три стила коришћења, тј. СОАП, РЕСТ и КСМЛ-РПЦ.
- Веб услугама је увек потребна мрежа за рад.
- Веб услуге подржавају „Један код различите апликације“. То значи да је генерички код написан у различитим апликацијама.
Веб АПИ
- Веб АПИ генерално користи ЈСОН (ЈаваСцрипт Објецт Нотатион), што значи да је веб АПИ бржи.
- Веб АПИ је бржи јер је ЈСОН лаган, за разлику од КСМЛ-а.
- Веб АПИ-ји су надскуп веб услуга. На пример, Сва три стила веб услуга су такође присутна у Веб АПИ-ју, али осим тога, он користи друге стилове као што је ЈСОН – РПЦ.
- Веб АПИ не захтева нужно мрежа за рад.
- Веб АПИ може, али не мора да подржава интероперабилност у зависности од природе система или апликације.
Увођење АПИ тестирања у вашу организацију
У нашем свакодневном животу, сви смо толико навикли на интеракцију са апликацијама са АПИ-јима, а ипак не размишљамо ни о позадинским процесима који покрећу основну функционалност.
На пример , Узмимо у обзир да претражујете производе на Амазон.цом и видите производ/посао који вам се заиста свиђа и желите да га поделите са својом Фацебоок мрежом.
У тренутку када кликнете на Фацебоок икони у одељку за дељење странице и унесите својуАкредитиве Фацебоок налога за дељење, ви сте у интеракцији са АПИ-јем који неприметно повезује веб локацију Амазон са Фацебоок-ом.
Пребацивање фокуса на тестирање АПИ-ја
Пре него што више разговарамо о АПИ тестирању, хајде да разговарамо о разлозима за које су апликације засноване на АПИ-ју стекле популарност у последње време.
Постоји неколико разлога због којих организације прелазе на производе и апликације засноване на АПИ-ју. И неколико њих је наведено у наставку за вашу референцу.
#1) Апликације засноване на АПИ-ју су скалабилније у поређењу са традиционалним апликацијама/софтвером. Брзина развоја кода је бржа и исти АПИ може да сервисира више захтева без већих промена кода или инфраструктуре.
#2) Развојни тимови не морају да почну да кодирају од нуле сваки пут време када почну да раде на развоју функције или апликације. АПИ-ји најчешће поново користе постојеће, поновљиве функције, библиотеке, ускладиштене процедуре итд. и стога их овај процес може учинити продуктивнијим у целини.
На пример, Ако сте програмер који ради на веб-сајт за е-трговину и желите да додате Амазон као процесор плаћања – тада не морате да пишете код од нуле.
Све што треба да урадите је да подесите интеграцију између ваше веб локације и Амазон АПИ-ја користећи Интеграциони кључеви и позовите Амазон АПИ за обраду плаћања током плаћања.
#3) АПИ-ји дозвољавајулака интеграција са другим системима како за подржане самосталне апликације тако и за софтверске производе засноване на АПИ-ју.
На пример , Узмимо у обзир да желите да пошаљете пошиљку из Торонта у Њујорк . Идите на интернет, идите на добро познату веб локацију за транспорт или логистику и унесите тражене информације.
Након давања обавезних информација, када кликнете на дугме Добиј цене – у позадини, ова веб локација за логистику се можда повезује са неколико АПИ-ја и апликација оператера и добављача услуга да бисте добили динамичке стопе за комбинацију локација од почетка до одредишта.
Пуни спектар тестирања АПИ-ја
Тестирање АПИ-ја није ограничено на слање захтева на АПИ и анализирајући само одговор на тачност. АПИ-ји треба да се тестирају на њихов учинак под различитим оптерећењима у погледу рањивости.
Разговарајмо о томе детаљно.
(и) Функционално тестирање
Функционално тестирање може бити изазован задатак због недостатка ГУИ интерфејса.
Да видимо како се приступ функционалног тестирања за АПИ-је разликује од апликација заснованих на ГУИ-у, а такође ћемо разговарати о неким примерима око тога.
а) Најочигледнија разлика је у томе што не постоји ГУИ за интеракцију. Тестери који обично раде функционално тестирање засновано на ГУИ-у сматрају да је мало теже прећи на тестирање апликација без ГУИ-ја у поређењу санеко ко је већ упознат са тим.
У почетку, чак и пре него што почнете да тестирате АПИ, мораћете да тестирате и верификујете сам процес аутентификације. Метод аутентификације ће се разликовати од једног АПИ-ја до другог АПИ-ја и укључивао би неку врсту кључа или токена за аутентификацију.
Ако нисте у могућности да се успешно повежете са АПИ-јем, даље тестирање не може да се настави. Овај процес се може сматрати упоредивим са аутентификацијом корисника у стандардним апликацијама где су вам потребни важећи акредитиви да бисте се пријавили и користили апликацију.
б) Провера валидације поља за тестирање или валидација улазних података је веома важна током тестирања АПИ-ја. Ако је био доступан стварни интерфејс заснован на обрасцима (ГУИ), онда би провере ваљаности поља могле да се имплементирају у предњи или задњи део, чиме се обезбеђује да кориснику није дозвољено да унесе неважеће вредности поља.
На пример, Ако апликација треба да формат датума буде ДД/ММ/ГГГГ, онда можемо да применимо ову валидацију на обрасцу који прикупља информације да бисмо били сигурни да апликација прима и обрађује важећи датум.
Ово, међутим, није исто за АПИ апликације. Морамо да обезбедимо да је АПИ добро написан и да може да примени све ове провере ваљаности, разликује важеће и неважеће податке и врати статусни код и поруку о грешци приликом валидације крајњем кориснику путем одговора.
ц) Тестирање