Meny

Tutorial för datamigreringstest: En komplett guide

data migration testing tutorial

Prova Vårt Instrument För Att Eliminera Problem

Översikt av datamigreringstestning:

Det hörs ganska ofta att en applikation flyttas till en annan server, tekniken ändras, den uppdateras till nästa version eller flyttas till en annan databasserver etc.,

  • Vad betyder detta egentligen?
  • Vad förväntas av testteamet i dessa situationer?

Ur testsynpunkt betyder allt att applikationen måste testas grundligt från början till slut tillsammans med migrering från det befintliga systemet till det nya systemet framgångsrikt.

Självstudier i denna serie:

Systemtestning måste utföras i det här fallet med alla data som används i en gammal applikation och de nya uppgifterna också. Befintlig funktionalitet måste verifieras tillsammans med den nya / modifierade funktionaliteten.

Test av datamigrering

Istället för bara Migration Testing kan det också kallas Data Migration Testing, där hela data för användaren kommer att migreras till ett nytt system.

Så, migreringstestning inkluderar testning med gamla data, nya data eller kombination av båda, gamla funktioner (oförändrade funktioner) och de nya funktionerna.

Gammal applikation kallas vanligtvis som ” arv ' Ansökan. Tillsammans med ny / uppgraderad applikation är det också obligatoriskt att testa äldre applikationer tills de nya / uppgraderade blir stabila och konsekventa. Omfattande migreringstest på nya applikationer kommer att avslöja de nya problemen som inte hittades i den äldre applikationen.

Vad du kommer att lära dig:

Vad är migrationstestning?

Migration Testing är en verifieringsprocess för migrering av det äldre systemet till det nya systemet med minimal störning / stillestånd, med dataintegritet och ingen förlust av data, samtidigt som man säkerställer att alla de angivna funktionella och icke-funktionella aspekterna av applikationen uppfylls efter migration.

Enkel representation av migrationssystemet:

Migration Testing

Varför Migration Test?

Som vi vet kan applikationsmigrationen till ett nytt system vara av olika skäl, systemkonsolidering, föråldrad teknik, optimering eller andra orsaker.

Medan systemet i bruk måste migreras till ett nytt system är det därför viktigt att säkerställa följande punkter:

  1. Alla typer av störningar / besvär som orsakas av användaren på grund av migrering måste undvikas / minimeras. Till exempel: driftstopp, förlust av data
  2. Måste säkerställa om användaren kan fortsätta använda alla funktionerna i programvaran genom att orsaka minimal eller ingen skada under migreringen. Exempel: förändring i funktionalitet, borttagning av en viss funktionalitet
  3. Det är också viktigt att förutse och utesluta alla eventuella problem / hinder som kan uppstå under den faktiska migrationen av det levande systemet.

För att säkerställa en smidig migrering av det levande systemet genom att eliminera dessa defekter är det därför viktigt att utföra migreringstester i labbet.

Denna testning har sin egen betydelse och den spelar en viktig roll när data kommer in i bilden.

Tekniskt krävs också att den körs för följande ändamål:

  • För att säkerställa kompatibilitet för den nya / uppgraderade applikationen med all möjlig hårdvara och programvara som den äldre applikationen stöder. Också nytt kompatibilitet bör testas för ny hårdvara, programvaruplattform också.
  • För att säkerställa att alla befintliga funktioner fungerar som i den äldre applikationen. Det bör inte förändras hur applikationen fungerar jämfört med den äldre.
  • Möjligheten till ett stort antal defekter på grund av migration är mycket hög. Många av bristerna är vanligtvis relaterade till data och därför måste dessa brister identifieras och åtgärdas under testningen.
  • För att säkerställa om systemets svarstid för den nya / uppgraderade applikationen är densamma eller mindre än vad som krävs för den äldre applikationen.
  • För att säkerställa att anslutningen mellan servrar, hårdvara, programvara etc. är intakt och inte bryts under testningen. Dataflödet mellan olika komponenter bör inte bryta under något tillstånd.

När krävs detta test?

Testning måste utföras både före och efter migrering.

De olika faserna i Migration test som ska utföras på testlaboratoriet kan klassificeras enligt nedan.

  1. Test före migrering
  2. Migration Testing
  3. Test efter postmigration

