Мени

Коришћење ЈСОН-а за тестирање интерфејса

using json interface testing

Испробајте Наш Инструмент За Елиминисање Проблема

Коришћење ЈСОН-а за тестирање интерфејса:

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

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

Испитивање интерфејса

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

Ово испитивање се углавном концентрише на испитивање два главна сегмента:

  • Комуникација базе података и сервера апликација
  • Веб и комуникација са сервером апликација

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

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

Зашто се изводи тест интерфејса?

Изводи се како би се осигурало:

  • Ако се комуникација између система врши правилно.
  • Сав софтвер и хардвер који се користе у систему раде исправно.
  • Сви документи који су повезани са комуникацијом доступни су на свим интегрисаним платформама.
  • Захтеви за безбедношћу и шифровањем придржавају се комуникације између система.
  • Интегрисане компоненте су у стању да се носе са мрежним кваровима и губитком комуникације.

Врсте пронађених недостатака

Већина недостатака пронађених у тестирању корисничког интерфејса настала је због нетачног мапирања података између система. Стога се већина грешака у основи може класификовати у следеће категорије.

  • Неусаглашен пренос података између два система.
  • Један од система погрешно тумачи пренос података из другог система.
  • Канал преноса или интерфејс између два система не успевају и то ограничава пренос података између система, што доводи до неуспеха целокупног интерфејса.

Како се изводи?

Може се углавном сврстати у следеће фазе:

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

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

Разлика између тестирања интерфејса и тестирања интеграције

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

Тестирање Интерфејс с друге стране, у основи се концентрише на канал везе између два система. Канал везе између два или више система назива се интерфејс. Тестирање овог канала везе назива се тестирање интерфејса. Већина интерфејса су АПИ или веб услуге. Нема УИ, али узима улаз и приказује кориснику излаз.

На пример

Испитивање интерфејса

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

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

Размотримо пример тестирања интерфејса:

Рецимо да имамо апликацију у којој имамо различите базе података које међусобно комуницирају.

У ово пример , размотрићемо интеракцију две базе података кроз интерфејс канал.

Узмимо у обзир да постоје две базе података или апликација, база података А и Б. „А“ преноси неке податке у „Б“, коју затим користи Б за извођење неке операције. Након извршавања одређене радње на долазним подацима Б убацује те податке у базу података и креира излазни ЈСОН за потврду са листом ажурираних података и шаље их назад А.

И А и Б користе интерфејс канал за комуникацију између себе.

Пословни сценарио

„А“ садржи податке о запосленима за све запослене који припадају одељењу за финансије.

Податке треба пренети на „Б. ' на дневној бази. “Б” садржи податке о општим детаљима запосленог. Сви подаци из „А“ морају се пренети у одређену табелу и колону „Б“. Осим уноса података, „Б“ такође треба да сортира и организује податке. Такође мора да се увери да ли су подаци унети против исправног запосленог.

Једном када се подаци унесу у систем, „Б“ треба да пошаље излазни ЈСОН да потврди да ли су подаци уметнути у базу података.

У случају било каквих одступања у ЈСОН шеми или недостајућих података, „Б“ неће обрађивати податке и послат ће ЈСОН поруку Одбиј са разлогом за одбијање.

Пословни сценарио испитивања интерфејса

Тестирање подешавања окружења

Да бисмо тестирали сценарио попут овог, требат ће нам тестни крад који имитира базу података „А“. Програмер може да обезбеди локацију на којој можете да избаците свој тестни ЈСОН или лажни кориснички интерфејс и налепите своје ЈСОН податке и да позовете обраду кроз интерфејс. За потребе тестирања можемо имати и излазну локацију на којој можемо добити потврду ЈСОН од „Б“.

У нашем пример , користићемо путању до директоријума где ћемо ставити наш тестни ЈСОН, услуга ће непрестано пробијати локацију за ЈСОН датотеку. Једном када датотека постоји, услуга ће је преузети и послати на „Б“ преко интерфејса. Једном када се датотека преузме, она ће бити избрисана са места преузимања.

