what is regression testing
Che cos'è il test di regressione?
Il test di regressione è un tipo di test che viene eseguito per verificare che una modifica del codice nel software non influisca sulle funzionalità esistenti del prodotto. Questo per assicurarsi che il prodotto funzioni correttamente con nuove funzionalità, correzioni di bug o qualsiasi modifica nella funzionalità esistente. I casi di test eseguiti in precedenza vengono rieseguiti per verificare l'impatto del cambiamento.
=> Fare clic qui per una serie completa di tutorial sul piano di test
Il test di regressione è un tipo di test del software in cui i casi di test vengono rieseguiti per verificare se la funzionalità precedente dell'applicazione funziona correttamente e le nuove modifiche non hanno introdotto nuovi bug.
Questo test può essere eseguito su una nuova build quando c'è un cambiamento significativo nella funzionalità originale anche in una singola correzione di bug.
Regressione significa ripetere il test delle parti non modificate dell'applicazione.
Cosa imparerai:
- Tutorial trattati in questa serie
- Panoramica del test di regressione
- Quando eseguire questo test?
- Il test di regressione può essere eseguito manualmente?
- Strumenti di test di regressione automatizzati
- Perché il test di regressione?
- Tipi di test di regressione
- Quanta regressione è richiesta?
- Cosa facciamo durante il controllo di regressione?
- Tecniche di test di regressione
- Come selezionare una suite di test di regressione?
- Come eseguire il test di regressione?
- Regressione in Agile
- Vantaggi
- Svantaggi
- Regressione dell'applicazione GUI
- Differenza tra regressione e nuovo test
- Modello del piano di test di regressione (TOC)
- Conclusione
- Lettura consigliata
Tutorial trattati in questa serie
Tutorial n. 1: Che cos'è il test di regressione (Questo tutorial)
Tutorial n. 2: Strumenti di test di regressione
Tutorial n. 3: Ripeti il test di regressione
Tutorial n. 4: Test di regressione automatizzato in Agile
Panoramica del test di regressione
Il test di regressione è come un metodo di verifica. I casi di test sono generalmente automatizzati in quanto i casi di test devono essere eseguiti più e più volte e l'esecuzione manuale degli stessi casi di test più e più volte manualmente richiede tempo e anche noioso.
Per esempio, Considera un prodotto X, in cui una delle funzionalità è di attivare la conferma, l'accettazione e l'invio di e-mail quando si fa clic sui pulsanti Conferma, Accetta e Invia.
Si verifica qualche problema nell'e-mail di conferma e per risolvere lo stesso, vengono apportate alcune modifiche al codice. In questo caso, non solo le e-mail di conferma devono essere testate, ma anche le e-mail di accettazione e inviate devono essere testate per garantire che la modifica del codice non le abbia influenzate.
Il test di regressione non dipende da alcun linguaggio di programmazione come Java, C ++, C #, ecc. Si tratta di un metodo di test che viene utilizzato per testare il prodotto per le modifiche o per eventuali aggiornamenti in corso. Verifica che qualsiasi modifica in un prodotto non influisca sui moduli esistenti del prodotto.
Verificare che i bug siano stati corretti e che le nuove funzionalità aggiunte non abbiano creato alcun problema nella precedente versione funzionante del software.
I tester eseguono il test funzionale quando una nuova build è disponibile per la verifica. Lo scopo di questo test è verificare le modifiche apportate alla funzionalità esistente e anche alla funzionalità appena aggiunta.
Al termine del test, il tester dovrebbe verificare se la funzionalità esistente funziona come previsto e le nuove modifiche non hanno introdotto alcun difetto nella funzionalità che funzionava prima di questa modifica.
Il test di regressione dovrebbe far parte del ciclo di rilascio e deve essere considerato nella stima del test.
Quando eseguire questo test?
Il test di regressione viene solitamente eseguito dopo la verifica di modifiche o nuove funzionalità. Ma non è sempre così. Per il rilascio che richiede mesi per essere completato, i test di regressione devono essere incorporati nel ciclo di test giornaliero. Per i rilasci settimanali, è possibile eseguire test di regressione al termine del test funzionale per le modifiche.
Il controllo della regressione è una variazione del nuovo test (che consiste semplicemente nel ripetere un test). Quando si ripete il test, il motivo può essere qualsiasi cosa. Diciamo che stavi testando una caratteristica particolare ed era la fine della giornata: non potevi finire il test e hai dovuto interrompere il processo senza decidere se il test è stato superato / fallito.
Il giorno successivo, quando torni, esegui il test ancora una volta, significa che stai ripetendo un test che hai eseguito in precedenza. Il semplice atto di ripetere un test è un nuovo test.
Il test di regressione al suo interno è una sorta di ripetizione. È solo per l'occasione speciale che qualcosa nell'applicazione / codice è cambiato. Potrebbe essere il codice, il design o qualsiasi altra cosa che determina la struttura generale del sistema.
Un nuovo test che viene condotto in questa situazione per assicurarsi che la suddetta modifica non abbia avuto un impatto su qualcosa che stava già funzionando prima è chiamato test di regressione. I motivi più comuni per cui questo potrebbe essere condotto sono perché sono state create nuove versioni del codice (aumento dell'ambito / requisito) o sono stati corretti dei bug.
Il test di regressione può essere eseguito manualmente?
Stavo insegnando uno di questi giorni nella mia classe e mi è venuta una domanda: 'La regressione può essere eseguita manualmente?'
Ho risposto alla domanda e siamo andati avanti con la classe. Sembrava tutto a posto, ma in qualche modo questa domanda mi tormentò per un bel po 'di tempo dopo.
Nel corso dei numerosi lotti, questa domanda viene posta più volte in vari modi diversi. Alcuni di loro sono:
- Per eseguire l'esecuzione del test abbiamo bisogno di uno strumento?
- Come viene eseguito il test di regressione?
- Anche dopo un intero ciclo di test, i nuovi arrivati hanno difficoltà a discernere cosa sia esattamente il test di regressione?
E, naturalmente, la domanda originale:
- Questo test può essere eseguito manualmente?
Iniziare con, Esecuzione del test è un semplice atto di utilizzare i tuoi casi di test ed eseguire quei passaggi sull'AUT, fornire i dati del test e confrontare il risultato ottenuto sull'AUT con il risultato atteso menzionato nei tuoi casi di test.
A seconda del risultato del confronto, impostiamo lo stato del test case superato / non superato. L'esecuzione del test è così semplice, non ci sono strumenti speciali necessari per questo processo.
Strumenti di test di regressione automatizzati
Il test di regressione automatizzato è l'area di test in cui possiamo automatizzare la maggior parte delle attività di test. Eseguiamo tutti i casi di test eseguiti in precedenza su una nuova build.
Ciò significa che abbiamo un set di test case disponibile e l'esecuzione manuale di questi test case richiede molto tempo. Conosciamo i risultati attesi, quindi automatizzare questi casi di test fa risparmiare tempo ed è un metodo di test di regressione efficiente. L'entità dell'automazione dipende dal numero di casi di test che rimarranno applicabili nel tempo.
Se i casi di test variano di volta in volta, l'ambito dell'applicazione continua ad aumentare e quindi l'automazione della procedura di regressione sarà una perdita di tempo.
La maggior parte degli strumenti di test di regressione sono di tipo registrazione e riproduzione. Registrerai i casi di test navigando attraverso l'AUT (applicazione sotto test) e verificherai se i risultati attesi stanno arrivando o meno.
Utensili
- Selenio
- Catalog Studio
- AdventNet QEngine
- Tester di regressione
- vTest
- acqua
- actiWate
- Rational Functional Tester
- SilkTest
- TimeShiftX
La maggior parte di questi sono strumenti di test funzionali e di regressione.
Lettura consigliata => Controlla qui per l'elenco dei principali strumenti di regressione
L'aggiunta e l'aggiornamento dei test case di regressione in una suite di test di automazione è un'attività complessa. Durante la selezione di uno strumento di automazione per i test di regressione, è necessario verificare se lo strumento consente di aggiungere o aggiornare facilmente i casi di test.
domande e risposte del colloquio di uscita campione
Nella maggior parte dei casi, è necessario aggiornare frequentemente i casi di test di regressione automatizzati a causa di frequenti modifiche nel sistema.
GUARDA IL VIDEO
Per una spiegazione più dettagliata della definizione con un esempio, controllare quanto segueVideo del test di regressione:
Perché il test di regressione?
La regressione viene avviata quando un programmatore corregge un bug o aggiunge un nuovo codice per nuove funzionalità al sistema.
Possono esserci molte dipendenze nelle funzionalità appena aggiunte ed esistenti.
È una misura di qualità per verificare se il nuovo codice è conforme al vecchio codice in modo che il codice non modificato non venga influenzato. Il più delle volte il team di test ha il compito di controllare le modifiche dell'ultimo minuto nel sistema.
In una tale situazione, è necessario testare solo l'area applicativa interessata per completare il processo di test in tempo coprendo tutti gli aspetti principali del sistema.
Questo test è molto importante quando viene aggiunto un continuo cambiamento / miglioramento nell'applicazione. La nuova funzionalità non dovrebbe influire negativamente sul codice testato esistente.
La regressione è necessaria per trovare i bug che si sono verificati a causa di una modifica nel codice. Se questo test non viene eseguito, il prodotto potrebbe presentare problemi critici nell'ambiente live e ciò può effettivamente portare il cliente nei guai.
Durante il test di qualsiasi sito Web online, un tester segnala un problema per cui il prezzo del prodotto non viene visualizzato correttamente, ovvero mostra un prezzo inferiore al prezzo effettivo del prodotto e deve essere risolto al più presto.
Una volta che lo sviluppatore risolve il problema, deve essere nuovamente testato ed è richiesto anche il test di regressione poiché la verifica del prezzo nella pagina segnalata sarebbe stata corretta ma potrebbe mostrare un prezzo errato nella pagina di riepilogo in cui viene mostrato il totale insieme con gli altri addebiti o la posta inviata al cliente ha ancora il prezzo errato.
Ora, in questo caso, il cliente dovrà sopportare la perdita se questo test non viene eseguito poiché il sito calcola il costo totale con il prezzo errato e lo stesso prezzo va a un cliente via e-mail. Una volta che il cliente accetta, il prodotto viene venduto online a un prezzo inferiore, sarà una perdita per il cliente.
Quindi, questo test gioca un ruolo importante ed è anche molto richiesto e importante.
Tipi di test di regressione
Di seguito sono riportati i vari tipi di regressione:
- Regressione unità
- Regressione parziale
- Regressione completa
# 1) Regressione delle unità
La regressione delle unità viene eseguita durante Test unitario fase e codice vengono testati isolatamente, ovvero tutte le dipendenze dall'unità da testare vengono bloccate in modo che l'unità possa essere testata individualmente senza alcuna discrepanza.
# 2) Regressione parziale
La regressione parziale viene eseguita per verificare che il codice funzioni correttamente anche quando le modifiche sono state apportate nel codice e quell'unità è integrata con il codice non modificato o già esistente.
# 3) Regressione completa
La regressione completa viene eseguita quando una modifica nel codice viene eseguita su un numero di moduli e anche se l'impatto della modifica di una modifica in qualsiasi altro modulo è incerto. Il prodotto nel suo insieme viene regredito per verificare eventuali modifiche a causa del codice modificato.
Quanta regressione è richiesta?
Ciò dipende dall'ambito delle nuove funzionalità aggiunte.
Se l'ambito di una correzione o di una funzionalità è troppo grande, anche l'area dell'applicazione interessata è piuttosto ampia e il test deve essere eseguito accuratamente, inclusi tutti i casi di test dell'applicazione. Ma questo può essere deciso in modo efficace quando il tester riceve input da uno sviluppatore sull'ambito, la natura e l'entità del cambiamento.
Poiché si tratta di test ripetitivi, i casi di test possono essere automatizzati in modo che un set di casi di test da solo possa essere facilmente eseguito su una nuova build.
I casi di test di regressione devono essere selezionati con molta attenzione in modo che la massima funzionalità sia coperta in un insieme minimo di casi di test. Questi set di casi di test necessitano di continui miglioramenti per le nuove funzionalità aggiunte.
Diventa molto difficile quando l'ambito dell'applicazione è molto vasto e ci sono continui incrementi o patch al sistema. In questi casi, è necessario eseguire test selettivi per risparmiare tempo e costi. Questi casi di test selettivi vengono selezionati in base ai miglioramenti apportati al sistema e alle parti in cui può influire maggiormente.
Cosa facciamo durante il controllo di regressione?
- Riesegui i test condotti in precedenza
- Confronta i risultati correnti con i risultati dei test eseguiti in precedenza
Si tratta di un processo continuo eseguito in varie fasi durante il ciclo di vita del test del software.
Una best practice consiste nell'eseguire un test di regressione dopo il Sanità o test del fumo e alla fine del test funzionale per un breve rilascio.
Per condurre test efficaci, la regressione Piano di test dovrebbe essere creato. Questo piano dovrebbe delineare la strategia del test di regressione e i criteri di uscita. Anche il test delle prestazioni fa parte di questo test per assicurarsi che le prestazioni del sistema non siano influenzate dalle modifiche apportate ai componenti del sistema.
Migliori pratiche : Esegui casi di test automatizzati ogni giorno la sera in modo che eventuali effetti collaterali di regressione possano essere corretti nella build del giorno successivo. In questo modo si riduce il rischio di rilascio coprendo quasi tutti i difetti di regressione in una fase iniziale piuttosto che trovare e correggere quelli alla fine del ciclo di rilascio.
Tecniche di test di regressione
Di seguito sono riportate le varie tecniche.
- Riprova tutto
- Selezione test di regressione
- Priorità dei casi di test
- Ibrido
# 1) Riprova tutto
Come suggerisce il nome stesso, gli interi casi di test nella suite di test vengono rieseguiti per garantire che non ci siano bug che si sono verificati a causa di una modifica nel codice. Questo è un metodo costoso in quanto richiede più tempo e risorse rispetto alle altre tecniche.
# 2) Selezione del test di regressione
In questo metodo, i casi di test vengono selezionati dalla suite di test per essere rieseguiti. Non l'intera suite viene rieseguita. La selezione dei casi di test viene eseguita sulla base della modifica del codice nel modulo.
I casi di test sono divisi in due categorie, uno è casi di test riutilizzabili e un altro è casi di test obsoleti. I casi di test riutilizzabili possono essere utilizzati nei cicli di regressione futuri mentre quelli obsoleti non vengono utilizzati nei cicli di regressione imminenti.
# 3) Assegnazione delle priorità allo scenario di test
I casi di test con priorità alta vengono eseguiti per primi rispetto a quelli con priorità media e bassa. La priorità del test case dipende dalla sua criticità e dal suo impatto sul prodotto e anche dalla funzionalità del prodotto che viene utilizzato più spesso.
# 4) Ibrido
La tecnica ibrida è una combinazione di selezione del test di regressione e Priorità dei casi di test. Piuttosto che selezionare l'intera suite di test, seleziona solo i casi di test che vengono rieseguiti in base alla loro priorità.
Come selezionare una suite di test di regressione?
La maggior parte dei bug trovati nell'ambiente di produzione si verificano a causa delle modifiche apportate o dei bug risolti all'undicesima ora, ovvero le modifiche apportate in una fase successiva. La correzione dei bug nell'ultima fase potrebbe creare altri problemi / bug nel prodotto. Ecco perché il controllo della regressione è molto importante prima di rilasciare un prodotto.
Di seguito è riportato un elenco di casi di test che possono essere utilizzati durante l'esecuzione di questo test:
- Funzionalità utilizzate frequentemente.
- Casi di test che coprono il modulo in cui sono state apportate le modifiche.
- Casi di test complessi.
- Casi di test di integrazione che includono tutti i componenti principali.
- Casi di test per le funzionalità o le caratteristiche principali del prodotto.
- I casi di test Priorità 1 e Priorità 2 dovrebbero essere inclusi.
- Casi di test che spesso falliscono o difetti di test recenti sono stati trovati nello stesso.
Come eseguire il test di regressione?
Ora che abbiamo stabilito cosa significa regressione, è evidente che sta anche testando, semplicemente ripetendo in una situazione specifica per un motivo specifico. Pertanto, possiamo tranquillamente dedurre che lo stesso metodo applicato per i test in primo luogo può essere applicato anche a questo.
Pertanto, se il test può essere eseguito manualmente, può esserlo anche il test di regressione. L'uso di uno strumento non è necessario. Tuttavia, col passare del tempo le applicazioni si accumulano con sempre più funzionalità che continuano ad aumentare l'ambito della regressione. Per sfruttare al massimo il tempo, questo test è il più delle volte automatizzato .
Di seguito sono riportati i vari passaggi coinvolti nell'esecuzione di questo test
- Preparare una suite di test per la regressione considerando i punti menzionati in 'Come selezionare la suite di test di regressione'?
- Automatizza tutti i casi di test della suite di test.
- Aggiorna la suite di regressione ogni volta che è necessario, come se venisse trovato un nuovo difetto che non è coperto nel test case, e un test case per lo stesso dovrebbe essere aggiornato nella suite di test in modo che il test non venga perso per lo stesso la prossima volta . La suite di test di regressione dovrebbe essere gestita correttamente aggiornando continuamente i casi di test.
- Esegui i casi di test di regressione ogni volta che viene apportata una modifica al codice, il bug viene corretto, viene aggiunta una nuova funzionalità, viene apportato un miglioramento alla funzionalità esistente, ecc.
- Creare un report di esecuzione del test che includa lo stato Superato / non riuscito dei casi di test eseguiti.
Per esempio:
Lasciatemi spiegare questo con un esempio. Si prega di esaminare la situazione seguente:
Statistiche versione 1 | |
---|---|
No. di tester | 3 |
Nome dell'applicazione | XYZ |
Numero di versione / rilascio | 1 |
Numero di requisiti (ambito) | 10 |
Numero di casi di test / test | 100 |
Numero di giorni necessari per lo sviluppo | 5 |
Numero di giorni necessari per eseguire il test | 5 |
Statistiche versione 2 | |
---|---|
No. di tester | 3 |
Nome dell'applicazione | XYZ |
Numero di versione / rilascio | Due |
Numero di requisiti (ambito) | 10+ 5 nuovi requisiti |
Numero di casi di test / test | 100+ 50 nuovi |
Numero di giorni necessari per lo sviluppo | 2,5 (poiché questa metà della quantità di lavoro rispetto a prima) |
Numero di giorni necessari per eseguire il test | 5 (per i 100 TC esistenti) + 2,5 (per i nuovi requisiti) |
Statistiche della versione 3 | |
---|---|
No. di tester | 3 |
Nome dell'applicazione | XYZ |
Numero di versione / rilascio | 3 |
Numero di requisiti (ambito) | 10+ 5 + 5 nuovi requisiti |
Numero di casi di test / test | 100+ 50+ 50 nuovi |
Numero di giorni necessari per lo sviluppo | 2,5 (poiché questa metà della quantità di lavoro rispetto a prima) |
Numero di giorni necessari per eseguire il test | 7,5 (per i 150 TC esistenti) + 2,5 (per i nuovi requisiti) |
Le seguenti sono le osservazioni che possiamo fare dalla situazione di cui sopra:
- Man mano che le versioni crescono, la funzionalità cresce.
- Il tempo di sviluppo non aumenta necessariamente con le versioni, ma il tempo di test sì
- Nessuna azienda / il suo management sarà pronto a investire più tempo nei test e meno nello sviluppo
- Non possiamo nemmeno ridurre il tempo necessario per i test aumentando le dimensioni del team di test perché più persone significano più soldi e nuove persone significa anche molta formazione e forse anche un compromesso nella qualità poiché le nuove persone potrebbero non essere alla pari con le conoscenze richieste livelli immediatamente.
- L'altra alternativa è chiaramente ridurre la quantità di regressione. Ma ciò potrebbe essere rischioso per il prodotto software.
Per tutti questi motivi, il test di regressione è un buon candidato per il test di automazione, ma non deve essere eseguito solo in questo modo.
Passaggi di base per eseguire i test di regressione
Ogni volta che il software subisce una modifica e ne esce una nuova versione / rilascio, i seguenti sono i passaggi che puoi compiere per eseguire questo tipo di test:
- Comprendi che tipo di modifiche sono state apportate al software
- Analizzare e determinare quali moduli / parti del software potrebbero essere influenzati: i team di sviluppo e BA possono essere determinanti nel fornire queste informazioni
- Dai un'occhiata ai tuoi casi di test e determina se dovrai eseguire una regressione completa, parziale o unitaria. Individua quelli che si adattano alla tua situazione
- Pianifica il tempo e prova!
Regressione in Agile
Agile è un approccio adattivo che segue un metodo iterativo e incrementale. Il prodotto è sviluppato in brevi iterazioni chiamate sprint che durano 2-4 settimane. In Agile, ci sono un certo numero di iterazioni, quindi questo test gioca un ruolo significativo poiché la nuova funzionalità o la modifica del codice viene eseguita nelle iterazioni.
La suite di test di regressione dovrebbe essere preparata dalla fase iniziale e dovrebbe essere aggiornata ad ogni sprint.
In Agile, il controllo della regressione è coperto da due categorie:
- Regressione a livello di sprint
- Regressione end-to-end
# 1) Regressione del livello di sprint
La regressione del livello di sprint viene eseguita principalmente per la nuova funzionalità o il miglioramento apportato nell'ultimo sprint. I casi di test dalla suite di test vengono selezionati in base alla funzionalità appena aggiunta o al miglioramento eseguito.
# 2) Regressione end-to-end
La regressione end-to-end include tutti i casi di test che devono essere rieseguiti per testare l'intero prodotto end-to-end coprendo tutte le funzionalità principali del prodotto.
Dato che Agile ha sprint brevi e va avanti, è molto necessario automatizzare la suite di test, i casi di test vengono eseguiti di nuovo e anche questo deve essere completato in un breve lasso di tempo. L'automazione dei casi di test riduce i tempi di esecuzione e lo slittamento dei difetti.
Vantaggi
Di seguito sono riportati i vari vantaggi del test di regressione
- Migliora la qualità del prodotto.
- Assicura che qualsiasi correzione di bug o miglioramento apportato non influisca sulle funzionalità esistenti del Prodotto.
- Gli strumenti di automazione possono essere utilizzati per questo test.
- Si assicura che i problemi che sono già stati risolti non si ripetano.
Svantaggi
Sebbene ci siano molti vantaggi, ci sono anche alcuni svantaggi. Sono:
- Deve essere fatto anche per una piccola modifica nel codice perché anche una piccola modifica nel codice può creare problemi nella funzionalità esistente.
- Se nel caso in cui l'automazione non viene utilizzata nel progetto per questo test, sarà un compito noioso e dispendioso in termini di tempo eseguire i casi di test ancora e ancora.
Regressione dell'applicazione GUI
È difficile eseguire un test di regressione GUI (Graphical User Interface) quando la struttura della GUI è modificato. I casi di test scritti sulla vecchia GUI diventano obsoleti o devono essere modificati.
Riutilizzare i casi di test di regressione significa che i casi di test della GUI vengono modificati in base alla nuova GUI. Ma questa attività diventa complicata se si dispone di un ampio set di casi di test GUI.
Differenza tra regressione e nuovo test
Il nuovo test viene eseguito per i casi di test che falliscono durante l'esecuzione e il bug sollevato per lo stesso è stato risolto mentre il controllo di regressione non è limitato alla correzione del bug in quanto copre anche altri casi di test per garantire che la correzione del bug non abbia ha influito su qualsiasi altra funzionalità del Prodotto.
Modello del piano di test di regressione (TOC)
1. Cronologia del documento
2. Riferimenti
3. Piano di test di regressione
3.1. introduzione
3.2. Scopo
3.3. Strategia di test
3.4. Caratteristica da testare
3.5. Fabbisogno di risorse
3.5.1. Requisiti hardware
3.5.2. Requisiti software
3.6. Programma dei test
3.7. Richiesta di modifica
3.8. Criteri di ingresso / uscita
3.8.1. Criteri di ingresso per questo test
3.8.2. Criteri di uscita per questo test
3.9. Presupposti / vincoli
3.10. Casi test
3.11. Rischio / ipotesi
3.12. Utensili
4. Approvazione / accettazione
Diamo un'occhiata a ciascuno di essi in dettaglio.
# 1) Cronologia dei documenti
La cronologia del documento consiste in una registrazione della prima bozza e di tutte quelle aggiornate nel formato indicato di seguito.
Versione | Data | Autore | Commento |
---|---|---|---|
1 | GG / MM / AA | ABC | Approvato |
Due | GG / MM / AA | ABC | Aggiornato per la funzionalità aggiunta |
# 2) Riferimenti
La colonna Riferimenti tiene traccia di tutti i documenti di riferimento utilizzati o richiesti per il progetto durante la creazione di un piano di test.
Non | Documento | Posizione |
---|---|---|
1 | Documento SRS | Guida condivisa |
# 3) Piano di test di regressione
3.1. introduzione
Questo documento descrive la modifica / aggiornamento / miglioramento del Prodotto da testare e l'approccio utilizzato per questo test. Tutte le modifiche al codice, i miglioramenti, gli aggiornamenti e le funzionalità aggiunte sono delineate per essere testate. I casi di test utilizzati per Unit Testing e Integration Testing possono essere utilizzati per creare una suite di test per la regressione.
3.2. Scopo
Lo scopo del piano di test di regressione è descrivere cosa esattamente e come verrebbero eseguiti i test per ottenere i risultati. Il controllo della regressione viene eseguito per garantire che nessun'altra funzionalità del prodotto sia ostacolata dalla modifica del codice.
3.3. Strategia di test
La strategia di test descrive l'approccio che verrà utilizzato per eseguire questo test e che include la tecnica che verrà utilizzata, quali saranno i criteri di completamento, chi eseguirà quale attività, chi scriverà gli script di test, quale strumento di regressione verrà utilizzato , passaggi per coprire i rischi come la mancanza di risorse, il ritardo nella produzione, ecc.
3.4. Caratteristiche da testare
Le caratteristiche / i componenti del prodotto da testare sono elencati qui. Nella regressione, tutti i casi di test vengono rieseguiti o vengono scelti quelli che influenzano la funzionalità esistente a seconda della correzione / aggiornamento o miglioramento effettuato.
3.5. Fabbisogno di risorse
3.5.1. Requisiti hardware:
I requisiti hardware sono identificati qui come computer, laptop, modem, libri Mac, smartphone, ecc.
3.5.2. Requisiti software:
Il requisito software viene identificato come il sistema operativo e i browser necessari.
3.6. Programma dei test
La pianificazione del test definisce il tempo stimato per l'esecuzione delle attività di test.
Per esempio Quante risorse eseguiranno un'attività di test e anche quella in quanto tempo?
3.7. Richiesta di modifica
Vengono menzionati i dettagli della CR per cui verrà eseguita la regressione.
S.No | Descrizione CR | Suite di test di regressione |
---|---|---|
1 | ||
Due |
3.8. Criteri di ingresso / uscita
3.8.1. Criteri di ingresso per questo test:
Sono definiti i criteri di immissione per il prodotto per avviare il controllo di regressione.
Per esempio:
- Le modifiche alla codifica / il miglioramento / l'aggiunta di nuove funzionalità dovrebbero essere completate.
- Il piano di test di regressione dovrebbe essere approvato.
3.8.2. Criteri di uscita per questo test:
Qui vengono definiti i criteri di uscita per la regressione.
Per esempio:
- Il test di regressione dovrebbe essere completato.
- Eventuali nuovi bug critici rilevati durante questo test dovrebbero essere chiusi.
- Il rapporto di prova dovrebbe essere pronto.
3.9. Casi test
I casi di test di regressione sono definiti qui.
3.10. Rischio / ipotesi
Vengono identificati eventuali rischi e ipotesi e per lo stesso viene preparato un piano di emergenza.
3.11. Utensili
Vengono identificati gli strumenti da utilizzare nel Progetto. Ad esempio:
- Strumento di automazione
- Strumento di segnalazione bug
# 4) Approvazione / accettazione
I nomi e le designazioni delle persone sono elencati qui:
Nome | Approvato / Rifiutato | Firma | Data |
---|---|---|---|
Conclusione
Il test di regressione è uno degli aspetti importanti in quanto aiuta a fornire un prodotto di qualità assicurandosi che qualsiasi modifica nel codice, piccola o grande, non influisca sulle funzionalità esistenti o vecchie.
Sono disponibili molti strumenti di automazione per automatizzare i casi di test di regressione, tuttavia, è necessario selezionare uno strumento in base ai requisiti del progetto. Uno strumento dovrebbe avere la capacità di aggiornare la suite di test poiché la suite di test Regression deve essere aggiornata frequentemente.
Con ciò, concludiamo questo argomento e speriamo che d'ora in poi ci sarà molta più chiarezza sull'argomento.
Fateci sapere le vostre domande e commenti relativi alla regressione. Come hai affrontato le tue attività di test di regressione?
=> Visita qui per una serie completa di tutorial sul piano di test
Lettura consigliata
- Migliori strumenti di test del software 2021 (Strumenti di automazione del test QA)
- I 10 strumenti di test di regressione più popolari nel 2021
- Che cos'è il test di affidabilità: definizione, metodo e strumenti
- 11 migliori strumenti di automazione per testare applicazioni Android (strumenti di test per app Android)
- Test di regressione automatizzato: sfide, processo e passaggi
- Download dell'eBook Testing Primer
- Differenza tra test di ripetizione e test di regressione con esempio
- Top 10+ migliori strumenti di test SAP (strumenti di automazione SAP)