Меню

Използване на JSON за тестване на интерфейс

using json interface testing

Опитайте Нашия Инструмент За Премахване На Проблемите

Използване на JSON за тестване на интерфейс:

Тестването на интерфейса проверява комуникацията между две различни системи. Извършва се на тестваното приложение, за да се провери дали връзката между двете мрежи е извършена правилно.

Интерфейсът е основно връзката между две софтуерни системи и тестването, което връзката за трансфер на данни се нарича Интерфейсно тестване. Интерфейсът обхваща широк спектър от услуги в реалния свят, може да се използва за позоваване на уеб услуга, API и т.н.

Тестване на интерфейса

Интерфейсът съдържа набор от правила, съобщения, команди и т.н., който улеснява комуникацията между две системи.

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

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

Извършва се интерфейсен тест за оценка на гореспоменатите сценарии, за да се провери дали компонентите предават правилно контрола и данните един на друг. Той също така проверява взаимодействието между различни модули.

Какво ще научите:

Защо се извършва интерфейсен тест?

Извършва се, за да се гарантира:

  • Ако комуникацията между системите се извършва правилно.
  • Всички използвани в системата софтуер и хардуер работят правилно.
  • Всички документи, свързани с комуникацията, са достъпни на всички интегрирани платформи.
  • Изискванията за сигурност и криптиране се придържат към комуникацията между системите.
  • Интегрираните компоненти са в състояние да се справят с мрежови грешки и загуба на комуникация.

Видове намерени дефекти

Повечето дефекти, открити при тестването на потребителския интерфейс, се дължат на неправилно картографиране на данните между системите. Следователно повечето грешки могат да бъдат класифицирани в следните категории.

  • Несъгласувано предаване на данни между двете системи.
  • Една от системите погрешно интерпретира предаването на данни от друга система.
  • Предавателният канал или интерфейсът между двете системи се провалят и това ограничава трансфера на данни между системите, като по този начин целият интерфейс се проваля.

Как се изпълнява?

Той може да бъде категоризиран основно на следните фази:

  • Интерфейсите могат да бъдат тествани индивидуално по време на системно тестване . Този тип изпитване се извършва предимно с помощта на система за заглушаване или манекен. Фиктивна система или заглушител имитира поведението на цялото взаимодействие на системата.
  • Друг случай, при който се извършва интерфейсният тест, е кръстовище, при което две системи комуникират помежду си.
  • Следователно ние проверяваме дали данните, изпратени от една система, са правилно картографирани и вмъкнати в друга система или не. Освен вмъкването на данни, ние също проверяваме целостта на данните, т.е. данните, когато са вкарани в друга система, не са били манипулирани или променяни и т.н.
  • Тестването може да се извърши и когато системата предава данни в друга база данни на приложения. Тук ще тестваме дали данните от една система са били правилно вмъкнати в дадена колона от дадената таблица въз основа на картографирането. Също така ще тестваме целостта и последователността на данните по отношение на системата източник.

Във всички тези сценарии за тестване интерфейсният тест се извършва въз основа на бизнес изискванията и правилата за бизнес потока.

Разлика между тестване на интерфейса и тестване на интеграция

Извикват се проверка и валидиране на функционалността от край до край на компоненти, свързани заедно Интеграционно тестване или по-популярно като тестване на системната интеграция. Интеграционното тестване проверява главно дали две или повече интегрирани системи са работили безупречно заедно или не.

Тестване Интерфейс от друга страна основно се концентрира върху канала за връзка между двете системи. Каналът за връзка между две или повече системи се нарича Интерфейс. Тестването на този канал за връзка се нарича Interface Testing. Повечето от интерфейсите са или API, или уеб услуги. Той няма потребителски интерфейс, но взема вход и представя на потребителя изход.

Например

Тестване на интерфейса

В горния пример уебсайтът и базата данни споделят интерфейс за предаване на информацията за вход, т.е. потребителско име и парола.

Интерфейсът използва уеб услуга за изпращане на информацията за вход в базата данни, която от своя страна потвърждава автентичността на входящото съобщение (потребителско име и парола) и връща стойността като истина, ако потребителското име и паролата съвпадат със записа, присъстващ в базата данни или false в случай, че някой от тях или както потребителското име, така и паролата не съвпадат с данните, присъстващи вътре.

Нека обсъдим примера за тестване на интерфейс:

Да приемем, че имаме приложение, при което имаме различни бази данни, които си взаимодействат.

В това пример , ще разгледаме две взаимодействия с база данни чрез интерфейсен канал.

Нека помислим, че има две бази данни или приложение, база данни A и B. „A“ прехвърля някои данни в „B“, която след това се използва от B за извършване на някаква операция. След извършване на определена операция върху входящите данни B вмъква тези данни в базата данни и създава изходен JSON за потвърждение със списъка с актуализирани данни и ги изпраща обратно на A.

И A, и B използват интерфейсен канал за комуникация помежду си.

Бизнес сценарий

„А“ съдържа данни за служителите за всички служители, принадлежащи към финансовия отдел.

Данните трябва да бъдат пренесени на „Б ' ежедневно. „B“ съдържа данни за общи подробности за служителите. Всички данни от „А“ трябва да бъдат прехвърлени в определена таблица и колона на „Б“. Освен въведените данни, „B“ също трябва да сортира и организира данните. Също така трябва да се увери дали данните са въведени срещу правилния служител.

