Testing programmer - feildeteksjon prosess i programvareprodukt

I programvareutvikling, blir en betydelig del av produksjonsprosessen basert på programvare testing. Hva er det og hvordan er slik aktivitet vil diskutere i denne artikkelen.

Hva kalles en test?

Dette refererer til prosessen med å kjøre programvaren for å påvise plasseringen av feil bruk av koden. For best resultat, bevisst konstruert vanskelig sett av inngangsdata. Hovedformålet med undersøkelsen er å skape den beste muligheten for svikt av programvare. Selv om noen ganger testing av utviklet program kan forenkles til en rutinemessig kontroll av arbeidskapasitet og utføre de funksjoner. Dette sparer tid, men er ofte ledsaget av upålitelighet av programvaren, bruker misnøye, og så videre.

effektivitet

Hvor godt og raskt er feil, en betydelig innvirkning på kostnadene og varigheten av programvareutvikling ønsket kvalitet. Så, til tross for at testere motta lønn flere ganger mindre enn utviklerne, er kostnaden for sine tjenester vanligvis opp til 30 - 40% av kostnadene for hele prosjektet. Dette er på grunn av antall personell, siden letingen etter feil - dette er en uvanlig og ganske vanskelig prosess. Men selv om programvaren er vedtatt en respektabel rekke tester, er det ingen 100% garanti for at feilen ikke vil skje. Bare vet ikke når de oppstår. For å oppmuntre testere til å velge hvilke typer tester som er mer sannsynlig å finne feil, ulike motivasjons verktøy brukt: både moralsk og materiell.

Tilnærming til arbeidet

Det optimale er når man skal gjennomføre ulike mekanismer for å sikre at feil i programvaren ikke har vært fra begynnelsen. For å gjøre dette, må du ta vare på riktig arkitektur design, klare mandat, og det er viktig ikke å foreta justeringer i kommunikasjon, da arbeidet med prosjektet har allerede begynt. I dette tilfellet, testeren til oppgaven med å finne og identifisere et lite antall feil som er igjen i det endelige resultatet. Dette vil spare både tid og penger.

Hva er testen?

Dette er en viktig del av kontrollvirksomheten, som er nødvendig for en vellykket oppdagelse av feil i koden. De er nødvendige for å kontrollere riktig program. Hva er inkludert i testen? Det består av data og deres startverdier som skal oppnås, fordi den resulterende (eller mellomprodukt). For å kunne identifisere problemer og uoverensstemmelser, skal testene være etter algoritmen ble utviklet, men fikk ikke starte programmering. Det er ønskelig å bruke flere fremgangsmåter for å estimere de nødvendige data. I dette tilfellet, øker sannsynligheten for å oppdage en feil fordi du kan undersøke koden fra et annet perspektiv. Komplekse tester må gi verifikasjon av eksterne virkninger av de ferdige programvareprodukter, så vel som hans arbeids algoritmer. Av spesiell interesse og gi marginale degenererte tilfeller. Derfor, i praksis av feil kan ofte avsløre at syklusen opererer på en eller flere ganger mindre enn planlagt. Også viktig er datamaskinen testing, der du kan bekrefte at det ønskede resultatet på forskjellige maskiner. Dette er nødvendig for å sørge for at programvaren vil fungere på alle datamaskiner. I tillegg datamaskinen test, der utbyggingen skal gjennomføres, er viktig i etableringen av multi-plattform utvikling.

feilsøkings Arts

Programmer ofte tar sikte på å arbeide med store datasett. Er det nødvendig å skape helt? Nei. Utbredt kjøpt praksisen med "miniatyrisering" av programmet. I dette tilfellet er det en rimelig reduksjon av datavolumet i forhold til det skal brukes. La oss se på et eksempel: det er et program, som skaper en matrise av størrelse 50x50. Med andre ord - du må manuelt inn 2500 verdier. Det er sikkert mulig, men det vil ta svært lang tid. Men for å teste funksjonaliteten, mottar programvaren en matrise som dimensjon er 5x5. For å gjøre dette, må du skrive inn mer enn 25 verdier. Dersom det i dette tilfellet, en normal, feilfri drift, betyr det at alt er i orden. Selv om det er fallgruver som ligger i det faktum at med miniatyrisering situasjonen oppstår, noe som resulterer i forandring blir implisitt og midlertidig forsvinne. Det er også svært sjelden, men likevel skjer er at det er nye bugs.

målsettinger forfulgt

Testing er ikke en lett oppgave på grunn av det faktum at denne prosessen er ikke mottagelig for formalisering i sin helhet. Store programmer nesten aldri har den nødvendige nøyaktig benchmark. Derfor, som en retningslinje ved hjelp av en rekke indirekte data, som imidlertid ikke fullt ut reflekterer egenskapene og funksjonene til programvareutvikling som feilsøkes. Videre bør de velges slik at riktig resultat beregnet før hvordan programvaren vil bli testet. Hvis du ikke videre, er det fristende å tenke seg om, og hvis resultatet av maskinen kommer i forventet område, vil det bli gjort en feil beslutning, at alt er riktig.

Sjekk under ulike forhold

Som regel forekommer program testing i volumer som er nødvendig for den minimale prøve funksjonalitet til en begrenset grad. Aktiviteter utført med endring av parametrene, samt deres arbeidsforhold. Testprosessen kan deles inn i tre faser:

• Sjekk under normale forhold. I dette tilfellet tester vi den grunnleggende funksjonaliteten til utviklet programvare. Resultatet må tilsvare forventet.
• Sjekk under ekstreme forhold. I disse tilfellene, som synonymt med grensedata, noe som kan påvirke ytelsen til laget programvare. Som et eksempel, arbeider vi med en ekstremt store eller små tall eller selv fullstendig fravær av informasjon mottatt.
• Sjekker inn spesielle situasjoner. Det innebærer bruk av data som er utenfor behandling. I slike situasjoner er det svært dårlig når programvaren oppfatter dem som nyttige for beregning og gir en plausibel resultat. Hensyn må tas at i slike tilfeller er det en avvisning av alle data som ikke kan behandles riktig. Det er også nødvendig å sørge for å informere brukeren om det

Testing: Typer

Lage programvare uten feil er svært vanskelig. Dette krever en betydelig mengde tid. For å få et godt produkt er ofte brukt to typer testing: "Alpha" og "Beta". Hva er de? Når folk snakker om alpha testing, betyr det at en vurdering skal gjennomføres selv i delstaten utvikling "laboratorium" forhold. Dette er den siste fasen av testing før programmet vil bli overført til sluttbrukere. Derfor er utviklere prøver å snu det maksimale. For enkel betjening, kan data være logget inn for å skape en kronologi over problemer og deres løsninger. Under beta test for å forstå levering av programvaren til et begrenset antall brukere, slik at de kan utnytte programmet og identifisere de feilene du har gått glipp av. Et særtrekk i dette tilfellet er det faktum at ofte programvaren er ikke brukt til sitt formål. På grunn av denne feilen vil bli identifisert der det ikke var noe før sett. Dette er helt normalt og bekymring om det ikke er nødvendig.

test Gjennomføring

Hvis de foregående trinnene er fullført, gjenstår det å utføre godkjenningstester. Han i dette tilfellet blir en ren formalitet. I løpet av denne testen kommer bekreftelse på at ingen flere problemer har blitt funnet og programvaren kan slippes på markedet. Det viktigste vil være sluttresultatet, jo tettere det skal verifiseres. Forsiktighet bør tas for å sikre at alle trinnene er fullført. Her er testprosessen som helhet. Nå la oss i dybden av de tekniske detaljene og snakke om et slikt nyttig verktøy, som testprogrammene. Hva de er og når de brukes?

dataassistert testing

Tidligere ble det antatt at dynamisk analyse av utviklet programvare - det er for tungt tilnærming som effektivt brukes til å oppdage feil. Men på grunn av den økende kompleksiteten og volumet av programmene dukket motsatte syn. Automatisert testing brukes der de viktigste prioriteringer er effektivitet og sikkerhet. Og de bør være under noen innspill. Som et eksempel, de programmer som det er hensiktsmessig for slik testing, innbefatter følgende: nettverksprotokoller, web-server, testmiljøer. Vi fortsetter å se på noen eksempler som kan brukes til slike aktiviteter. Hvis du er interessert i gratis testprogrammer, er kvaliteten vanskelig å finne blant dem. Men det er sprukket "piratkopierte" versjoner av de godt etablerte prosjekter, slik at du kan referere til sine tjenester.

snøskred

Dette verktøyet hjelper til å oppdage defekter testes programmer i det dynamiske analysemodus. Det samler inn data og analyserer resultatene av spor utformet gjenstand. Testeren er gitt et sett med innganger som forårsaker feil eller omgå det eksisterende sett av begrensninger. Takket være en god test av algoritmen utviklet av et stort antall mulige situasjoner. Programmet mottar et annet sett med inngangsdata, som gjør det mulig å simulere et stort antall situasjoner og skape betingelser hvor den mest sannsynlige er forekomsten av en feil. En viktig fordel med programmet er bruk av heuristiske beregning. Hvis det er et problem, da programfeil er høyst sannsynlig. Men dette programmet har begrensninger, slik som kun en sjekk merket inngangskontakten eller fil. Ved gjennomføring av en operasjon som for eksempel testprogrammer vil inneholde informasjon om problemene med nullpeker, uendelige løkker, feil adresser eller funksjonsfeil som skyldes bruken av bibliotekene. Selvfølgelig, dette er ikke en komplett liste over oppdagede feil og deres eneste vanlige eksempler. Retting av mangler dessverre har utviklere - automatiske metoder er ikke egnet for disse formål.

KLEE

Det er et godt program for å teste hukommelsen. Det kan oppfange ca. 50 systemkall og et stort antall av således utføres i parallell eller separat virtuelle prosesser. Men generelt, er programmet ikke ute etter noen mistenkelige steder, og behandler den maksimalt mulige mengden med kode og analyser brukes databaner. På grunn av dette, avhenger av testprogrammet på størrelsen på objektet. Når du sjekker spillet er plassert på symbolske prosesser. De er en av de mulige måter å utføre oppgaver i et program som er testet. Takket være parallell drift er mulig å analysere et stort antall varianter av arbeidet til testapplikasjon. Til hver bane av inngangsdatasettene er lagret etter sin test, som begynte med kontrollen. Det bør bemerkes at testprogrammer som bruker KLEE bidrar til å identifisere et stort antall varianter, som ikke bør være. Det kan finne problemer selv i applikasjoner som er utviklet i flere tiår.