Testarea API UTILIZÂND QTP/UFT: Tutorial complet

⚡ Rezumat inteligent

Testarea API în QTP/UFT Un serviciu este validat direct, fără a fi necesară implicarea unei interfețe utilizator. Un test API este construit ca un flux de activități pe o pânză, iar punctele de control decid dacă fiecare răspuns este satisfăcător.

  • 🔘 Nu este implicată interfața grafică: Datele de intrare sunt trimise direct către serviciu, iar răspunsul înregistrat este comparat cu așteptările.
  • ☑️ Cinci tipuri acceptate: Servicii web, REST, limbaje orientate pe obiecte, baze de date și API-uri proprietare.
  • Fluxul activității, nu obiectele: Trageți o cerere HTTP din Toolbox în fluxul de testare și setați-i proprietățile.
  • 🧪 Punctele de control decid verdictul: Un punct de control al codului de stare 200 marchează apelul ca fiind reușit fără inspecție manuală.
  • 🛠️ Rezultate într-un singur loc: Vizualizatorul de rezultate ale execuției raportează fiecare activitate, răspunsul acesteia și rezultatul fiecărui punct de control.
  • 📌 Denumire actuală: QTP plus Testul de service HP a devenit UFT, acum vândut ca OpenText Testare funcțională (UFT Unu).

Construirea și rularea unui test API în QTP și UFT O

Înainte de a testa o API, trebuie să știm ce este o API. O API (Application Programming Interface - Interfață de Programare a Aplicațiilor) este o colecție de funcții și proceduri software care pot fi executate de alte aplicații software.

Ce este testarea API?

Testare API este testare software metodă de validare a interfețelor de programare a aplicațiilor (API). Scopul testării API este de a testa API-ul în termeni de funcționalitate, fiabilitate, securitate și performanță. În testarea API, software-ul este utilizat pentru a trimite intrări către API, iar ieșirea este înregistrată pentru a testa API-ul.

Deci, testarea API este:

  • Testare fără GUI
  • Simularea programatică a datelor sau a scenariilor de flux de control.
  • Se concentreze pe funcționalitate, nu pe comportament sau pe experiența clienților.

Diagrama de mai jos plasează testarea API între clientul care apelează serviciul și datele la care ajunge acesta.

Domeniul de aplicare al testării API între nivelul client și nivelul bazei de date

De ce este importantă testarea API?

Testarea API are patru avantaje semnificative

1. Testarea API este tendința

După cum arată figura următoare, testarea API a crescut foarte rapid în ultimii zece ani. A devenit mult mai populară decât alte tipuri de testare.

Grafic care arată creșterea adoptării testării API pe parcursul a zece ani

2. Timp eficient

Cu ajutorul testării API putem folosi execuția paralelă pentru a reduce timpul de execuție a testelor. Puteți economisi de până la 5 ori în comparație cu alte tipuri de testare.

3. Independent de limbă

În Testarea API, datele sunt schimbate prin XML or JSON, deci orice limbaj poate fi folosit pentru a testa răspunsul. De exemplu, dacă aveți un serviciu al cărui răspuns este în format JSON, puteți analiza cu ușurință datele cu Java, C# sau orice altă limbă.

4. Integrare GUI ușoară

pentru că UFT Se țin testele GUI și testele API în aceeași soluție, un apel API poate configura datele pentru un test al interfeței utilizator și ambele tipuri de raport de testare în aceleași rezultate de rulare. Aceasta menține o verificare a serviciului și ecranul care o consumă într-un singur proiect în loc de două lanțuri de instrumente.

Testarea API cu UFT (Testare funcțională unificată)

Există multe instrumente disponibile, atât open-source, cât și comerciale. UFT este o alegere puternică pentru executarea testelor API, deoarece fluxul este construit vizual, iar configurația este păstrată într-un singur panou de proprietăți.

