REST API -testausopas: Esimerkkejä manuaalisista testitapauksista
Toimituksellinen tiimi
⚡ Älykäs yhteenveto
REST API -testaus validoi RESTful-verkkopalveluita lähettämällä HTTP-pyyntöjä, kuten GET, POST, PUT ja DELETE, ja tarkistamalla sitten palvelimen palauttaman tilakoodin, vastausotsikot ja hyötykuorman.
Mitä REST API -testaus on?
REST API -testaus on avoimen lähdekoodin verkkosovellusten automaatiotestaustekniikka, jota käytetään RESTful-rajapintojen testaamiseen verkkosovelluksissa. REST API -testauksen tarkoituksena on tallentaa REST API:n vastaus lähettämällä erilaisia HTTP/S-pyyntöjä tarkistaakseen, toimiiko REST API oikein. REST API -testaus tehdään GET-, POST-, PUT- ja DELETE-metodeilla.
REST on lyhenne sanoista Representational State Transfer. Se on arkkitehtoninen tyyli ja lähestymistapa kommunikaatioon, jota käytetään kehityksessä Web ServicesRESTistä on tullut looginen valinta API-rajapintojen rakentamiseen, koska se mahdollistaa käyttäjien tehokkaan yhteyden muodostamisen ja vuorovaikutuksen pilvipalveluiden kanssa.
API eli sovellusohjelmointirajapinta on joukko ohjelmointiohjeita verkkopohjaisen ohjelmistosovelluksen käyttämiseen. Toisin sanoen se on joukko komentoja, joita yksi ohjelma käyttää kommunikoidakseen suoraan toisen kanssa ja käyttääkseen toistensa toimintoja tiedon hankkimiseen.
Esimerkiksi Google Verkkosivustolla voi olla API haulle, käännöksille ja kalentereille. Yleisesti ottaen APIt näyttävät alla olevan esimerkin kaltaisilta, ja niissä on palvelimen nimi, polut ja parametrit.
http://<server name>/v1/export/Publisher/Standard_Publisher_Report?format=csv
Mutta miksi ylipäätään investoida testaustyötä tähän kerrokseen?
Miksi REST API -testaus on tärkeää
REST-rajapinta sijaitsee käyttöliittymän ja tietokannan välissä, mikä tekee siitä kerroksen, jolla suurin osa liiketoimintalogiikasta todellisuudessa sijaitsee. Hinnoittelusäännön tai käyttöoikeustarkistuksen virhe ilmenee rajapinnan vastauksessa kauan ennen kuin kukaan huomaa väärää numeroa näytöllä, joten testaus tässä rajapinnassa havaitsee ongelmat aikaisemmin ja lähempänä niiden syytä.
Nopeus on toinen syy. Pyyntö suoritetaan millisekunneissa eikä vaadi selainta, renderöintimoottoria tai hauraiden elementtien paikannusta. Testaaja voi käyttää kymmeniä päätepisteitä yhden käyttöliittymätestin sivun lataamiseen kuluvan ajan aikana, ja sama pyyntö käyttäytyy samalla tavalla riippumatta siitä, onko käyttöliittymä verkkosivusto, mobiilisovellus vai kumppaniintegraatio.
Vakaus on kolmas syy. Asettelut muuttuvat jatkuvasti, mutta julkaistu REST-konversiotracodotetaan pysyvän vakaana. Tätä vastaan kirjoitetut testittracne eivät selviä uudelleensuunnittelusta, joten ne suojaavat tuotteen osia, joiden päälle muut tiimit todellisuudessa rakentavat.
API-menetelmien tyypit
Niitä on pääasiassa 4 tyyppiä API-testaus metodit: GET, POST, DELETE ja PUT.
- SAA– GET-metodia käytetään esimerkkien esittämiseentractietoja annetulta palvelimelta tiettyä URI:a käyttäen. GET-pyyntöä käytettäessä sen tulisi näyttää vaintract-dataa eikä sillä pitäisi olla muuta vaikutusta dataan.
- POST– POST-pyyntöä käytetään uuden entiteetin luomiseen. Sen avulla voidaan myös lähettää palvelimelle dataa, esimerkiksi asiakastietoja, tiedostojen lataamista jne. HTML-lomakkeilla.
- PUT– Luo uusi kokonaisuus tai päivitä olemassa oleva.
- POISTA– Poistaa kaikki nykyiset URI:n antamat kohderesurssin esitykset.
Kuinka testata REST-sovellusliittymää
REST API -testaus edellyttää, että sovellus on vuorovaikutuksessa esimerkki-API:n kanssa testausta varten. API:n testaamiseen tarvitset kaksi asiaa:
- Testaustyökalu/kehys API:n ohjaamiseksi
- Oman koodin kirjoittaminen REST-sovellusliittymän testaamiseksi
REST API -testitapauksia voidaan testata työkaluilla, kuten:
- Advanced Rest Client
- Postman-Lepo asiakas
- Curl Linuxissa
Tässä käytämme Advanced Rest Clientiä. Alla on vaiheet Advanced Rest Clientin hankkimiseksi.
Miten saada Advanced Rest -asiakas?
- Mene Google Chromen verkkokauppa
- Hae "Advanced Rest Client" tai mene suoraan täältä ja asenna laajennus
- Valitse "Advanced Rest Client" -kuvake Chromen sovellusosiossa - chrome://apps/
Verkkokaupan listaus näyttää alla olevalta.
Kun asennus on valmis, testaa alla olevien ohjeiden mukaisesti RESTful API.
REST-sovellusliittymän testauksen vaiheet
Tässä käytämme REST-asiakaslaajennusta Chrome-selaimessa. Ymmärtääksemme sen selkeästi, käytämme testaukseen mallirajapintaa:
http://ip.jsontest.com/
Vaihe 1) Avaa Advanced REST -asiakas
Käynnistä Advanced REST -asiakassovellus (ARC), kun se on asennettu onnistuneesti.
Vaihe 2) Syötä URL testattavasta API:sta
Syötä REST-ohjelmointirajapintaesimerkki URL testausta varten URL tekstilaatikko.
Vaihe 3) Valitse HTTP-menetelmä
Valitse menetelmä HTTP-menetelmien tyypeille API-testauksessa osumaan esim. POST
Vaihe 4) Anna otsikot
Anna Otsikkojoukko Otsikot-tekstikenttään. Napsauta Lisää otsikkosarja.
Vaihe 5) Vahvista otsikot
Seuraava Napsauta KÄYTÄ TÄTÄ SETTIÄ.
Vaihe 6) Anna tarvittava kehon sisältö
- Vaihda nyt Body-välilehteen.
- Aseta vaadittu runkosisältötyyppi ja muokkausnäkymä, esim. Body content type : application/json
- Editor-näkymä: Raaka syöttö.
- Välitä kohdassa Hyötykuorma testausta varten demo-API:n pyynnön runko avain-arvo-parien muodossa, esimerkiksi {“avain1″:”arvo1″,”avain2″:”arvo2”}. Jos kyseessä on POST-API, meidän on välitettävä runko tai parametrit. Välitämme sen annetun hyötykuorman alla.
{"property" : ["Sites"], "report_type" : ["ALL"]}
⚠️ Varoitus: Application/json-tiedoston Content-Type-tyyppi, jonka hyötykuorma ei ole kelvollinen JSON palauttaa 400 virheellistä pyyntöä.
Vaihe 7) Lähetä tiedot aloittaaksesi testin
- Paina lähetyspainiketta.
- Voit napsauttaa TIEDOT-painiketta nähdäksesi vastausotsikot.
Tässä vastaustiedot:
Vastausta on silti arvioitava odotettua tulosta vasten.
Tulosten vahvistaminen
Pääasiassa Web API -testausta varten meidän on tarkistettava vastauskoodi, vastausviesti ja vastauksen runko.
Vastauskoodit jakautuvat viiteen ryhmään:
| Perhe | Luokka | Merkitys |
|---|---|---|
| 1xx | Tiedotteet | Vastaanotettu, edelleen käsittelyssä |
| 2xx | Menestys | Valmis; 200 OK, 201 Luotu |
| 3xx | Uudelleenohjaus | Lisätoimenpide tarvitaan |
| 4xx | Asiakasvirhe | Virheellinen hyötykuorma, tunnus tai resurssi |
| 5xx | Palvelinvirhe | Kelvollinen pyyntö, palvelin epäonnistui |
Alla on vastauskoodit, joihin saatat törmätä.
Yksi pyyntö todistaa päätepisteen toimivuuden. Ohjelmistopaketti todistaa, että se jatkaa toimintaansa.
REST API -testitapaukset, jotka sinun on käsiteltävä
Hyödyllinen REST API -paketti jakautuu useisiin kategorioihin sen sijaan, että toistaisi samaa happy-path-kutsua eri tiedoilla:
- Onnellinen polku: Lähetä kelvollinen pyyntö jokaiseen päätepisteeseen ja vahvista tilakoodi, kaava ja jokaisen kentän arvo.
- Negatiiviset tapaukset: Lähetä virheellisesti muotoiltu JSON, ei-tuettu metodi ja puuttuva resurssitunnus, ja odota sitten 400, 405 ja 404 500:n sijaan.
- Raja-arvot: Jos kenttä hyväksyy 1–200 merkkiä, testaa merkit 0, 1, 200 ja 201. Kelpoisuussäännöt rikkoutuvat reunoilla.
- Erikoismerkit: Paljasta koodausvirheet lisäämällä aksenttisia kirjaimia, emojeja, lainausmerkkejä ja monitavuista tekstiä jokaisen kentän läpi.
- kanssatract-tarkistukset: Vertaa vastausta julkaistuun OpenAPI- tai Swagger-spesifikaatioon, jotta dokumentoimattomat muutokset havaitaan varhaisessa vaiheessa.
- Jaksotus: Kutsu päätepisteitä realistisessa järjestyksessä, kuten POST, GET ja DELETE, koska tilatiedot pysyvät tiedossa kutsujen välillä.
- Suorituskyvyn järki: Kirjaa vasteajat jokaisella ajolla ja merkitse kaikki päätepisteet, jotka ylittävät tiimin kanssa sovitun kynnysarvon.
REST API Test Tool
Eri työkalut sopivat testauksen eri vaiheisiin.
| Työkalu | Tyyppi | Parasta |
|---|---|---|
| Advanced Rest Client | Työpöytäasiakas | Nopeat manuaaliset puhelut |
| Postman | Työpöytäasiakas | Kokoelmat ja tiimityötilat |
| JMeter | Kuormitustestaus | Vasteajat kuormituksen alaisena |
| SoapUI | Toiminnallinen testaus | REST ja SOAP yhdessä |
| Lepää varmana | Java kirjasto | Vakaiden tapausten automatisointi |
| cURL | Komentorivin | Kutsujen liittäminen vikailmoituksiin |
Katso yhteenveto API-testaustyökalut.
Useimmat todelliset päätepisteet kieltäytyvät vastaamasta, ennen kuin pyyntö todistaa kuka sen lähetti.
REST API -todennus ja tietoturvatarkistukset
Julkiset demopäätepisteet vastaavat keneen tahansa, mutta tuotantoympäristön REST-rajapinta sijaitsee todennusjärjestelmän takana, ja todennusvirhe on paljon vahingollisempi kuin väärä kentän arvo. Tunnista ensin mekanismi: staattinen API-avain, HTTP Basic -tunnistetiedot, OAuth 2.0 -haltijatunnus tai allekirjoitettu JSON Web Token.
Kun todennettu pyyntö onnistuu, käy epäonnistumispolut tarkoituksella läpi:
- Ei tunnistetietoja: Poista Valtuutus-otsikko. Odota virhettä 401 Luvaton ja ei tietuetietoja rungossa.
- Väärin muotoillut tunnistetiedot: korruptoi yhden merkin tunnuksessa. Odota uudelleen 401-virhettä, jossa ei selitetä syytä.
- Vanhentuneet tunnistetiedot: käyttää tokenia uudelleen sen vanhenemisen jälkeen. Varmista, että se hylätään eikä sitä hyväksytä, mikä on yleinen kellovirhe.
- Väärä käyttöoikeustaso: todenna itsesi käyttäjänä, jolla on alhaiset käyttöoikeudet, ja kutsu vain järjestelmänvalvojan käyttöön tarkoitettua päätepistettä. Odota virhettä 403 Forbidden, älä 200.
- Toisen käyttäjän ennätys: muuta tunnusta niin, että käyttäjä A pyytää käyttäjän B tietoja. Onnistuminen tässä on vakava käyttöoikeuksien hallintavirhe.
Lopuksi varmista, että jokainen puhelu kulkee HTTPS:n kautta, että epäonnistuneet vastaukset eivät vuoda pinoa traces- tai versiobannereita ja että nopeat toistot laukaisevat 429 Too Many Requests -koodin.
REST API -testaus tuo mukanaan myös vaikeuksia, joita rajapintatestaus ei tuo mukanaan.
API-testauksen haasteita
REST API -testauksen mielenkiintoisia ongelmia testaajille ovat:
- Varmistaakseen, että testijohdinsarja vaihtelee API-kutsujen parametreja siten, että se sekä varmistaa toiminnallisuuden että paljastaa virheet. Tämä sisältää reunaehtojen tutkimisen ja yhteisten parametrien määrittämisen.
- Mielenkiintoisten parametriarvoyhdistelmien luominen puheluille, joissa on kaksi tai useampia parametreja
- API-kutsujen sisällön tunnistaminen. Tämä voi sisältää ulkoisten ympäristöehtojen (oheislaitteet, tiedostot jne.) sekä API:in vaikuttavien sisäisesti tallennettujen tietojen asettamisen.
- Sekvensoi API-kutsut sen järjestyksen mukaan, jossa toiminto suoritetaan
- Jotta API tuottaisi hyödyllisiä tuloksia peräkkäisistä kutsuista.
