- Luettelo API-testauksen opetusohjelmista
- Yleiskatsaus tämän API-testaussarjan opetusohjelmiin
- API-testauksen opetusohjelma
- API-testauksen käyttöönotto organisaatiossasi
- Päätelmä
Tämä syvällinen API-testauksen opetusohjelma selittää kaiken API-testauksesta, verkkopalveluista ja siitä, miten API-testauksen voi ottaa käyttöön organisaatiossasi:
Tutustu API-testaukseen sekä shift-left-testauksen ja verkkopalvelujen käsitteeseen tässä johdanto-oppaassa.
Käsitteet kuten Web API, miten API toimii (todellisen maailman esimerkin avulla) ja miten se eroaa Web Services -palveluista, selitetään hyvin esimerkkien avulla tässä opetusohjelmassa.
Luettelo API-testauksen opetusohjelmista
Tutoriaali #1: API-testauksen opetusohjelma: Täydellinen opas aloittelijoille
Tutoriaali #2: Verkkopalveluiden opetusohjelma: Komponentit, arkkitehtuuri, tyypit ja esimerkit.
Tutoriaali #3: Top 35 ASP.Net ja Web API haastattelukysymyksiä vastauksineen
Ohje #4: POSTMAN Tutorial: API-testaus POSTMANin avulla
Ohje #5: Verkkopalvelujen testaus Apache HTTP -asiakkaan avulla
Yleiskatsaus tämän API-testaussarjan opetusohjelmiin
Tutorial # | Mitä opit |
---|---|
Tutorial_#1: | API-testauksen opetusohjelma: Täydellinen opas aloittelijoille Tämä syvällinen API-testauksen opetusohjelma kertoo yksityiskohtaisesti API-testauksesta ja verkkopalveluista sekä opettaa sinulle, miten voit ottaa API-testauksen käyttöön organisaatiossasi. |
Tutorial_#2: | Verkkopalveluiden opetusohjelma: Komponentit, arkkitehtuuri, tyypit ja esimerkit. Tässä Web Services -oppaassa selitetään Web Servicesin arkkitehtuuri, tyypit ja komponentit sekä tärkeät termit ja SOAPin ja RESTin erot. |
Tutorial_#3: | Top 35 ASP.Net ja Web API haastattelukysymyksiä vastauksineen Voit tutustua luetteloon suosituimmista usein kysytyistä ASP.Net- ja Web API -haastattelukysymyksistä vastauksineen & esimerkkejä aloittelijoille ja kokeneille ammattilaisille tässä opetusohjelmassa. |
Tutorial_#4: | POSTMAN Tutorial: API-testaus POSTMANin avulla Tämä vaiheittainen opetusohjelma selittää API-testaus POSTMANin avulla sekä POSTMANin perusteet, sen komponentit ja näytepyyntö ja näyte; Vastaus yksinkertaisin termein, jotta ymmärrät sen helposti. |
Tutorial_#5: | Verkkopalvelujen testaus Apache HTTP -asiakkaan avulla Tämä API-opas käsittelee erilaisten CRUD-operaatioiden suorittamista verkkopalveluissa ja verkkopalveluiden testaamista Apache HTTP -asiakkaan avulla. |
API-testauksen opetusohjelma
Tämä osio auttaa sinua saamaan perustiedot verkkopalveluista ja web-rajapinnoista, mikä puolestaan auttaa ymmärtämään tämän API-testaussarjan tulevien opetusohjelmien keskeisiä käsitteitä.
API (Application Programming Interface, sovellusohjelmointirajapinta) on joukko menettelyjä ja toimintoja, joiden avulla voimme luoda sovelluksen käyttämällä käyttöjärjestelmän tai alustojen tietoja tai ominaisuuksia. Tällaisten menettelyjen testausta kutsutaan API-testaukseksi.
Vaihtaa vasemmalle Testaus
Yksi tärkeistä testaustyypeistä, joita nykyään kysytään API-testaushaastatteluissa, on Shift Left -testaus. Tätä testaustyyppiä harjoitetaan lähes kaikissa projekteissa, jotka noudattavat ketterää metodologiaa.
Ennen Shift Left -testauksen käyttöönottoa ohjelmistotestaus tuli kuvaan vasta sen jälkeen, kun koodaus oli valmis ja koodi oli toimitettu testaajille. Tämä käytäntö johti viime hetken kiireeseen noudattaa määräaikaa, ja se myös haittasi suuresti tuotteen laatua.
Tämän lisäksi ponnistelut (kun virheistä ilmoitettiin viimeisessä vaiheessa ennen tuotantoa) olivat valtavia, koska kehittäjien oli käytävä sekä suunnittelu- että koodausvaihe läpi uudelleen.
Ohjelmistokehityksen elinkaari (SDLC) ennen siirtymistä vasemmalle Testaus
SDLC:n perinteinen kulku oli seuraava: vaatimukset -> suunnittelu -> koodaus -> testaus.
Perinteisen testauksen haitat
- Testaus on äärimmäinen oikealla. Paljon kustannuksia syntyy, kun virhe tunnistetaan viime hetkellä.
- Virheen korjaamiseen ja sen uudelleen testaamiseen ennen sen siirtämistä tuotantoon kuluu valtavasti aikaa.
Näin ollen syntyi uusi ajatus siirtää testausvaihe vasemmalle, mikä johti Shift Left Testing -testausjärjestelmään.
Suositeltu luku => Shift Left -testaus: salainen mantra ohjelmistojen menestykseen
Vasemman vuoron testauksen vaiheet
Vasemman vuoron testaus johti onnistuneeseen siirtymiseen vikojen havaitsemisesta vikojen ehkäisyyn. Se myös auttoi ohjelmistoa epäonnistumaan nopeasti ja korjaamaan kaikki virheet mahdollisimman aikaisessa vaiheessa.
Web API
Yleisesti ottaen web-rajapinta voidaan määritellä laitteeksi, joka ottaa vastaan pyynnön asiakasjärjestelmästä web-palvelimelle ja lähettää vastauksen web-palvelimelta takaisin asiakaskoneelle.
Miten API toimii?
Otetaan hyvin yleinen skenaario, jossa varataan lento osoitteesta www.makemytrip.com, joka on online-matkapalvelu, joka kokoaa yhteen useiden lentoyhtiöiden tiedot. Kun haet lentoa, syötät tiedot, kuten matkapäivän ja paluupäivän, matkustusluokan jne. ja napsautat hakua.
Tämä näyttää sinulle useiden lentoyhtiöiden hinnat ja niiden saatavuuden. Tässä tapauksessa sovellus on vuorovaikutuksessa useiden lentoyhtiöiden sovellusliittymien kanssa ja antaa siten pääsyn lentoyhtiöiden tietoihin.
Toinen esimerkki on www.trivago.com, joka vertailee ja listaa eri hotellien hintoja, saatavuutta jne. tietystä kaupungista. Tämä verkkosivusto kommunikoi useiden hotellien API-rajapintojen kanssa saadakseen pääsyn tietokantaan ja listaa hinnat ja saatavuuden niiden verkkosivuilta.
Web API voidaan siis määritellä "käyttöliittymäksi, joka helpottaa asiakaskoneen ja web-palvelimen välistä viestintää".
Verkkopalvelut
Verkkopalvelut ovat (kuten Web API) palveluita, jotka palvelevat koneelta toiselle. API:n ja verkkopalveluiden välillä on kuitenkin se merkittävä ero, että verkkopalvelut käyttävät verkkoa.
On turvallista sanoa, että kaikki verkkopalvelut ovat web-rajapintoja, mutta kaikki web-rajapinnat eivät ole web-palveluja (selitetään artikkelin loppuosassa). Näin ollen web-palvelut ovat web-rajapintojen osajoukko. Alla olevasta kaaviosta saat lisätietoja web-rajapinnoista ja web-palveluista.
Web API vs Web Services
Verkkopalvelut vs. Web API
Sekä Web API:ta että Web Services -palveluja käytetään helpottamaan asiakkaan ja palvelimen välistä viestintää. Suurin ero on vain siinä, miten ne kommunikoivat.
Kukin niistä vaatii tietyllä kielellä hyväksyttävän pyynnön rungon, niiden erot suojatun yhteyden tarjoamisessa, niiden nopeus yhteydenpidossa palvelimelle ja vastaamisessa asiakkaalle jne. ovat erilaiset.
Verkkopalveluiden ja Web API:n erot on lueteltu alla.
Verkkopalvelu
- Verkkopalvelut käyttävät yleensä XML:ää (Extensible Markup Language), mikä tarkoittaa, että ne ovat turvallisempia.
- Verkkopalvelut ovat turvallisempia, sillä sekä verkkopalvelut että sovellusrajapinnat tarjoavat SSL (Secure Socket Layer) -yhteyden tiedonsiirron aikana, mutta ne tarjoavat myös WSS (Web Services Security) -yhteyden.
- Web Service on Web API:n osajoukko. Esimerkiksi, Verkkopalvelut perustuvat ainoastaan kolmeen käyttötyyliin, joita ovat seuraavat. SOAP, REST ja XML-RPC.
- Verkkopalvelut tarvitsevat aina verkon toimiakseen.
- Verkkopalvelut tukevat "yhtä koodia eri sovelluksiin", mikä tarkoittaa, että eri sovelluksiin kirjoitetaan yleisempää koodia.
Web API
- Web API käyttää yleensä JSONia (JavaScript Object Notation), mikä tarkoittaa, että Web API on nopeampi.
- Web API on nopeampi, koska JSON on kevyt, toisin kuin XML.
- Verkkosovellusliittymät ovat verkkopalvelujen yläjoukko. Esimerkiksi, Kaikki kolme verkkopalvelutyyliä ovat läsnä myös Web API:ssa, mutta sen lisäksi se käyttää myös muita tyylejä, kuten JSON - RPC.
- Web API ei välttämättä vaadi verkkoa toimiakseen.
- Web API voi tukea tai olla tukematta yhteentoimivuutta järjestelmän tai sovelluksen luonteesta riippuen.
API-testauksen käyttöönotto organisaatiossasi
Olemme kaikki tottuneet päivittäisessä elämässämme olemaan vuorovaikutuksessa sovellusten kanssa sovellusrajapintojen avulla, emmekä kuitenkaan edes ajattele taustaprosesseja, jotka ohjaavat taustalla olevia toimintoja.
Esimerkiksi, Oletetaan, että selaat tuotteita Amazon.com-sivustolla ja näet tuotteen/tarjouksen, josta todella pidät ja haluat jakaa sen Facebook-verkostosi kanssa.
Kun napsautat Facebook-kuvaketta sivun jako-osiossa ja syötät Facebook-tilisi tunnukset jakamista varten, olet vuorovaikutuksessa API:n kanssa, joka yhdistää Amazonin verkkosivuston saumattomasti Facebookiin.
Painopiste siirtyy API-testaukseen
Ennen kuin keskustelemme lisää API-testauksesta, selvitetään syyt, joiden vuoksi API-pohjaiset sovellukset ovat kasvattaneet suosiotaan viime aikoina.
On useita syitä, joiden vuoksi organisaatiot siirtyvät API-pohjaisiin tuotteisiin ja sovelluksiin. Alla on lueteltu muutamia niistä.
#1) API-pohjaiset sovellukset ovat perinteisiin sovelluksiin/ohjelmistoihin verrattuna skaalautuvampia. Koodin kehitysnopeus on nopeampi, ja sama API voi palvella useampia pyyntöjä ilman suuria muutoksia koodiin tai infrastruktuuriin.
#2) Kehitystiimien ei tarvitse aloittaa koodausta tyhjästä joka kerta, kun ne alkavat kehittää ominaisuutta tai sovellusta. API:t käyttävät useimmiten uudelleen olemassa olevia, toistettavia funktioita, kirjastoja, tallennettuja proseduureja jne., ja näin ollen tämä prosessi voi tehdä tiimeistä kokonaisuudessaan tuottavampia.
Esimerkiksi, Jos olet kehittäjä, joka työstää verkkokauppasivustoa ja haluat lisätä Amazonin maksuprosessoriksi, sinun ei tarvitse kirjoittaa koodia tyhjästä.
Kaikki mitä sinun tarvitsee tehdä, on luoda integraatio verkkosivustosi ja Amazon API:n välille käyttämällä integraatioavaimia ja kutsua Amazon API:ta maksujen käsittelyä varten kassan aikana.
#3) API:t mahdollistavat helpon integroinnin muihin järjestelmiin sekä tuettujen itsenäisten sovellusten että API-pohjaisten ohjelmistotuotteiden kanssa.
Esimerkiksi , Oletetaan, että haluat lähettää lähetyksen Torontosta New Yorkiin. Menet verkkoon, siirryt tunnetulle rahtikuljetus- tai logistiikkasivustolle ja syötät tarvittavat tiedot.
Kun olet antanut pakolliset tiedot ja napsauttanut Get Rates (Hae hinnat) -painiketta, logistiikkasivusto voi olla yhteydessä useisiin liikenteenharjoittajien ja palveluntarjoajien API- ja sovellussovelluksiin saadakseen dynaamiset hinnat lähtö- ja määräpaikkojen yhdistelmälle.
API-testien koko kirjo
API-rajapintojen testaaminen ei rajoitu pelkästään pyynnön lähettämiseen API:lle ja vastauksen analysoimiseen oikeellisuuden kannalta. API-rajapintojen suorituskyky on testattava eri kuormituksissa haavoittuvuuksien varalta.
Keskustellaan tästä yksityiskohtaisesti.
(i) Toiminnallinen testaus
Toiminnallinen testaus voi olla haastava tehtävä graafisen käyttöliittymän puuttumisen vuoksi.
Katsotaanpa, miten sovellusrajapintojen toiminnallinen testaus eroaa graafiseen käyttöliittymään perustuvasta sovelluksesta, ja keskustelemme myös muutamista esimerkeistä.
a) Selkein ero on se, että ei ole graafista käyttöliittymää, jonka kanssa olla vuorovaikutuksessa. Testaajien, jotka yleensä tekevät graafiseen käyttöliittymään perustuvaa toiminnallista testausta, on hieman vaikeampi siirtyä sovellusten testaamiseen ilman graafista käyttöliittymää kuin niiden, joille se on jo tuttu.
Aluksi, jo ennen kuin aloitat API:n testaamisen, sinun on testattava ja todennettava itse todennusprosessi. Todennusmenetelmä vaihtelee API:sta toiseen, ja se sisältää jonkinlaisen avaimen tai tunnisteen todennusta varten.
Jos API-yhteyden muodostaminen ei onnistu, testausta ei voida jatkaa. Tätä prosessia voidaan verrata käyttäjän todennukseen tavallisissa sovelluksissa, joissa tarvitaan voimassa olevat tunnistetiedot sovellukseen kirjautumista ja sen käyttöä varten.
b) Kenttien validoinnin tai syöttötietojen validoinnin testaaminen on erittäin tärkeää API:iden testauksen yhteydessä. Jos käytettävissä olisi varsinainen lomakepohjainen (GUI) käyttöliittymä, kenttien validointi voitaisiin toteuttaa etu- tai takapäässä, jolloin voitaisiin varmistaa, että käyttäjä ei voi syöttää kentän virheellisiä arvoja.
Esimerkiksi, Jos sovellus tarvitsee päivämäärän muotoa DD/MM/YYYY, voimme soveltaa tätä validointia lomakkeella, jolla kerätään tietoja, jotta varmistetaan, että sovellus vastaanottaa ja käsittelee kelvollisen päivämäärän.
Meidän on varmistettava, että sovellusrajapinta on hyvin kirjoitettu ja että se pystyy toteuttamaan kaikki nämä validoinnit, erottamaan kelvolliset ja virheelliset tiedot toisistaan ja palauttamaan loppukäyttäjälle vastauksena tilakoodin ja validointivirheilmoituksen.
c) API:n vastausten oikeellisuuden testaaminen kelvollisten ja virheellisten vastausten osalta on todellakin ratkaisevan tärkeää. Jos testi-API:n vastauksena saadaan statuskoodi 200 (eli kaikki kunnossa), mutta vastaustekstissä sanotaan, että on havaittu virhe, kyseessä on virhe.
Lisäksi jos itse virheilmoitus on virheellinen, se voi olla hyvin harhaanjohtava loppuasiakkaalle, joka yrittää integroida tätä sovellusrajapintaa.
Alla olevassa kuvakaappauksessa käyttäjä on syöttänyt virheellisen painon, joka on suurempi kuin sallittu 2267 kg. API vastaa virheeseen tilakoodilla ja virheilmoituksella. Virheilmoituksessa mainitaan kuitenkin virheellisesti painoyksiköksi lbs KG:n sijasta KG. Tämä on virhe, joka voi hämmentää loppuasiakasta.
(ii) Kuormitus- ja suorituskykytestaukset
API:t on suunniteltu skaalautuviksi.
Tämä puolestaan tekee kuormitus- ja suorituskykytestauksesta olennaisen tärkeää, varsinkin jos suunnitellun järjestelmän odotetaan palvelevan tuhansia pyyntöjä minuutissa tai tunnissa vaatimuksesta riippuen. API:n kuormitus- ja suorituskykytestauksen rutiininomainen suorittaminen voi auttaa suorituskyvyn, huippukuormituksen ja murtumispisteen vertailussa.
Nämä tiedot ovat hyödyllisiä, kun suunnitellaan sovelluksen skaalaamista. Kun nämä tiedot ovat saatavilla, ne auttavat tukemaan päätöksiä ja suunnittelua erityisesti silloin, kun organisaatio suunnittelee lisäävänsä asiakkaita, mikä tarkoittaisi useampia saapuvia pyyntöjä.
Kuinka ottaa API-testaaminen käyttöön organisaatiossasi
API-testauksen käyttöönotto organisaatiossa on samanlainen prosessi kuin minkä tahansa muun testausvälineen ja -puitteiston käyttöönotto tai käyttöönotto.
Alla olevassa taulukossa esitetään yhteenveto tärkeimmistä vaiheista ja kunkin vaiheen odotetuista tuloksista.
Vaihe | Vaihe | Odotettu tulos |
---|---|---|
Työkalun valinta | Kerää vaatimukset ja tunnista rajoitukset | Ymmärtää vaatimukset, jotka koskevat sopivaa API-testaustyökalua koskevien markkinoiden tutkimista. Esim. Minkälaista API:ta testataan - SOAP vai REST? Pitääkö meidän palkata testaaja tähän tehtävään vai kouluttaa olemassa oleva testaaja? Millaisia testejä tehdään - toiminnallisia testejä, suorituskykytestejä jne. Mikä on täytäntöönpanon talousarvio? |
Arvioi käytettävissä olevat välineet | Vertaile käytettävissä olevia työkaluja ja tee lyhyt luettelo 1-2 työkalusta, jotka täyttävät vaatimukset parhaiten. | |
Proof of Concept | Toteuta osajoukko testejä valituilla työkaluilla. Esittele tulokset sidosryhmille. Viimeistellään käyttöön otettava työkalu. | |
Täytäntöönpano | Aloittaminen | Valitsemastasi työkalusta riippuen sinun on joko asennettava tarvittava työkalu tietokoneeseen, virtuaalikoneeseen tai palvelimeen. Jos valittu työkalu on tilauspohjainen, luo tarvittavat tiimitilit. Kouluta tiimi tarvittaessa. |
Lähde liikkeelle | Luo testit Testien suorittaminen Ilmoita vioista |
Yleiset haasteet ja keinot niiden lieventämiseksi
Keskustellaanpa joistakin yleisistä haasteista, joita QA-ryhmät kohtaavat yrittäessään ottaa API-testauksen kehyksen käyttöön organisaatiossa.
#1) Oikean työkalun valitseminen
Oikean työkalun valitseminen on yleisin haaste. Markkinoilla on saatavilla useita API-testityökaluja.
Saattaa tuntua houkuttelevalta ottaa käyttöön markkinoiden uusin ja kallein työkalu, mutta jos se ei tuota toivottuja tuloksia, työkalusta ei ole mitään hyötyä.
Valitse siis aina työkalu, joka täyttää organisaatiosi tarpeisiin perustuvat "pakolliset" vaatimukset.
Seuraavassa on esimerkki käytettävissä olevien API-työkalujen arviointimatriisista.
Työkalu | Hinnoittelu | Huomautukset |
---|---|---|
Soap UI | Ilmainen versio saatavilla SoapUI Open Source -versiosta (toiminnallinen testaus) | * REST, SOAP ja muut suositut API- ja IoT-protokollat. * Sisältyy ilmaisversioon SOAP- ja REST-ad-hoc-testaukset Viestin vahvistaminen Vedä &; pudota testin luominen Testilokit Testauskonfiguraatio Testi tallenteista Yksikön raportointi. * Täydellinen luettelo ominaisuuksista löytyy heidän verkkosivuiltaan. |
Postimies | Ilmainen Postman App saatavilla | * Eniten käytetty REST-käytössä. * Ominaisuudet löytyvät heidän verkkosivuiltaan. |
Parasoft | Se on maksullinen työkalu, joka vaatii lisenssin ostamisen ja asennuksen ennen kuin työkalua voi käyttää. | * Kattava API-testaus: toiminnallinen, kuormitus, tietoturvatestaus, testidatan hallinta |
vREST | Käyttäjien lukumäärän perusteella | * Automatisoitu REST API -testaus. * Tallenna ja toista. * Poistaa riippuvuuden frontendistä ja backendistä käyttämällä mock API:ta. * Tehokas vastausvalidointi. * Toimii testisovelluksille, jotka on asennettu localhostiin/intranetiin/internetiin. * JIRA-integraatio, Jenkins-integraatio Tuonnit Swaggerista, Postmanista. |
HttpMaster | Express Edition: Lataa ilmaiseksi Professional-versio: Käyttäjien lukumäärän perusteella | * Auttaa verkkosivuston testauksessa sekä API-testaus. * Muihin ominaisuuksiin kuuluu kyky määritellä globaaleja parametreja, antaa käyttäjälle mahdollisuuden luoda tarkistuksia datan vastauksen validointia varten käyttämällä suurta joukkoa validointityyppejä, joita se tukee. |
Runscope | Käyttäjien määrän ja suunnitelmatyyppien perusteella | * API:n seurantaan ja testaukseen. * Voidaan käyttää tietojen validointiin oikeiden tietojen palauttamisen varmistamiseksi. * Sisältää ominaisuuden seurata ja ilmoittaa, jos API-transaktio epäonnistuu ( jos sovelluksesi vaatii maksun validointia, tämä työkalu voi osoittautua hyväksi valinnaksi ). |
LoadFocus | Käyttäjien lukumäärän ja suunnitelmatyyppien perusteella. | * Voidaan käyttää API-kuormitustestaukseen - mahdollistaa muutaman testin suorittamisen sen selvittämiseksi, kuinka monta käyttäjää API voi tukea. * Helppokäyttöinen - mahdollistaa testien suorittamisen selaimessa. |
PingAPI | Ilmainen 1 projekti (1,000 pyyntöä) | * Hyödyllinen automatisoidulle API-testaukselle ja -seurannalle. |
#2) Puuttuvat testauseritelmät
Testaajina meidän on tiedettävä odotetut tulokset, jotta voimme testata sovelluksen tehokkaasti. Tämä on usein haasteellista, sillä jotta voisimme tietää odotetut tulokset, meillä on oltava selkeät ja tarkat vaatimukset, mikä ei kuitenkaan ole mahdollista.
Esimerkiksi ota huomioon jäljempänä esitetyt vaatimukset:
"Sovelluksen pitäisi hyväksyä vain voimassa oleva toimituspäivä ja kaikki virheelliset vaatimukset pitäisi hylätä"
Näistä vaatimuksista puuttuu keskeisiä yksityiskohtia, ja ne ovat hyvin epäselviä - miten määrittelemme kelvollisen päivämäärän? Entä muoto? Palautammeko loppukäyttäjälle hylkäävän viestin jne.?
Esimerkki selkeistä vaatimuksista:
1) Sovelluksen pitäisi hyväksyä vain voimassa oleva toimituspäivä.
Lähetyspäivämäärä katsotaan päteväksi, jos se on
- Ei aiemmin
- Suurempi tai yhtä suuri kuin tämän päivän päivämäärä
- Hyväksyttävä muoto: pp.kk.vvvv/vvvvv
2)
Vastauksen tilakoodi = 200
Viesti: OK
3) Toimituspäivämäärää, joka ei täytä edellä mainittuja kriteerejä, on pidettävä virheellisenä. Jos asiakas lähettää virheellisen toimituspäivämäärän, sen on vastattava seuraavalla virheilmoituksella (seuraavilla virheilmoituksilla):
3.1
Vastaus Tilakoodi NOT 200
Virhe: Toimituspäivämäärä on virheellinen; varmista, että päivämäärä on muodossa TT/MM/VVVV.
3.2
Vastaus Tilakoodi NOT 200
Virhe: Toimituspäivämäärä on menneisyydessä.
#3) Oppimiskäyrä
Kuten aiemmin mainittiin, sovellusrajapintatestauksen lähestymistapa on erilainen kuin graafiseen käyttöliittymään perustuvien sovellusten testauksen lähestymistapa.
Jos API-testaukseen palkataan asiantuntijoita joko talon sisällä tai konsultteja, API-testausmenetelmän tai API-testityökalun oppimiskäyrä voi olla minimaalinen. Oppimiskäyrä liittyy tässä tapauksessa tuote- tai sovellustuntemuksen hankkimiseen.
Jos API-testauksen opetteleminen annetaan tiimin olemassa olevalle jäsenelle, oppimiskäyrä voi olla valituista työkaluista riippuen keskinkertainen tai suuri, samoin kuin testauslähestymistavan muuttaminen. Itse tuotteen tai sovelluksen oppimiskäyrä voi olla matala tai keskinkertainen riippuen siitä, onko kyseinen testaaja testannut kyseistä sovellusta aiemmin vai ei.
#4) Olemassa olevat taidot
Tämä liittyy suoraan edelliseen kohtaan oppimiskäyrästä.
Jos testaaja on siirtymässä GUI-pohjaisesta testauksesta, hänen on muutettava testaustapaa ja opeteltava uusi työkalu tai kehys tarpeen mukaan. Esim. Jos API hyväksyy pyynnöt JSON-muodossa, testaajan on opittava, mitä JSON on, jotta hän voi aloittaa testien luomisen.
Tapaustutkimus
Tehtävä
Olemassa olevan sovelluksen skaalaamiseksi yritys halusi tarjota tuotetta API:na sekä tavallisen GUI-sovelluksen. QA-ryhmää pyydettiin toimittamaan testien kattavuussuunnitelma sen varmistamiseksi, että he ovat valmiita toteuttamaan API-testauksen tavanomaisten GUI-pohjaisten testien lisäksi.
Haasteet
- Yhdelläkään muulla ohjelmistotuotteella ei ollut API-pohjaista arkkitehtuuria, joten tämän tehtävän testaamiseksi tiimin oli luotava API-testausprosessi tyhjästä. Tämä tarkoittaa sitä, että työkalut oli arvioitava, valittava ja viimeisteltävä, ja tiimi oli koulutettava testejä varten.
- Työkalun hankkimiseen ja käyttöönottoon ei ollut varattu lisäbudjettia, joten tiimin oli valittava ilmainen tai avoimen lähdekoodin API-testaustyökalu, ja jonkun olemassa olevasta tiimistä oli koulutettava tähän tehtävään.
- API-kenttiä ja tietojen validointia koskevia vaatimuksia ei ollut. Vaatimuksina oli, että niiden pitäisi toimia samalla tavalla kuin vastaavan GUI-sovelluksen.
Tiimin noudattama lähestymistapa riskien lieventämiseksi ja haasteiden ratkaisemiseksi.
- Laadunvarmistusryhmä teki yhteistyötä projektiryhmän kanssa seuraavien vaatimusten määrittämiseksi:
- API-tyyppi (REST/SOAP ): REST
- Tarvittavat testit (toiminnalliset, kuormitus- ja turvatestit): Vain toiminnallinen testaus
- Tarvitaan automatisoituja testejä (Kyllä/Ei): Valinnainen toistaiseksi
- Testiraportit (kyllä/ei): Vaadittu
- QA-ryhmä teki työkalujen arvioinnin saatavilla olevista API-testaustyökaluista, jotka perustuivat pakollisiin vaatimuksiin. Postman API Tool valikoitui heidän valitsemakseen työkaluksi, koska se oli ilmainen ja helppokäyttöinen, mikä minimoi oppimiskäyrän, ja sillä oli mahdollisuus automatisoida testejä, ja siinä oli hyvät sisäänrakennetut raportit.
- Sama testaaja, joka testasi sovelluksen, koulutettiin käyttämään Postmania alustavien testien luomiseksi, jolloin tuotetuntemuksen puutteet poistettiin.
- Puuttuvien vaatimusten täyttämiseksi projektiryhmä laati korkean tason kenttätason dokumentaation Swaggerin avulla. Tämä jätti kuitenkin joitakin aukkoja hyväksyttävien tietomuotojen osalta, ja tästä keskusteltiin projektiryhmän kanssa, ja odotetut muodot sovittiin ja dokumentoitiin.
Päätelmä
API-pohjaiset sovellukset ovat kasvattaneet suosiotaan viime aikoina. Nämä sovellukset ovat skaalautuvampia kuin perinteiset sovellukset/ohjelmistot, ja ne on helpompi integroida muihin API-ohjelmiin tai sovelluksiin.
Tässä API-testausoppaassa selitetään yksityiskohtaisesti kaikki API-testaus, Shift Left -testaus, verkkopalvelut ja web-rajapinnat. Tutustuimme myös verkkopalvelujen ja web-rajapintojen välisiin eroihin esimerkkien avulla.
Ohjeen toisessa osassa käsittelimme API-testauksen koko kirjoa, sitä, miten API-testauksen voi ottaa käyttöön organisaatiossasi, ja joitakin yleisiä haasteita tässä prosessissa sekä ratkaisuja niihin.
Tutustu tulevaan opetusohjelmaamme saadaksesi lisää tietoa Web Services -palveluista esimerkkien kera!!!
Seuraava opetusohjelma