Meny

Data Migration Testing Tutorial: A Complete Guide

data migration testing tutorial

Prøv Instrumentet Vårt For Å Eliminere Problemer

Oversikt over datamigreringstesting:

Det høres ofte at et program blir flyttet til en annen server, teknologien endres, den oppdateres til neste versjon eller flyttes til en annen databaseserver osv.,

  • Hva betyr dette egentlig?
  • Hva forventes av testteamet i disse situasjonene?

Fra testperspektivet betyr alt at applikasjonen må testes grundig ende-til-ende sammen med migrering fra det eksisterende systemet til det nye systemet.

Opplæringsprogrammer i denne serien:

Systemtesting må i dette tilfellet utføres med alle dataene som brukes i en gammel applikasjon og de nye dataene også. Eksisterende funksjonalitet må verifiseres sammen med den nye / modifiserte funksjonaliteten.

Testing av datamigrering

I stedet for bare Migration Testing, kan det også betegnes som Data Migration Testing, der hele dataene til brukeren blir migrert til et nytt system.

Så migrasjonstesting inkluderer testing med gamle data, nye data eller en kombinasjon av begge, gamle funksjoner (uendrede funksjoner) og de nye funksjonene.

Gammel applikasjon blir vanligvis betegnet som ‘ arv ' applikasjon. Sammen med ny / oppgradert applikasjon er det også obligatorisk å fortsette å teste eldre applikasjoner til de nye / oppgraderte blir stabile og konsistente. Omfattende migrasjonstest på ny applikasjon vil avdekke de nye problemene som ikke ble funnet i den eldre applikasjonen.

Hva du vil lære:

Hva er migrasjonstesting?

Migration Testing er en verifiseringsprosess for migrering av det eldre systemet til det nye systemet med minimal forstyrrelse / nedetid, med dataintegritet og uten tap av data, samtidig som det sikres at alle de spesifiserte funksjonelle og ikke-funksjonelle aspektene ved applikasjonen blir oppfylt etter migrasjon.

Enkel representasjon av migrasjonssystem:

Migrasjonstesting

Hvorfor migrasjonstest?

Som vi vet kan applikasjonsmigrering til et nytt system være av forskjellige årsaker, systemkonsolidering, foreldet teknologi, optimalisering eller andre grunner.

Derfor, mens systemet i bruk må overføres til et nytt system, er det viktig å sikre følgende punkter:

  1. Enhver form for forstyrrelse / ulempe som er forårsaket av brukeren på grunn av migrering, må unngås / minimeres. F.eks .: nedetid, tap av data
  2. Må sørge for om brukeren kan fortsette å bruke alle funksjonene i programvaren ved å forårsake minimal eller ingen skade under migrering. F.eks .: endring i funksjonaliteten, fjerning av en bestemt funksjonalitet
  3. Det er også viktig å forutse og utelukke alle mulige feil / hindringer som kan oppstå under selve migrasjonen av det levende systemet.

Derfor, for å sikre en jevn migrering av det levende systemet ved å eliminere disse feilene, er det viktig å utføre migrasjonstesting i laboratoriet.

Denne testen har sin egen betydning, og den spiller en viktig rolle når dataene kommer inn i bildet.

Teknisk sett er det også nødvendig å utføres for følgende formål:

  • For å sikre kompatibilitet for det nye / oppgraderte programmet med all mulig maskinvare og programvare som den eldre applikasjonen støtter. Også nytt kompatibilitet bør testes for ny maskinvare, programvareplattform også.
  • For å sikre at alle eksisterende funksjoner fungerer som i den eldre applikasjonen. Det skal ikke være noen endring i måten applikasjonen fungerer i forhold til den eldre.
  • Muligheten for et stort antall feil på grunn av migrasjon er veldig høy. Mange av manglene vil vanligvis være relatert til data, og derfor må disse feilene identifiseres og løses under testing.
  • For å sikre om systemets responstid for den nye / oppgraderte applikasjonen er den samme eller mindre enn det som kreves for den eldre applikasjonen.
  • For å sikre at forbindelsen mellom servere, maskinvare, programvare etc. er intakt og ikke brytes under testing. Dataflyt mellom forskjellige komponenter skal ikke bryte under noen forhold.