Ultima versiune a QTP, numită HP Unified Functional Testing (UFT), este o combinație de HP QTP (un instrument de testare a interfețelor grafice) și HP Service Test (un instrument de testare a API-urilor). UFT suportă Web-ul, Java, .NET, Oracle, Siebel, servicii web și multe alte limbaje și platforme importante pe care versiunile mai vechi nu le acceptau.

⚠️ Denumirea produsului: instrumentul descris aici ca fiind HP UFT este acum vândut ca OpenText Testare funcțională (UFT Unu), trecând de la HP la Micro Focus și apoi la OpenTextEcranele de mai jos provin din versiunea din epoca HP, așadar formularea meniurilor diferă de versiunile actuale, dar fluxul de testare API, activitățile și punctele de control funcționează la fel.

Tipul de suport pentru testarea API de către HP UFT

  1. serviciu web
  2. REST
  3. Limbajul orientat pe obiecte
  4. Baza de date
  5. API proprietar

Începeți prima testare API cu QTP

În această testare API în UFT tutorial, vom acoperi UFT Exemple de testare API. Vom testa API-ul Graph al Facebook. Vom testa API-ul ca Caz de testare de mai jos

  1. Obțineți un profil al utilizatorului specificat pe Facebook.
  2. Verificați dacă profilul este conform așteptărilor

Iată un pas pentru a crea un flux de testare pentru acest API.

Planificat UFT flux de testare pentru cazul de testare al API-ului Facebook Graph

⚠️ Despre acest exemplu: Facebook a retras Graph API v2.3 acum ani, iar token-ul de acces afișat mai jos a expirat de mult, așadar apelul exact nu mai returnează date. Cererea inițială este păstrată neschimbată, ca exemplu funcțional; indicați aceiași pași către orice punct final REST curent pentru a urmări.

Pasul 1) Deschideți HP UFT și creați un nou proiect Testare API

  1. Alege Start > (Toate) programele > Software HP > Testare funcțională unificată HP > Testare funcțională unificată. În versiunile actuale, acesta este pur și simplu UFT O comenzi rapide.

    Windows Calea din meniul Start către comanda rapidă HP Unified Functional Testing

  2. Clic Fișier > Nou > Test. Selectează Test API tip

    UFT Caseta de dialog Adăugați un test nou cu tipul de test API selectat

  3. Când se deschide o casetă de dialog, introduceți numele testului API: API_Facebookși selectați o locație pentru a salva acest proiect. Faceți clic pe Crează pentru a crea proiectul de testare API.

    Denumirea noului API de test API_Facebook și alegerea locației de salvare a acestuia

Pasul 2) Adăugarea unei cereri HTTP la fluxul de testare

Vom folosi cererea HTTP pentru a face o cerere către API-ul Facebook.

  1. Selectați Toolbox > Reţea

    Grupul de rețea s-a extins în UFT Panoul Casetă de instrumente

  2. Trageți elementul Cerere HTTP pentru a testa fluxul.

    Activitatea cererii HTTP a fost plasată pe UFT Canvasul fluxului de testare API

Pasul 3) Configurați și transmiteți parametrii într-o cerere HTTP

  1. Faceți clic dreapta pe Cerere HTTP obiect pentru a-l edita.

    Faceți clic dreapta pe meniu pe obiectul HTTP Request din fluxul de testare

  2. În secțiunea Proprietăți, introduceți URL

    Panoul Proprietăți al activității Cerere HTTP cu URL camp

    https://graph.facebook.com/v2.3/me?access_token=CAACEdEose0cBANJsDnbZC92mNAghaM6xxZCZBZAvKlMXS98VYvKy%20OlrfAdsUWR8x5aw9Kqc0grscs9zb9IYED4VC3FwapIZBj%20dsuxy%20HdLcff38gYUBFNeRQlH%20fN7eXKoVZBNl0bR233ZAZCw8fLF1QLh98ry2ZBeYBhXLabtTDkFPZA1IqhaMG0mQp30zO1%20QxQ19nVCxZArJA6XRoB1o5FMepII5cn3DgbBmTgZD
  3. De asemenea, puteți transmite un parametru către API setând valori în Antet cerere grilă.

    Grila antetului de solicitare utilizată pentru a transmite parametri suplimentari în apelul API

    Folosește Graph API Explorer al Facebook pentru a obține valoarea access_token.

  4. Seteaza Metoda HTTP la GET.

    Lista metodelor HTTP pentru activitatea de solicitare HTTP setată la GET

    GET selectată ca metodă HTTP pentru solicitare

  5. Configurați Punctele de control a Cerere HTTPSetați codul de stare la 200 în secțiunea Puncte de control. Punctele de control vă permit să vedeți dacă acțiunea a avut succes fără a fi nevoie să verificați manual rezultatul, iar verdictul de succes sau eșec al testului este determinat de acestea. Un cod de stare 200 înseamnă că cazul de testare a trecut.

    Panoul Puncte de control cu ​​codul de stare așteptat setat la 200

