Kuinka API-päätepisteitä testataan

Ohjelmointirajapinta (API) mahdollistaa kahden järjestelmän välisen viestinnän. Pohjimmiltaan API tarjoaa sopimuksen ja kielen, jotka ohjaavat kahden järjestelmän välistä viestintää. 

API-testauksessa arvioidaan näitä rajapintoja sen varmistamiseksi, että ne täyttävät toiminnallisuutta, luotettavuutta, suorituskykyä ja tietoturvaa koskevat standardit. Tämä tehdään yleensä lähettämällä API:lle erilaisia pyyntöjä ja arvioimalla vastauksia. API-testaus on lähes kaikkien kehittäjien tärkeimpiä prioriteetteja: Rapidin vuoden 2022 maailmanlaajuisen API-kyselyn mukaan yli 90 % kehittäjistä ilmoitti testaavansa tai suunnittelevansa testaavansa API-rajapintojaan. 

API-päätepisteet ovat erityisiä polkuja tai URL-osoitteita, joita API tarjoaa ja jotka mahdollistavat ohjelmistosovelluksen eri toimintojen käytön. Kukin päätepiste vastaa tiettyä toimintoa, kuten tietojen hakemista, tietueen päivittämistä tai laskutoimituksen suorittamista, ja se on suunniteltu käsittelemään tietyntyyppisiä pyyntöjä ja vastauksia API:n kokonaisrakenteessa.

API-päätepisteiden jatkuva testaaminen koko kehitysprosessin ajan auttaa havaitsemaan ongelmat varhaisessa vaiheessa, mikä säästää aikaa ja resursseja pitkällä aikavälillä.

Joten, miten API-testausta voidaan tehdä tehokkaasti API:n kehityksen elinkaaren aikana? Sukelletaan aiheeseen!

Mitä API-päätepisteet ovat?

API on joukko sääntöjä ja protokollia ohjelmistosovellusten rakentamiseen ja niiden kanssa toimimiseen, ja se mahdollistaa eri ohjelmistojärjestelmien välisen viestinnän. Kunkin API:n dokumentaatiossa ja määrityksissä määritellään, miten tietoja voidaan vaihtaa.

API:t voivat käyttää HTTP-pyyntöjä tietojen hakemiseen verkkosovelluksesta tai palvelimelta samalla tavalla kuin verkkosivu hahmonnetaan.  

palvelut ja URL-osoitteet, aivan kuten ne, joilla vierailet verkkosivustolla. API:ssa päätepiste on tietty sijainti, joka vastaanottaa pyyntöjä ja vastaa niihin. Tietojen ja komentojen välittäminen päätepisteen kautta mahdollistaa eri sovellusten ja järjestelmien välisen viestinnän.

Sen ansiosta kehittäjät voivat nopeasti käyttää ja hyödyntää muiden järjestelmien tietoja ja ominaisuuksia, eikä heidän tarvitse rakentaa kaikkea alusta alkaen uusiin sovelluksiin.

Esimerkki API-päätepisteestä

Katsotaan, miltä API-päätepiste näyttää. Käytän esimerkkinä Cat API:a ja sen Postman-dokumentaatiota:

Tässä tapauksessa päätepisteitä ovat esimerkiksi ”images”, ”favorites” ja ”breeds”. Kukin niistä mahdollistaa erilaisia toimintoja, jotka suoritetaan eri HTTP-pyyntömenetelmillä. Yleisimmin käytettyjä menetelmiä ovat esimerkiksi CRUD-toimintoja suorittavat menetelmät: POST luomista, GET lukemista, PUT päivittämistä ja DELETE poistamista varten.

API-dokumentaation tulisi sisältää tiedot käytettävissä olevista päätepisteistä, päätepisteessä sallitusta pyyntömenetelmästä sekä pyynnön ja vastauksen malleista. Näiden tietojen avulla voimme aloittaa päätepisteiden testaamisen. Palaamme tähän yhdessä seuraavista osioista.

Miksi API-päätepisteitä testataan?

Jokainen API on rakennettu suorittamaan tiettyjä toimintoja, ja sovelluksen toiminta riippuu API-tapahtumista vastauksen saamiseksi. Perustason tapahtuma voi tehdä useita sisäisiä API-kutsuja. Jos yksi näistä API-kutsuista epäonnistuu, koko järjestelmä voi kaatua ja lakata toimimasta. Lisäksi samaa API:a voivat käyttää useat sovellukset, joten API:n toimintahäiriö voi vahingoittaa suurta määrää sovelluksia. API-päätepisteiden testaaminen auttaa ehkäisemään ongelmia ennen kuin asiakas havaitsee ne.

Miten API-päätepisteitä testataan?

API-testausta voidaan tehdä sekä manuaalisesti että automaattisesti. Molempia testaustyyppejä voidaan toteuttaa API-testaustyökaluilla.

Toisin kuin käyttöliittymätestit, API-testit eivät ole riippuvaisia selaimesta. Asiakkaana toimivaa API-testaustyökalua voidaan kuitenkin käyttää.

Dokumentaation perusteella voimme selvittää päätepisteen, johon HTTP-pyyntö lähetetään, HTTP-menetelmän, kyselyparametrit, pyynnön rungon (jos sitä tarvitaan), mahdolliset HTTP-vastauksen tilakoodit sekä HTTP-vastauksen rungon. Näiden tietojen avulla voimme tunnistaa suoritettavat API-testitapaukset.

Vaatimuksista riippuen voimme päättää, mitkä testit on suoritettava – toiminnallisesta testauksesta ei-toiminnalliseen testaukseen, kuten suorituskyky-, kuormitus- ja tietoturvatestaukseen.

Kaikkein yksinkertaisin API-testi koostuu pyynnön lähettämisestä ja vastauksen kelvollisuuden tarkistamisesta. Pyynnön tyypistä ja itse päätepisteestä riippuen saatamme tarvita lisätietoja pyynnön lähettämistä varten. Tässä on luettelo tiedoista, joita tarvitsemme pyynnön lähettämiseen:

• Päätepiste/URL-osoite: tämä on osoite, johon pyyntö lähetetään
• Pyynnön runko: POST- ja PUT-menetelmien kaltaisissa pyyntömenetelmissä tarvitaan runko, joka sisältää palvelimelle lähetettävät tiedot
• Kyselyparametrit: ylimääräisiä hakuparametreja voidaan käyttää vastauksessa palautettavien tulosten rajaamiseen 
• Otsakkeet: nämä ovat pyynnön mukana lähetettäviä metatietoja. Aiemmassa kissaesimerkissä API-avainta voidaan käyttää otsakkeena, mikä mahdollistaa useampien tietojen hakemisen kuin ilman avainta:

Kun pyyntö on lähetetty onnistuneesti, testissä pitäisi tarkistaa vastaus. Vastauksessa tarkistettavat asiat ovat:

• HTTP-tilakoodi: jokaisella vastauksella on tilakoodi. Ne voidaan ryhmitellä viiteen pääluokkaan: numerolla 1 alkavat koodit (100–199) edustavat informatiivista vastausta, numerolla 2 alkavat koodit (200–299) edustavat onnistunutta viestiä, koodit välillä 300–399 ovat uudelleenohjauksia, numerolla 4 alkavat koodit (400–499) ovat asiakasvirheitä ja 500-ryhmän koodit ovat palvelinvirheitä. 
• HTTP-vastauksen runko: palvelimelta takaisin tulevat tiedot. Dokumentaatiossa pitäisi ilmoittaa, millaisia tietoja vastauksen tulee sisältää, esimerkiksi:

• Vastauksen otsakkeet: palvelinten palauttamat metatiedot
• Vastausaika: jos olemme kiinnostuneita myös API:n suorituskyvystä.

Nopeana esimerkkinä käytän Postmania näyttääkseni, miltä GET-pyyntö näyttää Cat API:a käytettäessä. Lähetän GET-pyynnön images-päätepisteeseen. Tätä varten riittävät päätepisteen osoite, GET-menetelmä ja pyynnön lähettäminen:

Kun pyyntö on lähetetty, näemme HTTP-vastauskoodin, rungon ja ajan, joka vastauksen vastaanottamiseen kului:

Vastauksen rungon sisältö on se, mitä API palauttaa annettujen syötteiden perusteella, kun taas vastauksen tilakoodi ilmaisee pyynnön tämänhetkisen tilan.

API-vastauksen tietotyypeissä ja koossa on eroja. Vastauksissa voidaan käyttää pelkkää tekstiä, XML-asiakirjaa, JSON-tietorakennetta ja muita muotoja. Niissä voidaan käyttää sadan sivun JSON/XML-tiedostoa tai muutaman sanan pituista yksinkertaista merkkijonoa, jopa tyhjää merkkijonoa. Siksi sopivan varmennustekniikan valitseminen tietylle API:lle on ratkaisevan tärkeää.

API:n testitapausten luominen

Toiminnalliset testitapaukset voidaan muodostaa mustan laatikon testaustekniikoiden avulla. Dokumentaatiossa määritellään, millaisia tietotyyppejä kukin parametri hyväksyy, joten näiden tietojen perusteella voidaan luoda osioita ja raja-arvoja.

Sen jälkeen voimme luoda monimutkaisempia skenaarioita yhdistämällä useita pyyntöjä yhdeksi testiksi. Esimerkiksi resurssin luova, sitä päivittävä, lukeva ja lopuksi poistava testi on lähetettävä neljä erilaista pyyntöä.

Sekä positiiviset että negatiiviset testit ovat välttämättömiä API-testauksessa, jotta voidaan varmistaa API:n toimivan vaatimusten mukaisesti. Koska API-testaus on mustan laatikon testauksen osa-alue, syöte- ja tulostiedot ohjaavat molempia testaustyyppejä. Seuraavassa on muutamia ideoita testiskenaarioiden luomiseen:

Positiiviset skenaariot:

• Tarkista, että API hyväksyy syötteen ja tuottaa vaatimusten mukaisen halutun tuloksen.
• Tarkista, palautetaanko vastauksen tilakoodi — olipa kyseessä virhekoodi tai 2xx-koodi — vaatimuksissa ilmoitetulla tavalla.
• Ilmoita syötettävien kenttien vähimmäis- ja enimmäismäärä.

Negatiiviset skenaariot:

• Varmista, että API antaa asianmukaisen vastauksen tapauksissa, joissa odotettu tulos puuttuu.
• Suorita syötteen validointitesti.
• Tutki API:n toiminta eri valtuutustasoilla.

API:n ei-toiminnalliset testit 

Toiminnallisen testauksen lisäksi voimme suorittaa API:lle erilaisia ei-toiminnallisia testejä. Tässä on joitakin tärkeimmistä:

Suorituskykytestaus

Suorituskykytestauksella tarkoitetaan ohjelmiston suorituskyvyn mittaamista erilaisilla työkuormilla, skenaarioilla ja olosuhteissa. Sen avulla voit löytää resurssien pullonkauloja sekä varmistaa vakauden ja skaalautuvuuden. Suorituskykytestauksen alatyyppejä ovat kuormitustestaus, rasitustestaus, kestävyystestaus ja piikkitestaus. Suosituin suorituskykytestauksen muoto, kuormitustestaus, jäljittelee ohjelmistosi keskimääräistä tai suurta käyttäjäliikennettä. Sen avulla voit arvioida ohjelmistosi läpimenoa, vasteaikaa ja resurssien käyttöä. Apache JMeter on avoimen lähdekoodin Java-työkalu, joka voi luoda ja lähettää erilaisia pyyntöjä API:lle sekä mitata tuloksia, ja se on yksi parhaista työkaluista API:n kuormitustestaukseen.

