Teststrategi og testscenarier for datamigreringstesting
On februar 15, 2021 by adminVi konverterer en av våre frittstående windows-applikasjoner til en webapplikasjon. Når dette er fullført, trenger vi gjøre en datamigrering. Hvordan forberede jeg teststrategi for dette? Hva er fakta vi må vurdere? Hva er testscenariene?
Svar
I en lignende situasjon utformet jeg få kritiske end-to-end-forretningsscenarier og løp gjennom begge systemene og sammenlignet sluttresultatene så vel som avgjørende mellomtrinnsresultater når det gjelder utdata.
Valget av scenarier vil være diktert av nivå av datatransformasjon når de går gjennom systemet.
Også hvis systemet støtter søke- og rapporteringsfunksjonen der det viser detaljerte datarapporter basert på søkeparametere, slik at de kan brukes intensivt etter datamigrering for å sammenligne begge systemene .
Svar
Det vil innebære mye mer enn testing av datamigrering.
Det første du bør vurdere er kanskje hvordan kundene dine (både interne og eksterne) påvirkes. Hva må kundene dine gjøre hvis denne overgangen skjer.
- Hvis applikasjonen ser annerledes ut, kan kundene tilpasse seg de nye grensesnittene? Den beste måten er å involvere kunder fra første dag, og få dem til å gi deg tilbakemeldinger fra sluttbrukere.
Testdata for migrering av data kan enkelt finnes på internett, for eksempel kan du lese denne. http://datamigrationpro.com/data-migration-testing-strategy/
Sikkerhetstesting, en webapplikasjon kan være et mål for online hacking; du kan vurdere å ansette en ekspert på sikkerhetstesting for å hjelpe deg med penetrasjonstesting. Du kan gjerne lese denne lenken, https://www.owasp.org/index.php/Top_10-2017_Top_10
Uten å vite nøyaktige detaljer om søknaden din, kan jeg bare gi informasjon på et relativt høyt abstrakt nivå.
Svar
I henhold til ditt kravnett skjer to typer migrering: – Den første er Application og den andre er Database migrering.
Følgende er noen få strategier som blir utført av de beste programvaretestingsfirmaene for å sikre effektiv migreringstesting: –
1. Søknadsmigrasjon: Testaktiviteter her vil være:
Analysering av krav og identifisering av stabile krav Analyser og test alle strømmer i eldre applikasjoner mot den nye applikasjonen
Test de nye flytene i den migrerte applikasjonen hvis noen
Testscenarier generelt vil være som nedenfor:
Valider alle tidligere funksjoner sammen med de oppgraderte funksjonene – alt skal fungere riktig
Test applikasjonen for eksisterende data så vel som de nye dataene – begge skal fungere riktig
Eksempel:
Prøv å oppdatere eksisterende data, slette eksisterende data, søke etter eksisterende data og generere rapporter for eksisterende data.
Med nye data validerer du å opprette kontoer / data, oppdaterer nylig lagt til data, sletter nylig tilføyde data, søker med de nylig tilføyde dataene og genererer rapporter for nylig lagt til data
Bekreft om hele applikasjonen fungerer riktig
Bekreft om den nye teknologien fremdeles støtter alle komponentene i applikasjonen. For eksempel endres ikke programtillegg / tillegg / miljøverdier / bane og skal fungere korrekt uten feil. Bekreft om det er kompatibelt med alle mulige operativsystemer, nettleserversjoner osv.
Bekreft om gamle data beholdes i applikasjonen, og nye data fungerer fint på ny teknologi
2. Databasemigrering For denne typen migrering skal applikasjonen være stabil og dataene i databasen skal være korrekte og gyldige. Derfor har formatet, typen, verdien osv. Betydning når du migrerer mellom databaser.
Testaktiviteter her vil være:
Forsikre deg om at den eldre databasen ikke oppdateres under tester etter overføring
Forsikre deg om kartleggingen på felt- og tabellnivå ikke endres
Sikre hvis data overføres nøyaktig og fullstendig
Testscenarier vil være som nedenfor:
I) Hvis overføringen er til samme type database,
Bekreft om spørringene som er utført i den nye databasen gir samme resultater som i den eldre
Bekreft om antall poster i den gamle databasen og den nye databasen er det samme.Her bruker du passende automatiseringsverktøy
Bekreft at det ikke er noen permitteringer, og den nye databasen fungerer nøyaktig som den eldre
Kontroller om skjema, relasjoner, tabellstrukturer er uendret eller sett tilbake for å matche det gamle databasebildet
Bekreft om endringene i applikasjonen oppdaterer ny database med riktige verdier og skriv
Bekreft om etter at den nye databaseforbindelsen er gitt til alle komponentene i applikasjonen. Søknad, server, grensesnitt, brannmur, nettverkstilkobling osv.
Bekreft spørringsytelsen (det tar tid å utføre komplekse spørsmål) til den nye databasen er ikke mer enn tidligere ytelse
II ) Hvis migreringen er en annen type database, må få eller flere, sammen med ovennevnte valideringspunkter, tas vare på:
Bekreft datahåndteringen for alle feltene. Store utfordringer vil være å håndtere data for kalenderdatoer, flytende tall, heksadesimal osv.
Svar
I test før migrering utvikler og QA-teamet må være svært kjent med tilstanden og funksjonaliteten til applikasjonen. Det viktigste er å kjenne til alle eksisterende problemer som ikke har blitt løst av forskjellige årsaker. Testere må lage hovedtestscenarier med bruksflyter som brukerne gjør mest. De må også dekke de sjeldne arbeidsflytene med noen gode scenarier. De vil senere gjengi disse scenariene for å bekrefte at applikasjonen fungerer som forventet.
I migrasjonstesting prøver utviklere å integrere komponenter i applikasjonsskriving av kodeendringer. De må koordinere med serveradministratorer som spiller avgjørende rolle i dette trinnet. QA-team fanger viktige funksjonelle problemer i denne fasen, det forventes overtidstimer for alle involverte lag. Noen ganger vil det være nedetid for servere, så prosjektleder må bruke de gamle serverne til den nye produksjonen er klar for kunder.
I test etter migrering blir mindre viktige problemer funnet (f.eks. Innhold og visuelle feil) og testing av brukeraksept er implementert. Utviklere tar pause etter omfattende arbeid, og QA-ledere samler inn problemer i rapporter for å presentere det for produkteier eller annen forretningsrepresentant i teamet.
QA-teamet må ta hensyn til vanlige feil som forårsaket feil:
Manglende databaser og ressurser (bilder, dokumenter). Maskinvarekonfigurasjoner og oppsett. Domeneendring i kode og beskrivelser. Innstillinger for applikasjonen som testes, og som ikke replikeres på grunn av manglende database. En annen gren av koden blir presset (ny overstyrer gammel eller omvendt).
Ledelsen må bestemme:
Vil de gi tilgang til databasene til testere hvis prosjektet har frister? Hva er omfanget av testing? Hvis det er uløste problemer, bør de rapporteres sammen med de nye?
Utviklingsteamet må:
Være 100% kjent med teknologier og språk de jobber med. Samarbeid sterkt med serveradministratorer og databaseutviklere under migrering. Fokuser på funksjonelle problemer umiddelbart.
Legg igjen en kommentar