Qual è la differenza tra test e verifica?


15

Ogni libro di testo che ho visto dimostra in gran parte che test e verifica sono due concetti diversi. Eppure nessuno di loro fornisce una chiara (o abbastanza chiara per me, finalmente) distinzione.

Per fornire un po 'di contesto, sono interessato alla verifica dei progetti hardware digitali utilizzando i linguaggi di progettazione hardware (HDL).

Ho visto alcune spiegazioni che ricorrono a una differenza "fisica" o "tangibile": se si tratta di un dispositivo prodotto, allora sta testando. È tutta questa storia? In tal caso, perché la parola "test" compare così spesso durante la verifica (specialmente nella verifica funzionale, parliamo di casi di test, banchi di prova, DUT (dispositivo in prova), test diretti, test casuali, ecc ...)

Risposte:


21

Era un ingegnere di verifica del design ASIC presso Qualcomm. Nel modo più semplice posso spiegarlo:

Test: assicurarsi che un prodotto funzioni, dopo averlo creato (pensa al QA).

Verifica: assicurarsi che un prodotto funzioni PRIMA di averlo creato.

Sono entrambi test, solo che la verifica è più complicata perché devi trovare un modo per testare il prodotto prima che esista e devi essere in grado di assicurarti che funzioni come previsto e di specificare quando effettivamente esce.

Ad esempio, Intel sta progettando il prossimo processore, hanno le specifiche, hanno gli schemi e le simulazioni. Spendono $ 1 miliardo di dollari per passare attraverso la fabbricazione e la produzione. Quindi il chip ritorna e lo provano e scoprono che non funziona. Hanno appena buttato un sacco di soldi fuori dalla finestra.

Lancia la verifica. Gli ingegneri della verifica creano modelli che simulano il comportamento del chip, creano il banco di prova che testerà quei modelli particolari. Ottengono i risultati di questi modelli e poi lo confrontano con i risultati RTL (modello del circuito che scrive in un linguaggio di progettazione hardware). Se corrispondono, le cose sono (di solito) OK.

Esistono diverse metodologie per il processo di verifica, una popolare è la Universal Verification Methodology (UVM) .

C'è molta profondità nel campo e le persone possono passare tutta la loro carriera in esso.

Un'altra informazione casuale: di solito sono necessari 3 ingegneri di verifica per 1 ingegnere progettista. Questo è ciò che dicono tutti nel campo.

EDIT: Molte persone pensano alla verifica come a un ruolo di prova, ma non lo è; è un ruolo di progettazione in sé perché devi comprendere tutte le complessità del tuo IC come fa un designer, e quindi devi sapere come progettare modelli, banchi di prova e tutti i casi di test che copriranno tutte le funzionalità del tuo IC , oltre a cercare di colpire ogni singola riga di codice RTL per tutte le possibili combinazioni di bit. Ricorda che al giorno d'oggi un processore ha miliardi di transistor a causa del processo di fabbricazione che consente sempre più piccoli (ora 14 nm).

Inoltre, in grandi aziende come Intel, AMD, Qualcomm, ecc., I progettisti in realtà non progettano il chip. Di solito l'architetto definirà tutte le specifiche, impaginerà i tipi di pezzi che devono essere uniti per ottenere una funzione particolare con un requisito specifico (velocità, risoluzione, ecc.), E quindi il progettista lo codificherà in RTL. Non è affatto un lavoro facile, non è tanto progettare quanto molti ingegneri che escono da scuola pensano che sia. Quello che tutti vogliono essere è un architetto, ma ci vuole molta educazione ed esperienza per arrivare a quel punto. Molti architetti hanno un dottorato di ricerca e come 15-20 anni di esperienza nel campo come designer. Queste sono persone brillanti (e talvolta pazze) che meritano di fare quello che stanno facendo, e sono bravi a farlo. L'architetto sul primo chip su cui ho lavorato era un po 'imbarazzante e non seguiva davvero alcune norme sociali, ma poteva risolvere qualsiasi cosa tu fossi bloccato riguardo al chip, e a volte lo risolveva nella sua testa e ti diceva a guardare un segnale e saresti come "come diavolo l'ha fatto?". Quindi gli chiedi di spiegare e lui lo fa e ti va ben oltre la testa. In realtà mi ha ispirato a leggere libri di testo anche se mi sono già laureato.


