Mitä on mallipohjainen testaus?

Mitä on mallipohjainen testaus?

Mallipohjainen testaus on ohjelmistotestaustekniikka, jossa testattavan ohjelmiston suorituksenaikaista käyttäytymistä verrataan mallin tekemiin ennusteisiin. Malli on kuvaus järjestelmän käyttäytymisestä, joka ilmaistaan ​​syötesekvenssien, toimintojen, ehtojen, tulosteen ja datan kulun avulla syötteestä tulosteeseen. Käyttökelpoisen mallin on oltava käytännössä ymmärrettävä, uudelleenkäytettävä ja jaettava, ja sen on kuvattava testattavaa järjestelmää tarkasti.

Saatavilla on useita malleja, ja jokainen niistä kuvaa järjestelmän käyttäytymisen eri näkökohtaa. Yleisiä esimerkkejä ovat:

• Tietovirta
• Säätövirtaus
• Riippuvuuskaaviot
• Päätöstaulukot
• Tilansiirtokoneet

Mallipohjainen testaus kuvaa, miten järjestelmä käyttäytyy vastauksena mallin määrittämään toimintoon. Syötä toiminto ja tarkista sitten, reagoiko järjestelmä mallin ennustamalla tavalla. Kaikki näiden kahden väliset eroavaisuudet ovat joko ohjelmiston vika tai mallin virhe, ja molemmat ovat etsimisen arvoisia.

Se on kevyt formaali menetelmä järjestelmän validointiin, ja sitä voidaan soveltaa yhtä helposti sekä laitteistotestaukseen että ohjelmistotestaukseen. Koska testit perustuvat käyttäytymisen määrittelyyn koodin sijaan, tekniikka sopii yhteen musta ruutu testaus perheen ohjelmistotestaustekniikat.

Esimerkki mallipohjaisesta testauksesta

Yksinkertaisin tapa lukea käyttäytymismalli on seurata sitä läpi. Alla oleva kaavio mallintaa pientä tekstinmuokkaustehtävää, jossa jokainen ruutu edustaa sovelluksen mahdollista tilaa ja jokainen nuoli edustaa käyttäjän suorittamaa toimintoa.

Malli selittää yksinkertaistetun lähestymistavan runojen kirjoittamiseen Muistiossa ja kuhunkin vaiheeseen liittyvät mahdolliset toimenpiteet. Jokaista toimintoa, kuten sovelluksen käynnistämistä, runon syöttämistä tai tiedoston tallentamista, varten testitapaus voidaan luoda ja tulos varmentaa. Eri polun kulkeminen saman kaavion läpi, esimerkiksi aloittaminen ja lopettaminen tallentamatta, tuottaa erilaisen testitapauksen ilman lisäsuunnittelukustannuksia, mikä on koko tekniikan taloudellinen perustelu.

MBT:n tyypit

Mallipohjaisia ​​testauskehyksiä on kahdenlaisia, ja niiden välinen ero on yksinkertaisesti siinä, miten testivaiheet tuotetaan:

• Offline / a priori: Testipakettien luominen ennen niiden suorittamista. Testipaketti on kokoelma testitapauksia, ja tässä tilassa se tallennetaan, tarkistetaan ja suoritetaan uudelleen kuten mikä tahansa muu testipaketti. automaatiotestaus voimavara.
• Verkossa / lennossa: Testisarjojen luominen testien suorituksen aikana, jossa seuraava vaihe valitaan sen perusteella, miten järjestelmä todellisuudessa reagoi edelliseen.

Offline-generointi sopii säänneltyihin ympäristöihin, jotka tarvitsevat tarkistettavan ja toistettavan ratkaisun. Online-generointi sopii pitkiin tutkimusistuntoihin tilallisia järjestelmiä vastaan, koska generaattori voi reagoida todelliseen vasteeseen ennustetun sijaan.

Miten mallipohjainen testaus toimii