Når er denne testen påkrevd?

Testing må utføres både før og etter migrering.

De forskjellige fasene av migrasjonstesten som skal utføres på Test Lab kan klassifiseres som nedenfor.

  1. Testing før migrasjon
  2. Migrasjonstesting
  3. Testing etter migrasjon

I tillegg til ovennevnte, følgende tester blir også utført som en del av hele migrasjonsaktiviteten.

  1. Bakoverkompatibilitetsbekreftelse
  2. Tilbakestillingstesting

Før du utfører denne testen, er det viktig for enhver tester å forstå de følgende punktene tydelig:

  1. Endringene som skjer som en del av det nye systemet (server, frontend, DB, skjema, dataflyt, funksjonalitet osv.,)
  2. For å forstå den faktiske migrasjonsstrategien som er lagt ut av teamet. Hvordan migrasjonen skjer, trinnvise endringer som skjer i systemets bakside og skriptene som er ansvarlige for disse endringene.

Derfor er det viktig å gjøre en grundig studie av det gamle og det nye systemet, og deretter planlegge og utforme testtilfellene og testscenariene som skal dekkes som en del av testfasen og utarbeide teststrategien.

Strategi for testing av datamigrering

Utformingen av teststrategien for migrasjon inkluderer et sett med aktiviteter som skal utføres og få aspekter som skal vurderes. Dette er for å minimere feil og risikoer som oppstår som et resultat av migrasjon og for å utføre migreringstesting effektivt.

Aktiviteter i denne testingen:

#1) Spesialisert lagdannelse :

Dann testteamet med medlemmene som har den nødvendige kunnskapen og erfaring og gi opplæring relatert til systemet som blir migrert.

#to) Forretningsrisikoanalyse, mulig feilanalyse :

Nåværende virksomhet skal ikke hindres etter migrering og dermed utføre Analyse av forretningsrisiko ’ møter som involverer de rette interessentene (testleder, forretningsanalytiker, arkitekter, produkteiere, forretningseiere osv.), og identifiserer risikoen og de implementerbare begrensningene. Testingen bør omfatte scenarier for å avdekke disse risikoene og verifisere om riktige avbøtninger er implementert.

Oppførsel ' Mulig feilanalyse ’ bruker passende ‘Feilsøkte tilnærminger’ og design deretter tester rundt disse feilene for å avdekke dem under testing.

best safe youtube to mp3 converter

# 3) Migrasjonsomfangsanalyse og identifikasjon:

Analyser det tydelige omfanget av migrasjonstesten som når og hva som må testes.

# 4) Identifiser riktig verktøy for migrasjon:

Mens du definerer strategien for denne testingen, automatisk eller manuell, identifiser du verktøyene som skal brukes. F.eks .: Automatisert verktøy for å sammenligne kilde- og destinasjonsdata.

# 5) Identifiser passende testmiljø for migrasjon:

Identifiser separate miljøer for miljøer før og etter migrering for å utføre enhver bekreftelse som er nødvendig som en del av testingen. Forstå og dokumentere de tekniske aspektene ved Legacy and New Migration-systemet, for å sikre at testmiljøet er satt opp i henhold til det.

# 6) Spesifikasjonsdokument for migrasjonstest og gjennomgang:

Forbered migrasjonstest Spesifikasjonsdokument som tydelig beskriver testtilnærmingen, testområder, testmetoder (automatisert, manuell), testmetodikk (svart boks, testboksteknikk for hvit boks ), Antall sykluser med testing, tidsplan for testing, tilnærming for å lage data og bruke live data (sensitiv info må maskeres), testmiljøspesifikasjon, testerkvalifisering etc., og kjøre en gjennomgangssession med interessentene.

# 7) Produksjonslansering av det migrerte systemet :

Analyser og dokumenter oppgavelisten for produksjonsmigrering og publiser den i god tid

Ulike migrasjonsfaser

Nedenfor er de forskjellige faser av migrasjon.

Fase 1:Testing før migrasjon

Før migrering av dataene utføres testaktiviteter som en del av testfasen før migrering. Dette blir ignorert eller ikke vurdert i enklere applikasjoner. Men når komplekse applikasjoner skal overføres, er aktiviteter før migrering et must.

Nedenfor er listen over handlinger som blir tatt opp i denne fasen:

  • Sett et klart omfang av dataene - hvilke data som må inkluderes, hvilke data som må ekskluderes, hvilke data som trenger transformasjoner / konverteringer etc.
  • Utfør datakartlegging mellom eldre og den nye applikasjonen - for hver type data i den eldre applikasjonen, sammenlign den relevante typen i den nye applikasjonen, og kartlegg dem deretter - Kartlegging på høyere nivå.
  • Hvis den nye applikasjonen har det obligatoriske feltet, og men det ikke er tilfellet i arven, og sørg for at arven ikke har feltet som null. - Kartlegging på lavere nivå.
  • Studer det nye applikasjonens dataskjema - feltnavn, typer, minimums- og maksimumsverdier, lengde, obligatoriske felt, feltnivåvalidering osv., Tydelig
  • En rekke tabeller i det eldre systemet skal noteres, og hvis noen tabeller blir droppet, og tilføyde migrering av posten må bekreftes.
  • Et antall poster i hver tabell, visninger bør noteres i den eldre applikasjonen.
  • Studer grensesnittene i den nye applikasjonen og deres forbindelser. Data som flyter i grensesnittet skal være svært sikret og ikke ødelagt.
  • Forbered testsaker, testscenarier og bruk saker for nye forhold i de nye applikasjonene.
  • Utfør et sett med testtilfeller, scenarier med et sett med brukere og hold resultatene, loggene lagret. Det samme må verifiseres etter overføring for å sikre at eldre data og funksjonalitet er intakte.
  • Antall data og poster skal noteres tydelig, det må verifiseres etter migrering uten tap av data.

Fase 2:Migrasjonstesting

' Migration Guide ’som er utarbeidet av migrasjonsteamet må følges nøye for å utføre migrasjonsaktiviteten. Ideelt sett begynner migreringsaktiviteten med at dataene sikkerhetskopieres på båndet, slik at det eldre systemet kan gjenopprettes når som helst.

Bekrefte dokumentasjonsdelen av ‘ Migration Guide ’er også en del av data Migration Testing . Kontroller om dokumentet er oversiktlig og enkelt å følge. Alle skriptene og trinnene må dokumenteres riktig uten tvetydighet. Enhver form for dokumentasjonsfeil, glipp av treff i rekkefølgen for utførelse av trinn må også vurderes som viktig slik at de kan rapporteres og fikses.

Migrasjonsskript, veiledning og annen informasjon relatert til faktisk migrering må hentes fra versjonskontrolldatabasen for kjøring.

Å notere den faktiske tiden det tar for migrering fra startpunktet for migrering til vellykket restaurering av systemet, er en av testsakene som skal utføres, og derav 'Det tar tid å migrere systemet' må registreres i den endelige testrapporten som vil bli levert som en del av Migration-testresultatene, og denne informasjonen vil være nyttig under produksjonslanseringen. Nedetid registrert i testmiljøet ekstrapoleres for å beregne den omtrentlige nedetiden i live-systemet.

Det er på det eldre systemet der migrasjonsaktiviteten skal utføres.

Under denne testingen vil alle komponentene i miljøet vanligvis bli brakt ned og fjernet fra nettverket for å utføre migrasjonsaktivitetene. Derfor er det nødvendig å merke seg 'Nedetid' kreves for migrasjonstest. Ideelt sett vil det være det samme som for migrasjonstiden.

Generelt inkluderer migrasjonsaktivitet som er definert i dokumentet 'Migreringsguide':

  • Faktisk overføring av søknaden
  • Brannmurer, port, verter, maskinvare, programvarekonfigurasjoner er alle endret i henhold til det nye systemet som arven blir migrert på
  • Datalekkasje, sikkerhetskontroll utføres
  • Tilkobling mellom alle komponentene i applikasjonen er sjekket

Det er tilrådelig for testerne å verifisere det ovennevnte i bakenden av systemet eller ved å utføre testing av hvit boks.

Når migrasjonsaktiviteten som er spesifisert i guiden er fullført, blir alle serverne hentet og grunnleggende tester relatert til verifisering av vellykket migrering vil bli gjort, noe som sikrer at alle end-to-end-systemene er riktig koblet til og alle komponentene snakker til hver annet er DB oppe og går, frontend kommuniserer med baksiden vellykket. Disse testene må identifiseres tidligere og registreres i dokumentet Migration Test Specification.

Det er muligheter for at programvaren støtter flere forskjellige plattformer. I slike tilfeller må migrasjon verifiseres på hver av disse plattformene separat.

Bekreftelse av migrasjonsskript vil være en del av migrasjonstesten. Noen ganger blir også individuelt migrasjonsskript bekreftet ved hjelp av 'White box testing' i et frittstående testmiljø.

Derfor vil migrasjonstesting være en kombinasjon av både 'hvit boks og svart boks testing'.

Når denne migreringsrelaterte bekreftelsen er gjort og tilsvarende tester er bestått, kan teamet fortsette videre med aktiviteten til testing etter overføring.

Fase 3:Testing etter overføring

Når applikasjonen er overført med suksess, kommer testing etter overføring inn i bildet.

Her utføres end-to-end systemtesting i testmiljøet. Testere utfører identifiserte testsaker, testscenarier, bruker saker med eldre data samt et nytt datasett.

I tillegg til disse er det spesifikke elementer som skal verifiseres i de migrerte miljøene som er oppført nedenfor:

Alle disse er dokumentert som en test case og inkludert i dokumentet ‘Test Specification’.

  1. Sjekk om alle dataene i arven er overført til den nye applikasjonen innen nedetid som var planlagt. For å sikre dette, sammenlign antall poster mellom arven og den nye applikasjonen for hver tabell og visninger i databasen. Rapporter også tiden det tar å flytte si 10000 poster.
  2. Sjekk om alle skjemaendringene (felt og tabeller er lagt til eller fjernet) i henhold til det nye systemet er oppdatert.
  3. Data som er migrert fra arven til et nytt program, skal beholde verdien og formatet med mindre det ikke er spesifisert for det. For å sikre dette, sammenlign dataverdier mellom eldre og nye applikasjonsdatabaser.
  4. Test de overførte dataene mot det nye programmet. Her dekker et maksimalt antall mulige saker. For å sikre 100% dekning med hensyn til bekreftelse av datamigrering, bruk det automatiserte testverktøyet.
  5. Se etter databasesikkerhet.
  6. Se etter dataintegritet for alle mulige eksempler.
  7. Kontroller og sørg for at den tidligere støttede funksjonaliteten i det eldre systemet fungerer som forventet i det nye systemet.
  8. Kontroller dataflyten i applikasjonen som dekker de fleste komponentene.
  9. Grensesnittet mellom komponentene bør testes grundig, ettersom dataene ikke skal modifiseres, mistes og ødelegges når de går gjennom komponenter. Integrasjonstesttilfeller kan brukes til å verifisere dette.
  10. Sjekk om eldre data er overflødige. Ingen eldre data skal dupliseres selv under migrering
  11. Se etter datatilfeller som datatype endret, lagringsformat endres osv.,
  12. Alle feltnivåkontroller i den eldre applikasjonen bør også dekkes i den nye applikasjonen
  13. Ethvert datatillegg i den nye applikasjonen skal ikke gjenspeile arven
  14. Oppdatering av eldre applikasjonsdata gjennom den nye applikasjonen bør støttes. Når den er oppdatert i den nye applikasjonen, bør den ikke gjenspeile arven.
  15. Slette data fra den eldre applikasjonen i den nye applikasjonen bør støttes. Når det er slettet i det nye programmet, bør det ikke slette data i arven også.
  16. Kontroller at endringene i det eldre systemet støtter den nye funksjonaliteten som leveres som en del av det nye systemet.
  17. Bekreft at brukerne fra det eldre systemet kan fortsette å bruke både den gamle funksjonaliteten og den nye funksjonaliteten, spesielt de der endringene er involvert. Utfør testsakene og testresultatene som er lagret under testen før migrering.
  18. Opprett nye brukere på systemet og utfør tester for å sikre at funksjonalitet fra arven så vel som den nye applikasjonen, støtter de nyopprettede brukerne, og den fungerer bra.
  19. Utfør funksjonalitetsrelaterte tester med en rekke datasampler (forskjellige aldersgrupper, brukere fra forskjellige regioner etc.)
  20. Det er også nødvendig å verifisere om 'Feature Flags' er aktivert for de nye funksjonene, og når du slår den på / av, kan funksjonene slås på og av.
  21. Ytelsestesting er viktig for å sikre at overføring til nytt system / programvare ikke har svekket ytelsen til systemet.
  22. Det er også nødvendig å utføre belastnings- og stresstester for å sikre systemets stabilitet.
  23. Kontroller at programvareoppgraderingen ikke har åpnet for sikkerhetsproblemer, og utfør derfor sikkerhetstester, spesielt i området der det er gjort endringer i systemet under overføringen.
  24. Brukervennlighet er et annet aspekt som skal verifiseres, hvor hvis GUI-layout / front-end-system har endret seg eller en hvilken som helst funksjonalitet har endret seg, hva er den brukervennligheten som sluttbrukeren føler i forhold til det eldre systemet.

Siden omfanget av testing etter migrasjon blir veldig stort, er det ideelt å adskille de viktige testene som må gjøres først for å kvalifisere at migrering er vellykket, og deretter utføre de resterende senere.

Det anbefales også å automatisere end-to-end funksjonelle testtilfeller og andre mulige testtilfeller slik at testtiden kan reduseres og resultatene vil være tilgjengelige raskt.

Få tips for testere for å skrive testsaker for gjennomføring etter overføring:

  • Når søknaden overføres, betyr ikke det at testsakene må skrives for hele den nye søknaden. Testtilfeller som allerede er designet for arven, bør fortsatt holde godt for den nye applikasjonen. Så så langt som mulig, bruk de gamle testtilfellene og konverter de eldre testtilfellene til tilfeller av en ny applikasjon der det er nødvendig.
  • Hvis det er noen funksjonsendringer i det nye programmet, bør testtilfeller relatert til funksjonen endres.
  • Hvis det er lagt til noen nye funksjoner i den nye applikasjonen, bør nye testtilfeller utformes for den aktuelle funksjonen.
  • Når det faller noen funksjoner i den nye applikasjonen, skal ikke relaterte eldre applikasjoners testtilfeller vurderes for utføring etter overføring, og de bør merkes som ikke gyldige og holdes fra hverandre.
  • Test tilfeller utformet skal alltid være pålitelig og konsistent når det gjelder bruk. Verifisering av kritiske data bør dekkes i testtilfeller, slik at de ikke blir savnet under utførelsen.
  • Når utformingen av den nye applikasjonen er forskjellig fra den fra arven (UI), bør de UI-relaterte testsakene endres for å tilpasse den nye designen. Beslutningen om å enten oppdatere eller skrive nye, i dette tilfellet, kan tas av testeren basert på endringsvolumet som skjedde.

Bakoverkompatibilitetstesting

Migrering av systemet krever også at testerne må verifisere 'Bakoverkompatibilitet', der det nye systemet som er introdusert er kompatibelt med det gamle systemet (minst 2 tidligere versjoner) og sørger for at det fungerer perfekt med disse versjonene.

Bakoverkompatibilitet er å sikre:

  1. Om det nye systemet støtter funksjonaliteten som støttes i tidligere to versjoner sammen med den nye.
  2. Systemet kan overføres vellykket fra de to tidligere versjonene uten problemer.

Derfor er det viktig å sikre systemets bakoverkompatibilitet ved å spesifikt utføre testene relatert til støtte bakoverkompatibilitet. Testene relatert til bakoverkompatibilitet må utformes og inkluderes i testspesifikasjonsdokumentet for utføring.

Tilbakestillingstesting

I tilfelle problemer under migrering, eller hvis det er migrasjonsfeil når som helst under migrering, bør det være mulig for systemet å rulle tilbake til det eldre systemet og gjenoppta funksjonen raskt uten å påvirke brukerne og funksjonaliteten som ble støttet tidligere.

Så for å verifisere dette, må migrasjonssviktstestscenarier utformes som en del av negativ testing og tilbakestillingsmekanisme må testes. Total tid som kreves for å gjenoppta tilbake til det eldre systemet, må også registreres og rapporteres i testresultatene.

Etter tilbakestilling, hovedfunksjonaliteten og regresjonstesting (automatisert) bør kjøres for å sikre at migrasjon ikke har påvirket noe, og tilbakeføring er vellykket med å bringe tilbake det eldre systemet på plass.

Migration Test Summary Report

Testoppsummeringsrapporten skal produseres etter fullført test og skal dekke rapporten om sammendraget av de forskjellige testene / scenariene som er utført som en del av ulike migrasjonsfaser med resultatstatus (bestått / ikke bestått) og testloggene.

Tid registrert for følgende aktiviteter bør rapporteres tydelig:

beste programvaren for å rippe DVD til MP4
  1. Total tid for migrasjon
  2. Nedetid for applikasjonene
  3. Tid brukt til å migrere 10000 poster.
  4. Tid brukt til tilbakeføring.

I tillegg til informasjonen ovenfor, kan eventuelle observasjoner / anbefalinger også rapporteres.

Utfordringer i datamigreringstesting

Utfordringene i denne testingen er hovedsakelig med data. Nedenfor er det få på listen:

# 1) Datakvalitet:

Vi kan oppdage at dataene som brukes i den eldre applikasjonen har dårlig kvalitet i den nye / oppgraderte applikasjonen. I slike tilfeller må datakvaliteten forbedres for å oppfylle forretningsstandardene.

Faktorer som antagelser, datakonvertering etter migrasjoner, data som er angitt i selve den eldre applikasjonen er ugyldige, dårlig dataanalyse etc. fører til dårlig datakvalitet. Dette resulterer i høye driftskostnader, økt risiko for dataintegrering og avvik fra formålet med virksomheten.

# 2) Dataoverensstemmelse:

Data som er migrert fra arven til den nye / oppgraderte applikasjonen, kan bli funnet å være uoverensstemmende i den nye. Dette kan skyldes endring i datatype, format for datalagring, formålet som dataene brukes til kan omdefineres.

Dette resulterer i store anstrengelser for å modifisere de nødvendige endringene for å enten korrigere dataene som ikke samsvarer, eller godta dem og justere til det formålet.

# 3) Datatap:

Data kan gå tapt under migrering fra arven til den nye / oppgraderte applikasjonen. Dette kan være med obligatoriske felt eller ikke-obligatoriske felt. Hvis tapte data gjelder ikke-obligatoriske felt, vil posten for dem fremdeles være gyldig og kan oppdateres på nytt.