Започињање тестирања

Једном када је тест окружење постављено, следећи корак је стварање података о тестирању.

Приликом креирања тест података (прочитајте тест ЈСОН) требали бисмо имати на уму неколико ствари:

  • Поштујте пословна правила.
  • Обавезно попуните поља.
  • Промените вредност поља у складу са пословним правилима за сваки тест.
  • Уверите се да је ЈСОН шема у исправном формату.
  • Уверите се да је придржана номенклатура за име датотеке ЈСОН.

Погледајмо узорак теста ЈСОН који ћемо користити за тестирање:

{ 'employeeID ': 2569875, 'LastName': “Jackson”, 'baseSalary': 2569, 'DesignationCode':'P102', “Expenditure”:{ 'Month':“Feb”, 'Year': 2017, 'Official':560, 'Others”:0, } }

Започните тест

Када направите тест ЈСОН датотеку, одложите је на место за преузимање. Служба ће ово преузети и послати у базу података Б.

Сценарији за тестирање:

Постоји неколико сценарија које треба тестирати за овај пример, као што су:

  • Рад са веб услугом за слање и примање података.
  • Интегритет података за улазне податке. Ово се може потврдити испитивањем табела и колона у бази података Б за податке унете кроз тест ЈСОН.
  • Негативни сценарији.

Прво ћемо проверити да ли је тестна ЈСОН датотека преузета са локације или није присутна на локацији. Ово ће потврдити рад службе. Даље, отићи ћемо до излазне фасцикле да бисмо погледали излазни ЈСОН. Присуство излаза ЈСОН потврђује да ли су улазни подаци послати у базу података Б и примљено потврда за исти.

Следећи део тестирања састоји се од валидације података унетих у базу података.

У горе наведеном тесту проверићемо да ли су подаци послати кроз тест ЈСОН исправно унети у базу података. Проверићемо интегритет података, њихову доследност и уметање. Морамо да упитамо базу података Б за дати ступац у одређеној табели да бисмо проверили да ли су подаци тачно уметнути у табелу.

Рецимо да имамо табелу ЕмпДетаилс у коју треба убацити податке. Дакле, покренућемо упит за потврду података.

Упит ће бити отприлике овакав:

SELECT employeeID, LastName, baseSalary, DesignationCode, Month, Year, Official, Others FROM EmpDetails Where employeeID = 2569875;

Овде ћемо користити ид запосленика као примарни кључ за испитивање података у табели ЕмпДетаилс. Упит ћемо извршити користећи све називе колона у које су убачени подаци. Тада се подаци у имену колоне могу проверити са подацима послатим преко ЈСОН-а.

У горе наведеном случају подаци из ЈСОН-а чувају се у више табела базе података, стога можете користити СКЛ ЈОИНС да бисте преузели све жељене податке.

Трећи корак у тестирању биће тестирање негативних сценарија.

Неки од негативних сценарија који се могу тестирати су:

  • Понашање система када се нетачни подаци уносе кроз ЈСОН.
  • Када ЈСОН има погрешну шему или структуру.
  • Када обрађеном ЈСОН-у недостаје примарни кључ или неко обавезно поље.
  • Номенклатура ЈСОН датотеке није важећа.

У свим тим случајевима систем би требало да буде у стању да обрађује ове сценарије и не би требало уносити податке у систем према пословном правилу.

Закључак

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

Питања и одговори за интервјуе за старије програмере

Као један од најчешће коришћених формата за пренос података, ЈСОН се може користити за интерфејсни пренос података.

Испитивач треба да поседује основно знање о ЈСОН структури да би створио податке о тестовима (у облику ЈСОН-а) и да би читао излазне податке из система. Тестер би такође требао бити добро упућен у мапирање између ЈСОН кључева и колоне табеле базе података.

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

За било какво питање или појашњење, контактирајте нас у одељку за коментаре.

Водич бр. 5: ЈСОН Интервју питања

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

^