data migration testing tutorial
Oversigt over test af datamigrering:
Det høres ofte, at en applikation flyttes til en anden server, teknologien ændres, den opdateres til den næste version eller flyttes til en anden databaseserver osv.,
- Hvad betyder dette egentlig?
- Hvad forventes der af testteamet i disse situationer?
Fra testperspektivet betyder det hele, at applikationen skal testes grundigt end-to-end sammen med migration fra det eksisterende system til det nye system med succes.
Selvstudier i denne serie:
Systemtest skal i dette tilfælde udføres med alle de data, der bruges i en gammel applikation og de nye data også. Eksisterende funktionalitet skal verificeres sammen med den nye / ændrede funktionalitet.
I stedet for kun migreringstest kan det også betegnes som datamigreringstest, hvor hele brugerens data migreres til et nyt system.
Så migrationstest inkluderer test med gamle data, nye data eller en kombination af begge, gamle funktioner (uændrede funktioner) og de nye funktioner.
Gammel applikation kaldes normalt som ' eftermæle ' Ansøgning. Sammen med ny / opgraderet applikation er det også obligatorisk at fortsætte med at teste ældre applikationer, indtil de nye / opgraderede bliver stabile og konsistente. Omfattende migrationstest på ny applikation afslører de nye problemer, der ikke blev fundet i den ældre applikation.
Hvad du vil lære:
- Hvad er migrationstest?
- Hvorfor migrationsprøve?
- Hvornår er denne test påkrævet?
- Strategi til test af datamigration
- Forskellige faser af migration
- Test af bagudkompatibilitet
- Tilbageførselstest
- Migration Test Summary Report
- Udfordringer i test af datamigrering
- Tips til at udjævne datamigrationsrisikoen
- Konklusion
- Anbefalet læsning
Hvad er migrationstest?
Migration Testing er en verificeringsproces af migrering af det ældre system til det nye system med minimal afbrydelse / nedetid, med dataintegritet og intet tab af data, samtidig med at det sikres, at alle de specificerede funktionelle og ikke-funktionelle aspekter af applikationen er opfyldt efter migration.
Enkel repræsentation af migrationssystemet:
Hvorfor migrationsprøve?
Som vi ved, kan applikationsmigrationen til et nyt system være af forskellige årsager, systemkonsolidering, forældet teknologi, optimering eller andre grunde.
Derfor, mens systemet i brug skal migreres til et nyt system, er det vigtigt at sikre nedenstående punkter:
- Enhver form for forstyrrelse / ulejlighed forårsaget af brugeren på grund af migration skal undgås / minimeres. F.eks .: nedetid, tab af data
- Behov for at sikre, om brugeren kan fortsætte med at bruge alle softwarefunktionerne ved at forårsage minimal eller ingen skade under migrering. F.eks .: ændring i funktionaliteten, fjernelse af en bestemt funktionalitet
- Det er også vigtigt at foregribe og udelukke alle mulige fejl / forhindringer, der kan opstå under den aktuelle migration af det levende system.
Derfor er det vigtigt at udføre migreringstest i laboratoriet for at sikre en jævn migration af det levende system ved at eliminere disse defekter.
Denne testning har sin egen betydning, og den spiller en vigtig rolle, når dataene kommer ind i billedet.
Teknisk set er det også nødvendigt at udføres til nedenstående formål:
- For at sikre kompatibilitet af den nye / opgraderede applikation med al mulig hardware og software, som den ældre applikation understøtter. Også nyt kompatibilitet skal også testes for ny hardware, softwareplatform.
- For at sikre, at alle eksisterende funktioner fungerer som i den ældre applikation. Der må ikke være nogen ændring i måden, hvorpå applikationen fungerer sammenlignet med den ældre.
- Muligheden for et stort antal defekter på grund af migration er meget høj. Mange af manglerne vil normalt være relateret til data, og derfor skal disse mangler identificeres og løses under testningen.
- For at sikre, om systemets responstid for den nye / opgraderede applikation er den samme eller mindre end det, der kræves for den ældre applikation.
- For at sikre, om forbindelsen mellem servere, hardware, software osv. Er intakt og ikke afbrydes under test. Datastrøm mellem forskellige komponenter bør ikke brydes under nogen omstændigheder.
Hvornår er denne test påkrævet?
Test skal udføres både før og efter migrering.
De forskellige faser af migrationstesten der skal udføres på testlaboratoriet kan klassificeres som nedenfor.
- Test før migrering
- Migrationstest
- Test efter postmigration
Ud over ovenstående er den følgende tests udføres også som en del af hele migrationsaktiviteten.
- Bekræftelse af bagudkompatibilitet
- Tilbageførselstest
Før denne test udføres, er det vigtigt for enhver tester at forstå nedenstående punkter klart:
- Ændringerne sker som en del af det nye system (server, frontend, DB, skema, datastrøm, funktionalitet osv.,)
- At forstå den egentlige migrationsstrategi, der er fastlagt af holdet. Hvordan migrationen sker, trin for trin sker der ændringer i systemets backend og de scripts, der er ansvarlige for disse ændringer.
Derfor er det vigtigt at foretage en grundig undersøgelse af det gamle og det nye system og derefter planlægge og designe testcases og testscenarier, der skal dækkes som en del af ovenstående testfaser og forberede teststrategien.
Strategi til test af datamigration
Design af teststrategien for migration inkluderer et sæt aktiviteter, der skal udføres, og få aspekter, der skal overvejes. Dette er for at minimere de fejl og risici, der opstår som et resultat af migrering, og for at udføre migreringstesten effektivt.
Aktiviteter i denne test:
# 1) Specialiseret holddannelse :
Dann testteamet med medlemmerne, der har den krævede viden og erfaring, og sørg for træning relateret til det system, der migreres.
#to) Forretningsrisikoanalyse, mulig analyse af fejl :
Nuværende forretning bør ikke hæmmes efter migration og udfører derfor ' Analyse af forretningsrisici ' møder, der involverer de rigtige interessenter (Test Manager, Business Analyst, Architects, Product Owners, Business Owner osv.), og identificerer risici og implementerbare afbødninger. Testen skal omfatte scenarier for at afdække disse risici og kontrollere, om de korrekte afbødninger er implementeret.
Opførelse ' Mulig fejlanalyse ' ved hjælp af passende 'Fejl gætte fremgangsmåder' og design derefter test omkring disse fejl for at finde dem under test.
sql server spørgsmål og svar til erfarne
# 3) Analyse og identifikation af migrationsomfang:
Analyser det klare omfang af migrationstesten, hvornår og hvad der skal testes.
# 4) Identificer det passende værktøj til migration:
Mens du definerer strategien for denne test, automatisk eller manuel, skal du identificere de værktøjer, der skal bruges. For eksempel: Automatiseret værktøj til at sammenligne kilde- og destinationsdata.
# 5) Identificer det relevante testmiljø til migration:
Identificer separate miljøer til miljøer før og efter migration for at udføre enhver verifikation, der kræves som en del af testningen. Forstå og dokumentere de tekniske aspekter af Legacy and New Migration-systemet for at sikre, at testmiljøet er konfigureret i henhold til det.
# 6) Dokument og gennemgang af specifikation for migreringstest:
Forbered Migration Test Specification document, der tydeligt beskriver testmetoden, testområder, testmetoder (automatiseret, manuel), testmetodologi (sort boks, hvid boks testteknik ), Antal testcyklusser, testplan, tilgang til oprettelse af data og brug af live data (følsom info skal maskeres), testmiljøspecifikation, testerkvalifikation osv., Og køre en gennemgangssession med interessenterne.
# 7) Produktionsstart af det migrerede system :
Analyser og dokumenter to-do-listen til produktionsmigration, og offentliggør den i god tid
Forskellige faser af migration
Nedenfor er de forskellige faser af migration.
Fase 1:Test før migrering
Inden migrering af dataene udføres sæt testaktiviteter som en del af testfasen før migrering. Dette ignoreres eller overvejes ikke i enklere applikationer. Men når komplekse applikationer skal migreres, er aktiviteterne før migrering et must.
Nedenfor er listen over handlinger, der gennemføres i denne fase:
- Angiv et klart omfang af dataene - hvilke data der skal medtages, hvilke data der skal ekskluderes, hvilke data der skal transformeres / konverteres osv.
- Udfør datakortlægning mellem ældre og den nye applikation - for hver type data i den ældre applikation skal du sammenligne den relevante type i den nye applikation og derefter kortlægge dem - Kortlægning på højere niveau.
- Hvis den nye applikation har det obligatoriske felt, og det ikke er tilfældet i arv, og sørg for, at arven ikke har dette felt som null. - Kortlægning på lavere niveau.
- Undersøg den nye applikations dataskema - feltnavne, typer, minimums- og maksimumværdier, længde, obligatoriske felter, feltniveauvalideringer osv., Klart
- Et antal tabeller i det ældre system skal noteres, og hvis der tabes tabeller, og tilføjelse efter migrering skal bekræftes.
- Et antal poster i hver tabel, visninger skal noteres i den ældre ansøgning.
- Undersøg grænsefladerne i den nye applikation og deres forbindelser. Data, der flyder i grænsefladen, skal være meget sikret og ikke brudt.
- Forbered testsager, testscenarier og brug sager til nye forhold i de nye applikationer.
- Udfør et sæt testsager, scenarier med et sæt brugere, og hold resultaterne, logfilerne gemt. Det samme skal verificeres efter migrering for at sikre, at ældre data og funktionalitet er intakte.
- Antallet af data og poster skal noteres tydeligt, det skal verificeres efter migrering uden tab af data.
Fase 2:Migrationstest
'' Migration Guide 'som er udarbejdet af migrationsteamet skal følges nøje for at udføre migrationsaktiviteten. Ideelt set begynder migrationsaktiviteten med, at dataene sikkerhedskopieres på båndet, så det gamle system når som helst kan gendannes.
Bekræftelse af dokumentationsdelen af ' Migration Guide 'er også en del af datamigrationstest . Kontroller, om dokumentet er klart og let at følge. Alle scripts og trin skal dokumenteres korrekt uden tvetydighed. Enhver form for dokumentationsfejl, miss-matches i rækkefølgen af udførelse af trin skal også betragtes som vigtige, så de kan rapporteres og rettes.
Migrationsskripts, vejledning og anden information relateret til faktisk migration skal hentes fra versionskontroldatabasen til udførelse.
At notere den faktiske tid, der er taget for migrering fra startpunktet for migrering til vellykket gendannelse af systemet, er en af de testsager, der skal udføres, og dermed 'Det tager tid at migrere systemet' skal registreres i den endelige testrapport, som vil blive leveret som en del af Migration-testresultaterne, og disse oplysninger vil være nyttige under produktionsstart. Den nedetid, der er registreret i testmiljøet, ekstrapoleres for at beregne den omtrentlige nedetid i live-systemet.
Det er på det gamle system, hvor migrationsaktiviteten udføres.
Under denne test vil alle komponenter i miljøet normalt blive bragt ned og fjernet fra netværket for at udføre migrationsaktiviteterne. Derfor er det nødvendigt at bemærke 'Nedetid' krævet til migrationstest. Ideelt set vil det være det samme som for migreringstiden.
Generelt inkluderer migrationsaktivitet defineret i dokumentet 'Migreringsvejledning':
- Faktisk migrering af applikationen
- Firewalls, port, værter, hardware, softwarekonfigurationer ændres alle i henhold til det nye system, som arven migreres på
- Datalækager, sikkerhedskontrol udføres
- Forbindelsen mellem alle applikationens komponenter kontrolleres
Det tilrådes for testerne at kontrollere ovenstående i systemets bagende eller ved at udføre test af hvid boks.
Når migrationsaktiviteten, der er specificeret i vejledningen, er afsluttet, bliver alle serverne bragt op, og der udføres grundlæggende tests relateret til verifikation af vellykket migration, hvilket sikrer, at alle ende-til-slut-systemer er tilsluttet korrekt, og alle komponenterne taler til hver andet, DB er i gang, frontend kommunikerer med backenden med succes. Disse tests skal identificeres tidligere og registreres i Migration Test Specification-dokumentet.
Der er muligheder for, at softwaren understøtter flere forskellige platforme. I et sådant tilfælde skal migrering verificeres på hver af disse platforme separat.
Bekræftelse af migrationsskripter vil være en del af migreringstesten. Nogle gange verificeres individuelt migrationsscript også ved hjælp af 'White box-test' i et enkeltstående testmiljø.
Derfor er migrationstest en kombination af både 'hvid boks og sort boks test'.
Når denne migrationsrelaterede verifikation er udført, og tilsvarende test er bestået, kan teamet gå videre med aktiviteten af test efter postmigration.
Fase 3:Test efter migration
Når applikationen er migreret med succes, kommer test efter indvandring ind i billedet.
Her udføres end-to-end systemtest i testmiljøet. Testere udfører identificerede testsager, testscenarier, bruger sager med ældre data samt et nyt datasæt.
Ud over disse er der specifikke emner, der skal verificeres i de migrerede miljøer, der er anført nedenfor:
Alle disse er dokumenteret som en test case og inkluderet i dokumentet 'Test Specification'.
- Kontroller, om alle data i arven migreres til den nye applikation inden for den planlagte nedetid. For at sikre dette skal du sammenligne antallet af poster mellem arv og den nye applikation for hver tabel og visninger i databasen. Rapporter også den tid, det tog at flytte sig, siger 10000 poster.
- Kontroller, om alle skemaændringer (felter og tabeller tilføjet eller fjernet) i henhold til det nye system er opdateret.
- Data, der er migreret fra arven til den nye applikation, skal bevare sin værdi og format, medmindre det ikke er specificeret at gøre det. For at sikre dette skal du sammenligne dataværdier mellem ældre og den nye applikations database.
- Test de migrerede data mod den nye applikation. Her dækker et maksimalt antal mulige sager. Brug det automatiske testværktøj for at sikre 100% dækning med hensyn til verificering af datamigrering.
- Kontroller for databasesikkerhed.
- Kontroller for dataintegritet for alle mulige prøveoptegnelser.
- Kontroller og sørg for, at den tidligere understøttede funktionalitet i det ældre system fungerer som forventet i det nye system.
- Kontroller datastrømmen inden for applikationen, der dækker de fleste komponenter.
- Grænsefladen mellem komponenterne skal testes grundigt, da data ikke skal modificeres, mistes og ødelægges, når de gennemgår komponenter. Integrationstestsager kan bruges til at verificere dette.
- Kontroller, om ældre data er overflødige. Ingen ældre data skal duplikeres selv under migrering
- Kontroller, om data ikke stemmer overens, f.eks. Ændret datatype, lagringsformat ændres osv.,
- Alle kontrol på feltniveau i den ældre ansøgning skal også være omfattet af den nye ansøgning
- Enhver tilføjelse af data i den nye applikation skal ikke afspejle arven
- Opdatering af ældre applikations data gennem den nye applikation skal understøttes. Når den er opdateret i den nye applikation, skal den ikke afspejle arven igen.
- Sletning af den ældre applikations data i den nye applikation skal understøttes. Når det først er slettet i det nye program, skal det heller ikke slette data i arv.
- Kontroller, at de ændringer, der er foretaget i det ældre system, understøtter den nye funktionalitet, der leveres som en del af det nye system.
- Bekræft, at brugerne fra det ældre system kan fortsætte med at bruge både den gamle funktionalitet og den nye funktionalitet, især dem, hvor ændringerne er involveret. Udfør testsagerne og testresultaterne, der er gemt under testen før migrering.
- Opret nye brugere på systemet og udfør test for at sikre, at funktionalitet fra arven såvel som den nye applikation understøtter de nyoprettede brugere, og det fungerer fint.
- Udfør funktionsrelaterede tests med en række dataprøver (forskellige aldersgrupper, brugere fra forskellige regioner osv.)
- Det er også nødvendigt at kontrollere, om 'Feature Flags' er aktiveret for de nye funktioner, og ved at tænde / slukke for det, kan funktionerne tænde og slukke.
- Test af ydeevne er vigtig for at sikre, at migration til nyt system / software ikke har forringet systemets ydeevne.
- Det er også nødvendigt at udføre belastnings- og stresstest for at sikre systemets stabilitet.
- Kontroller, at softwareopgraderingen ikke har åbnet sikkerhedssårbarheder, og udfør derfor sikkerhedstest, især i det område, hvor der er foretaget ændringer i systemet under migrering.
- Brugervenlighed er et andet aspekt, der skal verificeres, hvor hvis GUI-layout / front-end-system er ændret, eller en hvilken som helst funktionalitet er ændret, hvad er den brugervenlighed, som slutbrugeren føler i forhold til det ældre system.
Da omfanget af test efter postmigration bliver meget stort, er det ideelt at adskille de vigtige tests, der skal udføres først for at kvalificere, at migrering er vellykket, og derefter udføre de resterende senere.
Det tilrådes også at automatisere slut-til-slut funktionelle testtilfælde og andre mulige testtilfælde, så testtiden kan reduceres, og resultaterne vil være tilgængelige hurtigt.
Få tip til testere til at skrive testsagerne til udførelse efter migrering:
- Når applikationen migreres, betyder det ikke, at testsagerne skal skrives til den helt nye applikation. Testtilfælde, der allerede er designet til arven, skal stadig vare godt for den nye applikation. Så så vidt muligt skal du bruge de gamle testsager og konvertere de ældre testsager til en ny applikations sager, hvor det er nødvendigt.
- Hvis der er ændringer i funktion i den nye applikation, skal testsager relateret til funktionen ændres.
- Hvis der er tilføjet nogen ny funktion i den nye applikation, skal nye testtilfælde designes til den pågældende funktion.
- Når der er noget funktionsfald i den nye applikation, skal relaterede ældre applikations testsager ikke overvejes til udførelse efter migrering, og de skal markeres som ikke gyldige og holdes adskilt.
- Testkasser designet skal altid være pålidelige og konsistente med hensyn til brug. Verifikation af kritiske data skal dækkes i testtilfælde, så de ikke går glip af under udførelsen.
- Når designet til den nye applikation adskiller sig fra arven (UI), skal de UI-relaterede testsager ændres for at tilpasse det nye design. Beslutningen om enten at opdatere eller skrive nye kan i dette tilfælde tages af testeren baseret på den ændringsvolumen, der skete.
Test af bagudkompatibilitet
Migrering af systemet opfordrer også testere til at kontrollere 'bagudkompatibilitet', hvor det nye system, der introduceres, er kompatibelt med det gamle system (mindst 2 tidligere versioner) og sikrer, at det fungerer perfekt med disse versioner.
Bagudkompatibilitet er at sikre:
- Uanset om det nye system understøtter den funktionalitet, der understøttes i tidligere 2 versioner sammen med den nye.
- Systemet kan migreres med succes fra de tidligere 2 versioner uden besvær.
Derfor er det vigtigt at sikre systemets bagudkompatibilitet ved specifikt at udføre testene relateret til bagudkompatibilitet. Testene relateret til bagudkompatibilitet skal designes og inkluderes i testspecifikationsdokumentet til udførelse.
Tilbageførselstest
I tilfælde af problemer under udførelsen af overførslen, eller hvis der er et migrationsfejl på et hvilket som helst tidspunkt under overførslen, skulle det være muligt for systemet at rulle tilbage til det ældre system og genoptage dets funktion hurtigt uden at påvirke brugerne og den tidligere understøttede funktionalitet.
Så for at bekræfte dette skal migrationsfejl testscenarier designes som en del af negativ test, og tilbagekoblingsmekanisme skal testes. Den samlede tid, der kræves for at genoptage tilbage til det ældre system, skal også registreres og rapporteres i testresultaterne.
Efter tilbageførsel, den vigtigste funktionalitet og regressionstest (automatiseret) bør køres for at sikre, at migration ikke har påvirket noget, og tilbagevenden er en succes med at bringe det ældre system tilbage.
Migration Test Summary Report
Testoversigtsrapporten skal produceres efter afslutning af testen og skal dække rapporten om resuméet af de forskellige tests / scenarier, der er udført som en del af forskellige migrationsfaser med resultatstatus (bestået / ikke bestået) og testlogfiler.
Tid registreret for følgende aktiviteter skal rapporteres tydeligt:
- Samlet tid til migration
- Nedetid for applikationerne
- Tid brugt til at migrere 10000 poster.
- Tid brugt til tilbageførsel.
Ud over ovenstående oplysninger kan eventuelle observationer / anbefalinger også rapporteres.
Udfordringer i test af datamigrering
Udfordringerne ved denne test er hovedsageligt med data. Nedenfor er der få på listen:
# 1) Datakvalitet:
Vi kan finde ud af, at de data, der bruges i den ældre applikation, har dårlig kvalitet i den nye / opgraderede applikation. I sådanne tilfælde skal datakvaliteten forbedres for at opfylde forretningsstandarder.
Faktorer som antagelser, datakonverteringer efter migreringer, data, der er indtastet i selve den ældre applikation, er ugyldige, dårlig dataanalyse osv. Fører til dårlig datakvalitet. Dette resulterer i høje driftsomkostninger, øgede dataintegrationsrisici og afvigelse fra forretningsformålet.
# 2) Dataoverensstemmelse:
Data, der er migreret fra arven til den nye / opgraderede applikation, kan blive fundet uoverensstemmende i den nye. Dette kan skyldes ændring i datatype, format på datalagring, det formål, hvortil dataene bruges, kan omdefineres.
Dette resulterer i en enorm indsats for at ændre de nødvendige ændringer for enten at rette de uoverensstemmende data eller acceptere dem og justere til dette formål.
# 3) Datatab:
Data går muligvis tabt under migrering fra arven til den nye / opgraderede applikation. Dette kan være med obligatoriske felter eller ikke-obligatoriske felter. Hvis de mistede data er for ikke-obligatoriske felter, vil registreringen for dem stadig være gyldig og kan opdateres igen.
java programmering interview spørgsmål og svar til freshers
Men hvis det obligatoriske felts data går tabt, bliver selve posten ugyldig, og de kan ikke trækkes tilbage. Dette vil resultere i enorme datatab og skal hentes enten fra backup-databasen eller auditlogfiler, hvis de fanges korrekt.
# 4) Datavolumen:
Enorme data, der kræver meget tid at migrere inden for nedetidstiden for migrationsaktiviteten. For eksempel: Skrabekort i telekommunikationsindustrien, brugere på en intelligent netværksplatform osv. Her er udfordringen på det tidspunkt, de ældre data ryddes, der oprettes en enorm ny data, som skal migreres igen. Automatisering er løsningen til enorm datamigrering.
# 5) Simulering af et realtidsmiljø (med de faktiske data):
Simulation af et realtidsmiljø i testlaboratoriet er en anden reel udfordring, hvor testere kommer ind i forskellige slags problemer med de rigtige data og det virkelige system, som ikke står over for under testningen.
Så dataudtagning, replikering af ægte miljø, identifikation af datamængden, der er involveret i migration, er ret vigtig, når der udføres datamigrationstest.
# 6) Simulering af datamængden:
Hold har brug for at studere dataene i live-systemet meget nøje og skulle komme med den typiske analyse og stikprøvetagning af dataene.
For eksempel: brugere med aldersgruppe under 10 år, 10-30 år osv. Så vidt muligt skal der hentes data fra live, hvis ikke dataoprettelse skal ske i testmiljøet. Automatiske værktøjer skal bruges til at skabe en stor datamængde. Ekstrapolering kan, hvor det er relevant, anvendes, hvis lydstyrken ikke kan simuleres.
Tips til at udjævne datamigrationsrisikoen
Nedenfor er der få tip, der skal udføres for at udjævne datamigrationsrisikoen:
- Standardiser data, der bruges i ældre systemer, så standarddata vil være tilgængelige i nyt system, når de migreres
- Forbedre kvaliteten af dataene, så når der migreres, er der kvalitative data til test, der giver følelsen af at teste som slutbruger
- Rengør dataene inden migrering, så når der migreres, vil der ikke være duplikatdata i det nye system, og det holder også hele systemet rent
- Kontroller begrænsningerne, lagrede procedurer, komplekse forespørgsler, der giver nøjagtige resultater, så når de overføres, returneres korrekte data også i det nye system
- Identificer korrekt automatiseringsværktøj til at udføre datakontrol / registreringskontrol i det nye system i sammenligning med arven.
Konklusion
Derfor er det meget vigtigt at udføre omhyggelig og grundig undersøgelse i betragtning af den kompleksitet, der er involveret i udførelsen af datamigrationstestning, idet man husker, at et lille miss i ethvert aspekt af verifikation under testning vil føre til risikoen for migrationsfejl ved produktionen. & analyse af systemet før og efter migration. Planlæg og design den effektive migrationsstrategi med de robuste værktøjer sammen med dygtige og uddannede testere.
Da vi ved, at migrering har en enorm indflydelse på applikationens kvalitet, skal hele teamet lægge en stor indsats for at verificere hele systemet i alle aspekter som funktionalitet, ydeevne, sikkerhed, brugervenlighed, tilgængelighed, pålidelighed, kompatibilitet osv., hvilket igen vil sikre vellykket 'Migration Testing'.
'Forskellige typer migrationer' der sker typisk ganske ofte i virkeligheden, og måderne til at håndtere deres test vil blive forklaret kort i vores næste tutorial i denne serie .
Om forfatterne: Denne guide er skrevet af STH-forfatter Nandini. Hun har 7+ års erfaring med softwaretest. Også tak til STH-forfatter Gayathri S. for at have gennemgået og leveret sine valubale-forslag til forbedring af denne serie. Gayathri har 18+ års erfaring inden for softwareudvikling og testtjenester.
Fortæl os dine kommentarer / forslag til denne tutorial.
Anbefalet læsning
- ETL Testing Data Warehouse Testing Tutorial (En komplet guide)
- Alpha Testing og Beta Testing (En komplet guide)
- Funktionel testning mod ikke-funktionel testning
- Typer af migreringstest: Med testscenarier for hver type
- Usability Testing Tutorial: En komplet vejledning til start
- 13 bedste datamigrationsværktøjer til komplet dataintegritet [2021 LIST]
- Build Verification Testing (BVT Testing) Komplet guide
- Bedste softwaretestværktøjer 2021 [QA Test Automation Tools]