Pasul 4) Rulați testul

Apasă pe Alerga sau apăsați F5, pentru a deschide caseta de dialog Executare test. Faceți clic pe Alerga pentru a compila și a rula testul.

UFT Caseta de dialog Executare test deschisă prin butonul Executare

Pasul 5) Vizualizați rezultatul

Se deschide Vizualizatorul de rezultate ale execuției. În această testare API folosind UFT De exemplu, un caz de testare eșuat este raportat ca în figura următoare.

Vizualizatorul de rezultate al rulării afișează un caz de testare API eșuat

Când cazul de testare este aprobat, rezultatul este afișat după cum urmează.

Vizualizatorul de rezultate ale rulării afișează succesul cazului de testare API

Primul tău test API în UFT este acum completă.

De unde să plec de aici

Acum că ați învățat să creați un test cu un test API în UFT, puteți crea propriul test pentru aplicația dvs. fără interfață grafică. Adăugarea unui punctul de control per răspuns și grupping apeluri în tranzacții sunt următorii pași obișnuiți.

Întrebări frecvente

Un test GUI (Interfață grafică) controlează controalele pe ecran și le stochează ca obiecte de testare. Un test API este un flux de activități pe o pânză care trimite solicitări direct către un serviciu, astfel încât nimic nu este înregistrat de la interfață.

Nu. Un test API are activități, proprietăți de intrare și ieșire și surse de date în loc de obiecte de testare, deci nu depozit de obiecte este implicat. Doar testele GUI învață obiecte și stochează descrierile acestora.

Importați serviciul WSDL în fișierul test. UFT citește documentul, creează o activitate pentru fiecare operațiune expusă de serviciu și le adaugă în panoul Toolbox, astfel încât să poată fi glisate în fluxul de testare ca orice altă activitate.

Legați proprietățile de intrare ale activității la o sursă de date, cum ar fi o foaie Excel sau un fișier XML, în loc de typing valori literale. Fiecare rând produce apoi o iterație, iar Vizualizatorul de rezultate ale execuției raportează rezultatul per iterație.

Instrumentele asistate de inteligență artificială compară răspunsurile între rulări pentru a semnala deviațiile schemei și câmpurile care au eșuat recent și pot grupa eșecurile repetate în funcție de cauza principală probabilă. Acest lucru scurtează triajul, dar valorile așteptate în fiecare punct de control necesită în continuare o decizie umană.

Copilot este util pentru codul din jurul testului: logică de activitate personalizată, analiză a răspunsurilor și funcții helper. Nu poate construi fluxul vizual de testare sau citi codul de service.tract, deci fiecare cerere și punct de control sugerat de acesta necesită verificare.

SoapUI și Postman sunt mai ușoare și gratuite de la bun început. UFT își câștigă locul acolo unde același proiect trebuie să acopere și interfața cu utilizatorul, deoarece o licență și un set de rezultate acoperă ambele straturi.

Dincolo de codul de stare HTTP, un test API poate verifica conținutul corpului răspunsului, valorile individuale ale antetului și datele returnate în comparație cu o sursă așteptată. Fiecare rezultat al punctului de control apare alături de solicitare în Vizualizatorul de rezultate ale execuției.

Rezumați această postare cu: