Тестване на API чрез използване QTP/UFT: Пълен урок

по: Томас Хамилтън Томас Хамилтън
Hours Обновено

⚡ Умно обобщение

API тестване в QTP/UFT Услугата се валидира директно, без да е необходим потребителски интерфейс. API тестът е изграден като поток от дейности върху платно, а контролните точки решават дали всеки отговор е преминал успешно.

  • 🔘 Без графичен потребителски интерфейс: Входните данни се изпращат директно към услугата и записаният отговор се сравнява с очакванията.
  • ☑️ Пет поддържани типа: Уеб услуга, REST, обектно-ориентиран език, база данни и собствени API.
  • ✅ Поток на активност, а не обекти: Плъзнете HTTP заявка от кутията с инструменти върху тестовия поток и задайте нейните свойства.
  • 🧪 Контролните пунктове решават присъдата: Контролна точка на код за състояние 200 отбелязва, че повикването е успешно без ръчна проверка.
  • 🛠️ Резултати на едно място: Прегледът на резултатите от изпълнението отчита всяка дейност, нейния отговор и резултата от всяка контролна точка.
  • 📌 Настоящо именуване: QTP плюс HP Service Test стана UFT, сега се продава като OpenText Функционално тестване (UFT Едно).
Прочетете повече

Създаване и изпълнение на API тест в QTP намлява UFT Един

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

Какво е API тестване?

Тестване на API е тестване на софтуер метод за валидиране на интерфейси за приложно програмиране (API). Целта на API тестването е да се тества API по отношение на функционалност, надеждност, сигурност и производителност. При API тестването софтуерът се използва за изпращане на входни данни към API, а изходните данни се записват, за да се тества API.

Така че API тестването е:

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

Диаграмата по-долу поставя API тестването между клиента, който извиква услугата, и данните, до които достига.

Обхват на API тестване между клиентския слой и слоя на базата данни

Защо API тестването е важно?

API тестването има четири значителни предимства

1. API тестването е тенденцията

Както показва следващата фигура, API тестването се разрасна много бързо през последните десет години. То стана много по-популярно от другите видове тестване.

Диаграма, показваща ръст в приемането на API тестване за десет години

2. Ефективно време

С API тестване можем да използваме паралелно изпълнение, за да намалим времето за изпълнение на тестовете. Можете да спестите до 5 пъти в сравнение с други видове тестване.

3. Езиково независим

При API тестването данните се обменят чрез XML or JSON, така че всеки език може да се използва за тестване на отговора. Например, ако имате услуга, чийто отговор е във формат JSON, можете лесно да анализирате данните с Java, C# или който и да е друг език.

4. Лесна интеграция на GUI

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

API тестване с UFT (Унифицирано функционално тестване)

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

Последната версия на QTP, наречен HP Unified Функционално тестване (UFT), е комбинация от HP QTP (инструмент за тестване на графичен потребителски интерфейс) и HP Service Test (инструмент за тестване на API). UFT поддържа уеб, Java, .NET, Oracle, Siebel, уеб услуги и много други основни езици и платформи, които по-старите версии не поддържаха.

⚠️ Наименование на продукта: инструментът, описан тук като HP UFT сега се продава като OpenText Функционално тестване (UFT Един), след като е преминал от HP към Micro Focus и след това към OpenTextЕкраните по-долу са от изданието от ерата на HP, така че формулировката на менютата се различава от текущите компилации, но потокът от тестове на API, дейностите и контролните точки работят по същия начин.

Вид поддръжка на API тестове от HP UFT

  1. Уеб услуга
  2. ПОЧИВКА
  3. Обектно-ориентиран език
  4. База данни
  5. Патентован API

СВЪРЗАНИ СТАТИИ

Започнете първото си API тестване с QTP

В това тестване на API в UFT урок, ще разгледаме UFT Примери за тестване на API. Ще тестваме Graph API на Facebook. Ще тестваме API-то като Тестов случай По-долу

  1. Вземете профил на посочения потребител във Facebook.
  2. Проверете дали профилът отговаря на очакванията

Ето стъпка за изграждане на тестов поток за този API.

Планиран UFT тестов поток за тестовия случай на Facebook Graph API

⚠️ Относно този пример: Facebook оттегли Graph API v2.3 преди години и показаният по-долу токен за достъп отдавна е изтекъл, така че точното извикване вече не връща данни. Оригиналната заявка се запазва непроменена като в работещия пример; насочете същите стъпки към всяка текуща REST крайна точка, за да продължите.

