Fremgangsmåter for testing av programvare og sammenligne dem. Testing metode for "black box" testing og metoden for "white box"

Testing programvare (SW) identifisere hull, mangler og feil i koden som må tas opp. Det kan også defineres som prosessen med å evaluere funksjonaliteten og riktigheten av programvaren ved hjelp av analysen. Grunnleggende metoder for integrasjon og testing av programvare og sikre kvalitet er å teste spesifikasjonen, design og koding, pålitelighet vurdering, validering og verifisering.

fremgangsmåter

Hovedformålet med software testing - bekreftelse av kvaliteten på programvaren systemet gjennom systema debugging applikasjoner under nøye kontrollerte forhold for å bestemme sin fullstendighet og nøyaktighet, samt påvisning av skjulte feil.

Metodene for verifikasjon (testing) programmer kan deles inn i statisk og dynamisk.

Den førstnevnte omfatter uformell, overvåking og teknisk gjennomgang, inspeksjon, trinnvis analyse, revisjon, samt statisk dataflyt og -styring.

Dynamiske teknikker er:

1. Hvit boks testing. Dette er en detaljert studie av den interne logikk og struktur av programmet. Det er nødvendig å kunnskap om kildekoden.
2. Black box testing. Denne teknikken krever ingen kunnskap om den interne driften av programmet. Vi anser bare de grunnleggende aspekter av systemet, som ikke er knyttet til eller forbundet med noen av sin interne logiske strukturen.
3. Grå boksen metode. Den kombinerer to tidligere tilnærminger. Feilsøking med begrenset kjennskap til den interne funksjon av programmet er kombinert med kunnskap om de grunnleggende aspekter av systemet.

gjennomsiktig testing

De hvite boks metode ved å bruke testskript kontrollere strukturen av prosedyre utforming. Denne teknikken gjør det mulig å avsløre implementeringsfeil, slik som dårlig styring kodesystem ved å analysere en del av den interne driften av programvaren. Disse testfremgangsmåtene kan anvendes integrering, modul- og nivåer. Testeren må ha tilgang til kildekoden og bruke den til å finne ut hvilken enhet oppfører seg upassende.

Testing programmer ved white-box har følgende fordeler:

• Det gjør det mulig å påvise en feil i den skjulte koden ved å fjerne unødvendige linjer;
• bruken av bivirkninger;
• maksimal dekning oppnås ved å skrive en test script.

ulemper:

• høye kostnader prosess, som krever dyktig feilsøkingsprogram;
• mange veier er fortsatt uutforsket grunn grundig sjekk av alle mulige skjulte feil er svært komplisert,
• noen av koden vil bli vedtatt ubemerket.

Som testes er noen ganger referert til ved å teste en gjennomsiktig eller åpen boks, strukturelle, logiske tester, basert på kildekoden, og logiske arkitektur.

De viktigste varianter:

1) testing av strømningsstyre - strukturell strategi ved hjelp av programstyringen strømningsmodell og som begunstiger flere enkle måter å færre mer kompleks;

2) gren er utformet for å studere feilsøkings hvert alternativ (sann eller usann) av hver styre operatør, som også inkluderer en kombinert løsning;

3) testing av hovedbanen, noe som gjør at testeren for å etablere logisk kompleksitetsmål prosedyre prosjekt for isolering av et tilhørende sett av utførelse baner;

4) kontroll av datastrømmen - strømningskontrollstrategien av forskning ved merknadene telle informasjon om annonsen og bruke programvariabler;

5) sykluser med testing - fullt fokusert på korrekt drift av sirkelprosesser.

atferds debugging

Svart boks testing behandler programvaren som en "black box" - informasjon om den interne driften av programmet telles ikke, og sjekket bare de grunnleggende aspekter av systemet. I dette tilfellet må testeren å vite systemarkitekturen uten tilgang til kildekoden.

Fordelene med denne tilnærmingen:

• effektivitet for stor kodesegment;
• letthet ved persepsjon tester;
• brukerperspektiv er klart adskilt fra utvikleren perspektiver (programmerer og tester er uavhengig av hverandre);
• mer rask etablering av testen.

Testing programvare svart boks metode har følgende ulemper:

• faktisk utført et begrenset antall testtilfelle, noe som resulterer i begrenset dekning;
• mangel på en klar angivelse vanskelig å utvikle testskript;
• lav effektivitet.

Andre navn for denne teknologien - atferdsmessige, ikke-transparent, funksjonell testing og feilretting metode av en lukket boks.

Denne kategorien kan omfatte følgende programvare testing teknikker:

1) tilsvarende skillevegg, som kan redusere sett med testdata som inngangsdata programvaremodulen er delt opp i adskilte deler;

2) grenseverdianalyse fokuserer på verifikasjon av grensene eller ekstreme grenseverdier - minimum, maksimum, og typiske verdier for feil;

3) dannelse av uklarhet - anvendt for å utføre søk ved å legge inn feil eller ødelagte data poluiskazhennyh i automatisk eller halvautomatisk modus;

4) tellinger av kausalitet - en teknikk basert på etablering av grafer, og å bestemme forholdet mellom handling og dens årsaker: identitet, negasjon, logisk ELLER og logisk OG - de fire hovedfigurene, som uttrykker forholdet mellom årsak og virkning;

5) Verifisering av ortogonale matriser påført på problemer med en relativt liten inngangs areal som overstiger det mulighet for grundig forskning;

6) testing av alle parene - en teknikk der et sett med testverdier omfatter alle mulige binære kombinasjoner av hvert par av inngangsparametre;

7) feilretting tilstandsovergang - en teknikk som brukes ved kontroll av status for maskinen, så vel som for å navigere gjennom GUI brukeren.

Svart boks testing: Eksempler

black-box teknikk er basert på spesifikasjoner, dokumentasjon og beskrivelser av programvaren grensesnittet eller system. I tillegg kan du bruke modeller (formelle eller uformelle), som representerer den forventede oppførselen av programvaren.

Vanligvis er denne metode anvendt for feilsøking brukergrensesnitt og krever interaksjon med programmet ved å innføre en datainnsamling og resultater - fra skjermen, fra rapportene eller utskrift.

Testeren derfor samvirker med programmet ved å legge inn, ved å påvirke brytere, knapper eller andre grensesnitt. Valget av inngangsdata, kan rekkefølgen av administrering eller sekvens av handlinger for å føre et stort antall kombinasjoner, slik det er vist i det følgende eksempel.

Hvor mange tester må gjøre for å sjekke alle mulige verdier for 4 vinduer flagg og one-off-feltet, angi tiden i sekunder? Ved første øyekast beregning er enkel: 4 felt med to mulige tilstander - 24 = 16, som må multipliseres med antall mulige posisjoner fra 00 til 99, dvs. 1600 mulige tester.

Imidlertid er denne beregningen feil: vi kan fastslå at de to-point feltet kan også inneholde et mellomrom, dvs. den består av to alfanumeriske posisjoner, og kan inneholde alfanumeriske tegn, spesialtegn, mellomrom, etc. Dermed, hvis .... systemet er en 16-bit datamaskin, slår 216 = 65 536 en for hver posisjon i de resulterende 4294967296 testtilfeller som skal multipliseres med 16 kombinasjoner av flagg som gir totalt 68719476 736. Hvis de utfører ved en test i sekundet, den totale forts olzhitelnost testing er 2 177,5 år. For 32 eller 64-bits systemer, varigheten enda mer.

Derfor er det et behov for å redusere denne periode til et akseptabelt nivå. Således bør de teknikker som anvendes for å redusere antall testtilfelle uten å redusere omfanget av testingen.

ekvivalensklasseinndeling

Den tilsvarende skillevegg er en enkel metode som er anvendelig for alle variabler som er tilstede i programvaren, enten inngangs- eller utgangsverdier, symbolsk, numerisk, og andre. Den er basert på prinsippet om at alle data fra én ekvivalent av skilleveggen vil bli behandlet på samme måte og ved de samme instruksjonene.

Under testing valgt en representant for hver spesiell ekvivalensinndeling. Dette gjør det mulig å systematisk redusere antall mulige testtilfelle uten tap av dekning av kommandoer og funksjoner.

En annen konsekvens av denne oppdeling er å redusere det kombinatoriske eksplosjon mellom de ulike variablene og dermed forringelse av testtilfeller.

For eksempel, i (1 / x) ^1/2 ved hjelp tre datasekvenser, tre tilsvarende skillevegg:

1. Alle positive tall vil bli behandlet på samme måte, og bør gi korrekte resultater.

2. Alle negative tall blir håndtert på samme måte med samme resultat. Dette er ikke riktig, fordi roten av et negativt tall er imaginær.

3. Zero vil bli behandlet separat og gi feil "divisjon med null". Dette er et snitt med en enkelt verdi.

Vi ser derfor i tre atskilte deler, hvorav den ene er redusert til en enkeltverdi. Det er en "riktig" -delen, som gir pålitelige resultater, og to "galt" med feil resultater.

grenseverdianalyse

Prosessering på grensen til tilsvarende partisjonering kan gjøres annerledes enn forventet. Undersøkelse av grenseverdier - en velkjent metode for å analysere oppførselen til programvare i slike områder. Denne teknikken gjør det mulig å identifisere slike feil:

• uriktig bruk av relasjonsoperatorene (<,>, =, ≠, ≥, ≤);
• enkeltfeil;
• problemer i sykluser og gjentakelser,
• feil type eller størrelse av variabler som brukes for lagring av informasjon;
• kunstige begrensninger forbundet med datatyper og variabler.

gjennomskinnelig testing

grå boks metoden øker testdekning, kan du fokusere på alle de vanskelige nivåer i systemet gjennom en kombinasjon av svart og hvitt teknikker.

Ved hjelp av denne teknikken, bør testeren for utvikling av testverdiene har kjennskap til interne datastrukturer og algoritmer. Eksempler på grå-box testmetoder er som følger:

• arkitektoniske modell;
• Unified Modeling Language (UML);
• tilstandsmodell (finite state machine).

I fremgangsmåten i den grå boksen for å utvikle testtilfeller studert moduler i hvite ingeniørkoder, og selve testen utføres på grensesnittene i svart teknologiprogrammer.

Disse testmetoder har følgende fordeler:

• kombinasjon av fordeler tekniker hvite og sorte bokser;
• Tester er basert på grensesnittet og funksjonell spesifikasjon, og ikke kildekoden;
• debugger kan gjøre stor test tilfeller;
• sjekk er gjort fra synspunkt av brukeren, ikke designeren av programmet;
• opprette egendefinerte test utvikling;
• objektivitet.

ulemper:

• testdekning er begrenset fordi det ikke er tilgang til kildekoden;
• kompleksiteten av defekter i distribuerte applikasjoner;
• mange måter fortsatt uutforsket;
• hvis programvareutvikler har lansert testen, deretter videre etterforskning kan være overdreven.

Et annet navn for de grå boks teknikker - gjennomskinnelig debugging.

Denne kategorien inkluderer slike metoder for testing:

1) vinkelrett mønster - bruk av et delsett av alle mulige kombinasjoner;

2) matrise feilsøking ved hjelp av tilstanden til programdata;

3) regressive inspeksjon utført ved de nye endringer i programvaren;

4) mal test som analyserer design og arkitektur av en god søknad.

Sammenligning av programvare testteknikker

Bruken av dynamiske metoder fører til et kombinatorisk eksplosjon av antallet tester som må utvikles, implementert og utført. Hver teknikk bør brukes pragmatisk, tar sine begrensninger i betraktning.

Den eneste sanne metoden ikke eksisterer, er det bare de som er bedre egnet for den spesifikke kontekst. Konstruksjonsteknikk tillate oss å finne en ubrukelig eller ondsinnet kode, men de er komplekse og gjelder ikke for store programmer. Metoder basert på spesifikasjoner - de eneste som er i stand til å identifisere den manglende kode, men de kan ikke identifisere en outsider. Noen teknikker er mer egnet for et bestemt testnivå, feiltypen eller sammenheng enn andre.

Nedenfor er de viktigste forskjellene mellom de tre dynamiske testteknikker - gis en sammenligningstabell mellom de tre former for feilsøking programvare.

aspektet	Den svarte boksen metode	Grå boksen metode	White-box metoden
Tilgjengeligheten av informasjon om sammensetningen av programmet	Undersøker bare de grunnleggende aspekter av	Delvis kunnskap om den interne strukturen i programmet	Full tilgang til kildekoden
Grad av fragmentering av programmet	lav	Central	høy
Hvem produserer debugging?	Sluttbrukere, testere og utviklere	Sluttbrukere, utviklere og debuggere	Utviklere og testere
basen	Testing er basert på eksterne krisesituasjoner.	Diagrammer database, dataflytdiagrammer, tilstand indre kunnskap av algoritmen og arkitektur	Den interne enheten er fullt klar
Dekningsgraden	Mindre omfattende og krever et minimum av tid	Central	Potensielt den mest omfattende. Tidkrevende
Data og de indre grenser	Debug bare ved prøving og feiling	Kan kontrolleres data domener og indre grenser, hvis de er kjent	De beste testdata domener og indre grenser
Egnethet testing algoritmen	ikke	ikke	Ja

automatisering

Automatiske metoder for software testing er mye forenkle prosessen med inspeksjon, uavhengig av teknisk miljø og kontekst. De brukes i to tilfeller:

1) å automatisere de kjedelige, repeterende eller nitid oppgaver som fil sammenligning til flere tusen rader for å frigjøre tid for konsentrering av testeren mer viktige poeng;

2) for å utføre sporing eller oppgaver som ikke lett kan utføres av folk som ytelse verifisering eller analyse responstiden som kan måles i hundredeler av et sekund.

Testverktøy kan klassifiseres på forskjellige måter. Den neste divisjonen er basert på de oppgavene de støtter:

• test, som også inkluderer prosjektstøtte styring, versjoner, konfigurasjoner, risikoanalyse, test sporing, feil, defekter, og rapporteringsverktøy;
• krav styring, som omfatter lagrings krav og spesifikasjoner, kontrollerer dem er fullstendig og tvetydighet, deres prioritet og sporbarhet av hver test;
• kritisk og statisk analyse, inkludert væskeovervåkning, og oppgaver, registrering og lagring av kommentarene, feil deteksjon og planlagte korreksjoner lederforbindelser til lister og regler, sporing kommunikasjon kildedokumenter og kode statisk analyse for å finne feil, for å sikre samsvar med de standarder for å skrive koden, analyse av strukturer og avhengigheter, beregning av de metriske parametrene i koden og arkitektur. I tillegg bruker kompilatorer, analysatorer, generatorer og forbindelser av kryssreferanser;
• modellering, som inkluderer verktøy for modellbransjen atferd og teste modeller;
• test utvikling sikrer generering av data som forventes på grunnlag av forhold og brukergrensesnitt modeller og kode, klarer å opprette eller endre filer og databaser, meldinger, data validering på grunnlag av reglene i ledelse, statistisk analyse av forholdene og risiko;
• et kritisk syn ved å legge inn data via et grafisk brukergrensesnitt, API, kommandolinje ved hjelp av komparatorer for å bidra til å identifisere vellykkede og mislykkede forsøk;
• støtte debugging miljø som gjør det mulig å erstatte den manglende maskinvare eller programvare, i Vol. h. Simulering utstyr basert på bestemt utgang undergruppe, terminalemulatorer, mobiltelefoner og nettverksutstyr, miljø for å sjekke språk, operativsystemer og maskinvare ved å erstatte manglende komponenter driver, fiktive moduler, etc., såvel som verktøy for å fange og å modifisere OS ber CPU simuleringen ikke begrenset til, RAM, ROM, eller nettverk .;
• .. En sammenligning av datafiler, databaser, sjekk de forventede resultater under og etter testen er fullført, inkl dynamisk og batch sammenligning Automatisk "Oracles";
• belegg måling for lokalisering av minne lekkasjer og feil dens kontroll oppførsel estimere system under simulerte belastning genererende belastninger, databaser, nettverk eller servere i en realistisk situasjon for vekst for måling, analyse og verifikasjon av systemressurser rapport;
• sikkerhet;
• ytelsestesting, belastning og dynamisk analyse;
• andre verktøy, i Vol. h. å kontrollere staving og syntaks, nettverkssikkerhet, tilgjengeligheten av alle nettsider og andre.

perspektiv

Med skiftende trender i programvareindustrien, er prosessen med debugging er også endres. Det er nye metoder for software testing, for eksempel en tjeneste-orientirovannae arkitektur (SOA), trådløse teknologier, mobile tjenester, og så videre. E., har åpnet opp nye måter å teste programvare. Noen av endringene som forventes i bransjen i løpet av de neste årene er listet nedenfor:

• testere vil gi en lett modell som utviklere vil være i stand til å sjekke koden din;
• utvikling av testmetoder, herunder visning og modelleringsprogram på et tidlig stadium, vil eliminere mange av motsetninger;
• tilstedeværelsen av flere avskjær test vil forkorte tiden for feildeteksjon;
• Statisk analysator og anordning for å bli mer utbredt;
• bruken av mineral matrikser, som for eksempel dekning av beskrivelsen, vil omfanget av modellen og kodedekning bestemme utviklingen av prosjekter;
• kombinatoriske verktøyene lar testere å bestemme de prioriterte områdene for debugging;
• testere vil gi en mer intuitiv og verdifulle tjenester i hele programvareutvikling prosessen;
• debuggers kan skape verktøy og programvare testmetoder som er skrevet i, og i samspill med en rekke programmeringsspråk;
• Debugging eksperter vil bli mer profesjonelt trenet.

Vil bli erstattet av en ny forretningsorientert programvare testmetoder, å endre måten for interaksjon med systemer og informasjonen de gir samtidig redusere risiko og øke nytten av de forretningsmessige endringer.