Tietoturvatestaus

Prosessia, jossa varmistetaan ohjelmiston suojaus haitallisilta hyökkäyksiltä, luvattomalta käytöltä ja tietomurroilta, kutsutaan tietoturvatestaukseksi. Sen avulla voit varmistaa ohjelmasi tietojen yksityisyyden, paikkansapitävyyden ja saatavuuden. Tietoturvatestausta voidaan suorittaa eri tasoilla, kuten tietokanta-, sovellus- ja verkkotasolla. Koodikatselmoinnit, tunkeutumistestit, haavoittuvuuksien tarkistukset ja eettinen hakkerointi ovat muutamia yleisiä tietoturvatestauksen menetelmiä. Postman on suosittu alustojen välinen apuohjelma, joka voi lähettää pyyntöjä API:lle ja vastaanottaa niitä sekä testata tietoturvaominaisuuksia, kuten todentamista, valtuutusta, salausta ja virheenkäsittelyä. Se on yksi parhaista työkaluista API:n tietoturvatestaukseen.

Luotettavuustestaus

Luotettavuustestaus on prosessi, jossa määritetään, kuinka luotettava ja johdonmukaisesti toimiva ohjelmistosi on ajan mittaan ja erilaisissa tilanteissa. Sen avulla voit varmistaa ohjelmistosi palautumiskyvyn, vikasietoisuuden ja saatavuuden. Voit suorittaa luotettavuustestausta lisäämällä ohjelmistoosi tarkoituksellisesti virheitä, erehdyksiä tai toimintahäiriöitä ja tarkkailemalla, miten se reagoi niihin ja palautuu niistä. Keskimääräinen vikojen välinen aika (MTBF), keskimääräinen vikaantumisaika (MTTF), keskimääräinen korjausaika (MTTR) ja vikaantumisaste ovat muutamia luotettavuustestauksessa usein käytettyjä mittareita. Chaos Monkey on työkalu, joka lopettaa pilviympäristössäsi olevia instansseja satunnaisesti ja testaa, miten ohjelmistosi käsittelee häiriötä. Se on yksi parhaista työkaluista API:n luotettavuustestaukseen.

Loppupäätelmät

API:n testaus on yhä tärkeämpi taito laadunvarmistuksen ammattilaisille. API-päätepisteet on testattava perusteellisesti, jotta voidaan varmistaa niiden toimivan tarkoitetulla tavalla ja täyttävän vaaditut standardit. API-päätepisteiden testaus auttaa tunnistamaan ja ratkaisemaan mahdolliset ongelmat tai virheet sekä vahvistaa sovelluksen yleisen toimivuuden.

API-päätepisteiden tehokkaassa testaamisessa on tärkeää noudattaa parhaita käytäntöjä, kuten suunnitella kattavia testitapauksia, ottaa huomioon erilaiset syötteet ja tulosteet sekä hyödyntää automaatiotyökaluja tehokkaaseen ja luotettavaan testaukseen. Lisäksi todellisia käyttötilanteita tarkasti jäljittelevien testiympäristöjen hyödyntäminen voi parantaa API-päätepisteiden testauksen tarkkuutta entisestään.

Kattava ja tehokas API-päätepisteiden testaus on olennaista nykyaikaisten sovellusten luotettavuuden, suorituskyvyn ja toiminnallisuuden varmistamiseksi. Ymmärtämällä, mitä API-päätepisteet ovat ja miten niitä testataan, kehittäjät voivat varmistaa sovellustensa onnistuneen integroinnin muihin järjestelmiin ja tarjota samalla erinomaisen käyttökokemuksen.

Tilaa QA-johtajan uutiskirje, niin saat päivityksiä uudesta testaussisällöstä.