software testing terms complete glossary
For å unngå uklarheter i forskjellige programvaretestbetingelser vedlegger jeg en ordliste for programvaretesting her.
Alle vilkår for testing av programvare er inkludert i denne ordlisten. Hvis du føler at du kjenner definisjonen av et begrep bedre enn nevnt her, kan du bruke dette Kontakt skjema å sende meg definisjonene. På gjennomgang vil jeg ta dem med i denne ordlisten.
For å vite med de grunnleggende definisjonene av programvaretesting og kvalitetssikring, er dette den beste ordlisten utarbeidet av Erik van Veenendaal . Også for hver definisjon er det en referanse av IEEE eller ISO nevnt i parentes.
TIL
akseptkriterier: Utgangskriteriene som en komponent eller et system må oppfylle for å væreakseptert av en bruker, kunde eller annen autorisert enhet. (IEEE 610)
aksept testing: Formell testing med tanke på brukerbehov, krav og forretningsprosesser utført for å avgjøre om et system oppfyller akseptkriteriene eller ikke, og for å gjøre det mulig for brukeren, kundene eller annen autorisert enhet å avgjøre om systemet skal akseptere. (Etter IEEE 610)
tilgjengelighetsprøving: Testing for å bestemme hvor enkelt brukere med funksjonshemninger kan bruke en komponent eller et system. (Gerrard)
nøyaktighet: Programvareproduktets evne til å gi de riktige eller avtalte resultatene eller effektene med den nødvendige grad av presisjon. (ISO 9126) Se også funksjonstesting.
egentlige resultatet: Atferden som produseres / observeres når en komponent eller et system testes.
ad hoc-testing: Testing utført uformelt; ingen formell testforberedelse finner sted, ingen anerkjent testdesignteknikk brukes, det er ingen forventninger til resultater og tilfeldighet styrer testutførelsesaktiviteten.
tilpasningsevne: Programvareproduktets evne til å tilpasses forskjellige spesifiserte miljøer uten å bruke andre handlinger eller midler enn de som er gitt for dette formålet for programvaren som vurderes. (ISO 9126) Se også testing av bærbarhet.
smidig testing: Testpraksis for et prosjekt ved bruk av smidige metoder, for eksempel ekstrem programmering (XP), behandler utvikling som kunde for testing og understreker test-første designparadigmet.
alfatesting: Simulert eller faktisk operasjonell testing av potensielle brukere / kunder eller et uavhengig testteam på utviklerens nettsted, men utenfor utviklingsorganisasjonen. Alfa-testing brukes ofte som en form for intern akseptantesting.
analyserbarhet: Programvareproduktets evne til å bli diagnostisert for mangler eller årsaker til feil i programvaren, eller for å identifisere delene som skal modifiseres. (ISO 9126) Se også testing av vedlikeholdsevne.
anomali: Enhver tilstand som avviker fra forventning basert på kravspesifikasjoner, designdokumenter, brukerdokumenter, standarder osv. Eller fra noens oppfatning eller erfaring. Avvik kan bli funnet under, men ikke begrenset til, gjennomgang, testing, analyse, kompilering eller bruk av programvareprodukter eller gjeldende dokumentasjon. (IEEE 1044) Se også feil, avvik, feil, feil, feil, hendelse, problem.
attraktivitet: Programvareproduktets evne til å være attraktiv for brukeren. (ISO 9126)
revidere: En uavhengig evaluering av programvareprodukter eller prosesser for å sikre overholdelse av standarder, retningslinjer, spesifikasjoner og / eller prosedyrer basert på objektive kriterier, inkludert dokumenter som spesifiserer:
(1) form eller innhold av produktene som skal produseres
(2) prosessen der produktene skal produseres
(3) hvordan samsvar med standarder eller retningslinjer skal måles. (IEEE 1028)
revisjonsspor: En bane der den originale inngangen til en prosess (f.eks. Data) kan spores tilbake gjennom prosessen, og tar utgangsprosessen som utgangspunkt. Dette letter feilanalyse og gjør det mulig å utføre en prosessrevisjon. (Etter TMap)
automatisert testvare: Testware som brukes i automatisert testing, for eksempel verktøyskripter.
tilgjengelighet: I hvilken grad en komponent eller et system er i drift og tilgjengelig når det er nødvendig for bruk. Ofte uttrykt i prosent. (IEEE 610)
B
back-to-back testing: Testing der to eller flere varianter av en komponent eller et system blir utført med samme innganger, utgangene sammenlignet og analysert i tilfeller av avvik. (IEEE 610)
grunnlinje: En spesifikasjon eller et programvareprodukt som formelt er gjennomgått eller avtalt, som deretter tjener som grunnlag for videre utvikling, og som bare kan endres gjennom en formell endringskontrollprosess. (Etter IEEE 610)
grunnleggende blokk: En sekvens av en eller flere påfølgende kjørbare uttalelser som ikke inneholder grener.
grunnprøvesett: Et sett med testtilfeller avledet fra den interne strukturen eller spesifikasjonen for å sikre at 100% av et spesifisert dekningskriterium oppnås.
oppførsel: Svaret fra en komponent eller et system til et sett med inngangsverdier og forutsetninger.
referansetest: (1) En standard som målinger eller sammenligninger kan gjøres mot. (2) En test som brukes til å sammenligne komponenter eller systemer med hverandre eller til en standard som i (1). (Etter IEEE 610)
skreddersydd programvare: Programvare utviklet spesielt for et sett med brukere eller kunder. Det motsatte er hylleprogramvare.
beste praksis: En overlegen metode eller nyskapende praksis som bidrar til forbedret ytelse for en organisasjon under gitt kontekst, vanligvis anerkjent som ‘best’ av andre jevnaldrende organisasjoner.
betatesting: Operasjonell testing av potensielle og / eller eksisterende brukere / kunder på et eksternt nettsted som ikke ellers er involvert i utviklerne, for å avgjøre om en komponent eller et system tilfredsstiller brukerens / kundens behov og passer inn i forretningsprosessene. Betatesting brukes ofte som en form for ekstern godkjenningstesting for å få tilbakemeldinger fra markedet.
big-bang testing: En type integrasjonstesting der programvareelementer, maskinvareelementer eller begge kombineres samtidig til en komponent eller et samlet system, snarere enn i trinn. (Etter IEEE 610) Se også integrasjonstesting.
den beste mp3-nedlastingsappen for android
black box testing: Testing, enten funksjonell eller ikke-funksjonell, uten referanse til den interne strukturen til komponenten eller systemet.
black box test design teknikker: Dokumentert prosedyre for å utlede og velge testsaker basert på en analyse av spesifikasjonen, enten funksjonell eller ikke-funksjonell, til en komponent eller et system uten referanse til dens interne struktur.
blokkert testsak: En testsak som ikke kan utføres fordi forutsetningene for gjennomføring ikke er oppfylt.
bottom-up testing: En inkrementell tilnærming til integrasjonstesting der komponenter på laveste nivå testes først, og deretter brukes til å lette testing av komponenter på høyere nivå. Denne prosessen gjentas til komponenten øverst i hierarkiet er testet. Se også integrasjonstesting.
grenseverdi: En inngangsverdi eller utgangsverdi som er på kanten av en ekvivalenspartisjon eller ved den minste inkrementelle avstanden på hver side av en kant, for eksempel minimums- eller maksimumsverdien for et område.
grenseverdianalyse: En svart boks testdesignteknikk der testtilfeller er utformet basert på grenseverdier.
grenseverdidekning: Prosentandelen av grenseverdier som er utøvd av en testpakke.
gren: En grunnleggende blokk som kan velges for kjøring basert på en programkonstruksjon der en av to eller flere alternative programbaner er tilgjengelige, f.eks. tilfelle, hopp, gå til, hvis det ellers.
gren dekning: Prosentandelen av filialer som har blitt utøvd av en testpakke. 100% grendekning innebærer både 100% beslutningsdekning og 100% utsagnsdekning.
gren testing: En designteknikk for en hvit boks der testkasser er designet for å utføre grener.
forretningsprosessbasert testing: En tilnærming til testing der testtilfeller er utformet basert på beskrivelser og / eller kunnskap om forretningsprosesser.
C
Capability Maturity Model (CMM): Et iscenesatt rammeverk på fem nivåer som beskriver nøkkelelementene i en effektiv programvareprosess. Capability Maturity Model dekker praksis for planlegging, prosjektering og administrering av programvareutvikling og vedlikehold. (CMM)
Capability Maturity Model Integration (CMMI): Et rammeverk som beskriver nøkkelelementene i en effektiv produktutviklings- og vedlikeholdsprosess. Capability Maturity Model Integration dekker praksis for planlegging, prosjektering og styring av produktutvikling og vedlikehold. CMMI er den utpekte etterfølgeren til CMM. (CMMI)
fange / avspille verktøy: En type testutføringsverktøy der innganger blir registrert under manuell testing for å generere automatiserte testskript som kan utføres senere (dvs. gjentas). Disse verktøyene brukes ofte til å støtte automatisert regresjonstesting.
SAK: Forkortelse for Computer Aided Software Engineering.
CAST: Forkortelse for testing av datamaskinstøttet programvare. Se også testautomatisering.
årsak-virkning-graf: En grafisk fremstilling av innganger og / eller stimuli (årsaker) med tilhørende utganger (effekter), som kan brukes til å designe testtilfeller.
årsakseffektgrafikk: En svart boks test design teknikk der test tilfeller er designet fra årsak-virkning grafer. (BS 7925/2)
sertifisering: Prosessen med å bekrefte at en komponent, et system eller en person oppfyller de spesifiserte kravene, f.eks. ved å bestå en eksamen.
foranderlighet: Programvareproduktets evne til å muliggjøre implementering av spesifiserte modifikasjoner. (ISO 9126) Se også vedlikeholdsevne.
klassifisering tre metode: En svart boks testdesignteknikk der testtilfeller, beskrevet ved hjelp av et klassifiseringstreet, er utformet for å utføre kombinasjoner av representanter for inngangs- og / eller utgangsdomener. (Grochtmann)
kodedekning: En analysemetode som bestemmer hvilke deler av programvaren som er utført (dekket) av testpakken og hvilke deler som ikke er utført, f.eks. uttalelsesdekning, beslutningsdekning eller tilstandsdekning.
sameksistens: Programvareproduktets evne til å eksistere samtidig med annen uavhengig programvare i et felles miljø som deler felles ressurser. (ISO 9126) Se testbarhet.
kompleksitet: I hvilken grad en komponent eller et system har en design og / eller intern struktur som er vanskelig å forstå, vedlikeholde og verifisere. Se også syklomatisk kompleksitet.
samsvar: Programvareproduktets evne til å overholde standarder, konvensjoner eller forskrifter i lover og lignende forskrifter. (ISO 9126)
samsvarstesting : Testprosessen for å bestemme samsvaret til komponenten eller systemet.
komponent: En minimal programvare som kan testes isolert.
komponentintegrasjonstesting: Testing utført for å avsløre feil i grensesnittene og samspill mellom integrerte komponenter.
komponentspesifikasjon: En beskrivelse av en komponents funksjon når det gjelder utgangsverdier for spesifiserte inngangsverdier under spesifiserte forhold, og nødvendig ikke-funksjonell oppførsel (f.eks. Ressursutnyttelse).
komponent testing: Testing av individuelle programvarekomponenter. (Etter IEEE 610)
sammensatt tilstand: To eller flere enkeltbetingelser forbundet med en logisk operatør (AND, OR eller XOR), f.eks. ‘A> B OG C> 1000’.
samtidighetstesting: Testing for å bestemme hvordan forekomsten av to eller flere aktiviteter innen samme tidsintervall, oppnådd enten ved å flette sammen aktivitetene eller ved samtidig utførelse, blir håndtert av komponenten eller systemet. (Etter IEEE 610)
betingelse: Et logisk uttrykk som kan vurderes som sant eller usant, f.eks. A> B. Se også testtilstand.
tilstandsdekning: Prosentandelen av tilstandsutfall som har blitt utøvd av en testpakke. 100% tilstandsdekning krever at hver enkelt tilstand i hver avgjørelse blir testet som sant og usant.
tilstandsbestemmelsesdekning: Prosentandelen av alle enkelttilstandsutfall som uavhengig påvirker et beslutningsresultat som har blitt utøvd av en test case suite. 100% dekningsbestemmelsesdekning innebærer 100% dekningsdekning.
test av tilstandsbestemmelse: En designteknikk for en hvit boks der testtilfeller er utformet for å utføre resultater med en enkelt tilstand som uavhengig påvirker et beslutningsresultat.
tilstandstesting: En designteknikk for en hvit boks der testtilfeller er designet for å utføre tilstandsresultater.
tilstandsutfall: Evaluering av en tilstand til sant eller usant.
konfigurasjon: Sammensetningen av en komponent eller et system som definert av antall, natur og sammenkoblinger av dets bestanddeler.
konfigurasjonsrevisjon: Funksjonen for å sjekke innholdet i biblioteker med konfigurasjonselementer, f.eks. for overholdelse av standarder. (IEEE 610)
konfigurasjonskontroll: Et element i konfigurasjonsadministrasjon, som består av evaluering, koordinering, godkjenning eller misbilligelse, og implementering av endringer i konfigurasjonselementer etter formell etablering av deres konfigurasjonsidentifikasjon. (IEEE
610)
konfigurasjonsidentifikasjon: Et element av konfigurasjonsadministrasjon, som består av å velge konfigurasjonselementene for et system og registrere deres funksjonelle og fysiske egenskaper i teknisk dokumentasjon. (IEEE 610)
konfigurasjonselement: En aggregering av maskinvare, programvare eller begge deler, som er utpekt for konfigurasjonsadministrasjon og behandles som en enkelt enhet i konfigurasjonsadministrasjonsprosessen. (IEEE 610)
konfigurasjonsstyring: En disiplin som bruker teknisk og administrativ retning og overvåking for å: identifisere og dokumentere de funksjonelle og fysiske egenskapene til et konfigurasjonselement, kontrollere endringer i disse egenskapene, registrere og rapportere endringsbehandlings- og implementeringsstatus, og verifisere samsvar med spesifiserte krav. (IEEE 610)
konsistens: Graden av enhetlighet, standardisering og frihet fra motsetning mellom dokumentene eller delene av en komponent eller et system. (IEEE 610)
kontroll flyt: En abstrakt representasjon av alle mulige sekvenser av hendelser (baner) i utførelsen gjennom en komponent eller et system.
konverteringstesting: Testing av programvare som brukes til å konvertere data fra eksisterende systemer for bruk i erstatningssystemer.
Barnesenger: Forkortelse for kommersiell programvare uten lager.
dekning: Graden, uttrykt i prosent, som en spesifisert dekningsartikkel har blitt utøvd av en testpakke.
dekningsanalyse: Måling av oppnådd dekning til et spesifisert dekningselement under testutførelse med henvisning til forhåndsbestemte kriterier for å avgjøre om ytterligere testing er nødvendig, og i så fall hvilke testtilfeller som er nødvendige.
dekningselement: En enhet eller eiendom brukt som grunnlag for testdekning, f.eks. ekvivalenspartisjoner eller kodeuttalelser.
dekningsverktøy: Et verktøy som gir objektive mål på hvilke strukturelle elementer, f.eks. uttalelser, har grener blitt utøvd av testpakken.
syklomatisk kompleksitet: Antall uavhengige stier gjennom et program. Syklomatisk kompleksitet er definert som: L - N + 2P, hvor -L = antall kanter / lenker i en graf -N = antall noder i en graf - P = antall frakoblede deler av grafen (f.eks. En anropsgraf og en underrutine). (Etter McCabe)
D
datadefinisjon: En kjørbar setning der en variabel tildeles en verdi.
datadrevet testing: En skriptteknikk som lagrer testinndata og forventede resultater i en tabell eller et regneark, slik at et enkelt kontrollskript kan utføre alle testene i tabellen. Datadrevet testing brukes ofte til å støtte applikasjonen av testutførelsesverktøy som fange- / avspillingsverktøy. (Fewster og Graham) Se også søkeorddrevet testing.
dataflyt: En abstrakt representasjon av sekvensen og mulige endringer i tilstanden til dataobjekter, der tilstanden til et objekt er noe av:opprettelse, bruk eller ødeleggelse. (Beizer)
dataflytanalyse: En form for statisk analyse basert på definisjon og bruk av variabler.
dataflyt dekning: Prosentandelen av definisjonsbrukepar som er utøvd av en test case-pakke.
dataflyt test: En designteknikk for en hvit boks der testtilfeller er utformet for å utføre definisjon og bruke par av variabler.
feilsøking: Prosessen med å finne, analysere og fjerne årsakene til feil i programvaren.
feilsøkingsverktøy: Et verktøy som brukes av programmerere for å reprodusere feil, undersøke tilstanden til programmene og finne den tilsvarende feilen. Feilsøkere gjør det mulig for programmerere å utføre programmer trinn for trinn, å stoppe et program i en hvilken som helst programerklæring og å sette og undersøke programvariabler.
beslutning: Et programpunkt der kontrollflyten har to eller flere alternative ruter. En node med to eller flere lenker til separate grener.
dekningsbetingelsesdekning: Prosentandelen av alle tilstandsutfall og beslutningsresultater som har blitt utøvd av en testpakke. 100% beslutningstilstandsdekning innebærer både 100% tilstandsdekning og 100% beslutningsdekning.
testing av beslutningstilstand: En designteknikk for en hvit boks der testtilfeller er utformet for å utføre tilstandsresultater og beslutningsresultater.
beslutningsdekning: Prosentandelen av beslutningsresultatene som har blitt utøvd av en testpakke. 100% beslutningsdekning innebærer både 100% filialdekning og 100% uttalelsesdekning.
beslutningstabell: En tabell som viser kombinasjoner av innganger og / eller stimuli (årsaker) med tilhørende utganger og / eller handlinger (effekter), som kan brukes til å designe testtilfeller.
beslutningstabell testing: En svart boks test design teknikker der test tilfeller er designet for å utføre kombinasjonene av innganger og / eller stimuli (årsaker) vist i en beslutningstabell. (Veenendaal)
beslutningstesting: En designteknikk for en hvit boks der testsaker er utformet for å utføre beslutningsresultater.
beslutningsutfall: Resultatet av en beslutning (som derfor bestemmer grenene som skal tas).
defekt: En feil i en komponent eller et system som kan føre til at komponenten eller systemet ikke klarer å utføre den nødvendige funksjonen, f.eks. feil uttalelse eller datadefinisjon. En feil, hvis den oppstår under utførelsen, kan forårsake en feil på komponenten eller systemet.
defekt tetthet: Antall feil identifisert i en komponent eller et system delt på størrelsen på komponenten eller systemet (uttrykt i standard måleord, f.eks. Kodelinjer, antall klasser eller funksjonspunkter).
Prosent av mangelfunksjon (DDP): antall feil funnet i en testfase, delt på antall funnet ved den testfasen og andre midler etterpå.
feilrapport: Et dokument som rapporterer om feil i en komponent eller et system som kan føre til at komponenten eller systemet ikke utfører den nødvendige funksjonen. (Etter IEEE 829)
feilhåndtering: Prosessen med å gjenkjenne, undersøke, iverksette tiltak og avhende feil. Det innebærer å registrere feil, klassifisere dem og identifisere virkningen. (Etter IEEE 1044)
feilmaskering: En hendelse der en defekt forhindrer påvisning av en annen. (Etter IEEE 610)
definisjon-bruk par: Sammenhengen mellom definisjonen av en variabel og bruken av den variabelen. Variable bruksområder inkluderer beregning (f.eks. Multiplikasjon) eller for å lede kjøringen av en bane ('predikat' -bruk).
leveres: Ethvert (arbeid) produkt som må leveres til noen andre som (arbeid) produktets forfatter.
designbasert testing: En tilnærming til testing der testtilfeller er utformet basert på arkitekturen og / eller detaljert utforming av en komponent eller et system (f.eks. Tester av grensesnitt mellom komponenter eller systemer).
skrivebordssjekking: Testing av programvare eller spesifikasjon ved manuell simulering av utførelsen.
utviklingstesting: Formell eller uformell testing utført under implementeringen av en komponent eller et system, vanligvis i utviklingsmiljøet av utviklere. (Etter IEEE 610)
dokumentasjonstesting: Testing av kvaliteten på dokumentasjonen, f.eks. brukerhåndbok eller installasjonsveiledning.
domene: Settet som gyldige inngangs- og / eller utgangsverdier kan velges fra.
sjåfør: En programvarekomponent eller et testverktøy som erstatter en komponent som tar seg av kontrollen og / eller anropet til en komponent eller et system. (Etter TMap)
dynamisk analyse: Prosessen med å evaluere atferd, f.eks. minneytelse, CPU-bruk, av et system eller en komponent under utførelsen. (Etter IEEE 610)
dynamisk sammenligning: Sammenligning av faktiske og forventede resultater, utført mens programvaren kjøres, for eksempel av et testutførelsesverktøy.
dynamisk testing: Testing som involverer kjøring av programvaren til en komponent eller et system.
ER
effektivitet: Programvareproduktets evne til å gi passende ytelse i forhold til mengden ressurser som brukes under oppgitte forhold. (ISO 9126)
effektivitetstesting: Testprosessen for å bestemme effektiviteten til et programvareprodukt.
elementær sammenligningstesting: En svart boks test design teknikker der test tilfeller er utformet for å utføre kombinasjoner av innganger ved hjelp av begrepet dekning av tilstandsbestemmelse. (TMap)
emulator: Enhet, dataprogram eller system som godtar de samme inngangene og produserer de samme utgangene som et gitt system. (IEEE 610) Se også simulator.
inngangskriterier: settet med generiske og spesifikke betingelser for å la en prosess gå videre med en definert oppgave, f.eks. testfase. Hensikten med oppføringskriterier er å forhindre at en oppgave starter som vil medføre mer (bortkastet) innsats sammenlignet med innsatsen som trengs for å fjerne de mislykkede oppføringskriteriene. (Gilb og Graham)
inngangspunkt: Den første kjørbare uttalelsen i en komponent.
ekvivalenspartisjon: En del av et inngangs- eller utgangsdomene der oppførselen til en komponent eller et system antas å være den samme, basert på spesifikasjonen.
ekvivalenspartisjon dekning: Prosentandelen av ekvivalenspartisjoner som er utøvd av en testpakke.
ekvivalenspartisjonering: En svart boks test design teknikk der test tilfeller er designet for å utføre representanter fra ekvivalens partisjoner. I prinsippet er testtilfeller designet for å dekke hver partisjon minst en gang.
feil: En menneskelig handling som gir et feil resultat. (Etter IEEE 610)
feil gjetting: En testdesignteknikk der testerenes opplevelse brukes til å forutse hvilke defekter som kan være tilstede i komponenten eller systemet som testes som et resultat av feil, og til å designe tester spesielt for å avsløre dem.
feilsåing: Prosessen med bevisst å legge til kjente feil til de som allerede er i komponenten eller systemet for å overvåke hastigheten på deteksjon og fjerning, og estimere antall gjenværende feil. (IEEE 610)
feiltoleranse: Evnen til et system eller en komponent til å fortsette normal drift til tross for tilstedeværelsen av feil innganger. (Etter IEEE 610).
avvikshåndtering: Oppførsel til en komponent eller et system som svar på feil inngang, enten fra en menneskelig bruker eller fra en annen komponent eller et system, eller til en intern feil.
kjørbar uttalelse: En uttalelse som, når den kompileres, oversettes til objektkode, og som vil bli utført prosessuelt når programmet kjører og kan utføre en handling på data.
trent: Et programelement sies å bli utøvd av en testtilfelle når inngangsverdien forårsaker utførelsen av det elementet, for eksempel en uttalelse, en beslutning eller et annet strukturelt element.
uttømmende testing: En testtilnærming der testpakken inneholder alle kombinasjoner av inngangsverdier og forutsetninger.
utgangskriterier: Settet med generiske og spesifikke betingelser, avtalt med interessentene, for å tillate at en prosess blir fullført offisielt. Formålet med utgangskriterier er å forhindre at en oppgave blir ansett som fullført når det fremdeles er utestående deler av oppgaven som ikke er ferdig. Utgangskriterier brukes ved testing for å rapportere mot og planlegge når du skal stoppe testen. (Etter Gilb og Graham)
utgangssted: Den siste kjørbare uttalelsen i en komponent.
forventet resultat: Atferden forutsagt av spesifikasjonen, eller en annen kilde, til komponenten eller systemet under spesifiserte forhold.
utforskende testing: Testing der testeren aktivt kontrollerer utformingen av testene etter hvert som testene utføres, og bruker informasjon som er oppnådd under testingen for å designe nye og bedre tester. (Bach)
F
mislykkes: En test anses å mislykkes hvis det faktiske resultatet ikke samsvarer med det forventede resultatet.
svikt: Faktisk avvik fra komponenten eller systemet fra forventet levering, service eller resultat. (Etter Fenton)
feil modus: Den fysiske eller funksjonelle manifestasjonen av en feil. For eksempel kan et system i feilmodus være preget av langsom drift, feil utganger eller fullstendig avslutning av utførelsen.
Feilmodus og effektanalyse (FMEA): En systematisk tilnærming til risikoidentifisering og analyse av å identifisere mulige feilmodus og forsøke å forhindre at de oppstår.
strykprosent: Forholdet mellom antall feil i en gitt kategori og en gitt måleenhet, f.eks. feil per tidsenhet, feil per antall transaksjoner, feil per antall datakjøringer. (IEEE 610)
feiltoleranse: Programvareproduktets evne til å opprettholde et spesifisert ytelsesnivå i tilfelle programvarefeil (mangler) eller brudd på det spesifiserte grensesnittet. (ISO 9126) Se også pålitelighet.
feiltre analyse: En metode som brukes til å analysere årsakene til feil (mangler).
gjennomførbar vei: En bane som det finnes et sett med inngangsverdier og forutsetninger som fører til at den blir utført.
trekk: Et attributt for en komponent eller et system spesifisert eller underforstått av kravdokumentasjon (for eksempel pålitelighet, brukervennlighet eller designbegrensninger). (Etter IEEE 1008)
endelig maskin: En beregningsmodell som består av et endelig antall stater og overganger mellom disse statene, muligens med tilhørende handlinger. (IEEE 610)
formell gjennomgang: En gjennomgang preget av dokumenterte prosedyrer og krav, f.eks. undersøkelse.
frossen testbasis: Et testbasisdokument som bare kan endres ved en formell endringskontrollprosess. Se også grunnlinje.
Funksjonspunktanalyse (FPA): Metode som tar sikte på å måle størrelsen på funksjonaliteten til et informasjonssystem. Målingen er uavhengig av teknologien. Denne målingen kan brukes som grunnlag for måling av produktivitet, estimering av nødvendige ressurser og prosjektkontroll.
funksjonell integrasjon: En integrasjonsmetode som kombinerer komponentene eller systemene for å få en grunnleggende funksjonalitet til å fungere tidlig. Se også integrasjonstesting.
funksjonskrav: Et krav som spesifiserer en funksjon som en komponent eller et system må utføre. (IEEE 610)
funksjonell testdesignteknikk: Dokumentert prosedyre for å utlede og velge testsaker basert på en analyse av spesifikasjonen av funksjonaliteten til en komponent eller et system uten referanse til den interne strukturen. Se også black box test design teknikk.
funksjonstesting: Testing basert på en analyse av spesifikasjonen av funksjonaliteten til en komponent eller et system. Se også testing av svart boks.
funksjonalitet: Programvareproduktets evne til å tilby funksjoner som oppfyller oppgitte og underforståtte behov når programvaren brukes under spesifiserte forhold. (ISO 9126)
funksjonstesting: Testprosessen for å bestemme funksjonaliteten til et programvareprodukt.
G
glassboks testing: Se testing av hvit boks.
H
heuristisk evaluering: En statisk brukbarhetstestteknikk for å bestemme overholdelsen av et brukergrensesnitt med anerkjente prinsipper for brukbarhet (den såkalte 'heuristikken').
høyt tilfelle test tilfelle: En testsak uten konkrete (implementeringsnivå) verdier for inngangsdata og forventede resultater.
horisontal sporbarhet: Sporing av krav til et testnivå gjennom lagene med testdokumentasjon (f.eks. Testplan, spesifikasjon av testdesign, spesifikasjon av testtilfelle og spesifikasjon av testprosedyrer).
Jeg
konsekvensanalyse: Vurderingen av endring i lagene med utviklingsdokumentasjon, testdokumentasjon og komponenter for å implementere en gitt endring i spesifiserte krav.
inkrementell utviklingsmodell: En utviklingslivssyklus der et prosjekt er delt inn i en rekke trinn, som hver leverer en del av funksjonaliteten i de overordnede prosjektkravene. Kravene prioriteres og leveres i prioritetsrekkefølge i riktig trinn. I noen (men ikke alle) versjoner av denne livssyklusmodellen følger hvert delprosjekt en ‘mini V-modell’ med sin egen design, koding og testing.
inkrementell testing: Testing hvor komponenter eller systemer er integrert og testet en eller noen av gangen, til alle komponentene eller systemene er integrert og testet.
hendelse: Enhver hendelse som oppstår under testing som krever etterforskning. (Etter IEEE 1008)
hendelsesstyring: Prosessen med å gjenkjenne, undersøke, iverksette tiltak og avhende hendelser. Det innebærer å registrere hendelser, klassifisere dem og identifisere virkningen. (Etter IEEE 1044)
hendelsesstyringsverktøy: Et verktøy som letter registrering og statussporing av hendelser som ble funnet under testing. De har ofte arbeidsflytorienterte fasiliteter for å spore og kontrollere tildeling, korreksjon og omprøving av hendelser og tilby rapporteringsfasiliteter.
hendelsesrapport: Et dokument som rapporterer om hendelser som inntreffer under testingen som krever etterforskning. (Etter IEEE 829)
selvstendighet: Separasjon av ansvar, som oppmuntrer til gjennomføring av objektiv testing. (Etter DO-178b)
umulig sti: En bane som ikke kan utøves av noen sett med mulige inngangsverdier.
uformell anmeldelse: En gjennomgang ikke basert på en formell (dokumentert) prosedyre.
inngang: En variabel (enten lagret i en komponent eller utenfor) som leses av en komponent.
inngangsdomene: Settet som gyldige inngangsverdier kan velges fra. Se også domene.
inngangsverdi: En forekomst av en innspill. Se også innspill.
undersøkelse: En type gjennomgang som er avhengig av visuell undersøkelse av dokumenter for å oppdage mangler, f.eks. brudd på utviklingsstandarder og manglende samsvar med dokumentasjon på høyere nivå. Den mest formelle gjennomgangsteknikken og derfor alltid basert på en dokumentert prosedyre. (Etter IEEE 610, IEEE 1028)
installerbarhet: Muligheten til programvareproduktet som skal installeres i et spesifisert miljø (ISO 9126). Se også bærbarhet.
installasjonstest: Prosessen med å teste installerbarheten til et programvareprodukt. Se også bærbarhetstesting.
installasjonsveiledning: Medfølgende instruksjoner på ethvert passende medium som guider installatøren gjennom installasjonsprosessen. Dette kan være en manuell veiledning, trinnvis fremgangsmåte, installasjonsveiviser eller annen lignende prosessbeskrivelse.
installasjonsveiviser: Leveres programvare på et hvilket som helst egnet medium, som leder installatøren gjennom installasjonsprosessen. Den kjører vanligvis installasjonsprosessen, gir tilbakemelding på installasjonsresultatene og ber om alternativer.
instrumentering: Innsetting av tilleggskode i programmet for å samle informasjon om programadferd under utførelse.
instrumenter: Et programvareverktøy som brukes til å utføre instrumentering.
inntakstest: En spesiell forekomst av en røykprøve for å avgjøre om komponenten eller systemet er klart for detaljert og videre testing. En inntakstest utføres vanligvis i starten av testutførelsesfasen.
integrering: Prosessen med å kombinere komponenter eller systemer i større sammenstillinger.
integrasjonstesting: Testing utført for å avsløre feil i grensesnittene og i samspillet mellom integrerte komponenter eller systemer. Se også testing av komponentintegrasjon, testing av systemintegrasjon.
grensesnitt testing: En integrasjonstesttype som er opptatt av å teste grensesnittene mellom komponenter eller systemer.
interoperabilitet: Programvareproduktets evne til å samhandle med en eller flere spesifiserte komponenter eller systemer. (Etter ISO 9126) Se også funksjonalitet.
interoperabilitetstesting: Testprosessen for å bestemme interoperabiliteten til et programvareprodukt. Se også funksjonstesting.
ugyldig testing: Testing ved hjelp av inngangsverdier som skal avvises av komponenten eller systemet. Se også feiltoleranse.
isolasjonstesting: Testing av enkeltkomponenter isolert fra omgivende komponenter, med omliggende komponenter simulert av stubber og drivere, om nødvendig.
TIL
søkeorddrevet testing: En skriptteknikk som bruker datafiler til å ikke bare inneholde testdata og forventede resultater, men også nøkkelord relatert til applikasjonen som testes. Nøkkelordene tolkes av spesielle støtteskripter som kalles av kontrollskriptet for testen. Se også datadrevet testing.
L
LCSAJ: En lineær kodesekvens og hopp, som består av følgende tre elementer (konvensjonelt identifisert av linjenumre i en kildekodeliste): starten på den lineære sekvensen av kjørbare utsagn, slutten på den lineære sekvensen og mållinjen som kontroll strømmen overføres på slutten av den lineære sekvensen.
LCSAJ-dekning: Prosentandelen LCSAJ av en komponent som har blitt utøvd av en testpakke. 100% LCSAJ-dekning innebærer 100% beslutningsdekning.
LCSAJ-testing: En designteknikk for en hvit boks der testtilfeller er designet for å utføre LCSAJ.
lærbarhet: Programvareproduktets evne til å gjøre det mulig for brukeren å lære seg applikasjonen. (ISO 9126) Se også brukervennlighet.
belastningstest: En testtype som er opptatt av å måle oppførselen til en komponent eller et system med økende belastning, f.eks. antall parallelle brukere og / eller antall transaksjoner for å bestemme hvilken belastning som kan håndteres av komponenten eller systemet.
testnivå på lavt nivå: En test case med konkrete (implementeringsnivå) verdier for inngangsdata og forventede resultater.
M
vedlikehold: Endring av et programvareprodukt etter levering for å rette opp mangler, for å forbedre ytelsen eller andre egenskaper, eller for å tilpasse produktet til et modifisert miljø. (IEEE 1219)
vedlikeholdstesting: Testing av endringene i et operativsystem eller effekten av et endret miljø til et operativsystem.
vedlikeholdsevne: Enkelheten med hvordan et programvareprodukt kan modifiseres for å rette feil, modifiseres for å oppfylle nye krav, modifiseres for å gjøre fremtidig vedlikehold enklere eller tilpasses et endret miljø. (ISO 9126)
testing av vedlikeholdsevne: Testprosessen for å bestemme vedlikeholdsevnen til et programvareprodukt.
gjennomgang av ledelsen: En systematisk evaluering av programvareanskaffelse, forsyning, utvikling, drift eller vedlikeholdsprosess, utført av eller på vegne av ledelsen som overvåker fremdriften, bestemmer statusen for planer og tidsplaner, bekrefter krav og arvtildeling av systemet, eller evaluerer effektiviteten av administrasjonsmetoder for å oppnå form for formål. (Etter IEEE 610, IEEE 1028)
modenhet: (1) En organisasjons evne med hensyn til effektiviteten og effektiviteten i dens prosesser og arbeidspraksis. Se også kapasitetsmodningsmodell, testmodningsmodell. (2) Programvareproduktets evne til å unngå feil som følge av feil i programvaren. (ISO 9126) Se også pålitelighet.
måle: Antallet eller kategorien som er tilordnet et attributt til en enhet ved å foreta en måling (ISO 14598).
mål: Prosessen med å tildele et nummer eller en kategori til en enhet for å beskrive et attributt for den enheten. (ISO 14598)
måleskala: En skala som begrenser typen dataanalyse som kan utføres på den. (ISO 14598)
hukommelsestap: En feil i programmets dynamiske butikkallokeringslogikk som får det til å mislykkes i å gjenvinne minnet etter at det er ferdig med å bruke det, og til slutt føre til at programmet mislykkes på grunn av mangel på minne.
beregning: En måleskala og metoden som brukes til måling. (ISO 14598)
milepæl: Et tidspunkt i et prosjekt der definerte (mellomliggende) leveranser ogresultatene skal være klare.
moderator: Lederen og hovedpersonen som er ansvarlig for en inspeksjon eller annen gjennomgangsprosess.
Observere: Et programvareverktøy eller en maskinvareenhet som kjører samtidig med komponenten eller systemet som testes, og overvåker, registrerer og / eller analyserer oppførselen til komponenten eller systemet. (Etter IEEE 610)
flere tilstandsdekning: Prosentandelen av kombinasjoner av alle enkeltbetingelserresultater i en uttalelse som er utøvd av en testpakke. 100% flere gangertilstandsdekning innebærer 100% tilstandsbestemmelsesdekning.
testing av flere tilstander: En designteknikk for en hvit boks der testtilfeller er utformet for å utføre kombinasjoner av resultater fra en enkelt tilstand (innen en uttalelse).
mutasjonsanalyse: En metode for å bestemme test suite grundighet ved å måle i hvilken grad en test suite kan skille programmet fra små varianter (mutanter) av programmet.
N
N-bryter dekning: Andelen sekvenser av N + 1-overganger som har blitt utøvd av en testpakke. (Chow)
N-bryter testing: En form for tilstandstransisjonstesting der testtilfeller er utformet for å utføre alle gyldige sekvenser av N + 1-overganger. (Chow) Se også statlig overgangstesting.
negativ testing: Tester rettet mot å vise at en komponent eller et system ikke fungerer. Negativ testing er relatert til testernes holdning i stedet for en spesifikk testtilnærming eller testdesignteknikk. (Etter Beizer).
avvik: Manglende oppfyllelse av et spesifisert krav. (ISO 9000)
ikke-funksjonelt krav: Et krav som ikke er relatert til funksjonalitet, men til egenskaper som pålitelighet, effektivitet, brukervennlighet, vedlikehold og bærbarhet.
ikke-funksjonell testing: Testing av attributtene til en komponent eller et system som ikke er relatert til funksjonalitet, f.eks. pålitelighet, effektivitet, brukervennlighet, vedlikehold og bærbarhet.
ikke-funksjonelle teknikker for testdesign: Metoder som brukes til å designe eller velge tester for ikke-funksjonell testing.
ELLER
hylleprogramvare: Et programvareprodukt som er utviklet for det generelle markedet, dvs. for et stort antall kunder, og som leveres til mange kunder i identisk format.
brukbarhet: Programvareproduktets evne til å gjøre det mulig for brukeren å betjene og kontrollere det. (ISO 9126) Se også brukervennlighet.
driftsmiljø: Maskinvare- og programvareprodukter installert på brukerens eller kundenes nettsteder der komponenten eller systemet som testes skal brukes. Programvaren kan omfatte operativsystemer, databasesystemer og andre applikasjoner.
testing av operativ profil: Statistisk testing ved bruk av en modell for systemoperasjoner (oppgaver med kort varighet) og sannsynligheten for typisk bruk. (Musa)
operasjonell testing: Testing utført for å evaluere en komponent eller et system i dets driftsmiljø. (IEEE 610)
produksjon: En variabel (enten lagret i en komponent eller utenfor) som er skrevet av en komponent.
utgangsdomene: Settet som gyldige utgangsverdier kan velges fra. Se også domene.
utgangsverdi: En forekomst av en utgang. Se også utdata.
P
par programmering: En programvareutviklingsmetode der kodelinjer (produksjon og / eller test) av en komponent skrives av to programmerere som sitter ved en datamaskin. Dette innebærer implisitt pågående sanntidskodevurderinger.
par testing: To testere jobber sammen for å finne feil. Vanligvis deler de én datamaskin og handler med kontrollen mens de tester.
Sende: En test anses å bestå hvis det faktiske resultatet samsvarer med det forventede resultatet.
bestått / ikke bestått kriterier: Beslutningsregler som brukes til å avgjøre om et testelement (funksjon) eller funksjon har bestått eller ikke bestått en test. (IEEE 829)
sti: En sekvens av hendelser, f.eks. kjørbare utsagn, fra en komponent eller et system fra et inngangspunkt til et utgangspunkt.
banedekning: Andelen stier som har blitt utøvd av en testpakke. 100% banedekning innebærer 100% LCSAJ-dekning.
sti sensibiliserende: Velge et sett med inngangsverdier for å tvinge utførelsen av en gitt bane.
banetesting: En designteknikk for en hvit boks der testtilfeller er designet for å utføre stier.
opptreden: I hvilken grad et system eller en komponent utfører sine angitte funksjoner innenfor gitte begrensninger angående behandlingstid og gjennomstrømningshastighet. (Etter IEEE 610) Se effektivitet.
ytelsesindikator: En høy grad av effektivitet og / eller effektivitet som brukes til å veilede og kontrollere progressiv utvikling, f.eks. Prosent av defektdeteksjon (DDP) for testing. (CMMI)
ytelsestesting: Testprosessen for å bestemme ytelsen til et programvareprodukt. Se effektivitetstesting.
verktøy for ytelsestesting: Et verktøy for å støtte ytelsestesting, og som vanligvis har to hovedanlegg: lastgenerering og måling av testtransaksjoner. Lastgenerering kan simulere enten flere brukere eller store mengder inndata. Under utførelse blir responstidsmålinger tatt fra utvalgte transaksjoner, og disse blir logget. Ytestestingsverktøy gir normalt rapporter basert på testlogger og grafer over belastning mot responstid.
fasetestplan: En testplan som vanligvis adresserer ett testnivå.
bærbarhet: Enkelt hvor programvareproduktet kan overføres fra en maskinvare eller et programvaremiljø til et annet. (ISO 9126)
bærbarhetstesting: Testprosessen for å bestemme bærbarheten til et programvareprodukt.
posttilstand: Miljø- og tilstandsvilkår som må oppfylles etter gjennomføring av en test eller testprosedyre.
sammenligning etter utførelse: Sammenligning av faktiske og forventede resultater, utført etter at programvaren er ferdig kjørt.
forutsetning: Miljø- og tilstandsvilkår som må oppfylles før komponenten eller systemet kan utføres med en bestemt test- eller testprosedyre.
Prioritet: Nivået av (forretnings) betydning tilordnet en vare, f.eks. defekt.
prosess syklus test: En svart boks test design teknikk der test tilfeller er utformet for å utføre forretningsprosedyrer og prosesser. (TMap)
prosess: Et sett med sammenhengende aktiviteter, som forvandler innganger til utganger. (ISO 12207)
prosjekt: Et prosjekt er et unikt sett med koordinerte og kontrollerte aktiviteter med start- og sluttdatoer som er et mål som samsvarer med spesifikke krav, inkludert tidsbegrensning, kostnader og ressurser. (ISO 9000)
prosjekt testplan: En testplan som vanligvis adresserer flere testnivåer.
pseudo-tilfeldig: En serie som ser ut til å være tilfeldig, men som faktisk genereres i henhold til en forhåndsbestemt sekvens.
Q
kvalitet: I hvilken grad en komponent, et system eller en prosess oppfyller spesifiserte krav og / eller bruker / kundebehov og forventninger. (Etter IEEE 610)
kvalitetssikring: En del av kvalitetsstyring fokusert på å gi tillit til at kvalitetskravene blir oppfylt. (ISO 9000)
kvalitetsattributt: En funksjon eller karakteristikk som påvirker varens kvalitet. (IEEE 610)
kvalitetsstyring: Koordinerte aktiviteter for å lede og kontrollere en organisasjon med hensyn til kvalitet. Retning og kontroll med hensyn til kvalitet inkluderer generelt etablering av kvalitetspolitikk og kvalitetsmål, kvalitetsplanlegging, kvalitetskontroll, kvalitetssikring og kvalitetsforbedring. (ISO 9000)
R
tilfeldig testing: En svart boks testdesignteknikk der testtilfeller er valgt, muligens ved hjelp av en pseudo-tilfeldig genereringsalgoritme, for å matche en operativ profil. Denne teknikken kan brukes til å teste ikke-funksjonelle attributter som pålitelighet og ytelse.
utvinnbarhet: Programvareproduktets evne til å gjenopprette et spesifisert ytelsesnivå og gjenopprette dataene som er direkte berørt i tilfelle feil. (ISO 9126) Se også pålitelighet.
utvinningstest: Testprosessen for å bestemme utvinnbarheten til et programvareprodukt. Se også pålitelighetstesting.
Regresjonstesting: Testing av et tidligere testet program etter modifisering for å sikre at mangler ikke har blitt introdusert eller avdekket i uendrede områder av programvaren, som et resultat av endringene som er gjort. Den utføres når programvaren eller miljøet endres.
utgivelsesmerknad: Et dokument som identifiserer testelementer, deres konfigurasjon, nåværende status og annen leveringsinformasjon levert av utvikling til testing, og muligens andre interessenter, ved starten av en testutførelsesfase. (Etter IEEE 829)
pålitelighet: Programvareproduktets evne til å utføre de nødvendige funksjonene under oppgitte forhold i en spesifisert tidsperiode, eller i et spesifisert antall operasjoner. (ISO 9126)
pålitelighetstesting: Testprosessen for å bestemme påliteligheten til et programvareprodukt.
utskiftbarhet: Muligheten til programvareproduktet til å brukes i stedet for et annet spesifisert programvareprodukt for samme formål i samme miljø. (ISO 9126) Se også bærbarhet.
krav: En tilstand eller evne som en bruker trenger for å løse et problem eller oppnå et mål som et system eller en systemkomponent må oppfylle eller ha for å oppfylle en kontrakt, standard, spesifikasjon eller annet formelt dokument. (Etter IEEE 610)
kravbasert testing: En tilnærming til testing der testtilfeller er utformet basert på testmål og testbetingelser avledet fra krav, f.eks. tester som utøver spesifikke funksjoner eller undersøker ikke-funksjonelle attributter som pålitelighet eller brukervennlighet.
verktøy for kravhåndtering: Et verktøy som støtter registrering av krav, kravattributter (f.eks. Prioritet, kunnskapsansvarlig) og kommentar, og letter sporbarhet gjennom lag med krav og kravendringshåndtering. Noen kravhåndteringsverktøy gir også fasiliteter for statisk analyse, for eksempel konsistenskontroll og brudd på forhåndsdefinerte kravregler.
kravfase: Tidsperioden i programvarens livssyklus der likhetene til et programvareprodukt er definert og dokumentert. (IEEE 610)
ressursutnyttelse: Programvareproduktets evne til å bruke passende mengder og typer ressurser, for eksempel mengden hoved- og sekundærminne som brukes av programmet, og størrelsen på nødvendige midlertidige filer eller overløpsfiler når programvaren utfører sin funksjon under oppgitte forhold. (Etter ISO 9126) Se også effektivitet.
ressursutnyttelse: Testprosessen for å bestemme ressursutnyttelsen av et programvareprodukt.
resultat: Konsekvensen / utfallet av gjennomføringen av en test. Den inkluderer utganger til skjermer, endringer i data, rapporter og kommunikasjonsmeldinger sendt ut. Se også faktisk resultat, forventet resultat.
gjenopptakelseskriterier: Testaktivitetene som må gjentas når testen startes på nytt etter en suspensjon. (Etter IEEE 829)
re-testing: Testing som kjører testsaker som mislyktes sist gang de ble kjørt, for å verifisere suksessen til korrigerende handlinger.
anmeldelse: En evaluering av et produkt eller prosjektstatus for å fastslå avvik fra planlagte resultater og for å anbefale forbedringer. Eksempler inkluderer ledelsesgjennomgang, uformell gjennomgang, teknisk gjennomgang, inspeksjon og gjennomgang. (Etter IEEE 1028)
anmelder: Personen som er involvert i gjennomgangen, som skal identifisere og beskrive avvik i produktet eller prosjektet som blir gjennomgått. Kritikere kan velges for å representere forskjellige synspunkter og roller i gjennomgangsprosessen.
Fare: En faktor som kan resultere i fremtidige negative konsekvenser; vanligvis uttrykt som innvirkning og sannsynlighet.
risikoanalyse: Prosessen med å vurdere identifiserte risikoer for å estimere deres innvirkning og sannsynlighet for forekomst (sannsynlighet).
risikobasert testing: Test orientert mot å utforske og gi informasjon om produktrisiko. (Etter Gerrard)
risikokontroll: Prosessen der beslutninger blir nådd og beskyttende tiltak implementeres for å redusere risiko for eller opprettholde risiko innenfor bestemte nivåer.
risikoidentifikasjon: Prosessen med å identifisere risiko ved hjelp av teknikker som idédugnad, sjekklister og feilhistorikk.
risikostyring: Systematisk anvendelse av prosedyrer og praksis på oppgavene med å identifisere, analysere, prioritere og kontrollere risiko.
robusthet: I hvilken grad en komponent eller et system kan fungere riktig i nærvær av ugyldige innganger eller belastende miljøforhold. (IEEE 610) Se også feiltoleranse, feiltoleranse.
Opprinnelig årsak: En underliggende faktor som forårsaket avvik og muligens bør elimineres permanent gjennom prosessforbedring.
S
sikkerhet: Programvareproduktets evne til å oppnå akseptable nivåer av risiko for skade på mennesker, virksomhet, programvare, eiendom eller miljøet i en spesifikk brukssammenheng. (ISO 9126)
sikkerhetstesting: Testprosessen for å bestemme sikkerheten til et programvareprodukt.
skalerbarhet: Muligheten til å oppgradere programvareproduktet for å imøtekomme økte belastninger. (Etter Gerrard)
skalerbarhetstesting: Testing for å bestemme skalerbarheten til programvareproduktet.
skribent: Personen som må registrere hver nevnte mangel og eventuelle forbedringsforslag under et gjennomgangsmøte, på et loggskjema. Skribenten må sørge for at loggformen er lesbar og forståelig.
skriptspråk: Et programmeringsspråk der eksekverbare testskripter er skrevet, brukt av et testutføringsverktøy (f.eks. Et opptaks- / omspillingsverktøy).
sikkerhet: Attributter til programvareprodukter som har sin evne til å forhindre uautorisert tilgang, enten det er utilsiktet eller bevisst, til programmer og data. (ISO 9126)
sikkerhetstesting: Testing for å bestemme sikkerheten til programvareproduktet.
alvorlighetsgrad: Graden av innvirkning som en feil har på utviklingen eller driften av en komponent eller et system. (Etter IEEE 610)
simulering: Representasjonen av utvalgte atferdskarakteristikker for et fysisk eller abstrakt system av et annet system. (ISO 2382/1)
simulator: En enhet, et dataprogram eller et system som brukes under testing, som oppfører seg eller fungerer som et gitt system når det er utstyrt med et sett med kontrollerte innganger. (Etter IEEE 610, DO178b) Se også emulator.
røykprøve: En delmengde av alle definerte / planlagte testtilfeller som dekker hovedfunksjonaliteten til en komponent eller et system, for å fastslå at de viktigste funksjonene til et program fungerer, men ikke bry seg med finere detaljer. En daglig test for bygging og røyk er blant beste praksis i bransjen. Se også inntakstest.
programvarekvalitet: Den totale funksjonaliteten og funksjonene til et programvareprodukt som har sin evne til å tilfredsstille uttalte eller underforståtte behov. (Etter ISO 9126)
spesifikasjon: Et dokument som, ideelt på en komplett, presis og verifiserbar måte, spesifiserer kravene, utformingen, oppførselen eller andre egenskaper ved en komponent eller et system, og ofte prosedyrene for å avgjøre om disse bestemmelsene er oppfylt. (Etter IEEE 610)
spesifikasjonsbasert testdesignteknikk: Se black box test design teknikk.
spesifisert inngang: En inngang som spesifikasjonen forutsier et resultat for.
stabilitet: Programvareproduktets evne til å unngå uventede effekter fra modifikasjoner i programvaren. (ISO 9126) Se også vedlikeholdsevne.
tilstandsdiagram: Et diagram som viser tilstandene som en komponent eller et system kan anta, og viser hendelsene eller omstendighetene som forårsaker og / eller skyldes endring fra en tilstand til en annen. (IEEE 610)
tilstandstabell: Et rutenett som viser de resulterende overgangene for hver stat kombinert med hver mulig hendelse, og viser både gyldige og ugyldige overganger.
tilstandsovergang: En overgang mellom to tilstander i en komponent eller et system.
sql database intervju spørsmål og svar
statlig overgangstesting: En svart boks test design teknikk der test tilfeller er designet for å utføre gyldige og ugyldige tilstandsoverganger. Se også testing av N-switch.
uttalelse: En enhet i et programmeringsspråk, som vanligvis er den minste udelelige enheten for utførelse.
uttalelse dekning: Prosentandelen av kjørbare uttalelser som er utøvd av en testpakke.
utsagnstesting: En designteknikk for en hvit boks der testtilfeller er utformet for å utføre uttalelser.
statisk analyse: Analyse av programvareartefakter, f.eks. krav eller kode, utført uten å utføre disse programvareartefaktene.
statisk analysator: Et verktøy som utfører statisk analyse.
statisk kodeanalyse: Analyse av programkildekoden utført uten kjøring av programvaren.
statisk kode analysator: Et verktøy som utfører statisk kodeanalyse. Verktøyet sjekker kildekoden for visse egenskaper, for eksempel samsvar med kodestandarder, kvalitetsmålinger eller dataflytavvik.
statisk testing: Testing av en komponent eller et system på spesifikasjons- eller implementeringsnivå uten kjøring av programvaren, f.eks. anmeldelser eller statisk kodeanalyse.
statistisk testing: En testdesignteknikk der en modell av den statistiske fordelingen av inngangen brukes til å konstruere representative testtilfeller. Se også testing av operativ profil.
statusregnskap: Et element av konfigurasjonsadministrasjon, som består av innspilling og rapportering av informasjon som er nødvendig for å administrere en konfigurasjon effektivt. Denne informasjonen inkluderer en liste over godkjent konfigurasjonsidentifikasjon, status for foreslåtte endringer i konfigurasjonen og implementeringsstatus for godkjente endringer. (IEEE 610)
Stresstesting: Testing utført for å evaluere et system eller en komponent ved eller utenfor grensene for de spesifiserte kravene. (IEEE 610)
strukturell dekning: Dekningstiltak basert på komponentens interne struktur.
strukturell testdesignteknikk: Se designteknikk for hvit boks.
stubbe: En skjelett- eller spesialimplementering av en programvarekomponent, brukt til å utvikle eller teste en komponent som ringer eller på annen måte er avhengig av den. Den erstatter en kalt komponent. (Etter IEEE 610)
undervei: En sekvens av kjørbare utsagn i en komponent.
suspensjonskriterier: Kriteriene som brukes til (midlertidig) å stoppe hele eller deler av testaktivitetene på testelementene. (Etter IEEE 829)
egnethet: Programvareproduktets evne til å tilby et passende sett med funksjoner for spesifiserte oppgaver og brukermål. (ISO 9126) Se også funksjonalitet.
Programvareovervåkningslager (SUMI): En spørreskjemabasert brukbarhetstestteknikk for å evaluere brukbarheten, f.eks. brukertilfredshet for en komponent eller et system. (Veenendaal)
syntaks testing: En svart boks testdesignteknikk der testtilfeller er utformet basert på definisjonen av inngangsdomenet og / eller utdataområdet.
system: En samling av komponenter organisert for å utføre en bestemt funksjon eller et sett med funksjoner. (IEEE 610)
systemintegrasjonstesting: Testing av integrering av systemer og pakker; teste grensesnitt til eksterne organisasjoner (f.eks. elektronisk datautveksling, Internett).
systemtesting: Prosessen med å teste et integrert system for å verifisere at det oppfyller spesifiserte krav. (Hetzel)
T
teknisk gjennomgang: En diskusjonsaktivitet for faggrupper som fokuserer på å oppnå enighet om den tekniske tilnærmingen som skal tas. En teknisk gjennomgang er også kjent som fagfellevurdering. (Gilb og Graham, IEEE 1028)
test tilnærming: Implementeringen av teststrategien for et bestemt prosjekt. Det inkluderer vanligvis de avgjørelsene som er tatt basert på (test) prosjektets mål og risikovurderingen, utgangspunkt for testprosessen, testdesignteknikkene som skal brukes, utgangskriterier og testtyper som skal utføres.
test automatisering: Bruk av programvare for å utføre eller støtte testaktiviteter, f.eks. testledelse, testdesign, testutførelse og resultatkontroll.
testgrunnlag: Alle dokumenter som kravene til en komponent eller et system kan utledes fra. Dokumentasjonen som prøvesakene bygger på. Hvis et dokument bare kan endres ved en formell endringsprosedyre, kalles testgrunnlaget et frossent testgrunnlag. (Etter TMap)
testforsøk: Et sett med inngangsverdier, utførelsesforutsetninger, forventede resultater og utførelsesforutsetninger, utviklet for et bestemt mål eller en testtilstand, for eksempel å utøve en bestemt programbane eller å verifisere samsvar med et spesifikt krav. (Etter IEEE 610)
test case spesifikasjon: Et dokument som spesifiserer et sett med testtilfeller (objektiv, innspill, testhandlinger, forventede resultater og utførelsesforutsetninger) for et testelement. (Etter IEEE 829)
test charter: En uttalelse om testmål, og muligens testideer. Testcharter er blant annet brukt i utforskende testing. Se også utforskende testing.
testkomparator: Et testverktøy for å utføre automatisk testsammenligning.
test sammenligning: Prosessen med å identifisere forskjeller mellom de faktiske resultatene som produseres av komponenten eller systemet som testes, og de forventede resultatene for en test. Test sammenligning kan utføres under testutførelse (dynamisk sammenligning) eller etter testutførelse.
testforhold: En gjenstand eller hendelse av en komponent eller et system som kan verifiseres av en eller flere testsaker, f.eks. en funksjon, transaksjon, kvalitetsattributt eller strukturelt element.
testdata: Data som eksisterer (for eksempel i en database) før en test utføres, og som påvirker eller påvirkes av komponenten eller systemet som testes.
test data forberedelse verktøy: En type testverktøy som gjør det mulig å velge data fra eksisterende databaser eller opprette, generere, manipulere og redigere for bruk i testing.
test design spesifikasjon: Et dokument som spesifiserer testforholdene (dekningselementer) for en testartikkel, den detaljerte testtilnærmingen og identifiserer de tilknyttede testnivåene på høyt nivå. (Etter IEEE 829)
test design verktøy: Et verktøy som støtter testdesignaktiviteten ved å generere testinnganger fra en spesifikasjon som kan holdes i et CASE-verktøylager, f.eks. kravhåndteringsverktøy, eller fra spesifiserte testforhold i selve verktøyet.
test design teknikk: En metode som brukes til å utlede eller velge testsaker.
test miljø: Et miljø som inneholder maskinvare, instrumentering, simulatorer, programvareverktøy og andre støtteelementer som trengs for å gjennomføre en test. (Etter IEEE 610)
testevalueringsrapport: Et dokument produsert på slutten av testprosessen som oppsummerer alle testaktiviteter og resultater. Den inneholder også en evaluering av testprosessen og erfaringer.
testutførelse: Prosessen med å kjøre en test av komponenten eller systemet som testes, og produserer faktiske resultater.
automatisering av testutførelse: Bruk av programvare, f.eks. fangst- / avspillingsverktøy, for å kontrollere gjennomføring av tester, sammenligning av faktiske resultater med forventede resultater, oppsett av testforutsetninger og andre testkontroll- og rapporteringsfunksjoner.
testutførelsesfase: Tiden i en livssyklus for programvareutvikling der komponentene i et programvareprodukt kjøres, og programvareproduktet blir evaluert for å avgjøre om kravene er oppfylt eller ikke. (IEEE 610)
testutførelsesplan: En ordning for gjennomføring av testprosedyrer. Testprosedyrene er inkludert i testutførelsesplanen i deres sammenheng og i rekkefølgen de skal utføres i.
testutførelsesteknikk: Metoden som brukes til å utføre den faktiske testutførelsen,enten manuelt eller automatisert.
testutførelsesverktøy: En type testverktøy som er i stand til å utføre annen programvare ved hjelp av et automatisert testskript, f.eks. fange / spille av. (Fewster og Graham)
test sele: Et testmiljø bestående av stubber og drivere som trengs for å gjennomføre en test.
test infrastruktur: De organisatoriske gjenstandene som trengs for å utføre testing, bestående av testmiljøer, testverktøy, kontormiljø og prosedyrer.
test produkt: Det enkelte elementet som skal testes. Det er vanligvis ett testobjekt og mange testelementer. Se også testobjekt.
testnivå: En gruppe testaktiviteter som er organisert og ledet sammen. Et testnivå er knyttet til ansvaret i et prosjekt. Eksempler på testnivåer er komponenttest, integrasjonstest, systemtest og akseptantest. (Etter TMap)
testlogg: En kronologisk oversikt over relevante detaljer om gjennomføring av tester. (IEEE 829)
testlogging: Prosessen med å registrere informasjon om tester utført i en testlogg.
testleder: Personen som er ansvarlig for å teste og evaluere et testobjekt. Individet, som leder, kontrollerer, administrerer planer og regulerer evalueringen av et testobjekt.
testledelse: Planlegging, estimering, overvåking og kontroll av testaktiviteter, vanligvis utført av en testleder.
Testmodningsmodell (TMM): Et iscenesatt rammeverk med fem nivåer for forbedring av testprosessen, relatert til Capability Maturity Model (CMM) som beskriver nøkkelelementene i en effektiv testprosess.
Testprosessforbedring (TPI): Et kontinuerlig rammeverk for forbedring av testprosessen som beskriver nøkkelelementene i en effektiv testprosess, spesielt rettet mot systemtesting og aksepttesting.
testobjekt: Komponenten eller systemet som skal testes. Se også testelement.
testmål: En grunn eller et formål for å designe og gjennomføre en test.
test orakel: En kilde for å bestemme forventede resultater som skal sammenlignes med det faktiske resultatet av programvaren som testes. Et orakel kan være det eksisterende systemet (for en referanseindeks), en brukerhåndbok eller individets spesialiserte kunnskap, men bør ikke være koden. (Etter Adrion)
test ytelsesindikator: En beregning, generelt høyt nivå, som indikerer i hvilken grad en bestemt målverdi eller et kriterium er oppfylt. Ofte relatert til mål for forbedring av testprosessen, f.eks. Prosent av mangel deteksjon (DDP).
testfase: Et tydelig sett med testaktiviteter samlet inn i en håndterbar fase av et prosjekt, f.eks. utførelsesaktivitetene til et testnivå. (Etter Gerrard)
testplan: Et dokument som beskriver omfanget, tilnærmingen, ressursene og tidsplanen for tiltenkte testaktiviteter. Den identifiserer blant annet testelementer, funksjonene som skal testes, testoppgavene, hvem som skal utføre hver oppgave, graden av testers uavhengighet, testmiljøet, testdesignteknikkene og testmålingsteknikkene som skal brukes, og begrunnelsen for deres valg , og eventuelle risikoer som krever beredskapsplanlegging. Det er en oversikt over testplanleggingsprosessen (Etter IEEE 829)
testplanlegging: Aktiviteten med å etablere eller oppdatere en testplan.
testpolicy: Et høyt nivå dokument som beskriver prinsippene, tilnærmingen og hovedmålene for organisasjonen når det gjelder testing.
testpunktanalyse (TPA): En formelbasert testestimeringsmetode basert på funksjonspunktanalyse. (TMap)
test prosedyre: Se testprosedyrens spesifikasjon.
testprosedyre spesifikasjon: Et dokument som spesifiserer en sekvens av handlinger for gjennomføring av en test. Også kjent som testskript eller manuell testskript. (Etter IEEE 829)
testprosess: Den grunnleggende testprosessen består av planlegging, spesifikasjon, utførelse, registrering og kontroll for fullføring. (BS 7925/2)
test repeterbarhet: Et attributt for en test som indikerer om de samme resultatene produseres hver gang testen utføres.
prøvekjøring: Gjennomføring av en test på en spesifikk versjon av testobjektet.
testmanus: Ofte brukt til å referere til en spesifikasjon for testprosedyrer, spesielt en automatisert.
test spesifikasjon: Et dokument som består av en spesifikasjon av testdesign, spesifikasjon av testtilfelle og / eller spesifikasjon av testprosedyrer.
teststrategi: Et dokument på høyt nivå som definerer testnivåene som skal utføres og testing innenfor disse nivåene for et program (ett eller flere prosjekter).
test suite: Et sett med flere testsaker for en komponent eller et system som testes, der posttilstanden til en test ofte brukes som forutsetning for den neste.
testoppsummeringsrapport: Et dokument som oppsummerer testaktiviteter og resultater. Den inneholder også en evaluering av de tilsvarende testelementene mot utgangskriterier.(Etter IEEE 829)
testmål: Et sett med utgangskriterier.
testverktøy: Et programvareprodukt som støtter en eller flere testaktiviteter, som planlegging og kontroll, spesifikasjon, bygging av innledende filer og data, testutførelse og testanalyse. (TMap) Se også CAST.
test type: En gruppe testaktiviteter rettet mot å teste en komponent eller et system angående en eller flere sammenhengende kvalitetsattributter. En testtype er fokusert på et spesifikt testmål, dvs. pålitelighetstest, brukervennlighetstest, regresjonstest osv., Og kan finne sted på ett eller flere testnivåer eller testfaser. (Etter TMap)
testbarhet: Programvareproduktets evne til å muliggjøre testing av modifisert programvare. (ISO 9126) Se også vedlikeholdsevne.
testbarhetsanmeldelse: En detaljert kontroll av testgrunnlaget for å avgjøre om testgrunnlaget er på et tilstrekkelig kvalitetsnivå for å fungere som et inngangsdokument for testprosessen. (Etter TMap)
testbare krav: I hvilken grad et krav er angitt i termer som tillater etablering av testdesign (og deretter testtilfeller) og gjennomføring av tester for å avgjøre om kravene er oppfylt. (Etter IEEE 610)
tester: En teknisk dyktig fagperson som er involvert i testing av en komponent eller et system.
testing: Prosessen som består av alle livssyklusaktiviteter, både statiske og dynamiske, opptatt av planlegging, klargjøring og evaluering av programvareprodukter og relaterte arbeidsprodukter for å fastslå at de tilfredsstiller spesifiserte krav, for å demonstrere at de er egnet til formålet og for å oppdage feil.
testvare: Artefakter produsert under testprosessen som kreves for å planlegge, designe og utføre tester, for eksempel dokumentasjon, skript, innganger, forventede resultater, oppsett- og oppklaringsprosedyrer, filer, databaser, miljø og eventuell tilleggsprogramvare eller verktøy som brukes i testing. (Etter Fewster og Graham)
trådtesting: En versjon av komponentintegrasjonstesting der progressiv integrering av komponenter følger implementeringen av delmengder av kravene, i motsetning til integrering av komponenter etter nivåer i et hierarki.
sporbarhet: Evnen til å identifisere relaterte elementer i dokumentasjon og programvare, for eksempelkrav med tilhørende tester. Se også horisontal sporbarhet, vertikal sporbarhet.
top-down testing: En inkrementell tilnærming til integrasjonstesting der komponenten øverst i komponenthierarkiet testes først, med komponenter på lavere nivå som simuleres av stubber. Testede komponenter brukes deretter til å teste komponenter på lavere nivå. Prosessen gjentas til komponentene på laveste nivå er testet.
U
forståelighet: Programvareproduktets evne til å gjøre det mulig for brukeren å forstå om programvaren er egnet, og hvordan den kan brukes til bestemte oppgaver og bruksbetingelser. (ISO 9126) Se også brukervennlighet.
uoppnåelig kode: Kode som ikke kan nås og som derfor er umulig å utføre.
brukervennlighet: Programvarens evne til å bli forstått, lært, brukt og attraktiv for brukeren når den brukes under spesifiserte forhold. (ISO 9126)
brukervennlighetstesting: Testing for å bestemme i hvilken grad programvareproduktet er forstått, lett å lære, lett å betjene og attraktivt for brukerne under spesifiserte forhold. (Etter ISO 9126)
bruk saksprøving: En svart boks test design teknikk der test tilfeller er utformet for å utføre bruker scenarier.
brukertest: En test der virkelige brukere er involvert for å evaluere brukervennligheten til en komponent eller et system.
V
V-modell: Et rammeverk for å beskrive programvareutviklingens livssyklusaktiviteter fra kravspesifikasjon til vedlikehold. V-modellen illustrerer hvordan testaktiviteter kan integreres i hver fase av livssyklusen for programvareutvikling.
validering: Bekreftelse ved undersøkelse og gjennom fremleggelse av objektive bevis for at kravene til en spesifikk tiltenkt bruk eller anvendelse er oppfylt. (ISO 9000)
variabel: Et lagringselement på en datamaskin som er tilgjengelig for et program ved å referere til det med et navn.
bekreftelse: Bekreftelse ved undersøkelse og gjennom fremleggelse av objektive bevis for at spesifiserte krav er oppfylt. (ISO 9000)
vertikal sporbarhet: Sporing av krav gjennom lag med utviklingsdokumentasjon til komponenter.
volumtesting: Testing hvor systemet utsettes for store datamengder. Se også testing av ressursutnyttelse.
I
gjennomgang: En trinnvis presentasjon av forfatteren av et dokument for å samle informasjon og etablere en felles forståelse av innholdet. (Freedman og W.einberg, IEEE 1028)
hvit boks test design teknikk: Dokumentert prosedyre for å utlede og velge testsaker basert på en analyse av den interne strukturen til en komponent eller et system.
testing av hvit boks: Testing basert på en analyse av den interne strukturen til komponenten eller systemet.
Bredband Delphi: En ekspertbasert testestimeringsteknikk som tar sikte på å lage en nøyaktig estimering ved hjelp av gruppemedlemmene.
Kontakt meg hvis du vil legge til flere definisjoner i denne ordlisten.
Referanse: http://www.istqb.org/downloads/glossary-1.0.pdf
Anbefalt lesing
- Beste verktøy for testing av programvare 2021 (QA Test Automation Tools)
- Programvaretesting QA Assistant Job
- Programvare Testing Course: Hvilket programvare Testing Institute skal jeg delta?
- Velge programvaretesting som din karriere
- Programvaretesting Teknisk innhold Writer Freelancer Jobb
- QA Outsourcing Guide: Software Testing Outsourcing Companies
- Noen interessante spørsmål om intervjuer med programvaretesting
- Programvaretestkurs Tilbakemelding og anmeldelser