Softwaretest er en forskningsproces, der tester et softwareprodukt , som har til formål at kontrollere overensstemmelsen mellem programmets faktiske opførsel og dets forventede adfærd på et endeligt sæt af tests udvalgt på en bestemt måde ( ISO /IEC TR 19759:2005) [ 1] .
Forskellige definitioner er blevet givet til test på forskellige tidspunkter og i forskellige kilder, herunder:
De første softwaresystemer blev udviklet som en del af videnskabelige forskningsprogrammer eller programmer til forsvarsafdelingernes behov. Test af sådanne produkter blev udført på en strengt formaliseret måde med en registrering af alle testprocedurer, testdata og de opnåede resultater. Testning blev opdelt i en separat proces, som begyndte efter færdiggørelsen af kodningen, men som normalt blev udført af det samme personale.
I 1960'erne blev der lagt stor vægt på "udtømmende" test, som skulle udføres ved hjælp af alle stier i koden eller alle mulige input. Det blev bemærket, at under disse forhold er fuld softwaretest ikke mulig, fordi for det første er antallet af mulige input meget stort, for det andet er der mange stier, og for det tredje er det svært at finde problemer i arkitekturen og specifikationerne. Af disse grunde blev "udtømmende" test afvist og anset som teoretisk umuligt.
I begyndelsen af 1970'erne blev softwaretest omtalt som "processen med at demonstrere rigtigheden af et produkt" eller "aktiviteten med at verificere den korrekte funktion af software." I spirende softwareudvikling blev softwareverifikation omtalt som "bevis for rigtighed." Selvom konceptet teoretisk var lovende, var det i praksis tidskrævende og ikke omfattende nok. Det blev besluttet, at bevis for korrekthed var en ineffektiv metode til test af software. Men i nogle tilfælde bruges påvisning af korrekt drift stadig i dag, for eksempel accepttest. I sidste halvdel af 1970'erne blev test set som at køre et program med den hensigt at finde fejl, ikke bevise, at det virkede. En vellykket test er en test, der opdager hidtil ukendte problemer. Denne tilgang er direkte modsat den foregående. Disse to definitioner repræsenterer "testparadokset", som er baseret på to modsatte udsagn: På den ene side giver test dig mulighed for at sikre dig, at produktet fungerer godt, og på den anden side afslører det fejl i programmer, hvilket viser, at produktet virker ikke. Det andet mål med test er mere produktivt med hensyn til kvalitetsforbedring, da det ikke tillader softwarefejl at blive ignoreret.
I 1980'erne blev test udvidet til at omfatte defektforebyggelse. Testdesign er den mest effektive kendte fejlforebyggende teknik. Samtidig begyndte der at komme tanker om, at der var behov for en testmetodologi, især at test skulle omfatte kontrol gennem hele udviklingscyklussen, og dette skulle være en kontrolleret proces. Under test er det nødvendigt at kontrollere ikke kun det samlede program, men også kravene, koden, arkitekturen og selve testene. "Traditionel" test, som eksisterede indtil begyndelsen af 1980'erne, refererede kun til det kompilerede, færdige system (nu almindeligvis omtalt som systemtest), men siden da er testere blevet involveret i alle aspekter af udviklingens livscyklus. Dette gjorde det muligt at finde problemer i kravene og arkitekturen tidligere, og derved reducere udviklingstiden og budgettet. I midten af 1980'erne dukkede de første værktøjer til automatiseret test op. Computeren skulle være i stand til at udføre flere test end et menneske, og at gøre det mere pålideligt. I starten var disse værktøjer ekstremt enkle og havde ikke evnen til at skrive scripts på scriptsprog.
I begyndelsen af 1990'erne begyndte begrebet "test" at omfatte planlægning, design, oprettelse, vedligehold og eksekvering af test og testmiljøer, og det betød en overgang fra test til kvalitetssikring, der dækkede hele softwareudviklingscyklussen. På dette tidspunkt begyndte forskellige softwareværktøjer at dukke op for at understøtte testprocessen: mere avancerede automatiseringsmiljøer med evnen til at oprette scripts og generere rapporter, teststyringssystemer og indlæse testsoftware. I midten af 1990'erne, med udviklingen af internettet og udviklingen af et stort antal webapplikationer, begyndte "agile test" (svarende til agile programmeringsmetoder) at vinde særlig popularitet.
Der er flere kriterier, som det er sædvanligt at klassificere typer af test efter. Normalt er der følgende:
Ifølge testobjektetOfte for gratis og open source-software, karakteriserer alfa-teststadiet det funktionelle indhold af koden, og beta- test karakteriserer fejlretningsstadiet. Samtidig er der som regel på hvert udviklingstrin mellemliggende resultater af arbejdet tilgængelige for slutbrugerne.
De teknikker, der er beskrevet nedenfor - test af hvid boks og test af sort boks - antager, at koden udføres, og forskellen er kun i den information, som testeren har. I begge tilfælde er dette dynamisk test .
Under statisk test udføres programkoden ikke - programmet analyseres ud fra kildekoden, som læses manuelt eller analyseres af specialværktøjer. I nogle tilfælde er det ikke kildekoden, der analyseres, men mellemkoden (såsom bytekode eller MSIL -kode ).
Statisk test omfatter også testkrav , specifikationer og dokumentation .
Efter at have foretaget ændringer i den næste version af programmet, bekræfter regressionstest, at de foretagne ændringer ikke påvirkede ydeevnen af resten af applikationens funktionalitet. Regressionstest kan udføres både manuelt og med testautomatiseringsværktøjer .
Testere bruger testscenarier på forskellige niveauer: både i komponenttest og i integration og systemtest. Testscripts er normalt skrevet for at teste komponenter, der med størst sandsynlighed vil fejle, eller en fejl, der ikke findes i tide, kan være dyr.
Afhængig af testudviklerens adgang til kildekoden for det testede program, skelnes der mellem " testning (efter strategi) af en hvid boks " og " testning (efter strategi) af en sort boks ".
I white box testing (også kaldet transparent box testing ) har testudvikleren adgang til kildekoden for programmerne og kan skrive kode, der linker til bibliotekerne i den software, der testes. Dette er typisk for komponenttest, hvor kun dele af systemet testes. Det sikrer, at de strukturelle komponenter til en vis grad er funktionelle og stabile. White box-testning bruger kodedækningsmålinger eller mutationstest .
Ved black box-test har testeren kun adgang til programmet via de samme grænseflader som kunden eller brugeren, eller via eksterne grænseflader, der tillader en anden computer eller anden proces at forbinde til systemet til test. For eksempel kan en testkomponent virtuelt trykke på taster eller museknapper i det testede program ved hjælp af proceskommunikationsmekanismen, med tillid til, at alt går godt, at disse hændelser forårsager samme respons som rigtige tastetryk og museknapper. Som udgangspunkt udføres black box test ved hjælp af specifikationer eller andre dokumenter, der beskriver kravene til systemet. I denne type test er dækningskriteriet typisk summen af inputdatastrukturdækning , kravdækning og modeldækning (i modelbaseret testning ).
Ved test af grå boks har testudvikleren adgang til kildekoden, men når man kører test direkte, kræves der normalt ikke adgang til koden.
Mens "alfa" og "beta-testning" refererer til stadierne før et produkt frigives (og også, implicit, til størrelsen af testfællesskabet og begrænsninger for testmetoder), henviser white box og black box test til de måder, hvorpå testeren når målet.
Beta-test er generelt begrænset til black box-teknikker (selvom en konsekvent undergruppe af testere normalt fortsætter white box-testning parallelt med beta-test). Således kan udtrykket "beta-testning" angive programmets tilstand (tættere på udgivelsen end "alfa"), eller det kan indikere en bestemt gruppe af testere og den proces, der udføres af denne gruppe. Det vil sige, at en tester kan fortsætte med at arbejde med white-box-test, selvom programmet allerede er "beta", men i dette tilfælde er det ikke en del af "beta-testen".
Kodedækning viser procentdelen af et programs kildekode, der blev udført ("dækket") under test. I henhold til målemetoderne, operatørdækning, tilstandsdækning, stidækning, funktionsdækning mv.
| Softwareudvikling | |
|---|---|
| Behandle | |
Koncepter på højt niveau | |
| Vejbeskrivelse |
|
| Udviklingsmetoder _ | |
| Modeller | |
| Bemærkelsesværdige tal |
|