Mitä on käyttöliittymätestaus? Tyypit ja esimerkki

Mitä on käyttöliittymätestaus?

Käyttöliittymän testaus määritellään ohjelmistotestaustyypiksi, joka varmistaa, että kahden eri ohjelmistojärjestelmän välinen kommunikaatio toimii oikein.

Kahden komponentin yhdistävää yhteyttä kutsutaan rajapinnaksi. Tietokonemaailmassa tämä rajapinta voi olla mikä tahansa, kuten API, web-palvelu jne. Näiden yhdistävien palveluiden tai rajapintojen testausta kutsutaan rajapintatestaukseksi.

Käyttöliittymä on itse asiassa ohjelmisto, joka koostuu komentojoukoista, viesteistä ja muista attribuuteista, jotka mahdollistavat viestinnän laitteen ja käyttäjän välillä.

Tärkeää on, että käyttöliittymällä on haittapuolitract: sovittu pyyntömuoto, sovittu vastausmuoto, sovittu virhekoodien joukko ja sovittu aikakatkaisu. Rajapintatestausharjoitukset, jotkatracmolemmilta puolilta, joten yhden tiimin tekemä muutos ei hiljaa riko toista. Koska suurin osa tästä liikenteestä ei koskaan päädy näytölle, sen löytämät viat ovat näkymättömiä muille musta ruutu testaus suoritetaan pelkästään käyttöliittymän kautta.

Kuinka tehdä käyttöliittymätestaus

Käyttöliittymätestaus sisältää kahden pääsegmentin testauksen:

1. Verkkopalvelimen ja sovelluspalvelimen käyttöliittymä
2. Sovelluspalvelin ja tietokantapalvelinliittymä.

Yllä mainituissa skenaarioissa käyttöliittymätestaus suoritetaan

• Tarkista, että palvelimet suoritetaan oikein vai ei
• Virheet käsitellään oikein tai ne palauttavat virheilmoituksen kaikista sovelluksen tekemistä kyselyistä
• Tarkista tulokset, kun yhteys verkkopalvelimeen nollataan välillä

Alla oleva kaavio näyttää nämä kaksi segmenttiä yhtenä ketjuna, jossa selain kommunikoi web-palvelimen kanssa, web-palvelin kommunikoi sovelluspalvelimen kanssa ja sovelluspalvelin kommunikoi tietokantapalvelimen kanssa.

Käytännössä testaaja käy läpi kyseisen ketjun yhden hypyn kerrallaan. Jokainen hyppy ajetaan ensin kelvollisen pyynnön kanssa, sitten väärin muotoillun pyynnön kanssa ja lopuksi pyynnön etäpään ollessa tarkoituksella poissa käytöstä, jolloin sekä onnistumis- että epäonnistumispolku tallennetaan samaan polkuun. testitapaus.

Esimerkki käyttöliittymätestauksesta

Oletetaan, että mille tahansa xyz-sovellukselle rajapinta ottaa XML tiedosto syötteenä ja toimittaa JSON tiedosto tulosteena. Sovelluksen käyttöliittymän testaamiseksi tarvitaan vain XML- ja JSON-tiedostomuotojen määritykset.

Näiden spesifikaatioiden avulla voimme luoda XML-syötetiedostomallin ja syöttää sen käyttöliittymään. Syöte- (XML) ja tuloste- (JSON) tiedostojen validointi vaatimusten mukaisesti on käyttöliittymätestaus.

Huomaa, mitä esimerkki ei tarvitse: ei näyttöä, ei käyttöliittymän rakennetta eikä rajapinnan sisäisen koodin tuntemusta. Kaksi formaattispesifikaatiota riittää testien kirjoittamiseen, minkä vuoksi rajapinnan testaus voi alkaa jo kauan ennen käyttöliittymän olemassaoloa.

Miksi käyttöliittymätestaus

Käyttöliittymätestaus on tehty

