Rikkomaton ohjelmistotestaus (NDT): Mikä on testausstrategia?

Mitä on tuhoamaton ohjelmistotestaus?

Tuhoamaton testaus on ohjelmiston testaustyyppi, joka sisältää ohjelmistosovelluksen oikean testauksen ja vuorovaikutuksen. Toisin sanoen tuhoamatonta ohjelmistotestausta (NDT) voidaan kutsua myös positiiviseksi testaukseksi tai Happy path -testaukseksi. Se antaa odotetut tulokset ja osoittaa, että ohjelmistosovellus toimii odotetulla tavalla.

Nimi on lainattu tekniikasta, jossa rikkomattomassa testauksessa fyysinen komponentti tarkastetaan vahingoittamatta sitä. Ohjelmistoissa ajatus on sama: sovellusta käytetään suunnitellulla tavalla, ja se selviää testistä ehjänä.

Esimerkiksi: Oikeiden tietojen syöttäminen kirjautumismoduuliin ja sen tarkistaminen, hyväksyykö se tunnistetiedot ja siirtyykö se seuraavalle sivulle.

Alla olevassa kuvakaappauksessa näkyy kirjautumislomake, jossa käyttäjätunnuskenttään on kirjoitettu kelvollinen arvo ennen testin suorittamista.

Suorittaaksesi yllä olevassa esimerkissä rikkomattoman testauksen, syötä kelvollinen käyttäjätunnus ja salasana kirjautumislomakkeeseen. Koska syöte vastaa vaatimusta, haluttu tulos on positiivinen ja testaaja yksinkertaisesti vahvistaa, että sovellus siirtyy seuraavalle sivulle.

Miksi tuhoamaton ohjelmistotestaus (NDT)?

Rikkomaton testaus vastaa ensimmäiseen kysymykseen, jonka jokainen sidosryhmä kysyy kokoonpanosta: tekeekö ominaisuus todella sen, mitä sitä pyydettiin tekemään? Nämä ovat syyt, miksi tiimit käyttävät sitä.

• NDT-menetelmän suurin etu on, että se parantaa ohjelmiston laatua, koska päävirrassa havaitut viat korjataan varhaisessa vaiheessa.
• Osoittaa, että ohjelmiston toiminnot toimivat spesifikaatioiden mukaisesti.
• Varmistaakseen, että suorituskykyvaatimukset on täytetty.
• Varmistaakseen, että loppukäyttäjien vaatimukset täyttyvät.
• Tarkistaa, että pieni osa koodia tai toiminnallisuutta toimii odotetulla tavalla eikä riko siihen liittyvää toiminnallisuutta.
• Tuottaakseen todisteita, jotka voidaan esittää käyttäjän hyväksyntätestaus kuittaus, jossa asiakas haluaa nähdä tarkoitetun toiminnan vikatilaen sijaan.

Milloin ainetta rikkomaton testi (NDT) suoritetaan?

Ajoituksella on tässä enemmän merkitystä kuin useimmissa tekniikoissa, koska onnellinen polku ohjaa kaiken myötävirtaan.

• Se on ensimmäinen testausmuoto, jonka testaaja suorittaa sovellukselle, eli testauksen alkuvaiheessa. SDLC.
• Rikkomatonta testausta tehdään yleensä silloin, kun ei ole tarpeeksi aikaa koko testisyklin suorittamiseen, koska se silti osoittaa, että hyväksymiskriteerit täyttyvät.
• Se suoritetaan ennen negatiivisia ja tuhoisia skenaarioita. Jos pääasiallinen kulku on rikki, virheenkäsittelytestit raportoivat kohinaa todellisten vikojen sijaan.
• Se toistetaan jokaisen viankorjauksen jälkeen, jolloin se on päällekkäinen regressiotestaus.

Testistrategia hajoamatonta testausta varten

Rikkomattoman testauksen strategia on tarkoituksella yksinkertainen, ja kurinalaisuus perustuu positiivisuuteen eikä työkalujen käyttöön.

• Lähestymistavan ei-tuhoavaan testaukseen tulisi olla positiivinen.
• NDT-tekniikan tarkoituksena on todistaa, että sovellus toimii, kun sille annetaan kelvollisia syöttötietoja.
• Rikkomattoman testauksen suorittamiseen ei ole erityisvaatimuksia tai -ympäristöä.
• Paras käytäntö rikkomattomassa testauksessa on tarkistaa, toimiiko järjestelmä niin kuin sen on tarkoitus.

Alla oleva kaavio havainnollistaa, miten kyseinen strategia normaalisti organisoidaan testisyklin aikana.

Kuinka kirjoittaa tuhoamattomia (positiivisia) testitapauksia

Ei-tuhoava testitapaus on hyödyllinen vain silloin, kun sen syöte on todistettavasti validi ja sen odotettu tulos tulee vaatimuksesta eikä testaajan oletuksesta. Seuraavat vaiheet tuottavat tällaisen testitapaus.

Vaihe 1) Valitse yksi hyväksymiskriteeri. Lue vaatimus ja muotoile se uudelleen yhdeksi todennettavaksi lausekkeeksi, esimerkiksi "käyttäjätunnuskenttään voi kirjoittaa kuudesta kahteenkymmeneen aakkosnumeerista merkkiä".