Förutom ovanstående har följande tester utförs också som en del av hela migrationsaktiviteten.

  1. Verifiering av bakåtkompatibilitet
  2. Återställningstestning

Innan du utför detta test är det viktigt för alla testare att förstå nedanstående punkter:

  1. Förändringarna sker som en del av det nya systemet (server, frontend, DB, schema, dataflöde, funktionalitet etc.,)
  2. Att förstå den faktiska migrationsstrategin som lagts ut av teamet. Hur migrationen sker, steg för steg förändringar som händer i systemets backend och de skript som är ansvariga för dessa förändringar.

Därför är det viktigt att göra en grundlig studie av det gamla och det nya systemet och sedan planera och designa testfall och testscenarier som ska täckas som en del av ovanstående testfaser och förbereda teststrategin.

Strategi för testning av datamigrering

Att utforma teststrategin för migration inkluderar en uppsättning aktiviteter som ska utföras och få aspekter som ska övervägas. Detta för att minimera de fel och risker som uppstår till följd av migration och för att utföra migreringstestningen effektivt.

Aktiviteter i denna testning:

# 1) Specialiserad lagbildning :

Bilda testteamet med medlemmarna som har den kunskap och erfarenhet som krävs och ge utbildning relaterat till det system som migreras.

#två) Analys av affärsrisker, möjliga felanalyser :

Nuvarande affärer bör inte hindras efter migrationen och därmed utföra ” Analys av affärsrisker ” möten som involverar rätt intressenter (testchef, affärsanalytiker, arkitekter, produktägare, företagsägare etc.) och identifierar riskerna och de genomförbara begränsningarna. Testningen bör innehålla scenarier för att avslöja dessa risker och verifiera om korrekta begränsningar har genomförts.

Uppförande “ Möjlig felanalys ' med lämpligt 'Fel gissningsmetoder' och utforma sedan tester kring dessa fel för att ta reda på dem under testningen.

hur man skriver ut innehåll i array java

# 3) Analys och identifiering av migrationsomfång:

Analysera det tydliga omfånget för migreringstestet när och vad som behöver testas.

# 4) Identifiera lämpligt verktyg för migrering:

När du definierar strategin för denna testning, automatiserad eller manuell, identifiera de verktyg som ska användas. T.ex: Automatiserat verktyg för att jämföra käll- och destinationsdata.

# 5) Identifiera lämplig testmiljö för migration:

Identifiera separata miljöer för miljöer före och efter migrering för att utföra alla verifieringar som krävs som en del av testningen. Förstå och dokumentera de tekniska aspekterna av Legacy and New Migration-systemet för att säkerställa att testmiljön är inställd enligt den.

# 6) Migration Test Specification Document och recension:

Förbered dokument för migreringstestspecifikation som tydligt beskriver testmetoden, testområden, testmetoder (automatiserad, manuell), testmetodik (svart ruta, vitlåda testteknik ), Antal testcykler, testschema, metod för att skapa data och använda live-data (känslig info måste maskeras), testmiljöspecifikation, testarkvalificering etc., och köra en granskningssession med intressenterna.

# 7) Produktionslansering av det migrerade systemet :

Analysera och dokumentera att göra-listan för produktionsmigrering och publicera den i god tid

Olika faser av migration

Nedan följer de olika faserna i Migration.

Fas 1:Test före migrering

Innan data migreras utförs uppsättning testaktiviteter som en del av testfasen före migrering. Detta ignoreras eller beaktas inte i enklare applikationer. Men när komplexa applikationer ska migreras är aktiviteterna före migrering ett måste.

