Menu

Esercitazione sul test della migrazione dei dati: una guida completa

data migration testing tutorial

Prova Il Nostro Strumento Per Eliminare I Problemi

Panoramica del test di migrazione dei dati:

Si sente abbastanza spesso che un'applicazione viene spostata su un server diverso, la tecnologia viene modificata, viene aggiornata alla versione successiva o spostata su un server database diverso, ecc.,

  • Cosa significa questo in realtà?
  • Cosa ci si aspetta dal team di test in queste situazioni?

Dal punto di vista del test, tutto ciò significa che l'applicazione deve essere testata accuratamente end-to-end insieme alla migrazione dal sistema esistente al nuovo sistema con successo.

Tutorial in questa serie:

In questo caso il test del sistema deve essere eseguito con tutti i dati, che vengono utilizzati in una vecchia applicazione e anche con i nuovi dati. La funzionalità esistente deve essere verificata insieme alla funzionalità nuova / modificata.

Test di migrazione dei dati

Invece di solo test di migrazione, può anche essere definito come test di migrazione dei dati, in cui tutti i dati dell'utente verranno migrati su un nuovo sistema.

Pertanto, il test di migrazione include test con vecchi dati, nuovi dati o una combinazione di entrambe, vecchie funzionalità (funzionalità invariate) e nuove funzionalità.

La vecchia applicazione viene solitamente definita come ' eredità ' applicazione. Insieme all'applicazione nuova / aggiornata, è anche obbligatorio continuare a testare l'applicazione legacy fino a quando quelle nuove / aggiornate non diventano stabili e coerenti. Un ampio test di migrazione sulla nuova applicazione rivelerà i nuovi problemi che non sono stati trovati nell'applicazione precedente.

Cosa imparerai:

Cos'è il test di migrazione?

Il test di migrazione è un processo di verifica della migrazione del sistema legacy al nuovo sistema con interruzioni / tempi di inattività minimi, con integrità dei dati e nessuna perdita di dati, garantendo al contempo che tutti gli aspetti funzionali e non funzionali specificati dell'applicazione siano soddisfatti dopo migrazione.

Rappresentazione semplice del sistema di migrazione:

Test di migrazione

Perché il test di migrazione?

Come sappiamo, la migrazione dell'applicazione a un nuovo sistema potrebbe essere per vari motivi, consolidamento del sistema, tecnologia obsoleta, ottimizzazione o qualsiasi altro motivo.

Pertanto, sebbene il sistema in uso debba essere migrato su un nuovo sistema, è essenziale garantire i seguenti punti:

  1. Qualsiasi tipo di interruzione / disagio causato all'utente a causa della migrazione deve essere evitato / ridotto al minimo. Ad esempio: downtime, perdita di dati
  2. È necessario assicurarsi che l'utente possa continuare a utilizzare tutte le funzionalità del software causando danni minimi o nulli durante la migrazione. Ad esempio: modifica della funzionalità, rimozione di una funzionalità particolare
  3. È inoltre importante anticipare ed escludere tutti i possibili glitch / ostacoli che potrebbero verificarsi durante l'effettiva migrazione del sistema live.

Quindi, al fine di garantire una migrazione regolare del sistema live eliminando tali difetti, è essenziale eseguire il test di migrazione in laboratorio.

Questo test ha la sua importanza e gioca un ruolo fondamentale quando i dati entrano in gioco.

Tecnicamente, è anche necessario che venga eseguito per i seguenti scopi:

  • Per garantire la compatibilità dell'applicazione nuova / aggiornata con tutto l'hardware e il software possibile supportati dall'applicazione legacy. Inoltre, nuovo Compatibilità dovrebbe essere testato anche per nuovo hardware, piattaforma software.
  • Per garantire che tutte le funzionalità esistenti funzionino come nell'applicazione legacy. Non dovrebbe esserci alcun cambiamento nel modo in cui funziona l'applicazione rispetto a quella legacy.
  • La possibilità di un gran numero di difetti dovuti alla migrazione è molto alta. Molti dei difetti saranno solitamente correlati ai dati e quindi questi difetti devono essere identificati e corretti durante il test.
  • Per garantire se il tempo di risposta del sistema dell'applicazione nuova / aggiornata è uguale o inferiore a quello necessario per l'applicazione legacy.
  • Per garantire che la connessione tra server, hardware, software ecc. Sia intatta e non si interrompa durante il test. Il flusso di dati tra i diversi componenti non dovrebbe interrompersi in nessuna condizione.