Käytettiinpä kumpaa tahansa viitekehystä, tekniikka noudattaa samoja viittä vaihetta. Jokainen vaihe tuottaa artefaktin, jonka seuraava vaihe käsittelee, minkä vuoksi tiimi ylläpitää mallia, ei testiskriptiä.

• Vaihe 1: Rakenna malli. Käännä vaatimukset tai eritelmät taulukoksitracodotetun käyttäytymisen malli, joka määrittelee tilat, niiden väliset siirtymät ja kunkin siirtymän laukaisevat syötteet.
• Vaihe 2: Valitse testin valintakriteerit. Kriteerit kertovat generaattorille, milloin se pysähtyy. Yleisiä kriteerejä ovat kaikkien tilojen kattavuus, jossa jokainen tila käydään läpi ainakin kerran; kaikkien siirtymien kattavuus, jossa jokainen nuoli suoritetaan ainakin kerran; ja polku- tai tietovuokattavuus syvällisempää tutkimusta varten.
• Vaihe 3: Vatsalihasten luominentract-testitapaukset. Työkalu kävelee mallin päällä ja tuottaa vatsalihasliikkeitätract vaiheet, jotka täyttävät valitut kriteerit, sekä odotettu tulos kullakin vaiheella.
• Vaihe 4: Konkretisoi vatsalihaksettract-testit. Sovitinkerros kuvaa jokaisen vatsalihaksentract astu todelliseen toimintoon järjestelmää vastaan, kuten käyttöliittymän vuorovaikutukseen, API puhelu tai protokollaviesti. Tämä karttaping kirjoitetaan kerran ja sitä käytetään uudelleen jokaisessa luodussa testissä.
• Vaihe 5: Toteuta ja anna tuomiot. Betonitestit suoritetaan testattavaa järjestelmää vasten, kutakin havaittua vastetta verrataan malliennusteeseen ja kirjataan hyväksymis- tai hylkäystulos. tracpalasi takaisin mallielementtiin, joka sen tuotti.

tracVaiheessa 5 luotu toimivuus on käytännön hyöty. Kun vaatimus muuttuu, malli muuttuu ja kyseiset testit luodaan uudelleen sen sijaan, että ne kirjoitettaisiin uudelleen, minkä vuoksi tiimit, jotka tekevät usein regressiotestaus vakaata spesifikaatiota vastaan ​​hyödyttävät eniten.

Eri mallit testauksessa

MBT:n ymmärtämiseksi on välttämätöntä ymmärtää joitakin alla selitetyistä malleista. Jokainen malli vaihtaa ilmaisuvoimaa vaivaa vastaan, joten valinta riippuu siitä, kuinka monimutkaista testattava käyttäytyminen todella on.

Äärelliset tilakoneet

Tämä malli auttaa testaajia arvioimaan tulosta valitun syötteen perusteella. Syötteiden erilaiset yhdistelmät voivat johtaa järjestelmän vastaavaan tilaan.

Järjestelmällä on tietty tila ja nykyinen tila, joita säätelevät testaajien antamat syötteet.

Tarkastellaan alla olevaa esimerkkiä. Järjestelmä sallii työntekijöiden kirjautua sovellukseen. Työntekijän nykyinen tila on "Ulos", ja siitä tulee "Sisään", kun työntekijä kirjautuu järjestelmään. "Sisään"-tilassa työntekijä voi tarkastella, tulostaa ja skannata järjestelmässä olevia asiakirjoja.

Esimerkin tilakone on esitetty tässä, ja jokainen nuoli on merkitty siirtymän aiheuttavalla syötteellä.

Osavaltiokaaviot

Tilakaavio on äärellisen tilakoneen laajennus, ja sitä voidaan käyttää monimutkaisissa ja reaaliaikaisissa järjestelmissä. Tilakaaviot kuvaavat järjestelmän erilaisia ​​käyttäytymismalleja, niillä on tietty määrä tiloja, ja järjestelmän käyttäytymistä analysoidaan ja esitetään tapahtumien muodossa kullekin tilalle. Käytännössä tärkeä laajennus on hierarkia: tilakaavio sallii sisäkkäiset ja rinnakkaiset tilat, joten kone, joka tarvitsisi kymmeniä yksitasoisia tiloja, voidaan piirtää kompaktisti.