Nedan är en lista över åtgärder som vidtas under denna fas:

  • Ställ in ett tydligt omfång av data - vilka data som måste inkluderas, vilka data som måste uteslutas, vilka data som behöver omvandlas / konverteras etc.
  • Utför datamappning mellan äldre och den nya applikationen - för varje typ av data i den äldre applikationen, jämför dess relevanta typ i den nya applikationen och kartlägg dem sedan - Mappning på högre nivå.
  • Om den nya applikationen har det obligatoriska fältet, men det inte är fallet i arv, och se till att arvet inte har det fältet som null. - Mappning på lägre nivå.
  • Studera den nya applikationens dataskema - fältnamn, typer, minimi- och maxvärden, längd, obligatoriska fält, fältnivåvalidering etc., tydligt
  • Ett antal tabeller i det äldre systemet ska noteras och om några tabeller tappas och tillägg efter migrering måste verifieras.
  • Ett antal poster i varje tabell, vyer bör noteras i den äldre applikationen.
  • Studera gränssnitten i den nya applikationen och deras anslutningar. Data som flödar i gränssnittet ska vara mycket säkert och inte brytas.
  • Förbered testfall, testscenarier och använd fall för nya förhållanden i de nya applikationerna.
  • Utför en uppsättning testfall, scenarier med en uppsättning användare och förvara resultaten, loggarna. Detsamma måste verifieras efter migrering för att säkerställa att äldre data och funktionalitet är intakta.
  • Antalet data och poster bör noteras tydligt, det måste verifieras efter migrering utan att förlora data.

Fas 2:Migration Testing

'' Migration Guide ”vilket är som utarbetats av migrationsgruppen måste följas strikt för att utföra migreringsaktiviteten. Helst börjar migrationsaktiviteten med att data säkerhetskopieras på bandet, så att det gamla systemet kan återställas när som helst.

Verifiera dokumentationsdelen av ” Migration Guide ”är också en del av datamigreringstestning . Kontrollera om dokumentet är tydligt och enkelt att följa. Alla skript och steg måste dokumenteras korrekt utan tvetydighet. Varje typ av dokumentationsfel, missmatchningar i ordningen för utförande av steg måste också betraktas som viktiga så att de kan rapporteras och fixas.

Migrationsskript, guide och annan information relaterad till faktisk migrering måste hämtas från versionskontrollförvaret för körning.

Att notera den faktiska tiden det tog för migrering från migrationspunkten till framgångsrik återställning av systemet är ett av testfallet som ska köras och därmed ”Det tar tid att migrera systemet” måste registreras i den slutliga testrapporten som kommer att levereras som en del av Migration testresultat och denna information kommer att vara användbar under produktionslanseringen. Den driftstopp som registrerats i testmiljön extrapoleras för att beräkna ungefärlig driftstopp i live-systemet.

Det är i det äldre systemet där migrationsaktiviteten kommer att genomföras.

Under denna testning kommer alla komponenter i miljön vanligtvis att tas ner och tas bort från nätverket för att utföra migrationsaktiviteter. Därför är det nödvändigt att notera 'Stilleståndstid' krävs för migrationstest. Helst kommer det att vara samma som för migreringstiden.

Generellt innehåller migrationsaktivitet som definierats i dokumentet ”Migrationsguide”:

  • Faktisk migrering av ansökan
  • Brandväggar, port, värdar, hårdvara, programvarukonfigurationer ändras alla enligt det nya systemet som arvet migreras på
  • Dataläckage, säkerhetskontroller utförs
  • Anslutningen mellan alla komponenter i applikationen är kontrollerad

Det är tillrådligt för testarna att verifiera ovanstående i systemets baksida eller genom att testa vita rutor.

När migrationsaktiviteten som anges i guiden har slutförts tas alla servrar fram och grundläggande tester relaterade till verifiering av framgångsrik migrering kommer att göras, vilket säkerställer att alla slut-till-slut-system är korrekt anslutna och alla komponenter pratar med var och en för övrigt är DB igång, frontend kommunicerar framgångsrikt. Dessa tester måste identifieras tidigare och registreras i dokumentet Migration Test Specification.

Det finns möjligheter att programvaran stöder flera olika plattformar. I sådana fall måste migrering verifieras på var och en av dessa plattformar separat.

Verifiering av migrationsskript kommer att ingå i migreringstestet. Ibland verifieras även enskild migrationsskript med hjälp av ”White box testing” i en fristående testmiljö.

Följaktligen kommer migreringstester att vara en kombination av både ”vitlåda och svartlåda-testning”.

När denna migrationsrelaterade verifiering är klar och motsvarande tester har godkänts kan teamet fortsätta med aktiviteten med test efter migrering.

Fas # 3:Test efter migrering

När applikationen har migrerats framgångsrikt kommer test efter migrering in i bilden.

Här utförs end-to-end systemtestning i testmiljön. Testare utför identifierade testfall, testscenarier, använder fall med äldre data samt en ny uppsättning data.

Utöver dessa finns det specifika objekt som ska verifieras i de migrerade miljöerna som listas nedan:

Alla dessa dokumenteras som ett testfall och ingår i dokumentet 'Testspecifikation'.

  1. Kontrollera om all data i arvet migreras till den nya applikationen inom den driftstopp som planerades. För att säkerställa detta, jämför antalet poster mellan äldre och den nya applikationen för varje tabell och vyer i databasen. Rapportera också hur lång tid det tar att säga 10000 poster.
  2. Kontrollera om alla schemaändringar (fält och tabeller läggs till eller tas bort) enligt det nya systemet uppdateras.
  3. Data som migreras från det gamla till det nya programmet bör behålla sitt värde och format såvida det inte anges för detta. För att säkerställa detta, jämför datavärden mellan äldre och den nya applikationsdatabasen.
  4. Testa migrerad data mot den nya applikationen. Här täcker maximalt antal möjliga fall. För att säkerställa 100% täckning med avseende på verifiering av datamigrering, använd det automatiska testverktyget.
  5. Sök efter databassäkerhet.
  6. Sök efter dataintegritet för alla möjliga exempelposter.
  7. Kontrollera och se till att den tidigare stödda funktionaliteten i det äldre systemet fungerar som förväntat i det nya systemet.
  8. Kontrollera dataflödet i applikationen som täcker de flesta komponenterna.
  9. Gränssnittet mellan komponenterna bör testas noggrant, eftersom data inte bör modifieras, förloras och skadas när de går igenom komponenter. Integrationstestfall kan användas för att verifiera detta.
  10. Sök efter äldre dators överflöd. Inga äldre data ska kopieras själv under migrationen
  11. Kontrollera om data inte stämmer överens, t.ex. datatyp har ändrats, lagringsformat har ändrats etc.,
  12. Alla fältnivåkontroller i den äldre applikationen bör också omfattas av den nya applikationen
  13. Alla datatillägg i den nya applikationen bör inte återspegla arvet
  14. Uppdatering av äldre applikationsdata via den nya applikationen bör stödjas. När den har uppdaterats i den nya applikationen bör den inte återspegla arvet.
  15. Att ta bort den äldre applikationsdata i den nya applikationen bör stödjas. När den väl har tagits bort i den nya applikationen bör den inte heller ta bort data i äldre stil.
  16. Kontrollera att ändringarna i det äldre systemet stöder den nya funktionaliteten som levereras som en del av det nya systemet.
  17. Kontrollera att användarna från det äldre systemet kan fortsätta använda både den gamla funktionaliteten och den nya funktionaliteten, särskilt de där ändringarna är inblandade. Utför testfall och testresultat som lagrats under testet före migrering.
  18. Skapa nya användare på systemet och utför tester för att säkerställa att funktionalitet från arvet såväl som den nya applikationen stöder de nyskapade användarna och det fungerar bra.
  19. Utför funktionsrelaterade tester med en mängd olika dataprov (olika åldersgrupper, användare från olika regioner etc.)
  20. Det är också nödvändigt att verifiera om ”Feature Flags” är aktiverade för de nya funktionerna och om du slår på / av den kan funktionerna slås på och av.
  21. Prestandatest är viktigt för att säkerställa att migrering till nytt system / programvara inte har försämrat systemets prestanda.
  22. Det är också nödvändigt att utföra belastnings- och stresstester för att säkerställa systemets stabilitet.
  23. Kontrollera att programuppgraderingen inte har öppnat några säkerhetsproblem och gör därför säkerhetstester, särskilt i det område där ändringar har gjorts i systemet under migrering.
  24. Användbarhet är en annan aspekt som ska verifieras, där om GUI-layout / front-end-system har ändrats eller någon funktion har förändrats, vad är användarvänligheten som slutanvändaren känner jämfört med det äldre systemet.

Eftersom omfattningen av test efter migrering blir väldigt stor är det idealiskt att separera de viktiga testerna som måste göras först för att kvalificera mig för att migrationen lyckas och sedan utföra de återstående senare.

Det är också tillrådligt att automatisera funktionella testfall och andra möjliga testfall så att testtiden kan minskas och resultaten snabbt blir tillgängliga.