+1 Grazie per l'ultima osservazione, ci aiuta a vedere che il campo è davvero importante (anche se RTL e ingegneria del design sembrano più attraenti per la maggior parte degli ingegneri, penso)
VHDL Addict

Per completezza, ti dispiacerebbe aggiungere cosa sia una testcase?
VHDL Addict,

Ho aggiunto un boccone su ciò che la verifica è in realtà a causa del tuo primo commento sul ruolo di progettazione più attraente; sono entrambi buoni ruoli, dipende solo da quello che ti piace. Per quanto riguarda un caso di test, un SoC come lo Snapdragon potrebbe avere da decine a centinaia di migliaia di casi di test, e con test casuali, in milioni. Per dirla semplicemente: stai applicando una serie di bit di input e questo viene modificato passando attraverso molti moduli, quindi ottieni alcuni bit di output di conseguenza che confronti con i risultati del tuo modello. Qualcosa di semplice come testare un'immagine che appare sul tuo telefono avrebbe ...
PGT

un gran numero di testcase. Supponi di voler mostrare un singolo pixel sul tuo schermo mobile. Ciò che qualcuno al di fuori del campo penserà è applicare 1 bit per il bianco e 0 per il nero. Nel mondo mobile attuale, quel pixel può differire per dimensione, intensità, rotazione, formato del colore (YUV ###, RGB ###, ecc.). E probabilmente stai testando 1 bit all'interno di una serie di bit che vengono applicati insieme all'input. Gli altri bit possono essere 0 perché sono neri o possono essere 1 perché stanno gestendo altre informazioni come la modalità di trasmissione, CLK, abilita / disabilita, inneschi, cose fantasiose come quelle.
PGT

6

Nel mio libro, la verifica sta assicurando che ciò che hai progettato "fa il lavoro", vale a dire che hai una serie di cose che il "dispositivo" deve eseguire e la verifica spunta quelle sulla lista.

Il test, tuttavia, sta assicurando che le cose che il "dispositivo" fa siano fatte bene. Si dispone di una serie di funzioni e si verifica ogni funzione assicurandosi che funzioni correttamente.

In breve, Verifica sta controllando il progetto e Test sta controllando il prodotto.


Penso che sto iniziando a capire ... Potresti fornire alcuni esempi di ciascuno?
VHDL Addict,

Come si adatta a un piano di verifica , che specifica cosa deve essere implementato e anche come sapere che la funzionalità è corretta? Sarebbe di scarsa utilità implementare o spuntare una funzione se non funziona.
VHDL Addict,

@ Majenko - Quindi hai scritto un libro sulla verifica? Vuoi condividere qualche dettaglio in più al riguardo?
Michael Karas,

4

Provenienti da un background di progettazione ASIC (hardware), ci sono tre termini importanti: validazione , verifica e test . Le risposte precedenti in genere parlano di uno o due di questi termini, ma non contrastano chiaramente tutti e tre nel modo in cui vorrei. Ecco come li capisco:

  • Convalida: le specifiche (spesso un modello C) soddisfano le esigenze del mercato o dei clienti
  • Verifica: l'implementazione (RTL, netlist o GDS2) corrisponde alla specifica
  • Test: il dispositivo prodotto corrisponde all'implementazione

Le simulazioni netlist e GDS2 possono dare risultati diversi?
Ciro Santilli 15 改造 中心 法轮功 六四 事件

1
@CiroSantilli 巴拿馬 文件 六四 事件 法轮功, suppongo che tu stia chiedendo del comportamento dei gate rispetto ai transistor. Per le normali tensioni e forme d'onda digitali, direi che daranno gli stessi risultati. Ma potrebbero esserci effetti "analogici" non considerati dalle porte idealizzate, come variazioni di potenza / terra o condivisione della carica del segnale. Se tali effetti sono presenti, il comportamento digitale ideale potrebbe non essere vero.
Winston Smith,

1
@CiroSantilli 新疆 改造 中心 法轮功 六四 事件 Sì, possono dare risultati significativamente diversi. Ci sono stato, ho fatto quell'errore.
Elliot Alderson,

1

Un test è progettato per vedere se una specifica è soddisfatta. La verifica è vedere se il dispositivo soddisfa gli input di progettazione, ovvero tutte le specifiche. Suppongo che ci siano molte più interpretazioni, ma questo è ciò che ho visto nei documenti di orientamento della FIA.


Vedo, ho leggermente modificato il testo (dal test al test ) per rendere più chiaro che entrambi sono processi. Sono d'accordo con te che per i singoli test la parola di prova è appropriato (a volte mi sento come se fossi ribadendo l'ovvio con queste domande terminologia ...) :)
VHDL Addict