Esimerkiksi viat näytetään vianhallintatyökalussa tilassa Uusi. Kun kehittäjät ovat korjanneet vian, tila on muutettava tilaan Korjattu. Jos vikaa ei ole korjattu, tila muuttuu tilaan Avattu uudelleen. Tilakaaviot tulisi suunnitella siten, että jokaista tilaa kohden kutsutaan tapahtuma.

Vian elinkaari on piirretty alla, jossa kukin tila näkyy tilana ja kukin työnkulun toiminto tapahtumana, joka siirtää vian niiden välillä.

Unified Modeling Language (UML)

Unified Modeling Language (UML) on standardoitu yleiskäyttöinen mallinnuskieli. UML sisältää joukon graafisia merkintätekniikoita, joita käytetään visuaalisten mallien luomiseen, jotka voivat kuvata erittäin monimutkaista järjestelmän käyttäytymistä.

UML:ssä on merkintöjä, kuten:

• Toiminta
• Näyttelijät
• Liiketoimintaprosessi
• komponentit
• Ohjelmointikieli

Testigeneraattorit lukevat useimmin aktiviteetti- ja tilakonekaavioita, kuten alla oleva UML-esimerkkimalli havainnollistaa.

Mallipohjaiset testaustyökalut

Paperilla oleva malli ei itsessään tuota mitään. Tarvitaan generaattori mallin läpikäymiseen ja testipolkujen luomiseen, ja työkalumarkkinat jakautuvat avoimen lähdekoodin generaattoreihin ja kaupallisiin testisuunnittelualustoihin.

• GraphWalker — avoimen lähdekoodin työkalu, joka lukee suunnattujen graafien muotoisia malleja ja luo niistä testipolkuja valittavilla generaattoreilla ja pysäytysehdoilla.
• fMBT — Intelin avoimen lähdekoodin mallipohjainen testaustyökalusarja, joka tukee testien luomista ja suorittamista tilamalleja vasten.
• Conformiq — kaupallinen automatisoitu testisuunnittelutuote, joka johtaa testitapauksia ja skriptejä graafisista käyttäytymismalleista.
• MaTeLo ja MBTsuite — kaupalliset alustat, jotka on suunnattu tilastollisiin käyttömalleihin ja testien luomiseen olemassa oleviin automaatiokehyksiin.
• Teknisten tietojen selaus - Microsoftn mallipohjainen testauslaajennus Visual Studiolle, johon on viitattu laajasti protokollatestauskirjallisuudessa.

Valinta riippuu vähemmän ominaisuuslistoista kuin kahdesta kysymyksestä: minkä notaatiomuodon tiimi voi itse asiassa piirtää ja voiko työkalu lähettää testejä jo käytössä olevaan automaatiokehykseen. Generaattori, joka tuottaa testejä, joita kukaan ei voi suorittaa, lisää prosessiin vaiheen sen sijaan, että poistaisi sen.

Mallipohjainen testaus vs. perinteinen testisuunnittelu

Käsin kirjoitetun testisuunnittelun ja niiden välisen eron tarkastelu on syytä tehdä, koska nämä kaksi lähestymistapaa epäonnistuvat eri paikoissa sen sijaan, että toinen olisi yksinkertaisesti parempi.

