Miten API-savukokeet suoritetaan jatkuvan käyttöönoton putkessa

Joka vuosi yhä useammat ohjelmistoyritykset siirtyvät mikropalveluarkkitehtuuriin, jossa käytetään ohjelmointirajapintoja (APIs), koska API:t helpottavat projektin eri tiimien pääsyä toistensa resursseihin. API:t mahdollistavat myös sen, että ohjelmistoyritykset tai yksityishenkilöt voivat saada tietoja toisiltaan: esimerkiksi Twitterillä on API, jota monet pienyritykset käyttävät liiketoimintaansa liittyvien twiittien hakemiseen ja näyttämiseen yrityksen verkkosivulla.

Toinen API:en erinomainen ominaisuus on se, että ne ovat monoliittista sovellusta pienempiä, mikä tarkoittaa, että ne voidaan ottaa käyttöön usein. Yrityksessä, jossa työskentelen, jokaisella tiimillä on useita API:ja, ja meillä on kahdeksan eri ympäristöä, joihin otamme niitä käyttöön. Jos luottaisimme pelkästään manuaaliseen testaukseen varmistaaksemme, että API:t on otettu käyttöön oikein, joutuisimme suorittamaan kahdeksan testikokonaisuutta jokaisen API-julkaisun yhteydessä. Jos ottaisimme käyttöön useamman kuin yhden API:n kerrallaan, kuten usein teemme, koska API:mme toimivat yhdessä, voisimme joutua suorittamaan satoja testejä. Ja jos otamme käyttöön uuden version joka toinen viikko, nämä testit muodostavat suuren määrän puuduttavaa ja toistuvaa testausta! 

Ratkaisimme tämän ongelman määrittämällä automatisoidut API-savutestit, jotka suoritetaan jokaisen käyttöönoton yhteydessä kaikissa ympäristöissä. Tässä artikkelissa kerron, miten päätimme, mitä testataan, ja miten määritimme savutestimme. Käytimme Postmania, Newmania, Powershelliä ja Octopusta automatisoitujen savutestien määrittämiseen, joten kuvailen, mitä teimme näillä työkaluilla. Näitä strategioita voidaan kuitenkin soveltaa mihin tahansa jatkuvan käyttöönoton (CD) putkeen.

Vaihe yksi: päätä, mitä testataan

Savutestien päätarkoitus on suorittaa yksinkertaisia, korkean tason testejä, joilla varmistetaan käyttöönoton onnistuminen. Tässä ei ole tarkoitus testata kaikkea, mitä API:si pystyy tekemään. Kun valitsimme savutesteihin sisällytettävät testit, otimme huomioon seuraavat asiat:

• Määritimme yhden ”onnistumispolku”-testin jokaiselle päätepisteelle – toisin sanoen yhden testin, jonka odotetaan onnistuvan. Esimerkiksi tietyn tunnisteen sisältävän resurssin GET-pyynnön odotetaan palauttavan kyseisen resurssin. Jokainen päätepiste kannattaa testata kerran sen varmistamiseksi, että se toimii odotetulla tavalla.

• Jos tietyn päätepisteen käyttötavoissa oli merkittäviä vaihteluita, lisäsimme yhden tai useamman testin näiden vaihteluiden tarkistamiseksi. Meillä on esimerkiksi tiedostojen hakemiseen tarkoitettu API, jossa tiedosto voidaan hakea kahdella eri menetelmällä. Päätepiste näyttää samalta, mutta pyyntöjen rungot ovat erilaisia. Siksi lisäsimme yhden testin kumpaakin menetelmää varten.

• Päätepisteille, jotka edellyttivät tiettyä suojaustasoa, lisäsimme testin, jolla varmistettiin, että pyyntö ilman asianmukaista todennusta EI palauttaisi tietoja, vaan palauttaisi 400-tasoisen virheen.

• Emme lisänneet muita negatiivisia testejä, kuten POST-pyyntöä, jonka tiedot olivat sallittujen parametrien ulkopuolella, koska emme kokeneet niiden olevan tarpeellisia API:n toiminnan varmistamiseksi. Suoritimme nämä testit sen sijaan osana öistä regressiotestikokonaisuutta.

Vaihe kaksi: vie testisi 

Loimme API-testimme Postmanilla, joten testien luomisen jälkeen veimme sekä testikokoelman että testiympäristötiedoston JSON-tiedostoiksi. Niille, joille Postman ei ole tuttu, testiympäristö on joukko muuttujia, joihin voidaan viitata testikokoelmassa. 

Vaihe kolme: kirjoita komentosarja testien suorittamista varten

Postmanissa on Newman-niminen komentorivityökalu, jolla voidaan suorittaa testikokoelma, joten käytimme sitä testiemme suorittamiseen. Loimme Powershell-komentosarjan, joka suorittaisi Newman-komennon. 

Vaihe neljä: luo käyttöönottovaihe komentosarjasi kutsumista varten

Kun Powershell-komentosarja oli valmis, määritimme jokaiseen Octopus API -käyttöönottoprojektiin käyttöönottovaiheen, joka suorittaisi testikomentosarjan. Jos komentosarja epäonnistui, käyttöönotto epäonnistui.

Vaihe viisi: järjestä muuttujasi

Muuttujat ovat usein huomioitava asia, kun savutestejä suoritetaan eri ympäristöissä. Esimerkiksi QA-ympäristössä testikäyttäjäsi tunniste voi olla 340, mutta Staging-ympäristössä testikäyttäjäsi tunniste voi olla 620. Toinen muuttujien ongelma on se, että turvallisuussyistä sinulla ei välttämättä ole pääsyä tuotantoympäristöjen salasanoihin tai avaimiin. Näin oli myös meidän tiimillämme, mutta onneksi Octopuksessa on testiemme suorittamiseen tarvitsemamme arvot, joten ratkaisimme ongelman antamalla Octopuksen välittää tarvitsemamme arvot testikomentosarjalle.

Savutestiämme varten tarvittiin kolmenlaisia muuttujia:

• Tyyppi 1: Muuttujat, jotka eivät muuttuneet testiympäristöittäin, kuten ”firstName”: ”Prunella”. Nämä muuttujat voitiin lisätä suoraan Postman-ympäristöön, joten niille ei tarvinnut tehdä mitään muuta. 

• Tyyppi 2: Muuttujat, jotka muuttuivat testiympäristöittäin, mutta joita ei tarvinnut pitää suojattuina, kuten ”userId”: 340. Nämä muuttujat lisättiin Octopus-muuttujina seuraavasti: ”smoke.userId”, ja muuttujan arvo määritettiin kullekin ympäristölle; esimerkiksi QA:lle määritettiin 340, Stagingille 620 ja Productionille 450.

• Tyyppi 3: Muuttujat, jotka muuttuivat kussakin testiympäristössä ja jotka piti pitää suojattuina, kuten “apiKey”: “b20628a9-3c00-4dad-b38c-0a4d2d85ffab”. Tyypin 3 muuttujat oli jo määritetty Octopus-muuttujakirjastossa. 

Käytimme muuttujia tämän jälkeen seuraavasti:

1. Kun kutsuimme PowerShell-komentosarjaa Octopuksessa, lähetimme Octopuksessa määritetyt muuttujat komentosarjalle. 
2. PowerShell-komentosarjassa vastaanotimme lähetetyt Octopus-muuttujat ja määritimme ne PowerShell-muuttujiksi. 
3. Kun käytimme Newman-komentoa PowerShell-komentosarjassa, lähetimme komentosarjan muuttujat Postman-ympäristöön.
4. Newman käytti PowerShell-komentosarjassa lähetettyjä muuttujia yhdessä Postman-ympäristön muuttujien kanssa Postman-kokoelman suorittamiseen.

Kun API-savutestimme suoritetaan Octopuksessa jokaiselle API:lle ja jokaisessa ympäristössä, voimme olla luottavaisia siihen, että kaikki suuret API:n käyttöönottoon liittyvät ongelmat havaitaan välittömästi. Lisäksi voimme testata tuotantoympäristöissä myös silloin, kun meillä ei ole pääsyä arkaluonteisiin API-avaimiin. Automaattiset käyttöönoton savutestit vapauttavat aikaa muuhun testaamiseen, kuten manuaaliseen tutkivaan testaukseen ja tietoturvatestaukseen, sekä useamman testiautomaation kirjoittamiseen öisiä regressiotestejä varten. 

Jos haluat lisää käyttöohjeita, tilaa The QA Lead -uutiskirje.

Jatka oppimista ja tutustu tähän podcastiin: MITEN AVOIMEN LÄHDEKOODIN OHJELMISTOT YKSINKERTAISTAVAT INTEGRAATIOTA AUTOMAATIOTEKNIIKASSA (JAMES WALKERIN JA SANJAY KUMARIN KANSSA)