API-testauksen työhaastattelukysymykset

SlashDatan vuonna 2020 tekemän kyselyn mukaan lähes 90 % haastatelluista kehittäjistä käytti jossain määrin ohjelmointirajapintoja. Tätä taustaa vasten ei ole ihme, että vaikka olisit manuaalinen tai automaatiotestaaja ja etsisit työpaikan vaihtoa, työhaastattelu sisältää ohjelmointirajapintoihin liittyviä kysymyksiä. 

Tässä artikkelissa käyn läpi yleisimpiä ja tärkeimpiä ohjelmointirajapintojen testaukseen liittyviä haastattelukysymyksiä ja annan jokaiseen ihanteellisen vastauksen. Aloitetaan!

1. Mitä ohjelmointirajapintojen testaus on?

Ohjelmointirajapintojen testaus on ohjelmistotestauksen tyyppi, jossa ohjelmointirajapintoja (sovellusohjelmointirajapinta) arvioidaan sen selvittämiseksi, täyttävätkö ne toiminnallisuutta, luotettavuutta, suorituskykyä ja tietoturvaa koskevat vaatimukset. Koska ohjelmointirajapinnoilla ei ole graafista käyttöliittymää, ohjelmointirajapintojen testaus suoritetaan järjestelmän viestitasolla. 

2. Mitä hyötyjä ohjelmointirajapintojen testauksesta on?

Ohjelmointirajapintojen testauksella on useita hyötyjä. Tärkeimpiä ovat esimerkiksi:

• Testaus ilman graafista käyttöliittymää: Testaajat voivat suorittaa ohjelmointirajapintojen testejä ilman, että heidän tarvitsee käyttää ohjelmistoa suoraan. Tämä on merkittävä etu, koska sen ansiosta laadunvarmistusinsinöörit saavat varhaisen käsityksen puutteista ja virheistä, jolloin kehittäjät voivat korjata ne ennen kuin ne vaikuttavat graafiseen käyttöliittymään.
• Ydintoiminnallisuuksien testaus: Sovelluksen kooditason toiminnallisuuden testaaminen ennen graafisen käyttöliittymän testejä mahdollistaa sen kokonaislaadun arvioinnin. Tämä auttaa paljastamaan pienet virheet, jotka voivat kasvaa merkittäviksi ongelmiksi käyttöliittymätasolla. Pääsy ytimeen mahdollistaa testauksen samanaikaisesti kehityksen kanssa, mikä edistää viestintää ja parempaa yhteistyötä.
• Ajankäytön tehokkuus: Ohjelmointirajapintojen testit vievät yleensä vähemmän aikaa kuin toiminnalliset graafisen käyttöliittymän testit. Käyttöliittymätestaus kestää kauemmin, koska verkkokomponentteja on kyseltävä. Ohjelmointirajapintojen testiautomaatio edellyttää erityisesti vähemmän koodia ja tarjoaa paremman ja nopeamman testikattavuuden kuin graafisen käyttöliittymän automatisoitu testaus.
• Kieliriippumattomuus: Ohjelmointirajapintatesti käyttää XML:ää tai JSONia tietojen vaihtamiseen. Nämä siirtotavat eivät ole ohjelmointikielestä riippuvaisia, joten ohjelmointirajapinnan automatisoituja testejä kirjoitettaessa voi käyttää mitä tahansa ohjelmointikieltä. 

3. Miten ohjelmointirajapintojen testaus eroaa käyttöliittymätestauksesta?

Ohjelmointirajapintojen testauksessa keskitytään paljon enemmän liiketoimintalogiikan, tietovastausten ja tietoturvan testaamiseen sekä suorituskyvyn pullonkauloihin. Käyttöliittymätestauksessa puolestaan keskitytään verkkokäyttöliittymän ulkoasun ja toiminnan tarkistamiseen tai siihen, toimivatko tietyt painikkeet, lomakkeet, avattavat luettelot ja muut vastaavat elementit.

4. Mitkä ovat HTTP-pyynnön osat?

HTTP-pyynnössä on viisi osaa:

• HTTP-metodi (käsitellään jäljempänä), joka määrittää toiminnon.
• URI (yhtenäinen resurssitunniste) on palvelimella olevan resurssin tunniste.
• HTTP-versio, esimerkiksi HTTP v1.1.
• Pyynnön otsake sisältää HTTP-pyynnön viestin metatiedot (avain–arvo-pareina). Esimerkkejä metatiedoista ovat asiakkaan (tai selaimen) tyyppi, asiakkaan tukemat muodot, viestin rungon muodot, välimuistiasetukset ja muut tiedot.
• Pyynnön runko edustaa tietoja, jotka asiakas lähettää ohjelmointirajapinnalle.

