Mittepurustav tarkvaratestimine (NDT): mis on testimisstrateegia?

Mis on mittepurustav tarkvara testimine?

Mittepurustav testimine on tarkvara testimise tüüp, mis hõlmab tarkvararakenduse õiget testimist ja sellega suhtlemist. Teisisõnu võib mittepurustavat tarkvara testimist (NDT) nimetada ka positiivseks testimiseks või õnneliku tee testimiseks. See annab oodatud tulemused ja tõestab, et tarkvararakendus käitub ootuspäraselt.

Nimi on laenatud inseneriteadusest, kus mittepurustava testimise käigus kontrollitakse füüsilist komponenti seda kahjustamata. Tarkvaras on idee sama: rakendust käivitatakse nii, nagu see on loodud kasutamiseks, ja see jääb testist puutumata.

Näide: Õigete andmete sisestamine sisselogimismoodulisse ja kontrollimine, kas see aktsepteerib volitusi ja navigeerib järgmisele lehele.

Allolev ekraanipilt näitab sisselogimisvormi, kus enne testi käivitamist on kasutajanime väljale sisestatud kehtiv väärtus.

Ülaltoodud näites mittepurustava testimise teostamiseks sisestage sisselogimisvormile kehtiv kasutajanimi ja parool. Kuna sisend vastab nõudele, on soovitud tulemus positiivne ja testija lihtsalt kinnitab, et rakendus liigub järgmisele lehele.

Miks tehakse mittepurustavat tarkvara testimist (NDT)?

Mittepurustav testimine vastab esimesele küsimusele, mida iga sidusrühm ehituse kohta küsib: kas funktsioon teeb tegelikult seda, mida sellelt paluti? Need on põhjused, miks meeskonnad seda teevad.

• NDT meetodi peamine eelis on tarkvara kvaliteedi paranemine, kuna põhivoos leitud defektid parandatakse varakult.
• Et näidata, et tarkvara funktsioonid töötavad vastavalt spetsifikatsioonidele.
• Toimivusnõuete täitmise kontrollimiseks.
• Lõppkasutajate nõuete täitmise kontrollimiseks.
• Kontrollimaks, kas väike koodiosa või funktsionaalsus töötab ootuspäraselt ega riku seotud funktsionaalsust.
• Esitada tõendeid, mida saab esitada kasutaja aktsepteerimise testimine kinnitus, kus klient soovib näha kavandatud käitumist, mitte rikkerežiime.

Millal tehakse mittepurustavat testimist (NDT)?

Aeg on siin olulisem kui enamiku tehnikate puhul, sest õnnelik tee suunab kõik allavoolu.

• See on esimene testimisvorm, mida testija rakendusel teostab, st rakenduse algstaadiumis. SDLC.
• Mittepurustavat katsetamist tehakse tavaliselt siis, kui täieliku katsetsükli jaoks pole piisavalt aega, kuna see tõestab ikkagi vastuvõtukriteeriumide täitmist.
• See käivitub enne negatiivseid ja destruktiivseid stsenaariume. Kui põhivoog on katki, siis veakäsitlustestid näitavad müra, mitte tegelikke defekte.
• Seda korratakse pärast iga defekti parandamist, mis kattub sellega. regressioonitest.

Mittepurustavate katsete testimisstrateegia

Mittepurustava testimise strateegia on tahtlikult lihtne ja distsipliin seisneb pigem positiivses suhtumises kui tööriistade kasutamises.

• Mittepurustava testimise lähenemisviis peaks olema positiivne.
• NDT-tehnika eesmärk on tõestada, et rakendus töötab, kui sellele antakse kehtivad sisendandmed.
• Mittepurustava katsetamise läbiviimiseks ei ole vaja erinõudeid ega keskkonda.
• Mittepurustava testimise parim tava on kontrollida, kas süsteem teeb seda, mida peaks tegema.

Allolev diagramm võtab kokku, kuidas see strateegia tavaliselt testitsükli jooksul korraldatakse.

Kuidas kirjutada mittepurustavaid (positiivseid) testijuhtumeid

Mittepurustav test on kasulik ainult siis, kui selle sisend on tõestatavalt kehtiv ja selle oodatav tulemus tuleneb nõudest, mitte testija eeldusest. Järgmised sammud loovad sellise tulemuse. testjuhtum.

1. samm) Valige üks vastuvõtukriteerium. Lugege nõuet ja sõnastage see uuesti ühe kontrollitava avaldusena, näiteks „kasutajanime väli aktsepteerib kuut kuni kahtekümmet tähtnumbrilist märki”.

