Ikke-destruktiv softwaretestning (NDT): Hvad er teststrategi?

Hvad er ikke-destruktiv softwaretest?

Ikke-destruktiv testning er en softwaretesttype, der involverer test og interaktion med softwareapplikationen korrekt. Med andre ord kan Non Destructive Software Testing (NDT) også kaldes Positiv Testing eller Happy path testing. Det giver de forventede resultater og beviser, at softwareapplikationen opfører sig som forventet.

Navnet er lånt fra ingeniørvidenskab, hvor ikke-destruktiv testning inspicerer en fysisk komponent uden at beskadige den. I software er ideen den samme: applikationen udføres på den måde, den er designet til at blive brugt, og den overlever testen intakt.

Eksempel: Indtastning af de korrekte data i et loginmodul og kontrol af, om det accepterer legitimationsoplysningerne og navigerer til næste side.

Skærmbilledet nedenfor viser loginformularen med en gyldig værdi indtastet i brugernavnsfeltet, før testen udføres.

For at udføre ikke-destruktiv testning på ovenstående eksempel skal du indtaste et gyldigt brugernavn og en gyldig adgangskode i loginformularen. Da inputtet matcher kravene, er det ønskede resultat positivt, og testeren bekræfter blot, at applikationen går videre til næste side.

Hvorfor udfører ikke-destruktiv softwaretest (NDT)?

Ikke-destruktiv testning besvarer det første spørgsmål, som enhver interessent stiller om et build: Gør funktionen rent faktisk det, den blev bedt om at gøre? Dette er grundene til, at teams kører den.

• Den største fordel ved NDT-metoden er, at den resulterer i forbedret softwarekvalitet, fordi fejl, der findes i hovedflowet, rettes tidligt.
• For at demonstrere, at softwarefunktioner fungerer i overensstemmelse med specifikationen.
• For at verificere, at præstationskravene er opfyldt.
• For at verificere, at slutbrugernes krav er opfyldt.
• At kontrollere, at en lille del af koden eller funktionaliteten fungerer som forventet og ikke ødelægger den relaterede funktionalitet.
• At fremlægge beviser, der kan fremvises på et test af brugeraccept godkendelse, hvor kunden ønsker at se den tilsigtede adfærd i stedet for fejltilstandene.

Når ikke-destruktiv testning (NDT) udføres?

Timing betyder mere her end for de fleste teknikker, fordi den lykkelige vej fører alt nedstrøms.

• Det er den første form for testning, som en tester udfører på en applikation, dvs. i den indledende fase af SDLC.
• Ikke-destruktiv testning udføres normalt, når der ikke er tid nok til en fuld testcyklus, da det stadig beviser, at acceptkriterierne er opfyldt.
• Den kører før negative og destruktive scenarier. Hvis hovedflowet er afbrudt, rapporterer fejlhåndteringstests støj snarere end reelle defekter.
• Det gentages efter hver fejlrettelse, hvilket er hvor det overlapper med regressionstest.

Teststrategi for ikke-destruktiv testning

Strategien for ikke-destruktiv testning er bevidst enkel, og disciplinen ligger i at forblive positiv snarere end i at anvende værktøjer.

• Tilgangen til ikke-destruktiv prøvning bør være positiv.
• Formålet med NDT-teknikken er at bevise, at en applikation vil fungere, når den får gyldige inputdata.
• Der er ingen særlige krav eller behov for at udføre ikke-destruktiv testning.
• Bedste praksis for ikke-destruktiv testning er at kontrollere, om systemet gør, hvad det skal.

Diagrammet nedenfor opsummerer, hvordan strategien normalt er organiseret på tværs af en testcyklus.

Sådan skriver du ikke-destruktive (positive) testcases

En ikke-destruktiv testcase er kun nyttig, når dens input er beviseligt gyldigt, og dens forventede resultat kommer fra et krav snarere end fra testerens antagelse. De følgende trin producerer den slags test sag.

Trin 1) Vælg ét acceptkriterium. Læs kravet, og gentag det som én verificerbar erklæring, for eksempel "brugernavnsfeltet accepterer seks til tyve alfanumeriske tegn".