След като данните бъдат въведени в системата, „B“ трябва да изпрати изходен JSON, за да потвърди дали данните са вмъкнати в базата данни.

В случай на несъответствие в JSON схема или липсващи данни „B“ няма да обработи данните и ще изпрати съобщение Reject JSON с причината за отхвърлянето.

Бизнес сценарий на тестване на интерфейса

Тествайте настройката на средата

За да тестваме сценарий като този, ще ни е необходим тест за заглушаване, който да имитира база данни „A“. Разработчикът може да предостави местоположение, където можете или да зарежете тестовия JSON, или фалшив потребителски интерфейс и да поставите вашите JSON данни и да извикате обработката през интерфейса. За целите на тестването можем да имаме и изходно местоположение, където да получим потвърждението JSON от „B“.

В нашата пример , ще използваме пътека към папка, където ще поставим нашия тестов JSON, услугата постоянно ще проследява местоположението на JSON файла. След като файлът присъства, услугата ще вземе файла и ще го изпрати на „B“ чрез интерфейса. След като файлът бъде взет, той ще бъде изтрит от мястото за взимане.

Започване на вашето тестване

След като тестовата среда е настроена, следващата стъпка е да създадете тестови данни.

Докато създаваме тестови данни (прочетете тестовия JSON), трябва да имаме предвид няколко неща:

  • Спазвайте бизнес правилата.
  • Уверете се, че задължителните полета са налице.
  • Променете стойността на полетата според бизнес правилата за всеки тест.
  • Уверете се, че схемата JSON е в правилния формат.
  • Уверете се, че номенклатурата за JSON име на файл е спазена.

Нека да разгледаме примерния тест JSON, който ще използваме за тестване:

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

Започнете своя тест

След като създадете своя тестов JSON файл, пуснете го на мястото за вземане. Услугата ще вземе това и ще го публикува в базата данни B.

Сценарии за тестване:

Може да има няколко сценария, които трябва да бъдат тествани за този пример, като:

  • Работа с уеб услугата за изпращане и получаване на данни.
  • Целостта на данните за входните данни. Това може да бъде проверено чрез заявки за таблици и колони в база данни Б за данните, въведени чрез тестовия JSON.
  • Отрицателни сценарии.

Отначало ще проверим дали тестовият JSON файл е взет от местоположението или не присъства в него. Това ще потвърди работата на услугата. След това ще преминем към изходната папка, за да видим изходния JSON. Наличие на изход JSON валидира, ако входните данни са изпратени до база данни В и е получено потвърждение за същото.

Следващата част от тестването включва проверка на данните, въведени в базата данни.

В горния тест ще проверим дали данните, изпратени чрез тестовия JSON, са били правилно въведени в базата данни. Ще проверим целостта на данните, тяхната последователност и вмъкване на данни. Ще трябва да потърсим база данни Б за дадената колона в определена таблица, за да проверим дали данните са били правилно вмъкнати в таблицата.

Да приемем, че имаме таблица EmpDetails, където данните трябва да бъдат вмъкнати. И така, ще изпълним заявка за валидиране на данните.

Запитването ще бъде нещо подобно:

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

Тук ще използваме идентификатора на служителя като първичен ключ за заявки за данни в таблицата EmpDetails. Ще направим заявка, като използваме името на всички колони, в които са вмъкнати данните. Тогава данните в името на колоната могат да бъдат валидирани с данните, изпратени чрез JSON.

В горния случай данните от JSON се съхраняват в повече от една таблица в базата данни, поради което можете да използвате SQL JOINS, за да извлечете всички желани данни.

Третата стъпка в тестването ще бъде тестване на негативните сценарии.

Някои от негативните сценарии, които могат да бъдат тествани, са:

  • Поведението на системата, когато чрез JSON се подават неправилни данни.
  • Когато JSON има грешна схема или структура.
  • Когато в обработения JSON липсва първичният ключ или някакви задължителни полета.
  • Номенклатурата на JSON файла не е валидна.

Във всички тези случаи системата трябва да може да обработва тези сценарии и не трябва да се вмъкват данни в системата според бизнес правилото.

Заключение

Каналът за връзка между две системи, чрез които се предават данни, се нарича Интерфейс и тестването на интерфейса работи главно около тестването на тези връзки. Повечето от интерфейсите използват уеб услуга или API. Не винаги има потребителски интерфейс, но приема вход и осигурява изход.

безплатен блокиращ прозорец за Google Chrome

Като един от най-широко използваните формати за трансфер на данни, JSON може да се използва за интерфейсен трансфер на данни.

Тестерът трябва да има основни познания за структурата на JSON, за да създава тестови данни (под формата на JSON) и да чете изходни данни от системата. Тестерът също трябва да е добре запознат с картографирането между JSON ключовете и колоната на таблицата на базата данни.

Всеки тестер, който иска да работи по тестване на интерфейса, трябва да има ясни познания за бизнес насоките и правилата на приложението. Тестерът също трябва да притежава адекватни познания за базата данни и трябва да може да пише прости SQL заявки.

За всеки въпрос или разяснение, моля, свържете се с нас в раздела за коментари.

Урок № 5: Въпроси за интервю за JSON

Препоръчително четене

^