software testing terms complete glossary
Al fine di evitare le ambiguità nei diversi termini di test del software, allego un file glossario del test del software Qui.
Tutti i termini di test del software sono inclusi in questo glossario. Se ritieni di conoscere la definizione di qualsiasi termine meglio di quanto menzionato qui, puoi usarlo Modulo di Contatto per inviarmi le definizioni. Durante la revisione li includerò in questo elenco di glossari.
Per conoscere le definizioni di base di test del software e garanzia di qualità questo è il miglior glossario compilato da Erik van Veenendaal . Inoltre per ogni definizione c'è un riferimento di IEEE o ISO menzionato tra parentesi.
PER
criteri di accettazione: I criteri di uscita che un componente o un sistema deve soddisfare per essereaccettato da un utente, cliente o altra entità autorizzata. [IEEE 610]
test di accettazione: Test formali relativi alle esigenze degli utenti, ai requisiti e ai processi aziendali condotti per determinare se un sistema soddisfa o meno i criteri di accettazione e per consentire all'utente, ai clienti o ad altre entità autorizzate di determinare se accettare o meno il sistema. [Dopo IEEE 610]
test di accessibilità: Test per determinare la facilità con cui gli utenti con disabilità possono utilizzare un componente o un sistema. [Gerrard]
precisione: La capacità del prodotto software di fornire i risultati o gli effetti corretti o concordati con il grado di precisione necessario. [ISO 9126] Vedi anche test di funzionalità.
risultato attuale: Il comportamento prodotto / osservato quando un componente o un sistema viene testato.
test ad hoc: Test effettuati in modo informale; non ha luogo alcuna preparazione formale del test, non viene utilizzata alcuna tecnica di progettazione del test riconosciuta, non ci sono aspettative per i risultati e la casualità guida l'attività di esecuzione del test.
c e c ++ differenza
adattabilità: La capacità del prodotto software di essere adattato a diversi ambienti specificati senza applicare azioni o mezzi diversi da quelli previsti a tale scopo per il software considerato. [ISO 9126] Vedi anche test di portabilità.
test agili: Pratica di test per un progetto che utilizza metodologie agili, come la programmazione estrema (XP), trattando lo sviluppo come cliente del test ed enfatizzando il paradigma di progettazione test-first.
test alfa: Test operativi simulati o effettivi da parte di potenziali utenti / clienti o un team di test indipendente presso il sito degli sviluppatori, ma al di fuori dell'organizzazione di sviluppo. Il test alpha viene spesso impiegato come forma di test di accettazione interna.
analizzabilità: La capacità del prodotto software di essere diagnosticati per carenze o cause di guasti nel software, o per identificare le parti da modificare. [ISO 9126] Vedi anche test di manutenibilità.
anomalia: Qualsiasi condizione che si discosti dalle aspettative basate su specifiche dei requisiti, documenti di progettazione, documenti utente, standard, ecc. O dalla percezione o dall'esperienza di qualcuno. È possibile riscontrare anomalie durante, ma non limitatamente a, revisione, test, analisi, compilazione o utilizzo di prodotti software o documentazione applicabile. [IEEE 1044] Vedere anche difetto, deviazione, errore, guasto, guasto, incidente, problema.
attrattiva: La capacità del prodotto software di essere attraente per l'utente. [ISO 9126]
audit: Una valutazione indipendente di prodotti o processi software per accertare la conformità a standard, linee guida, specifiche e / o procedure sulla base di criteri oggettivi, inclusi documenti che specificano:
(1) la forma o il contenuto dei prodotti da produrre
(2) il processo di fabbricazione dei prodotti
(3) come misurare la conformità a standard o linee guida. [IEEE 1028]
audit trail: Un percorso attraverso il quale l'input originale di un processo (ad esempio i dati) può essere ricondotto attraverso il processo, prendendo l'output del processo come punto di partenza. Ciò facilita l'analisi dei difetti e consente di eseguire un audit di processo. [Dopo TMap]
testware automatizzato: Testware utilizzato nei test automatizzati, come gli script degli strumenti.
disponibilità: Il grado in cui un componente o un sistema è operativo e accessibile quando richiesto per l'uso. Spesso espresso in percentuale. [IEEE 610]
B
test back-to-back: Test in cui due o più varianti di un componente o sistema vengono eseguite con gli stessi input, gli output vengono confrontati e analizzati in caso di discrepanze. [IEEE 610]
linea di base: Una specifica o un prodotto software che è stato formalmente rivisto o concordato, che in seguito funge da base per ulteriori sviluppi e che può essere modificato solo attraverso un processo formale di controllo delle modifiche. [Dopo IEEE 610]
blocco base: Una sequenza di una o più istruzioni eseguibili consecutive che non contengono rami.
set di test di base: Una serie di casi di test derivati dalla struttura interna o dalle specifiche per garantire il raggiungimento del 100% di un criterio di copertura specificato.
comportamento: La risposta di un componente o di un sistema a una serie di valori di input e precondizioni.
test di benchmark: (1) Uno standard rispetto al quale è possibile effettuare misurazioni o confronti. (2) Un test utilizzato per confrontare componenti o sistemi tra loro o con uno standard come in (1). [Dopo IEEE 610]
software su misura: Software sviluppato specificamente per un insieme di utenti o clienti. L'opposto è un software standard.
la migliore pratica: Un metodo superiore o una pratica innovativa che contribuisce al miglioramento delle prestazioni di un'organizzazione in un determinato contesto, generalmente riconosciuto come 'migliore' da altre organizzazioni pari.
beta test: Test operativi da parte di utenti / clienti potenziali e / o esistenti presso un sito esterno non altrimenti coinvolto con gli sviluppatori, per determinare se un componente o un sistema soddisfa o meno le esigenze dell'utente / cliente e si adatta ai processi aziendali. Il beta testing viene spesso utilizzato come forma di test di accettazione esterno per acquisire feedback dal mercato.
test big bang: Un tipo di test di integrazione in cui gli elementi software, gli elementi hardware o entrambi vengono combinati contemporaneamente in un componente o in un sistema complessivo, piuttosto che in fasi. [Dopo IEEE 610] Vedi anche test di integrazione.
test della scatola nera: Collaudo, funzionale o non funzionale, senza riferimento alla struttura interna del componente o del sistema.
tecniche di progettazione del test della scatola nera: Procedura documentata per derivare e selezionare i casi di test sulla base di un'analisi delle specifiche, funzionali o non funzionali, di un componente o sistema senza riferimento alla sua struttura interna.
caso di test bloccato: Un test case che non può essere eseguito perché le condizioni preliminari per la sua esecuzione non sono soddisfatte.
test dal basso: Un approccio incrementale al test di integrazione in cui i componenti di livello più basso vengono prima testati e quindi utilizzati per facilitare il test di componenti di livello superiore. Questo processo viene ripetuto finché non viene testato il componente in cima alla gerarchia. Vedi anche test di integrazione.
valore limite: Un valore di input o un valore di output che si trova sul bordo di una partizione di equivalenza o alla distanza incrementale più piccola su entrambi i lati di un bordo, ad esempio il valore minimo o massimo di un intervallo.
analisi del valore limite: Una tecnica di progettazione di test black box in cui i casi di test sono progettati in base a valori limite.
copertura del valore limite: La percentuale di valori limite che sono stati esercitati da una suite di test.
ramo: Un blocco di base che può essere selezionato per l'esecuzione in base a un costrutto di programma in cui sono disponibili uno o più percorsi di programma alternativi, ad es. case, jump, go to, ifthen- else.
copertura delle filiali: La percentuale di rami che sono stati esercitati da una suite di test. La copertura del 100% delle filiali implica sia una copertura del 100% delle decisioni che una copertura delle dichiarazioni del 100%.
test di filiale: Una tecnica di progettazione di test white box in cui i casi di test sono progettati per eseguire rami.
test basati sui processi aziendali: Un approccio al testing in cui i test case sono progettati sulla base di descrizioni e / o conoscenza dei processi aziendali.
C
Modello di maturità delle capacità (CMM): Un framework a cinque livelli che descrive gli elementi chiave di un processo software efficace. Il Capability Maturity Model copre le pratiche per la pianificazione, l'ingegneria e la gestione dello sviluppo e della manutenzione del software. [CMM]
Capability Maturity Model Integration (CMMI): Un framework che descrive gli elementi chiave di un efficace processo di sviluppo e manutenzione del prodotto. Il Capability Maturity Model Integration copre le pratiche per la pianificazione, l'ingegneria e la gestione dello sviluppo e della manutenzione del prodotto. CMMI è il successore designato della CMM. [CMMI]
strumento di acquisizione / riproduzione: Un tipo di strumento di esecuzione del test in cui gli input vengono registrati durante il test manuale al fine di generare script di test automatizzati che possono essere eseguiti in seguito (cioè riprodotti). Questi strumenti vengono spesso utilizzati per supportare i test di regressione automatizzati.
ASTUCCIO: Acronimo di Computer Aided Software Engineering.
CAST: Acronimo di Computer Aided Software Testing. Vedi anche automazione dei test.
grafico causa-effetto: Una rappresentazione grafica di input e / o stimoli (cause) con i loro output associati (effetti), che possono essere utilizzati per progettare casi di test.
grafico causa-effetto: Una tecnica di progettazione di test black box in cui i casi di test sono progettati da grafici causa-effetto. [BS 7925/2]
certificazione: Il processo di conferma che un componente, sistema o persona è conforme ai requisiti specificati, ad es. superando un esame.
mutevolezza: La capacità del prodotto software di consentire l'implementazione di modifiche specifiche. [ISO 9126] Vedi anche manutenibilità.
metodo dell'albero di classificazione: Una tecnica di progettazione di test black box in cui i casi di test, descritti per mezzo di un albero di classificazione, sono progettati per eseguire combinazioni di rappresentanti di domini di input e / o output. [Grochtmann]
copertura del codice: Un metodo di analisi che determina quali parti del software sono state eseguite (coperte) dalla suite di test e quali parti non sono state eseguite, ad es. copertura delle dichiarazioni, copertura delle decisioni o copertura delle condizioni.
coesistenza: La capacità del prodotto software di coesistere con altro software indipendente in un ambiente comune che condivide risorse comuni. [ISO 9126] Vedi test di portabilità.
complessità: Il grado in cui un componente o un sistema ha un design e / o una struttura interna difficile da comprendere, mantenere e verificare. Vedi anche complessità ciclomatica.
conformità: La capacità del prodotto software di aderire a standard, convenzioni o regolamenti in leggi e prescrizioni simili. [ISO 9126]
test di conformità : Il processo di test per determinare la conformità del componente o del sistema.
componente: Un elemento software minimo che può essere testato separatamente.
test di integrazione dei componenti: Test eseguiti per esporre difetti nelle interfacce e interazione tra componenti integrati.
specifica dei componenti: Una descrizione della funzione di un componente in termini di valori di output per valori di input specificati in condizioni specificate e comportamento non funzionale richiesto (ad es. Utilizzo delle risorse).
test dei componenti: Il test dei singoli componenti software. [Dopo IEEE 610]
condizione composta: Due o più condizioni singole unite mediante un operatore logico (AND, OR o XOR), ad es. 'A> B AND C> 1000'.
test di concorrenza: Test per determinare come il verificarsi di due o più attività nello stesso intervallo di tempo, ottenuto sia intercalando le attività sia mediante esecuzione simultanea, viene gestito dal componente o dal sistema. [Dopo IEEE 610]
condizione: Un'espressione logica che può essere valutata come Vero o Falso, ad es. A> B. Vedi anche condizioni di prova.
copertura delle condizioni: La percentuale di risultati della condizione che sono stati esercitati da una suite di test. La copertura delle condizioni al 100% richiede che ogni singola condizione in ogni dichiarazione di decisione sia verificata come vera e falsa.
copertura per la determinazione delle condizioni: La percentuale di tutti i risultati di una singola condizione che influenzano in modo indipendente un risultato decisionale che è stato esercitato da una suite di casi di test. La copertura della determinazione delle condizioni al 100% implica una copertura delle condizioni delle decisioni al 100%.
test di determinazione delle condizioni: Una tecnica di progettazione di test white box in cui i casi di test sono progettati per eseguire risultati di singole condizioni che influenzano in modo indipendente un risultato decisionale.
test delle condizioni: Una tecnica di progettazione di test white box in cui i casi di test sono progettati per eseguire i risultati delle condizioni.
esito della condizione: La valutazione di una condizione su Vero o Falso.
configurazione: La composizione di un componente o sistema come definito dal numero, natura e interconnessioni delle sue parti costituenti.
controllo della configurazione: La funzione per controllare il contenuto delle librerie degli elementi di configurazione, ad es. per la conformità agli standard. [IEEE 610]
controllo della configurazione: Un elemento di gestione della configurazione, che consiste nella valutazione, coordinamento, approvazione o disapprovazione e implementazione delle modifiche agli elementi di configurazione dopo la definizione formale della loro identificazione della configurazione. [IEEE
610]
identificazione della configurazione: Un elemento di gestione della configurazione, consistente nella selezione degli elementi di configurazione di un sistema e nella registrazione delle loro caratteristiche funzionali e fisiche nella documentazione tecnica. [IEEE 610]
elemento di configurazione: Un'aggregazione di hardware, software o entrambi, designata per la gestione della configurazione e trattata come una singola entità nel processo di gestione della configurazione. [IEEE 610]
gestione della configurazione: Una disciplina che applica la direzione e la sorveglianza tecnica e amministrativa per: identificare e documentare le caratteristiche funzionali e fisiche di un elemento di configurazione, controllare le modifiche a tali caratteristiche, registrare e segnalare l'elaborazione delle modifiche e lo stato di implementazione e verificare la conformità ai requisiti specificati. [IEEE 610]
consistenza: Il grado di uniformità, standardizzazione e assenza di contraddizioni tra i documenti o le parti di un componente o sistema. [IEEE 610]
flusso di controllo: Una rappresentazione astratta di tutte le possibili sequenze di eventi (percorsi) nell'esecuzione attraverso un componente o sistema.
test di conversione: Test del software utilizzato per convertire i dati da sistemi esistenti per l'utilizzo in sistemi sostitutivi.
CULLA: Acronimo di software commerciale off-the-shelf.
copertura: Il grado, espresso in percentuale, al quale un determinato elemento di copertura è stato esercitato da una suite di test.
analisi di copertura: Misurazione della copertura raggiunta per un elemento di copertura specificato durante l'esecuzione del test facendo riferimento a criteri predeterminati per determinare se sono necessari test aggiuntivi e, in tal caso, quali casi di test sono necessari.
elemento di copertura: Un'entità o proprietà utilizzata come base per la copertura del test, ad es. partizioni di equivalenza o istruzioni di codice.
strumento di copertura: Uno strumento che fornisce misure oggettive di quali elementi strutturali, ad es. dichiarazioni, i rami sono stati esercitati dalla suite di test.
complessità ciclomatica: Il numero di percorsi indipendenti attraverso un programma. La complessità ciclomatica è definita come: L - N + 2P, dove -L = il numero di bordi / collegamenti in un grafico -N = il numero di nodi in un grafico - P = il numero di parti disconnesse del grafico (ad esempio un grafo chiamante e una subroutine). [Dopo McCabe]
D
definizione dei dati: Un'istruzione eseguibile in cui a una variabile viene assegnato un valore.
test guidato dai dati: Una tecnica di scripting che memorizza l'input del test e i risultati attesi in una tabella o in un foglio di calcolo, in modo che un singolo script di controllo possa eseguire tutti i test nella tabella. Il test basato sui dati viene spesso utilizzato per supportare l'applicazione di strumenti di esecuzione del test come strumenti di acquisizione / riproduzione. [Fewster e Graham] Vedi anche test guidato da parole chiave.
flusso di dati: Una rappresentazione astratta della sequenza e dei possibili cambiamenti dello stato degli oggetti dati, dove lo stato di un oggetto è uno qualsiasi di:creazione, utilizzo o distruzione. [Beizer]
analisi del flusso di dati: Una forma di analisi statica basata sulla definizione e l'utilizzo di variabili.
copertura del flusso di dati: La percentuale di coppie di definizione-uso che sono state esercitate da una suite di casi di test.
test del flusso di dati: Una tecnica di progettazione di test white box in cui i casi di test sono progettati per eseguire la definizione e utilizzare coppie di variabili.
debug: Il processo di ricerca, analisi e rimozione delle cause dei guasti nel software.
strumento di debug: Uno strumento utilizzato dai programmatori per riprodurre i guasti, indagare sullo stato dei programmi e trovare il difetto corrispondente. I debugger consentono ai programmatori di eseguire i programmi passo dopo passo, di interrompere un programma in qualsiasi istruzione di programma e di impostare ed esaminare le variabili del programma.
decisione: Un punto del programma in cui il flusso di controllo ha due o più percorsi alternativi. Un nodo con due o più collegamenti a rami separati.
copertura delle condizioni decisionali: La percentuale di tutti i risultati delle condizioni e dei risultati decisionali che sono stati esercitati da una suite di test. La copertura delle condizioni decisionali al 100% implica sia la copertura delle condizioni del 100% che la copertura delle decisioni del 100%.
test delle condizioni decisionali: Una tecnica di progettazione di test white box in cui i casi di test sono progettati per eseguire i risultati delle condizioni e dei risultati decisionali.
copertura decisionale: La percentuale di risultati decisionali che sono stati esercitati da una suite di test. La copertura del 100% delle decisioni implica sia una copertura del 100% delle filiali che una copertura delle dichiarazioni del 100%.
tabella decisionale: Una tabella che mostra le combinazioni di input e / o stimoli (cause) con i loro output e / o azioni (effetti) associati, che possono essere utilizzati per progettare casi di test.
test della tabella decisionale: Tecniche di progettazione di test a scatola nera in cui i casi di test sono progettati per eseguire le combinazioni di input e / o stimoli (cause) mostrati in una tabella decisionale. [Veenendaal]
test decisionale: Una tecnica di progettazione di test white box in cui i casi di test sono progettati per eseguire i risultati delle decisioni.
risultato della decisione: Il risultato di una decisione (che quindi determina i rami da prendere).
difetto: Un difetto in un componente o sistema che può impedire al componente o al sistema di svolgere la sua funzione richiesta, ad es. una dichiarazione o una definizione dei dati errata Un difetto, se riscontrato durante l'esecuzione, può causare un guasto del componente o del sistema.
densità del difetto: Il numero di difetti identificati in un componente o sistema diviso per la dimensione del componente o del sistema (espresso in termini di misurazione standard, ad esempio righe di codice, numero di classi o punti funzione).
Percentuale di rilevamento dei difetti (DDP): il numero di difetti riscontrati da una fase di test, diviso per il numero riscontrato da quella fase di test e ogni altro mezzo successivo.
rapporto sui difetti: Un documento che riporta qualsiasi difetto in un componente o sistema che può impedire al componente o al sistema di svolgere la funzione richiesta. [Dopo IEEE 829]
gestione dei difetti: Il processo di riconoscimento, indagine, azione e eliminazione dei difetti. Si tratta di registrare i difetti, classificarli e identificare l'impatto. [Dopo IEEE 1044]
mascheramento dei difetti: Un evento in cui un difetto impedisce il rilevamento di un altro. [Dopo IEEE 610]
coppia definizione-uso: L'associazione della definizione di una variabile con l'uso di quella variabile. Gli usi delle variabili includono il calcolo (ad es. Moltiplicazione) o per dirigere l'esecuzione di un percorso (uso 'predicato').
consegnabile: Qualsiasi prodotto (di lavoro) che deve essere consegnato a qualcun altro che sia l'autore del prodotto (di lavoro).
test basati sulla progettazione: Un approccio al test in cui i casi di test sono progettati sulla base dell'architettura e / o della progettazione dettagliata di un componente o sistema (ad es. Test di interfacce tra componenti o sistemi).
controllo da banco: Test di software o specifiche mediante simulazione manuale della sua esecuzione.
test di sviluppo: Test formali o informali condotti durante l'implementazione di un componente o sistema, solitamente nell'ambiente di sviluppo dagli sviluppatori. [Dopo IEEE 610]
test della documentazione: Verificare la qualità della documentazione, ad es. guida per l'utente o guida all'installazione.
dominio: Il set da cui è possibile selezionare valori di input e / o output validi.
conducente: Un componente software o uno strumento di test che sostituisce un componente che si occupa del controllo e / o della chiamata di un componente o sistema. [Dopo TMap]
analisi dinamica: Il processo di valutazione del comportamento, ad es. prestazioni della memoria, utilizzo della CPU, di un sistema o di un componente durante l'esecuzione. [Dopo IEEE 610]
confronto dinamico: Confronto dei risultati effettivi e previsti, eseguito durante l'esecuzione del software, ad esempio da uno strumento di esecuzione del test.
test dinamico: Test che coinvolgono l'esecuzione del software di un componente o sistema.
E
efficienza: La capacità del prodotto software di fornire prestazioni adeguate, in relazione alla quantità di risorse utilizzate in condizioni stabilite. [ISO 9126]
test di efficienza: Il processo di test per determinare l'efficienza di un prodotto software.
test comparativi elementari: Tecniche di progettazione di test black box in cui i casi di test sono progettati per eseguire combinazioni di input utilizzando il concetto di copertura della determinazione delle condizioni. [TMap]
emulatore: Un dispositivo, programma per computer o sistema che accetta gli stessi input e produce gli stessi output di un dato sistema. [IEEE 610] Vedi anche simulatore.
criteri di ingresso: l'insieme di condizioni generiche e specifiche per consentire a un processo di andare avanti con un'attività definita, ad es. fase di prova. Lo scopo dei criteri di ingresso è impedire l'avvio di un'attività che comporterebbe uno sforzo maggiore (sprecato) rispetto allo sforzo necessario per rimuovere i criteri di ingresso non riusciti. [Gilb e Graham]
punto d'entrata: La prima istruzione eseguibile all'interno di un componente.
partizione di equivalenza: Una porzione di un dominio di input o output per il quale si presume che il comportamento di un componente o sistema sia lo stesso, in base alla specifica.
copertura della partizione di equivalenza: La percentuale di partizioni di equivalenza che sono state esercitate da una suite di test.
partizionamento di equivalenza: Una tecnica di progettazione di test black box in cui i casi di test sono progettati per eseguire rappresentanti da partizioni di equivalenza. In linea di principio, i casi di test sono progettati per coprire ogni partizione almeno una volta.
errore: Un'azione umana che produce un risultato errato. [Dopo IEEE 610]
errore nell'indovinare: Una tecnica di progettazione di test in cui l'esperienza del tester viene utilizzata per anticipare quali difetti potrebbero essere presenti nel componente o nel sistema sotto test a seguito di errori commessi e per progettare test specificamente per esporli.
seeding degli errori: Il processo di aggiunta intenzionale di difetti noti a quelli già presenti nel componente o nel sistema allo scopo di monitorare la velocità di rilevamento e rimozione e stimare il numero di difetti rimanenti. [IEEE 610]
tolleranza agli errori: La capacità di un sistema o di un componente di continuare il normale funzionamento nonostante la presenza di input errati. [Dopo IEEE 610].
la gestione delle eccezioni: Comportamento di un componente o sistema in risposta a un input errato, da parte di un utente umano o di un altro componente o sistema, oppure a un guasto interno.
istruzione eseguibile: Un'istruzione che, una volta compilata, viene tradotta in codice oggetto e che verrà eseguita proceduralmente quando il programma è in esecuzione e potrebbe eseguire un'azione sui dati.
esercitato: Si dice che un elemento del programma venga esercitato da un test case quando il valore di input provoca l'esecuzione di quell'elemento, come un'istruzione, una decisione o un altro elemento strutturale.
test esaustivi: Un approccio di test in cui la suite di test comprende tutte le combinazioni di valori di input e precondizioni.
criteri di uscita: L'insieme delle condizioni generiche e specifiche, concordate con gli stakeholder, per consentire il completamento ufficiale di un processo. Lo scopo dei criteri di uscita è impedire che un'attività venga considerata completata quando vi sono ancora parti in sospeso dell'attività che non sono state completate. I criteri di uscita vengono utilizzati dai test per creare report e pianificare quando interrompere i test. [Dopo Gilb e Graham]
punto di uscita: L'ultima istruzione eseguibile all'interno di un componente.
Risultato atteso: Il comportamento previsto dalla specifica, o da un'altra fonte, del componente o del sistema in condizioni specificate.
test esplorativi: Test in cui il tester controlla attivamente la progettazione dei test mentre tali test vengono eseguiti e utilizza le informazioni acquisite durante il test per progettare test nuovi e migliori. [Bach]
F
fallire: Un test si considera fallito se il suo risultato effettivo non corrisponde al risultato atteso.
fallimento: Deviazione effettiva del componente o del sistema dalla consegna, dal servizio o dal risultato previsti. [Dopo Fenton]
Modalità di fallimento: La manifestazione fisica o funzionale di un fallimento. Ad esempio, un sistema in modalità guasto può essere caratterizzato da un funzionamento lento, uscite errate o termine completo dell'esecuzione.
Modalità di guasto e analisi degli effetti (FMEA): Un approccio sistematico all'identificazione del rischio e all'analisi per identificare possibili modalità di guasto e tentare di prevenirne il verificarsi.
tasso di fallimento: Il rapporto tra il numero di guasti di una data categoria e una data unità di misura, ad es. errori per unità di tempo, errori per numero di transazioni, errori per numero di computer eseguiti. [IEEE 610]
tolleranza ai guasti: La capacità del prodotto software di mantenere un livello specifico di prestazioni in caso di errori del software (difetti) o di violazione della sua interfaccia specificata. [ISO 9126] Vedi anche affidabilità.
analisi dell'albero dei guasti: Un metodo utilizzato per analizzare le cause dei guasti (difetti).
percorso fattibile: Un percorso per il quale esiste un insieme di valori di input e precondizioni che ne determinano l'esecuzione.
caratteristica: Un attributo di un componente o sistema specificato o implicito nella documentazione dei requisiti (ad esempio affidabilità, usabilità o vincoli di progettazione). [Dopo IEEE 1008]
macchina a stati finiti: Un modello computazionale costituito da un numero finito di stati e transizioni tra questi stati, possibilmente con azioni di accompagnamento. [IEEE 610]
revisione formale: Una revisione caratterizzata da procedure e requisiti documentati, ad es. ispezione.
base di prova congelata: Un documento base di prova che può essere modificato solo da un processo formale di controllo delle modifiche. Vedi anche baseline.
Function Point Analysis (FPA): Metodo volto a misurare la dimensione della funzionalità di un sistema informativo. La misurazione è indipendente dalla tecnologia. Questa misurazione può essere utilizzata come base per la misurazione della produttività, la stima delle risorse necessarie e il controllo del progetto.
integrazione funzionale: Un approccio di integrazione che combina i componenti oi sistemi allo scopo di far funzionare in anticipo una funzionalità di base. Vedi anche test di integrazione.
requisito funzionale: Un requisito che specifica una funzione che un componente o un sistema deve eseguire. [IEEE 610]
tecnica di progettazione del test funzionale: Procedura documentata per derivare e selezionare i casi di test sulla base di un'analisi della specifica della funzionalità di un componente o sistema senza riferimento alla sua struttura interna. Vedi anche tecnica di progettazione del test della scatola nera.
test funzionale: Test basato su un'analisi delle specifiche della funzionalità di un componente o sistema. Vedi anche test della scatola nera.
funzionalità: La capacità del prodotto software di fornire funzioni che soddisfano le esigenze dichiarate e implicite quando il software viene utilizzato in condizioni specifiche. [ISO 9126]
test di funzionalità: Il processo di test per determinare la funzionalità di un prodotto software.
G
prova della scatola di vetro: Vedi test white box.
H
valutazione euristica: Una tecnica di test di usabilità statica per determinare la conformità di un'interfaccia utente con principi di usabilità riconosciuti (la cosiddetta 'euristica').
caso di test di alto livello: Un test case senza valori concreti (a livello di implementazione) per i dati di input e i risultati attesi.
tracciabilità orizzontale: La tracciabilità dei requisiti per un livello di test attraverso gli strati della documentazione di test (ad es. Piano di test, specifica del progetto di test, specifica del caso di test e specifica della procedura di test).
io
analisi d'impatto: La valutazione delle modifiche ai livelli della documentazione di sviluppo, della documentazione di test e dei componenti, al fine di implementare una determinata modifica ai requisiti specificati.
modello di sviluppo incrementale: Un ciclo di vita di sviluppo in cui un progetto è suddiviso in una serie di incrementi, ognuno dei quali fornisce una parte della funzionalità nei requisiti generali del progetto. I requisiti vengono assegnati in ordine di priorità e forniti in ordine di priorità con l'incremento appropriato. In alcune (ma non tutte) versioni di questo modello del ciclo di vita, ogni sottoprogetto segue un 'mini modello a V' con le proprie fasi di progettazione, codifica e test.
test incrementali: Verifica in cui componenti o sistemi sono integrati e testati uno o alcuni alla volta, fino a quando tutti i componenti o sistemi sono integrati e testati.
incidente: Qualsiasi evento che si verifica durante il test che richiede un'indagine. [Dopo IEEE 1008]
gestione degli incidenti: Il processo di riconoscimento, indagine, azione e eliminazione degli incidenti. Si tratta di registrare gli incidenti, classificarli e identificare l'impatto. [Dopo IEEE 1044]
strumento di gestione degli incidenti: Uno strumento che facilita la registrazione e il monitoraggio dello stato degli incidenti rilevati durante i test. Spesso dispongono di strutture orientate al flusso di lavoro per tracciare e controllare l'allocazione, la correzione e il riesame degli incidenti e fornire servizi di reporting.
verbale di incidente: Un documento che riporta ogni evento che si verifica durante il test che richiede un'indagine. [Dopo IEEE 829]
indipendenza: Separazione delle responsabilità, che incoraggia la realizzazione di test oggettivi. [Dopo DO-178b]
percorso non fattibile: Un percorso che non può essere esercitato da nessun insieme di possibili valori di input.
revisione informale: Una revisione non basata su una procedura formale (documentata).
ingresso: Una variabile (memorizzata all'interno o all'esterno di un componente) che viene letta da un componente.
dominio di input: Il set da cui è possibile selezionare valori di input validi .. Vedere anche dominio.
valore di input: Un'istanza di un input. Vedi anche input.
ispezione: Un tipo di revisione che si basa sull'esame visivo dei documenti per rilevare i difetti, ad es. violazioni degli standard di sviluppo e non conformità alla documentazione di livello superiore. La tecnica di revisione più formale e quindi sempre basata su una procedura documentata. [Dopo IEEE 610, IEEE 1028]
installabilità: La capacità del prodotto software di essere installato in un ambiente specificato [ISO 9126]. Vedi anche portabilità.
test di installabilità: Il processo di verifica dell'installazione di un prodotto software. Vedi anche test di portabilità.
guida d'installazione: Istruzioni fornite su qualsiasi supporto adatto, che guidano l'installatore attraverso il processo di installazione. Questa può essere una guida manuale, una procedura passo passo, una procedura guidata di installazione o qualsiasi altra descrizione di processo simile.
procedura guidata di installazione: Software fornito su qualsiasi supporto adatto, che guida l'installatore attraverso il processo di installazione. Normalmente esegue il processo di installazione, fornisce feedback sui risultati dell'installazione e richiede opzioni.
strumentazione: L'inserimento di codice aggiuntivo nel programma per raccogliere informazioni sul comportamento del programma durante l'esecuzione.
strumenti: Uno strumento software utilizzato per eseguire la strumentazione.
test di assunzione: Un'istanza speciale di un test del fumo per decidere se il componente o il sistema è pronto per test dettagliati e ulteriori. Un test di assunzione viene generalmente eseguito all'inizio della fase di esecuzione del test.
integrazione: Il processo di combinazione di componenti o sistemi in assiemi più grandi.
test d'integrazione: Test eseguiti per esporre difetti nelle interfacce e nelle interazioni tra componenti o sistemi integrati. Vedere anche test di integrazione dei componenti, test di integrazione del sistema.
test dell'interfaccia: Un tipo di test di integrazione che riguarda il test delle interfacce tra componenti o sistemi.
interoperabilità: La capacità del prodotto software di interagire con uno o più componenti o sistemi specificati. [Dopo ISO 9126] Vedi anche funzionalità.
test di interoperabilità: Il processo di test per determinare l'interoperabilità di un prodotto software. Vedi anche test di funzionalità.
test non valido: Test utilizzando valori di input che dovrebbero essere rifiutati dal componente o dal sistema. Vedi anche tolleranza agli errori.
test di isolamento: Test di singoli componenti in isolamento dai componenti circostanti, con componenti circostanti simulati da stub e driver, se necessario.
PER
test guidati da parole chiave: Una tecnica di scripting che utilizza file di dati per contenere non solo dati di test e risultati attesi, ma anche parole chiave correlate all'applicazione in fase di test. Le parole chiave vengono interpretate da speciali script di supporto che vengono chiamati dallo script di controllo per il test. Vedi anche test guidato dai dati.
L
LCSAJ: Una sequenza di codice lineare e un salto, che consiste dei seguenti tre elementi (identificati convenzionalmente dai numeri di riga in un elenco di codice sorgente): l'inizio della sequenza lineare di istruzioni eseguibili, la fine della sequenza lineare e la riga di destinazione a cui controllare il flusso viene trasferito alla fine della sequenza lineare.
Copertura LCSAJ: La percentuale di LCSAJ di un componente che è stata esercitata da una suite di test. La copertura LCSAJ al 100% implica una copertura decisionale del 100%.
Test LCSAJ: Una tecnica di progettazione di test white box in cui i casi di test sono progettati per eseguire LCSAJ.
apprendibilità: La capacità del prodotto software di consentire all'utente di apprendere la sua applicazione. [ISO 9126] Vedi anche usabilità.
test di carico: Un tipo di prova riguardante la misurazione del comportamento di un componente o sistema con un carico crescente, ad es. numero di utenti paralleli e / o numero di transazioni per determinare quale carico può essere gestito dal componente o dal sistema.
caso di test di basso livello: Un test case con valori concreti (a livello di implementazione) per i dati di input e i risultati attesi.
M
Manutenzione: Modifica di un prodotto software dopo la consegna per correggere i difetti, migliorare le prestazioni o altri attributi o adattare il prodotto a un ambiente modificato. [IEEE 1219]
test di manutenzione: Testare le modifiche a un sistema operativo o l'impatto di un ambiente modificato su un sistema operativo.
manutenibilità: La facilità con cui un prodotto software può essere modificato per correggere difetti, modificato per soddisfare nuovi requisiti, modificato per rendere più facile la manutenzione futura o adattato a un ambiente mutato. [ISO 9126]
test di manutenibilità: Il processo di verifica per determinare la manutenibilità di un prodotto software.
controllo di gestione: Una valutazione sistematica del processo di acquisizione, fornitura, sviluppo, funzionamento o manutenzione del software, eseguita da o per conto della direzione che monitora i progressi, determina lo stato dei piani e dei programmi, conferma i requisiti e l'allocazione del sistema erede o valuta l'efficacia degli approcci di gestione per raggiungere l'idoneità allo scopo. [Dopo IEEE 610, IEEE 1028]
scadenza: (1) La capacità di un'organizzazione rispetto all'efficacia e all'efficienza dei suoi processi e pratiche di lavoro. Vedi anche Capability Maturity Model, Test Maturity Model. (2) La capacità del prodotto software di evitare guasti dovuti a difetti del software. [ISO 9126] Vedi anche affidabilità.
misurare: Il numero o la categoria assegnata a un attributo di un'entità effettuando una misurazione [ISO 14598].
misura: Il processo di assegnazione di un numero o di una categoria a un'entità per descrivere un attributo di tale entità. [ISO 14598]
scala di misurazione: Una scala che vincola il tipo di analisi dei dati che può essere eseguita su di essa. [ISO 14598]
perdita di memoria: Un difetto nella logica di allocazione dinamica dell'archivio di un programma che impedisce al programma di recuperare la memoria dopo che ha finito di utilizzarlo, causando infine il fallimento del programma per mancanza di memoria.
metrica: Una scala di misurazione e il metodo utilizzato per la misurazione. [ISO 14598]
pietra miliare: Un punto nel tempo in un progetto in cui i deliverable (intermedi) definiti ei risultati dovrebbero essere pronti.
moderatore: Il leader e la persona principale responsabile di un'ispezione o di un altro processo di revisione.
tenere sotto controllo: Uno strumento software o un dispositivo hardware che viene eseguito contemporaneamente al componente o al sistema sottoposto a test e controlla, registra e / o analizza il comportamento del componente o del sistema. [Dopo IEEE 610]
copertura di condizioni multiple: La percentuale di combinazioni di tutte le singole condizionirisultati all'interno di una dichiarazione che è stata esercitata da una suite di test. 100% multiplola copertura delle condizioni implica una copertura della determinazione delle condizioni del 100%.
test di condizioni multiple: Una tecnica di progettazione di test white box in cui i casi di test sono progettati per eseguire combinazioni di risultati di singole condizioni (all'interno di una dichiarazione).
analisi delle mutazioni: Un metodo per determinare la completezza della suite di test misurando la misura in cui una suite di test può discriminare il programma da lievi varianti (mutanti) del programma.
N
Copertura N-switch: La percentuale di sequenze di transizioni N + 1 che sono state esercitate da una suite di test. [Rancio]
Test N-switch: Una forma di test di transizione di stato in cui i casi di test sono progettati per eseguire tutte le sequenze valide di transizioni N + 1. [Chow] Vedi anche test di transizione di stato.
test negativo: Test volti a dimostrare che un componente o un sistema non funziona. Il test negativo è correlato all'atteggiamento dei tester piuttosto che a uno specifico approccio di test o tecnica di progettazione del test. [Dopo Beizer].
non conformità: Inadempimento di un requisito specificato. [ISO 9000]
requisito non funzionale: Un requisito che non riguarda la funzionalità, ma attributi quali affidabilità, efficienza, usabilità, manutenibilità e portabilità.
test non funzionali: Testare gli attributi di un componente o di un sistema che non sono correlati alla funzionalità, ad es. affidabilità, efficienza, usabilità, manutenibilità e portabilità.
tecniche di progettazione di test non funzionali: Metodi utilizzati per progettare o selezionare i test per i test non funzionali.
O
software disponibile in commercio: Un prodotto software sviluppato per il mercato generale, cioè per un gran numero di clienti, e che viene consegnato a molti clienti in un formato identico.
operabilità: La capacità del prodotto software di consentire all'utente di azionarlo e controllarlo. [ISO 9126] Vedi anche usabilità.
ambiente operativo: Prodotti hardware e software installati presso i siti degli utenti o dei clienti in cui verrà utilizzato il componente o il sistema in prova. Il software può includere sistemi operativi, sistemi di gestione di database e altre applicazioni.
test del profilo operativo: Test statistici utilizzando un modello di operazioni di sistema (attività di breve durata) e la loro probabilità di utilizzo tipico. [Musa]
test operativi: Test condotti per valutare un componente o un sistema nel suo ambiente operativo. [IEEE 610]
produzione: Una variabile (memorizzata all'interno o all'esterno di un componente) che viene scritta da un componente.
dominio di output: Il set da cui è possibile selezionare valori di output validi. Vedi anche dominio.
valore di uscita: Un'istanza di un output. Vedi anche output.
P
programmazione in coppia: Un approccio di sviluppo software in base al quale le righe di codice (produzione e / o test) di un componente vengono scritte da due programmatori seduti allo stesso computer. Ciò significa implicitamente che vengono eseguite revisioni del codice in tempo reale.
test di coppia: Due tester lavorano insieme per trovare i difetti. In genere, condividono un computer e ne scambiano il controllo durante i test.
Passaggio: Un test è considerato superato se il suo risultato effettivo corrisponde al risultato atteso.
criteri di superamento / fallimento: Regole decisionali utilizzate per determinare se un elemento (funzione) o una caratteristica del test ha superato o meno un test. [IEEE 829]
sentiero: Una sequenza di eventi, ad es. istruzioni eseguibili, di un componente o di un sistema da un punto di ingresso a un punto di uscita.
copertura percorso: La percentuale di percorsi che sono stati eseguiti da una suite di test. La copertura del percorso al 100% implica una copertura LCSAJ al 100%.
sensibilizzazione del percorso: Scegliere un insieme di valori di input per forzare l'esecuzione di un determinato percorso.
test del percorso: Una tecnica di progettazione di test white box in cui i casi di test sono progettati per eseguire percorsi.
prestazione: Il grado in cui un sistema o un componente svolge le funzioni designate entro determinati vincoli relativi al tempo di elaborazione e alla velocità di elaborazione. [Dopo IEEE 610] Vedi efficienza.
indicatore di prestazione: Una metrica di alto livello di efficacia e / o efficienza utilizzata per guidare e controllare lo sviluppo progressivo, ad es. Percentuale di rilevamento dei difetti (DDP) per il test. [CMMI]
test delle prestazioni: Il processo di test per determinare le prestazioni di un prodotto software. Vedi test di efficienza.
strumento di test delle prestazioni: Uno strumento per supportare i test delle prestazioni e che di solito ha due funzionalità principali: generazione di carico e misurazione delle transazioni di test. La generazione del carico può simulare più utenti o grandi volumi di dati di input. Durante l'esecuzione, le misurazioni del tempo di risposta vengono prese dalle transazioni selezionate e queste vengono registrate. Gli strumenti di test delle prestazioni normalmente forniscono report basati su log di test e grafici di carico rispetto ai tempi di risposta.
piano di prova di fase: Un piano di test che in genere si rivolge a un livello di test.
portabilità: La facilità con cui il prodotto software può essere trasferito da un ambiente hardware o software a un altro. [ISO 9126]
test di portabilità: Il processo di test per determinare la portabilità di un prodotto software.
postcondizione: Condizioni ambientali e di stato che devono essere soddisfatte dopo l'esecuzione di una prova o di una procedura di prova.
confronto post-esecuzione: Confronto dei risultati effettivi e previsti, eseguito al termine dell'esecuzione del software.
presupposto: Condizioni ambientali e di stato che devono essere soddisfatte prima che il componente o il sistema possa essere eseguito con un test o una procedura di test particolare.
Priorità: Il livello di importanza (aziendale) assegnato a un elemento, ad es. difetto.
test del ciclo di processo: Una tecnica di progettazione di test black box in cui i casi di test sono progettati per eseguire procedure e processi aziendali. [TMap]
processi: Un insieme di attività correlate, che trasformano gli input in output. [ISO 12207]
progetto: Un progetto è un insieme unico di attività coordinate e controllate con date di inizio e fine intraprese un obiettivo conforme a requisiti specifici, inclusi i vincoli di tempo, costi e risorse. [ISO 9000]
piano di test del progetto: Un piano di test che in genere si rivolge a più livelli di test.
pseudo-casuale: Una serie che appare casuale ma in realtà è generata secondo una sequenza prestabilita.
Q
qualità: Il grado in cui un componente, sistema o processo soddisfa requisiti specifici e / o esigenze e aspettative dell'utente / cliente. [Dopo IEEE 610]
garanzia di qualità: Parte della gestione della qualità si è concentrata sulla fiducia che i requisiti di qualità saranno soddisfatti. [ISO 9000]
attributo di qualità: Una caratteristica o caratteristica che influisce sulla qualità di un articolo. [IEEE 610]
gestione della qualità: Attività coordinate per dirigere e controllare un'organizzazione per quanto riguarda la qualità. La direzione e il controllo riguardo alla qualità generalmente includono la definizione della politica e degli obiettivi di qualità, la pianificazione della qualità, il controllo della qualità, la garanzia della qualità e il miglioramento della qualità. [ISO 9000]
R
test casuale: Una tecnica di progettazione di test black box in cui vengono selezionati i casi di test, possibilmente utilizzando un algoritmo di generazione pseudo-casuale, per abbinare un profilo operativo. Questa tecnica può essere utilizzata per testare attributi non funzionali come affidabilità e prestazioni.
recuperabilità: La capacità del prodotto software di ristabilire un livello specifico di prestazioni e recuperare i dati direttamente interessati in caso di guasto. [ISO 9126] Vedi anche affidabilità.
test di recuperabilità: Il processo di verifica per determinare la recuperabilità di un prodotto software. Vedi anche test di affidabilità.
test di regressione: Test di un programma precedentemente testato a seguito di modifiche per garantire che i difetti non siano stati introdotti o scoperti in aree invariate del software, a seguito delle modifiche apportate. Viene eseguito quando il software o il suo ambiente vengono modificati.
nota di rilascio: Un documento che identifica gli elementi di test, la loro configurazione, lo stato corrente e altre informazioni di consegna fornite dallo sviluppo al testing e possibilmente ad altri stakeholder all'inizio di una fase di esecuzione del test. [Dopo IEEE 829]
affidabilità: La capacità del prodotto software di eseguire le funzioni richieste alle condizioni stabilite per un periodo di tempo specificato o per un numero specificato di operazioni. [ISO 9126]
test di affidabilità: Il processo di test per determinare l'affidabilità di un prodotto software.
sostituibilità: La capacità del prodotto software di essere utilizzato al posto di un altro prodotto software specificato per lo stesso scopo nello stesso ambiente. [ISO 9126] Vedi anche portabilità.
Requisiti: Una condizione o capacità necessaria a un utente per risolvere un problema o raggiungere un obiettivo che deve essere soddisfatto o posseduto da un sistema o da un componente del sistema per soddisfare un contratto, standard, specifica o altro documento imposto formalmente. [Dopo IEEE 610]
test basato sui requisiti: Un approccio al test in cui i casi di test sono progettati sulla base di obiettivi di test e condizioni di test derivate dai requisiti, ad es. test che esercitano funzioni specifiche o sondano attributi non funzionali come l'affidabilità o l'usabilità.
strumento di gestione dei requisiti: Uno strumento che supporta la registrazione di requisiti, attributi dei requisiti (ad es. Priorità, responsabile della conoscenza) e annotazioni e facilita la tracciabilità attraverso livelli di requisiti e gestione delle modifiche dei requisiti. Alcuni strumenti di gestione dei requisiti forniscono anche funzionalità per l'analisi statica, come il controllo della coerenza e le violazioni delle regole dei requisiti predefiniti.
fase dei requisiti: Il periodo di tempo nel ciclo di vita del software durante il quale i requisiti per un prodotto software vengono definiti e documentati. [IEEE 610]
utilizzo delle risorse: La capacità del prodotto software di utilizzare quantità e tipi di risorse appropriati, ad esempio la quantità di memoria principale e secondaria utilizzata dal programma e le dimensioni dei file temporanei o di overflow richiesti, quando il software esegue la sua funzione in condizioni stabilite. [Dopo ISO 9126] Vedi anche efficienza.
test di utilizzo delle risorse: Il processo di verifica per determinare l'utilizzo delle risorse di un prodotto software.
risultato: La conseguenza / risultato dell'esecuzione di un test. Include output su schermate, modifiche ai dati, rapporti e messaggi di comunicazione inviati. Vedi anche risultato effettivo, risultato atteso.
criteri di ripresa: Le attività di test che devono essere ripetute alla ripresa del test dopo una sospensione. [Dopo IEEE 829]
nuovo test: Test che esegue casi di test non riusciti l'ultima volta che sono stati eseguiti, al fine di verificare il successo delle azioni correttive.
revisione: Una valutazione dello stato di un prodotto o di un progetto per accertare discrepanze rispetto ai risultati pianificati e per raccomandare miglioramenti. Gli esempi includono revisione della direzione, revisione informale, revisione tecnica, ispezione e procedura dettagliata. [Dopo IEEE 1028]
recensore: La persona coinvolta nella revisione che deve identificare e descrivere le anomalie nel prodotto o nel progetto in esame. I revisori possono essere scelti per rappresentare diversi punti di vista e ruoli nel processo di revisione.
rischio: Un fattore che potrebbe comportare future conseguenze negative; di solito espresso come impatto e probabilità.
analisi del rischio: Il processo di valutazione dei rischi identificati per stimare il loro impatto e la probabilità di accadimento (verosimiglianza).
test basato sul rischio: Test orientati all'esplorazione e alla fornitura di informazioni sui rischi del prodotto. [Dopo Gerrard]
controllo del rischio: Il processo attraverso il quale vengono prese le decisioni e implementate le misure di protezione per ridurre i rischi o mantenerli entro livelli specificati.
identificazione del rischio: Il processo di identificazione dei rischi utilizzando tecniche come il brainstorming, le liste di controllo e la cronologia dei guasti.
gestione del rischio: Applicazione sistematica di procedure e pratiche ai compiti di identificazione, analisi, definizione delle priorità e controllo del rischio.
robustezza: Il grado in cui un componente o un sistema può funzionare correttamente in presenza di input non validi o condizioni ambientali stressanti. [IEEE 610] Vedere anche tolleranza agli errori, tolleranza agli errori.
causa ultima: Un fattore sottostante che ha causato una non conformità e che forse dovrebbe essere eliminato definitivamente attraverso il miglioramento del processo.
S
sicurezza: La capacità del prodotto software di raggiungere livelli accettabili di rischio di danni a persone, aziende, software, proprietà o ambiente in uno specifico contesto di utilizzo. [ISO 9126]
test di sicurezza: Il processo di test per determinare la sicurezza di un prodotto software.
scalabilità: La capacità del prodotto software di essere aggiornato per accogliere carichi maggiori. [Dopo Gerrard]
test di scalabilità: Test per determinare la scalabilità del prodotto software.
scriba: La persona che deve registrare ogni difetto menzionato e qualsiasi suggerimento per il miglioramento durante una riunione di revisione, su un modulo di registrazione. Lo scriba deve assicurarsi che il modulo di registrazione sia leggibile e comprensibile.
linguaggio di scripting: Un linguaggio di programmazione in cui vengono scritti script di test eseguibili, utilizzato da uno strumento di esecuzione del test (ad esempio uno strumento di acquisizione / riproduzione).
sicurezza: Attributi dei prodotti software che influiscono sulla sua capacità di impedire l'accesso non autorizzato, accidentale o intenzionale, a programmi e dati. [ISO 9126]
test di sicurezza: Test per determinare la sicurezza del prodotto software.
gravità: Il grado di impatto che un difetto ha sullo sviluppo o sul funzionamento di un componente o sistema. [Dopo IEEE 610]
simulazione: La rappresentazione di caratteristiche comportamentali selezionate di un sistema fisico o astratto da parte di un altro sistema. [ISO 2382/1]
simulatore: Un dispositivo, programma per computer o sistema utilizzato durante il test, che si comporta o funziona come un dato sistema quando dotato di una serie di input controllati. [Dopo IEEE 610, DO178b] Vedi anche emulatore.
test del fumo: Un sottoinsieme di tutti i casi di test definiti / pianificati che coprono la funzionalità principale di un componente o sistema, per accertare che le funzioni più cruciali di un programma funzionino, ma senza preoccuparsi di dettagli più fini. Un test quotidiano di build e fumo è tra le migliori pratiche del settore. Vedi anche test di assunzione.
qualità del software: La totalità delle funzionalità e delle caratteristiche di un prodotto software che dipendono dalla sua capacità di soddisfare esigenze dichiarate o implicite. [Dopo ISO 9126]
specifica: Un documento che specifica, idealmente in modo completo, preciso e verificabile, i requisiti, il design, il comportamento o altre caratteristiche di un componente o sistema e, spesso, le procedure per determinare se queste disposizioni sono state soddisfatte. [Dopo IEEE 610]
tecnica di progettazione del test basata sulle specifiche: Vedere la tecnica di progettazione del test della scatola nera.
input specificato: Un input per il quale la specifica prevede un risultato.
stabilità: La capacità del prodotto software di evitare effetti imprevisti da modifiche al software. [ISO 9126] Vedi anche manutenibilità.
diagramma di stato: Un diagramma che illustra gli stati che un componente o un sistema può assumere e mostra gli eventi o le circostanze che causano e / o risultano da un cambiamento da uno stato all'altro. [IEEE 610]
tabella di stato: Una griglia che mostra le transizioni risultanti per ogni stato combinate con ogni possibile evento, mostrando transizioni valide e non valide.
transizione di stato: Una transizione tra due stati di un componente o di un sistema.
miglior programma per monitorare la temperatura della gpu
test di transizione di stato: Una tecnica di progettazione di test black box in cui i casi di test sono progettati per eseguire transizioni di stato valide e non valide. Vedi anche Test N-switch.
dichiarazione: Un'entità in un linguaggio di programmazione, che in genere è la più piccola unità di esecuzione indivisibile.
copertura delle dichiarazioni: La percentuale di istruzioni eseguibili che sono state esercitate da una suite di test.
test delle dichiarazioni: Una tecnica di progettazione di test white box in cui i casi di test sono progettati per eseguire istruzioni.
analisi statica: Analisi di artefatti software, ad es. requisiti o codice, eseguito senza l'esecuzione di questi artefatti software.
analizzatore statico: Uno strumento che esegue analisi statiche.
analisi statica del codice: Analisi del codice sorgente del programma eseguita senza l'esecuzione di tale software.
analizzatore di codice statico: Uno strumento che esegue l'analisi statica del codice. Lo strumento controlla il codice sorgente, per determinate proprietà come la conformità agli standard di codifica, metriche di qualità o anomalie del flusso di dati.
test statico: Test di un componente o sistema a livello di specifica o implementazione senza l'esecuzione di tale software, ad es. revisioni o analisi statica del codice.
test statistici: Una tecnica di progettazione di test in cui un modello della distribuzione statistica dell'input viene utilizzato per costruire casi di test rappresentativi. Vedi anche test del profilo operativo.
stato contabile: Un elemento di gestione della configurazione, costituito dalla registrazione e dalla segnalazione delle informazioni necessarie per gestire efficacemente una configurazione. Queste informazioni includono un elenco dell'identificazione della configurazione approvata, lo stato delle modifiche proposte alla configurazione e lo stato di implementazione delle modifiche approvate. [IEEE 610]
Test di stress: Test condotti per valutare un sistema o un componente in corrispondenza o oltre i limiti dei requisiti specificati. [IEEE 610]
copertura strutturale: Misure di copertura basate sulla struttura interna del componente.
tecnica di progettazione del test strutturale: Vedere la tecnica di progettazione del test white box.
stub: Un'implementazione scheletrica o per scopi speciali di un componente software, utilizzata per sviluppare o testare un componente che chiama o è altrimenti dipendente da esso. Sostituisce un componente chiamato. [Dopo IEEE 610]
sottopercorso: Una sequenza di istruzioni eseguibili all'interno di un componente.
criteri di sospensione: I criteri utilizzati per interrompere (temporaneamente) tutte o una parte delle attività di test sugli elementi di test. [Dopo IEEE 829]
adeguatezza: La capacità del prodotto software di fornire un insieme appropriato di funzioni per attività e obiettivi utente specifici. [ISO 9126] Vedi anche funzionalità.
Inventario della misurazione dell'usabilità del software (SUMI): Una tecnica di test di usabilità basata su questionario per valutare l'usabilità, ad es. soddisfazione dell'utente, di un componente o di un sistema. [Veenendaal]
test di sintassi: Una tecnica di progettazione di test black box in cui i casi di test sono progettati in base alla definizione del dominio di input e / o del dominio di output.
sistema: Una raccolta di componenti organizzata per eseguire una funzione specifica o un insieme di funzioni. [IEEE 610]
test di integrazione del sistema: Testare l'integrazione di sistemi e pacchetti; testare le interfacce con organizzazioni esterne (ad es. scambio elettronico di dati, Internet).
test di sistema: Il processo di test di un sistema integrato per verificare che soddisfi i requisiti specificati. [Hetzel]
T
revisione tecnica: Un'attività di discussione di gruppo tra pari che si concentra sul raggiungimento del consenso sull'approccio tecnico da adottare. Una revisione tecnica è anche nota come revisione tra pari. [Gilb and Graham, IEEE 1028]
approccio di prova: L'implementazione della strategia di test per un progetto specifico. In genere include le decisioni prese che seguono in base all'obiettivo del progetto (di test) e alla valutazione del rischio eseguita, i punti di partenza riguardanti il processo di test, le tecniche di progettazione del test da applicare, i criteri di uscita e i tipi di test da eseguire.
automazione del test: L'uso di software per eseguire o supportare attività di test, ad es. gestione dei test, progettazione dei test, esecuzione dei test e controllo dei risultati.
base di prova: Tutti i documenti da cui è possibile dedurre i requisiti di un componente o di un sistema. La documentazione su cui si basano i casi di test. Se un documento può essere modificato solo tramite una procedura di modifica formale, la base di prova viene chiamata base di prova congelata. [Dopo TMap]
caso di test: Un insieme di valori di input, precondizioni di esecuzione, risultati attesi e postcondizioni di esecuzione, sviluppati per un particolare obiettivo o condizione di test, ad esempio per esercitare un particolare percorso di programma o per verificare la conformità a un requisito specifico. [Dopo IEEE 610]
specifica del caso di test: Un documento che specifica una serie di casi di test (obiettivo, input, azioni di test, risultati attesi e precondizioni di esecuzione) per un elemento di test. [Dopo IEEE 829]
carta di prova: Una dichiarazione degli obiettivi del test e possibilmente delle idee di test. Le carte di prova sono tra le altre utilizzate nei test esplorativi. Vedi anche test esplorativi.
comparatore di prova: Uno strumento di test per eseguire il confronto automatico dei test.
confronto di prova: Il processo di identificazione delle differenze tra i risultati effettivi prodotti dal componente o dal sistema sotto test e i risultati attesi per un test. Il confronto dei test può essere eseguito durante l'esecuzione del test (confronto dinamico) o dopo l'esecuzione del test.
condizione di test: Un elemento o un evento di un componente o sistema che potrebbe essere verificato da uno o più casi di test, ad es. una funzione, transazione, attributo di qualità o elemento strutturale.
dati di test: Dati che esistono (ad esempio, in un database) prima dell'esecuzione di un test e che influiscono o sono influenzati dal componente o sistema sottoposto a test.
strumento di preparazione dei dati di prova: Un tipo di strumento di test che consente di selezionare i dati da database esistenti o di crearli, generarli, manipolarli e modificarli per l'uso nei test.
specifica di progettazione del test: Un documento che specifica le condizioni di test (elementi di copertura) per un elemento di test, l'approccio di test dettagliato e che identifica i casi di test di alto livello associati. [Dopo IEEE 829]
strumento di progettazione del test: Uno strumento che supporta l'attività di progettazione di test generando input di test da una specifica che può essere conservata in un repository di strumenti CASE, ad es. strumento di gestione dei requisiti, o da specifiche condizioni di test contenute nello strumento stesso.
tecnica di progettazione del test: Un metodo utilizzato per derivare o selezionare casi di test.
ambiente di test: Un ambiente contenente hardware, strumentazione, simulatori, strumenti software e altri elementi di supporto necessari per condurre un test. [Dopo IEEE 610]
rapporto di valutazione del test: Un documento prodotto alla fine del processo di test che riassume tutte le attività ei risultati del test. Contiene anche una valutazione del processo di test e delle lezioni apprese.
esecuzione del test: Il processo di esecuzione di un test da parte del componente o del sistema sottoposto a test, che produce risultati effettivi.
automazione dell'esecuzione dei test: L'uso del software, ad es. strumenti di acquisizione / riproduzione, per controllare l'esecuzione dei test, il confronto dei risultati effettivi con i risultati attesi, l'impostazione delle condizioni preliminari dei test e altre funzioni di controllo e reporting dei test.
fase di esecuzione del test: Il periodo di tempo in un ciclo di vita di sviluppo software durante il quale vengono eseguiti i componenti di un prodotto software e il prodotto software viene valutato per determinare se i requisiti sono stati soddisfatti o meno. [IEEE 610]
programma di esecuzione del test: Uno schema per l'esecuzione di procedure di test. Le procedure di test sono incluse nel programma di esecuzione del test nel loro contesto e nell'ordine in cui devono essere eseguite.
tecnica di esecuzione del test: Il metodo utilizzato per eseguire l'effettiva esecuzione del test,sia manualmente che automatizzato.
strumento di esecuzione del test: Un tipo di strumento di test in grado di eseguire altro software utilizzando uno script di test automatizzato, ad es. cattura / riproduzione. [Fewster e Graham]
collaudare l'imbragatura: Un ambiente di test composto da stub e driver necessari per condurre un test.
infrastruttura di test: Gli artefatti organizzativi necessari per eseguire i test, costituiti da ambienti di test, strumenti di test, ambiente di ufficio e procedure.
elemento di prova: Il singolo elemento da testare. Di solito c'è un oggetto di prova e molti elementi di prova. Vedi anche oggetto di prova.
livello di prova: Un gruppo di attività di test che vengono organizzate e gestite insieme. Un livello di test è collegato alle responsabilità in un progetto. Esempi di livelli di test sono il test dei componenti, il test di integrazione, il test di sistema e il test di accettazione. [Dopo TMap]
registro dei test: Una registrazione cronologica dei dettagli rilevanti sull'esecuzione dei test. [IEEE 829]
registrazione di prova: Il processo di registrazione delle informazioni sui test eseguiti in un registro dei test.
responsabile del test: La persona responsabile del test e della valutazione di un oggetto di prova. L'individuo, che dirige, controlla, amministra i piani e regola la valutazione di un oggetto di prova.
gestione dei test: La pianificazione, stima, monitoraggio e controllo delle attività di test, tipicamente svolte da un responsabile del test.
Test Maturity Model (TMM): Un framework a cinque livelli per il miglioramento del processo di test, correlato al Capability Maturity Model (CMM) che descrive gli elementi chiave di un processo di test efficace.
Miglioramento del processo di test (TPI): Un framework continuo per il miglioramento del processo di test che descrive gli elementi chiave di un processo di test efficace, mirato in particolare al test del sistema e al test di accettazione.
oggetto di prova: Il componente o il sistema da testare. Vedi anche elemento di prova.
obiettivo del test: Un motivo o uno scopo per progettare ed eseguire un test.
prova oracolo: Una fonte per determinare i risultati attesi da confrontare con il risultato effettivo del software sottoposto a test. Un oracolo può essere il sistema esistente (per un benchmark), un manuale utente o la conoscenza specializzata di un individuo, ma non dovrebbe essere il codice. [Dopo Adrion]
indicatore di performance del test: Una metrica, in generale di alto livello, che indica in che misura è soddisfatto un determinato valore o criterio obiettivo. Spesso correlato agli obiettivi di miglioramento del processo di test, ad es. Percentuale di rilevamento dei difetti (DDP).
fase di prova: Un insieme distinto di attività di test raccolte in una fase gestibile di un progetto, ad es. le attività di esecuzione di un livello di test. [Dopo Gerrard]
piano di prova: Un documento che descrive l'ambito, l'approccio, le risorse e il programma delle attività di test previste. Identifica tra gli altri elementi di test, le caratteristiche da testare, le attività di test, chi eseguirà ciascuna attività, il grado di indipendenza del tester, l'ambiente di test, le tecniche di progettazione del test e le tecniche di misurazione del test da utilizzare e la motivazione per la loro scelta e tutti i rischi che richiedono una pianificazione di emergenza. È una registrazione del processo di pianificazione del test [After IEEE 829]
pianificazione del test: L'attività di definizione o aggiornamento di un piano di test.
politica di test: Un documento di alto livello che descrive i principi, l'approccio e gli obiettivi principali dell'organizzazione in materia di test.
analisi del punto di prova (TPA): Un metodo di stima del test basato su formula basato sull'analisi dei punti di funzione. [TMap]
Procedura di prova: Vedere le specifiche della procedura di test.
specifica della procedura di prova: Un documento che specifica una sequenza di azioni per l'esecuzione di un test. Noto anche come script di test o script di test manuale. [Dopo IEEE 829]
processo di prova: Il processo di test fondamentale comprende pianificazione, specifica, esecuzione, registrazione e controllo per il completamento. [BS 7925/2]
ripetibilità del test: Un attributo di un test che indica se gli stessi risultati vengono prodotti ogni volta che viene eseguito il test.
prova: Esecuzione di un test su una versione specifica dell'oggetto di test.
script di test: Comunemente usato per fare riferimento a una specifica di procedura di test, specialmente a una automatizzata.
specifica di prova: Un documento che consiste in una specifica del progetto di test, una specifica del caso di test e / o una specifica della procedura di test.
strategia di test: Un documento di alto livello che definisce i livelli di test da eseguire e il test all'interno di tali livelli per un programma (uno o più progetti).
suite di test: Un insieme di diversi casi di test per un componente o un sistema sottoposto a test, in cui la condizione post-test di un test viene spesso utilizzata come precondizione per il successivo.
rapporto di sintesi del test: Un documento che riassume le attività ei risultati dei test. Contiene anche una valutazione degli elementi di test corrispondenti rispetto ai criteri di uscita.[Dopo IEEE 829]
obiettivo del test: Una serie di criteri di uscita.
strumento di prova: Un prodotto software che supporta una o più attività di test, come pianificazione e controllo, specifiche, creazione di file e dati iniziali, esecuzione di test e analisi di test. [TMap] Vedi anche CAST.
tipo di test: Un gruppo di attività di test volte a testare un componente o un sistema per quanto riguarda uno o più attributi di qualità correlati. Un tipo di test è focalizzato su uno specifico obiettivo di test, cioè test di affidabilità, test di usabilità, test di regressione ecc., E può svolgersi su uno o più livelli di test o fasi di test. [Dopo TMap]
testabilità: La capacità del prodotto software di consentire il test del software modificato. [ISO 9126] Vedi anche manutenibilità.
revisione della testabilità: Un controllo dettagliato della base del test per determinare se la base del test è a un livello di qualità adeguato per fungere da documento di input per il processo di test. [Dopo TMap]
requisiti verificabili: Il grado in cui un requisito è stabilito in termini che consentono di stabilire progetti di test (e successivamente casi di test) e l'esecuzione di test per determinare se i requisiti sono stati soddisfatti. [Dopo IEEE 610]
tester: Un professionista tecnicamente qualificato che è coinvolto nel collaudo di un componente o sistema.
test: Il processo costituito da tutte le attività del ciclo di vita, sia statiche che dinamiche, relative alla pianificazione, preparazione e valutazione dei prodotti software e dei prodotti di lavoro correlati per determinare che soddisfano requisiti specifici, per dimostrare che sono adatti allo scopo e per rilevare i difetti.
testware: Artefatti prodotti durante il processo di test richiesto per pianificare, progettare ed eseguire test, come documentazione, script, input, risultati attesi, procedure di configurazione e cancellazione, file, database, ambiente e qualsiasi software o utilità aggiuntivo utilizzato in test. [Dopo Fewster e Graham]
test del filo: Una versione di test di integrazione dei componenti in cui la progressiva integrazione dei componenti segue l'implementazione di sottoinsiemi dei requisiti, in contrapposizione all'integrazione dei componenti per livelli di una gerarchia.
tracciabilità: La capacità di identificare gli elementi correlati nella documentazione e nel software, comerequisiti con test associati. Vedi anche tracciabilità orizzontale, tracciabilità verticale.
test top-down: Un approccio incrementale al test di integrazione in cui il componente nella parte superiore della gerarchia dei componenti viene testato per primo, con i componenti di livello inferiore simulati dagli stub. I componenti testati vengono quindi utilizzati per testare i componenti di livello inferiore. Il processo viene ripetuto fino a quando non sono stati testati i componenti di livello più basso.
U
comprensibilità: La capacità del prodotto software di consentire all'utente di capire se il software è adatto e come può essere utilizzato per particolari attività e condizioni d'uso. [ISO 9126] Vedi anche usabilità.
codice irraggiungibile: Codice non raggiungibile e quindi impossibile da eseguire.
usabilità: La capacità del software di essere compreso, appreso, utilizzato e attrattivo per l'utente quando utilizzato in condizioni specifiche. [ISO 9126]
test di usabilità: Test per determinare la misura in cui il prodotto software è compreso, facile da apprendere, facile da usare e attraente per gli utenti in condizioni specificate. [Dopo ISO 9126]
test dei casi d'uso: Una tecnica di progettazione di test black box in cui i casi di test sono progettati per eseguire scenari utente.
test utente: Un test in cui gli utenti della vita reale sono coinvolti per valutare l'usabilità di un componente o sistema.
V
Modello V: Un framework per descrivere le attività del ciclo di vita dello sviluppo del software dalla specifica dei requisiti alla manutenzione. Il modello V illustra come le attività di test possono essere integrate in ogni fase del ciclo di vita dello sviluppo del software.
validazione: Conferma mediante esame e fornitura di prove oggettive che i requisiti per uno specifico uso o applicazione previsti sono stati soddisfatti. [ISO 9000]
variabile: Un elemento di archiviazione in un computer accessibile da un programma software facendo riferimento ad esso con un nome.
verifica: Conferma mediante esame e fornitura di prove oggettive che i requisiti specificati sono stati soddisfatti. [ISO 9000]
tracciabilità verticale: La tracciabilità dei requisiti attraverso i livelli della documentazione di sviluppo fino ai componenti.
test di volume: Verifica in cui il sistema è sottoposto a grandi volumi di dati. Vedi anche test sull'utilizzo delle risorse.
NEL
Procedura dettagliata: Una presentazione passo passo da parte dell'autore di un documento al fine di raccogliere informazioni e stabilire una comprensione comune del suo contenuto. [Freedman e Weinberg, IEEE 1028]
tecnica di progettazione del test della scatola bianca: Procedura documentata per derivare e selezionare casi di test sulla base di un'analisi della struttura interna di un componente o sistema.
test della scatola bianca: Test basati su un'analisi della struttura interna del componente o del sistema.
Delphi a banda larga: Una tecnica di stima del test basata su esperti che mira a fare una stima accurata utilizzando la saggezza collettiva dei membri del team.
Contattami se vuoi aggiungere più definizioni in questo glossario.
Riferimento: http://www.istqb.org/downloads/glossary-1.0.pdf
Lettura consigliata
- Migliori strumenti di test del software 2021 [Strumenti di automazione del test QA]
- Lavoro assistente QA test software
- Corso di test del software: quale istituto di test del software dovrei iscrivermi?
- Scegliere il test del software come carriera
- Lavoro freelance di scrittore di contenuti tecnici di test del software
- QA Outsourcing Guide: Software Testing Outsourcing Companies
- Alcune interessanti domande di intervista sul test del software
- Feedback e recensioni sul corso di test del software