Få tips för testare för att skriva testfall för exekvering efter migrering:

  • När applikationen migreras betyder det inte att testfallet måste skrivas för den helt nya applikationen. Testfall som redan är utformade för arvet bör fortfarande vara bra för den nya applikationen. Så, så långt som möjligt, använd de gamla testerna och konvertera de äldre testerna till en ny applikations fall där det behövs.
  • Om det ändras någon funktion i den nya applikationen bör testfall relaterade till funktionen ändras.
  • Om det finns någon ny funktion i den nya applikationen, bör nya testfall utformas för just den funktionen.
  • När det faller någon funktion i den nya applikationen, bör relaterade äldre applikations testfall inte övervägas för exekvering efter migrering, och de bör markeras som inte giltiga och hållas isär.
  • Testfall som utformats ska alltid vara tillförlitliga och konsekventa när det gäller användning. Verifiering av kritiska data bör täckas i testfall så att den inte missas under körning.
  • När utformningen av den nya applikationen skiljer sig från den gamla (UI), bör de UI-relaterade testfallet modifieras för att anpassa den nya designen. Beslutet att antingen uppdatera eller skriva nya kan i det här fallet tas av testaren baserat på den förändringsvolym som inträffat.

Testning av bakåtkompatibilitet

Migrering av systemet kräver också att testarna ska verifiera ”bakåtkompatibilitet”, där det nya systemet som introduceras är kompatibelt med det gamla systemet (minst två tidigare versioner) och säkerställer att det fungerar perfekt med dessa versioner.

Bakåtkompatibilitet är att säkerställa:

  1. Oavsett om det nya systemet stöder den funktionalitet som stöds i tidigare två versioner tillsammans med den nya.
  2. Systemet kan migreras framgångsrikt från de tidigare två versionerna utan problem.

Därför är det viktigt att säkerställa systemets bakåtkompatibilitet genom att specifikt utföra testerna för att stödja bakåtkompatibilitet. Testerna relaterade till bakåtkompatibilitet måste utformas och inkluderas i testspecifikationsdokumentet för körning.

Återställningstestning

Om det uppstår problem när migreringen utförs eller om migrationsfel uppstår vid någon tidpunkt under migreringen, bör det vara möjligt för systemet att rulla tillbaka till det äldre systemet och återuppta dess funktion snabbt utan att påverka användarna och den funktionalitet som stöds tidigare.

Så, för att verifiera detta, måste testscenarier för migrationsfel utformas som en del av negativ testning och rollback-mekanismen måste testas. Den totala tid som krävs för att återgå till det gamla systemet måste också registreras och rapporteras i testresultaten.

Efter återställning, huvudfunktionalitet och regressionstest (automatiserad) bör köras för att säkerställa att migration inte har påverkat någonting och återgång är framgångsrik med att få tillbaka det gamla systemet.

Sammanfattningsrapport om migreringstest

Testöversiktsrapporten bör produceras efter avslutad testning och ska omfatta rapporten om sammanfattningen av de olika tester / scenarier som utförts som en del av olika faser av migration med resultatstatus (pass / fail) och testloggar.

Tid registrerad för följande aktiviteter bör tydligt rapporteras:

  1. Total tid för migration
  2. Driftstopp för applikationerna
  3. Tidsåtgång för att migrera 10000 poster.
  4. Tidsåtgång för återgång.

Förutom ovanstående information kan eventuella observationer / rekommendationer också rapporteras.

Utmaningar i datamigreringstestning

Utmaningarna i denna testning är främst med data. Nedan följer några i listan:

# 1) Datakvalitet:

hur man förklarar flyta i java

Vi kan upptäcka att data som används i den äldre applikationen är av dålig kvalitet i den nya / uppgraderade applikationen. I sådana fall måste datakvaliteten förbättras för att uppfylla affärsstandarderna.

Faktorer som antaganden, datakonvertering efter migrering, data som anges i den äldre applikationen är ogiltiga, dålig dataanalys etc. leder till dålig datakvalitet. Detta resulterar i höga driftskostnader, ökade dataintegrationsrisker och avvikelse från syftet med verksamheten.

# 2) Datafel:

Data som migrerats från arvet till den nya / uppgraderade applikationen kan tyckas att de inte passar i den nya. Detta kan bero på förändring av datatyp, format på datalagring, syftet med vilket datan används kan omdefinieras.