2. samm) Valige kehtivad sisendandmed. Valige väärtused, mis jäävad mugavalt lubatud vahemikku. Ekvivalentsuse jagamine aitab siin – tavaliselt piisab ühest esinduslikust väärtusest kehtiva partitsiooni kohta.

3. samm) Enne käivitamist kirjutage oodatav tulemus üles. Oodatav tulemus tuleb spetsifikatsioonist kirja panna. Selle kirjutamine pärast käivitamist muudab testi kirjelduseks sellest, mida ehitus tegi.

4. samm) Hoidke sammud kasutaja järjekorras. Järjekord peaks vastama sellele, kuidas päris kasutaja ülesande täidaks, sest tehnika eesmärk on kavandatud teekonna kinnitamine.

5. samm) Salvestage nõude identifikaator. TracJuhtumi tagasiviimine kriteeriumini võimaldab meeskonnal läbivaatamise käigus katvust tõestada.

Sisselogimismooduli toimiv näide näeb välja selline.

Pane tähele, et juhtumis ei püüta välja rikkuda. Juhtum, mis veateate kuvamiseks sisestab viis tähemärki, on negatiivne test, mitte mittepurustav.

Mittepurustavate katsete näited

Allolev näide demonstreerib, kuidas mittepurustav testimine toimib mitme mooduliga rakenduses pärast defekti parandamist.

• Rakendusel on viis moodulit: sisselogimisleht, avaleht, kasutajaandmete leht, uue kasutaja loomine ja ülesande loomine.
• Oletame, et sisselogimislehel on viga: kasutajanime väli aktsepteerib vähem kui kuut tähemärki. See on vastuolus seatud nõudega, mis sätestab, et kasutajanimi ei tohiks aktsepteerida vähem kui kuut tähemärki, seega on selline käitumine defekt.
• Veast teatatakse arendusmeeskonnale tavapärasel viisil. defektide haldamise protsess, see parandatakse ja versioon saadetakse testimismeeskonnale tagasi.
• Testimismeeskond ei kontrolli mitte ainult sisselogimislehte, kus viga parandati, vaid testib ka teisi mooduleid. Kõikide kehtivate andmetega moodulite testimise ajal teostavad nad mittepurustavaid teste, et lihtsalt kinnitada kogu rakenduse korrektset toimimist.

Mittepurustav testimine vs hävitav testimine

Neid kahte tehnikat õpetatakse sageli koos, sest need vastavad sama ehituse kohta käivatele vastandlikele küsimustele. Destruktiivne katsetamine otsib punkti, kus tarkvara annab järele, samas kui mittepurustav testimine kinnitab kavandatud käitumise püsimist.

Need kaks täiendavad teineteist, mitte ei ole alternatiivid. Ainult mittepurustava testimise abil jääb veakäsitlus kontrollimata ja ainult purustava testimise abil ei saa kunagi tõestada, et toode teeb oma tööd.

Mittepurustava tarkvaratestimise eelised ja piirangud

Sama oluline on teada, kus tehnika enam kasulik pole, kui teada, mida see hõlmab.

Eelised

• Kiire kujundada ja teostada, sest testiandmed pärinevad otse spetsifikatsioonist.
• Ei vaja spetsiaalset keskkonda, veasüstimist ega rikutud andmekogumit.
• Esitab tõendeid, mis on üks-ühele vastavuses nõuetega, mis sobib auditite ja heakskiitmiste jaoks.
• Toimib sama hästi kui käsitsi testimine ja nagu stsenaariumi järgi automaatika testimine, seega saab samu juhtumeid regressioonikomplektis uuesti kasutada.
• Annab varajase ja ausa signaali ehituse seisukorra kohta igal tasandil, alates üksusest kuni integratsiooni testimine et süsteemi testimine.

Piirangud

• Täielik läbimine ei ütle midagi selle kohta, kuidas rakendus sobimatu sisendiga käitub, seega võivad tõsised veakäsitlusvead selle üle elada.
• Hõlmatud ulatust piirab nõuete kvaliteet. Midagi täpsustamata ei testita kunagi.
• See võib tekitada valekindlust, kui õnnelik tee on ainus tee, mida enne vabastamist järgitakse.
• See ei mõõda vastupidavust, taastumist ega sooritust stressitingimustes, milleks on vaja oma tehnikaid laiemast valikust. tarkvara testimise tüübid.

Mittepurustavat testimist tuleks käsitleda alusena, millele kõik teised tehnikad tuginevad, ja planeerida see laiemasse protsessi. tarkvara testimise elutsükkel mitte ühekordse tegevusena.

KKK