Teststrategi och testscenarier för datamigreringstest
On februari 15, 2021 by adminVi konverterar en av våra fristående Windows-applikationer till en webbapplikation. När detta är klart behöver vi göra en datamigrering. Hur förbereder jag teststrategi för detta? Vilka är de fakta vi behöver tänka på? Vilka är testscenarierna?
Svar
I en liknande situation designade jag några kritiska scenarier från slut till slut och sprang igenom båda systemen och jämförde slutresultaten såväl som avgörande mellanstegsresultat när det gäller utdata.
Valet av scenarier kommer att dikteras av nivå av datatransformation när de går igenom systemet.
Även om systemet stöder sök- och rapporteringsfunktionen där det visar detaljerade datarapporter baserat på sökparametrar så att de kan användas intensivt efter datamigrering för att jämföra båda systemen .
Svar
Det kommer att innebära mycket mer än datamigreringstestning.
Det första du bör tänka på är kanske hur dina kunder (både interna och externa) påverkas. Vad behöver dina kunder göra om den här övergången sker.
- Om applikationen ser annorlunda ut, kan kunderna anpassa sig till de nya gränssnitten? Det bästa sättet är att involvera kunder från första dagen och få dem att ge dig återkopplingar från slutanvändaren.
Datamigreringsteststrategier kan enkelt hittas på internet, till exempel, läs den här. http://datamigrationpro.com/data-migration-testing-strategy/
Säkerhetstestning, en webbapplikation kan vara ett mål för online-hacking; du kan överväga att anställa en expert för säkerhetstest för att hjälpa dig med penetrationstest. Tveka inte att läsa den här länken, https://www.owasp.org/index.php/Top_10-2017_Top_10
Utan att veta exakta detaljer om din ansökan kan jag bara ge information på en relativt hög abstrakt nivå.
Svar
Enligt ditt kravnät pågår två typer av migrering: – Den första är Application och den andra är Database migration.
Nedan följer några strategier som utförs av de bästa programvarutestningsföretagen för att säkerställa effektiv migreringstest: –
1. Applikationsmigrering: Testaktiviteter här kommer att vara:
Analysera krav och identifiera stabila krav Analysera och testa alla flöden i äldre applikationer mot den nya applikationen
Testa de nya flödena i den migrerade applikationen om någon
Testscenarier i allmänhet skulle vara som nedan:
Validera alla tidigare funktioner tillsammans med de uppgraderade funktionerna – allt ska fungera korrekt
Testa applikationen för befintlig data såväl som de nya data – båda ska fungera korrekt
Exempel:
Försök att uppdatera befintlig data, radera befintlig data, söka efter befintlig data och generera rapporter för befintlig data.
Med nya data, validera att skapa konton / data, uppdatera nyligen tillagda data, ta bort nyligen tillagda data, sök med den nyligen tillagda data och generera rapporter för nyligen tillagda data
Kontrollera om hela applikationen fungerar korrekt
Kontrollera om den nya tekniken fortfarande stöder alla komponenter i applikationen. Till exempel ändras inte plugins / tillägg / miljövärden / sökväg och ska fungera korrekt utan några fel. Kontrollera om det är kompatibelt med alla möjliga operativsystem, webbläsarversioner etc.
Kontrollera om gamla data behålls i applikationen och nya data fungerar bra på ny teknik
2. Databasmigrering För denna typ av migrering ska applikationen vara stabil och data i databasen vara korrekta och giltiga. Därför är formatet, typen, värdet etc. viktigt när du migrerar mellan databaser.
Testaktiviteter här kommer att vara:
Se till om den äldre databasen inte uppdateras under tester efter migrering
Kontrollera om kartläggningen på fält- och tabellnivåer inte ändras
Säkerställer om data migreras exakt och fullständigt
Testscenarier skulle vara som nedan:
I) Om migreringen är till samma typ av databas,
Kontrollera om frågorna i den nya databasen ger samma resultat som i den äldre
Verifiera om antalet poster i den gamla databasen och den nya databasen är densamma.Här använder du lämpligt automatiseringsverktyg
Kontrollera att det inte finns några uppsägningar och att den nya databasen fungerar precis som den äldre
Kontrollera om schemat, relationer, tabellstrukturer är oförändrade eller återställs för att matcha den gamla databasbilden
Kontrollera om ändringarna i applikationen uppdaterar den nya databasen med korrekta värden och skriv
Kontrollera om efter den nya databasanslutningen tillhandahålls till alla komponenter i applikationen. Applikation, server, gränssnitt, brandvägg, nätverksanslutning etc.
Kontrollera att frågeprestanda (det tar lång tid att utföra komplexa frågor) i den nya databasen inte är mer än tidigare prestanda
II ) Om migreringen är av en annan typ av databas, så måste få eller fler tas hand om tillsammans med ovanstående valideringspunkter:
Verifiera datahantering för alla fält. Stora utmaningar är att hantera data för kalenderdatum, flytande siffror, hexadecimala mm.
Svar
I test före migrering utvecklar och QA-teamet måste vara mycket bekant med applikationens tillstånd och funktionalitet. Det viktigaste är att känna till alla befintliga problem som inte har fixats av olika skäl. Testare måste skapa huvudsakliga testscenarier med användningsflöden som användarna gör mest. De måste också täcka de sällsynta arbetsflödena med några bra scenarier. De kommer senare att reproducera dessa scenarier för att bekräfta att applikationen fungerar som förväntat.
I migreringstester försöker utvecklare att integrera komponenter i programskrivningskodändringar. De måste samordna med serveradministratörer vilket spelar en avgörande roll i detta steg. QA-team fångar viktiga funktionella frågor i denna fas, övertidstimmar förväntas för alla inblandade lag. Ibland skulle det vara stillestånd för servrar, så projektledare måste använda de gamla servrarna tills den nya produktionen är redo för kunder.
I test efter migrering hittas mindre viktiga problem (t.ex. innehåll och visuella buggar) och användaracceptans testning implementeras. Utvecklare tar paus efter omfattande arbete och QA-chefer samlar in frågor i rapporter för att presentera det för produktägare eller annan företagsrepresentant i teamet.
QA-teamet måste vara uppmärksam på vanliga fel som orsakade brister:
Databaser och resurser saknas (bilder, dokument). Hårdvarukonfigurationer och installation. Domänförändring i kod och beskrivningar. Inställningar för applikation som testas som inte har replikerats på grund av saknad databas. Olika grenar av kod drivs (ny åsidosätter gammal eller vice versa).
Ledningen måste besluta:
Skulle de ge tillgång till databaserna för testare om projektet har tidsfrister? Vad är omfattningen av testningen? Om det finns olösta problem, ska de rapporteras med de nya?
Utvecklingsteamet måste:
Vara 100% bekant med tekniker och språk som de arbetar på. Samarbeta kraftigt med serveradministratörer och databasutvecklare under migrering. Fokusera på funktionella frågor omedelbart.
Lämna ett svar