Aspect	Mallipohjainen testaus	Perinteinen testisuunnittelu
Testitapausten lähde	Luodaan automaattisesti käyttäytymismallista	Testaajan erikseen vaatimuksista kirjoittama
Vaatimuksen muutoksen vaikutus	Päivitä malli ja luo uudelleen testit, jotka vaikuttavat asiaan	Paikanna ja muokkaa kutakin testitapausta manuaalisesti
Kattavuus	Mitattu mallikriteerien, kuten kaikkien tilojen tai kaikkien siirtymien, perusteella	Mitattu vaatimuksia vasten ja riippuu testaajan arviosta
Ennakkomaksut	Korkea: mallinnustaito, työkalujen asetukset ja sovitinkerros	Matala: testaaja voi aloittaa kirjoittamisen välittömästi
Parhaiten sopiva	Tilalliset, pitkäikäiset järjestelmät, joilla on vakaa spesifikaatio	Lyhytaikaiset projektit, kertaluonteiset teokset ja tutkiva työ
Päävikatila	Väärä tai vanhentunut malli tuottaa huomaamattomasti vääriä testejä	Aukot ja kaksoiskappaleet kertyvät suureen ohjelmistokokonaisuuteen

Alla oleva kehitys asettaa tekniikan kontekstiin: manuaalinen testien suoritus antoi tietä automatisoidulle suoritukselle, ja mallipohjaiset lähestymistavat siirtävät automaation yhden tason aikaisemmaksi, itse testisuunnitteluun.

Mallipohjaisen testauksen haasteet

MBT:n käyttöönotto organisaatiossa vaatii huomattavia rahallisia ja vaivaisia ​​investointeja. Seuraavassa on MBT:n haittoja ohjelmistotuotanto:

• Testaajat tarvitsevat mallinnustaitoja, joita perinteinen testisuunnittelu ei vaadi.
• Oppimiskäyrä on pitkä, ja ensimmäinen projekti maksaa yleensä enemmän kuin sillä säästetään.
• Mallia itsessään voi olla vaikea ymmärtää ja tarkastella, varsinkin kun se kasvaa.
• Malli, joka ajautuu pois spesifikaatioiden tahdista, tuottaa luotettavia, vääriä testejä.
• Adapterikerros, joka kääntää vatsalihaksettracTodellisiin toimiin johtavat askeleet on kirjoitettava ja ylläpidettävä erikseen.
• Mallin koko kasvaa nopeasti, joten rajoittamaton tilamalli voi tuottaa enemmän polkuja kuin mikään tiimi voi toteuttaa.

Mikään näistä ei ole syy välttää tekniikkaa, mutta yhdessä ne selittävät, miksi MBT otetaan yleensä käyttöön ensin yhdessä vakaassa alijärjestelmässä eikä koko järjestelmässä. ohjelmistotestauksen elinkaari heti.

Mallipohjaisen testauksen edut

Näihin kustannuksiin verrattuna MBT:n edut ovat:

• Helppo testitapausten ja testisarjojen ylläpito, koska muokataan mallia yksittäisten testien sijaan.
• Kustannusten aleneminen pitkäaikaisen projektin elinkaaren aikana.
• Parantunut testin kattavuus, koska generaattori tutkii polkuja, jotka henkilö ohittaisi.
• Erilaisia ​​luotuja paketteja voidaan ajaa rinnakkain useilla koneilla.
• Varhainen virheiden havaitseminen, koska epäselvyydet tulevat esiin mallin rakentamisen aikana, ennen kuin mitään koodia on suoritettu.
• Samalla testaussuorituksella löydettyjen vikojen määrän kasvu.
• Ajansäästö testisuunnittelussa, kun malli ja sovitin ovat valmiit.
• Parempi testaajien työtyytyväisyys, kun työmäärä siirtyy toistuvasta skriptaamisesta mallintamiseen ja analysointiin.

Testaajat rakentavat mentaalimalleja joka tapauksessa työskennellessään, ja MBT yksinkertaisesti siirtää nämä mentaalimallit paperille, jossa niitä voidaan tarkastella, versioida ja käyttää uudelleen. Tekniikan sopivuus muihin käytettävissä oleviin lähestymistapoihin on esitetty kohdassa ohjelmistotestauksen tyypit.

UKK