Metoder til test software og sammenligne dem. Testmetode af "black box" test og metoden for "hvide boks"

Software test (software) afslører mangler, fejl og fejl i den kode, der skal fjernes. Det kan også defineres som processen med at evaluere funktionaliteten og korrektheden af software ved hjælp af analyse. De vigtigste metoder til integration og testning af softwareprodukter sikrer kvaliteten af applikationer og består i at kontrollere specifikationen, design og kode, pålidelighed evaluering, validering og verifikation.

metoder

Hovedmålet med software test er at bekræfte softwarepakkenes kvalitet ved systematisk debugging-applikationer under omhyggeligt kontrollerede forhold, bestemmelse af deres fuldstændighed og korrekthed samt opdagelse af skjulte fejl.

Metoder til testning (testning) programmer kan opdeles i statisk og dynamisk.

Den første omfatter uformel, kontrol og teknisk revision, inspektion, trin-for-trin analyse, revision, samt statisk analyse af datastrøm og ledelse.

Dynamiske teknikker er som følger:

1. Hvidboksprøvning. Dette er en detaljeret undersøgelse af programmets interne logik og struktur. Dette kræver kendskab til kildekoden.
2. Black box test. Denne teknik kræver ingen kendskab til den interne drift af ansøgningen. Vi overvejer kun de vigtigste aspekter af systemet, der ikke er relaterede eller lidt relateret til dets interne logiske struktur.
3. Metoden i den grå boks. Kombinerer de to foregående tilgange. Fejlfinding med begrænset viden om applikationens interne funktion kombineres med kendskab til systemets grundlæggende aspekter.

Gennemsigtig test

Den hvide boks metode anvender testscenarier for kontrolstrukturen i procedureprojektet. Denne teknik giver dig mulighed for at identificere implementeringsfejl, såsom dårlig kodestyring, ved at analysere det interne arbejde i et softwareprogram. Disse testmetoder er gældende på integrations-, modul- og systemniveau. Testeren skal have adgang til kildekoden og ved hjælp af den finde ud af hvilken blok opfører sig på en upassende måde.

Testprogrammer ved hjælp af den hvide boks metode har følgende fordele:

• Tillader dig at registrere en fejl i den skjulte kode, når du sletter unødvendige rækker;
• Muligheden for at bruge bivirkninger;
• Den maksimale dækning opnås ved at skrive et testscenarie.

ulemper:

• En omkostningsproces, der kræver en kvalificeret debugger;
• Mange stier forbliver uudforskede, da en grundig kontrol af alle mulige skjulte fejl er meget kompliceret;
• Nogle af den manglende kode vil gå ubemærket.

Hvidboksprøvning kaldes også undertiden gennemsigtig eller åben boks test, strukturel, logisk test, kildebaseret test, arkitektur og logik.

De vigtigste sorter:

1) flow kontrol test er en strukturel strategi, der bruger program kontrol flow som en model og giver præference for mere enkle stier over et mindre antal mere komplekse dem;

2) Branch-debugging er designet til at undersøge hver valgmulighed (sand eller falsk) for hver kontroloperatør, som også omfatter en kombineret løsning;

3) afprøvning af hovedvejen, som gør det muligt for testeren at fastslå en måling af procedurprojektets logiske kompleksitet for at tildele et grundlæggende sæt af eksekveringsveje;

4) Kontrol af datastrømmen - Kontrolstrømforskningsstrategien ved at annotere grafen med oplysninger om erklæring og anvendelse af programvariabler;

5) test af cykler - er fuldt fokuseret på korrekt udførelse af cykliske procedurer.

Behavioral debugging

Black box test betragter softwaren som en "black box" - der tages ikke hensyn til oplysninger om programmets interne arbejde, og kun de vigtigste aspekter af systemet kontrolleres. I dette tilfælde skal testeren kende systemarkitekturen uden adgang til kildekoden.

Fordele ved denne tilgang:

• Effektivitet for et stort kodesegment;
• Enkelhed af opfattelse af testeren;
• Brugerperspektivet er klart adskilt fra udviklerens perspektiv (programmøren og testeren er uafhængige af hinanden);
• Hurtigere test oprettelse.

Testprogrammer ved hjælp af den sorte boks metode har følgende ulemper:

• Faktisk udføres et udvalgt antal testscenarier, hvilket resulterer i en begrænset dækning;
• Manglen på en klar specifikation gør det vanskeligt at udvikle testscenarier;
• Lav effektivitet.

Andre navne på denne teknik er adfærdsmæssige, uigennemsigtige, funktionelle test og fejlsøgning ved den lukkede boks metode.