• Sen varmistamiseksi, että loppukäyttäjät tai asiakkaat eivät kohtaa ongelmia käyttäessään tiettyä ohjelmistotuotetta
• Tunnistaa, mitä sovellusalueita loppukäyttäjät yleensä käyttävät, ja tarkistaa myös sen käyttäjäystävällisyys.
• Turvallisuusvaatimusten tarkistaminen järjestelmien välisen tiedonsiirron aikana
• Tarkistaa, pystyykö ratkaisu käsittelemään verkkohäiriöitä sovelluspalvelimen ja verkkosivuston välillä

Myös kustannusperustelut ovat olemassa. Pyyntömuodon virheen korjaaminen on halpaa, kun järjestelmiä vielä yhdistetään, ja kallista, kun alajuoksujärjestelmä on jo tallentanut virheellisesti muotoillut tiedot.

Liitäntätestauksen tyypit

Käyttöliittymätestauksen aikana rajapinnalle tehdään erilaisia ​​testejä, joihin voi sisältyä

• Työnkulku: Se varmistaa, että käyttöliittymämoottori käsittelee normaalit työnkulkusi odotetulla tavalla.
• Reunatapaukset - odottamattomat arvot: Tämä otetaan huomioon, kun testaus sisältää päivämäärän, kuukauden ja päivän käänteisenä.
• Suorituskyky-, kuormitus- ja verkkotestaus: Suuren volyymin käyttöliittymä saattaa vaatia enemmän Kuormitustesti kuin pienen volyymin liitäntä, riippuen liitäntämoottorista ja yhteysinfrastruktuurista
• Yksittäiset järjestelmät: Tämä sisältää jokaisen järjestelmän testaamisen erikseen. Esimerkiksi vähittäiskaupan laskutusjärjestelmän ja varastonhallintajärjestelmän pitäisi pystyä toimimaan erikseen.

Ensimmäinen kohde on tarpeeksi lähellä työnkulun testaus käyttää uudelleen skenaarioitaan, ja viimeinen kohta on päällekkäinen moduulitestauskoska järjestelmä, joka vikaantuu itsestään, vikaantuu uudelleen, kun se on kytketty uudelleen.

Käyttöliittymän testausstrategia

Rajapintatestausstrategia on menetelmä, jota käytetään rajapintojen testaamiseen yleisillä testeillä toteutuksesta riippumatta. Voimme käyttää abs-arvoatract testitapauksia ja luo konkreettisia instansseja testitapauksesta kullekin rajapintatestausstrategian toteutukselle. Perus/abstract-testitapaukset suorittavat toteutusneutraaleja testejä, kun taas konkreettiset testit huolehtivat testattavien objektien instanssien luomisesta ja toteutuskohtaisten testien suorittamisesta.

Tämän rakenteen tuoma hyöty on uudelleenkäyttö. Kun sama rajapinta toteutetaan kolmannen kerran, abstract-paketti suoritetaan sitä vasten muuttumattomana, ja vain instanssikoodi tarvitsee kirjoittaa. Samaa ideaa sovelletaan suuremmassa mittakaavassa komponenttien testaus, jossa jaettu huijaustract-sviittiä ajetaan kaikkia komponentteja vastaan, jotka väittävät täyttävänsä sen.

Rajapintatestaustyökalut

Koska käyttöliittymässä ei ole näyttöä, työkalujen on muodostettava pyynnöt suoraan ja tehtävä vaatimuksia raakavastausten perusteella. Tiimit yhdistävät yleensä kolmenlaisia ​​työkaluja.

• API-asiakasohjelmat ja pyyntöjen rakentajat: Työkalut, kuten Postman, SoapUI, Insomnia ja Hoppscotch lähettävät REST-, SOAP- tai GraphQL-kutsuja, tallentavat ne uudelleenkäytettäviksi kokoelmiksi ja käyttävät argumentteja tilakoodeissa, otsikoissa ja vastausrungoissa.
• Code-tason testikirjastot: Olemassa olevan testipaketin sisällä toimivat kirjastot mahdollistavat rajapintatarkistusten suorittamisen yksikkötestien rinnalla ja niiden suorittamisen jokaisella koontiversiolla, mikä estää niitä vanhenemasta.
• Kuormitus- ja protokollatyökalut: Työkalu, kuten JMeter ajaa samaa rajapintaa äänenvoimakkuudella, mikä tekee toiminnallisesta tarkistuksesta suorituskyvyn testaus yhteydestä.
• Palveluiden virtualisointi ja mallit: Kaukopään tilalla oleva tynkä mahdollistaa toisen puolen testaamisen, kun toinen puoli on käytettävissä, keskeneräinen tai liian kallis toistuvasti soitettavaksi.