Men hvis det obligatoriske feltets data går tapt, blir selve posten ugyldig, og den kan ikke trekkes tilbake. Dette vil føre til enorme tap av data og må hentes enten fra sikkerhetskopidatabasen eller revisjonsloggene hvis de fanges opp riktig.

# 4) Datavolum:

Enorme data som krever mye tid å migrere i nedetid-vinduet til migreringsaktiviteten. F.eks .: Skrapelodd i telekombransjen, brukere på en intelligent nettverksplattform etc., her er utfordringen for tiden, eldre data blir ryddet, det vil bli opprettet en enorm ny data, som må migreres igjen. Automatisering er løsningen for enorm datamigrering.

# 5) Simulering av et sanntidsmiljø (med de faktiske dataene):

Simulering av et sanntidsmiljø i testlaboratoriet er en annen reell utfordring, hvor testere kommer inn i forskjellige slags problemer med de virkelige dataene og det virkelige systemet, som ikke blir møtt under testingen.

Så, prøvetaking av data, replikering av ekte miljø, identifikasjon av datavolum involvert i migrasjon er ganske viktig når du utfører datamigreringstesting.

# 6) Simulering av datamengden:

Teamene må studere dataene i live-systemet veldig nøye og bør komme med den typiske analysen og prøvetakingen av dataene.

F.eks .: brukere med aldersgruppe under 10 år, 10-30 år osv., Så langt det er mulig, må data fra live innhentes, hvis ikke dataoppretting må gjøres i testmiljøet. Automatiske verktøy må brukes til å skape et stort datamengde. Ekstrapolering, der det er aktuelt, kan brukes, hvis volumet ikke kan simuleres.

Tips for å jevne ut dataoverføringsrisikoen

Nedenfor er det noen få tips som skal utføres for å redusere risikoen for datamigrering:

  • Standardiser data som brukes i eldre system, slik at når standardene blir migrert, vil standarddata være tilgjengelig i nytt system
  • Forbedre kvaliteten på dataene, slik at det er kvalitative data å teste når de overføres, noe som gir følelsen av å teste som sluttbruker
  • Rengjør dataene før migrering, slik at dupliserte data ikke blir tilstede i det nye systemet når det overføres, og dette holder hele systemet rent
  • Kontroller begrensningene, lagrede prosedyrer, komplekse spørsmål som gir nøyaktige resultater, slik at når du migrerer, returneres riktige data også i det nye systemet
  • Identifiser riktig automatiseringsverktøy for å utføre datasjekker / registrere sjekker i det nye systemet sammenlignet med arven.

Konklusjon

Derfor med tanke på kompleksiteten involvert i å utføre datamigreringstesting, med tanke på at en liten glipp i ethvert aspekt av verifikasjon under testing vil føre til risikoen for migrasjonssvikt i produksjonen, er det veldig viktig å utføre nøye og grundige studier & analyse av systemet før og etter migrering. Planlegg og utform den effektive migreringsstrategien med de robuste verktøyene sammen med dyktige og trente testere.

Ettersom vi vet at Migration har en enorm innvirkning på kvaliteten på applikasjonen, må det legges en stor innsats av hele teamet for å verifisere hele systemet i alle aspekter som funksjonalitet, ytelse, sikkerhet, brukervennlighet, tilgjengelighet, pålitelighet, kompatibilitet etc., som igjen vil sikre vellykket 'Migration Testing'.

‘Ulike typer migrasjoner’ som vanligvis skjer ganske ofte i virkeligheten, og måtene å håndtere testingen på blir forklart kort i vår neste opplæring i denne serien .

Om forfatterne: Denne guiden er skrevet av STH-forfatter Nandini. Hun har 7+ års erfaring med testing av programvare. Også takk til STH-forfatter Gayathri S. for at hun har gjennomgått og gitt sine valubale forslag for å forbedre denne serien. Gayathri har 18+ års erfaring innen programvareutvikling og testingstjenester.

Gi oss beskjed om dine kommentarer / forslag om denne opplæringen.

Anbefalt lesing

^