Käyttöliittymien testaus on tärkeämpää kuin koskaan aiemmin, mikä johtuu verkkosivustojen ja sovellusten yleistymisestä ja hyperautomaation suuntauksesta (Gartnerin mukaan kaikki, mikä voidaan automatisoida, automatisoidaan). Jos olet ottamassa käyttöön uutta ohjelmistoa tai verkkosivua, on ratkaisevan tärkeää, että käyttöliittymä (UI) on oikea, jotta toiminnallisuus ja estetiikka ovat tasapainossa.
Vakuuttavaa käyttöliittymää luotaessa on paljon tehtävää, ja käyttöliittymän testaaminen toimii lakmustestinä, jolla määritetään, onko käyttöliittymä osunut kaikkiin kohtiin vai ei.
Tässä artikkelissa käymme läpi kaikki käyttöliittymän testaukseen liittyvät keskeiset osa-alueet käyttöliittymän määrittelystä parhaimpiin tapoihin testata käyttöliittymää.
UI vs. GUI: Sekaannuksen selvittäminen
Yritetään aluksi selvittää käsitteisiin UI ja GUI liittyvät epäselvyydet. Seuraavassa selvitetään, mitä nämä kaksi termiä tarkoittavat ja missä ne eroavat toisistaan:
1. Mitä on käyttöliittymän testaus?
Käyttöliittymä eli UI on alusta, jota käytät vuorovaikutuksessa tietyn ohjelmiston kanssa. Käyttöliittymä on paikka, johon saatat syöttää ohjeita, syöttää tietoja tai tarkastella tietoja näytöltä tai näytöltä.
Käyttöliittymiä on monenlaisia, kuten graafisia käyttöliittymiä (GUI) ja komentorivikäyttöliittymiä, joissa näytetään vain koodia ja tekstiä.
2. Mikä on graafinen käyttöliittymä (GUI)?
Graafinen käyttöliittymä (GUI) on useimmille tuttu käyttöliittymätyyppi. Se on eräänlainen käyttöliittymä, jossa käytetään visuaalisia keinoja, jotka auttavat meitä toimimaan vuorovaikutuksessa järjestelmän ominaisuuksien kanssa.
Voit esimerkiksi käyttää valikoita tai työkalurivejä, joissa on kuvakkeita, joiden avulla voit navigoida järjestelmässä. Jopa teksti toimii hyvin graafisissa käyttöliittymissä keinona opastaa käyttäjää toiminnon läpi, esimerkiksi klikkaamalla “tiedosto”, kun haluat avata tai tallentaa asiakirjan.
3. UI vs. GUI
Jotta ymmärtäisit paremmin näitä kahta tietokonevuorovaikutuksen muotoa, katso alla olevaa suoraa vertailua UI:n ja GUI:n välillä:
UI:
– Lyhenne sanoista user interface
– Se on eräänlainen alusta, jonka avulla käyttäjät voivat olla vuorovaikutuksessa laitteiden kanssa.
– Se on eräänlainen ihmisen ja koneen vuorovaikutuksen muoto.
– Kaikki käyttävät sitä, ja se toimii usein taustalla, joten et huomaa käyttäväsi sitä.
– Yleisiä esimerkkejä ovat MS-DOS tai Unix
GUI:
– Lyhenne sanoista graphical user interface (graafinen käyttöliittymä)
– Se on alustatyyppi, joka käyttää grafiikkaa auttaakseen käyttäjiä navigoimaan laitteen toiminnoissa.
– Se on UI
– Sitä käyttävät tyypillisesti tavalliset, jokapäiväiset käyttäjät, kuten kuluttajat.
– Yleisiä esimerkkejä ovat Windows 10, iOS ja Android
Mitä on käyttöliittymän (UI) testaus?
Käyttöliittymän (UI) testaaminen, joka kontekstista riippuen tunnetaan joskus myös nimellä GUI-testaaminen, on sarja toimia, joilla mitataan sovelluksen visuaalisten elementtien suorituskykyä ja yleistä toimivuutta. Se tarkastaa ja validoi käyttöliittymän eri toiminnot ja varmistaa, ettei käyttöliittymässä ole odottamattomia tuloksia, vikoja tai virheitä.
Käyttöliittymän testausta ZAPTESTin kaltaisilla työkaluilla käytetään ensisijaisesti käytettävyyden, toiminnallisuuden ja suorituskyvyn tarkistamiseen, jotta voidaan varmistaa, että käyttöliittymä on tarkoituksenmukainen.
Joissain tapauksissa tarkistetaan myös, että se on esimerkiksi järjestelmän yleisten suunnittelukonseptien mukainen tai visuaalisesti yhtenäinen.
Milloin ja miksi käyttöliittymätestejä tarvitaan?
Käyttöliittymän testaaminen on yleensä tehokkainta ennen sovelluksen julkaisemista tuotantoon. Näin varmistetaan, että loppukäyttäjä saa parhaan käyttökokemuksen ja että virheitä ja puutteita on mahdollisimman vähän.
Loppukäyttäjät eivät ole parhaita ohjelmistotestaajia, joten on tärkeää, että ongelmat korjataan ennen kuin ne ehtivät heidän luokseen.
Käyttöliittymätestaus on hyödyllinen tapa arvioida, miten sovellus suhtautuu tiettyihin toimintoihin, kuten näppäimistön ja hiiren käyttämiseen valikoissa. Sen avulla voidaan tarkistaa sovelluksen visuaaliset elementit ja varmistaa, että ne näkyvät oikein.
Käyttöliittymän testaus on myös hyvä tapa arvioida suorituskykyä ja varmistaa, ettei sovelluksen toiminnallisuudessa ole vikoja tai ongelmia.
Käyttöliittymätestien tyypit
Testattavasta sovelluksesta riippuen on olemassa useita erilaisia käyttöliittymätestejä.
Käyttöliittymätesteillä voidaan todentaa monia toimintoja eri sovelluksissa, joten oikean testityypin valinta voi auttaa tunnistamaan tiettyjä ongelmia.
Toisin sanoen on olemassa erilaisia käyttöliittymätestausmenetelmiä ja työkaluja, kuten ZAPTESTin RPA-ohjelmisto ja automatisoidut käyttöliittymätestausvälineet, joita kannattaa harkita sen mukaan, mitä aiot testata.
Joitakin yleisimpiä toiminnallisen ja ei-toiminnallisen testauksen lähestymistapoja ovat seuraavat:
1. Regressiotestaus
Regressiotestaus on eräänlainen käyttöliittymätestaus, jossa tarkastellaan sovelluksen tai verkkosivuston koodaukseen tehtyjä muutoksia.
Se varmistaa, että kaikki sovelluksen toiminnot ovat suunnitellun mukaisia, kun koodin osiin on tehty muutoksia.
Sen ei tarvitse tehdä mitään hienoja testejä, se vain ajaa koodin varmistaakseen, että kaikki riippuvuudet ja toiminnot toimivat samalla tavalla kuin ennen muutoksia.
2. Toiminnallinen testaus
Toiminnallisella testauksella pyritään validoimaan sovellus ja varmistamaan, että se täyttää kaikki toiminnalliset vaatimukset.
Se testaa kaikki sovelluksen yksittäiset toiminnot ja tarkistaa sitten tuloksen varmistaakseen, että se toimii odotetulla tavalla.
Tämäntyyppinen käyttöliittymätestaus keskittyy yleensä mustan laatikon testaukseen, jossa ei tarkastella lähdekoodia. Toiminnallisessa testauksessa tarkastetaan yleensä sellaisia asioita kuin käyttöliittymä, siihen liittyvät sovellusrajapinnat, asiakkaan ja palvelimen välinen viestintä tai tietoturva.
3. Hyväksymistestaus
Hyväksymistestaus, joka tunnetaan joskus nimellä User Acceptance Testing (UAT), on käyttöliittymän testauksen muoto, jonka sovelluksen loppukäyttäjä suorittaa järjestelmän tarkistamiseksi ennen tuotantoon siirtymistä.
Tämäntyyppinen käyttöliittymätestaus on useimmiten testauksen loppuvaiheessa, kun muut osa-alueet on tarkistettu.
Hyväksymistestauksen avulla validoidaan sovelluksen kokonaisvirtaus alusta loppuun. Se ei tarkastele pintatason asioita, kuten kirjoitusvirheitä tai esteettisiä ongelmia. Se käyttää erillistä testausympäristöä jäljittelemään tuotantoympäristöä ja varmistaa, että se on valmis siirtymään seuraavaan vaiheeseen.
4. Yksikkötestaus
Yksikkötestauksessa tarkastetaan sovelluksen yksittäiset osat sen varmistamiseksi, että se toimii tarkoitetulla tavalla.
Se suoritetaan yleensä koodausvaiheessa, joten tämäntyyppisen käyttöliittymätestin suorittaminen on yleensä kehittäjien ja heidän käyttöliittymätestityökalujensa tehtävä.
Yksikkötestaus toimii erottelemalla koodinpätkä toisistaan ja varmistamalla, että se toimii odotetulla tavalla. Tämä yksittäinen koodinpätkä voi olla tietty moduuli, funktio, objekti tai mikä tahansa muu yksittäinen sovelluksen osa.
5. Suorituskyvyn testaus
Suorituskyky- ja kuormitustestien avulla arvioidaan sovelluksen optimointia ja tarkastellaan esimerkiksi sovelluksen nopeutta, vakautta, reagointikykyä ja skaalautuvuutta käytön aikana.
Tämäntyyppisellä käyttöliittymätestauksella pyritään löytämään sovelluksen ongelmakohtia tai pullonkauloja tietovirrassa. Suorituskyvyn testaustyökalut tarkastelevat kolmea pääaluetta: sovelluksen nopeutta, skaalautuvuutta ja vakautta.
6. GUI-testaus
GUI-testaustyökalut tarkastavat sovelluksen graafisen käyttöliittymän varmistaakseen, että kaikki toiminnot toimivat odotetulla tavalla.
Tähän sisältyy sovelluksen graafisten ominaisuuksien ja hallintalaitteiden, kuten painikkeiden, työkalurivien ja kuvakkeiden tarkastelu. GUI on se, mitä loppukäyttäjä näkee ja on vuorovaikutuksessa sovellusta käyttäessään.
Mitä hyötyä UI-testauksesta on?
Käyttöliittymän testaukseen ja ZAPTESTin käyttöliittymätestauspaketin kaltaisten työkalujen käyttöön liittyy useita etuja sekä kehittäjän että loppukäyttäjän kannalta.
Alla on lueteltu joitakin tärkeimpiä käyttöliittymätestaukseen liittyviä etuja:
1. Se parantaa toiminnallisuutta
On tärkeää testata sovelluksia sen varmistamiseksi, että ne toimivat odotetulla tavalla, jotta mahdolliset häiriöt, viat tai muut ongelmat voidaan korjata ennen julkaisua.
Jos sovellus päätyy loppukäyttäjille ja se on buginen, täynnä virheitä tai rikkinäinen, se ei tee sitä työtä, jota siltä odotetaan. Tämä puolestaan aiheuttaa liikaa ongelmia loppukäyttäjille, ja he todennäköisesti lopettavat sen käytön.
2. Se helpottaa käyttöä
Käyttöliittymän testauksen automatisointityökalut ovat myös hyödyllinen tapa optimoida ja virtaviivaistaa sovellusta.
Vaikka kaikki koodaus toimisikin niin kuin pitääkin, huonosti suunniteltu käyttöliittymä voi hämmentää loppukäyttäjiä ja käännyttää heidät nopeasti pois, mikä vähentää sovelluksen käyttöönottoa. Käyttöliittymän testaaminen on hyvä tapa korjata elementtejä tai suunnitteluvalintoja niin, että niitä on helpompi käyttää.
3. Se vahvistaa sovelluksen mainetta
Kun käytät aikaa käyttöliittymän testaamiseen ja otat käyttöön ZAPTESTin testausautomaatio-ohjelmiston kaltaisia työkaluja, voit hioa sovellusta ja tehdä siitä mahdollisimman käyttäjäystävällisen.
Oikein tehtynä se tekee sovelluksesta loistavan brändilähettilään, mikä parantaa sen yleistä mainetta. Jos sovellus toimii virheettömästi ja tekee kaiken sen, mitä sen on tarkoitus tehdä, käyttäjät arvostavat sitä ja käyttävät sovellusta.
Mitkä ovat käyttöliittymätestauksen tärkeimmät haasteet?
Vaikka käyttöliittymän testaus on tärkeä osa sovelluskehitystä, se ei välttämättä ole helppo osa prosessia.
Ilmaisiin UI-testien automatisointiohjelmistoihin liittyy useita ongelmia ja haasteita, jotka tekevät siitä vaikean työn.
Alla on lueteltu joitakin tärkeimpiä käyttöliittymätestaukseen liittyviä haasteita, kun käytetään riittämättömiä käyttöliittymätestaustyökaluja:
1. UI-päivitykset
Sovelluskehitys on tyypillisesti iteratiivinen prosessi, joka tuo uusia ominaisuuksia ja toimintoja koko kehityssyklin ajan ja sen jälkeen.
Kaikki nämä satunnaiset muutokset voivat vaikeuttaa käyttöliittymätestien tehokasta suorittamista, sillä muut riippuvuudet ja koodin vuorovaikutus muuttavat testattavaa.
2. Testaus, jonka monimutkaisuus kasvaa
Sovellukset ja verkkosivustot ovat nykyään paljon kehittyneempiä kuin vielä muutama vuosi sitten. Kaikkien näiden lisätoimintojen myötä käyttöliittymän testaustyökalujen ja käyttöliittymäautomaatio-ohjelmistojen on tarkasteltava entistä enemmän elementtejä ja prosesseja.
Tämän seurauksena monia käyttöliittymätestauksen työkaluja on mukautettava, jotta ne pystyvät ottamaan huomioon kaikki nämä monimutkaiset lisäykset.
3. Aikarajoitteet
Sovellusten monimutkaistuessa myös testauksessa käytettävät työkalut kasvavat. Käyttöliittymän testausskripteistä on tulossa paljon aikaa vievämpiä, koska testattavan koodin määrä on valtava. Ongelma pahenee, kun käytettävissä ei ole oikeita käyttöliittymän testaustyökaluja.
4. Käyttöliittymäkomentosarjojen pitäminen ajan tasalla.
Kun käyttöliittymä muuttuu ja uusia toimintoja otetaan käyttöön, testiskriptejä on mukautettava uusien prosessien testaamiseksi. Tästä tulee haastavampaa jokaisen uuden lisäyksen myötä, sillä testiskriptejä päivitetään ja muokataan jatkuvasti uusien toimintojen mukaan.
Pitäisikö käyttöliittymätestaus automatisoida?
Kun on päätettävä, mikä on paras lähestymistapa mobiilisovelluksen tai web-käyttöliittymän testaukseen, on kaksi eri vaihtoehtoa – manuaalinen testaus tai automatisoitu käyttöliittymän testaus automaattisilla työkaluilla. Sekä manuaalisella testauksella että käyttöliittymäautomaatiolla on omat hyötynsä ja haittansa, joten on viisasta harkita molempia, jotta nähdään, kumpi sopii parhaiten sovellukseen.
Mitä on manuaalinen käyttöliittymän testaus?
Toisin kuin käyttöliittymäautomaatiossa, manuaalisessa testauksessa testaaja on manuaalisesti vuorovaikutuksessa sovelluksen tai verkkosivuston kaikkien ominaisuuksien kanssa ja tarkastaa ne.
Niiden ensisijainen tarkoitus on etsiä kysymyksiä, sääntöjenvastaisuuksia tai ongelmia koko hakemuksessa. Tämä on erityisen hyödyllinen vaihtoehto pienemmille sovelluksille, joissa on rajoitetusti elementtejä, kuten sovellusten varhaisissa versioissa.
1. Käyttöliittymän manuaalisen testauksen edut
Manuaalisen käyttöliittymän testauksen valinnalla on monia etuja sovelluksesta ja sen suunnittelusta riippuen.
Alla on lueteltu joitakin käyttöliittymän manuaaliseen testaukseen liittyviä etuja:
– Manuaalisessa käyttöliittymän testauksessa testaukseen käytetään ihmisen älykkyyttä virheiden tai ongelmien etsimiseen. On asioita, joita automatisoitu käyttöliittymätestaus ei yksinkertaisesti pysty suorittamaan, ja kaikkien sovelluksen puutteiden löytäminen vaatii inhimillistä vuorovaikutusta, kriittistä ajattelua ja inhimillistä elementtiä.
– Automatisoidut testit voivat olla melko aikaa vieviä, koska niissä luodaan uudelleen useita eri ominaisuuksia koskevia skenaarioita, jotka ihmistestaajan on tarkistettava. Manuaalisen käyttöliittymätestauksen ansiosta testaajat voivat keskittyä virheiden etsimiseen emulaatioiden luomisen sijaan.
– Ihmistestaajat tuntevat sovelluksen yleensä hyvin ja käyttävät usein lukemattomia tunteja käyttöliittymään tottumiseen. Tämän vuoksi he ymmärtävät, mitä virheitä on varottava, ja samalla he pysyvät ajan tasalla sovelluksen nykytilasta.
– Automaattinen käyttöliittymätestaus ei välttämättä havaitse tiettyjä ongelmia, koska ne eivät vaikuta koodiin. Palvelimen vasteajat saattavat olla hitaita, mutta automaattinen testi voi helposti jättää ne huomiotta. Manuaalinen käyttöliittymätestaus poistaa tämän ongelman, koska ihmiskäyttäjä huomaa nämä ongelmat välittömästi.
– Manuaalinen käyttöliittymätestaus on tarkin jäljitelmä käyttäjäkokemuksesta, koska asetat tilanteen, joka heijastaa sitä, miten loppukäyttäjä toimii sovelluksen kanssa. Näin luodaan reaalimaailman konteksti sellaisten ongelmien löytämiseksi, jotka loppukäyttäjät havaitsevat yleisesti, mutta jotka saattavat jäädä huomaamatta automaattisessa käyttöliittymätestauksessa.
2. Manuaalisen käyttöliittymätestauksen rajoitukset
Manuaalisessa käyttöliittymän testauksessa on myös rajoituksia, jotka on otettava huomioon, ennen kuin teet päätöksen sovelluksesi parhaasta testausmenetelmästä.
Manuaalisten käyttöliittymätestien rajoituksia ovat muun muassa seuraavat:
– Manuaalisen testauksen suorittaminen kestää paljon kauemmin kuin automaattisen käyttöliittymätestauksen tekeminen, etenkin kun käytetään nykyaikaisia työkaluja, kuten hyperautomaatiota. Automaattisen testauksen skriptit voivat toimia paljon nopeammin kuin minkäänlainen inhimillinen panos, joten manuaalisen web-käyttöliittymän testauksen valitseminen lisää aikatauluun lisätunteja.
– Koska se on viime kädessä inhimillinen prosessi, manuaalinen web-käyttöliittymän testaus on altis inhimillisille virheille. Manuaalisessa käyttöliittymän testauksessa voi jäädä huomaamatta virheitä, jotka johtuvat keskittymisen puutteesta tai häiriötekijöistä, mikä voi johtaa ongelmiin. Vertailun vuoksi automaattinen käyttöliittymätestaus poistaa inhimillisen elementin prosessista, joten se on paljon vähemmän altis tämäntyyppisille ongelmille. Tämä pätee erityisesti uusimpiin käyttöliittymän automatisoidun testauksen tyyppeihin, kuten robottiprosessien automatisointiin.
– Löydettyjen virheiden kirjaaminen lokiin kestää paljon kauemmin, mikä voi vaikeuttaa muutosten seuraamista niiden tapahtuessa. Automatisoitu käyttöliittymätestaus on tässä parempi lähestymistapa, koska se vaatii päivitystä vain, jos uusi ominaisuus otetaan käyttöön.
– Manuaalinen käyttöliittymätestaus edellyttää sovelluksen perusteellista tuntemusta, jotta ongelmia voidaan testata asiantuntevasti. Tämän vuoksi ihmistestaajilta vaaditaan tietynlaista tietämystä, jotta he voivat testata tehokkaasti. Automatisoitu testaus ja RPA eivät vaadi tämäntasoista osaamista.
3. Tallenna ja toista testaus
Tallenna ja toista -testaus on kooditon käyttöliittymätestaus, jonka avulla voit suorittaa testejä ilman syvällistä ohjelmointitaitoa. Se käyttää toiminnallisuutta ja usein tietokonenäköteknologiaa tallentamaan sovelluksessa suoritetut manuaaliset toiminnot ennen niiden tallentamista testikuviona.
Tämän ansiosta käyttöliittymätesti voidaan suorittaa yhä uudelleen ilman ihmisen osallistumista.
4. Manuaalinen testaus vs. tallennus ja toisto vs. automaatiotestaus
Kun päätät näiden kolmen käyttöliittymätestityypin välillä, on tärkeää ottaa huomioon sovelluksen laajuus ja mittakaava sekä käytettävissä olevat resurssit.
Manuaalinen käyttöliittymätestaaminen on helpointa toteuttaa ja käyttää, mutta siihen liittyy paljon vaatimuksia, kuten testaajan hyvä tietämys sovelluksesta. Manuaalista käyttöliittymän testausta on myös vaikea jatkaa, jos sovellusta päivitetään jatkuvasti.
ZAPTESTin tarjoamien kaltaiset käyttöliittymän testauksen automatisointityökalut ovat hyvä vaihtoehto, jos sovellukseen tehdään säännöllisiä päivityksiä, ja ajan mittaan se kannattaakin, sillä ne omaksuvat ketteryyden periaatteet.
Record & replay -toiminnolla voidaan kuroa umpeen näiden kahden käyttöliittymätestaustyypin välinen kuilu. Se tarjoaa perustason käyttöliittymäautomaation, mutta sen käynnistäminen edellyttää silti ihmisen panosta.
Mitä testaat, kun teet käyttöliittymätestejä?
Se, mitä testataan, kun tehdään käyttöliittymätestejä ZAPTESTin käyttöliittymätestausohjelmiston kaltaisilla työkaluilla, vaihtelee sen mukaan, mitä sovellus sisältää.
Se noudattaa kuitenkin yleensä sovelluksen toiminnallisuutta. Jos sovelluksessa on esimerkiksi kassasivu, käyttöliittymätestaus sisältää esimerkiksi “osta nyt” -painikkeen testauksen.
Vaikka varsinaiset testattavat prosessit vaihtelevat sovelluksesta toiseen, on olemassa joukko yleisiä testattavia käyttöliittymäasioita, kuten:
1. Virheet tietotyypeissä
Tällä käyttöliittymätestillä varmistetaan, että oikeanlaiset tiedot toimivat asianmukaisissa kentissä. Esimerkiksi tekstiä nimiä varten ilman mahdollisuutta käyttää numeroita. Jos käyttöliittymän testaaja voi syöttää numeerisia arvoja nimikenttään, jokin on vialla.
2. Kentän leveyteen liittyvät kysymykset
Tätä käytetään tiettyjen kenttien, kuten postinumeroiden, merkkimäärän rajoittamiseen. Jos sovellus ei rajoita näiden kenttien merkkimäärää, loppukäyttäjä voi syöttää virheellisiä tietoja.
3. Painikkeet
Näillä käyttöliittymätesteillä varmistetaan, että painikkeet toimivat oikein, joten esimerkiksi Seuraava sivu -painike ohjaa loppukäyttäjän seuraavalle sivulle. On olemassa paljon erilaisia painiketyyppejä, joilla on erilaiset käyttötarkoitukset, joten on tärkeää, että ne tekevät tehtävänsä, jotta sovellus olisi toimiva.
4.Table vieritys
Jos sovelluksessa on taulukoita, joissa on tietoja, taulukoiden selaaminen varmistaa, että voit selata tietoja pitäen samalla otsikot näkyvissä.
Jos tämä ei toimi, loppukäyttäjä saa tiedot sekaviksi.
5. Virhelokit
Sovelluksen kaatumisen tai virheen sattuessa on tärkeää testata virhelokit, jotta voidaan varmistaa, että ne antavat tarkat tulokset vikailmoituksia varten.
Ilman tarkkoja vikailmoituksia ja virhelokeja ei ole mitään hyvää tapaa selvittää, mikä aiheuttaa ongelman tai miten se voidaan korjata.
Miten suoritetaan UI (GUI) -testi?
Jotta saisit hyvän käsityksen siitä, miten käyttöliittymä- eli GUI-testi tehdään, luomme esimerkin, jota voit tarkastella.
Oletetaan, että aiomme testata sovelluksen lomakesivua tilin rekisteröintiä varten. Tällä sivulla on useita testattavia käyttöliittymäelementtejä, jotka on merkitty TC-X:llä (jossa TC tarkoittaa testitapausta ja X elementin numeroa).
Alla on luettelo testattavissa olevista TC:istä:
TC-1: Tuotemerkin logo näytön yläreunassa.
– Tämä on testattava, jotta voidaan tarkistaa, että se näyttää oikean sijainnin, kirjasintyypin ja sivutunnisteen.
TC-2: Rekisteröi tilisi
– Tämän pitäisi testata, että sivun otsikko on tarkka.
– Sen pitäisi myös tarkistaa, että oikea fontti näkyy.
TC-3: Etunimikenttä
– Tämän pitäisi testata tekstilaatikon oikea kohdistus ja sijainti.
– Sen olisi myös testattava kenttien merkinnät ja tarkistettava, että se hyväksyy kelvolliset ja hylkää virheelliset merkinnät.
TC-4: Sukunimikenttä
– Tämän pitäisi testata tekstilaatikon oikea kohdistus ja sijainti.
– Sen olisi myös testattava kenttien merkinnät ja tarkistettava, että se hyväksyy kelvolliset ja hylkää virheelliset merkinnät.
TC-5: Käyttäjätunnus-kenttä
– Tämän pitäisi testata, mikä virheilmoitus näytetään, kun syötetään rajoitettuja merkkejä.
– Sen olisi myös tarkistettava, että virheilmoitus on pätevä ja tarkka.
TC-6: Salasanakenttä
– Tämän pitäisi testata kentän merkinnät varmistaakseen, että se hyväksyy kelvolliset merkit ja hylkää virheelliset merkit.
– Sen pitäisi myös testata tekstilaatikon kohdistus ja sijainti.
TC-7: Seuraava sivu -painike
– Tämän pitäisi testata, että lomakkeen lähettäminen toimii tarkoitetulla tavalla.
– Sen pitäisi myös tarkastaa painikkeen sijainti ja varmistaa, että se on käyttäjän luettavissa.
UI-testaussuunnitelma – Mikä se on?
Käyttöliittymän testaussuunnitelma on asiakirja, joka on osa sovellusten testausprosessia.
Käyttöliittymän testaussuunnitelmassa eritellään keskeiset tiedot sovelluksesta ja siihen liittyvistä testaustoiminnoista.
Testaussuunnitelman laatiminen on yleensä yksi ensimmäisistä vaiheista sovelluksia testattaessa, sillä se luo pohjan testausmenetelmille ja tavoitelluille tuloksille.
Se on hyödyllinen asiakirja, joka antaa testausryhmän ulkopuolisille paremman käsityksen siitä, mitä prosessissa tapahtuu. Jokaisella vakavasti otettavalla TCOE:llä(Testing Center of Excellence) on sellainen.
Kuinka kirjoittaa UI-testisuunnitelma
Käyttöliittymän testaussuunnitelmat tarjoavat erinomaista opastusta ja ohjeita käyttöliittymän testaajille, joten niiden tekeminen oikein auttaa todella paljon sovellusten testaamisessa ja tarkastamisessa.
Tutustu alla oleviin vaiheisiin, jotta opit kirjoittamaan käyttöliittymän testaussuunnitelman:
1. Sisällytä tärkeimmät tiedot käyttöliittymän testausta varten.
Käyttöliittymän testaussuunnitelma sisältää kaikki keskeiset tiedot, joita tarvitaan sovelluksen testaamiseen. Näihin tietoihin kuuluvat muun muassa seuraavat:
– testauksessa tarvittavat ammattilaiset, heidän roolinsa ja taitonsa.
– Sovelluksen testaamiseen tarvittava kokonaisaika.
– testauksessa käytettävät testaustekniikat ja testidatan hallintaprosessit.
– Kaikki testaukseen tarvittavat resurssit, kuten erityinen laitteisto, dokumentaatio tai työkalut.
– Kohteena olevien testiympäristöjen, kuten mobiililaitteiden, tietyn käyttöjärjestelmän tai selaimien, erittely.
– Testausprosessin yleiset tavoitteet.
2. Savutestaus
Seuraavaksi voit käyttää savutestausta apuna käyttöliittymän testaussuunnitelman luomisessa. Savutestaus on hyödyllinen tapa tunnistaa sovelluksen perusongelmat ja -virheet, mutta se ei etsi ongelmia liian syvältä.
Tämä tekniikka soveltuu parhaiten sovelluksen ylemmän kerroksen käyttöliittymätestaukseen, joten sillä voidaan havaita räikeät ongelmat melko helposti.
3. Vakavuustarkastus
Jos haluat kaivaa sovelluksen syvemmälle ja löytää vähemmän ilmeisiä vikoja ja puutteita, terveystestaus on loistava tekniikka käyttöliittymän testaukseen.
Terveystestauksessa tarkastetaan kaikki uusi tai muutettu koodaus sen varmistamiseksi, että se vastaa sovelluksen vaatimuksia.
Se eroaa savutestauksesta siinä, että se on paljon kattavampi käyttöliittymätestaus, joka mahdollistaa syvemmän katsauksen sovelluksen toiminnallisuuteen.
Kun sovellus on läpäissyt savutestin, terveystesti lisää ylimääräisen tarkastustason.
UI-testiskenaariot
Jotta voidaan varmistaa, että sovellus toimii tarkoitetulla tavalla useilla eri alueilla ja vuorovaikutustilanteissa, on tärkeää suorittaa erilaisia käyttöliittymätestiskenaarioita.
Alla on erittely ja esimerkki siitä, mitä UI-testiskenaariot ovat.
1. Mitä ovat käyttöliittymän testiskenaariot?
Käyttöliittymän testiskenaario on tapa luoda dokumentaatio sovelluksen useille käyttötapauksille.
Käyttöliittymätestiskenaariota käytetään kuvaamaan erityisiä toimia, joita käyttäjä voi tehdä sovellusta käyttäessään.
Joissakin tapauksissa se kuvaa myös skenaariota, jonka käyttäjä voi kokea sovellusta käyttäessään.
Käyttöliittymän testiskenaariot ovat hyödyllisiä, koska niillä varmistetaan, että sovelluksen toiminnot toimivat odotetulla tavalla. Hyödyllisten skenaarioiden luominen edellyttää sovelluksen syvällistä tuntemusta sekä asiakkaiden ja kehittäjien panosta.
2. Esimerkki käyttöliittymän testiskenaarioista
Tarkastellaan esimerkiksi sovelluksen kirjautumissivun testausskenaariota. Käyttöliittymän testiskenaariossa pyritään vastaamaan seuraaviin kysymyksiin:
– Voivatko käyttäjät kirjautua alustalle oikeilla tunnuksilla?
– Mitä seuraa, jos kirjaudut sisään väärillä tunnuksilla?
– Mitä tapahtuu, kun käytät kelvollista käyttäjätunnusta mutta virheellistä salasanaa?
– Mitä tapahtuu, kun jätät kentät tyhjiksi ja yrität kirjautua sisään?
– Jos salasanan unohtaminen -painike on olemassa, mitä tapahtuu, kun sitä napsautetaan?
– Toimivatko kaikki sivulla olevat linkit tarkoitetulla tavalla?
Näihin kysymyksiin vastaaminen auttaa käyttöliittymätestaajia tunnistamaan kaikki sovelluksen osat, jotka eivät toimi niin kuin pitäisi.
Se tarkistaa myös, että kaikki käytettävissä olevat toiminnot tuottavat odotetun tuloksen, kuten kirjautumisen oikeilla tunnuksilla.
UI-testitapaukset
Käyttöliittymän testausskenaarion yksittäisten osa-alueiden tarkastelemiseksi käytetään testitapauksia, joiden avulla voidaan pilkkoa sovelluksen toiminnallisuuden yksittäisiä ominaisuuksia.
Alla on yhteenveto siitä, mitä käyttöliittymän testitapaukset ovat, sekä esimerkkejä.
1. Mitä ovat käyttöliittymän testitapaukset?
Käyttöliittymän testitapaus on sarja toimintoja, jotka suoritetaan tietyn ominaisuuden tai toiminnallisuuden tarkistamiseksi sovelluksessa.
Käyttöliittymän testitapauksissa eritellään testivaiheet, tiedot, ennakkoehto ja jälkiehto tiettyjä skenaarioita varten, ja niissä tarkistetaan myös vaatimukset.
Käyttöliittymän testitapaukseen sisältyy yleensä hyvin tarkkoja muuttujia, jotka mahdollistavat syvällisen testauksen yksittäisellä tasolla. Tämän jälkeen käyttöliittymätestaajat vertaavat todellisia tuloksia odotettuihin tuloksiin varmistaakseen, että sovellus toimii vaatimusten mukaisesti.
2. Esimerkkejä käyttöliittymä- ja graafisen käyttöliittymän testitapauksista
Jotta ymmärtäisit paremmin käyttöliittymä- ja graafisen käyttöliittymän testitapauksia, katso alla olevia esimerkkejä, jotka ovat testitapauksia testiskenaariolle, jossa tarkastellaan kirjautumisnäytön toimivuutta:
– Tarkista, miten järjestelmä käyttäytyy, kun syötät voimassa olevia tunnistetietoja.
– Tarkista, miten järjestelmä käyttäytyy, kun käytetään virheellistä sähköpostiosoitetta mutta voimassa olevaa salasanaa.
– Tarkista, miten järjestelmä käyttäytyy, kun käytetään voimassa olevaa sähköpostiosoitetta mutta virheellistä salasanaa.
– Tarkista, miten järjestelmä käyttäytyy, kun käytetään virheellistä sähköpostiosoitetta ja salasanaa.
– Tarkista, miten järjestelmä käyttäytyy, kun kentät jätetään tyhjiksi.
– Tarkista ‘unohda salasana’ -linkki ja katso, toimiiko se odotetulla tavalla.
– Tarkista, miten järjestelmä käyttäytyy, kun “Pidä minut kirjautuneena sisään” -painike on valittuna.
– Tarkista, miten järjestelmä käyttäytyy, kun virheellinen puhelinnumero syötetään.
Kaikki nämä esimerkit ovat siis yksittäisiä käyttöliittymän testitapauksia.
Toisin kuin testausskenaario, joka kattaa koko prosessin, testitapaukset tarkastelevat yksittäisiä toimintoja. Toisin sanoen jokainen yllä oleva esimerkki on käyttöliittymän testitapaus, ja koko luettelo luokitellaan testausskenaarioksi.
UI-testiskriptit
Sovellustestauksen vielä yksityiskohtaisemman erittelyn saamiseksi luodaan käyttöliittymätestiskriptejä, jotka antavat testaajille lisätietoja testitapauksista ja -skenaarioista.
Seuraavassa on yhteenveto siitä, mitä käyttöliittymän testiskriptit ovat ja miten niitä kirjoitetaan.
1. Mitä ovat käyttöliittymätestiskriptit?
Käyttöliittymän testiskriptit ovat erittäin yksityiskohtaisia kuvauksia sovellukselle suoritettavista testeistä, yleensä riveittäin.
Ne ovat luonteeltaan hyvin yksityiskohtaisia ja sisältävät paljon yksityiskohtia käytettyjen testitapausten, tietojen ja sovelluksen odotetun toiminnallisuuden osalta.
Testitapausten mahdolliset tulokset sisällytetään myös testiskripteihin, mikä lisää tietojen monipuolisuutta.
2. Kuinka kirjoittaa UI-testiskriptejä
Käyttöliittymän testiskriptit ovat suoraviivaisia, koska niissä on vain yksityiskohtaiset tiedot testitapauksista.
Kunhan sisällytät niihin seuraavat tiedot, voit saada paljon hyötyä UI-testiskripteistäsi:
– Testisarjan ID: Tämä on testiskriptin yksilöllinen tunniste.
– Otsikko: Testiskriptin nimi.
– Testitapauksen ID: Tämä on sen testitapauksen ID, jolle luot skriptin.
– Vaatimukset: Vaatimukset: Nämä ovat testitapausten suorittamiseen tarvittavien laitteistojen määrittelyt.
– Menettely: Menettely: Nämä ovat vaiheet, joiden avulla testauksessa edetään.
– Tulos: Tämä on testauksen tulos ja lopputulos.
– Tilanne: Tämä on osoitus testiskriptin onnistumisesta – läpäisikö se vai ei?
– Virhekoodi: Jos ilmeni ongelma, virhekoodi kertoo yksityiskohtaisesti, mikä ongelma oli.
Tarkistuslista UI-testejä varten
Nyt kun olet valmis aloittamaan käyttöliittymätestauksen, voit luoda omat testisi alla olevan tarkistuslistan avulla:
1. Tarkista perustoiminnot
Toiminnallinen testaus on hyvä tapa löytää esimerkiksi visuaalisia vikoja tai häiriöitä alustassa.
Muista sisällyttää tässä vaiheessa esimerkiksi biometriset tiedot, mahdolliset viestit ja sovelluksen muistitiedot.
2. Tarkista alustojen välinen yhteensopivuus
Jotta vältyttäisiin ongelmilta, kuten laitteen pirstaleisuudelta, joka estää tiettyjä käyttäjiä käyttämästä sovellusta, on hyödyllistä tehdä alustojen välisiä yhteensopivuustarkastuksia.
Tähän sisältyy sovelluksen tarkistaminen eri näytön resoluutioilla.
On hyvä tutkia sekä natiivien että hybridisovellusten yhteensopivuutta mobiililaitteissa, kuten Androidissa ja iOS:ssä.
3. Tarkista yhteensopivuus eri näyttökokojen välillä
Loppukäyttäjät saattavat yrittää käyttää sovellusta monilla eri näytön kooilla, joten on tärkeää testata käyttöliittymä niille.
Käyttöliittymän reagointikyvyn testaus on parasta toteuttaa uusimmilla laitteilla, jotta mahdolliset ongelmat voidaan ratkaista. Muista myös testata sekä maisema- että muotokuvatilassa.
4. Tarkista suorituskyky ja skaalautuvuus
Kun sovellus on skaalautuva, se pystyy tarjoamaan erinomaista suorituskykyä eri alustoilla.
Testaa erilaisia kuormitustasoja, liikennettä ja muita loppukäyttäjäskenaarioita sovelluksen suorituskyvyn ja skaalautuvuuden arvioimiseksi.
Tämä voidaan tehdä käyttämällä rinnakkaista testausta, jossa käytetään automaattista käyttöliittymätestausta kuten robottiprosessien automatisointia useissa ympäristöissä.
5. Tarkista sovelluksen saavutettavuus
Esteettömyystestauksella varmistetaan, että loppukäyttäjien auttamiseen tarkoitetut erityispiirteet toimivat odotetulla tavalla. Tarkista täältä esimerkiksi fonttikoko, ruudunlukutila ja zoomausvaihtoehdot.
6. Tarkista värit ja teksti
Sovellusten pitäisi näyttää värit tietyllä tavalla, joten on tärkeää varmistaa tämä testaamalla värimalleja.
Tähän kuuluvat esimerkiksi hyperlinkkien väri tai muut kirjasintyypit. On myös hyödyllistä tarkistaa tekstin oikeinkirjoitus, fonttikoko ja rivitys.
7. Arvioi navigointinopeus
Varmista, että sovelluksen käyttöliittymä toimii sujuvasti ilman häiriöitä. Esimerkiksi otsikoiden latausruutu on hyvä paikka etsiä viivettä.
