Graafinen käyttöliittymän testaus - Graphical user interface testing
Vuonna ohjelmistotuotanto , graafisen käyttöliittymän testaus on prosessi testaa tuotteen graafinen käyttöliittymä (GUI), jotta se täyttää laatuvaatimukset. Tämä tapahtuu yleensä käyttämällä erilaisia testitapauksia .
Testitapausten luominen
Tuottamaan joukon testitapauksia , testi suunnittelijat yrittävät kattaa kaikki järjestelmän toiminnallisuus ja täysin käyttää GUI itse. Tämän tehtävän suorittamisen vaikeus on kaksi: käsitellä verkkotunnuksen kokoa ja sekvenssejä. Lisäksi testaaja joutuu kohtaamaan enemmän vaikeuksia, kun heidän on tehtävä regressiotestaus .
Toisin kuin CLI (komentoriviliittymä), käyttöliittymässä voi olla testattavia lisätoimintoja. Suhteellisen pienellä ohjelmalla, kuten Microsoft WordPad, on 325 mahdollista käyttöliittymäoperaatiota. Suuressa ohjelmassa operaatioiden määrä voi olla helposti suuruusluokkaa suurempi.
Toinen ongelma on sekvensointiongelma. Jotkin järjestelmän toiminnot voidaan saavuttaa vain GUI-tapahtumien sekvenssillä. Esimerkiksi tiedoston avaamiseksi käyttäjän on ensin napsautettava Tiedosto-valikkoa, sitten valittava Avaa-toiminto, määritettävä tiedostonimi valintaikkunan avulla ja kohdistettava sovellus vasta avattuun ikkunaan. Mahdollisten operaatioiden määrän lisääminen lisää sekvensointiongelmaa eksponentiaalisesti. Tästä voi tulla vakava ongelma, kun testaaja luo testitapauksia manuaalisesti.
Regressiotestaus on usein haaste myös käyttöliittymien kanssa. GUI voi muuttua merkittävästi, vaikka taustalla oleva sovellus ei. Testi, joka on suunniteltu seuraamaan tiettyä polkua graafisen käyttöliittymän kautta, saattaa tällöin epäonnistua, koska painike, valikkokohta tai valintaikkuna ovat saattaneet muuttaa sijaintia tai ulkonäköä.
Nämä ongelmat ovat ajaneet graafisen käyttöliittymän testauksen ongelmakohdan kohti automaatiota. On ehdotettu monia erilaisia tekniikoita täydellisten ja käyttäjien käyttäytymistä simuloivien testipakettien luomiseksi automaattisesti .
Suurin osa testaustekniikoista yrittää rakentaa aiemmin CLI-ohjelmien testaamiseen käytettyjä tekniikoita, mutta niillä voi olla skaalausongelmia, kun niitä käytetään käyttöliittymiin. Esimerkiksi Finite State Machine -pohjainen mallinnus - jossa järjestelmä mallinnetaan äärelliseksi tilakoneeksi ja ohjelmaa käytetään luomaan testitapauksia, jotka käyttävät kaikkia tiloja - voi toimia hyvin järjestelmässä, jolla on rajallinen määrä tiloja, mutta josta voi tulla liian monimutkainen ja vaivaton käyttöliittymälle (katso myös mallipohjainen testaus ).
Suunnittelu ja tekoäly
CLI-tekniikasta mukautettu uusi lähestymistapa testipaketin luomiseen edellyttää suunnittelujärjestelmän käyttöä. Suunnittelu on tekoälyn (AI) alueelta hyvin tutkittu tekniikka, joka yrittää ratkaista ongelmia, joihin liittyy neljä parametria:
- alkutila,
- tavoitetila,
- - joukko operaattoreita, ja -
- joukko esineitä käytettäväksi.
Suunnittelujärjestelmät määrittävät polun alkutilasta tavoitetilaan operaattoreiden avulla. Yksinkertaisena esimerkkinä suunnitteluongelmasta, kun annetaan kaksi sanaa ja yksi operaatio, joka korvaa yhden sanan kirjaimen toisella, tavoitteena voi olla yhden sanan vaihtaminen toiseksi.
Kirjoittajat käyttivät IPP-suunnittelijaa osoittamaan tätä tekniikkaa. Järjestelmän käyttöliittymä analysoidaan ensin mahdollisten toimintojen määrittämiseksi. Näistä tulee suunnitteluprobleemissa käytettyjä operaattoreita. Seuraavaksi määritetään järjestelmän alkuperäinen tila ja määritetään tavoitetila, jonka testaaja uskoo mahdollistavan järjestelmän käytön. Suunnittelujärjestelmä määrittää polun alkutilasta tavoitetilaan, josta tulee testisuunnitelma.
Suunnittelijan avulla testitapausten luomiseen on joitain erityisiä etuja manuaaliseen tuottamiseen verrattuna. Suunnittelujärjestelmä luonteensa vuoksi tuottaa ratkaisuja suunnitteluongelmiin tavalla, joka on erittäin hyödyllistä testaajalle:
- Suunnitelmat ovat aina voimassa. Järjestelmän tulos on joko kelvollinen ja oikea suunnitelma, joka käyttää operaattoreita tavoitetilan saavuttamiseen, tai ei lainkaan suunnitelmaa. Tämä on hyödyllistä, koska testipaketin luomisessa manuaalisesti voidaan hukata paljon aikaa virheellisten testitapausten takia, jotka testaaja ajatteli toimivan, mutta eivät.
- Suunnittelujärjestelmässä kiinnitetään huomiota järjestykseen. Usein tietyn toiminnon testaamiseksi testitapauksen on oltava monimutkainen ja seurattava tietä GUI: n läpi, jossa toiminnot suoritetaan tietyssä järjestyksessä. Kun se tehdään manuaalisesti, se voi johtaa virheisiin ja voi olla myös melko vaikeaa ja aikaa vievää.
- Ja mikä tärkeintä, suunnittelujärjestelmä on tavoitteellinen. Testaaja keskittyy testipaketin luomiseen tärkeimpään, testaa järjestelmän toimivuuden.
Kun luot testipaketin manuaalisesti, testaaja keskittyy enemmän toiminnon testaamiseen (ts. Tiettyyn polkuun käyttöliittymän kautta). Suunnittelujärjestelmää käyttämällä polku hoidetaan ja testaaja voi keskittyä testattavaan toimintoon. Tämän lisäetuna on, että suunnittelujärjestelmää ei rajoiteta millään tavalla polun muodostamisen yhteydessä ja se voi usein löytää polun, jota testaaja ei koskaan odottanut. Tämä ongelma on erittäin tärkeä taistella.
Toinen menetelmä GUI-testitapausten luomiseksi simuloi aloittelijaa. Järjestelmän asiantuntijakäyttäjä pyrkii seuraamaan suoraa ja ennustettavaa tietä graafisen käyttöliittymän kautta, kun taas aloitteleva käyttäjä seuraisi satunnaisempaa polkua. Aloitteleva käyttäjä tutkii todennäköisesti enemmän GUI: n mahdollisia tiloja kuin asiantuntija.
Vaikeus on luoda testipaketteja, jotka simuloivat "aloittelija" järjestelmän käyttöä. Käyttämällä geneettisiä algoritmeja on ehdotettu tämän ongelman ratkaisemiseksi. Aloittelijan polut järjestelmän läpi eivät ole satunnaisia polkuja. Ensinnäkin aloitteleva käyttäjä oppii ajan myötä eikä yleensä tee samoja virheitä toistuvasti, ja toiseksi aloitteleva käyttäjä seuraa suunnitelmaa ja hänellä on todennäköisesti jonkin verran toimialue- tai järjestelmätiedot.
Geneettiset algoritmit toimivat seuraavasti: joukko "geenejä" luodaan satunnaisesti ja alistetaan sitten jollekin tehtävälle. Geenit, jotka suorittavat tehtävän parhaiten, säilytetään ja ne, jotka eivät täytä, hylätään. Prosessi toistetaan jälleen jäljelle jääneiden geenien kanssa ja loput joukosta täytetään enemmän satunnaisilla geeneillä. Lopulta yksi geeni (tai pieni geeniryhmä, jos kynnysjoukkoa on) on ainoa geeni sarjassa ja sopii luonnollisesti parhaiten kyseiseen ongelmaan.
GUI-testauksen tapauksessa menetelmä toimii seuraavasti. Jokainen geeni on olennaisesti luettelo satunnaisista kokonaisluvuista, joiden pituus on kiinteä. Jokainen näistä geeneistä edustaa polkua GUI: n läpi. Esimerkiksi tietylle widget-puulle geenin ensimmäinen arvo (kutakin arvoa kutsutaan alleeliksi) valitsisi toimivan widgetin, seuraavat alleelit täyttävät sitten syötteen widgetiin mahdollisten syötteiden lukumäärän mukaan widgetiin (esimerkiksi pudotusluetteloruudussa olisi yksi syöttö… valittu luetteloarvo). Geenien menestys arvioidaan kriteerillä, joka palkitsee parhaan 'aloittelijan' käyttäytymisen.
Järjestelmä tämän testauksen suorittamiseksi X-ikkunajärjestelmälle, mutta laajennettavissa mihin tahansa ikkunointijärjestelmään, on kuvattu kohdassa. X-ikkuna- järjestelmä tarjoaa toiminnallisuuden ( XServerin ja toimittajien protokollan kautta) GUI-syötteen dynaamiseen lähettämiseen ja GUI-ulostulon saamiseksi ohjelmasta käyttämättä suoraan käyttöliittymää. Esimerkiksi, voidaan kutsua XSendEvent () simuloida napsautusta alasvetovalikossa ja niin edelleen. Tämän järjestelmän avulla tutkijat voivat automatisoida geenien luomisen ja testaamisen, joten mihin tahansa testattavaan sovellukseen voidaan luoda joukko aloittelevien käyttäjien testitapauksia.
Testitapausten suorittaminen
Aluksi strategiat siirrettiin ja mukautettiin CLI-testausstrategioista.
Hiiren sijainnin sieppaus
Suosittu CLI-ympäristössä käytetty menetelmä on sieppaus / toisto. Sieppaa toisto on järjestelmä, jossa järjestelmän näyttö “siepataan” bittikartoitettuna graafisena kuviona eri aikoina järjestelmän testauksen aikana. Tämä sieppaus antoi testaajalle mahdollisuuden "toistaa" testausprosessia ja verrata testin lähtövaiheen näyttöjä odotettuihin näyttöihin. Tämä vahvistus voitaisiin automatisoida, koska näytöt olisivat identtiset tapauskohtaisesti ja erilaiset, jos tapaus epäonnistuu.
Sieppauksen / toiston käyttö toimi melko hyvin CLI-maailmassa, mutta on huomattavia ongelmia, kun yritetään toteuttaa se GUI-pohjaiseen järjestelmään. Ilmeisin havaittu ongelma on se, että GUI-järjestelmän näyttö voi näyttää erilaiselta, kun taas taustalla olevan järjestelmän tila on sama, mikä tekee automaattisesta validoinnista erittäin vaikeaa. Tämä johtuu siitä, että graafisen käyttöliittymän avulla graafiset objektit voivat vaihdella ulkonäöltään ja sijoittumiselta ruudulle. Fontit voivat olla erilaisia, ikkunan värit tai koot voivat vaihdella, mutta järjestelmän tulos on periaatteessa sama. Tämä olisi ilmeistä käyttäjälle, mutta ei selvää automaattiselle validointijärjestelmälle.
Tapahtumien sieppaaminen
Tämän ja muiden ongelmien torjumiseksi testaajat ovat menneet "konepellin alle" ja keränneet graafisen käyttöliittymän vuorovaikutustietoja taustalla olevasta ikkunointijärjestelmästä. Sieppaamalla ikkunan 'tapahtumat' lokeiksi vuorovaikutukset järjestelmän kanssa ovat nyt muodossa, joka on irrotettu käyttöliittymän ulkoasusta. Nyt vain tapahtumavirrat siepataan. Tapahtumasuosituksia on suodatettu jonkin verran, koska tapahtumavirrat ovat yleensä hyvin yksityiskohtaisia eivätkä useimmat tapahtumat ole suoraan merkityksellisiä ongelman kannalta. Tätä lähestymistapaa voidaan tehdä helpommaksi käyttämällä esimerkiksi MVC- arkkitehtuuria ja tekemällä näkymä (ts. GUI tässä) mahdollisimman yksinkertaiseksi, kun taas mallissa ja ohjaimessa on kaikki logiikat. Toinen lähestymistapa on käyttää ohjelmiston sisäänrakennettua avustavaa tekniikkaa , käyttää HTML-käyttöliittymää tai kolmitasoista arkkitehtuuria, joka mahdollistaa myös käyttöliittymän erottamisen paremmin muusta sovelluksesta.
Toinen tapa suorittaa testejä käyttöliittymällä on rakentaa ohjain käyttöliittymään, jotta komennot tai tapahtumat voidaan lähettää ohjelmistolle toisesta ohjelmasta. Tämä tapa lähettää tapahtumia suoraan ja vastaanottaa tapahtumia järjestelmästä on erittäin toivottavaa testattaessa, koska tulo- ja lähtötestaus voidaan täysin automatisoida ja käyttäjävirheet eliminoida.