Trin 2) Vælg gyldige inputdata. Vælg værdier, der ligger komfortabelt inden for det tilladte område. Ækvivalensopdeling hjælper her — én repræsentativ værdi pr. gyldig partition er normalt nok.

Trin 3) Skriv det forventede resultat, før du udfører det. Det forventede resultat skal skrives ud fra specifikationen. At skrive det efter kørslen forvandler testen til en beskrivelse af, hvad buildet tilfældigvis gjorde.

Trin 4) Hold trinnene i brugerens rækkefølge. Sekvensen skal matche, hvordan en rigtig bruger ville udføre opgaven, fordi pointen med teknikken er at bekræfte den tilsigtede rejse.

Trin 5) Registrer kravidentifikatoren. TracAt bringe sagen tilbage til dens kriterium er det, der gør det muligt for teamet at bevise dækning under en gennemgang.

Et eksempel på et login-modul ser sådan ud.

Bemærk, at intet i sagen forsøger at bryde feltet. En sag, der indtaster fem tegn for at se fejlmeddelelsen, er en negativ test, ikke en ikke-destruktiv en.

Eksempler på ikke-destruktiv testning

Eksemplet nedenfor viser, hvordan ikke-destruktiv testning opfører sig på tværs af en multimodulapplikation, efter at en fejl er blevet rettet.

• En applikation har fem moduler: loginside, startside, brugerdetaljeside, oprettelse af nye brugere og oprettelse af opgaver.
• Antag, at der er en fejl på login-siden: brugernavnsfeltet accepterer færre end seks alfanumeriske tegn. Dette er imod det fastsatte krav, som siger, at brugernavnet ikke må acceptere færre end seks tegn, så opførslen er en defekt.
• Fejlen rapporteres til udviklingsteamet via den sædvanlige metode. proces til håndtering af fejl, det er rettet, og build'et sendes tilbage til testholdet.
• Testteamet tjekker ikke kun loginsiden, hvor fejlen blev rettet, men tester også de andre moduler. Mens de tester alle modulerne med gyldige data, udfører de ikke-destruktiv testning, simpelthen for at bekræfte, at hele applikationen stadig fungerer korrekt.

Ikke-destruktiv testning vs. destruktiv testning

De to teknikker undervises ofte sammen, fordi de besvarer modsatrettede spørgsmål om den samme bygning. Destruktiv test ser efter det punkt, hvor softwaren giver efter, mens ikke-destruktiv testning bekræfter, at den tilsigtede adfærd holder.

De to er komplementære snarere end alternativer. At køre ikke-destruktiv test alene efterlader fejlhåndtering ubekræftet, og at køre destruktiv test alene beviser aldrig, at produktet fungerer.

Fordele og begrænsninger ved ikke-destruktiv softwaretestning

At vide, hvor teknikken holder op med at være nyttig, er lige så vigtigt som at vide, hvad den dækker.

Fordele

• Hurtig at designe og udføre, fordi testdataene kommer direkte fra specifikationen.
• Kræver intet særligt miljø, fejlinjektion eller beskadiget datasæt.
• Producerer dokumentation, der afspejler kravene én-til-én, hvilket passer til revisioner og godkendelser.
• Fungerer lige så godt som manuel test og som skrevet automatiseringstest, så de samme tilfælde kan genbruges i en regressionssuite.
• Giver et tidligt, ærligt signal om bygningens tilstand på ethvert niveau, fra enhed til integrationstest til system test.

Begrænsninger

• En fuld gennemgang siger intet om, hvordan applikationen opfører sig med ugyldigt input, så alvorlige fejlhåndteringsfejl kan overleve den.
• Dækningen er begrænset af kravenes kvalitet. Alt, der ikke er specificeret, testes aldrig.
• Det kan skabe falsk selvtillid, når den lykkelige vej er den eneste vej, der praktiseres før en frigørelse.
• Den måler ikke robusthed, restitution eller ydeevne under stress, som kræver deres egne teknikker fra det bredere sæt af typer af softwaretest.

Betragt ikke-destruktiv testning som den grundlæggende metode, som alle andre teknikker bygger på, og planlæg den inden for den bredere ramme. livscyklus for softwaretest snarere end som en engangsaktivitet.

Ofte Stillede Spørgsmål