Denne kategori indeholder følgende metoder til software testning:

1) ækvivalent partitionering, som kan reducere sæt testdata, fordi indgangsdata for programmodulet er opdelt i separate dele;

2) kantanalyse fokuserer på at verificere grænser eller ekstreme grænseværdier - minima, maxima, fejlagtige og typiske værdier;

3) fuzzing - bruges til at finde implementeringsfejl ved at indtaste forvrængede eller halv-disaggregerede data i automatisk eller halvautomatisk tilstand;

4) Grafer af årsagssammenhænge - En teknik baseret på dannelsen af grafer og etablering af en forbindelse mellem handlingen og dens årsager: identitet, negation, logisk OR og logisk OG er de fire grundlæggende symboler der udtrykker den indbyrdes afhængighed mellem årsag og virkning;

5) verifikation af ortogonale arrays, anvendt på problemer med et forholdsvis lille inputområde, der overstiger mulighederne for en udtømmende undersøgelse

6) test af alle par - en teknik, hvis sæt testværdier indbefatter alle mulige diskrete kombinationer af hvert par input parametere;

7) Fejlfindingstilstandsovergange er en teknik, der er nyttig til at tjekke statsmaskinen, og også til at navigere gennem den grafiske brugergrænseflade .

Black-box test: eksempler

Black box teknologi er baseret på specifikationer, dokumentation, samt beskrivelser af software interface eller system. Derudover er det muligt at bruge modeller (formelle eller uformelle), der repræsenterer software forventede opførsel.

Denne debugging-metode bruges typisk til brugergrænseflader og kræver interaktion med applikationen ved at indtaste data og indsamle resultaterne - fra skærmen, fra rapporter eller udskrifter.

Testeren, på denne måde, interagerer med softwaren ved input, der virker på switche, knapper eller andre grænseflader. Valget af input data, rækkefølgen af deres introduktion eller rækkefølgen af handlinger kan føre til et gigantisk totalt antal kombinationer, som det ses i det følgende eksempel.

Hvor mange tests skal du udføre for at kontrollere alle mulige værdier for de 4 afkrydsningsfelter og et topositionsfelt, der angiver tiden i sekunder? Ved første øjekast er beregningen enkel: 4 felter med to mulige tilstande - 24 = 16, som skal multipliceres med antallet af mulige positioner fra 00 til 99, det er 1600 mulige tests.

Ikke desto mindre er denne beregning fejlagtig: vi kan bestemme, at topositionsfeltet også kan indeholde et tomt, det vil sige, det består af to alfanumeriske positioner og kan omfatte symboler i alfabetet, specielle symboler, mellemrum osv. Således, hvis Systemet er en 16-bit computer, så får vi 216 = 65.536 varianter for hver position, hvilket resulterer i 4.294.967.296 test tilfælde, der skal multipliceres med 16 kombinationer for flagene, hvilket giver i alt 68.719.476.736. Hvis du udfører dem Med en hastighed på 1 test pr. Sekund, så den samlede Testvarigheden er 2 177,5 år. For 32 eller 64-bit systemer er varigheden endnu større.

Derfor er der behov for at reducere denne tid til en acceptabel værdi. Teknikker bør således bruges til at reducere antallet af testtilfælde uden at reducere testdækningen.

En tilsvarende partition

Ækvivalent partitionering er en simpel metode, der kan anvendes på eventuelle variabler, der findes i softwaren, hvad enten input eller output værdier, symbolsk, numerisk osv. Det er baseret på princippet om, at alle data fra en tilsvarende partition behandles på samme måde af dem Samme instruktioner.

Under testning vælges en repræsentant fra hver defineret ækvivalent partition. Dette giver dig mulighed for systematisk at reducere antallet af mulige test tilfælde uden at miste omfanget af kommandoer og funktioner.

En anden konsekvens af denne opdeling er reduktionen af den kombinatoriske eksplosion mellem de forskellige variabler og den tilhørende reduktion i testtilfælde.

For eksempel anvendes i (1 / x) ^1/2 tre datasekvenser, tre ækvivalente partitioner:

1. Alle positive tal behandles på samme måde og skal give de rigtige resultater.

2. Alle negative tal behandles ens, med samme resultat. Dette er ikke sandt, da roden til et negativt tal er imaginært.

3. Zero vil blive behandlet separat og vil give en fejl "division med nul". Dette er en sektion med en værdi.

Således ser vi tre forskellige sektioner, hvoraf den ene er reduceret til en enkelt værdi. Der er en "korrekt" sektion, der giver pålidelige resultater og to "forkerte" med ukorrekte resultater.