1

Facciamo una distinzione tra test di verifica e test di validazione. Supponiamo che tu stia progettando un ventilatore che raffredda alcune apparecchiature. Il test di verifica viene eseguito per assicurarsi che il ventilatore soddisfi tutti i requisiti di progettazione. Quindi potresti testare il flusso d'aria, il ciclo termico, le vibrazioni, ecc.

I test di convalida assicurano che i requisiti di progettazione fossero quelli giusti. Gli input di design che abbiamo avuto per il fan ci hanno dato il fan che volevamo? Ad esempio, ti assicureresti che il ventilatore raffreddi effettivamente l'attrezzatura come previsto.


Ecco come i termini sono compresi dai libri sull'ingegneria del software che ho letto. Convalida = assicurarsi che i requisiti siano corretti (verificarli con il cliente, i regolamenti, ecc.); Verifica = assicurarsi che il prodotto sia corretto (testarlo in base alle specifiche)
Wouter van Ooijen

1

ISO9000 parla di verifica e validazione. Nel contesto della verifica ISO9000 significa testare un prototipo per dimostrare che soddisfa le aspettative funzionali e prestazionali. Convalida significa testare la prima serie di produzione anche soddisfare le aspettative di progettazione. Verifica prima, convalida più tardi è il mio piccolo modo di ricordare l'ordine delle cose.

Numerosi standard software invertono l'ordine di verifica e convalida e questo potrebbe davvero causare confusione, quindi sii consapevole di ciò.

La linea di fondo è ... Perché stai testando qualcosa - è un progetto prototipo - se è così, allora gli standard di qualità tendono a chiamare questa verifica. Se stai testando una corsa di produzione per la prima volta, i ragazzi dell'hardware chiamano questa convalida.

Solo le mie esperienze personali.


0

Dalla lettura di queste risposte, mi rendo conto ora che non esiste una definizione definita di come il "testing" differisca dalla "verifica" nel settore.

Quando lavoriamo con il design HW (design "reale" HW, come roba su PCB, non programmazione VHDL) passiamo attraverso una fase di verifica e convalida e una fase di test di produzione (in realtà semplicemente progettando i test di produzione stessi e consegnandoli al sito di produzione). - Verifica - (1) verificare che il prototipo / articolo prodotto in serie soddisfi i requisiti HW (2) convalidare i requisiti HW rispetto ai requisiti SYS. - Test di produzione - test del fumo e casi di test di verifica semplificati e rapidi adattati per escludere difetti di produzione di massa senza dover passare attraverso l'intero processo di verifica per ciascuna delle 500000 unità prodotte all'anno.

Quindi in quella particolare società multinazionale "testing" si riferisce a test di produzione e nient'altro.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.