Quando è necessario questo test?

Il test deve essere eseguito sia prima che dopo la migrazione.

Le diverse fasi del test di migrazione da eseguire presso il Laboratorio di Prova possono essere classificati come di seguito.

  1. Test pre-migrazione
  2. Test di migrazione
  3. Test post migrazione

Oltre a quanto sopra, il vengono eseguiti anche i seguenti test come parte dell'intera attività di migrazione.

  1. Verifica della compatibilità con le versioni precedenti
  2. Test di rollback

Prima di eseguire questo test, è essenziale che qualsiasi Tester comprenda chiaramente i punti seguenti:

  1. I cambiamenti che avvengono come parte del nuovo sistema (server, front end, DB, schema, flusso di dati, funzionalità ecc.)
  2. Comprendere l'effettiva strategia di migrazione stabilita dal team. Come avviene la migrazione, i cambiamenti passo passo che avvengono nel backend del sistema e gli script responsabili di questi cambiamenti.

Quindi è essenziale fare uno studio approfondito del vecchio e del nuovo sistema e quindi pianificare e progettare di conseguenza i casi di test e gli scenari di test da coprire come parte delle fasi di test sopra e preparare la strategia di test.

Strategia di test sulla migrazione dei dati

La progettazione della strategia di test per la migrazione include una serie di attività da svolgere e pochi aspetti da considerare. Questo per ridurre al minimo gli errori e i rischi che si verificano a seguito della migrazione e per eseguire il test di migrazione in modo efficace.

Attività in questo test:

# 1) Formazione di squadre specializzate :

Formare il team di test con i membri che hanno la conoscenza e l'esperienza richieste e fornire formazione relativa al sistema che si sta migrando.

#Due) Analisi dei rischi aziendali, analisi dei possibili errori :

Le attività attuali non dovrebbero essere ostacolate dopo la migrazione e quindi svolgere ' Analisi dei rischi aziendali ' incontri che coinvolgono gli stakeholder giusti (Test Manager, Business Analyst, Architects, Product Owner, Business Owner ecc.) e identificare i rischi e le mitigazioni implementabili. Il test dovrebbe includere scenari per scoprire tali rischi e verificare se sono state implementate mitigazioni adeguate.

Condotta ' Possibile analisi degli errori ' utilizzando appropriato 'Approcci per indovinare l'errore' e quindi progettare test intorno a questi errori per portarli alla luce durante il test.

domande e risposte al colloquio di garanzia della qualità

# 3) Analisi e identificazione dell'ambito della migrazione:

Analizza l'ambito chiaro del test di migrazione come quando e cosa deve essere testato.

# 4) Identifica lo strumento appropriato per la migrazione:

Durante la definizione della strategia di questo test, automatizzato o manuale, identificare gli strumenti che verranno utilizzati. Per esempio: Strumento automatizzato per confrontare i dati di origine e di destinazione.

# 5) Identificare l'ambiente di test appropriato per la migrazione:

Identificare ambienti separati per gli ambienti pre e post migrazione per eseguire qualsiasi verifica richiesta come parte del test. Comprendere e documentare gli aspetti tecnici del sistema di migrazione legacy e nuovo, per garantire che l'ambiente di test sia configurato in base a tale impostazione.

# 6) Documento di specifica del test di migrazione e revisione:

Preparare il documento di specifica del test di migrazione che descriva chiaramente l'approccio al test, le aree di test, i metodi di test (automatizzati, manuali), la metodologia di test (scatola nera, tecnica di prova scatola bianca ), Numero di cicli di test, pianificazione dei test, approccio alla creazione di dati e utilizzo di dati in tempo reale (le informazioni sensibili devono essere mascherate), specifiche dell'ambiente di test, qualificazione dei tester, ecc.