Valinnalla on vähemmän merkitystä kuin kattavuudella. Riippumatta siitä, mikä asiakasohjelma valitaan, pyyntöjen kokoelma on tallennettava versionhallintaan koodin rinnalle, joten rajapinnan muutos ja sen testien muutos saapuvat samaan commit-tiedostoon. Laajemman kategorian yksityiskohdat käsitellään kohdassa API-testaus.

Rajapintatestauksen tarkistuslista ja parhaat käytännöt

Lyhyt tarkistuslista pitää rajapintojen kattavuuden rehellisenä eri versioissa. Käy se läpi jokaiselle yhteydelle erikseen koko sovelluksen sijaan.

• kanssatracensin: Varmista, että pyyntö- ja vastausmallit vastaavat julkaistua määritystä kenttä kentältä, mukaan lukien tietotyypit ja valinnaiset kentät.
• Raja-arvot: Lähetä tyhjiä hyötykuormia, enimmäispituisia kenttiä, odottamattomia merkistöjä ja käänteisiä päivämäärämuotoja.
• Virhepolut: Varmista, että jokainen virhe palauttaa merkityksellisen koodin ja viestin pinon sijaan tractai hiljainen menestys.
• Aikakatkaisut ja uudelleenyritykset: Keskeytä yhteys pyynnön aikana ja varmista, että soittaja yrittää uudelleen turvallisesti toistamatta tapahtumaa.
• Turvallisuus: Tarkista linkin todennus, valtuutus ja salaus ja varmista, että virheilmoitukset eivät vuoda sisäisiä tietoja.
• Tietojen johdonmukaisuus: Lue tietue takaisin toiselta puolelta ja varmista, ettei mitään katkaistu, koodattu uudelleen tai järjestetty uudelleen kuljetuksen aikana.
• Volume: Toista eniten liikennettä saanut kutsu samanaikaisen kuormituksen alaisena ja tarkkaile yhteyspoolin loppumista.

Kolme käytäntöä tekee tästä tarkistuslistasta toistettavan. Ensinnäkin, automatisoi testipaketti ja suorita se jokaisella koontiversiolla, koska käyttöliittymät muuttuvat hiljaisemmin kuin näytöt. Toiseksi, kirjaa koko pyyntö ja vastaus jokaisesta virheestä, koska käyttöliittymävirhettä on lähes mahdotonta toistaa kuvakaappauksesta. Kolmanneksi, pidä testipaketti riippumattomana muiden testipakettien luomasta testidatasta, jotta virhe viittaa käyttöliittymään eikä puuttuvaan tietueeseen.

Nämä tarkistukset sopivat luonnollisesti yhteen laajemman suunnitelman kanssa, jota kuvataan kohdassa ohjelmistotestauksen tyypit, ja ne suoritetaan ennen kuin samat yhteydet on harjoitettu päästä päähän aikana järjestelmän testaus.

Käyttöliittymätestaus vs integraatiotestaus

Nämä kaksi termiä liittyvät toisiinsa pikemminkin kuin ovat vastakkain: rajapintatestaus on integraatiotyön osa, joka keskittyy itse yhteyteen. Alla oleva taulukko osoittaa kummankin puolen painotukset.

Jokainen, joka on uusi laajemmalle tieteenalalle, löytää ympäröivät tasot, jotka on kuvattu kohdassa integraatiotestaus ja yleisesti ottaen ohjelmistojen testaus johdanto, kun taas yllä käytetty terminologia on peräisin standardista ohjelmistotuotanto harjoitus. Selainpohjaisissa järjestelmissä samoja yhteyksiä harjoitetaan lopulta uudelleen harjoituksen aikana. verkkosovellusten testaus.

UKK