data migration testing tutorial
Overzicht van datamigratietests:
Het wordt vaak gehoord dat een applicatie wordt verplaatst naar een andere server, de technologie wordt gewijzigd, wordt bijgewerkt naar de volgende versie of wordt verplaatst naar een andere databaseserver enz.,
- Wat betekent dit eigenlijk?
- Wat wordt er in deze situaties van het testteam verwacht?
Vanuit het oogpunt van testen betekent dit allemaal dat de applicatie grondig end-to-end moet worden getest en dat de migratie van het bestaande systeem naar het nieuwe systeem met succes moet worden uitgevoerd.
Tutorials in deze serie:
Systeemtesten moeten in dit geval worden uitgevoerd met alle gegevens, die worden gebruikt in een oude applicatie en ook met de nieuwe gegevens. Bestaande functionaliteit moet worden geverifieerd, samen met de nieuwe / gewijzigde functionaliteit.
In plaats van alleen Migratietests, kan het ook worden aangeduid als Data Migration Testing, waarbij de volledige gegevens van de gebruiker naar een nieuw systeem worden gemigreerd.
Migratietests omvatten dus testen met oude gegevens, nieuwe gegevens of een combinatie van beide, oude functies (ongewijzigde functies) en de nieuwe functies.
Oude applicatie wordt meestal aangeduid als ‘ erfenis ’Applicatie. Naast een nieuwe / geüpgradede applicatie is het ook verplicht om legacy-applicaties te blijven testen totdat de nieuwe / geüpgradede applicaties stabiel en consistent worden. Uitgebreide migratietest op nieuwe applicatie zal de nieuwe problemen aan het licht brengen die niet zijn gevonden in de legacy applicatie.
Wat je leert:
- Wat is migratietesten?
- Waarom een migratietest?
- Wanneer is deze test vereist?
- Strategie voor het testen van gegevensmigratie
- Verschillende fasen van migratie
- Testen van achterwaartse compatibiliteit
- Rollback-testen
- Overzichtsrapport migratietest
- Uitdagingen bij het testen van gegevensmigratie
- Tips om de risico's van datamigratie te verminderen
- Gevolgtrekking
- Aanbevolen literatuur
Wat is migratietesten?
Migratietesten is een verificatieproces voor de migratie van het oude systeem naar het nieuwe systeem met minimale verstoring / downtime, met gegevensintegriteit en zonder verlies van gegevens, terwijl ervoor wordt gezorgd dat aan alle gespecificeerde functionele en niet-functionele aspecten van de applicatie wordt voldaan na migratie.
Eenvoudige weergave van het migratiesysteem:
Waarom een migratietest?
Zoals we weten, kan de migratie van applicaties naar een nieuw systeem verschillende redenen hebben: systeemconsolidatie, verouderde technologie, optimalisatie of andere redenen.
Daarom, terwijl het systeem in gebruik moet worden gemigreerd naar een nieuw systeem, is het essentieel om de onderstaande punten te waarborgen:
- Elke vorm van verstoring / ongemak voor de gebruiker als gevolg van migratie moet worden vermeden / geminimaliseerd. Bijv .: downtime, verlies van data
- Moet ervoor zorgen dat de gebruiker alle functies van de software kan blijven gebruiken door tijdens de migratie minimale of geen schade aan te richten. Bijv .: wijziging in de functionaliteit, verwijdering van een bepaalde functionaliteit
- Het is ook belangrijk om te anticiperen en alle mogelijke storingen / hindernissen uit te sluiten die kunnen optreden tijdens de daadwerkelijke migratie van het live-systeem.
Om een vlotte migratie van het live-systeem te garanderen door die defecten te elimineren, is het daarom essentieel om migratietesten in het Lab uit te voeren.
Dit testen heeft zijn eigen belang en speelt een cruciale rol wanneer de gegevens in beeld komen.
Technisch gezien moet het ook worden uitgevoerd voor de onderstaande doeleinden:
- Om ervoor te zorgen dat de nieuwe / geüpgradede applicatie compatibel is met alle mogelijke hardware en software die de oude applicatie ondersteunt. Ook nieuw compatibiliteit moet ook worden getest op nieuwe hardware, softwareplatforms.
- Om ervoor te zorgen dat alle bestaande functionaliteiten werken zoals in de legacy-applicatie. Er mag geen verandering zijn in de manier waarop de applicatie werkt in vergelijking met de oude.
- De kans op een groot aantal defecten door migratie is zeer groot. Veel van de defecten hebben meestal betrekking op gegevens en daarom moeten deze defecten tijdens het testen worden geïdentificeerd en verholpen.
- Om ervoor te zorgen dat de systeemreactietijd van de nieuwe / geüpgradede applicatie gelijk of korter is dan wat nodig is voor de legacy-applicatie.
- Om er zeker van te zijn dat de verbinding tussen servers, hardware, software enz. Allemaal intact is en niet verbroken wordt tijdens het testen. De gegevensstroom tussen verschillende componenten mag onder geen enkele voorwaarde breken.
Wanneer is deze test vereist?
Het testen moet zowel voor als na de migratie worden uitgevoerd.
De verschillende fasen van de migratietest die in het testlaboratorium worden uitgevoerd, kunnen als volgt worden geclassificeerd.
- Testen vóór migratie
- Migratietesten
- Testen na de migratie
Naast het bovenstaande is de volgende tests worden ook uitgevoerd als onderdeel van de volledige migratie-activiteit.
- Verificatie van achterwaartse compatibiliteit
- Rollback-testen
Alvorens deze test uit te voeren, is het essentieel dat elke tester de onderstaande punten goed begrijpt:
- De veranderingen die plaatsvinden als onderdeel van het nieuwe systeem (server, front-end, DB, schema, gegevensstroom, functionaliteit enz.)
- De feitelijke migratiestrategie die door het team is opgesteld, begrijpen. Hoe de migratie verloopt, stap voor stap gebeuren er veranderingen in de backend van het systeem en de scripts die verantwoordelijk zijn voor deze veranderingen.
Daarom is het essentieel om het oude en het nieuwe systeem grondig te bestuderen en vervolgens de testgevallen en testscenario's te plannen en te ontwerpen die moeten worden behandeld als onderdeel van de bovenstaande testfasen en om de teststrategie voor te bereiden.
Strategie voor het testen van gegevensmigratie
Het ontwerpen van de teststrategie voor migratie omvat een reeks activiteiten die moeten worden uitgevoerd en enkele aspecten waarmee rekening moet worden gehouden. Dit om de fouten en risico's die optreden als gevolg van migratie te minimaliseren en om de migratietesten effectief uit te voeren.
Activiteiten in deze test:
# 1) Gespecialiseerde teamvorming
Vorm het testteam met de leden met de vereiste kennis en ervaring en geef training met betrekking tot het systeem dat wordt gemigreerd.
#twee) Bedrijfsrisicoanalyse, mogelijke foutenanalyse
De huidige zaken mogen na migratie niet worden belemmerd en moeten daarom ‘ Bedrijfsrisicoanalyse ’ bijeenkomsten met de juiste stakeholders (Test Manager, Business Analist, Architecten, Product Owners, Business Owner etc.) en het identificeren van de risico's en de implementeerbare mitigaties. Het testen moet scenario's omvatten om die risico's bloot te leggen en te verifiëren of de juiste maatregelen zijn geïmplementeerd.
Gedrag ‘ Mogelijke foutanalyse ’ met behulp van de juiste ‘Benaderingen voor het raden van fouten’ en ontwerp vervolgens tests rond deze fouten om ze tijdens het testen op te sporen.
wat is een verkeerde combinatie van de netwerkbeveiligingssleutel?
# 3) Analyse en identificatie van migratiebereik:
Analyseer de duidelijke reikwijdte van de migratietest zoals wanneer en wat er moet worden getest.
# 4) Identificeer de juiste tool voor migratie:
Bepaal bij het bepalen van de strategie van deze test, geautomatiseerd of handmatig, welke tools zullen worden gebruikt. Bijv .: Geautomatiseerde tool om bron- en bestemmingsgegevens te vergelijken.
# 5) Identificeer de juiste testomgeving voor migratie:
Identificeer afzonderlijke omgevingen voor Pre- en Post-migratieomgevingen om eventuele verificatie uit te voeren die nodig is als onderdeel van testen. Begrijp en documenteer de technische aspecten van het oude en nieuwe migratiesysteem, om ervoor te zorgen dat de testomgeving op die manier wordt opgezet.
# 6) Migratietestspecificatiedocument en beoordeling:
Bereid een migratietestspecificatiedocument voor dat duidelijk de testaanpak, testgebieden, testmethoden (geautomatiseerd, handmatig), testmethodologie (zwarte doos, white box-testtechniek ), Aantal testcycli, testschema, benadering van het creëren van gegevens en het gebruik van live gegevens (gevoelige informatie moet worden gemaskeerd), specificatie van testomgeving, kwalificatie van testers enz., En een evaluatiesessie met de belanghebbenden uitvoeren.
# 7) Productiestart van het gemigreerde systeem
Analyseer en documenteer de to-do lijst voor productiemigratie en publiceer deze ruim van tevoren
Verschillende fasen van migratie
Hieronder worden de verschillende fasen van migratie weergegeven.
Fase 1:Testen vóór migratie
Voordat de gegevens worden gemigreerd, wordt een reeks testactiviteiten uitgevoerd als onderdeel van de testfase vóór de migratie. Dit wordt genegeerd of er wordt geen rekening mee gehouden in eenvoudigere toepassingen. Maar wanneer complexe applicaties moeten worden gemigreerd, zijn de activiteiten voorafgaand aan de migratie een must.
Hieronder vindt u de lijst met acties die tijdens deze fase worden ondernomen:
- Stel een duidelijke reikwijdte van de gegevens in - welke gegevens moeten worden opgenomen, welke gegevens moeten worden uitgesloten, welke gegevens moeten worden getransformeerd / geconverteerd enz.
- Voer datamapping uit tussen legacy en de nieuwe applicatie - vergelijk voor elk type data in de legacy applicatie het relevante type in de nieuwe applicatie en breng ze vervolgens in kaart - Mapping op hoger niveau.
- Als de nieuwe applicatie het verplichte veld heeft, en het is niet het geval in legacy, zorg er dan voor dat de legacy dat veld niet als null heeft. - Mapping op een lager niveau.
- Bestudeer het gegevensschema van de nieuwe applicatie - veldnamen, typen, minimum- en maximumwaarden, lengte, verplichte velden, validaties op veldniveau enz., Duidelijk
- Een aantal tabellen in het legacysysteem moet worden genoteerd en als er tabellen worden verwijderd en toegevoegd na de migratie, moet dit worden geverifieerd.
- Een aantal records in elke tabel, views moeten worden genoteerd in de oude applicatie.
- Bestudeer de interfaces in de nieuwe applicatie en hun verbindingen. Gegevens die in de interface stromen, moeten sterk beveiligd zijn en niet kapot.
- Bereid testcases, testscenario's en use cases voor nieuwe omstandigheden in de nieuwe applicaties voor.
- Voer een reeks testcases en scenario's uit met een reeks gebruikers en bewaar de resultaten, logboeken opgeslagen. Hetzelfde moet worden geverifieerd na de migratie om ervoor te zorgen dat de verouderde gegevens en functionaliteit intact zijn.
- De telling van de gegevens en records moet duidelijk worden genoteerd, deze moet na de migratie worden geverifieerd om geen gegevens te verliezen.
Fase 2:Migratietesten
Migratiegids ’dat is opgesteld door het migratieteam moet strikt worden opgevolgd om de migratieactiviteit uit te voeren. Idealiter begint de migratieactiviteit met het maken van een back-up van de gegevens op de tape, zodat het oude systeem op elk moment kan worden hersteld.
Verifiëren van het documentatiegedeelte van ‘ Migration Guide ’maakt ook deel uit van Data Migration Testing Controleer of het document duidelijk en gemakkelijk te volgen is. Alle scripts en stappen moeten correct worden gedocumenteerd zonder enige dubbelzinnigheid. Elke vorm van documentatiefouten, missende overeenkomsten in de volgorde van uitvoering van de stappen moeten ook als belangrijk worden beschouwd, zodat ze kunnen worden gerapporteerd en opgelost.
Migratiescripts, handleidingen en andere informatie met betrekking tot de daadwerkelijke migratie moeten worden opgehaald uit de opslagplaats voor versiebeheer voor uitvoering.
Het noteren van de werkelijke tijd die nodig is voor de migratie vanaf het begin van de migratie tot het succesvol herstellen van het systeem, is een van de uit te voeren testcases en daarmee de ‘Tijd die nodig is om het systeem te migreren’ moet worden opgenomen in het definitieve testrapport dat zal worden geleverd als onderdeel van de migratietestresultaten en deze informatie zal nuttig zijn tijdens de productiestart. De downtime die in de testomgeving wordt geregistreerd, wordt geëxtrapoleerd om de geschatte downtime in het live systeem te berekenen.
Het is op het oude systeem waar de migratie-activiteit zal worden uitgevoerd.
Tijdens deze tests worden meestal alle componenten van de omgeving uitgeschakeld en uit het netwerk verwijderd om de migratieactiviteiten uit te voeren. Daarom is het noodzakelijk om de ‘Uitvaltijd’ vereist voor migratietest. Idealiter is het hetzelfde als dat van de migratietijd.
Over het algemeen omvat de migratieactiviteit die is gedefinieerd in de ‘Migratiegids’:
- Werkelijke migratie van de applicatie
- Firewalls, poorten, hosts, hardware, softwareconfiguraties worden allemaal gewijzigd volgens het nieuwe systeem waarop de legacy wordt gemigreerd
- Datalekken, veiligheidscontroles worden uitgevoerd
- De connectiviteit tussen alle componenten van de applicatie wordt gecontroleerd
Het is aan te raden dat de testers het bovenstaande verifiëren in de backend van het systeem of door middel van white box testen.
Zodra de migratieactiviteit die in de handleiding wordt gespecificeerd, is voltooid, worden alle servers opgestart en worden basistests met betrekking tot verificatie van succesvolle migratie uitgevoerd, wat ervoor zorgt dat alle end-to-end-systemen op de juiste manier zijn verbonden en dat alle componenten met elkaar praten. andere, DB is actief, front-end communiceert succesvol met de back-end. Deze tests moeten eerder worden geïdentificeerd en vastgelegd in het Migration Test Specification-document.
Er zijn mogelijkheden dat de software meerdere verschillende platforms ondersteunt. In dat geval moet de migratie op elk van deze platforms afzonderlijk worden geverifieerd.
Verificatie van migratiescripts maakt deel uit van de migratietest. Soms wordt het individuele migratiescript ook geverifieerd met ‘White box testing’ in een zelfstandige testomgeving.
Daarom zullen migratietests een combinatie zijn van zowel ‘white box- als black box-tests’.
Zodra deze migratie-gerelateerde verificatie is voltooid en de bijbehorende tests zijn geslaagd, kan het team verder gaan met de activiteit van post-migratietests.
Fase # 3:Testen na de migratie
Zodra de applicatie met succes is gemigreerd, komt Post-Migration-testen in beeld.
Hier worden end-to-end systeemtesten uitgevoerd in de testomgeving. Testers voeren geïdentificeerde testcases uit, testscenario's, use cases met legacy data en een nieuwe set data.
Daarnaast zijn er specifieke items die moeten worden geverifieerd in de gemigreerde omgevingen die hieronder worden vermeld:
Deze zijn allemaal gedocumenteerd als een testcase en opgenomen in het ‘Testspecificatie’ document.
- Controleer of alle data in de legacy binnen de geplande downtime naar de nieuwe applicatie is gemigreerd. Om dit te garanderen, vergelijkt u het aantal records tussen de oude en de nieuwe toepassing voor elke tabel en views in de database. Rapporteer ook de tijd die nodig is om bijvoorbeeld 10.000 records te verplaatsen.
- Controleer of alle schemawijzigingen (velden en tabellen toegevoegd of verwijderd) volgens het nieuwe systeem zijn bijgewerkt.
- Gegevens die zijn gemigreerd van de oude naar de nieuwe toepassing, moeten hun waarde en indeling behouden, tenzij hiervoor niet is gespecificeerd. Om dit te garanderen, vergelijkt u de gegevenswaarden tussen de verouderde en de nieuwe app-database.
- Test de gemigreerde gegevens met de nieuwe applicatie. Behandel hier een maximaal aantal mogelijke gevallen. Gebruik de geautomatiseerde testtool om 100% dekking te garanderen met betrekking tot gegevensmigratieverificatie.
- Controleer op databasebeveiliging.
- Controleer de gegevensintegriteit voor alle mogelijke voorbeeldrecords.
- Controleer en zorg ervoor dat de eerder ondersteunde functionaliteit in het oude systeem werkt zoals verwacht in het nieuwe systeem.
- Controleer de gegevensstroom binnen de applicatie die de meeste componenten omvat.
- De interface tussen de componenten moet uitgebreid worden getest, aangezien de gegevens niet mogen worden gewijzigd, verloren of beschadigd wanneer ze door componenten gaan. Om dit te verifiëren kunnen integratietestgevallen worden gebruikt.
- Controleer op redundantie van oude gegevens. Tijdens de migratie mogen er geen legacy-gegevens worden gedupliceerd
- Controleer op gevallen van niet-overeenkomende gegevens, zoals datatype gewijzigd, opslagformaat is gewijzigd enz.,
- Alle controles op veldniveau in de oude applicatie moeten ook in de nieuwe applicatie worden behandeld
- Elke toevoeging van gegevens in de nieuwe applicatie mag niet weerspiegelen in de legacy
- Het bijwerken van de gegevens van de verouderde app via de nieuwe app moet worden ondersteund. Eenmaal bijgewerkt in de nieuwe applicatie, zou het niet moeten reflecteren op de legacy.
- Het verwijderen van de gegevens van de oude applicatie in de nieuwe applicatie moet worden ondersteund. Eenmaal verwijderd in de nieuwe applicatie, mag het ook geen gegevens in legacy verwijderen.
- Controleer of de wijzigingen die aan het oude systeem zijn aangebracht, de nieuwe functionaliteit ondersteunen die als onderdeel van het nieuwe systeem wordt geleverd.
- Controleer of de gebruikers van het legacysysteem zowel de oude als de nieuwe functionaliteit kunnen blijven gebruiken, met name de functies waarbij de wijzigingen zijn betrokken. Voer de testcases en de testresultaten uit die zijn opgeslagen tijdens de Pre-migratietest.
- Maak nieuwe gebruikers aan op het systeem en voer tests uit om er zeker van te zijn dat de functionaliteit van zowel de legacy als de nieuwe applicatie de nieuw aangemaakte gebruikers ondersteunt en dat het prima werkt.
- Voer functionaliteitgerelateerde tests uit met een verscheidenheid aan gegevensmonsters (verschillende leeftijdsgroepen, gebruikers uit verschillende regio's enz.)
- Het is ook vereist om te controleren of ‘Feature Flags’ zijn ingeschakeld voor de nieuwe functies en door deze in / uit te schakelen, kunnen de functies worden in- en uitgeschakeld.
- Prestatietests zijn belangrijk om ervoor te zorgen dat migratie naar nieuw systeem / nieuwe software de prestaties van het systeem niet heeft verslechterd.
- Het is ook vereist om belastings- en stresstests uit te voeren om de stabiliteit van het systeem te garanderen.
- Controleer of de software-upgrade geen beveiligingsproblemen heeft veroorzaakt en voer daarom beveiligingstests uit, vooral in het gebied waar tijdens de migratie wijzigingen in het systeem zijn aangebracht.
- Bruikbaarheid is een ander aspect dat moet worden geverifieerd, waarbij, als de GUI-lay-out / front-end-systeem is veranderd of enige functionaliteit is veranderd, wat het gebruiksgemak is dat de eindgebruiker voelt in vergelijking met het oude systeem.
Aangezien de reikwijdte van Post-Migration-tests erg groot wordt, is het ideaal om de belangrijke tests die moeten worden uitgevoerd eerst te scheiden om te kwalificeren dat de migratie succesvol is en vervolgens de resterende tests later uit te voeren.
Het is ook raadzaam om de end-to-end functionele testgevallen en andere mogelijke testgevallen te automatiseren, zodat de testtijd kan worden verkort en de resultaten snel beschikbaar zijn.
Enkele tips voor testers voor het schrijven van testcases voor uitvoering na migratie:
- Wanneer de applicatie wordt gemigreerd, betekent dit niet dat de testcases voor de hele nieuwe applicatie moeten worden geschreven. Testcases die al voor de legacy zijn ontworpen, moeten nog steeds gelden voor de nieuwe toepassing. Maak dus zoveel mogelijk gebruik van de oude testcases en zet de legacy testcases waar nodig om naar de cases van een nieuwe applicatie.
- Als er een wijziging in de functie is in de nieuwe toepassing, moeten testcases met betrekking tot de functie worden gewijzigd.
- Als er een nieuwe functie is toegevoegd in de nieuwe applicatie, moeten nieuwe testcases worden ontworpen voor die specifieke functie.
- Wanneer er een functiedaling in de nieuwe applicatie optreedt, mogen testcases van gerelateerde legacy applicaties niet in overweging worden genomen voor uitvoering na de migratie, en moeten ze worden gemarkeerd als ongeldig en apart worden gehouden.
- Ontworpen testcases moeten altijd betrouwbaar en consistent zijn in termen van gebruik. Verificatie van kritieke gegevens moet worden behandeld in testgevallen, zodat deze niet worden gemist tijdens het uitvoeren.
- Wanneer het ontwerp van de nieuwe applicatie verschilt van dat van de legacy (UI), dan moeten de UI-gerelateerde testgevallen worden aangepast om het nieuwe ontwerp aan te passen. De beslissing om in dit geval bij te werken of nieuwe te schrijven, kan door de tester worden genomen op basis van het aantal wijzigingen dat is opgetreden.
Testen van achterwaartse compatibiliteit
Migratie van het systeem vereist ook dat de testers de ‘Backward Compatibility’ verifiëren, waarbij het geïntroduceerde nieuwe systeem compatibel is met het oude systeem (minstens 2 eerdere versies) en ervoor zorgt dat het perfect functioneert met die versies.
Achterwaartse compatibiliteit is om te zorgen voor:
- Of het nieuwe systeem de functionaliteit ondersteunt die in eerdere 2 versies werd ondersteund, samen met de nieuwe.
- Het systeem kan met succes worden gemigreerd van de eerdere 2 versies zonder gedoe.
Daarom is het essentieel om de achterwaartse compatibiliteit van het systeem te waarborgen door specifiek de tests uit te voeren die betrekking hebben op de ondersteuning van achterwaartse compatibiliteit. De tests met betrekking tot achterwaartse compatibiliteit moeten worden ontworpen en opgenomen in het testspecificatiedocument voor uitvoering.
Rollback-testen
In het geval van problemen tijdens het uitvoeren van de migratie of als er op enig moment tijdens de migratie een migratiefout optreedt, moet het mogelijk zijn dat het systeem teruggaat naar het oude systeem en zijn functie snel hervat zonder de gebruikers te beïnvloeden en de functionaliteit die eerder werd ondersteund.
Om dit te verifiëren, moeten testscenario's voor migratiefouten worden ontworpen als onderdeel van negatieve tests en moet het terugdraaimechanisme worden getest. De totale tijd die nodig is om terug te gaan naar het oude systeem, moet ook worden geregistreerd en gerapporteerd in de testresultaten.
Na rollback, de belangrijkste functionaliteit en de regressietesten (geautomatiseerd) moet worden uitgevoerd om ervoor te zorgen dat de migratie niets heeft beïnvloed en dat rollback erin slaagt het oude systeem weer op zijn plaats te brengen.
Overzichtsrapport migratietest
Het testoverzichtsrapport moet worden geproduceerd na voltooiing van de tests en moet het rapport bevatten over de samenvatting van de verschillende tests / scenario's die zijn uitgevoerd als onderdeel van verschillende fasen van de migratie met de resultaatstatus (geslaagd / mislukt) en de testlogboeken.
De geregistreerde tijd voor de volgende activiteiten moet duidelijk worden gerapporteerd:
- Totale tijd voor migratie
- Stilstand van de applicaties
- Tijd besteed aan het migreren van 10.000 records.
- Tijd besteed aan rollback.
Naast bovenstaande informatie kunnen ook eventuele observaties / aanbevelingen worden gerapporteerd.
Uitdagingen bij het testen van gegevensmigratie
Uitdagingen bij deze tests hebben voornamelijk betrekking op gegevens. Hieronder staan er een paar in de lijst:
# 1) Gegevenskwaliteit:
Het is mogelijk dat de gegevens die in de oude applicatie worden gebruikt, van slechte kwaliteit zijn in de nieuwe / geüpgradede applicatie. In dergelijke gevallen moet de datakwaliteit worden verbeterd om aan de zakelijke normen te voldoen.
Factoren zoals aannames, dataconversies na migraties, data ingevoerd in de legacy applicatie zelf zijn ongeldig, slechte data-analyse etc. leiden tot een slechte datakwaliteit. Dit leidt tot hoge operationele kosten, verhoogde risico's voor data-integratie en afwijking van het bedrijfsdoel.
# 2) Gegevens komen niet overeen:
Gegevens die zijn gemigreerd van de oude naar de nieuwe / geüpgradede applicatie, komen mogelijk niet overeen in de nieuwe. Dit kan te wijten zijn aan de verandering in het gegevenstype, het formaat van de gegevensopslag, het doel waarvoor de gegevens worden gebruikt, kan opnieuw worden gedefinieerd.
Dit resulteert in een enorme inspanning om de noodzakelijke wijzigingen aan te passen om de niet-overeenkomende gegevens te corrigeren of deze te accepteren en aan dat doel aan te passen.
# 3) Gegevensverlies:
Er kunnen gegevens verloren gaan tijdens het migreren van de oude naar de nieuwe / geüpgradede applicatie. Dit kan zijn met verplichte velden of niet-verplichte velden. Als de verloren gegevens voor niet-verplichte velden zijn, is het record ervoor nog steeds geldig en kan het opnieuw worden bijgewerkt.
Maar als de gegevens van het verplichte veld verloren gaan, wordt het record zelf ongeldig en kan het niet worden ingetrokken. Dit zal resulteren in enorm gegevensverlies en zou moeten worden opgehaald uit de back-updatabase of auditlogboeken als het correct is vastgelegd.
# 4) Gegevensvolume:
Enorme gegevens die veel tijd nodig hebben om te migreren binnen het downtime-venster van de migratieactiviteit. Bijv .: Krasloten in de telecom-industrie, gebruikers op een intelligent netwerkplatform enz., Hier is de uitdaging dat tegen de tijd dat de oude gegevens worden gewist, er enorme nieuwe gegevens zullen worden gecreëerd die opnieuw moeten worden gemigreerd. Automatisering is de oplossing voor enorme datamigratie.
# 5) Simulatie van een real-time omgeving (met de feitelijke gegevens):
Simulatie van een real-time omgeving in het testlaboratorium is een andere echte uitdaging, waar testers in verschillende soorten problemen terechtkomen met de echte gegevens en het echte systeem, die tijdens het testen niet voorkomen.
Dus gegevensbemonstering, replicatie van de echte omgeving, identificatie van de hoeveelheid gegevens die bij migratie is betrokken, is vrij belangrijk tijdens het uitvoeren van datamigratietests.
# 6) Simulatie van het datavolume:
Teams moeten de gegevens in het live-systeem zeer zorgvuldig bestuderen en moeten de typische analyse en steekproeven van de gegevens bedenken.
Bijv .: gebruikers met een leeftijdsgroep onder de 10 jaar, 10-30 jaar enz., Voor zover mogelijk moeten gegevens van het leven worden verkregen, zo niet moet het aanmaken van gegevens in de testomgeving worden gedaan. Er moeten geautomatiseerde tools worden gebruikt om een grote hoeveelheid gegevens te creëren. Extrapolatie, waar van toepassing, kan worden gebruikt als het volume niet kan worden gesimuleerd.
Tips om de risico's van datamigratie te verminderen
Hieronder worden enkele tips gegeven die moeten worden uitgevoerd om de risico's van datamigratie te verminderen:
- Standaardiseer gegevens die worden gebruikt in een legacy-systeem, zodat bij migratie standaardgegevens beschikbaar zijn in een nieuw systeem
- Verbeter de kwaliteit van de gegevens, zodat er bij het migreren kwalitatieve gegevens zijn om te testen die het gevoel geven dat je als eindgebruiker test
- Maak de gegevens schoon voordat u migreert, zodat bij het migreren geen dubbele gegevens in het nieuwe systeem aanwezig zijn en ook dit houdt het hele systeem schoon
- Controleer opnieuw de beperkingen, opgeslagen procedures, complexe zoekopdrachten die nauwkeurige resultaten opleveren, zodat bij migratie ook de juiste gegevens in het nieuwe systeem worden geretourneerd
- Identificeer de juiste automatiseringstool om gegevenscontroles / recordcontroles uit te voeren in het nieuwe systeem in vergelijking met het oude.
Gevolgtrekking
Gezien de complexiteit die het uitvoeren van datamigratietests met zich meebrengt, en in gedachten houdend dat een kleine fout in elk aspect van de verificatie tijdens het testen zal leiden tot het risico van mislukking van de migratie bij de productie, is het erg belangrijk om een zorgvuldig en grondig onderzoek uit te voeren. & analyse van het systeem voor en na migratie. Plan en ontwerp de effectieve migratiestrategie met de robuuste tools samen met bekwame en getrainde testers.
Omdat we weten dat migratie een enorme impact heeft op de kwaliteit van de applicatie, moet er door het hele team veel moeite worden gedaan om het hele systeem te verifiëren op alle aspecten, zoals functionaliteit, prestaties, beveiliging, bruikbaarheid, beschikbaarheid, betrouwbaarheid, compatibiliteit. etc., die op hun beurt zorgen voor een succesvolle 'Migration Testing'.
‘Verschillende soorten migraties’ dat gebeurt in de praktijk meestal vrij vaak en de manieren om met hun testen om te gaan, zullen kort worden uitgelegd in ons volgende tutorial in deze serie
Over de Auteurs: Deze handleiding is geschreven door STH Author Nandini. Ze heeft meer dan 7 jaar ervaring in het testen van software. Ook dank aan STH-auteur Gayathri S. voor het beoordelen en verstrekken van haar waardevolle suggesties voor het verbeteren van deze serie. Gayathri heeft 18+ jaar ervaring in softwareontwikkeling en testdiensten.
Laat ons uw opmerkingen / suggesties over deze tutorial weten.
objecten opslaan in een array java
Aanbevolen literatuur
- ETL-testen Tutorial datawarehouse-testen (een complete gids)
- Alfatesten en bètatesten (een complete gids)
- Functioneel testen versus niet-functioneel testen
- Typen migratietests: met testscenario's voor elk type
- Tutorial over bruikbaarheidstesten: een complete handleiding om aan de slag te gaan
- 13 beste tools voor gegevensmigratie voor volledige gegevensintegriteit [2021 LIST]
- Build Verification Testing (BVT Testing) Complete Guide
- Beste softwaretesttools 2021 [QA Test Automation Tools]