API-testning ved hjælp af QTP/UFT: Komplet selvstudie

Af: Thomas Hamilton Thomas Hamilton
Hours Opdateret

⚡ Smart opsummering

API-testning i QTP/UFT Man validerer en tjeneste direkte, uden involveret brugergrænseflade. En API-test er bygget som et flow af aktiviteter på et lærred, og checkpoints afgør, om hvert svar består.

  • 🔘 Ingen GUI involveret: Input sendes direkte til tjenesten, og det registrerede svar sammenlignes med forventningerne.
  • ☑️ Fem understøttede typer: Webservice, REST, objektorienteret sprog, database og proprietære API'er.
  • ✅ Aktivitetsflow, ikke objekter: Træk en HTTP-anmodning fra værktøjskassen over i testflowet, og angiv dens egenskaber.
  • 🧪 Kontrolpunkter afgør dommen: Et statuskodecheckpoint på 200 markerer, at opkaldet er vellykket uden manuel inspektion.
  • 🛠️ Resultater samlet ét sted: Run Results Viewer rapporterer alle aktiviteter, dens reaktion og hvert kontrolpunktsresultat.
  • 📌 Nuværende navngivning: QTP plus HP Service Test blev UFT, nu solgt som OpenText Funktionel testning (UFT en).
Læs mere

Opbygning og udførelse af en API-test i QTP og UFT Én

Før vi tester et API, skal vi vide, hvad et API er. Et API (Application Programming Interface) er en samling af softwarefunktioner og -procedurer, der kan udføres af andre softwareapplikationer.

Hvad er API-test?

API-testning er en software test Metode til validering af applikationsprogrammeringsgrænseflader (API'er). Målet med API-testning er at teste API'en med hensyn til funktionalitet, pålidelighed, sikkerhed og ydeevne. I API-testning bruges software til at sende input til API'en, og outputtet registreres for at teste API'en.

Så API-testning er:

  • Test uden GUI
  • Programmatisk simulering af data eller kontrolflow-scenarier.
  • Fokus på funktionalitet, ikke på adfærd eller kundeoplevelse.

Diagrammet nedenfor placerer API-testning mellem den klient, der kalder tjenesten, og de data, den når.

Omfanget af API-testning mellem klientlaget og databaselaget

Hvorfor er API-testning vigtig?

API-testning har fire væsentlige fordele

1. API-testning er trenden

Som den følgende figur viser, er API-testning vokset meget hurtigt i løbet af de sidste ti år. Det er blevet langt mere populært end andre testtyper.

Diagram, der viser væksten i API-testimplementering over ti år

2. Tidseffektiv

Med API-testning kan vi bruge parallel udførelse til at reducere testudførelsestiden. Du kan spare op til 5 gange sammenlignet med andre testtyper.

3. Sproguafhængig

I API Testing udveksles data via XML or JSON, så ethvert sprog kan bruges til at teste svaret. Hvis du for eksempel har en tjeneste, hvis svar er i JSON-format, kan du nemt analysere dataene med Java, C# eller et hvilket som helst andet sprog.

4. Nem GUI-integration

Fordi UFT Man kan holde GUI-tests og API-tests i den samme løsning, mens et API-kald kan opsætte data til en brugergrænsefladetest og begge typer testrapporter i de samme kørselsresultater. Det holder en servicekontrol og den skærm, der bruger den, i ét projekt i stedet for to værktøjskæder.

API-testning med UFT (Samlet funktionel testning)

Der findes mange værktøjer, både open source og kommercielle. UFT er et stærkt valg til udførelse af API-tests, fordi flowet er visuelt opbygget, og konfigurationen holdes i én egenskabsrude.

Den sidste version af QTP, kaldet HP Unified Funktionstest (UFT), er en kombination af HP QTP (et GUI-testværktøj) og HP Service Test (et API-testværktøj). UFT understøtter internettet, Java, .NET, Oracle, Siebel, webtjenester og mange andre større sprog og platforme, som ældre versioner ikke understøttede.

⚠️ Produktnavngivning: værktøjet beskrevet her som HP UFT sælges nu som OpenText Funktionel testning (UFT En), efter at have skiftet fra HP til Micro Focus og derefter til OpenTextSkærmbillederne nedenfor stammer fra HP-æra-udgivelsen, så menuteksten adskiller sig fra nuværende builds, men API-testflowet, aktiviteter og kontrolpunkter fungerer på samme måde.

Type af API-testunderstøttelse efter HP UFT

  1. Webtjeneste
  2. REST
  3. Objektorienteret sprog
  4. Database
  5. Proprietær API
Gå ikke glip af:

Start din første API-test med QTP

I denne API-testning i UFT tutorial, vi vil dække UFT Eksempler på API-testning. Vi skal teste Facebooks Graph API. Vi vil teste API'en som Test sag jf. nedenstående

  1. Få en profil af den angivne bruger på Facebook.
  2. Kontroller, at profilen lever op til forventningerne

Her er et trin til at opbygge et testflow for denne API.

Planlagt UFT testflow for Facebook Graph API-testcasen

⚠️ Om dette eksempel: Facebook udfasede Graph API v2.3 for 3 år siden, og adgangstokenet vist nedenfor er for længst udløbet, så det præcise kald returnerer ikke længere data. Den oprindelige anmodning forbliver uændret som det fungerende eksempel; peg de samme trin på ethvert aktuelt REST-slutpunkt for at følge op.

Trin 1) Åbn HP UFT og opret nyt projekt API-testning

  1. Vælg Start > (Alle) programmer > HP Software > HP Unified Functional Testing > Unified Functional Testing. I nuværende udgivelser er dette simpelthen UFT Én genvej.

    Windows Startmenusti til genvejen til HP Unified Functional Testing

  2. Klik Fil > Ny > Test. Vælg API test typen

    UFT Dialogboksen Tilføj ny test med den valgte API-testtype

  3. Når en dialogboks åbnes, skal du indtaste navnet på API-testen: API_Facebook, og vælg en placering for at gemme dette projekt. Klik på Opret for at oprette API-testprojektet.

    Navngivning af den nye API-test API_Facebook og valg af dens gemningsplacering

