I test di regressione sono l'intera suite di test o un campione di test?

Question

Mi è stato insegnato che un test di regressione era un piccolo esempio (solo per dimostrare che non hai rotto nulla con l'introduzione di una modifica o di nuovi moduli) dei test generali. Tuttavia, questo articolo di Ron Morrison e Grady Booch mi fa pensare diversamente:

  

La strategia desiderata sarebbe quella di riunire ciascuna unità una alla volta, eseguire un ampio test di regressione, correggere eventuali difetti e quindi passare all'unità successiva.

Lo stesso documento dice anche:

  

Non appena viene aggiunto un numero limitato di unità, viene generata una versione di prova e "testato contro il fumo", in cui viene eseguito un numero limitato di test per ottenere la sicurezza che il prodotto integrato funzionerà come previsto. L'intento non è né testare a fondo le nuove unità né testare completamente la regressione dell'intero sistema.

Nel descrivere il test del fumo, gli autori dicono questo:

  

È anche importante che il test del fumo esegua un rapido controllo dell'intero sistema, non solo dei nuovi componenti.

Non ho mai visto " esteso " e "test di regressione" usato insieme né un test di regressione descritto come "test di regressione completo dell'intero sistema". I test di regressione dovrebbero essere il più leggeri e rapidi possibili. E la definizione di test del fumo è ciò che ho imparato che era un test di regressione.

Ho frainteso ciò che mi è stato insegnato? Mi è stato insegnato in modo errato? Oppure ci sono più interpretazioni di "test di regressione"?

Answer 1

Esistono più interpretazioni. Se stai risolvendo solo un bug che interessa una piccola parte del tuo sistema, i test di regressione potrebbero includere solo una piccola serie di test che esercitano la classe o il pacchetto in questione. Se stai risolvendo un bug o aggiungendo una funzionalità che ha un ambito più ampio, anche i tuoi test di regressione dovrebbero avere un ambito più ampio.

Il " se potrebbe rompersi, testalo " la regola empirica si applica qui. Se una modifica in Foo potrebbe influire su Bar , eseguire le regressioni per entrambi.

I test di regressione controllano semplicemente se una modifica ha causato il fallimento di un test precedentemente superato. Possono essere eseguiti a qualsiasi livello (unità, integrazione, sistema). Riferimento .

Answer 2

Ho sempre preso i test di regressione per indicare qualsiasi test il cui scopo era garantire che la funzionalità esistente non venisse interrotta da nuove modifiche. Ciò non implicherebbe alcun vincolo per le dimensioni della suite di test.

Answer 3

La regressione viene generalmente utilizzata per fare riferimento all'intera suite di test. È l'ultima cosa che fa il QA prima di un rilascio. Viene usato per mostrare che tutto ciò che era solito funzionare funziona ancora, nella misura in cui ciò è possibile mostrare. In base alla mia esperienza, si tratta generalmente di una serie di test a livello di sistema, indipendentemente da quanto piccola fosse la modifica (sebbene piccole modifiche non possano innescare un test di regressione).

Answer 4

Dove lavoro, i test di regressione sono standardizzati per ogni applicazione alla fine di ogni versione. Sono destinati a testare tutte le funzionalità, ma non sono progettati per rilevare bug sottili. Pertanto, se si dispone di un modulo su cui sono stati eseguiti vari tipi di convalida, ad esempio, una suite di regressione per quel modulo sarebbe quella di confermare che ciascun tipo di convalida viene eseguito (livello di campo e livello di modulo) e che è possibile inviare informazioni corrette . Non è progettato per coprire ogni singolo caso (ovvero se lascio il campo A vuoto? Che ne dici del campo B? Ne testerà solo uno e supporrà che gli altri funzionino).

Tuttavia, sull'attuale progetto a cui sto lavorando, i test di regressione sono molto più approfonditi e abbiamo notato una riduzione del numero di difetti sollevati durante i test. Questi due non sono necessariamente correlati, ma lo notiamo in modo abbastanza coerente.

Answer 5

la mia comprensione del termine "test di regressione" è:

• i test unitari vengono scritti per testare le funzioni quando viene creato il sistema
• quando vengono rilevati dei bug, vengono scritti più test unitari per riprodurre il bug e verificare che sia stato corretto
• un test di regressione esegue l'intero set di test per dimostrare che tutto funziona ancora, incluso che non sono riapparsi vecchi bug [ad es. per dimostrare che il codice non è stato "regredito"]

in pratica, è consigliabile eseguire sempre tutti i test unitari esistenti quando vengono apportate modifiche. l'unica volta che mi preoccuperei di un sottoinsieme di test è quando l'intera suite di test dell'unità impiega "troppo tempo" per eseguire [dove " troppo lungo " è abbastanza soggettivo]

Answer 6

Inizia con ciò che stai cercando di realizzare. Quindi fai quello che devi fare per raggiungere questo obiettivo. E poi usa il bingo di parole d'ordine per assegnare una parola a ciò che fai realmente. Proprio come tutti gli altri :-) La precisione non è poi così importante.

Answer 7

  

... il test di regressione era un piccolo esempio (solo per dimostrare che non hai rotto nulla con l'introduzione di una modifica o di nuovi moduli) campione dei test generali

Se è sufficiente un piccolo campione di test per dimostrare che il sistema funziona, perché esiste anche il resto dei test? E se ritieni di sapere che la modifica ha influito solo su un sottoinsieme di funzionalità, allora perché devi provare qualcosa dopo aver apportato la modifica? Gli umani sono fallibili, nessuno sa davvero se cambiare qualcosa rompe qualcos'altro. IMO, se i test sono automatizzati, rieseguili tutti. E se non sono automatizzati, automatizzali. Nel frattempo, riesegui tutto ciò che è automatizzato.

Answer 8

In generale, un sottoinsieme dei test delle funzionalità per la nuova funzionalità introdotta nella versione X di un prodotto diventa la base dei test di regressione per la versione X + 1, X + 2 e così via. Nel tempo, è possibile ridurre il tempo impiegato dai test di funzionalità / regressione di funzionalità stabili che non hanno subito regressioni. Se una funzione soffre di molte regressioni, può essere utile aumentare l'enfasi sulla funzione.

Penso che l'articolo che si riferisce al "test di regressione esteso" significhi eseguire un ampio set di test di regressione (individualmente semplici).