Vaihe 2) Valitse kelvolliset syöttötiedot. Valitse arvot, jotka ovat mukavasti sallitun alueen sisällä. Ekvivalenssiositus auttaa tässä — yksi edustava arvo kelvollista osiota kohden riittää yleensä.

Vaihe 3) Kirjoita odotettu tulos ennen suorittamista. Odotettu tulos on kirjoitettava spesifikaatiosta. Sen kirjoittaminen ajon jälkeen muuttaa testin kuvaukseksi siitä, mitä koonti tapahtui.

Vaihe 4) Pidä vaiheet käyttäjäjärjestyksessä. Järjestyksen tulisi vastata sitä, miten todellinen käyttäjä suorittaisi tehtävän, koska tekniikan tarkoituksena on vahvistaa aiottu matka.

Vaihe 5) Kirjaa vaatimuksen tunniste. TracTapauksen palauttaminen kriteeriin antaa tiimille mahdollisuuden todistaa kattavuuden tarkistuksen aikana.

Toimiva esimerkki kirjautumismoduulista näyttää tältä.

Huomaa, että mikään tapauksessa ei yritä rikkoa kenttää. Tapaus, jossa syötetään viisi merkkiä virheilmoituksen näkemiseksi, on negatiivinen testi, ei tuhoamaton.

Esimerkkejä rikkomattomasta testauksesta

Alla oleva esimerkki näyttää, miten rikkomaton testaus toimii monimoduulisessa sovelluksessa vian korjaamisen jälkeen.

• Sovelluksessa on viisi moduulia: kirjautumissivu, kotisivu, käyttäjätietosivu, uuden käyttäjän luonti ja tehtävien luonti.
• Oletetaan, että kirjautumissivulla on virhe: käyttäjätunnuskenttään hyväksytään alle kuusi aakkosnumeerista merkkiä. Tämä on vastoin asetettua vaatimusta, jonka mukaan käyttäjätunnuksen ei tulisi hyväksyä alle kuutta merkkiä, joten kyseessä on vika.
• Vika ilmoitetaan kehitystiimille tavanomaisen lomakkeen kautta. vianhallinnan prosessi, se korjataan ja koontiversio lähetetään takaisin testaustiimille.
• Testaustiimi ei ainoastaan ​​tarkista kirjautumissivua, jolla vika korjattiin, vaan testaa myös muut moduulit. Kaikkien kelvollisilla tiedoilla varustettujen moduulien testauksen yhteydessä se suorittaa rikkomatonta testausta yksinkertaisesti varmistaakseen, että koko sovellus toimii edelleen oikein.

Tuhoamaton testaus vs. tuhoava testaus

Näitä kahta tekniikkaa opetetaan usein yhdessä, koska ne vastaavat vastakkaisiin kysymyksiin samasta rakenteesta. Tuhoava testaus etsii kohtaa, jossa ohjelmisto antaa periksi, kun taas rikkomaton testaus varmistaa, että tarkoitettu toiminta säilyy.

Nämä kaksi täydentävät toisiaan eivätkä ole toisensa vaihtoehtoja. Pelkkä rikkomattoman testauksen suorittaminen jättää virheiden käsittelyn varmentamatta, ja pelkkä rikkomattoman testauksen suorittaminen ei koskaan todista, että tuote toimii tehtävänsä mukaisesti.

Ei-tuhoavan ohjelmistotestauksen edut ja rajoitukset

On yhtä tärkeää tietää, missä kohtaa tekniikka ei ole enää hyödyllinen, kuin tietää, mitä se kattaa.

edut

• Nopea suunnitella ja toteuttaa, koska testidata tulee suoraan spesifikaatiosta.
• Ei vaadi erityistä ympäristöä, vikainjektiota tai vioittunutta datajoukkoa.
• Tuottaa todistusaineistoa, joka vastaa yksi yhteen vaatimuksia, mikä sopii auditointeihin ja hyväksyntoihin.
• Toimii yhtä hyvin kuin manuaalinen testaus ja käsikirjoitetun mukaisesti automaatiotestaus, joten samoja tapauksia voidaan käyttää uudelleen regressiopaketissa.
• Antaa varhaisen ja rehellisen signaalin rakennuksen kunnosta millä tahansa tasolla yksiköstä loppuun asti integraatiotestaus että järjestelmän testaus.

Rajoitukset

• Täysi läpäisy ei kerro mitään siitä, miten sovellus toimii virheellisen syötteen kanssa, joten vakavat virheenkäsittelyvirheet voivat selvitä siitä.
• Kattavuus rajoittuu vaatimusten laatuun. Mitään määrittelemätöntä ei koskaan testata.
• Se voi luoda väärää itseluottamusta, kun onnellinen polku on ainoa polku, jota harjoitetaan ennen julkaisua.
• Se ei mittaa kestävyyttä, palautumista tai suorituskykyä stressitilanteissa, jotka vaativat omat tekniikkansa laajemmasta valikoimasta. ohjelmistotestaustyypit.

Käsittele rikkomatonta testausta lähtökohtana, jolle kaikki muut tekniikat rakentuvat, ja aikatauluta se laajemman kokonaisuuden sisällä. ohjelmistotestauksen elinkaari eikä kertaluonteisena toimintana.

UKK