Differenza tra test di collaudo e test funzionale?
Risposte:
Nel mio mondo, usiamo i termini come segue:
test funzionali : questa è un'attività di verifica ; abbiamo costruito un prodotto funzionante correttamente? Il software soddisfa i requisiti aziendali?
Per questo tipo di test abbiamo casi di test che coprono tutti i possibili scenari a cui possiamo pensare, anche se è improbabile che tale scenario esista "nel mondo reale". Quando eseguiamo questo tipo di test, miriamo alla massima copertura del codice. Usiamo qualsiasi ambiente di test che possiamo acquisire in quel momento, non deve essere di livello "produzione", purché sia utilizzabile.
test di accettazione : questa è un'attività di validazione ; abbiamo costruito la cosa giusta? È questo ciò di cui il cliente ha davvero bisogno?
Ciò avviene di solito in collaborazione con il cliente o da un proxy interno del cliente (proprietario del prodotto). Per questo tipo di test utilizziamo casi di test che coprono gli scenari tipici in cui prevediamo di utilizzare il software. Questo test deve essere condotto in un ambiente "simile alla produzione", su hardware identico o simile a quello che verrà utilizzato da un cliente. Questo è quando testiamo i nostri "ilicità":
Affidabilità, disponibilità : convalidato tramite uno stress test.
Scalabilità : convalidato tramite un test di carico.
Usabilità : convalidato tramite un'ispezione e una dimostrazione al cliente. L'interfaccia utente è configurata a loro piacimento? Abbiamo messo il marchio del cliente in tutti i posti giusti? Abbiamo tutti i campi / schermate che ci hanno chiesto?
Sicurezza (aka, protezione, solo per adattarsi) : convalidato tramite dimostrazione. A volte un cliente assumerà un'azienda esterna per eseguire un controllo di sicurezza e / o test di intrusione.
Manutenibilità : convalidato attraverso la dimostrazione di come forniremo aggiornamenti / patch software.
Configurabilità : convalidato attraverso la dimostrazione di come il cliente può modificare il sistema in base alle proprie esigenze.
Questo non è affatto standard e non credo che esista una definizione "standard", come dimostrano le risposte contrastanti qui. La cosa più importante per la tua organizzazione è che definisci questi termini con precisione e ti attieni a questi.
Mi piace la risposta di Patrick Cuff. Quello che mi piace aggiungere è la distinzione tra un livello di test e un tipo di test che è stato per me un rivelatore.
livelli di prova
Il livello di test è facile da spiegare usando il modello V , un esempio: 
ogni livello di test ha il suo livello di sviluppo corrispondente . Ha una caratteristica tipica del tempo, vengono eseguiti in una determinata fase del ciclo di vita dello sviluppo.
- test componente / unità => verifica del progetto dettagliato
- test di integrazione componente / unità => verifica della progettazione globale
- test di sistema => verifica dei requisiti di sistema
- test di integrazione di sistema => verifica dei requisiti di sistema
- testing di accettazione => convalida dei requisiti dell'utente
tipi di test
Un tipo di test è una caratteristica, si concentra su un obiettivo di test specifico. I tipi di test enfatizzano i tuoi aspetti di qualità, noti anche come aspetti tecnici o non funzionali. I tipi di test possono essere eseguiti a qualsiasi livello di test . Mi piace usare come tipi di test le caratteristiche di qualità menzionate nella norma ISO / IEC 25010: 2011.
- test funzionali
- test di affidabilità
- test delle prestazioni
- test di operabilità
- test di sicurezza
- test di compatibilità
- test di manutenibilità
- test di trasferibilità
Per completarlo. C'è anche qualcosa chiamato test di regressione . Questa è una classificazione aggiuntiva accanto al livello di prova e al tipo di prova . Un test di regressione è un test che desideri ripetere perché tocca qualcosa di critico nel tuo prodotto. È in effetti un sottoinsieme di test definiti per ciascun livello di test . Se c'è una piccola correzione di bug nel tuo prodotto, non si ha sempre il tempo di ripetere tutti i test. Il test di regressione è una risposta a questo.
La differenza è tra il test del problema e la soluzione. Il software è una soluzione a un problema, entrambi possono essere testati.
Il test funzionale conferma che il software esegue una funzione entro i limiti di come hai risolto il problema. Questa è una parte integrante dello sviluppo di software, paragonabile ai test che vengono effettuati su prodotti fabbricati in serie prima che lasci la fabbrica. Un test funzionale verifica che il prodotto funzioni effettivamente come tu (lo sviluppatore) pensi che faccia.
I test di accettazione verificano che il prodotto risolva effettivamente il problema per il quale è stato risolto. Ciò può essere fatto meglio dall'utente (cliente), ad esempio eseguendo le sue attività che il software assiste. Se il software supera questo test del mondo reale, viene accettato di sostituire la soluzione precedente. Questo test di accettazione a volte può essere eseguito correttamente solo durante la produzione, specialmente se si dispone di clienti anonimi (ad es. Un sito Web). Pertanto, una nuova funzionalità sarà accettata solo dopo giorni o settimane di utilizzo.
Test funzionali : prova il prodotto, verificando che abbia le qualità che hai progettato o costruito (funzioni, velocità, errori, coerenza, ecc.)
Test di accettazione : testare il prodotto nel suo contesto, ciò richiede (simulazione di) interazione umana, testare ha l'effetto desiderato sui problemi originali.
La risposta è opinione. Ho lavorato in molti progetti ed essendo testmanager e issuemanager e tutti i diversi ruoli e le descrizioni in vari libri differiscono, quindi ecco la mia variazione:
test funzionali: prendi i requisiti di business e testali tutti bene e rigorosamente da un punto di vista funzionale.
test di collaudo: il cliente "pagante" esegue i test che gli piace fare in modo da poter accettare il prodotto consegnato. Dipende dal cliente, ma di solito i test non sono accurati come i test funzionali, soprattutto se si tratta di un progetto interno perché gli stakeholder riesaminano e si fidano dei risultati dei test effettuati nelle fasi di test precedenti.
Come ho già detto, questo è il mio punto di vista ed esperienza. Il test funzionale è sistematico e il test di accettazione è piuttosto il dipartimento aziendale che sta testando la cosa.
Pubblico. I test funzionali hanno lo scopo di assicurare ai membri del team che producono il software che fa quello che si aspettano. Il test di accettazione ha lo scopo di assicurare al consumatore che soddisfa le sue esigenze.
Scopo. Il test funzionale verifica solo la funzionalità di un componente alla volta. Il test di accettazione copre tutti gli aspetti del prodotto che contano abbastanza per il consumatore da testare prima di accettare il software (vale a dire, qualsiasi cosa valga la pena il tempo o il denaro necessario per testarlo per determinarne l'accettabilità).
Il software può superare test funzionali, test di integrazione e test di sistema; fallire i test di accettazione solo quando il cliente scopre che le funzionalità non soddisfano le proprie esigenze. Questo di solito implicherebbe che qualcuno ha rovinato le specifiche. Il software potrebbe anche fallire alcuni test funzionali, ma superare i test di accettazione perché il cliente è disposto a gestire alcuni bug funzionali fintanto che il software fa le cose fondamentali di cui ha bisogno accettabilmente bene (il software beta sarà spesso accettato da un sottoinsieme di utenti prima di esso è completamente funzionale).
Test funzionali: applicazione dei dati di test derivati dai requisiti funzionali specificati indipendentemente dalla struttura del programma finale. Conosciuto anche come test black-box.
Test di accettazione: test formali condotti per determinare se un sistema soddisfa o meno i suoi criteri di accettazione — consente a un utente finale di determinare se accettare o meno il sistema.
A mio avviso, la differenza principale è chi dice se i test hanno esito positivo o negativo.
Un test funzionale verifica che il sistema soddisfi i requisiti predefiniti. Viene eseguito e verificato dalle persone responsabili dello sviluppo del sistema.
Un test di accettazione viene approvato dagli utenti. Idealmente gli utenti diranno ciò che vogliono testare, ma in pratica è probabile che sia il tramonto di un test funzionale poiché gli utenti non investono abbastanza tempo. Tieni presente che questo punto di vista è degli utenti aziendali con cui ho a che fare con altri gruppi di utenti, ad esempio l'aviazione e altri aspetti critici della sicurezza potrebbero non avere questa differenza
... sono test in scatola nera eseguiti su un sistema (ad es. software, molte parti meccaniche fabbricate o lotti di prodotti chimici) prima della sua consegna.
Anche se questo continua dicendo:
È anche noto come test funzionale, test black-box, accettazione del rilascio, test QA, test dell'applicazione, test di affidabilità, test finale, test di convalida o test di accettazione in fabbrica
con un marchio "citazione necessaria".
Test funzionali (che reindirizzano effettivamente ai test di sistema):
condotto su un sistema completo e integrato per valutare la conformità del sistema ai requisiti specificati. I test di sistema rientrano nell'ambito dei test black box e, come tali, non dovrebbero richiedere alcuna conoscenza del design interno del codice o della logica.
Quindi da questa definizione sono praticamente la stessa cosa.
Nella mia esperienza, i test di accettazione sono di solito un sottoinsieme dei test funzionali e sono utilizzati nel processo di approvazione formale da parte del cliente, mentre i test funzionali / di sistema saranno quelli eseguiti dal dipartimento sviluppatore / QA.
La relazione tra i due: il test di accettazione di solito include test funzionali, ma può includere test aggiuntivi. Ad esempio, verificare i requisiti di etichettatura / documentazione.
Il test funzionale si verifica quando il prodotto in esame viene immesso in un ambiente di test in grado di produrre una varietà di stimolazione (nell'ambito del test) ciò che l'ambiente target tipicamente produce o anche oltre, esaminando la risposta del dispositivo in prova.
Per un prodotto fisico (non software) esistono due tipi principali di test di accettazione : test di progettazione e test di fabbricazione. I test di progettazione in genere utilizzano un gran numero di campioni di prodotti che hanno superato i test di produzione. Diversi consumatori possono testare il design in diversi modi.
I test di accettazione vengono indicati come verifica quando il progetto viene testato rispetto alle specifiche del prodotto e i test di accettazione vengono indicati come convalida, quando il prodotto viene inserito nell'ambiente reale del consumatore.
Il test di accettazione è solo un test eseguito dal cliente e include altri tipi di test:
- Test funzionali: "questo pulsante non funziona"
- Test non funzionali: "questa pagina funziona ma è troppo lenta"
Per test funzionali vs test non funzionali (i loro sottotipi) - vedere la mia risposta a questa domanda SO .
Sono la stessa cosa.
Il test di accettazione viene eseguito sul sistema completato nel modo più identico possibile al reale ambiente di produzione / distribuzione prima che il sistema venga distribuito o consegnato.
È possibile eseguire test di accettazione in modo automatizzato o manualmente.