Detta resulterar i stora ansträngningar för att modifiera de nödvändiga ändringarna för att antingen korrigera data som inte stämmer överens eller acceptera den och justera för det ändamålet.

# 3) Dataförlust:

Data kan gå förlorade vid migrering från arvet till den nya / uppgraderade applikationen. Detta kan vara med obligatoriska fält eller icke-obligatoriska fält. Om den förlorade informationen gäller icke-obligatoriska fält kommer posten för den fortfarande att vara giltig och kan uppdateras igen.

Men om det obligatoriska fältets data går förlorade blir posten i sig ogiltig och den kan inte dras tillbaka. Detta kommer att resultera i enorma dataförluster och måste hämtas antingen från reservdatabasen eller granskningsloggar om de fångas korrekt.

# 4) Datavolym:

Enorma data som kräver mycket tid att migrera inom migrationsaktivitetsfönstret. T.ex: Skraplotter i telekombranschen, användare på en intelligent nätverksplattform etc., här är utmaningen när tiden är, de äldre uppgifterna rensas, en enorm ny data kommer att skapas, som måste migreras igen. Automation är lösningen för enorm datamigrering.

# 5) Simulering av en realtidsmiljö (med faktiska data):

Simulering av en realtidsmiljö i testlaboratoriet är en annan verklig utmaning, där testare hamnar i olika slags problem med den verkliga datan och det verkliga systemet, som inte står inför under testningen.

Så, provtagning av data, replikering av verklig miljö, identifiering av datamängden involverad i migration är ganska viktigt när du utför datamigreringstestning.

# 6) Simulering av datamängden:

Team måste studera data i live-systemet mycket noggrant och bör komma med den typiska analysen och samplingen av data.

T.ex: användare med åldersgrupp under 10 år, 10-30 år etc., så långt det är möjligt, måste data från live fås, om inte dataskapande behöver göras i testmiljön. Automatiserade verktyg måste användas för att skapa en stor datamängd. Extrapolering, där detta är tillämpligt, kan användas om volymen inte kan simuleras.

Tips för att utjämna riskerna för datamigrering

Nedan ges några tips som ska utföras för att minska riskerna för datamigrering:

  • Standardisera data som används i äldre system så att standarddata kommer att finnas tillgängliga i det nya systemet vid migrering
  • Förbättra datakvaliteten så att det finns kvalitativa data att testa när de migreras, vilket ger känslan av att testa som slutanvändare
  • Rengör data innan de migreras, så att dubbla data inte kommer att finnas i det nya systemet vid migrering och det håller hela systemet rent
  • Kontrollera om begränsningarna, lagrade procedurer, komplexa frågor som ger korrekta resultat, så att korrekt data returneras i det nya systemet vid migrering
  • Identifiera korrekt automatiseringsverktyg för att utföra datakontroller / inspelningskontroller i det nya systemet jämfört med arvet.

Slutsats

Därför med tanke på komplexiteten i att utföra datamigreringstestning, med tanke på att en liten miss i alla aspekter av verifiering under testning kommer att leda till risken för migrationsfel vid produktionen, är det mycket viktigt att utföra noggrann och grundlig studie & analys av systemet före och efter migrering. Planera och utforma den effektiva migrationsstrategin med de robusta verktygen tillsammans med skickliga och utbildade testare.

Eftersom vi vet att Migration har en enorm inverkan på applikationens kvalitet, måste en hel del ansträngningar göras av hela teamet för att verifiera hela systemet i alla aspekter som funktionalitet, prestanda, säkerhet, användbarhet, tillgänglighet, tillförlitlighet, kompatibilitet etc., vilket i sin tur kommer att säkerställa framgångsrik 'Migration Testing'.

”Olika typer av migrationer” som vanligtvis händer ganska ofta i verkligheten och sätten att hantera deras testning kommer att förklaras kort i vår nästa handledning i denna serie .

Om Författarna: Denna guide är skriven av STH-författaren Nandini. Hon har 7+ års erfarenhet av mjukvarutestning. Tack också STH-författaren Gayathri S. för att ha granskat och lämnat sina valubale-förslag för att förbättra denna serie. Gayathri har 18+ års erfarenhet av mjukvaruutveckling och testtjänster.

Låt oss veta dina kommentarer / förslag om den här handledningen.

Rekommenderad läsning

^