Стъпка 1) Отворете HP UFT и създайте нов проект API тестване

  1. Изберете Старт > (Всички) програми > Софтуер на HP > HP Unified Functional Testing > Unified Functional Testing. В текущите издания това е просто UFT Един за бърз достъп.

    Windows Пътят в менюто „Старт“ до прекия път на HP Unified Functional Testing

  2. Кликнете Файл > Нов > Тест, Изберете API тест тип

    UFT Диалогов прозорец „Добавяне на нов тест“ с избран тип API тест

  3. Когато се отвори диалогов прозорец, въведете името на API теста: API_Facebookи изберете място за запазване на този проект. Кликнете Създаване на за да създадете API тестов проект.

    Именуване на новия API тест API_Facebook и избор на място за запазване

Стъпка 2) Добавяне на HTTP заявка към тестовия поток

Ще използваме HTTP заявката, за да отправим заявка към Facebook API.

  1. Изберете Toolbox > мрежа

    Мрежовата група се разшири в UFT Панел с инструменти

  2. Плъзнете елемент HTTP заявка за тестване на потока.

    HTTP заявка, пусната в UFT Платно за поток на тестване на API

Стъпка 3) Конфигуриране и предаване на параметри в HTTP заявка

  1. Щракнете с десния бутон върху HTTP заявка обект, за да го редактирате.

    Меню с десен бутон върху обекта HTTP Request в тестовия поток

  2. В секцията „Свойства“ въведете URL

    Панелът със свойства на активността HTTP заявка с URL област

    https://graph.facebook.com/v2.3/me?access_token=CAACEdEose0cBANJsDnbZC92mNAghaM6xxZCZBZAvKlMXS98VYvKy%20OlrfAdsUWR8x5aw9Kqc0grscs9zb9IYED4VC3FwapIZBj%20dsuxy%20HdLcff38gYUBFNeRQlH%20fN7eXKoVZBNl0bR233ZAZCw8fLF1QLh98ry2ZBeYBhXLabtTDkFPZA1IqhaMG0mQp30zO1%20QxQ19nVCxZArJA6XRoB1o5FMepII5cn3DgbBmTgZD
  3. Можете също да предадете параметър в API, като зададете стойности в Заглавка на заявката решетка.

    Мрежата на заглавката на заявката, използвана за предаване на допълнителни параметри в API извикването

    Използвайте Graph API Explorer на Facebook, за да получите стойността на access_token.

  4. Нагласи HTTP метод да се GET.

    Списък с HTTP методи на активността HTTP заявка, зададена на GET

    GET е избран като HTTP метод за заявката

  5. Определен Контролните пунктове от HTTP заявкаЗадайте кода на състоянието на 200 в частта „Контролни точки“. Контролните точки ви позволяват да видите дали действието е било успешно, без да се налага да проверявате резултата ръчно, а резултатът от теста (или „успешен“, или „неуспешен“) се определя от тях. Код на състояние 200 означава, че тестът е преминал успешно.

    Панел с контролни точки с очакван код на състоянието, зададен на 200

Стъпка 4) Изпълнете теста

Щракнете върху бягане бутон или натиснете F5, за да отворите диалоговия прозорец „Изпълнение на тест“. Щракнете бягане за компилиране и изпълнение на теста.

UFT Диалоговият прозорец „Изпълнение на тест“ се отваря от бутона „Изпълнение“

Стъпка 5) Вижте резултата

Отваря се Прегледът на резултатите от изпълнението. В това API тестване с помощта на UFT Например, неуспешен тестов случай се отчита както е показано на следващата фигура.

Преглед на резултатите от изпълнението, показващ неуспешен тестов случай на API

Когато тестовият случай е успешно завършен, резултатът се отчита, както е показано по-долу.

Преглед на резултатите от изпълнението, показващ успешното преминаване на тестовия случай на API

Вашият първи API тест в UFT вече е завършено.

Къде да отида от тук

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

Въпроси и Отговори

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

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

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

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

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

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

SoapUI намлява Postman са по-леки и безплатни в началото. UFT заслужава си място там, където един и същ проект трябва да обхваща и потребителския интерфейс, тъй като един лиценз и един набор от резултати обхващат и двата слоя.

Освен кода за състояние на HTTP, API тестът може да провери съдържанието на тялото на отговора, отделните стойности на заглавките и върнатите данни в сравнение с очаквания източник. Всеки резултат от контролната точка се показва заедно със заявката в инструмента за преглед на резултати от изпълнение.

Обобщете тази публикация с: