Meniu

Tutorial de testare a migrării datelor: un ghid complet

data migration testing tutorial

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

Prezentare generală a testării migrării datelor:

Se aude destul de des că o aplicație este mutată pe un alt server, tehnologia este schimbată, este actualizată la următoarea versiune sau mutată pe un server de baze de date diferite etc.,

  • Ce înseamnă asta de fapt?
  • Ce se așteaptă de la echipa de testare în aceste situații?

Din punct de vedere al testării, totul înseamnă că aplicația trebuie testată complet end-to-end împreună cu migrarea de la sistemul existent la noul sistem cu succes.

Tutoriale din această serie:

Testarea sistemului trebuie efectuată în acest caz cu toate datele, care sunt utilizate într-o aplicație veche și, de asemenea, cu datele noi. Funcționalitatea existentă trebuie verificată împreună cu funcționalitatea nouă / modificată.

Testarea migrării datelor

În loc de doar testarea migrării, poate fi denumită și testarea migrării datelor, în care toate datele utilizatorului vor fi migrate într-un sistem nou.

Deci, testarea migrării include testarea cu date vechi, date noi sau o combinație a ambelor, caracteristici vechi (caracteristici neschimbate) și caracteristici noi.

Aplicația veche este denumită de obicei „ moştenire Cerere. Împreună cu aplicația nouă / actualizată, este obligatoriu să continuați testarea aplicației vechi până când cele noi / actualizate devin stabile și consistente. Testul de migrare extins pe o nouă aplicație va dezvălui noile probleme care nu au fost găsite în aplicația veche.

Ce veți învăța:

Ce este testarea migrării?

Testarea migrării este un proces de verificare a migrării sistemului vechi către noul sistem cu întreruperi / perioade de nefuncționare minime, cu integritate a datelor și fără pierderi de date, asigurând în același timp că toate aspectele funcționale și nefuncționale specificate ale aplicației sunt îndeplinite după migrație.

Reprezentare simplă a sistemului de migrație:

Testarea migrației

De ce testul migrației?

După cum știm, migrarea aplicației către un nou sistem ar putea fi din diverse motive, consolidarea sistemului, tehnologia învechită, optimizarea sau orice alte motive.

Prin urmare, în timp ce sistemul în uz trebuie migrat către un nou sistem, este esențial să se asigure următoarele puncte:

  1. Orice fel de perturbare / inconvenient cauzat utilizatorului din cauza migrației trebuie evitat / minimizat. De exemplu: timpii morți, pierderea datelor
  2. Trebuie să vă asigurați că utilizatorul poate continua să utilizeze toate caracteristicile software-ului provocând daune minime sau deloc în timpul migrării. De exemplu: schimbarea funcționalității, eliminarea unei anumite funcționalități
  3. De asemenea, este important să anticipăm și să excludem toate problemele / obstacolele posibile care ar putea apărea în timpul migrației reale a sistemului viu.

Prin urmare, pentru a asigura o migrare lină a sistemului activ prin eliminarea acestor defecte, este esențial să se efectueze teste de migrare în laborator.

Acest test are propria importanță și joacă un rol vital atunci când datele apar în imagine.

Din punct de vedere tehnic, este necesar, de asemenea, să fie executat în următoarele scopuri:

  • Pentru a asigura compatibilitatea aplicației noi / actualizate cu toate componentele hardware și software posibile acceptate de aplicația veche. De asemenea, nou compatibilitate ar trebui să fie testat pentru hardware nou, platformă software, de asemenea.
  • Pentru a vă asigura că toate funcționalitățile existente funcționează ca în aplicația veche. Nu ar trebui să existe nicio schimbare în modul în care funcționează aplicația în comparație cu cea veche.
  • Posibilitatea unui număr mare de defecte datorate migrației este foarte mare. Multe dintre defecte vor fi de obicei legate de date și, prin urmare, aceste defecte trebuie identificate și remediate în timpul testării.
  • Pentru a vă asigura dacă timpul de răspuns al sistemului pentru aplicația nouă / actualizată este același sau mai mic decât este necesar pentru aplicația veche.
  • Pentru a vă asigura că conexiunea dintre servere, hardware, software etc. sunt intacte și nu se întrerupe în timpul testării. Fluxul de date între diferite componente nu trebuie să se întrerupă în nicio condiție.

Când este necesar acest test?

Testarea trebuie efectuată atât înainte, cât și după migrare.

Diferitele faze ale testului de migrare care urmează să fie efectuate la laboratorul de testare pot fi clasificate ca mai jos.

  1. Testarea pre-migrare
  2. Testarea migrației
  3. Testarea după migrare

Pe lângă cele de mai sus, sunt executate și următoarele teste ca parte a întregii activități de migrație.

  1. Verificarea compatibilității înapoi
  2. Testare de revenire

Înainte de a efectua acest test, este esențial ca orice tester să înțeleagă clar punctele de mai jos:

  1. Modificările care au loc ca parte a noului sistem (server, front end, DB, schemă, flux de date, funcționalitate etc.)
  2. Pentru a înțelege strategia de migrație propusă de echipă. Cum se întâmplă migrarea, schimbări pas cu pas care se întâmplă în backend-ul sistemului și scripturile responsabile de aceste modificări.

Prin urmare, este esențial să se facă un studiu amănunțit al vechiului și noului sistem și apoi să planifice și să proiecteze în consecință cazurile de testare și scenariile de testare care să fie acoperite ca parte a fazelor de testare de mai sus și să pregătească strategia de testare.

Strategia de testare a migrării datelor

Proiectarea strategiei de testare a migrației include un set de activități care trebuie efectuate și câteva aspecte care trebuie luate în considerare. Aceasta este pentru a minimiza erorile și riscurile care apar ca urmare a migrației și pentru a efectua testarea migrației în mod eficient.

Activități în cadrul acestui test:

# 1) Formarea specializată a echipei :

Formați echipa de testare cu membrii care au cunoștințele și experiența necesare și oferiți instruire legată de sistemul care este migrat.

#Două) Analiza riscului de afaceri, analiza posibilelor erori :

Activitatea actuală nu ar trebui să fie împiedicată după migrare și, prin urmare, să desfășoare „ Analiza riscului de afaceri ” întâlniri care implică părțile interesate potrivite (test manager, analist de afaceri, arhitecți, proprietari de produse, proprietar de afaceri etc.) și identifică riscurile și atenuările implementabile. Testarea ar trebui să includă scenarii pentru a descoperi aceste riscuri și pentru a verifica dacă au fost implementate atenuări adecvate.

Conduce ' Analiza posibilă a erorilor ” folosind adecvat „Eroare ghicind abordări” și apoi proiectați teste în jurul acestor erori pentru a le dezgropa în timpul testării.

testarea beta este ultima fază a procesului de testare.

# 3) Analiza și identificarea domeniului migrației:

Analizați domeniul de aplicare clar al testului de migrare ca atunci când și ce trebuie testat.

# 4) Identificați instrumentul adecvat pentru migrație:

În timp ce definiți strategia acestui test, automat sau manual, identificați instrumentele care urmează să fie utilizate. De exemplu: Instrument automat pentru compararea datelor sursă și destinație.

# 5) Identificați mediul de testare adecvat pentru migrare:

Identificați medii separate pentru mediile pre și post migrare pentru a efectua orice verificare care este necesară ca parte a testării. Înțelegeți și documentați aspectele tehnice ale sistemului vechi și nou al migrației, pentru a vă asigura că mediul de testare este configurat în conformitate cu aceasta.

# 6) Documentul de specificații al testului de migrare și revizuirea:

Pregătiți documentul cu specificațiile testului de migrare care descrie clar abordarea testului, domeniile de testare, metodele de testare (automatizate, manuale), metodologia de testare (caseta neagră, tehnica de testare a cutiei albe ), Numărul de cicluri de testare, programul de testare, abordarea creării datelor și utilizarea datelor live (informațiile sensibile trebuie mascate), specificațiile mediului de testare, calificarea testerilor etc. și organizarea unei sesiuni de revizuire cu părțile interesate.

# 7) Lansarea în producție a sistemului migrat :

Analizați și documentați lista de sarcini pentru migrarea producției și publicați-o cu mult timp în avans

Diferite etape ale migrației

Mai jos sunt prezentate diferitele faze ale migrației.

Faza 1:Testarea pre-migrare

Înainte de migrarea datelor, un set de activități de testare sunt efectuate ca parte a fazei de testare pre-migrare. Acest lucru este ignorat sau nu este luat în considerare în aplicațiile mai simple. Dar atunci când aplicațiile complexe urmează să fie migrate, activitățile de pre-migrare sunt obligatorii.

Mai jos este lista acțiunilor întreprinse în această fază:

  • Setați un domeniu clar al datelor - ce date trebuie incluse, ce date trebuie excluse, ce date necesită transformări / conversii etc.
  • Efectuați maparea datelor între aplicația moștenită și noua aplicație - pentru fiecare tip de date din aplicația moștenită comparați tipul său relevant în noua aplicație și apoi mapați-le - Mapare la nivel superior.
  • Dacă noua aplicație are câmpul obligatoriu, dar nu este cazul în moștenire, apoi asigurați-vă că moștenirea nu are acel câmp ca nul. - Cartografiere la nivel inferior.
  • Studiați schema de date a noii aplicații - numele câmpurilor, tipurile, valorile minime și maxime, lungimea, câmpurile obligatorii, validările la nivel de câmp etc., în mod clar
  • Un număr de tabele din sistemul vechi trebuie notate și dacă tabelele sunt abandonate și adăugate după migrare trebuie verificate.
  • Un număr de înregistrări în fiecare tabel, vizualizările trebuie notate în aplicația veche.
  • Studiați interfețele din noua aplicație și conexiunile acestora. Datele care curg în interfață ar trebui să fie foarte securizate și să nu fie defecte.
  • Pregătiți cazuri de testare, scenarii de testare și cazuri de utilizare pentru condiții noi în noile aplicații.
  • Executați un set de cazuri de testare, scenarii cu un set de utilizatori și păstrați rezultatele, jurnalele stocate. Același lucru trebuie verificat după migrare pentru a ne asigura că datele și funcționalitatea vechi sunt intacte.
  • Numărul de date și înregistrări trebuie notat în mod clar, trebuie verificat după migrare pentru a nu pierde date.

Faza 2:Testarea migrației

' Ghid de migrație ”care este pregătit de echipa de migrație trebuie să fie strict respectat pentru a desfășura activitatea de migrație. În mod ideal, activitatea de migrare începe cu backupul datelor pe bandă, astfel încât, oricând, sistemul vechi să poată fi restaurat.

Verificarea părții de documentare din „ Ghidul de migrare ”face parte, de asemenea, din testarea migrării datelor . Verificați dacă documentul este clar și ușor de urmărit. Toate scripturile și pașii trebuie să fie documentați corect, fără nicio ambiguitate. Orice tip de erori de documentare, meciuri ratate în ordinea executării pașilor trebuie, de asemenea, considerate importante, astfel încât să poată fi raportate și remediate.

Scripturile de migrare, ghidul și alte informații legate de migrarea reală trebuie preluate din depozitul de control al versiunii pentru executare.

Unul dintre cazurile de testare care trebuie executat și, prin urmare, este să noteze timpul efectiv necesar pentru migrare de la punctul de pornire a migrării până la restaurarea cu succes a sistemului. „Timpul necesar pentru migrarea sistemului” trebuie să fie înregistrat în raportul final de testare, care va fi livrat ca parte a rezultatelor testului de migrare și aceste informații vor fi utile în timpul lansării producției. Timpul de nefuncționare înregistrat în mediul de testare este extrapolat pentru a calcula timpul de oprire aproximativ în sistemul live.

Activitatea de migrație se va desfășura pe sistemul moștenit.

În timpul acestei testări, toate componentele mediului vor fi de obicei coborâte și eliminate din rețea pentru a desfășura activitățile de migrare. Prin urmare, este necesar să se noteze „Inactivitate” necesar pentru testul de migrare. În mod ideal, va fi același cu cel al timpului de migrare.

În general, activitatea de migrare definită în documentul „Ghid de migrare” include:

  • Migrarea efectivă a aplicației
  • Firewall-urile, portul, gazdele, hardware-ul, configurațiile software sunt toate modificate conform noului sistem pe care se migrează moștenirea
  • Se efectuează scurgeri de date, verificări de securitate
  • Conectivitatea dintre toate componentele aplicației este verificată

Este recomandabil ca testerii să verifice cele de mai sus în backend-ul sistemului sau efectuând teste cu cutie albă.

Odată ce activitatea de migrare specificată în ghid este finalizată, toate serverele sunt lansate și se vor efectua teste de bază legate de verificarea migrării cu succes, ceea ce asigură conectarea corespunzătoare a tuturor sistemelor de la capăt la cap și că toate componentele vorbesc cu fiecare altul, DB este în funcțiune, front-end comunică cu back-end-ul cu succes. Aceste teste trebuie identificate mai devreme și înregistrate în documentul Specificație test de migrare.

Există posibilități ca software-ul să accepte mai multe platforme diferite. În acest caz, migrarea trebuie verificată separat pe fiecare dintre aceste platforme.

Verificarea scripturilor de migrare va face parte din testul de migrare. Uneori, scriptul de migrare individual este, de asemenea, verificat folosind „Testarea cutiei albe” într-un mediu de testare independent.

Prin urmare, testarea migrației va fi o combinație atât de „testare cutie albă, cât și testare cutie neagră”.

Odată ce această verificare legată de migrație este efectuată și testele corespunzătoare sunt trecute, echipa poate continua cu activitatea de testare post-migrare.

Faza # 3:Testarea după migrare

Odată ce aplicația este migrată cu succes, testele post-migrare intră în imagine.

Aici testarea sistemului de la cap la cap se efectuează în mediul de testare. Testerii execută cazuri de testare identificate, scenarii de testare, cazuri de utilizare cu date vechi, precum și un nou set de date.

În plus față de acestea, există elemente specifice care trebuie verificate în mediile migrate, care sunt enumerate mai jos:

Toate acestea sunt documentate ca un caz de testare și sunt incluse în documentul „Specificații de testare”.

  1. Verificați dacă toate datele din moștenire sunt migrate către noua aplicație în timpul de nefuncționare planificat. Pentru a asigura acest lucru, comparați numărul de înregistrări dintre moștenirea și noua aplicație pentru fiecare tabel și vizualizări din baza de date. De asemenea, raportați timpul necesar mutării, spuneți 10000 înregistrări.
  2. Verificați dacă toate modificările schemei (câmpuri și tabele adăugate sau eliminate) conform noului sistem sunt actualizate.
  3. Datele migrate de la moștenirea la aplicația nouă ar trebui să își păstreze valoarea și formatul, cu excepția cazului în care nu este specificat să facă acest lucru. Pentru a asigura acest lucru, comparați valorile datelor între vechea și baza de date a noii aplicații.
  4. Testați datele migrate cu noua aplicație. Aici acoperiți un număr maxim de cazuri posibile. Pentru a asigura o acoperire de 100% în ceea ce privește verificarea migrării datelor, utilizați instrumentul de testare automată.
  5. Verificați securitatea bazei de date.
  6. Verificați integritatea datelor pentru toate înregistrările probe posibile.
  7. Verificați și asigurați-vă că funcționalitatea acceptată anterior în sistemul vechi funcționează așa cum era de așteptat în noul sistem.
  8. Verificați fluxul de date din aplicație care acoperă majoritatea componentelor.
  9. Interfața dintre componente ar trebui să fie testată extensiv, deoarece datele nu ar trebui modificate, pierdute și corupte atunci când acestea trec prin componente. Cazurile de testare a integrării pot fi utilizate pentru a verifica acest lucru.
  10. Verificați dacă sunt redundante datele vechi. Nicio dată veche nu ar trebui să fie duplicată ea însăși în timpul migrării
  11. Verificați cazurile de nepotrivire a datelor, cum ar fi modificarea tipului de date, modificarea formatului de stocare etc.,
  12. Toate verificările la nivel de teren din aplicația veche ar trebui să fie acoperite și în noua aplicație
  13. Orice adăugare de date în noua aplicație nu ar trebui să se reflecte asupra moștenirii
  14. Actualizarea datelor vechi ale aplicației prin noua aplicație ar trebui să fie acceptată. Odată actualizat în noua aplicație, nu ar trebui să se reflecte asupra moștenirii.
  15. Ștergerea datelor aplicației vechi din noua aplicație ar trebui să fie acceptată. Odată șters în noua aplicație, nu ar trebui să șteargă și datele din moștenire.
  16. Verificați dacă modificările aduse sistemului vechi acceptă noua funcționalitate livrată ca parte a noului sistem.
  17. Verificați dacă utilizatorii din sistemul vechi pot continua să utilizeze atât funcționalitatea veche, cât și funcționalitatea nouă, în special cele în care sunt implicate modificările. Executați cazurile de testare și rezultatele testelor stocate în timpul testului de pre-migrare.
  18. Creați utilizatori noi pe sistem și efectuați teste pentru a vă asigura că funcționalitatea din moștenire, precum și noua aplicație, acceptă utilizatorii nou creați și funcționează bine.
  19. Efectuați teste legate de funcționalitate cu o varietate de eșantioane de date (grupe de vârstă diferite, utilizatori din diferite regiuni etc.)
  20. De asemenea, este necesar să verificați dacă „Semnalizatori de funcții” sunt activate pentru noile caracteristici și activarea / dezactivarea acesteia permite activarea și dezactivarea funcțiilor.
  21. Testarea performanței este importantă pentru a se asigura că migrarea către un nou sistem / software nu a degradat performanța sistemului.
  22. De asemenea, este necesar să efectuați teste de sarcină și solicitare pentru a asigura stabilitatea sistemului.
  23. Verificați dacă actualizarea software-ului nu a deschis nicio vulnerabilitate de securitate și, prin urmare, efectuați teste de securitate, în special în zona în care au fost aduse modificări sistemului în timpul migrării.
  24. Utilizarea este un alt aspect care urmează să fie verificat, în cazul în care aspectul GUI / sistemul front-end s-a schimbat sau orice funcționalitate s-a schimbat, care este ușurința de utilizare pe care o simte utilizatorul final în comparație cu sistemul vechi.