5. Mitkä ovat REST-ohjelmointirajapinnoissa yleisimmin käytetyt HTTP-metodit?

Tärkeimmät REST-ohjelmointirajapintojen testauksessa käytettävät HTTP-metodit ovat CRUD-toimintoja suorittavat metodit:

• GET on HTTP-metodi, joka lukee tiedot resurssista.
• POST-metodia käytetään resurssien luomiseen tai päivittämiseen.
• PUT muokkaa olemassa olevaa resurssia.
• DELETE poistaa määritetyn resurssin.

6. Mikä ero on PUT- ja POST-metodeilla?

Tämä on haastattelukysymys, jonka sain usein, ja vastaus on osittain annettu jo edellä. 

Kun sinun on muutettava yksittäistä resurssia, joka on resurssikokoelman osa, kutsut PUT-metodia. Kun sinun on lisättävä lapsiresurssi resurssikokoelmaan, sinun on käytettävä POST-metodia. Jos PUT-HTTP-kutsu lähetetään useammin kuin kerran, tulokset pysyvät samoina. Jos POST-pyyntö lähetetään useita kertoja, tulokset vaihtelevat: esimerkiksi voidaan luoda useita resursseja tai palauttaa virhe.

Jos sinulla on esimerkiksi käyttäjien luomiseen ja päivittämiseen tarkoitettu resurssi, saman PUT-metodin lähettäminen käyttäjälle päivittää käyttäjän joka kerta. Saman POST-metodin lähettäminen käyttäjälle johtaa joko useiden käyttäjien luomiseen tai virheeseen, jonka mukaan käyttäjänimi tai sähköpostiosoite on jo käytössä.

7. Mitä HTTP-vastausten tilakoodiluokat ovat?

Tämä on toinen yleinen haastattelukysymys, ja se on tärkeä tietää, kun suoritetaan API-testausta. HTTP-vastausten koodiluokat ovat:

• 1xx: tähän luokkaan kuuluvat vastaukset ovat informatiivisia vastauksia. Ne tarkoittavat, että asiakkaan tulee jatkaa pyyntöä tai jättää vastaus huomiotta, jos pyyntö on valmis.
• 2xx: koodi 200 tarkoittaa onnistumista. 
• 3xx: nämä vastaukset ovat uudelleenohjausvastauksia. Tämä tarkoittaa, että pyynnölle on useita mahdollisia vastauksia. Käyttäjäagentin tai käyttäjän tulee valita niistä yksi. 
• 4xx: tämän ryhmän koodit ilmaisevat asiakasvirheen. Tämä tarkoittaa, ettei palvelin pysty käsittelemään pyyntöä ja tulkitsee sen asiakkaan puolelta johtuvaksi virheeksi, kuten tunnistamattomaksi URL-osoitteeksi, virheelliseksi pyynnön syntaksiksi tai vastaavaksi.
• 5xx: HTTP-vastauskoodi 500 palautetaan, kun palvelimen puolella tapahtuu virhe eikä palvelin pysty suorittamaan pyyntöä.

Jos haluat perehtyä vastausten tiloihin tarkemmin, löydät täydellisen luettelon verkosta. 

8. Mitkä ovat yleisiä API-testauksen automatisointityökaluja?

Tähän kysymykseen vastaisin mainitsemalla työkaluja, joiden kanssa olen jo työskennellyt tai jotka tunnen ainakin jonkin verran. Jos sinulla siis on kokemusta jostakin API-testaustyökalusta, mainitse se. Jos ei, voit vastata mainitsemalla joitakin suosittuja työkaluja, kuten Katalonin, Postmanin tai SoapUIn. Tutustu parhaita API-testaustyökaluja käsittelevään artikkeliimme saadaksesi inspiraatiota. 

9. Mitkä ovat yleisesti käytettyjä todennusmenetelmiä API-testauksessa?  

Sopiva vastaus tähän kysymykseen olisi:

• Istuntoon ja evästeisiin perustuva todennus
• Perustodennus
• Tiivistetodennus
• OAuth

10. Mitä eroa on todennuksella ja valtuutuksella?

