Automaattinen testaus
Kokeneet kirjoittajat eivät ole vielä tarkistaneet sivun nykyistä versiota, ja se voi poiketa merkittävästi 30. elokuuta 2018 tarkistetusta
versiosta . tarkastukset vaativat
6 muokkausta .
Automaattinen ohjelmistotestaus on osa testausprosessia ohjelmistokehitysprosessin laadunvalvontavaiheessa . Se käyttää ohjelmistotyökaluja testien suorittamiseen ja ajon tulosten tarkistamiseen, mikä auttaa lyhentämään testausaikaa ja yksinkertaistamaan testausprosessia.
Historia
Ensimmäiset "automaatioyritykset" ilmestyivät DOS- ja CP / M -käyttöjärjestelmien aikakaudella . Sitten se koostui komentojen antamisesta sovellukselle komentorivin kautta ja tulosten analysoinnista. Hieman myöhemmin etäpuhelut lisättiin API :n kautta verkon yli työskentelemistä varten . Ensimmäinen Automaattinen testaus mainitaan Frederick Brooksin kirjassa The Mythical Man-Month , joka kertoo yksikkötestauksen mahdollisuuksista . Mutta todellinen testiautomaatio alkoi kehittyä vasta 1980-luvulla.
Lähestymistavat
Testausautomaatiossa on kaksi päätapaa: kooditason testaus ja käyttöliittymätestaus (erityisesti GUI-testaus). Ensimmäinen tyyppi sisältää erityisesti yksikkötestauksen . Toiseen - käyttäjän toimintojen jäljitelmä - toiminnallinen testaus (käyttäen erityisiä testikehyksiä .)
GUI-automaatio
Yleisin automaation muoto on sovellusten testaus graafisen käyttöliittymän ( GUI ) kautta . Tämäntyyppisen testauksen suosio johtuu kahdesta tekijästä: ensinnäkin sovellus testataan samalla tavalla kuin henkilö käyttää sitä, ja toiseksi sovellusta on mahdollista testata ilman pääsyä lähdekoodiin.
GUI-automaatio on kehittynyt neljän sukupolven työkalujen ja tekniikoiden aikana:
- Kaappaus-/ toistotyökalut tallentavat testaajan toimet manuaalisen testauksen aikana . Niiden avulla voit suorittaa testejä ilman suoraa ihmisen väliintuloa pitkään, mikä lisää merkittävästi tuottavuutta ja eliminoi toistuvien toimien "tyhmän" toiston manuaalisen testauksen aikana. Samaan aikaan kaikki pienet muutokset testattavaan ohjelmistoon edellyttävät manuaalisten testien uudelleenkirjoittamista. Siksi tämä ensimmäisen sukupolven työkalut eivät ole tehokkaita tai skaalautuvia.
- Skriptaus , ohjelmoinnin muoto kielillä, jotka on suunniteltu erityisesti automatisoimaan ohjelmistotestausta, lievittää monia tallennus- ja toistotyökalujen ongelmia. Mutta kehitystyötä tekevät korkean tason ohjelmoijat, jotka työskentelevät erillään testaajista, jotka suorittavat testejä suoraan. Lisäksi komentosarjat soveltuvat parhaiten graafisten käyttöliittymien testaamiseen, eikä niitä voi lisätä, pakata tai yhdistää järjestelmään millään tavalla. Lopuksi muutokset testattavaan ohjelmistoon edellyttävät monimutkaisia muutoksia vastaaviin skripteihin, ja jatkuvasti kasvavan testiskriptikirjaston ylläpidosta tulee loppujen lopuksi ylitsepääsemätön tehtävä.
- Datalähtöinen testaus on menetelmä, jota käytetään testiautomaatiossa. Erikoisuutena on, että testiskriptit suoritetaan ja tarkistetaan keskustietovarastoon tai -tietokantaan tallennettujen tietojen perusteella. Tietokannan roolia voivat hoitaa ODBC-resurssit, csv- tai xls-tiedostot jne. Data-ohjattu testaus on useiden vuorovaikutuksessa olevien testikomentosarjajen ja niiden tietolähteiden yhdistäminen metodologiassa käytettäväksi viitekehykseksi. Tässä viitekehyksessä muuttujia käytetään sekä syöttöarvoille että ulostulotestiarvoille: testiskriptissä sovelluksessa liikkuminen, tietolähteiden lukeminen ja kirjaustestaus yleensä koodataan. Joten skriptissä suoritettava logiikka riippuu myös tiedoista.
- Avainsanoihin perustuva testausautomaatio sisältää tapauksen luomisprosessin jakamisen kahteen vaiheeseen: suunnitteluvaiheeseen ja toteutusvaiheeseen . Tässä tapauksessa viimeinen testi ei ole ohjelmakoodi, vaan kuvaus toimintosarjasta parametreineen (esim. "luo tietokantaan käyttäjä kirjautumistunnuksella XXX ja salasanalla YYY"). Tässä tapauksessa viitekehys vastaa avainsanojen (toimintojen) suorasta toteutuksesta, ja testisuunnittelijalla riittää käsitys koko viitekehyksessä toteutettavista toiminnoista. Tämä mahdollistaa testien tekemisen ihmisille, joilla ei ole ohjelmointitaitoja.
Ongelmia
Yksi automaattisen testauksen suurimmista ongelmista on sen monimutkaisuus: huolimatta siitä, että sen avulla voidaan poistaa osa rutiinitoiminnoista ja nopeuttaa testien suorittamista, itse testien päivittämiseen voidaan käyttää suuria resursseja. Tämä koskee molempia automaatiotyyppejä. Refaktoroinnin yhteydessä on usein tarpeen päivittää myös yksikkötestejä, ja testikoodin muuttaminen voi viedä yhtä paljon aikaa kuin pääkoodin vaihtaminen . Toisaalta sovelluksen käyttöliittymää vaihdettaessa on tarpeen kirjoittaa uudelleen kaikki päivitettyihin ikkunoihin liittyvät testit, jotka voivat suurella määrällä testejä viedä merkittäviä resursseja.
Sovellukset
Testausautomaatioon on monia sovelluksia. Suosituin niistä vuoden 2007 tulosten mukaan: [1]
Näiden työkalujen avulla testaajat automatisoivat seuraavat tehtävät:
- tuotteen asennus
- testidatan luominen
- GUI- vuorovaikutus
- ongelman määrittely
Automaattiset testit eivät kuitenkaan voi täysin korvata manuaalista testausta. Kaikkien testien automatisointi on erittäin kallis prosessi, joten automaattinen testaus on vain lisä manuaaliseen testaukseen. Paras käyttötapa automaattisille testeille on regressiotestaus .
Toolkit
Katso myös
Muistiinpanot
- ↑ SoftJournal 'Syyskuu 2007/ SoftJournal 'Syyskuu 2007 (linkki ei saatavilla) . Haettu 12. huhtikuuta 2010. Arkistoitu alkuperäisestä 23. maaliskuuta 2010. (määrätön)
Linkit