Deoarece domeniul de aplicare al testării post-migrare devine foarte mare, este ideal să separați testele importante care trebuie făcute mai întâi pentru a califica faptul că migrarea are succes și apoi pentru a efectua restul mai târziu.

De asemenea, se recomandă automatizarea cazurilor de test funcțional cap la cap și a altor posibile cazuri de testare, astfel încât timpul de testare să poată fi redus și rezultatele să fie disponibile rapid.

Câteva sfaturi pentru testeri pentru scrierea testelor pentru execuția post-migrare:

  • Când aplicația este migrată, nu înseamnă că cazurile de testare trebuie scrise pentru întreaga nouă aplicație. Testele deja concepute pentru moștenire ar trebui să fie valabile pentru noua aplicație. Deci, pe cât posibil, utilizați vechile cazuri de testare și convertiți cazurile de testare vechi în cazurile unei noi aplicații ori de câte ori este necesar.
  • Dacă există o modificare a funcției în noua aplicație, atunci cazurile de testare legate de caracteristică ar trebui modificate.
  • Dacă există o caracteristică nouă adăugată în noua aplicație, ar trebui concepute noi cazuri de testare pentru acea caracteristică specială.
  • Atunci când noua aplicație are o caracteristică scăzută, cazurile de test ale aplicației vechi conexe nu ar trebui luate în considerare pentru executarea după migrare și ar trebui marcate ca nevalide și ținute la distanță.
  • Testele proiectate trebuie să fie întotdeauna fiabile și coerente în ceea ce privește utilizarea. Verificarea datelor critice ar trebui să fie acoperită în cazurile de testare, astfel încât să nu fie ratate în timpul executării.
  • Când designul noii aplicații este diferit de cel al modelului vechi (UI), atunci cazurile de test legate de UI ar trebui modificate pentru a adapta noul design. Decizia de a actualiza sau de a scrie altele noi, în acest caz, poate fi luată de tester pe baza volumului de schimbare care a avut loc.

Testarea compatibilității înapoi