# 7) Avvio in produzione del sistema migrato :

Analizza e documenta l'elenco delle cose da fare per la migrazione della produzione e pubblicalo con largo anticipo

Diverse fasi della migrazione

Di seguito sono riportate le varie fasi della migrazione.

Fase 1:Test pre-migrazione

Prima di migrare i dati, una serie di attività di test viene eseguita come parte della fase di test pre-migrazione. Questo viene ignorato o non considerato nelle applicazioni più semplici. Ma quando si devono migrare applicazioni complesse, le attività di pre-migrazione sono un must.

Di seguito è riportato l'elenco delle azioni che vengono intraprese durante questa fase:

  • Stabilisci un ambito chiaro dei dati: quali dati devono essere inclusi, quali dati devono essere esclusi, quali dati necessitano di trasformazioni / conversioni, ecc.
  • Eseguire la mappatura dei dati tra la versione precedente e la nuova applicazione: per ogni tipo di dati nell'applicazione precedente, confrontare il tipo pertinente nella nuova applicazione e quindi mapparli - Mappatura di livello superiore.
  • Se la nuova applicazione contiene il campo obbligatorio, ma non è il caso in legacy, assicurati che il campo legacy non abbia quel campo come nullo. - Mappatura di livello inferiore.
  • Studiare lo schema dei dati della nuova applicazione: nomi di campi, tipi, valori minimi e massimi, lunghezza, campi obbligatori, convalide a livello di campo ecc., Chiaramente
  • È necessario annotare un certo numero di tabelle nel sistema precedente e verificare se vengono eliminate e aggiunte dopo la migrazione.
  • Un numero di record in ciascuna tabella, le visualizzazioni dovrebbero essere annotate nell'applicazione precedente.
  • Studia le interfacce nella nuova applicazione e le loro connessioni. I dati che fluiscono nell'interfaccia dovrebbero essere altamente protetti e non danneggiati.
  • Preparare casi di test, scenari di test e casi d'uso per nuove condizioni nelle nuove applicazioni.
  • Esegui una serie di casi di test, scenari con un insieme di utenti e conserva i risultati e i registri archiviati. Lo stesso deve essere verificato dopo la migrazione per garantire che i dati e le funzionalità legacy siano intatti.
  • Il conteggio dei dati e dei record deve essere annotato chiaramente, deve essere verificato dopo la migrazione per evitare perdite di dati.

Fase 2:Test di migrazione

' Guida alla migrazione 'che è preparato dal team di migrazione deve essere rigorosamente seguito per svolgere l'attività di migrazione. Idealmente, l'attività di migrazione inizia con il backup dei dati sul nastro, in modo che il sistema legacy possa essere ripristinato in qualsiasi momento.

Verifica della documentazione parte di ' Anche la Guida alla migrazione fa parte del test di migrazione dei dati . Verifica se il documento è chiaro e facile da seguire. Tutti gli script e i passaggi devono essere documentati correttamente senza alcuna ambiguità. Qualsiasi tipo di errore di documentazione, mancata corrispondenza nell'ordine di esecuzione dei passaggi deve essere considerato importante in modo che possa essere segnalato e corretto.

Gli script di migrazione, la guida e altre informazioni relative alla migrazione effettiva devono essere prelevati dal repository di controllo della versione per l'esecuzione.

Annotare il tempo effettivo impiegato per la migrazione dal punto di inizio della migrazione fino al corretto ripristino del sistema, è uno dei casi di test da eseguire e quindi il 'Tempo impiegato per migrare il sistema' deve essere registrato nel rapporto di prova finale che sarà consegnato come parte dei risultati del test di migrazione e queste informazioni saranno utili durante il lancio della produzione. Il tempo di inattività registrato nell'ambiente di test viene estrapolato per calcolare il tempo di inattività approssimativo nel sistema live.

È sul sistema legacy dove verrà svolta l'attività di migrazione.

Durante questo test, tutti i componenti dell'ambiente verranno normalmente disattivati ​​e rimossi dalla rete per eseguire le attività di migrazione. Quindi è necessario notare il 'Tempo di inattività' richiesto per il test di migrazione. Idealmente, sarà lo stesso dell'epoca della migrazione.

In generale, l'attività di migrazione definita nel documento 'Guida alla migrazione' include:

  • Migrazione effettiva dell'applicazione
  • Firewall, porte, host, hardware, configurazioni software vengono tutti modificati in base al nuovo sistema su cui viene migrato il legacy
  • Fughe di dati, vengono eseguiti controlli di sicurezza
  • La connettività tra tutti i componenti dell'applicazione è verificata

Si consiglia ai tester di verificare quanto sopra nel backend del sistema o conducendo test white box.

Una volta completata l'attività di Migrazione specificata nella guida, vengono attivati ​​tutti i server e verranno eseguiti i test di base relativi alla verifica del buon esito della migrazione, il che garantisce che tutti i sistemi end to end siano opportunamente collegati e tutti i componenti stiano comunicando tra loro altro, DB è attivo e funzionante, il front-end sta comunicando con successo con il back-end. Questi test devono essere identificati in anticipo e registrati nel documento Specifiche del test di migrazione.

È possibile che il software supporti più piattaforme diverse. In tal caso, la migrazione deve essere verificata separatamente su ciascuna di queste piattaforme.

La verifica degli script di migrazione farà parte del test di migrazione. A volte lo script di migrazione individuale viene verificato anche utilizzando il 'test white box' in un ambiente di test autonomo.

Quindi il test di migrazione sarà una combinazione di 'test white box e black box'.

Una volta eseguita questa verifica relativa alla migrazione e superati i test corrispondenti, il team può procedere ulteriormente con l'attività di test Post-Migration.

Fase 3:Test di post-migrazione

Una volta che l'applicazione è stata migrata con successo, entra in gioco il test Post-Migration.

Qui il test del sistema end-to-end viene eseguito nell'ambiente di test. I tester eseguono casi di test identificati, scenari di test, casi d'uso con dati legacy e un nuovo set di dati.

Oltre a questi, ci sono elementi specifici da verificare negli ambienti migrati elencati di seguito:

è c ++ meglio di java

Tutti questi sono documentati come un caso di prova e inclusi nel documento 'Specifiche di prova'.

  1. Verificare se tutti i dati nella legacy vengono migrati nella nuova applicazione entro il tempo di inattività pianificato. Per garantire ciò, confrontare il numero di record tra il precedente e la nuova applicazione per ogni tabella e vista nel database. Inoltre, segnala il tempo impiegato per spostarti, diciamo 10000 record.
  2. Verificare se tutte le modifiche allo schema (campi e tabelle aggiunti o rimossi) in base al nuovo sistema vengono aggiornate.
  3. I dati migrati dall'applicazione precedente a quella nuova dovrebbero mantenere il proprio valore e formato a meno che non venga specificato di farlo. Per garantire ciò, confronta i valori dei dati tra il database dell'applicazione precedente e quello della nuova applicazione.
  4. Testare i dati migrati con la nuova applicazione. Qui copre un numero massimo di casi possibili. Per garantire una copertura del 100% rispetto alla verifica della migrazione dei dati, utilizzare lo strumento di test automatizzato.
  5. Verifica la sicurezza del database.
  6. Verificare l'integrità dei dati per tutti i record di esempio possibili.
  7. Verificare e assicurarsi che la funzionalità supportata in precedenza nel sistema legacy funzioni come previsto nel nuovo sistema.
  8. Controllare il flusso di dati all'interno dell'applicazione che copre la maggior parte dei componenti.
  9. L'interfaccia tra i componenti dovrebbe essere ampiamente testata, poiché i dati non dovrebbero essere modificati, persi e danneggiati quando passano attraverso i componenti. I casi di test di integrazione possono essere utilizzati per verificarlo.
  10. Verifica la ridondanza dei dati precedenti. Nessun dato legacy deve essere duplicato durante la migrazione
  11. Verificare la presenza di casi di mancata corrispondenza dei dati come il tipo di dati modificato, il formato di archiviazione è cambiato ecc.,
  12. Tutti i controlli a livello di campo nell'applicazione legacy dovrebbero essere coperti anche nella nuova applicazione
  13. Qualsiasi aggiunta di dati nella nuova applicazione non dovrebbe riflettere l'eredità
  14. L'aggiornamento dei dati dell'applicazione precedente tramite la nuova applicazione dovrebbe essere supportato. Una volta aggiornato nella nuova applicazione, non dovrebbe riflettere sull'eredità.
  15. L'eliminazione dei dati dell'applicazione legacy nella nuova applicazione dovrebbe essere supportata. Una volta eliminato nella nuova applicazione, non dovrebbe eliminare anche i dati legacy.
  16. Verificare che le modifiche apportate al sistema legacy supportino la nuova funzionalità fornita come parte del nuovo sistema.
  17. Verificare che gli utenti del sistema precedente possano continuare a utilizzare sia la vecchia funzionalità che la nuova funzionalità, soprattutto quelle in cui sono coinvolte le modifiche. Eseguire i casi di test ei risultati dei test memorizzati durante il test di pre-migrazione.
  18. Crea nuovi utenti sul sistema ed esegui test per garantire che le funzionalità della legacy e della nuova applicazione supportino gli utenti appena creati e funzionino bene.
  19. Eseguire test relativi alla funzionalità con una varietà di campioni di dati (gruppo di età diverso, utenti di regioni diverse ecc.)
  20. È inoltre necessario verificare se i 'Flag di funzionalità' sono abilitati per le nuove funzionalità e attivarli / disattivarli abilita l'attivazione e la disattivazione delle funzionalità.
  21. Il test delle prestazioni è importante per garantire che la migrazione a un nuovo sistema / software non abbia degradato le prestazioni del sistema.
  22. È inoltre necessario eseguire prove di carico e stress per garantire la stabilità del sistema.
  23. Verificare che l'aggiornamento del software non abbia aperto alcuna vulnerabilità di sicurezza e quindi eseguire test di sicurezza, soprattutto nell'area in cui sono state apportate modifiche al sistema durante la migrazione.
  24. L'usabilità è un altro aspetto che deve essere verificato, in cui se il layout della GUI / sistema di front-end è cambiato o qualsiasi funzionalità è cambiata, qual è la facilità d'uso che l'utente finale prova rispetto al sistema legacy.

Poiché l'ambito dei test di post-migrazione diventa molto vasto, è ideale separare i test importanti che devono essere eseguiti prima per qualificare che la migrazione ha successo e quindi per eseguire i rimanenti in un secondo momento.

Si consiglia inoltre di automatizzare i casi di test funzionali end-to-end e altri casi di test possibili in modo che il tempo di test possa essere ridotto e i risultati siano disponibili rapidamente.

Alcuni suggerimenti per i tester per scrivere i casi di test per l'esecuzione post-migrazione:

  • Quando l'applicazione viene migrata, non significa che i casi di test devono essere scritti per l'intera nuova applicazione. I casi di test già progettati per l'eredità dovrebbero ancora essere validi per la nuova applicazione. Quindi, per quanto possibile, utilizza i vecchi casi di test e converti i casi di test legacy in casi di una nuova applicazione ove necessario.
  • In caso di modifiche alle funzionalità nella nuova applicazione, è necessario modificare i casi di test relativi alla funzionalità.
  • Se è presente una nuova funzionalità aggiunta nella nuova applicazione, è necessario progettare nuovi casi di test per quella particolare funzionalità.
  • Quando si verifica un calo di funzionalità nella nuova applicazione, i casi di test dell'applicazione legacy correlata non devono essere presi in considerazione per l'esecuzione post migrazione e devono essere contrassegnati come non validi e separati.
  • I casi di test progettati dovrebbero essere sempre affidabili e coerenti in termini di utilizzo. La verifica dei dati critici dovrebbe essere coperta nei casi di test in modo che non venga persa durante l'esecuzione.
  • Quando il design della nuova applicazione è diverso da quello della legacy (UI), i casi di test relativi all'interfaccia utente dovrebbero essere modificati per adattare il nuovo design. La decisione di aggiornare o scriverne di nuovi, in questo caso, può essere presa dal tester in base al volume di modifiche avvenute.

Test di compatibilità con le versioni precedenti

La migrazione del sistema richiede anche ai tester di verificare la 'Compatibilità con le versioni precedenti', in cui il nuovo sistema introdotto è compatibile con il vecchio sistema (almeno 2 versioni precedenti) e garantisce che funzioni perfettamente con quelle versioni.

La compatibilità con le versioni precedenti serve a garantire:

  1. Se il nuovo sistema supporta la funzionalità supportata nelle 2 versioni precedenti insieme a quella nuova.
  2. Il sistema può essere migrato con successo dalle precedenti 2 versioni senza problemi.

Pertanto è essenziale garantire la retrocompatibilità del sistema effettuando in modo specifico i test relativi alla compatibilità con il supporto. I test relativi alla compatibilità con le versioni precedenti devono essere progettati e inclusi nel documento Specifiche di test per l'esecuzione.

Test di rollback

In caso di problemi durante l'esecuzione della migrazione o se si verifica un errore di migrazione in qualsiasi momento durante la migrazione, dovrebbe essere possibile per il sistema eseguire il rollback al sistema legacy e riprendere la sua funzione rapidamente senza influire sugli utenti e la funzionalità supportata in precedenza.

Quindi, per verificare ciò, è necessario progettare scenari di test di errore di migrazione come parte del test negativo e il meccanismo di rollback deve essere testato. Anche il tempo totale necessario per tornare al sistema precedente deve essere registrato e riportato nei risultati del test.

Dopo il rollback, la funzionalità principale e l'estensione test di regressione (automatizzato) dovrebbe essere eseguito per garantire che la migrazione non abbia avuto alcun impatto e che il rollback abbia successo nel ripristinare il sistema legacy.

Report di riepilogo del test di migrazione

Il rapporto di sintesi del test dovrebbe essere prodotto dopo aver completato il test e dovrebbe coprire il rapporto sul riepilogo dei vari test / scenari effettuati come parte delle varie fasi della migrazione con lo stato del risultato (superato / non superato) e i registri del test.

Il tempo registrato per le seguenti attività deve essere chiaramente riportato:

  1. Tempo totale per la migrazione
  2. Tempo di inattività delle applicazioni
  3. Tempo impiegato per migrare 10000 record.
  4. Tempo impiegato per il rollback.

Oltre alle informazioni di cui sopra, possono essere riportate anche eventuali osservazioni / raccomandazioni.

Sfide nel test della migrazione dei dati

Le sfide affrontate in questo test riguardano principalmente i dati. Di seguito sono riportati alcuni nella lista:

# 1) Qualità dei dati:

È possibile che i dati utilizzati nell'applicazione precedente siano di scarsa qualità nell'applicazione nuova / aggiornata. In questi casi, la qualità dei dati deve essere migliorata per soddisfare gli standard aziendali.

Fattori come ipotesi, conversioni di dati dopo le migrazioni, dati inseriti nella stessa applicazione precedente non sono validi, scarsa analisi dei dati ecc. Porta a una scarsa qualità dei dati. Ciò si traduce in costi operativi elevati, maggiori rischi di integrazione dei dati e deviazione dallo scopo dell'attività.

# 2) Mancata corrispondenza dei dati:

I dati migrati dall'applicazione precedente a quella nuova / aggiornata potrebbero non corrispondere a quella nuova. Ciò può essere dovuto al cambiamento nel tipo di dati, nel formato di archiviazione dei dati, lo scopo per cui i dati vengono utilizzati può essere ridefinito.

Ciò si traduce in un enorme sforzo per modificare le modifiche necessarie per correggere i dati non corrispondenti o accettarli e apportare modifiche a tale scopo.

# 3) Perdita di dati:

I dati potrebbero andare persi durante la migrazione dall'applicazione precedente a quella nuova / aggiornata. Questo può essere con campi obbligatori o campi non obbligatori. Se i dati persi riguardano campi non obbligatori, il record sarà comunque valido e potrà essere aggiornato di nuovo.

Ma se i dati del campo obbligatorio vengono persi, il record stesso diventa nullo e non può essere ritirato. Ciò comporterà un'enorme perdita di dati e dovrebbe essere recuperato dal database di backup o dai registri di controllo se acquisito correttamente.

# 4) Volume dati:

Dati enormi che richiedono molto tempo per migrare entro il periodo di inattività dell'attività di migrazione. Per esempio: Gratta e vinci nel settore delle telecomunicazioni, utenti su una piattaforma di rete intelligente ecc., Qui la sfida è per il momento, i dati legacy vengono cancellati, verranno creati nuovi enormi dati, che devono essere migrati di nuovo. L'automazione è la soluzione per enormi migrazioni di dati.

# 5) Simulazione di un ambiente in tempo reale (con i dati effettivi):

La simulazione di un ambiente in tempo reale nel laboratorio di test è un'altra vera sfida, in cui i tester affrontano diversi tipi di problemi con i dati reali e il sistema reale, che non vengono affrontati durante i test.

Quindi, il campionamento dei dati, la replica dell'ambiente reale, l'identificazione del volume di dati coinvolti nella migrazione sono piuttosto importanti durante lo svolgimento del test di migrazione dei dati.

# 6) Simulazione del volume di dati:

I team devono studiare i dati nel sistema live con molta attenzione e dovrebbero elaborare l'analisi e il campionamento tipici dei dati.

Per esempio: utenti con fascia di età inferiore a 10 anni, 10-30 anni ecc., Per quanto possibile, è necessario ottenere i dati dal vivo, altrimenti la creazione dei dati deve essere eseguita nell'ambiente di test. È necessario utilizzare strumenti automatizzati per creare un grande volume di dati. Se il volume non può essere simulato, può essere utilizzata l'estrapolazione, ove applicabile.

Suggerimenti per attenuare i rischi della migrazione dei dati

Di seguito vengono forniti alcuni suggerimenti da eseguire per attenuare i rischi di migrazione dei dati:

  • Standardizzare i dati utilizzati nel sistema legacy, in modo che, una volta migrati, i dati standard saranno disponibili nel nuovo sistema
  • Migliora la qualità dei dati, in modo che durante la migrazione ci siano dati qualitativi da testare che diano la sensazione di eseguire il test come utente finale
  • Pulisci i dati prima della migrazione, in modo che quando migrati, i dati duplicati non saranno presenti nel nuovo sistema e anche questo mantiene pulito l'intero sistema
  • Ricontrolla i vincoli, le stored procedure, le query complesse che producono risultati accurati, in modo che, quando vengono migrati, vengano restituiti dati corretti anche nel nuovo sistema
  • Identificare lo strumento di automazione corretto per eseguire controlli dei dati / controlli dei record nel nuovo sistema rispetto al precedente.

Conclusione

Quindi considerando la complessità insita nello svolgimento del Test di Migrazione dei dati, tenendo presente che un piccolo errore in qualsiasi aspetto della verifica durante il test comporterà il rischio di fallimento della migrazione in produzione, è molto importante effettuare uno studio attento e approfondito e analisi del sistema prima e dopo la migrazione. Pianifica e progetta la strategia di migrazione efficace con strumenti affidabili insieme a tester esperti e formati.

Poiché sappiamo che la migrazione ha un impatto enorme sulla qualità dell'applicazione, l'intero team deve impegnarsi per verificare l'intero sistema in tutti gli aspetti come funzionalità, prestazioni, sicurezza, usabilità, disponibilità, affidabilità, compatibilità ecc., che a sua volta garantirà il successo dei 'test di migrazione'.

'Diversi tipi di migrazioni' ciò accade tipicamente abbastanza spesso nella realtà e le modalità per gestire i loro test saranno spiegate brevemente nel nostro prossimo tutorial di questa serie .

Riguardo agli Autori: Questa guida è stata scritta dall'autore STH Nandini. Ha più di 7 anni di esperienza nel test del software. Inoltre, grazie all'autore di STH Gayathri S. per la revisione e per aver fornito i suoi suggerimenti valubali per migliorare questa serie. Gayathri ha più di 18 anni di esperienza nello sviluppo di software e nei servizi di test.

Fateci sapere i vostri commenti / suggerimenti su questo tutorial.

Lettura consigliata

^