Mikä on dynaaminen testaus? Tyypit, tekniikat ja esimerkki
Thomas Hamilton
⚡ Älykäs yhteenveto
Dynaaminen testaus suorittaa sovelluksen ja tarkkailee, miten käynnissä oleva koodi käyttäytyy todellisten syötteiden kanssa, jotta testaajat voivat validoida toiminnallisuutta, suorituskykyä ja vakautta, joita mikään määrä dokumenttien tarkastelua ei pysty paljastamaan.
Mikä on dynaaminen testaus?
Dynaaminen testaus on ohjelmistotestausmenetelmä, jota käytetään ohjelmistokoodin dynaamisen käyttäytymisen testaamiseen. Dynaamisen testauksen päätarkoitus on tutkia ohjelmiston käyttäytymistä dynaamisilla muuttujilla – muuttujilla, jotka eivät ole vakioita – ja löytää heikkoja kohtia ohjelmiston suoritusympäristöstä. Koodi on suoritettava dynaamisen käyttäytymisen testaamiseksi.
Testaus on todentaminen ja validointi, ja testauksen suorittamiseen tarvitaan molemmat V:t. Todentaminen suoritetaan staattisella testauksella, jossa tarkastellaan vaatimuksia, suunnitteludokumentteja ja koodia ilman niiden suorittamista. Validointi suoritetaan dynaamisella testauksella, jossa suoritetaan koontiversio ja verrataan sovelluksen todellista toimintaa siihen, mitä sen pitäisi tehdä.
Alla oleva taulukko erottaa nämä kaksi yhdellä silmäyksellä.
| Aspect | Staattinen testaus (todentaminen) | Dynaaminen testaus (validointi) |
| Code teloitettiin | Ei | Kyllä |
| Tyypilliset aktiviteetit | RevNäkymät, läpikäynnit, tarkastukset, staattinen analyysi | Testitapausten suoritus kaikilla testitasoilla |
| Kysymykseen vastattu | Rakennammeko tuotteen oikein? | Rakennammeko oikeanlaista tuotetta? |
| Löytyneet viat | Epäselvät vaatimukset, koodausstandardien rikkomukset, kuollut koodi | Väärä tulostusjälki, muistivuodot, ajoitusvirheet, integrointivirheet |
| Alkaa | Heti kun artefakti on olemassa | Kun suoritettava koontitiedosto on olemassa |
| Korjauksen suhteelliset kustannukset | Alempi, koska viat havaitaan aikaisemmin | Korkeampi, koska viat tulevat esiin myöhemmin |
Esimerkki dynaamisesta testauksesta
Lyhyt esimerkki osoittaa, miten dynaaminen testaus toimii käytännössä.
Oletetaan, että testataan kirjautumissivua. Siinä on kaksi kenttää, käyttäjätunnus ja salasana, ja käyttäjätunnus on rajoitettu aakkosnumeerisiin merkkeihin.
Kun käyttäjä syöttää käyttäjätunnuksen muodossa "Guru99”, järjestelmä hyväksyy sen. Kun käyttäjä syöttää ”Guru99@123”, sovellus antaa virheilmoituksen. Tämä tulos osoittaa, että koodi toimii dynaamisesti käyttäjän syötteen perusteella.
Dynaaminen testaus tarkoittaa siis työskentelyä todellisen järjestelmän kanssa, syötteen antamista ja sovelluksen todellisen käyttäytymisen vertaamista odotettuun käyttäytymiseen – toisin sanoen työskentelyä järjestelmän kanssa virheiden löytämiseksi.
Dynaaminen testaus on siis prosessi, jossa ohjelmistosovellus validoidaan loppukäyttäjän tavoin erilaisissa ympäristöissä oikean ohjelmiston rakentamiseksi.
Mitä dynaaminen testaus tekee?
Dynaamisten testien päätavoitteena on varmistaa, että ohjelmisto toimii oikein asennuksen aikana ja sen jälkeen, ja tuottaa vakaan sovelluksen ilman merkittäviä virheitä. Mikään ohjelmisto ei ole täysin virheetön, ja testaus voi osoittaa virheiden olemassaolon, mutta ei koskaan niiden puuttumista.
Dynaamiset testit varmistavat myös ohjelmiston yhdenmukaisuuden, kuten tämä esimerkki osoittaa.
Pankkisovelluksessa on useita näyttöjä, kuten Omat tilit, Rahansiirto ja Bill Maksa. Kaikissa niissä on summakenttä.
Oletetaan, että Omat tilit -kentässä näkyy summana 25 000, Rahansiirto-kentässä näkyy 25 000 dollaria ja Bill Maksunäytöllä näkyy 25 000 dollaria. Summa on sama, mutta sen esitystapa on erilainen, mikä tekee ohjelmistosta epäjohdonmukaisen.
Johdonmukaisuus ei rajoitu toiminnallisuuteen. Se kattaa myös standardit, kuten suorituskyvyn, käytettävyyden ja yhteensopivuuden, minkä vuoksi dynaaminen testaus on niin tärkeää.
Dynaamisen testauksen tyypit
Dynaaminen testaus luokitellaan kahteen luokkaan.
- Valkoinen Box Testaus
- Musta Box Testaus
Alla oleva kaavio kuvaa näitä kahta luokkaa niiden alemmilla testaustasoilla.
Jokainen tyyppi ja sen käyttötarkoitus on kuvattu alla.
Valkoinen Box Testaus — ohjelmistotestausmenetelmä, jossa testaaja tuntee järjestelmän sisäisen rakenteen ja suunnittelun. Sen päätavoitteena on tarkistaa järjestelmän suorituskyky koodin perusteella. Sen suorittavat pääasiassa kehittäjät tai white box -testaajat, joilla on ohjelmointiosaamista.
Musta Box Testaus — testausmenetelmä, jossa testaaja EI tunne sisäistä rakennetta, koodia ja suunnittelua. Sen päätavoitteena on varmistaa testattavan järjestelmän toimivuus. Tämän tyyppinen testaus edellyttää koko testisarjan suorittamista, sen suorittavat pääasiassa testaajat, eikä se vaadi ohjelmointiosaamista.
Mustalaatikkotestaus luokitellaan jälleen kahteen tyyppiin.
- Toiminnallinen testaus
- Ei-toiminnallinen testaus
Toiminnallinen testaus
Toiminnallinen testaus suoritetaan sen varmistamiseksi, että kaikki kehitetyt ominaisuudet vastaavat toiminnallisia spesifikaatioita. Se suoritetaan suorittamalla toiminnallinen testitapaukset laadunvarmistustiimin kirjoittama. Tässä vaiheessa järjestelmää testataan antamalla syötteitä, tarkistamalla tulosteet ja vertaamalla todellisia tuloksia odotettuihin tuloksiin.
Toiminnallista testausta on eri tasoilla, joista tärkeimmät ovat alla olevat neljä.
- Yksikkötestaus — yksikkö on pieni, testattava koodipätkä. Yksikkötestaus suoritetaan yksittäiselle ohjelmistoyksikölle, ja sen suorittavat kehittäjät.
- Integraation testaus — suoritetaan yksikkötestauksen jälkeen yhdistämällä yksittäiset testattavat yksiköt. Sen suorittavat joko kehittäjät tai testaajat.
- Järjestelmän testaus — suoritetaan sen varmistamiseksi, että järjestelmä toimii vaatimusten mukaisesti. Yleensä testaajat suorittavat sen, kun koko järjestelmä on valmis ja koontiversio on julkaistu laadunvarmistustiimille.
- Hyväksyntätestaus — suoritetaan sen varmistamiseksi, että järjestelmä täyttää liiketoimintavaatimukset ja on käyttö- tai käyttöönottovalmis. Yleensä loppukäyttäjät suorittavat sen.
Ei-toiminnallinen testaus
Ei-toiminnallinen testaus on testaustekniikka, joka ei keskity toiminnallisiin näkökohtiin, vaan keskittyy järjestelmän ei-toiminnallisiin ominaisuuksiin, kuten muistivuotoihin, suorituskykyyn tai kestävyyteen. Ei-toiminnallista testausta suoritetaan kaikilla testaustasoilla.
On olemassa monia ei-toiminnallisia testaustekniikoita, joista tärkeimmät ovat alla olevat viisi.
- Suorituskykytestaus — tarkistaa, onko järjestelmän vasteaika normaali vaatimusten mukaisesti halutulla verkkokuormituksella.
- Palautustestaus — tarkistaa, kuinka hyvin järjestelmä toipuu kaatumisista ja laitteistovioista.
- Yhteensopivuuden testaus — varmistaa, miten järjestelmä toimii eri ympäristöissä.
- Suojaustestaus — tarkistaa sovelluksen kestävyyden varmistaen, että vain valtuutetut käyttäjät ja roolit voivat käyttää järjestelmää.
- Käytettävyystestaus — varmistaa järjestelmän käytettävyyden loppukäyttäjien keskuudessa ja sen, kuinka mukavasti he ovat sen kanssa.
Dynaamiset testaustekniikat
Kun tyypit on selvitetty, seuraava kysymys on, miten dynaaminen testisykli oikeastaan suoritetaan.
Dynaamiset testaustekniikat STLC koostuvat tehtävistä, kuten testien vaatimusanalyysi, testien suunnittelu, testitapausten suunnittelu ja toteutus, testiympäristön määrittäminen, testitapausten suorittaminen, virheraportointi ja lopuksi testin päättäminen. Jokainen dynaamisen testauksen tehtävä riippuu edellisen testausprosessin tehtävän valmistumisesta.
STLC:ssä varsinainen dynaaminen testausprosessi alkaa testitapauksen suunnittelusta. Alla oleva kaavio näyttää aktiviteettien järjestyksen, joista jokainen on kuvattu sen jälkeen.
Ennen prosessin aloittamista on sovittava dynaamisessa testauksessa noudatettavasta strategiasta.
Testausstrategian tulisi keskittyä pääasiassa käytettävissä oleviin resursseihin ja aikatauluun. Näiden kahden tekijän perusteella on dokumentoitava testauksen tavoite, testauksen laajuus, testausvaiheet tai -syklit, ympäristön tyyppi, mahdolliset oletukset tai haasteet sekä riskit.
Kun strategia on määritelty ja johto on hyväksynyt sen, alkaa varsinainen testitapausten suunnitteluprosessi.
Testien suunnittelu ja toteutus
Tässä vaiheessa tiimi tunnistaa seuraavat asiat.
- Testattavat ominaisuudet
- Näistä ominaisuuksista johdetut testiolosuhteet
- Testiolosuhteista johdetut kattavuuskohteet
- Kattavuuden osista johdetut testitapaukset
Musta laatikko testisuunnittelutekniikat kuten ekvivalenssiositus, reuna-arvoanalyysi, päätöstaulutestaus ja tilasiirtymätestaus ovat niitä, jotka muuttavat testiehdon konkreettiseksi joukoksi suoritettavia tapauksia.
Testiympäristön asetukset
testiympäristössä tulisi aina olla samanlainen kuin tuotantoympäristö. Tässä vaiheessa asennetaan koontiversio ja hallitaan ja konfiguroidaan testikoneita.
Testin suorittaminen
Tässä vaiheessa testitapaukset itse asiassa suoritetaan joko manuaalisesti tai automaatio, ja todelliset tulokset kirjataan odotettuja tuloksia vasten.
Virheraportti tallennettu
Suorituksen perusteella, jos odotetut ja todelliset tulokset eivät ole samat, testitapaus on merkittävä epäonnistuneeksi ja järjestelmään on kirjattava virheilmoitus. vianhallinnan prosessiin.
Dynaamisen testauksen edut
- Dynaaminen testaus paljastaa vikoja, joita pidetään liian vaikeina tai monimutkaisina havaita ja joita staattinen analyysi ei pysty kattamaan lainkaan.
- Ohjelmisto toteutetaan kokonaisvaltaisesti, mikä nostaa sekä tuotteen että projektin laatua.
- Dynaaminen testaus on olennainen keino havaita tietoturvauhkia käynnissä olevassa järjestelmässä.
- Ajonaikaiset virheet, kuten muistivuodot, ajoitusongelmat ja integrointivirheet, ilmenevät täällä eivätkä missään muualla.
Dynaamisen testauksen haitat
- Dynaaminen testaus on aikaa vievää, koska sovelluksen tai koodin suorittaminen vaatii paljon resursseja.
- Se lisää projektin kustannuksia, koska se ei ala ohjelmiston elinkaaren alkuvaiheessa ja myöhemmissä vaiheissa korjatut ongelmat maksavat enemmän.
- Tuotantoympäristön kaltainen ympäristö ja realistinen testidata ovat edellytyksiä, ja molempien rakentaminen ja ylläpito vaativat vaivaa.
