Teststrategi og testscenarier til datamigreringstest
On februar 15, 2021 by adminVi konverterer en af vores uafhængige windows-applikationer til en webapplikation. Når dette er afsluttet, har vi brug for foretage en datamigrering. Hvordan forbereder man teststrategi til dette? Hvad er de fakta, vi skal overveje? Hvad er testscenarierne?
Svar
I en lignende situation designede jeg få kritiske slut-til-end forretningsscenarier og løb igennem begge systemer og sammenlignede slutresultaterne såvel som vigtige resultater i mellemtrin med hensyn til outputdata.
Valget af scenarier dikteres af niveau af datatransformation, når de går gennem systemet.
Også hvis systemet understøtter søgnings- og rapporteringsfunktion, hvor det viser detaljerede datarapporter baseret på søgeparametre, så de kan bruges intensivt efter datamigrering til at sammenligne begge systemer .
Svar
Det vil involvere meget mere end test af datamigrering.
Det første, du skal overveje, er måske, hvordan dine kunder (både interne og eksterne) påvirkes. Hvad skal dine kunder gøre, hvis denne overgang sker.
- Hvis applikationen ser anderledes ud, kan kunderne tilpasse sig de nye grænseflader? Den bedste måde er at involvere kunder fra første dag og få dem til at give dig konstant tilbagemeldinger fra slutbrugeroplevelsen.
Datamigreringsteststrategier kan let findes på Internettet, for eksempel skal du læse denne. http://datamigrationpro.com/data-migration-testing-strategy/
Sikkerhedstest, en webapplikation kan være et mål for online hacking; du kan overveje at ansætte en sikkerhedstestekspert, der hjælper dig med penetrationstest. Du er velkommen til at læse dette link, https://www.owasp.org/index.php/Top_10-2017_Top_10
Uden at vide nøjagtige detaljer om din ansøgning, kan jeg kun give oplysninger på et relativt højt abstrakt niveau.
Svar
I henhold til dit kravnet finder to typer migrering sted: – Den første er Application og den anden er Database migration.
Følgende er de få strategier, der udføres af de bedste softwaretestfirmaer for at sikre effektiv migrationstest: –
1. Applikationsmigration: Testaktiviteter her vil være:
Analyse af krav og identifikation af stabile krav Analyser og test alle strømme i ældre applikationer mod den nye applikation
Test de nye strømme i den migrerede applikation, hvis nogen
Testscenarier generelt vil være som nedenfor:
Valider alle de tidligere funktioner sammen med de opgraderede funktioner – alt skal fungere korrekt
Test applikationen for de eksisterende data såvel som de nye data – begge skal fungere korrekt
Eksempel:
Prøv at opdatere de eksisterende data, slette de eksisterende data, søge efter de eksisterende data og generere rapporter til de eksisterende data.
Med nye data skal du validere oprettelse af konti / data, opdatere nyligt tilføjede data, slette nyligt tilføjede data, søge med de nyligt tilføjede data og generere rapporter om nyligt tilføjede data
Kontroller, om hele applikationen fungerer korrekt
Kontroller, om den nye teknologi stadig understøtter alle programmets komponenter. For eksempel ændres plugins / tilføjelsesprogrammer / miljøværdier / sti ikke og skal fungere korrekt uden fejl. Kontroller, om det er kompatibelt med alle mulige operativsystemer, browserversioner osv.
Kontroller, om gamle data bevares i applikationen, og nye data fungerer fint på ny teknologi
2. Databasemigrering For denne type migrering skal applikationen være stabil, og dataene i databasen skal være korrekte og gyldige. Derfor har formatet, typen, værdien osv. Betydning under migrering mellem databaser.
Testaktiviteter her vil være:
Sørg for, om den ældre database ikke opdateres under test efter migrering
Sørg for, om kortlægningen på felt- og tabelniveauer ikke ændres
Sikrer hvis data migreres nøjagtigt og fuldstændigt
Testscenarier ville være som nedenfor:
I) Hvis overførslen er til den samme type database,
Kontroller, om forespørgslerne i den nye database giver de samme resultater som i den ældre
Kontroller, om antallet af poster i den gamle database og den nye database er det samme.Brug her passende automatiseringsværktøj
Bekræft, at der ikke er afskedigelser, og den nye database fungerer nøjagtigt som den ældre
Kontroller, om skemaet, relationer, tabelstrukturer er uændrede eller sættes tilbage til at matche det gamle databasebillede
Kontroller, om de ændringer, der er foretaget i applikationen, opdaterer den nye database med korrekte værdier, og skriv
Bekræft, hvis alle nye komponenter til applikationen leveres efter den nye databaseforbindelse. Applikation, server, grænseflader, firewall, netværksforbindelse osv.
Bekræft forespørgselsydelsen (det tager tid at udføre komplekse forespørgsler) i den nye database er ikke mere end tidligere ydeevne
II ) Hvis migrationen er en anden type database, skal der sammen med ovenstående valideringspunkter kun tages nogle eller flere:
Bekræft datahåndtering for alle felterne. Store udfordringer er at håndtere data til kalenderdatoer, flydende tal, hexadecimal osv.
Svar
I test før migrering udvikler og QA-teamet skal være yderst fortrolig med applikationens tilstand og funktionalitet. Det vigtigste er at kende alle eksisterende problemer, der ikke er løst af forskellige årsager. Testere skal oprette hovedtestscenarier med brugsstrømme, som brugerne gør mest. De skal også dække de sjældne arbejdsgange med nogle gode scenarier. De vil senere gengive disse scenarier for at bekræfte, at applikationen fungerer som forventet.
I migreringstest forsøger udviklere at integrere komponenter i applikationsskrivning af kodeændringer. De skal koordinere med serveradministratorer, hvilket spiller en afgørende rolle i dette trin. QA-team fanger vigtige funktionelle problemer i denne fase, der forventes overarbejde for alle involverede hold. Lejlighedsvis vil der være nedetid for servere, så projektleder skal bruge de gamle servere, indtil den nye produktion er klar til kunder.
I test efter migrering findes mindre vigtige problemer (f.eks. Indhold og visuelle fejl) og test af brugeraccept implementeres. Udviklere tager pause efter udtømmende arbejde, og QA-ledere samler spørgsmål i rapporter for at præsentere det for produktejeren eller en anden forretningsrepræsentant i teamet.
QA-teamet skal være opmærksom på almindelige fejl, der forårsagede mangler:
Manglende databaser og ressourcer (billeder, dokumenter). Hardwarekonfigurationer og opsætning. Domæneændring i kode og beskrivelser. Indstillinger for applikation under test, som ikke replikeres på grund af manglende database. En anden gren af kode skubbes (ny overstyrer gammel eller omvendt).
Ledelsen skal beslutte:
Vil de give adgang til databaserne til testere, hvis projektet har deadlines? Hvad er testomfanget? Hvis der er uløste problemer, skal de rapporteres sammen med de nye?
Udviklingsteamet skal:
Vær 100% fortrolig med teknologier og sprog, som de arbejder på. Samarbejde kraftigt med serveradministratorer og databaseudviklere under migrering. Fokuser straks på funktionelle problemer.
Skriv et svar