Migrarea sistemului solicită, de asemenea, ca testerii să verifice „Compatibilitatea înapoi”, în care noul sistem introdus este compatibil cu vechiul sistem (cel puțin 2 versiuni anterioare) și se asigură că funcționează perfect cu acele versiuni.

Compatibilitatea inversă este de a asigura:

  1. Dacă noul sistem acceptă funcționalitatea acceptată în cele 2 versiuni anterioare împreună cu cea nouă.
  2. Sistemul poate fi migrat cu succes din cele 2 versiuni anterioare fără probleme.

Prin urmare, este esențial să se asigure compatibilitatea inversă a sistemului prin efectuarea specifică a testelor legate de compatibilitatea inversă. Testele legate de compatibilitatea cu versiunile anterioare trebuie proiectate și incluse în documentul cu specificațiile de testare pentru executare.

Testare de revenire

În cazul oricăror probleme în timpul efectuării migrației sau dacă există un eșec de migrare în orice moment al migrației, atunci ar trebui să fie posibil ca sistemul să revină la sistemul vechi și să-și reia funcția rapid fără a afecta utilizatorii și funcționalitatea acceptată anterior.

Deci, pentru a verifica acest lucru, scenariile de testare a eșecului migrării trebuie proiectate ca parte a testării negative și mecanismul de revenire trebuie testat. Timpul total necesar pentru a reveni la sistemul vechi trebuie, de asemenea, să fie înregistrat și raportat în rezultatele testului.

După revenire, funcționalitatea principală și fișierul testare de regresie (automată) ar trebui să fie executat pentru a se asigura că migrația nu a afectat nimic și retrocedarea are succes în readucerea sistemului vechi în loc.

Raport sumar test de migrare

Raportul rezumat al testului ar trebui să fie produse după finalizarea testării și ar trebui să acopere raportul privind rezumatul diferitelor teste / scenarii efectuate ca parte a diferitelor faze ale migrației cu starea rezultatului (trecere / eșuare) și jurnalele de testare.

Timpul înregistrat pentru următoarele activități trebuie raportat clar:

  1. Timp total pentru migrare
  2. Timpul oprit al aplicațiilor
  3. Timpul petrecut pentru a migra 10000 de înregistrări.
  4. Timpul petrecut pentru restabilire.

În plus față de informațiile de mai sus, pot fi raportate și orice observații / recomandări.

Provocări în testarea migrării datelor

Provocările cu care se confruntă aceste teste sunt în principal date. Mai jos sunt câteva în listă:

# 1) Calitatea datelor:

Este posibil să constatăm că datele utilizate în aplicația veche sunt de calitate slabă în aplicația nouă / actualizată. În astfel de cazuri, calitatea datelor trebuie îmbunătățită pentru a respecta standardele comerciale.

Factori precum ipotezele, conversia datelor după migrări, datele introduse în aplicația veche nu sunt valide, analiza slabă a datelor etc. duce la o calitate slabă a datelor. Acest lucru are ca rezultat costuri operaționale ridicate, riscuri crescute de integrare a datelor și abateri de la scopul afacerii.

# 2) Nepotrivirea datelor:

Datele migrate de la moștenirea la aplicația nouă / actualizată pot fi găsite nepotrivite în cea nouă. Acest lucru se poate datora schimbării tipului de date, formatului de stocare a datelor, scopul pentru care datele sunt utilizate poate fi redefinit.

Acest lucru are ca rezultat un efort uriaș de modificare a modificărilor necesare, fie pentru a corecta datele nepotrivite, fie pentru a le accepta și a le modifica în acest scop.

# 3) Pierderea datelor:

Este posibil ca datele să fie pierdute în timp ce migrați de la moștenirea la aplicația nouă / actualizată. Aceasta poate fi cu câmpuri obligatorii sau câmpuri neobligatorii. Dacă datele pierdute sunt pentru câmpuri neobligatorii, atunci înregistrarea pentru acestea va fi în continuare valabilă și poate fi actualizată din nou.

Dar dacă datele câmpului obligatoriu se pierd, atunci înregistrarea însăși devine nulă și nu poate fi retrasă. Acest lucru va duce la pierderi uriașe de date și ar trebui să fie recuperate fie din baza de date de rezervă, fie din jurnalele de audit, dacă sunt capturate corect.