Lyhyesti sanottuna todennus on käyttäjän henkilöllisyyden tarkistamisprosessi, kun taas valtuutus on käyttäjän käyttöoikeustason vahvistamisprosessi. 

11. Miksi API-testausta suositaan käyttöliittymätestauksen sijaan automatisoiduissa testeissä?

Kun palataan klassiseen testiautomaation pyramidiin, alallamme tiedetään hyvin, että käyttöliittymän päästä päähän -testien tulisi olla pyramidin huipulla, eli niiden tulisi muodostaa testien pienin määrä. Tämä johtuu siitä, että käyttöliittymän automatisoidut testit vievät yleensä enemmän aikaa ja ovat alttiimpia epävakaudelle, koska niillä on monia riippuvuuksia. Automatisoidut API-testit edustavat pyramidin integraatiotestausosaa, ja ne ovat paljon nopeampia ja yleensä luotettavampia.

12. Mitä eroa on API-testauksella ja yksikkötestauksella?

Yksikkötestaus kuuluu lasilaatikkotestaukseen, kun taas API-testaus on yleensä mustan laatikon testausta. Koska loppukäyttäjä käyttää käyttöliittymää, API-testauksen on edustettava järjestelmää kokonaisuutena. Yksikkötestauksessa keskeinen huomioitava asia on, toimiiko jokainen komponentti tai moduuli moitteettomasti. Toisin sanoen vankan moduuliarkkitehtuurin saavuttamiseksi riippuvuudet tulisi minimoida. 

13. Millaisia testauksia voidaan soveltaa API-rajapintoihin?

Useimmat käyttöliittymätestauksessa käytettävät testaustyypit toimivat myös API-rajapinnoilla. Muutamia merkittävimpiä testaustyyppejä, jotka voit mainita tässä API-haastattelukysymyksessä, ovat:

• Toiminnallinen testaus: useimmiten haluat testata, että rajapinnat tekevät sen, mihin ne on suunniteltu. Tämä tarkoittaa, että suoritat rajapinnoille toiminnallisia testitapauksia. 
• Manuaalinen testaus: se, ettet ole automaatiotestaaja, ei tarkoita, ettet voisi testata rajapintoja. Voit käyttää esimerkiksi Postmanin kaltaisia työkaluja pyyntöjen lähettämiseen ja vastausten testaamiseen manuaalisesti.
• Automaattinen testaus: API-testitapausten automatisointi on hyvä idea. Monet edellä mainituista työkaluista voivat auttaa siinä, tai voit luoda oman API-kehyksesi. 
• Kuormitustestaus: simuloimalla rajapintoihin kohdistuvaa liikennettä testaajat voivat tunnistaa pullonkaulat ennen niiden päätymistä tuotantoon. Jos tuotantokuormaa ei ole käytettävissä, näiden pullonkaulojen tunnistaminen kehitysympäristöissä voi olla haastavaa. On olemassa kuormitustestaustyökaluja, joiden avulla voit lähettää HTTP-kutsuja tiettyyn päätepisteeseen sekä mitata vastausajan, virheet ja virheiden määrän sekä muita arvokkaita tietoja vastauksista. Niiden avulla voidaan myös simuloida suuria tietomääriä sen arvioimiseksi, miten sovellus toimii.
• Tietoturvatestaus: tietoturvatestauksen avulla API-toteutus suojataan ulkopuolisilta uhilta. Tietoturvatestauksen vaiheisiin kuuluvat salaustekniikoiden ja API:n pääsynhallinnan arkkitehtuurin tarkistaminen. Myös käyttäjien pääsynhallinta ja valtuutusten tarkistaminen sisältyvät siihen.
• Penetraatiotestaus: tämän tyyppisessä testauksessa API:iin perehtymättömät käyttäjät yrittävät arvioida uhkavektoria etäältä keskittyen toiminnallisuuksiin, resursseihin, työnkulkuihin tai koko API:iin ja sen komponentteihin.

Olitpa sitten manuaalinen testaaja tai työskentelit testiautomaation parissa, on tärkeää tietää, miten rajapintojen kanssa työskennellään. Jos valmistaudut API-testausta koskeviin työhaastattelukysymyksiin, toivon, että löydät tästä artikkelista hyödyllistä tietoa.

Älä unohda tilata The CTO Clubin uutiskirjettä, niin saat lisää testausvinkkejä ja opetusohjelmia!