Trin 2) Tilføjelse af HTTP-anmodning til testflow

Vi bruger HTTP-anmodningen til at sende en anmodning til Facebooks API.

  1. Type Værktøjskasse > Netværk

    Netværksgruppen blev udvidet i UFT Værktøjskasse-ruden

  2. Træk element HTTP-anmodning for at teste flow.

    HTTP-anmodningsaktivitet blev sendt til UFT API-testflowlærred

Trin 3) Konfigurer og overfør parametre til en HTTP-anmodning

  1. Højreklik på HTTP-anmodning objekt for at redigere det.

    Højreklikmenuen på HTTP-anmodningsobjektet i testflowet

  2. I Egenskaber-delen skal du indtaste URL

    Egenskabsruden for HTTP-anmodningsaktiviteten med URL felt

    https://graph.facebook.com/v2.3/me?access_token=CAACEdEose0cBANJsDnbZC92mNAghaM6xxZCZBZAvKlMXS98VYvKy%20OlrfAdsUWR8x5aw9Kqc0grscs9zb9IYED4VC3FwapIZBj%20dsuxy%20HdLcff38gYUBFNeRQlH%20fN7eXKoVZBNl0bR233ZAZCw8fLF1QLh98ry2ZBeYBhXLabtTDkFPZA1IqhaMG0mQp30zO1%20QxQ19nVCxZArJA6XRoB1o5FMepII5cn3DgbBmTgZD
  3. Du kan også sende en parameter til API'en ved at indstille værdier i Anmodningshoved grid.

    Anmodningsheadergitter, der bruges til at sende ekstra parametre til API-kaldet

    Brug Graph API Explorer af Facebook for at hente værdien af ​​access_token.

  4. Indstil HTTP-metode til GET.

    HTTP-metodeliste over HTTP-anmodningsaktiviteten indstillet til GET

    GET valgt som HTTP-metode for anmodningen

  5. Konfigurer checkpoints af HTTP-anmodningIndstil statuskoden til 200 i Checkpoints-delen. Checkpoints giver dig mulighed for at se, om handlingen var vellykket, uden at skulle kontrollere resultatet manuelt, og testens beståelses- eller fiaskovurdering bestemmes ud fra dem. En statuskode på 200 betyder, at testcasen er bestået.

    Kontrolpunktsruden med den forventede statuskode indstillet til 200

Trin 4) Kør testen

Klik på knappen Kør knappen, eller tryk på F5, for at åbne dialogboksen Kør test. Klik på Kør at kompilere og køre testen.

UFT Dialogboksen Kør test åbnet fra knappen Kør

Trin 5) Se resultatet

Kørselsresultatvisningen åbnes. I denne API-testning ved hjælp af UFT For eksempel rapporteres en mislykket testtilfælde som i følgende figur.

Kør resultatvisning, der viser en mislykket API-testsag

Når testcasen består, rapporteres resultatet som nedenfor.

Kør resultatvisning, der viser, at API-testcasen er bestået

Din første API-test i UFT er nu færdig.

Hvor skal vi hen herfra

Nu hvor du har lært at oprette en test med en API-test i UFT, kan du oprette din egen test til din GUI-løse applikation. Tilføjelse af en kontrolpost pr. svar og gruppeping ringer ind transaktioner er de sædvanlige næste skridt.

Ofte Stillede Spørgsmål

En GUI testkører kontroller på skærmen og gemmer dem som testobjekter. En API-test er en strøm af aktiviteter på et lærred, der sender anmodninger direkte til en tjeneste, så intet registreres fra grænsefladen.

Nej. En API-test har aktiviteter, input- og outputegenskaber og datakilder i stedet for testobjekter, så nej objektlager er involveret. Kun GUI-tests lærer objekter at kende og gemmer deres beskrivelser.

Importer tjenesten WSDL til testen. UFT læser dokumentet, opretter en aktivitet for hver handling, som tjenesten eksponerer, og tilføjer dem til værktøjskasseruden, så de kan trækkes over i testflowet ligesom enhver anden aktivitet.

Link aktivitetsinddataegenskaberne til en datakilde, f.eks. et Excel-ark eller en XML-fil, i stedet for typing literale værdier. Hver række producerer derefter én iteration, og Run Results Viewer rapporterer resultatet pr. iteration.

AI-assisterede værktøjer sammenligner svar på tværs af kørsler for at markere skemadrift og nyligt fejlende felter, og de kan gruppere gentagne fejl efter sandsynlig rodårsag. Det forkorter triage, men de forventede værdier i hvert kontrolpunkt kræver stadig en menneskelig beslutning.

Copilot er nyttig til koden omkring testen: brugerdefineret aktivitetslogik, responsparsing og hjælpefunktioner. Den kan ikke opbygge det visuelle testflow eller læse dine servicekonti.tract, så hver anmodning og hvert kontrolpunkt, den foreslår, skal verificeres.

SoapUI og Postman er lettere og frie til at starte med. UFT fortjener sin plads, hvor det samme projekt også skal dække brugergrænsefladen, da én licens og ét resultatsæt spænder over begge lag.

Ud over HTTP-statuskoden kan en API-test kontrollere svarets brødtekstindhold, individuelle headerværdier og returnerede data sammenlignet med en forventet kilde. Hvert kontrolpunktsresultat vises sammen med anmodningen i Run Results Viewer.

Opsummer dette indlæg med: