Software Testing vilkår komplet ordliste

software testing terms complete glossary

For at undgå tvetydighederne i forskellige softwaretestbetingelser vedlægger jeg en ordliste til softwaretest her.

Alle softwaretestbetingelser er inkluderet i denne ordliste. Hvis du føler, at du kender definitionen af ​​ethvert udtryk bedre end nævnt her, kan du bruge dette Kontaktformular at sende mig definitionerne. Efter gennemgang vil jeg medtage dem i denne ordliste.

At vide med de grundlæggende definitioner af softwaretest og kvalitetssikring er dette den bedste ordliste udarbejdet af Erik van Veenendaal . Også for hver definition er der en henvisning til IEEE eller ISO nævnt i parentes.

TIL

godkendelseskriterier: De udgangskriterier, som en komponent eller et system skal opfylde for at væreaccepteret af en bruger, kunde eller anden autoriseret enhed. (IEEE 610)

accept test: Formel test med hensyn til brugerbehov, krav og forretningsprocesser udført for at afgøre, om et system opfylder godkendelseskriterierne eller ej, og for at gøre det muligt for brugeren, kunderne eller en anden autoriseret enhed at afgøre, om systemet skal acceptere eller ej. (Efter IEEE 610)

tilgængelighedstest: Test for at bestemme den lethed, hvormed brugere med handicap kan bruge en komponent eller et system. (Gerrard)

nøjagtighed: Softwareproduktets evne til at levere de rigtige eller aftalte resultater eller effekter med den nødvendige grad af præcision. (ISO 9126) Se også funktionstest.

faktisk resultat: Den adfærd, der produceres / observeres, når en komponent eller et system testes.

ad hoc-test: Test udført uformelt ingen formel testforberedelse finder sted, ingen anerkendt testdesignteknik anvendes, der er ingen forventninger til resultater, og tilfældighed styrer testudførelsesaktiviteten.

tilpasningsevne: Softwareproduktets evne til at blive tilpasset til forskellige specificerede miljøer uden at anvende andre handlinger eller midler end dem, der er givet til dette formål til den pågældende software. (ISO 9126) Se også test af bærbarhed.

adræt test: Testpraksis for et projekt ved hjælp af agile metoder, såsom ekstrem programmering (XP), der behandler udvikling som kunden til testning og understreger test-første designparadigmet.

alfatest: Simuleret eller faktisk operationel test af potentielle brugere / kunder eller et uafhængigt testteam på udviklerens side, men uden for udviklingsorganisationen. Alfatestning anvendes ofte som en form for intern acceptstest.

analyserbarhed: Softwareproduktets evne til at blive diagnosticeret for mangler eller årsager til fejl i softwaren eller for at identificere de dele, der skal ændres. (ISO 9126) Se også vedligeholdelsestest.

anomali: Enhver tilstand, der afviger fra forventning baseret på kravspecifikationer, designdokumenter, brugerdokumenter, standarder osv. Eller fra en persons opfattelse eller erfaring. Afvigelser kan findes under, men ikke begrænset til, gennemgang, test, analyse, kompilering eller brug af softwareprodukter eller relevant dokumentation. (IEEE 1044) Se også defekt, afvigelse, fejl, fejl, fejl, hændelse, problem.

tiltrækningskraft: Softwareproduktets evne til at være attraktiv for brugeren. (ISO 9126)

revidere: En uafhængig evaluering af softwareprodukter eller processer for at sikre overholdelse af standarder, retningslinjer, specifikationer og / eller procedurer baseret på objektive kriterier, herunder dokumenter, der specificerer:

(1) form eller indhold af de produkter, der skal produceres

(2) den proces, hvormed produkterne skal produceres

(3) hvordan overholdelse af standarder eller retningslinjer skal måles. (IEEE 1028)

revisionsspor: En sti, hvor det originale input til en proces (f.eks. Data) kan spores tilbage gennem processen, idet procesoutputet tager udgangspunkt. Dette letter fejlanalyse og gør det muligt at udføre en procesrevision. (Efter TMap)

automatiseret testware: Testware, der bruges til automatiseret test, såsom værktøjsscripts.

tilgængelighed: I hvilken grad en komponent eller et system fungerer og er tilgængeligt, når det kræves til brug. Ofte udtrykt i procent. (IEEE 610)

B

back-to-back test: Test, hvor to eller flere varianter af en komponent eller et system udføres med de samme indgange, output sammenlignes og analyseres i tilfælde af uoverensstemmelser. (IEEE 610)

basislinje: En specifikation eller et softwareprodukt, der er blevet gennemgået eller aftalt formelt, som derefter tjener som basis for videreudvikling, og som kun kan ændres gennem en formel ændringskontrolproces. (Efter IEEE 610)

grundlæggende blok: En sekvens af et eller flere på hinanden følgende eksekverbare udsagn, der ikke indeholder grene.

basis test sæt: Et sæt testsager afledt af den interne struktur eller specifikation for at sikre, at 100% af et specificeret dækningskriterium opnås.

opførsel: Svaret fra en komponent eller et system til et sæt inputværdier og forudsætninger.

benchmark test: (1) En standard, mod hvilken målinger eller sammenligninger kan foretages. (2) En test, der bruges til at sammenligne komponenter eller systemer med hinanden eller til en standard som i (1). (Efter IEEE 610)

skræddersyet software: Software udviklet specielt til et sæt brugere eller kunder. Det modsatte er hyldesoftware.

bedste praksis: En overlegen metode eller innovativ praksis, der bidrager til en forbedret præstation for en organisation under en given sammenhæng, normalt anerkendt som 'bedst' af andre peer-organisationer.

betatestning: Operationel test af potentielle og / eller eksisterende brugere / kunder på et eksternt sted, der ikke ellers er involveret i udviklerne, for at afgøre, om en komponent eller et system tilfredsstiller brugerens / kundens behov og passer inden for forretningsprocesserne. Betatestning anvendes ofte som en form for ekstern acceptstest for at få tilbagemeldinger fra markedet.

big-bang test: En type integrationstest, hvor softwareelementer, hardwareelementer eller begge kombineres på én gang til en komponent eller et samlet system snarere end i etaper. (Efter IEEE 610) Se også integrationstest.

test af sort boks: Test, enten funktionel eller ikke-funktionel, uden henvisning til komponentens eller systemets interne struktur.

black box test design teknikker: Dokumenteret procedure til at udlede og udvælge testsager baseret på en analyse af specifikationen, enten funktionel eller ikke-funktionel, af en komponent eller et system uden henvisning til dens interne struktur.

blokeret test sag: En testsag, der ikke kan udføres, fordi forudsætningerne for dens gennemførelse ikke er opfyldt.

bottom-up test: En inkrementel tilgang til integrationstest, hvor komponenterne på det laveste niveau testes først og derefter bruges til at lette testningen af ​​komponenter på højere niveau. Denne proces gentages, indtil komponenten øverst i hierarkiet testes. Se også integrationstest.

grænseværdi: En inputværdi eller outputværdi, der er på kanten af ​​en ækvivalenspartition eller ved den mindste inkrementelle afstand på hver side af en kant, for eksempel minimums- eller maksimumværdien af ​​et interval.

grænseværdi analyse: En sort boks test design teknik, hvor test tilfælde er designet baseret på grænseværdier.

grænseværdi dækning: Procentdelen af ​​grænseværdier, der er udøvet af en testpakke.

afdeling: En grundlæggende blok, der kan vælges til udførelse baseret på en programkonstruktion, hvor en af ​​to eller flere alternative programstier er tilgængelige, f.eks. sag, spring, gå til, hvis det ellers.

filialdækning: Procentdelen af ​​filialer, der er udøvet af en testpakke. 100% filialdækning indebærer både 100% beslutningsdækning og 100% erklæringsdækning.

filialtest: En testteknik til en hvid boks, hvor testcases er designet til at udføre grene.

forretningsprocesbaseret test: En tilgang til test, hvor testcases er designet ud fra beskrivelser og / eller viden om forretningsprocesser.

C

Kapacitet modenhedsmodel (CMM): En iscenesat ramme på fem niveauer, der beskriver nøgleelementerne i en effektiv softwareproces. Moden om kapacitetsmodning dækker fremgangsmåder til planlægning, konstruktion og styring af softwareudvikling og vedligeholdelse. (CMM)

Capability Maturity Model Integration (CMMI): En ramme, der beskriver nøgleelementerne i en effektiv produktudviklings- og vedligeholdelsesproces. Capability Maturity Model Integration dækker fremgangsmåder til planlægning, konstruktion og styring af produktudvikling og vedligeholdelse. CMMI er den udpegede efterfølger for CMM. (CMMI)

optage / afspilningsværktøj: En type testudførelsesværktøj, hvor input registreres under manuel test for at generere automatiske testscripts, der kan udføres senere (dvs. genafspilles). Disse værktøjer bruges ofte til at understøtte automatiseret regressionstest.

SAG: Forkortelse for Computer Aided Software Engineering.

CAST: Forkortelse for Computer Aided Software Testing. Se også testautomatisering.

årsag-virkning graf: En grafisk gengivelse af input og / eller stimuli (årsager) med deres tilknyttede output (effekter), som kan bruges til at designe testcases.

årsag-virkning tegning: En sort boks test design teknik, hvor test tilfælde er designet ud fra årsag-virkning grafer. (BS 7925/2)

certificering: Processen med at bekræfte, at en komponent, et system eller en person overholder de specificerede krav, f.eks. ved at bestå en eksamen.

omskiftelighed: Softwareproduktets evne til at muliggøre implementering af specificerede ændringer. (ISO 9126) Se også vedligeholdelsesevne.

klassificeringstræ metode: En designteknik til en sort boks, hvor testtilfælde, beskrevet ved hjælp af et klassificeringstræ, er designet til at udføre kombinationer af repræsentanter for input- og / eller outputdomæner. (Grochtmann)

kode dækning: En analysemetode, der bestemmer, hvilke dele af softwaren der er blevet udført (dækket) af testpakken, og hvilke dele der ikke er udført, f.eks. erklæring dækning, beslutning dækning eller tilstand dækning.

sameksistens: Softwareproduktets evne til at eksistere sammen med anden uafhængig software i et fælles miljø, der deler fælles ressourcer. (ISO 9126) Se test af bærbarhed.

kompleksitet: I hvilken grad en komponent eller et system har et design og / eller en intern struktur, der er vanskelig at forstå, vedligeholde og verificere. Se også cyklomatisk kompleksitet.

overholdelse: Softwareproduktets evne til at overholde standarder, konventioner eller regler i love og lignende recepter. (ISO 9126)

test af overholdelse : Testprocessen for at bestemme overholdelsen af ​​komponent eller system.

komponent: En minimal softwarepost, der kan testes isoleret.

test af komponentintegration: Test udført for at afsløre defekter i grænsefladerne og interaktion mellem integrerede komponenter.

komponent specifikation: En beskrivelse af en komponents funktion i form af dens outputværdier for specificerede inputværdier under specificerede forhold og krævet ikke-funktionel adfærd (f.eks. Ressourceudnyttelse).

komponent test: Test af individuelle softwarekomponenter. (Efter IEEE 610)

sammensat tilstand: To eller flere enkelte betingelser forbundet ved hjælp af en logisk operator (AND, OR eller XOR), f.eks. 'A> B OG C> 1000'.

test af samtidighed: Test for at bestemme, hvordan forekomsten af ​​to eller flere aktiviteter inden for det samme tidsinterval, opnået enten ved at sammenflette aktiviteterne eller ved samtidig udførelse, håndteres af komponenten eller systemet. (Efter IEEE 610)

tilstand: Et logisk udtryk, der kan vurderes som sandt eller falsk, f.eks. A> B. Se også testtilstand.

tilstandsdækning: Procentdelen af ​​tilstandsresultater, der er udøvet af en testpakke. 100% betingelsesdækning kræver, at hver enkelt tilstand i hver beslutningserklæring testes som sand og falsk.

betingelse bestemmelse dækning: Procentdelen af ​​alle udfald af en enkelt tilstand, der uafhængigt påvirker et beslutningsresultat, der er udøvet af en test case suite. 100% betingelsesbestemmelsesdækning indebærer 100% beslutningsbetingelsesdækning.

test af tilstandsbestemmelse: En designteknik for en hvid boks, hvor testcases er designet til at udføre resultater med en enkelt tilstand, der uafhængigt påvirker et beslutningsresultat.

tilstandstest: En hvid boks test design teknik, hvor test tilfælde er designet til at udføre tilstandsresultater.

tilstandsresultat: Evaluering af en tilstand til sand eller falsk.

konfiguration: Sammensætningen af ​​en komponent eller et system som defineret af antallet, karakteren og sammenkoblingen af ​​dets bestanddele.

konfigurationsrevision: Funktionen til at kontrollere indholdet af biblioteker med konfigurationselementer, f.eks. for overholdelse af standarder. (IEEE 610)

konfigurationskontrol: Et element i konfigurationsstyring, der består af evaluering, koordinering, godkendelse eller afvisning og implementering af ændringer til konfigurationselementer efter formel etablering af deres konfigurationsidentifikation. (IEEE

610)

konfigurationsidentifikation: Et element i konfigurationsstyring, der består i at vælge konfigurationselementerne til et system og registrere deres funktionelle og fysiske egenskaber i teknisk dokumentation. (IEEE 610)

konfigurationselement: En sammenlægning af hardware, software eller begge dele, der er udpeget til konfigurationsstyring og behandlet som en enkelt enhed i konfigurationsstyringsprocessen. (IEEE 610)

Konfigurationsstyring: En disciplin, der anvender teknisk og administrativ retning og overvågning for at: identificere og dokumentere de funktionelle og fysiske egenskaber ved et konfigurationselement, kontrollere ændringer til disse karakteristika, registrere og rapportere ændringer til bearbejdnings- og implementeringsstatus og kontrollere overensstemmelse med specificerede krav. (IEEE 610)

konsistens: Graden af ​​ensartethed, standardisering og frihed fra modsigelse mellem dokumenter eller dele af en komponent eller et system. (IEEE 610)

kontrol flow: En abstrakt gengivelse af alle mulige sekvenser af begivenheder (stier) i udførelsen gennem en komponent eller et system.

konverteringstest: Test af software, der bruges til at konvertere data fra eksisterende systemer til brug i erstatningssystemer.

BØRNE: Forkortelse for kommerciel off-the-shelf software.

dækning: Graden udtrykt i procent, hvor en specificeret dækning er udøvet af en testpakke.

dækningsanalyse: Måling af opnået dækning til et specificeret dækningselement under testudførelse med henvisning til forudbestemte kriterier for at bestemme, om yderligere test er påkrævet, og hvis ja, hvilke testtilfælde der er behov for.

dækning: En enhed eller ejendom, der bruges som grundlag for testdækning, f.eks. ækvivalenspartitioner eller kodeudtalelser.

dækningsværktøj: Et værktøj, der giver objektive mål for, hvilke strukturelle elementer, f.eks. erklæringer, er filialer udøvet af testpakken.

cyklomatisk kompleksitet: Antallet af uafhængige stier gennem et program. Cyklomatisk kompleksitet er defineret som: L - N + 2P, hvor -L = antallet af kanter / links i en graf -N = antallet af noder i en graf - P = antallet af frakoblede dele af grafen (f.eks. En kaldegraf og en underrutine). (Efter McCabe)

D

datadefinition: En eksekverbar erklæring, hvor en variabel tildeles en værdi.

datadrevet test: En scriptteknik, der gemmer testinput og forventede resultater i en tabel eller et regneark, så et enkelt kontrolscript kan udføre alle testene i tabellen. Datadrevet test bruges ofte til at understøtte anvendelsen af ​​testudførelsesværktøjer såsom capture / playback-værktøjer. (Fewster og Graham) Se også søgeordsdrevet test.

datastrøm: En abstrakt repræsentation af sekvensen og mulige ændringer af dataobjektens tilstand, hvor et objekts tilstand er en af:skabelse, brug eller ødelæggelse. (Beizer)

datastrømsanalyse: En form for statisk analyse baseret på definition og anvendelse af variabler.

datastrøm dækning: Procentdelen af ​​definition-brugspar, der er udøvet af en test case-suite.

dataflow test: En designteknik til en hvid boks, hvor testcases er designet til at udføre definition og bruge par af variabler.

fejlretning: Processen med at finde, analysere og fjerne årsagerne til fejl i software.

fejlfindingsværktøj: Et værktøj, der bruges af programmører til at reproducere fejl, undersøge programmets tilstand og finde den tilsvarende fejl. Debuggere gør det muligt for programmører at udføre programmer trin for trin, stoppe et program ved enhver programerklæring og at indstille og undersøge programvariabler.

afgørelse: Et programpunkt, hvor kontrolflowet har to eller flere alternative ruter. En knude med to eller flere links til separate grene.

beslutningstilstand dækning: Procentdelen af ​​alle tilstandsresultater og beslutningsresultater, der er udøvet af en testpakke. 100% beslutningsdækning indebærer både 100% dækning af betingelse og 100% dækning af beslutninger.

test af beslutningstilstand: En hvid boks test design teknik, hvor test tilfælde er designet til at udføre tilstandsresultater og beslutningsresultater.

beslutningsdækning: Procentdelen af ​​beslutningsresultater, der er udøvet af en testpakke. 100% beslutningsdækning indebærer både 100% filialdækning og 100% erklæringsdækning.

beslutningstabel: En tabel, der viser kombinationer af input og / eller stimuli (årsager) med deres tilknyttede output og / eller handlinger (effekter), som kan bruges til at designe testsager.

beslutningstabeltestning: En sort boks test design teknikker, hvor test tilfælde er designet til at udføre kombinationer af input og / eller stimuli (årsager) vist i en beslutningstabel. (Veenendaal)

beslutningstest: En teknik til design af en hvid boks-test, hvor testsager er designet til at udføre beslutningsresultater.

beslutningsresultat: Resultatet af en beslutning (som derfor bestemmer de grene, der skal tages).

defekt: En fejl i en komponent eller et system, der kan få komponenten eller systemet til ikke at udføre den krævede funktion, f.eks. en forkert erklæring eller datadefinition. En defekt, hvis den opstår under udførelsen, kan forårsage en fejl i komponenten eller systemet.

defekt tæthed: Antallet af defekter, der er identificeret i en komponent eller et system divideret med komponentens eller systemets størrelse (udtrykt i standardmåleudtryk, f.eks. Kodelinjer, antal klasser eller funktionspunkter).

Procentdel af detektionsdetektering (DDP): antallet af mangler fundet i en testfase divideret med antallet fundet ved denne testfase og ethvert andet middel bagefter.

fejlrapport: Et dokument, der rapporterer om enhver fejl i en komponent eller et system, der kan få komponenten eller systemet til at udføre den nødvendige funktion. (Efter IEEE 829)

mangelforvaltning: Processen med at genkende, undersøge, tage handling og bortskaffe mangler. Det indebærer at registrere mangler, klassificere dem og identificere virkningen. (Efter IEEE 1044)

defekt maskering: En begivenhed, hvor en defekt forhindrer påvisning af en anden. (Efter IEEE 610)

definition-brug par: Sammenhængen mellem definitionen af ​​en variabel og brugen af ​​denne variabel. Variable anvendelser inkluderer beregning (f.eks. Multiplikation) eller til at styre udførelsen af ​​en sti ('predikat' -brug).

leveres: Ethvert (arbejde) produkt, der skal leveres til en anden, som (arbejde) produktets forfatter.

designbaseret test: En tilgang til testning, hvor testcases er designet baseret på arkitekturen og / eller detaljeret design af en komponent eller et system (f.eks. Test af grænseflader mellem komponenter eller systemer).

kontrol af skrivebordet: Test af software eller specifikation ved manuel simulering af dens udførelse.

udviklingstest: Formel eller uformel test udført under implementeringen af ​​en komponent eller et system, normalt i udviklingsmiljøet af udviklere. (Efter IEEE 610)

dokumentationstest: Test af dokumentationens kvalitet, f.eks. brugervejledning eller installationsvejledning.

domæne: Sættet, hvorfra gyldige input- og / eller outputværdier kan vælges.

chauffør: En softwarekomponent eller et testværktøj, der erstatter en komponent, der tager sig af styringen og / eller kaldet af en komponent eller et system. (Efter TMap)

dynamisk analyse: Processen med at evaluere adfærd, f.eks. hukommelsesydelse, CPU-brug af et system eller en komponent under udførelsen. (Efter IEEE 610)

dynamisk sammenligning: Sammenligning af faktiske og forventede resultater, udført, mens softwaren udføres, for eksempel af et testudførelsesværktøj.

dynamisk test: Test, der involverer udførelse af softwaren til en komponent eller et system.

ER

effektivitet: Softwareproduktets evne til at levere passende ydeevne i forhold til mængden af ​​ressourcer, der bruges under angivne forhold. (ISO 9126)

effektivitetstest: Testprocessen for at bestemme effektiviteten af ​​et softwareprodukt.

elementær sammenligningstest: En sort boks test design teknikker, hvor test tilfælde er designet til at udføre kombinationer af input ved hjælp af begrebet tilstandsbestemmelsesdækning. (TMap)

emulator: En enhed, et computerprogram eller et system, der accepterer de samme indgange og producerer de samme udgange som et givet system. (IEEE 610) Se også simulator.

adgangskriterier: sættet med generiske og specifikke betingelser for at tillade en proces at gå videre med en defineret opgave, f.eks. testfase. Formålet med adgangskriterier er at forhindre, at en opgave starter, som vil medføre mere (spildt) indsats sammenlignet med den nødvendige indsats for at fjerne de mislykkede adgangskriterier. (Gilb og Graham)

indgang: Den første eksekverbare erklæring inden for en komponent.

ækvivalenspartition: En del af et input- eller outputdomæne, for hvilket en komponents eller systems opførsel antages at være den samme, baseret på specifikationen.

ækvivalens partition dækning: Procentdelen af ​​ækvivalenspartitioner, der er udøvet af en testpakke.

ækvivalenspartitionering: En sort boks test design teknik, hvor test tilfælde er designet til at udføre repræsentanter fra ækvivalens partitioner. I princippet er testcases designet til at dække hver partition mindst en gang.

fejl: En menneskelig handling, der giver et forkert resultat. (Efter IEEE 610)

fejl gætte: En testdesignteknik, hvor testernes oplevelse bruges til at forudse, hvilke defekter der kan være til stede i komponenten eller systemet under test som resultat af fejl, og til at designe tests specifikt for at udsætte dem.

fejlsåning: Processen med forsætlig tilføjelse af kendte defekter til dem, der allerede findes i komponenten eller systemet med det formål at overvåge hastigheden for påvisning og fjernelse og estimere antallet af tilbageværende defekter. (IEEE 610)

fejltolerance: Et systems eller komponents evne til at fortsætte normal drift på trods af tilstedeværelsen af ​​fejlagtige input. (Efter IEEE 610).

undtagelse håndtering: En komponents eller systems adfærd som reaktion på fejlagtig input fra enten en menneskelig bruger eller fra en anden komponent eller et system eller til en intern fejl.

eksekverbar erklæring: En erklæring, som, når den kompileres, oversættes til objektkode, og som udføres proceduremæssigt, når programmet kører og muligvis udfører en handling på data.

udøvet: Et programelement siges at udøves af en testtilfælde, når inputværdien forårsager udførelsen af ​​dette element, såsom en erklæring, beslutning eller andet strukturelt element.

udtømmende test: En testtilgang, hvor testpakken omfatter alle kombinationer af inputværdier og forudsætninger.

udgangskriterier: Sættet med generiske og specifikke betingelser, der er aftalt med interessenterne, for at tillade en proces at blive afsluttet officielt. Formålet med exitkriterier er at forhindre, at en opgave betragtes som afsluttet, når der stadig er udestående dele af opgaven, som ikke er afsluttet. Udgangskriterier bruges ved test til at rapportere imod og planlægge, hvornår test skal stoppes. (Efter Gilb og Graham)

udgangssted: Den sidste eksekverbare erklæring inden for en komponent.

forventet resultat: Den adfærd, der forudsiges af specifikationen eller en anden kilde for komponenten eller systemet under specificerede forhold.

sonderende test: Testning, hvor testeren aktivt styrer designen af ​​testene, når disse tests udføres, og bruger information opnået under testning til at designe nye og bedre tests. (Bach)

F

svigte: En test anses for at fejle, hvis dens faktiske resultat ikke svarer til det forventede resultat.

fiasko: Faktisk afvigelse af komponenten eller systemet fra dens forventede levering, service eller resultat. (Efter Fenton)

fejl tilstand: Den fysiske eller funktionelle manifestation af en fiasko. For eksempel kan et system i fejltilstand være karakteriseret ved langsom drift, forkerte output eller fuldstændig afslutning af udførelse.

Fejltilstand og effektanalyse (FMEA): En systematisk tilgang til risikoidentifikation og analyse af identificering af mulige fiaskometoder og forsøg på at forhindre deres forekomst.

fejlrate: Forholdet mellem antallet af fejl i en given kategori og en given måleenhed, f.eks. fejl pr. tidsenhed, fejl pr. antal transaktioner, fejl pr. antal computerkørsler. (IEEE 610)

fejltolerance: Softwareproduktets evne til at opretholde et bestemt ydeevne i tilfælde af softwarefejl (defekter) eller krænkelse af det specificerede interface. (ISO 9126) Se også pålidelighed.

fejltræanalyse: En metode, der bruges til at analysere årsagerne til fejl (defekter).

mulig sti: En sti, for hvilken der findes et sæt inputværdier og forudsætninger, som får den til at blive udført.

funktion: En attribut for en komponent eller et system, der er specificeret eller underforstået i kravsdokumentation (f.eks. Pålidelighed, brugervenlighed eller designbegrænsninger). (Efter IEEE 1008)

endelig maskine: En beregningsmodel bestående af et begrænset antal stater og overgange mellem disse stater, muligvis med ledsagende handlinger. (IEEE 610)

formel gennemgang: En gennemgang karakteriseret ved dokumenterede procedurer og krav, f.eks. inspektion.

frossen testbasis: Et testbasisdokument, der kun kan ændres ved en formel proces til ændringskontrol. Se også basislinje.

Funktionspunktsanalyse (FPA): Metode, der sigter mod at måle størrelsen på et informationssystems funktionalitet. Målingen er uafhængig af teknologien. Denne måling kan bruges som grundlag for måling af produktivitet, estimering af de nødvendige ressourcer og projektstyring.

funktionel integration: En integrationsmetode, der kombinerer komponenterne eller systemerne med det formål at få en grundlæggende funktionalitet til at fungere tidligt. Se også integrationstest.

funktionelt krav: Et krav, der specificerer en funktion, som en komponent eller et system skal udføre. (IEEE 610)

funktionel test design teknik: Dokumenteret procedure til at udlede og udvælge testsager baseret på en analyse af specifikationen af ​​en komponents eller systems funktionalitet uden henvisning til dens interne struktur. Se også sort boks test design teknik.

funktionel test: Test baseret på en analyse af specifikationen af ​​en komponents eller systems funktionalitet. Se også test af sort boks.

funktionalitet: Softwareproduktets evne til at levere funktioner, der opfylder de angivne og underforståede behov, når softwaren bruges under specificerede forhold. (ISO 9126)

funktionstest: Testprocessen for at bestemme funktionaliteten af ​​et softwareprodukt.

G

test af glasæske: Se test af hvide kasser.

H

heuristisk evaluering: En statisk testteknik til brugervenlighed til at bestemme overholdelsen af ​​en brugergrænseflade med anerkendte anvendelsesprincipper (den såkaldte 'heuristik').

test tilfælde på højt niveau: En test case uden konkrete (implementeringsniveau) værdier for inputdata og forventede resultater.

vandret sporbarhed: Sporing af krav til et testniveau gennem lagene i testdokumentationen (f.eks. Testplan, specifikation af testdesign, specifikation af testcase og specifikation af testprocedurer).

jeg

konsekvensanalyse: Vurderingen af ​​ændring af lagene i udviklingsdokumentation, testdokumentation og komponenter for at implementere en given ændring af specificerede krav.

inkrementel udviklingsmodel: En udviklingslivscyklus, hvor et projekt er opdelt i en række trin, som hver leverer en del af funktionaliteten i de overordnede projektkrav. Kravene prioriteres og leveres i prioriteret rækkefølge i passende trin. I nogle (men ikke alle) versioner af denne livscyklusmodel følger hvert delprojekt en 'mini V-model' med sit eget design, kodning og testfaser.

app, hvor du kan downloade youtube-videoer

inkrementel test: Test, hvor komponenter eller systemer er integreret og testet en eller nogle ad gangen, indtil alle komponenter eller systemer er integreret og testet.

utilsigtet hændelse: Enhver begivenhed, der opstår under test, der kræver undersøgelse. (Efter IEEE 1008)

hændelsesstyring: Processen med at genkende, undersøge, tage handling og bortskaffe hændelser. Det indebærer at registrere hændelser, klassificere dem og identificere virkningen. (Efter IEEE 1044)

hændelsesstyringsværktøj: Et værktøj, der letter registrering og statussporing af hændelser fundet under test. De har ofte arbejdsfloworienterede faciliteter til at spore og kontrollere tildeling, korrektion og gentest af hændelser og levere rapporteringsfaciliteter.

hændelses rapport: Et dokument, der rapporterer om enhver begivenhed, der opstår under testen, der kræver undersøgelse. (Efter IEEE 829)

uafhængighed: Adskillelse af ansvar, hvilket tilskynder til gennemførelse af objektiv testning. (Efter DO-178b)

umulig sti: En sti, der ikke kan udøves af ethvert sæt mulige inputværdier.

uformel anmeldelse: En gennemgang, der ikke er baseret på en formel (dokumenteret) procedure.

input: En variabel (uanset om den er gemt i en komponent eller udenfor), der læses af en komponent.

input domæne: Sættet, hvorfra gyldige inputværdier kan vælges .. Se også domæne.

inputværdi: En forekomst af et input. Se også input.

inspektion: En type gennemgang, der er afhængig af visuel undersøgelse af dokumenter for at opdage mangler, f.eks. krænkelser af udviklingsstandarder og manglende overensstemmelse med dokumentation på højere niveau. Den mest formelle gennemgangsteknik og derfor altid baseret på en dokumenteret procedure. (Efter IEEE 610, IEEE 1028)

installationsbarhed: Softwareproduktets mulighed for at blive installeret i et specificeret miljø (ISO 9126). Se også bærbarhed.

test af installabilitet: Processen med at teste installationsprogrammet for et softwareprodukt. Se også bærbarhedstest.

installationsvejledning: Medfølgende instruktioner om ethvert passende medie, der guider installationsprogrammet gennem installationsprocessen. Dette kan være en manuel guide, trin-for-trin procedure, installationsguide eller en hvilken som helst anden lignende procesbeskrivelse.

installationsguide: Leveret software på ethvert passende medie, der fører installationsprogrammet gennem installationsprocessen. Det kører normalt installationsprocessen, giver feedback om installationsresultaterne og beder om muligheder.

instrumentering: Indsættelse af ekstra kode i programmet for at indsamle oplysninger om programadfærd under udførelse.

instrumenter: Et softwareværktøj, der bruges til at udføre instrumentering.

indtagelsestest: En særlig forekomst af en røgtest for at afgøre, om komponenten eller systemet er klar til detaljeret og yderligere test. En indtagelsestest udføres typisk i starten af ​​testudførelsesfasen.

integration: Processen med at kombinere komponenter eller systemer i større samlinger.

integrationstest: Test udført for at afsløre defekter i grænsefladerne og i interaktionen mellem integrerede komponenter eller systemer. Se også test af komponentintegration, test af systemintegration.

interface test: En integrationstesttype, der beskæftiger sig med at teste grænsefladerne mellem komponenter eller systemer.

interoperabilitet: Softwareproduktets evne til at interagere med en eller flere specificerede komponenter eller systemer. (Efter ISO 9126) Se også funktionalitet.

interoperabilitetstest: Testprocessen for at bestemme interoperabiliteten af ​​et softwareprodukt. Se også funktionstest.

ugyldig test: Test ved hjælp af inputværdier, der skal afvises af komponenten eller systemet. Se også fejltolerance.

isolationstest: Test af individuelle komponenter isoleret fra omgivende komponenter, hvor omgivende komponenter simuleres af stubbe og drivere, hvis det er nødvendigt.

TIL

søgeordsdrevet test: En scriptteknik, der bruger datafiler til ikke kun at indeholde testdata og forventede resultater, men også nøgleord relateret til den applikation, der testes. Nøgleordene fortolkes af specielle understøttende scripts, der kaldes af kontrolscriptet til testen. Se også datadrevet test.

L

LCSAJ: En lineær kodesekvens og spring, der består af følgende tre punkter (traditionelt identificeret ved linjenumre i en kildekodeliste): starten på den lineære sekvens af eksekverbare udsagn, slutningen af ​​den lineære sekvens og mållinien, som styres til flow overføres i slutningen af ​​den lineære sekvens.

LCSAJ-dækning: Procentdelen af ​​LCSAJ'er for en komponent, der er blevet udøvet af en testpakke. 100% LCSAJ-dækning indebærer 100% beslutningsdækning.

LCSAJ-test: En designteknik for en hvid boks, hvor testcases er designet til at udføre LCSAJ'er.

lærbarhed: Softwareproduktets evne til at gøre det muligt for brugeren at lære dets anvendelse. (ISO 9126) Se også anvendelighed.

belastningstest: En testtype, der beskæftiger sig med måling af en komponents eller systems opførsel med stigende belastning, f.eks. antal parallelle brugere og / eller antal transaktioner for at bestemme, hvilken belastning der kan håndteres af komponenten eller systemet.

lavt niveau test tilfælde: En test case med konkrete (implementeringsniveau) værdier for inputdata og forventede resultater.

M

vedligeholdelse: Ændring af et softwareprodukt efter levering for at rette fejl, forbedre ydeevne eller andre egenskaber eller tilpasse produktet til et modificeret miljø. (IEEE 1219)

vedligeholdelsestest: Test af ændringerne i et operativsystem eller virkningen af ​​et ændret miljø på et operativsystem.

vedligeholdelse: Den lethed, hvormed et softwareprodukt kan modificeres for at rette fejl, modificeres for at imødekomme nye krav, modificeres for at gøre fremtidig vedligeholdelse lettere eller tilpasset til et ændret miljø. (ISO 9126)

test af vedligeholdelsesevne: Testprocessen for at bestemme vedligeholdelsen af ​​et softwareprodukt.

ledelsesgennemgang: En systematisk evaluering af softwareanskaffelse, levering, udvikling, drift eller vedligeholdelsesproces, udført af eller på vegne af ledelsen, der overvåger fremskridt, bestemmer status for planer og tidsplaner, bekræfter krav og arvingssystemfordeling eller evaluerer effektiviteten af ​​ledelsesmetoder for at opnå egnethed til formålet. (Efter IEEE 610, IEEE 1028)

modenhed: (1) En organisations kapacitet med hensyn til effektiviteten af ​​dens processer og arbejdspraksis. Se også kapacitet modenhedsmodel, test modenhedsmodel. (2) Softwareproduktets evne til at undgå fiasko som følge af mangler i softwaren. (ISO 9126) Se også pålidelighed.

måle: Antallet eller kategorien tildelt en attribut for en enhed ved at foretage en måling (ISO 14598).

måling: Processen med at tildele et nummer eller en kategori til en enhed for at beskrive en attribut for den enhed. (ISO 14598)

måleskala: En skala, der begrænser den type dataanalyse, der kan udføres på den. (ISO 14598)

hukommelsestab: En fejl i programmets dynamiske butikstildelingslogik, der får det til ikke at genvinde hukommelse, efter at det er færdig med at bruge det, hvilket til sidst får programmet til at mislykkes på grund af manglende hukommelse.

metrisk: En måleskala og metoden, der anvendes til måling. (ISO 14598)

milepæl: Et tidspunkt i et projekt, hvor definerede (mellemliggende) leverancer ogresultaterne skal være klar.

moderator: Lederen og hovedpersonen, der er ansvarlig for en inspektion eller anden gennemgangsproces.

overvåge: Et softwareværktøj eller hardwareenhed, der kører samtidigt med komponenten eller systemet under test og overvåger, registrerer og / eller analyserer komponentens eller systemets opførsel. (Efter IEEE 610)

dækning af flere forhold: Procentdelen af ​​kombinationer af alle enkelt betingelserresultater inden for en erklæring, der er udøvet af en testpakke. 100% flerebetingelsesdækning indebærer 100% betingelsesbestemmelsesdækning.

test af flere forhold: En teknik til design af en hvid boks test, hvor testcases er designet til at udføre kombinationer af resultater med en enkelt tilstand (inden for en sætning).

mutationsanalyse: En metode til at bestemme test suite grundighed ved at måle, i hvor høj grad en test suite kan skelne mellem programmet fra små varianter (mutanter) af programmet.

N

N-switch dækning: Procentdelen af ​​sekvenser af N + 1-overgange, der er udøvet af en testpakke. (Chow)

N-switch test: En form for tilstandstransitionstest, hvor testcases er designet til at udføre alle gyldige sekvenser af N + 1-overgange. (Chow) Se også tilstandsovergangstest.

negativ test: Test med det formål at vise, at en komponent eller et system ikke fungerer. Negativ testning er relateret til testernes holdning snarere end en specifik testtilgang eller testdesignteknik. (Efter Beizer).

Manglende overensstemmelse: Manglende opfyldelse af et specificeret krav. (ISO 9000)

ikke-funktionelt krav: Et krav, der ikke vedrører funktionalitet, men egenskaber som pålidelighed, effektivitet, brugervenlighed, vedligeholdelsesevne og bærbarhed.

ikke-funktionel test: Test af attributterne for en komponent eller et system, der ikke vedrører funktionalitet, f.eks. pålidelighed, effektivitet, brugervenlighed, vedligeholdelighed og bærbarhed.

ikke-funktionelle testdesignteknikker: Metoder, der bruges til at designe eller vælge tests til ikke-funktionel test.

ELLER

hyldesoftware: Et softwareprodukt, der er udviklet til det generelle marked, dvs. for et stort antal kunder, og som leveres til mange kunder i identisk format.

anvendelighed: Softwareproduktets evne til at gøre det muligt for brugeren at betjene og kontrollere det. (ISO 9126) Se også anvendelighed.

driftsmiljø: Hardware- og softwareprodukter installeret på brugernes eller kunders websteder, hvor den komponent eller det testede system vil blive brugt. Softwaren kan omfatte operativsystemer, databasestyringssystemer og andre applikationer.

test af operationel profil: Statistisk test ved hjælp af en model af systemoperationer (opgaver med kort varighed) og sandsynligheden for typisk brug. (Musa)

operationel test: Test udført for at evaluere en komponent eller et system i dets driftsmiljø. (IEEE 610)

produktion: En variabel (uanset om den er gemt i en komponent eller udenfor), der er skrevet af en komponent.

output domæne: Sættet, hvorfra gyldige outputværdier kan vælges. Se også domæne.

output værdi: En forekomst af et output. Se også output.

P

par programmering: En softwareudviklingsmetode, hvor kodelinjer (produktion og / eller test) af en komponent skrives af to programmører, der sidder ved en enkelt computer. Dette betyder implicit, at der gennemføres løbende realtidskodevurderinger.

par test: To testere arbejder sammen for at finde mangler. Typisk deler de en computer og handler med dem under test.

Passere: En test anses for at være bestået, hvis dens faktiske resultat svarer til det forventede resultat.

bestå / ikke bestå kriterier: Beslutningsregler, der bruges til at bestemme, om et testelement (funktion) eller funktion er bestået eller ikke bestået en test. (IEEE 829)

sti: En sekvens af begivenheder, f.eks. eksekverbare udsagn om en komponent eller et system fra et indgangssted til et udgangspunkt.

stigdækning: Procentdelen af ​​stier, der er udøvet af en testpakke. 100% stigdækning indebærer 100% LCSAJ-dækning.

stisensibiliserende: Valg af et sæt inputværdier til at tvinge udførelsen af ​​en given sti.

statestning: En testteknik til en hvid boks, hvor testcases er designet til at udføre stier.

ydeevne: I hvilken grad et system eller en komponent udfører sine udpegede funktioner inden for givne begrænsninger med hensyn til behandlingstid og gennemstrømningshastighed. (Efter IEEE 610) Se effektivitet.

præstationsindikator: En høj grad af effektivitet og / eller effektivitet brugt til at styre og kontrollere progressiv udvikling, f.eks. Procentdel af defektdetektion (DDP) til test. (CMMI)

ydelsestest: Testprocessen for at bestemme ydelsen af ​​et softwareprodukt. Se effektivitetstest.

værktøj til test af ydelse: Et værktøj til at understøtte præstationstest, og som normalt har to hovedfaciliteter: generering af belastning og måling af testtransaktioner. Belastningsgenerering kan simulere enten flere brugere eller store mængder inputdata. Under udførelsen tages måling af responstid fra udvalgte transaktioner, og disse registreres. Værktøj til præstationstest leverer normalt rapporter baseret på testlogfiler og grafer over belastning i forhold til responstider.

fasetestplan: En testplan, der typisk adresserer et testniveau.

bærbarhed: Den lethed, hvormed softwareproduktet kan overføres fra en hardware eller et softwaremiljø til et andet. (ISO 9126)

bærbarhedstest: Testprocessen for at bestemme bærbarheden af ​​et softwareprodukt.

posttilstand: Miljømæssige og tilstandsbetingelser, der skal være opfyldt efter udførelse af en test eller testprocedure.

sammenligning efter udførelse: Sammenligning af faktiske og forventede resultater, udført efter at softwaren er kørt.

forudsætning: Miljø- og tilstandsbetingelser, der skal være opfyldt, før komponenten eller systemet kan udføres med en bestemt test- eller testprocedure.

Prioritet: Niveauet af (forretnings) betydning, der tildeles en vare, f.eks. defekt.

procescyklustest: En sort boks test design teknik, hvor test cases er designet til at udføre forretningsprocedurer og processer. (TMap)

behandle: Et sæt af indbyrdes forbundne aktiviteter, der omdanner input til output. (ISO 12207)

projekt: Et projekt er et unikt sæt koordinerede og kontrollerede aktiviteter med start- og slutdatoer, der gennemføres som et mål, der overholder specifikke krav, herunder tidsbegrænsninger, omkostninger og ressourcer. (ISO 9000)

projekt testplan: En testplan, der typisk adresserer flere testniveauer.

pseudo-tilfældig: En serie, der ser ud til at være tilfældig, men faktisk er genereret efter en forudbestemt sekvens.

Q

kvalitet: I hvilken grad en komponent, et system eller en proces opfylder specificerede krav og / eller bruger / kunders behov og forventninger. (Efter IEEE 610)

kvalitetssikring: En del af kvalitetsstyring med fokus på at give tillid til, at kvalitetskravene bliver opfyldt. (ISO 9000)

kvalitetsattribut: En funktion eller karakteristik, der påvirker en vares kvalitet. (IEEE 610)

kvalitetsstyring: Koordinerede aktiviteter for at lede og kontrollere en organisation med hensyn til kvalitet. Retning og kontrol med hensyn til kvalitet inkluderer generelt etablering af kvalitetspolitik og kvalitetsmål, kvalitetsplanlægning, kvalitetskontrol, kvalitetssikring og kvalitetsforbedring. (ISO 9000)

R

tilfældig test: En sort boks test design teknik, hvor test tilfælde er valgt, muligvis ved hjælp af en pseudo-tilfældig generation algoritme, til at matche en operationel profil. Denne teknik kan bruges til at teste ikke-funktionelle attributter såsom pålidelighed og ydeevne.

genopretningsgrad: Softwareproduktets evne til at gendanne et bestemt ydeevne og gendanne de direkte berørte data i tilfælde af fejl. (ISO 9126) Se også pålidelighed.

test af inddrivelighed: Testprocessen for at bestemme gendannelsen af ​​et softwareprodukt. Se også pålidelighedstest.

regressionstest: Test af et tidligere testet program efter modifikation for at sikre, at defekter ikke er blevet introduceret eller afdækket i uændrede områder af softwaren som et resultat af de foretagne ændringer. Det udføres, når softwaren eller dens miljø ændres.

udgivelsesnote: Et dokument, der identificerer testelementer, deres konfiguration, aktuelle status og andre leveringsoplysninger leveret af udvikling til test og muligvis andre interessenter i starten af ​​en testudførelsesfase. (Efter IEEE 829)

pålidelighed: Softwareproduktets evne til at udføre de krævede funktioner under angivne forhold i en bestemt periode eller i et bestemt antal operationer. (ISO 9126)

pålidelighedstest: Testprocessen for at bestemme pålideligheden af ​​et softwareprodukt.

udskiftelighed: Softwareproduktets evne til at blive brugt i stedet for et andet specificeret softwareprodukt til det samme formål i det samme miljø. (ISO 9126) Se også bærbarhed.

krav: En betingelse eller kapacitet, som en bruger har brug for til at løse et problem eller opnå et mål, som et system eller en systemkomponent skal opfylde eller besidde for at opfylde en kontrakt, standard, specifikation eller andet formelt pålagt dokument. (Efter IEEE 610)

kravbaseret test: En metode til testning, hvor testcases er designet baseret på testmål og testbetingelser afledt af krav, f.eks. test, der udøver specifikke funktioner eller prøver ikke-funktionelle attributter såsom pålidelighed eller anvendelighed.

værktøj til styring af krav: Et værktøj, der understøtter registrering af krav, kravattributter (f.eks. Prioritet, videnansvarlig) og kommentering og letter sporbarhed gennem lag af krav og kravændringsstyring. Nogle kravstyringsværktøjer giver også faciliteter til statisk analyse, såsom konsistenskontrol og overtrædelser af foruddefinerede kravregler.

kravsfase: Tidsperioden i softwarelevecyklussen, i hvilken ligningerne for et softwareprodukt er defineret og dokumenteret. (IEEE 610)

ressourceudnyttelse: Softwareproduktets evne til at bruge passende mængder og typer ressourcer, for eksempel mængderne af hoved- og sekundærhukommelse, der bruges af programmet, og størrelsen på krævede midlertidige filer eller overløbsfiler, når softwaren udfører sin funktion under angivne forhold. (Efter ISO 9126) Se også effektivitet.

test af ressourceudnyttelse: Testprocessen for at bestemme ressourceudnyttelsen af ​​et softwareprodukt.

resultat: Konsekvensen / resultatet af udførelsen af ​​en test. Det inkluderer output til skærme, ændringer af data, rapporter og kommunikationsmeddelelser sendt ud. Se også det faktiske resultat, forventet resultat.

genoptagelseskriterier: De testaktiviteter, der skal gentages, når testen genstartes efter en suspension. (Efter IEEE 829)

re-test: Test, der kører testsager, der mislykkedes sidste gang de blev kørt, for at kontrollere succesen med korrigerende handlinger.

anmeldelse: En evaluering af et produkt eller projektstatus for at fastslå afvigelser fra planlagte resultater og anbefale forbedringer. Eksempler inkluderer ledelsesanmeldelse, uformel gennemgang, teknisk gennemgang, inspektion og gennemgang. (Efter IEEE 1028)

anmelder: Den person, der er involveret i gennemgangen, som skal identificere og beskrive uregelmæssigheder i det produkt eller projekt, der gennemgås. Der kan vælges korrekturlæsere til at repræsentere forskellige synspunkter og roller i gennemgangsprocessen.

risiko: En faktor, der kan resultere i fremtidige negative konsekvenser; normalt udtrykt som påvirkning og sandsynlighed.

risikoanalyse: Processen med at vurdere identificerede risici for at estimere deres indvirkning og sandsynlighed for forekomst (sandsynlighed).

risikobaseret test: Test orienteret mod at udforske og give information om produktrisici. (Efter Gerrard)

risikokontrol: Processen, hvorved beslutninger nås og beskyttelsesforanstaltninger implementeres for at reducere risici til eller opretholde risici inden for bestemte niveauer.

risikoidentifikation: Processen med at identificere risici ved hjælp af teknikker som brainstorming, tjeklister og fejlhistorik.

Risikostyring: Systematisk anvendelse af procedurer og praksis på opgaverne med at identificere, analysere, prioritere og kontrollere risiko.

robusthed: I hvilken grad en komponent eller et system kan fungere korrekt i nærvær af ugyldige input eller stressende miljøforhold. (IEEE 610) Se også fejltolerance, fejltolerance.

hovedårsagen: En underliggende faktor, der forårsagede en manglende overensstemmelse og muligvis burde elimineres permanent gennem procesforbedring.

S

sikkerhed: Softwareproduktets evne til at opnå acceptable niveauer af risiko for skade på mennesker, forretning, software, ejendom eller miljøet i en specificeret sammenhæng med brugen. (ISO 9126)

sikkerhedstest: Testprocessen for at bestemme sikkerheden ved et softwareprodukt.

skalerbarhed: Softwareproduktets evne til at blive opgraderet for at imødekomme øgede belastninger. (Efter Gerrard)

test af skalerbarhed: Test for at bestemme skalerbarheden af ​​softwareproduktet.

skriftlærde: Den person, der skal registrere hver af de nævnte mangler og eventuelle forbedringsforslag under et gennemgangsmøde på en logningsformular. Skribenten skal sørge for, at logningsformularen er læselig og forståelig.

scripting sprog: Et programmeringssprog, hvor eksekverbare testskripter skrives, brugt af et testudførelsesværktøj (f.eks. Et capture / replay-værktøj).

sikkerhed: Attributter af softwareprodukter, der har sin evne til at forhindre uautoriseret adgang, hvad enten det er utilsigtet eller bevidst, til programmer og data. (ISO 9126)

sikkerhedstest: Test for at bestemme sikkerheden for softwareproduktet.

alvorlighed: Graden af ​​indvirkning, som en defekt har på udviklingen eller driften af ​​en komponent eller et system. (Efter IEEE 610)

simulation: Repræsentationen af ​​udvalgte adfærdsmæssige egenskaber ved et fysisk eller abstrakt system af et andet system. (ISO 2382/1)

simulator: En enhed, et computerprogram eller et system, der bruges under test, og som fungerer eller fungerer som et givet system, når det er udstyret med et sæt kontrollerede indgange. (Efter IEEE 610, DO178b) Se også emulator.

røg test: En delmængde af alle definerede / planlagte testtilfælde, der dækker en komponents eller systems hovedfunktionalitet, for at fastslå, at de mest vigtige funktioner i et program fungerer, men ikke gider med finere detaljer. En daglig konstruktion og røgtest er blandt bedste praksis i branchen. Se også indtagningstest.

softwarekvalitet: Den samlede funktionalitet og funktioner i et softwareprodukt, der har sin evne til at tilfredsstille de angivne eller underforståede behov. (Efter ISO 9126)

specifikation: Et dokument, der ideelt, på en komplet, præcis og verificerbar måde, specificerer kravene, designet, opførelsen eller andre karakteristika ved en komponent eller et system og ofte procedurerne til at afgøre, om disse bestemmelser er opfyldt. (Efter IEEE 610)

specifikationsbaseret testdesignteknik: Se den sorte boks test design teknik.

specificeret input: Et input, som specifikationen forudsiger et resultat for.

stabilitet: Softwareproduktets evne til at undgå uventede effekter fra ændringer i softwaren. (ISO 9126) Se også vedligeholdelsesevne.

tilstandsdiagram: Et diagram, der viser de tilstande, som en komponent eller et system kan antage, og viser de begivenheder eller omstændigheder, der forårsager og / eller skyldes en ændring fra en tilstand til en anden. (IEEE 610)

statstabel: Et gitter, der viser de resulterende overgange for hver tilstand kombineret med hver mulig begivenhed, der viser både gyldige og ugyldige overgange.

tilstandsovergang: En overgang mellem to tilstande i en komponent eller et system.

hvad er formålet med test af brugeraccept

test af tilstandstransition: En sort boks test design teknik, hvor test tilfælde er designet til at udføre gyldige og ugyldige tilstandsovergange. Se også test af N-switch.

udmelding: En enhed på et programmeringssprog, som typisk er den mindste udelelige enhed til udførelse.

erklæring dækning: Procentdelen af ​​eksekverbare udsagn, der er udøvet af en testpakke.

erklæring test: En hvid boks test design teknik, hvor test tilfælde er designet til at udføre udsagn.

statisk analyse: Analyse af softwareartifakter, f.eks. krav eller kode, udført uden udførelse af disse softwareartifakter.

statisk analysator: Et værktøj, der udfører statisk analyse.

analyse af statisk kode: Analyse af programkildekode udført uden udførelse af denne software.

statisk kode analysator: Et værktøj, der udfører analyse af statisk kode. Værktøjet kontrollerer kildekoden for bestemte egenskaber, f.eks. Overensstemmelse med kodningsstandarder, kvalitetsmålinger eller dataforløbsafvigelser.

statisk test: Test af en komponent eller et system på specifikations- eller implementeringsniveau uden udførelse af denne software, f.eks. anmeldelser eller analyse af statisk kode.

statistisk test: En testdesignteknik, hvor en model af den statistiske fordeling af input bruges til at konstruere repræsentative testsager. Se også test af operationel profil.

statusregnskab: Et element i konfigurationsstyring, der består af optagelse og rapportering af de oplysninger, der er nødvendige for at styre en konfiguration effektivt. Disse oplysninger inkluderer en liste over godkendt konfigurationsidentifikation, status for foreslåede ændringer til konfigurationen og implementeringsstatus for de godkendte ændringer. (IEEE 610)

Stresstest: Test udført for at evaluere et system eller en komponent inden for eller uden for grænserne for dets specificerede krav. (IEEE 610)

strukturel dækning: Dækningsforanstaltninger baseret på komponentens interne struktur.

strukturel test design teknik: Se den hvide boks test design teknik.

stub: En skelet- eller specialimplementering af en softwarekomponent, der bruges til at udvikle eller teste en komponent, der ringer til eller på anden måde er afhængig af den. Det erstatter en kaldet komponent. (Efter IEEE 610)

undervej: En sekvens af eksekverbare udsagn inden for en komponent.

suspensionskriterier: Kriterierne, der bruges til (midlertidigt) at stoppe hele eller en del af testaktiviteterne på testelementerne. (Efter IEEE 829)

egnethed: Softwareproduktets evne til at levere et passende sæt funktioner til specificerede opgaver og brugermål. (ISO 9126) Se også funktionalitet.

Software Usability Measuring Inventory (SUMI): Et spørgeskema baseret brugbarhedstestteknik til evaluering af anvendeligheden, f.eks. brugertilfredshed af en komponent eller et system. (Veenendaal)

syntaks test: En sort boks test design teknik, hvor test tilfælde er designet baseret på definitionen af ​​input domæne og / eller output domæne.

system: En samling af komponenter organiseret til at udføre en bestemt funktion eller et sæt funktioner. (IEEE 610)

test af systemintegration: Test af integrationen af ​​systemer og pakker test af grænseflader til eksterne organisationer (f.eks. elektronisk dataudveksling, internet).

systemtest: Processen med at teste et integreret system for at kontrollere, at det opfylder specificerede krav. (Hetzel)

T

teknisk gennemgang: En peer group-diskussionsaktivitet, der fokuserer på at opnå konsensus om den tekniske tilgang, der skal tages. En teknisk gennemgang er også kendt som en peer review. (Gilb og Graham, IEEE 1028)

test tilgang: Implementeringen af ​​teststrategien for et specifikt projekt. Det inkluderer typisk de beslutninger, der følger, der er baseret på (test) projektets mål og den udførte risikovurdering, udgangspunkt for testprocessen, de testdesignteknikker, der skal anvendes, exitkriterier og testtyper, der skal udføres.

test automatisering: Brug af software til at udføre eller understøtte testaktiviteter, f.eks. testadministration, testdesign, testudførelse og resultatkontrol.

testbasis: Alle dokumenter, hvorfra kravene til en komponent eller et system kan udledes. Dokumentationen, som testsagerne er baseret på. Hvis et dokument kun kan ændres ved hjælp af en formel ændringsprocedure, kaldes testgrundlaget et frossent testgrundlag. (Efter TMap)

test sag: Et sæt inputværdier, eksekveringsforudsætninger, forventede resultater og eksekverings-postconditions, udviklet til et bestemt mål eller en testtilstand, såsom at udøve en bestemt programsti eller at kontrollere overholdelse af et specifikt krav. (Efter IEEE 610)

test case specifikation: Et dokument, der specificerer et sæt testsager (objektivt, input, testhandlinger, forventede resultater og eksekveringsforudsætninger) for et testelement. (Efter IEEE 829)

test charter: En erklæring om testmål og muligvis testideer. Testcharter er blandt andet brugt i sonderende test. Se også sonderende test.

test komparator: Et testværktøj til at udføre automatiseret testsammenligning.

test sammenligning: Processen med at identificere forskelle mellem de faktiske resultater produceret af komponenten eller systemet under test og de forventede resultater for en test. Testsammenligning kan udføres under testudførelse (dynamisk sammenligning) eller efter testudførelse.

testtilstand: En genstand eller begivenhed i en komponent eller et system, der kunne verificeres af en eller flere testsager, f.eks. en funktion, en transaktion, en kvalitetsattribut eller et strukturelt element.

testdata: Data, der findes (for eksempel i en database), før en test udføres, og som påvirker eller påvirkes af komponenten eller systemet, der testes.

værktøj til forberedelse af testdata: En type testværktøj, der gør det muligt at vælge data fra eksisterende databaser eller oprette, generere, manipulere og redigere dem til brug i test.

test design specifikation: Et dokument, der specificerer testforholdene (dækningselementer) for en testartikel, den detaljerede testmetode og identificerer de tilknyttede testniveauer på højt niveau. (Efter IEEE 829)

test design værktøj: Et værktøj, der understøtter testdesignaktiviteten ved at generere testinput fra en specifikation, der kan opbevares i et CASE-værktøjsregister, f.eks. kravstyringsværktøj eller fra specificerede testbetingelser i selve værktøjet.

test design teknik: En metode, der bruges til at udlede eller udvælge testsager.

testmiljø: Et miljø, der indeholder hardware, instrumentering, simulatorer, softwareværktøjer og andre supportelementer, der er nødvendige for at udføre en test. (Efter IEEE 610)

testevalueringsrapport: Et dokument produceret i slutningen af ​​testprocessen, der opsummerer alle testaktiviteter og resultater. Den indeholder også en evaluering af testprocessen og de indhøstede erfaringer.

testudførelse: Processen med at køre en test af den komponent eller det system, der testes, og producerer faktiske resultater.

automatisering af testudførelse: Brug af software, f.eks. optagelses- / afspilningsværktøjer til at kontrollere udførelsen af ​​test, sammenligning af faktiske resultater med forventede resultater, opsætning af testforudsætninger og andre testkontrol- og rapporteringsfunktioner.

testudførelsesfase: Tidsperioden i en softwareudviklings livscyklus, hvor komponenterne i et softwareprodukt udføres, og softwareproduktet evalueres for at afgøre, om kravene er opfyldt eller ej. (IEEE 610)

testudførelsesplan: En ordning til udførelse af testprocedurer. Testprocedurerne er inkluderet i testudførelsesplanen i deres sammenhæng og i den rækkefølge, de skal udføres i.

test udførelse teknik: Metoden, der bruges til at udføre den faktiske testudførelse,enten manuelt eller automatiseret.

testudførelsesværktøj: En type testværktøj, der er i stand til at udføre anden software ved hjælp af et automatiseret test script, f.eks. optagelse / afspilning. (Fewster og Graham)

test sele: Et testmiljø bestående af stubbe og drivere, der er nødvendige for at udføre en test.

test infrastruktur: De organisatoriske artefakter, der er nødvendige for at udføre test, bestående af testmiljøer, testværktøjer, kontormiljø og procedurer.

test element: Det individuelle element, der skal testes. Der er normalt et testobjekt og mange testgenstande. Se også testobjekt.

testniveau: En gruppe testaktiviteter, der er organiseret og ledet sammen. Et testniveau er knyttet til ansvaret i et projekt. Eksempler på testniveauer er komponenttest, integrationstest, systemtest og acceptstest. (Efter TMap)

testlog: En kronologisk oversigt over relevante detaljer om udførelsen af ​​test. (IEEE 829)

testlogning: Processen med at registrere information om test udført i en testlog.

test manager: Den person, der er ansvarlig for at teste og evaluere et testobjekt. Individet, der leder, styrer, administrerer planer og regulerer evalueringen af ​​et testobjekt.

testledelse: Planlægning, estimering, overvågning og kontrol af testaktiviteter, typisk udført af en testleder.

Testmodningsmodel (TMM): En iscenesat ramme med fem niveauer til forbedring af testprocesser, relateret til CMM (Capability Maturity Model), der beskriver nøgleelementerne i en effektiv testproces.

Testprocesforbedring (TPI): En kontinuerlig ramme til forbedring af testprocessen, der beskriver nøgleelementerne i en effektiv testproces, især målrettet mod systemtest og accepttest.

testobjekt: Komponenten eller systemet, der skal testes. Se også testemne.

testmål: En grund eller et formål med at designe og udføre en test.

test orakel: En kilde til at bestemme forventede resultater, der skal sammenlignes med det faktiske resultat af softwaren, der testes. Et orakel kan være det eksisterende system (for et benchmark), en brugervejledning eller en persons specialiserede viden, men bør ikke være koden. (Efter Adrion)

test ydeevne indikator: En måling, generelt højt niveau, der angiver i hvilket omfang en bestemt målværdi eller et kriterium er opfyldt. Ofte relateret til testprocesforbedringsmål, f.eks. Procentdel af mangleregistrering (DDP).

testfase: Et tydeligt sæt testaktiviteter indsamlet i en håndterbar fase af et projekt, f.eks. udførelsesaktiviteterne på et testniveau. (Efter Gerrard)

testplan: Et dokument, der beskriver omfanget, tilgangen, ressourcerne og tidsplanen for tilsigtede testaktiviteter. Den identificerer blandt andet testelementer, de funktioner, der skal testes, testopgaverne, der skal udføre hver opgave, graden af ​​testers uafhængighed, testmiljøet, testdesignteknikkerne og testmålingsteknikkerne, der skal bruges, og begrundelsen for deres valg og eventuelle risici, der kræver beredskabsplanlægning. Det er en oversigt over testplanlægningsprocessen (Efter IEEE 829)

testplanlægning: Aktiviteten med at etablere eller opdatere en testplan.

testpolitik: Et dokument på højt niveau, der beskriver organisationens principper, tilgang og hovedmål med hensyn til testning.

testpunktsanalyse (TPA): En formelbaseret testestimeringsmetode baseret på funktionspunktsanalyse. (TMap)

test procedure: Se specifikation for testprocedure.

test procedure specifikation: Et dokument, der specificerer en sekvens af handlinger til udførelse af en test. Også kendt som test script eller manuelt test script. (Efter IEEE 829)

testproces: Den grundlæggende testproces omfatter planlægning, specifikation, udførelse, registrering og kontrol af færdiggørelse. (BS 7925/2)

test gentagelighed: En attribut for en test, der angiver, om de samme resultater produceres, hver gang testen udføres.

test løb: Udførelse af en test på en bestemt version af testobjektet.

test script: Almindeligt brugt til at henvise til en testprocedurespecifikation, især en automatiseret.

testspecifikation: Et dokument, der består af en specifikation af testdesign, specifikation af testcase og / eller specifikation af testprocedure.

teststrategi: Et dokument på højt niveau, der definerer de testniveauer, der skal udføres, og testningen inden for disse niveauer for et program (et eller flere projekter).

test suite: Et sæt af flere testcases for en komponent eller et system, der testes, hvor posttilstanden for en test ofte bruges som forudsætning for den næste.

testoversigtsrapport: Et dokument, der opsummerer testaktiviteter og resultater. Den indeholder også en evaluering af de tilsvarende testemner i forhold til exitkriterier.(Efter IEEE 829)

testmål: Et sæt exitkriterier.

testværktøj: Et softwareprodukt, der understøtter en eller flere testaktiviteter, såsom planlægning og kontrol, specifikation, opbygning af indledende filer og data, testudførelse og testanalyse. (TMap) Se også CAST.

test type: En gruppe testaktiviteter, der sigter mod at teste en komponent eller et system vedrørende en eller flere indbyrdes forbundne kvalitetsattributter. En testtype er fokuseret på et specifikt testmål, dvs. pålidelighedstest, brugbarhedstest, regressionstest osv., Og kan finde sted på et eller flere testniveauer eller testfaser. (Efter TMap)

testbarhed: Softwareproduktets evne til at muliggøre test af modificeret software. (ISO 9126) Se også vedligeholdelsesevne.

testbarhedsanmeldelse: En detaljeret kontrol af testgrundlaget for at bestemme, om testgrundlaget er på et tilstrækkeligt kvalitetsniveau til at fungere som et inputdokument til testprocessen. (Efter TMap)

testbare krav: I hvilket omfang et krav er angivet i termer, der tillader etablering af testdesign (og derefter testcases) og udførelse af tests for at afgøre, om kravene er opfyldt. (Efter IEEE 610)

tester: En teknisk dygtig professionel, der er involveret i test af en komponent eller et system.

testning: Processen bestående af alle livscyklusaktiviteter, både statiske og dynamiske, der vedrører planlægning, forberedelse og evaluering af softwareprodukter og relaterede arbejdsprodukter for at bestemme, at de opfylder specificerede krav, for at demonstrere, at de er egnede til formålet og for at opdage mangler.

testware: Artefakter produceret under testprocessen, der kræves for at planlægge, designe og udføre tests, såsom dokumentation, scripts, input, forventede resultater, opsætnings- og opklaringsprocedurer, filer, databaser, miljø og enhver yderligere software eller hjælpeprogrammer, der bruges i testning. (Efter Fewster og Graham)

trådtest: En version af komponentintegrationstest, hvor progressiv integration af komponenter følger implementeringen af ​​delmængder af kravene i modsætning til integrationen af ​​komponenter efter niveauer i et hierarki.

sporbarhed: Evnen til at identificere relaterede emner i dokumentation og software, såsomkrav med tilhørende tests. Se også vandret sporbarhed, lodret sporbarhed.

top-down test: En inkrementel tilgang til integrationstest, hvor komponenten øverst i komponenthierarkiet testes først, hvor komponenter på lavere niveau simuleres af stubber. Testede komponenter bruges derefter til at teste komponenter på lavere niveau. Processen gentages, indtil komponenterne på det laveste niveau er testet.

U

forståelighed: Softwareproduktets evne til at sætte brugeren i stand til at forstå, om softwaren er egnet, og hvordan den kan bruges til bestemte opgaver og anvendelsesbetingelser. (ISO 9126) Se også anvendelighed.

uopnåelig kode: Kode, der ikke kan nås, og som derfor er umulig at udføre.

anvendelighed: Softwarens evne til at forstå, lære, bruges og tiltrække for brugeren, når den bruges under specificerede forhold. (ISO 9126)

brugervenlighedstest: Test for at bestemme, i hvilket omfang softwareproduktet forstås, let at lære, let at betjene og attraktivt for brugerne under specificerede forhold. (Efter ISO 9126)

test af brugssager: En sort boks test design teknik, hvor test tilfælde er designet til at udføre bruger scenarier.

brugertest: En test, hvorved virkelige brugere er involveret i at vurdere anvendeligheden af ​​en komponent eller et system.

V

V-model: En ramme til beskrivelse af softwareudviklingens livscyklusaktiviteter fra kravspecifikation til vedligeholdelse. V-modellen illustrerer, hvordan testaktiviteter kan integreres i hver fase af softwareudviklingens livscyklus.

validering: Bekræftelse ved undersøgelse og gennem fremlæggelse af objektive beviser for, at kravene til en bestemt bestemt anvendelse eller anvendelse er opfyldt. (ISO 9000)

variabel: Et lagringselement på en computer, der er tilgængeligt af et softwareprogram ved at henvise til det med et navn.

verifikation: Bekræftelse ved undersøgelse og gennem fremlæggelse af objektive beviser for, at specificerede krav er opfyldt. (ISO 9000)

lodret sporbarhed: Sporing af krav gennem lagene i udviklingsdokumentation til komponenter.

volumen test: Test, hvor systemet udsættes for store datamængder. Se også test af ressourceudnyttelse.

I

går igennem: En trinvis præsentation af forfatteren af ​​et dokument for at samle information og skabe en fælles forståelse af dets indhold. (Freedman og W.einberg, IEEE 1028)

hvid boks test design teknik: Dokumenteret procedure til at udlede og udvælge testsager baseret på en analyse af en komponents eller systems interne struktur.

test af hvid boks: Test baseret på en analyse af komponentens eller systemets interne struktur.

Bredbånd Delphi: En ekspertbaseret testestimeringsteknik, der sigter mod at lave en nøjagtig estimering ved hjælp af teammedlemmernes kollektive visdom.

Kontakt mig hvis du vil tilføje flere definitioner i denne ordliste.

Reference: http://www.istqb.org/downloads/glossary-1.0.pdf

Anbefalet læsning

• Bedste softwaretestværktøjer 2021 (QA Test Automation Tools)
• Software Testning QA Assistant Job
• Software Testing Course: Hvilket Software Testing Institute skal jeg tilmelde mig?
• Valg af softwaretest som din karriere
• Softwaretest Teknisk indhold Writer Freelancer Job
• QA Outsourcing Guide: Software Testing Outsourcing Company
• Nogle interessante spørgsmål om software-test Interview
• Software Testing Course Feedback og anmeldelser