# 4) Volumul datelor:

Date imense care necesită mult timp pentru a migra în fereastra de nefuncționare a activității de migrare. De exemplu: Cartele cu zgârieturi în industria telecomunicațiilor, utilizatorii de pe o platformă de rețea inteligentă etc., aici provocarea este până la momentul respectiv, datele vechi sunt șterse, vor fi create noi date imense, care trebuie migrate din nou. Automatizarea este soluția pentru migrarea imensă a datelor.

# 5) Simularea unui mediu în timp real (cu datele reale):

Simularea unui mediu în timp real în laboratorul de testare este o altă provocare reală, în care testerii intră în diferite tipuri de probleme cu datele reale și sistemul real, care nu se confruntă în timpul testării.

cum se face un program ddos

Deci, eșantionarea datelor, replicarea mediului real, identificarea volumului de date implicate în migrație este destul de importantă în timpul efectuării testării migrării datelor.

# 6) Simularea volumului de date:

Echipele trebuie să studieze datele din sistemul live foarte atent și ar trebui să vină cu analiza și eșantionarea tipică a datelor.

De exemplu: utilizatorii cu grupa de vârstă sub 10 ani, 10-30 ani etc., În măsura posibilului, trebuie obținute date din live, dacă nu, crearea datelor trebuie făcută în mediul de testare. Instrumentele automate trebuie utilizate pentru a crea un volum mare de date. Extrapolarea, ori de câte ori este cazul, poate fi utilizată, dacă volumul nu poate fi simulat.

Sfaturi pentru a atenua riscurile de migrare a datelor

Mai jos sunt prezentate câteva sfaturi care trebuie realizate pentru a atenua riscurile de migrare a datelor:

  • Standardizați datele utilizate în sistemul vechi, astfel încât, atunci când sunt migrate, datele standard să fie disponibile în noul sistem
  • Îmbunătățiți calitatea datelor, astfel încât, atunci când sunt migrați, există date calitative de testat, oferind senzația de testare ca utilizator final
  • Curățați datele înainte de migrare, astfel încât atunci când sunt migrate, datele duplicate să nu fie prezente în noul sistem și, de asemenea, să păstreze întregul sistem curat
  • Verificați din nou constrângerile, procedurile stocate, interogările complexe care dau rezultate exacte, astfel încât atunci când sunt migrate, datele corecte să fie returnate și în noul sistem
  • Identificați instrumentul de automatizare corect pentru a efectua verificări de date / verificări de înregistrare în noul sistem în comparație cu moștenirea.

Concluzie

Prin urmare, având în vedere complexitatea implicată în efectuarea testării migrării datelor, ținând cont de faptul că o mică lipsă a oricărui aspect al verificării în timpul testării va duce la riscul eșecului migrării la producție, este foarte important să efectuați un studiu atent și amănunțit. & analiza sistemului înainte și după migrare. Planificați și proiectați strategia eficientă de migrare cu instrumente robuste, împreună cu testeri calificați și instruiți.

Deoarece știm că Migrarea are un impact uriaș asupra calității aplicației, întreaga echipă trebuie să depună eforturi bune pentru a verifica întregul sistem în toate aspectele, cum ar fi funcționalitatea, performanța, securitatea, utilizabilitatea, disponibilitatea, fiabilitatea, compatibilitatea etc., care la rândul său vor asigura „testarea migrării” cu succes.

„Diferite tipuri de migrații” care de obicei se întâmplă destul de des în realitate și modalitățile de gestionare a testării lor vor fi explicate pe scurt în documentul nostru următorul tutorial din această serie .

Despre autori: Acest ghid este scris de autorul STH Nandini. Are peste 7 ani de experiență în testarea software-ului. De asemenea, mulțumim autorului STH Gayathri S. pentru revizuirea și furnizarea de sugestii valubale pentru îmbunătățirea acestei serii. Gayathri are peste 18 ani de experiență în dezvoltarea de software și servicii de testare.

Spuneți-ne comentariile / sugestiile dvs. despre acest tutorial.

Lectură recomandată

^