Grænseanalyse

Databehandling ved grænserne for en tilsvarende partition kan udføres forskelligt end forventet. Undersøgelsen af grænseværdier er en velkendt måde at analysere softwareadfærd på i sådanne områder. Denne teknik gør det muligt for os at identificere sådanne fejl:

• Misbrug af relationelle operatører (<,>, =, ≠, ≥, ≤);
• Enkle fejl;
• Problemer i cykler og iterationer,
• Forkerte typer eller størrelser af variabler, der bruges til at gemme oplysninger;
• Kunstige begrænsninger forbundet med data og typer af variabler.

Semi-gennemsigtig test

Den grå boks metode øger dækningen af kontrollen, så du kan fokusere på alle niveauer i det komplekse system ved at kombinere metoderne for hvid og sort.

Ved hjælp af denne teknik skal en tester til udvikling af testværdier have kendskab til interne datastrukturer og algoritmer. Eksempler på testmetoder for en grå boks er:

• Arkitektonisk model;
• Unified Modeling Language (UML);
• Statlig model (finite state machine).

I den grå boks metode til udvikling af test tilfælde undersøges hvide modulkoder, og den egentlige test udføres på grænsefladerne for det sorte teknologiprogram.

Sådanne testmetoder har følgende fordele:

• Kombination af fordele ved teknikker af hvide og sorte kasser;
• Testeren er afhængig af grænsefladen og den funktionelle specifikation, snarere end på kildekoden;
• Fejlfindingen kan skabe fremragende testskrifter;
• Kontrol foretages ud fra brugerens synsvinkel og ikke af programdesigneren;
• Oprettelse af tilpasset testudvikling;
• objektivitet.

ulemper:

• Testdækning er begrænset, da der ikke er adgang til kildekoden;
• Kompleksiteten ved at detektere defekter i distribuerede applikationer;
• Mange måder forbliver uudforskede;
• Hvis softwareudvikleren allerede har startet testen, kan yderligere forskning være overflødig.

Et andet navn til den grå boks teknik er en semi-gennemsigtig debugging.

Denne kategori omfatter sådanne testmetoder:

1) ortogonale array - brug af en delmængde af alle mulige kombinationer;

2) matrix debugging ved hjælp af program state data;

3) en regressionskontrol foretaget under introduktionen af nye ændringer i softwaren;

4) en skabelon test, der analyserer design og arkitektur af en solid applikation.

Sammenligning af software testmetoder

Brugen af alle dynamiske metoder fører til en kombinatorisk eksplosion af antallet af tests, der skal udvikles, implementeres og udføres. Hver teknik bør anvendes pragmatisk under hensyntagen til dens begrænsninger.

Den eneste rigtige metode eksisterer ikke, der er kun de der passer bedre til en bestemt sammenhæng. Strukturelle teknikker giver os mulighed for at finde ubrugelige eller ondsindede kode, men de er komplekse og uanvendelige til store programmer. Metoder baseret på specifikationen er de eneste, der er i stand til at identificere den manglende kode, men de kan ikke identificere en outsider. Nogle teknikker er mere egnede til et bestemt niveau af test, såsom fejl eller kontekst, end andre.

Nedenfor er de vigtigste forskelle mellem de tre dynamiske testteknikker - givet en sammenligningstabel mellem de tre former for debugging software.

aspekt	Sort boks metode	Grå boks metode	Hvid boks metode
Tilgængelighed af oplysninger om programmets sammensætning	Kun grundlæggende aspekter analyseres	Delvis kendskab til det interne enhedsprogram	Fuld adgang til kildekoden
Graden af fragmentering af programmet	lav	Central	høj
Hvem laver debugging?	Slutbrugere, testere og udviklere	Slutbrugere, debuggere og udviklere	Udviklere og testere
basen	Testning er baseret på eksterne freelance situationer.	DB diagrammer, data flow diagrammer, interne tilstande, algoritme og arkitektur kendskab	Det interne arrangement er fuldt kendt
Grad af dækning	Mindst udtømmende og kræver et minimum af tid	Central	Potentielt den mest omfattende. Det tager lang tid
Data og interne grænser	Enkel fejlfinding ved forsøg og fejl	Kan kontrolleres data domæner og de indre grænser, hvis de er kendt	De bedste test data domæner og de indre grænser
Egnethed test algoritme	ingen	ingen	Ja

automatisering

Automatiske metoder til softwaretest er meget forenkle processen med inspektion, uanset hvilket teknisk miljø og sammenhæng med. De anvendes i to tilfælde:

1) at automatisere den kedelige, gentagne eller omhyggelige opgaver såsom fil sammenligning til flere tusinde rækker for at frigive tid til koncentration af testeren mere vigtige punkter;

2) til at udføre sporing eller opgaver, der ikke let kan udføres af folk som ydeevnekontrol eller analyse responstid, der kan måles i hundrededele af et sekund.

Test værktøjer kan klassificeres på forskellige måder. Den næste afdeling er baseret på de opgaver, de understøtter:

• test management, der omfatter støtte til projektstyring, versioner, konfigurationer, risikoanalyse, test sporing, fejl, defekter, og rapporteringsværktøjer;
• kravstyring, som omfatter opbevaring krav og specifikationer, så tjek dem for fuldstændighed og tvetydighed, deres prioritet og sporbarhed af hver test;
• kritisk gennemgang og statisk analyse, herunder flow overvågning, og opgaver, registrering og opbevaring af kommentarer defekt afsløring og planlagte rettelser management links til checklister og regler, tracking kilde kommunikation dokumenter og kode statisk analyse til påvisning defekter og sikrer overensstemmelse med de standarder for at skrive kode, analyse af strukturer og afhængigheder, beregning af metriske parametre af koden og arkitektur. Derudover bruger oversættere, analysatorer, generatorer og forbindelser krydshenvisninger;
• modellering, som indeholder værktøjer til modellering forretningsadfærd og teste modellerne;
• test udvikling sikrer generering af data, der forventes på grundlag af betingelser og brugergrænseflade modeller og kode, formår at oprette eller ændre filer og databaser, messaging, data validering på grundlag af reglerne for ledelse, statistisk analyse af de betingelser og risici;
• kritisk ved at indtaste data via en grafisk brugergrænseflade, API, kommandolinjen med komparatorer til at identificere vellykkede og mislykkede forsøg;
• støtte debugging miljø, der giver mulighed for at erstatte den manglende hardware eller software, i bind. h. Simulering udstyr baseret på den fastlagte output delmængde, terminalemulatorer, mobiltelefoner og netværksudstyr, miljøet til kontrol sprog, operativsystemer og hardware ved at erstatte den manglende komponenter driver, fiktive moduler, etc., samt værktøjer til at opfange og modificere OS anmoder CPU simulering begrænsning, RAM, rOM, eller netværk .;
• .. En sammenligning af datafiler, databaser kontrollere de forventede resultater under og efter testen er færdig, inkl dynamisk og batch sammenligning, Automatisk "Orakler";
• belægning måling til lokalisering af memory leaks og forkert dens kontrol adfærd estimering systemet under simulerede belastning genererer belastning applikationer, databaser, netværk eller servere i et realistisk scenarie for vækst til måling, analyse og verifikation af systemressourcer;
• sikkerhed;
• performance test, belastning og dynamisk analyse;
• andre værktøjer, i bind. h. at kontrollere stavningen og syntaks, netværkssikkerhed, tilgængeligheden af alle websider og andre.

perspektiv

Med de skiftende tendenser i software-industrien, processen med debugging er også med forbehold for ændringer. Der er nye metoder til softwaretest, såsom en tjeneste-orientirovannae arkitektur (SOA), trådløse teknologier, mobile tjenester, og så videre. E., har åbnet op for nye måder at teste softwaren. Nogle af de ændringer, der forventes i industrien i de kommende år er angivet nedenfor:

• testere vil give en letvægts model, udviklere vil være i stand til at kontrollere din kode;
• udvikling af testmetoder, herunder visning og modellering programmer på et tidligt stadium, vil fjerne mange af de modsætninger;
• tilstedeværelsen af flere påvisninger test vil afkorte fejldetektering;
• Statisk analysator og detekteringsorganer til at være mere udbredt;
• anvendelse af mineralske matrixer, såsom dækning af specifikationen, vil omfanget af modellen og kode dækning bestemme udviklingen af projekter;
• kombinatoriske værktøjer giver testere til at bestemme de prioriterede områder for debugging;
• testere vil give en mere intuitiv og værdifulde tjenester i hele software udviklingsprocessen;
• debuggers kan oprette værktøjer og software testmetoder skrevet i og interagere med en bred vifte af programmeringssprog;
• Debugging eksperter vil blive mere professionelt uddannet.

Vil blive erstattet af en ny virksomhed-orienteret software testmetoder, at ændre den måde for interaktion med systemerne og de oplysninger, de giver samtidig reducere risici og øge fordelene ved de forretningsmæssige ændringer.