data migration testing tutorial
Visió general de les proves de migració de dades:
Sovint se sap que una aplicació es mou a un servidor diferent, que la tecnologia es canvia, que s’actualitza a la versió següent o es mou a un servidor de bases de dades diferent, etc.,
- Què significa això en realitat?
- Què s’espera de l’equip de proves en aquestes situacions?
Des del punt de vista de les proves, tot vol dir que l'aplicació s'ha de provar exhaustivament de punta a punta juntament amb la migració del sistema existent al nou sistema amb èxit.
Tutorials d'aquesta sèrie:
En aquest cas, s’ha de fer proves de sistema amb totes les dades que s’utilitzen en una aplicació antiga i també en les dades noves. Cal verificar la funcionalitat existent juntament amb la nova / modificada.
En lloc de fer només proves de migració, també es pot anomenar proves de migració de dades, on es migraran totes les dades de l'usuari a un sistema nou.
Per tant, les proves de migració inclouen proves amb dades antigues, dades noves o una combinació de totes dues, funcions antigues (funcions sense canvis) i funcions noves.
L'antiga aplicació se sol denominar ' llegat ’Aplicació. Juntament amb les aplicacions noves / actualitzades, també és obligatori continuar provant les aplicacions heretades fins que les noves / actualitzades esdevinguin estables i coherents. Una extensa prova de migració de la nova aplicació revelarà els nous problemes que no s'han trobat a l'aplicació heretada.
Què aprendreu:
- Què són les proves de migració?
- Per què la prova de migració?
- Quan es requereix aquesta prova?
- Estratègia de proves de migració de dades
- Diferents fases de migració
- Proves de compatibilitat cap enrere
- Proves de retrocés
- Informe resum de proves de migració
- Reptes en les proves de migració de dades
- Consells per suavitzar els riscos de migració de dades
- Conclusió
- Lectura recomanada
Què són les proves de migració?
Les proves de migració són un procés de verificació de la migració del sistema heretat al nou sistema amb un mínim interrupció / temps d'inactivitat, amb integritat de dades i sense pèrdua de dades, tot garantint que tots els aspectes funcionals i no funcionals de l'aplicació es compleixen després de migració.
Representació simple del sistema de migració:
Per què la prova de migració?
Com sabem, la migració de l'aplicació a un nou sistema pot ser per diversos motius, la consolidació del sistema, la tecnologia obsoleta, l'optimització o qualsevol altre motiu.
Per tant, tot i que el sistema en ús ha de migrar-se a un sistema nou, és essencial assegurar els punts següents:
- Cal evitar / minimitzar qualsevol tipus de molèstia / molèstia causada a l'usuari a causa de la migració. Per exemple: temps d'inactivitat, pèrdua de dades
- Cal assegurar-se que l'usuari pugui continuar utilitzant totes les funcions del programari causant danys mínims o nuls durant la migració. Per exemple: canvi en la funcionalitat, eliminació d'una funcionalitat concreta
- També és important preveure i descartar tots els problemes o obstacles que es puguin produir durant la migració real del sistema viu.
Per tant, per tal d’assegurar una migració fluida del sistema actiu eliminant aquests defectes, és essencial realitzar proves de migració al laboratori.
Aquestes proves tenen la seva pròpia importància i juguen un paper vital quan les dades apareixen a la imatge.
Tècnicament, també s'ha d'executar per als propòsits següents:
- Per garantir la compatibilitat de l'aplicació nova / actualitzada amb tot el maquinari i el programari possibles compatibles amb l'aplicació heretada. A més, novetat compatibilitat també s'hauria de provar el nou maquinari, la plataforma de programari.
- Per garantir que totes les funcionalitats existents funcionin com a l'aplicació heretada. No hauria d’haver cap canvi en el funcionament de l’aplicació en comparació amb l’antiga.
- La possibilitat d’un gran nombre de defectes a causa de la migració és molt elevada. Molts dels defectes solen estar relacionats amb les dades i, per tant, cal identificar-los i corregir-los durant la prova.
- Per garantir si el temps de resposta del sistema de l'aplicació nova / actualitzada és igual o inferior al que es necessita per a l'aplicació heretada.
- Per garantir que la connexió entre servidors, maquinari, programari, etc., estigui intacta i no es trenqui durant la prova. El flux de dades entre diferents components no s’hauria de trencar sota cap condició.
Quan es requereix aquesta prova?
Les proves s'han de realitzar tant abans com després de la migració.
Les diferents fases de la prova de migració que es realitzaran al laboratori de proves es poden classificar a continuació.
- Proves de pre-migració
- Proves de migració
- Proves posteriors a la migració
A més de l'anterior, el també s'executen les proves següents com a part de tota l'activitat de migració.
- Verificació de compatibilitat cap enrere
- Proves de retrocés
Abans de realitzar aquesta prova, és essencial que qualsevol provador entengui clarament els punts següents:
- Els canvis que es produeixen com a part del nou sistema (servidor, portada, base de dades, esquema, flux de dades, funcionalitat, etc.)
- Comprendre l'estratègia de migració real establerta per l'equip. Com passa la migració, canvis pas a pas que es produeixen al fons del sistema i als scripts responsables d’aquests canvis.
Per tant, és fonamental fer un estudi exhaustiu del sistema antic i nou i, a continuació, planificar i dissenyar els casos de prova i els escenaris de prova que es tractaran com a part de les fases anteriors de la prova i preparar l’estratègia de prova.
Estratègia de proves de migració de dades
El disseny de l’estratègia de prova per a la migració inclou un conjunt d’activitats a realitzar i pocs aspectes a tenir en compte. Es tracta de minimitzar els errors i els riscos que es produeixen com a conseqüència de la migració i realitzar les proves de migració amb eficàcia.
Activitats en aquesta prova:
# 1) Formació d’equips especialitzats :
Formeu l'equip de proves amb els membres que tinguin el coneixement i l'experiència necessaris i oferiu formació relacionada amb el sistema que s'està migrant.
# 2) Anàlisi de risc empresarial, anàlisi de possibles errors :
El negoci actual no s’hauria de dificultar després de la migració i, per tant, dur a terme ‘ Anàlisi del risc empresarial » reunions amb els interessats adequats (gestor de proves, analista de negocis, arquitectes, propietaris de productes, propietari d’empreses, etc.) i identificar els riscos i les mitigacions implementables. Les proves han d'incloure escenaris per descobrir aquests riscos i verificar si s'han implementat mitigacions adequades.
Conducta ' Possible anàlisi d'errors ' utilitzant adequat 'Error en endevinar els enfocaments' i després dissenyeu proves al voltant d'aquests errors per desenterrar-los durant les proves.
què és la clau de seguretat de la xarxa al router
# 3) Anàlisi i identificació de l'abast de la migració:
Analitzeu l'abast clar de la prova de migració com quan i què cal provar.
# 4) Identifiqueu l'eina adequada per a la migració:
Mentre definiu l’estratègia d’aquestes proves, automatitzades o manuals, identifiqueu les eines que s’utilitzaran. Per exemple: Eina automatitzada per comparar dades d'origen i destinació.
# 5) Identifiqueu l'entorn de prova adequat per a la migració:
Identifiqueu entorns separats per a entorns anteriors i posteriors a la migració per dur a terme qualsevol verificació que sigui necessària com a part de les proves. Comprendre i documentar els aspectes tècnics del sistema de migració heretat i nou, per garantir que l'entorn de prova estigui configurat d'acord amb això.
# 6) Document d'especificació de proves de migració i revisió:
Prepareu un document d’especificació de proves de migració que descrigui clarament l’enfocament de la prova, les àrees de prova, els mètodes de prova (automatitzats, manuals), la metodologia de prova (quadre negre, tècnica de proves de caixa blanca ), Nombre de cicles de proves, calendari de proves, enfocament de creació de dades i ús de dades en directe (cal emmascarar la informació sensible), especificació de l'entorn de prova, qualificació dels verificadors, etc. i executeu una sessió de revisió amb els grups d'interès.
# 7) Llançament de producció del sistema migrat :
Analitzeu i documenteu la llista de tasques per a la migració de producció i publiqueu-la amb suficient antelació
Diferents fases de migració
A continuació es detallen les diverses fases de la migració.
Fase 1:Proves de pre-migració
Abans de migrar les dades, es realitzen un conjunt d'activitats de prova com a part de la fase de prova prèvia a la migració. Això s'ignora o no es considera en aplicacions més simples. Però quan s’han de migrar aplicacions complexes, les activitats de pre-migració són imprescindibles.
A continuació es mostra la llista d’accions que es duen a terme durant aquesta fase:
- Definiu un abast clar de les dades: quines dades s’han d’incloure, quines dades s’han d’excloure, quines dades necessiten transformacions / conversions, etc.
- Realitzeu un mapatge de dades entre l'aplicació antiga i la nova aplicació: per a cada tipus de dades de l'aplicació antiga compareu el tipus rellevant a la nova aplicació i, a continuació, mapeu-les: mapatge de nivell superior.
- Si la nova aplicació té el camp obligatori, però no és el cas de l'herència, assegureu-vos que l'herència no té aquest camp com a nul. - Cartografia de nivell inferior.
- Estudieu clarament l’esquema de dades de la nova aplicació: noms de camp, tipus, valors mínims i màxims, longitud, camps obligatoris, validacions de nivell de camp, etc., clarament
- Cal assenyalar una sèrie de taules del sistema heretat i, si s'ha de retirar alguna taula i s'ha de verificar la migració afegida.
- Un nombre de registres a cada taula, les vistes s'han de tenir en compte a l'aplicació heretada.
- Estudieu les interfícies de la nova aplicació i les seves connexions. Les dades que flueixin a la interfície haurien d’estar molt segures i no estar trencades.
- Prepareu casos de prova, escenaris de prova i casos d’ús per a noves condicions a les noves aplicacions.
- Executeu un conjunt de casos de prova, escenaris amb un conjunt d’usuaris i guardeu els resultats, els registres emmagatzemats. Cal verificar el mateix després de la migració per garantir que les dades i la funcionalitat heretades estiguin intactes.
- El recompte de dades i registres s’ha d’anotar amb claredat, s’ha de verificar després de la migració per no perdre les dades.
Fase 2:Proves de migració
' Guia de migració ’que és s’ha de seguir estrictament l’elaboració de l’equip de migració per dur a terme l’activitat de migració. Idealment, l'activitat de migració comença amb la còpia de seguretat de les dades a la cinta, de manera que, en qualsevol moment, es pot restaurar el sistema heretat.
Verificació de la part de documentació de ‘ Guia de migració també forma part de les proves de migració de dades . Verifiqueu si el document és clar i fàcil de seguir. Tots els scripts i passos s'han de documentar correctament sense cap ambigüitat. Qualsevol tipus d’error de documentació, faltes de coincidència en l’ordre d’execució dels passos també s’ha de considerar important perquè es puguin informar i corregir.
Els scripts de migració, la guia i altra informació relacionada amb la migració real s'han de recollir al dipòsit de control de versions per executar-los.
Un dels casos de prova que cal executar i, per tant, és el d’anotar el temps real de migració des del punt d’inici de la migració fins a la restauració reeixida del sistema. 'Temps necessari per migrar el sistema' s'ha de registrar a l'informe final de la prova que es lliurarà com a part dels resultats de la prova de migració i aquesta informació serà útil durant el llançament de la producció. El temps d'inactivitat registrat a l'entorn de prova s'extrapola per calcular el temps d'inactivitat aproximat al sistema en directe.
És al sistema heretat on es durà a terme l’activitat de migració.
Durant aquesta prova, tots els components de l’entorn solen ser enderrocats i eliminats de la xarxa per dur a terme les activitats de migració. Per tant, cal tenir en compte el 'Temps d'inactivitat' necessari per a la prova de migració. Idealment, serà el mateix que el temps de migració.
En general, l'activitat de migració definida al document 'Guia de migració' inclou:
- Migració real de l'aplicació
- Les tallafocs, els ports, els amfitrions, el maquinari i les configuracions de programari es modifiquen segons el nou sistema on es migra el llegat
- Es realitzen filtracions de dades, controls de seguretat
- Es comprova la connectivitat entre tots els components de l’aplicació
És recomanable que els provadors comprovin l’anterior al fons del sistema o realitzant proves de caixa blanca.
Un cop finalitzada l'activitat de migració especificada a la guia, es publiquen tots els servidors i es realitzaran proves bàsiques relacionades amb la verificació de la migració amb èxit, cosa que garanteix que tots els sistemes de punta a punta estiguin correctament connectats i que tots els components parlin altra, la base de dades està en funcionament, la part frontal es comunica amb la part posterior amb èxit. Aquestes proves s'han d'identificar prèviament i registrar-les al document d'especificació de proves de migració.
Hi ha possibilitats que el programari admeti diverses plataformes diferents. En aquest cas, la migració s'ha de verificar per separat en cadascuna d'aquestes plataformes.
La verificació dels scripts de migració formarà part de la prova de migració. De vegades, també es verifica l’escriptura de migració individual mitjançant la prova de caixes blanques en un entorn de proves autònom.
Per tant, les proves de migració seran una combinació tant de 'proves de caixa blanca com de caixa negra'.
Un cop feta aquesta verificació relacionada amb la migració i superades les proves corresponents, l'equip pot continuar amb l'activitat de les proves post-migració.
Fase 3:Proves post-migració
Quan l'aplicació es migra amb èxit, apareixen les proves de post-migració.
Aquí es realitzen proves de sistema extrem a extrem a l’entorn de proves. Els verificadors executen casos de prova identificats, escenaris de prova, casos d’ús amb dades heretades, així com un nou conjunt de dades.
A més d’això, hi ha elements específics per verificar als entorns migrats que s’enumeren a continuació:
Tots aquests es documenten com a cas de prova i s’inclouen al document «Especificació de prova».
- Comproveu si totes les dades de l'herència es migren a la nova aplicació durant el temps d'inactivitat previst. Per assegurar-ho, compareu el nombre de registres entre l’herència i la nova aplicació per a cada taula i visualitzacions de la base de dades. A més, informeu del temps necessari per moure’s, per exemple, 10.000 registres.
- Comproveu si s’actualitzen tots els canvis d’esquema (camps i taules afegits o eliminats) segons el sistema nou.
- Les dades migrades des de l’aplicació antiga a la nova aplicació haurien de conservar el seu valor i format, tret que no s’especifiqui per fer-ho. Per assegurar-ho, compareu els valors de dades entre la base de dades heretada i la nova aplicació.
- Proveu les dades migrades amb la nova aplicació. Aquí cobreix un nombre màxim de casos possibles. Per garantir una cobertura del 100% respecte a la verificació de la migració de dades, utilitzeu l'eina de proves automatitzades.
- Comproveu si hi ha seguretat de la base de dades.
- Comproveu la integritat de les dades per a tots els registres de mostra possibles.
- Comproveu i assegureu-vos que la funcionalitat admesa anteriorment al sistema heretat funciona tal com s’esperava al nou sistema.
- Comproveu el flux de dades dins de l'aplicació que cobreix la majoria dels components.
- La interfície entre els components s'hauria de provar àmpliament, ja que les dades no s'han de modificar, perdre ni corrompre quan es passen per components. Per verificar-ho es poden utilitzar casos de proves d’integració.
- Comproveu la redundància de les dades heretades. No s'haurien de duplicar les dades heretades durant la migració
- Comproveu si hi ha casos de desajustament de dades, com ara el tipus de dades, el format d’emmagatzematge, etc.
- Totes les comprovacions de nivell de camp de l’aplicació heretada també s’han d’incloure a la nova aplicació
- Qualsevol addició de dades a la nova aplicació no hauria de reflectir el llegat
- S'hauria de donar suport a l'actualització de les dades de l'aplicació antiga mitjançant la nova aplicació. Un cop actualitzada a la nova aplicació, no hauria de tornar a reflectir el llegat.
- La supressió de les dades de l'aplicació antiga a la nova aplicació hauria de ser compatible. Un cop suprimida a la nova aplicació, tampoc no hauria de suprimir les dades existents.
- Verifiqueu que els canvis realitzats al sistema heretat admetin la nova funcionalitat lliurada com a part del nou sistema.
- Verifiqueu que els usuaris del sistema heretat puguin continuar utilitzant tant la funcionalitat antiga com la nova, especialment aquells en què intervenen els canvis. Executeu els casos de prova i els resultats de la prova emmagatzemats durant la prova prèvia a la migració.
- Creeu nous usuaris al sistema i realitzeu proves per assegurar-vos que la funcionalitat de l’herència, així com de la nova aplicació, admeti els usuaris de nova creació i que funcioni bé.
- Realitzeu proves relacionades amb la funcionalitat amb una gran varietat de mostres de dades (diferents grups d'edat, usuaris de diferents regions, etc.)
- També cal verificar si les 'Funcions de funcions' estan habilitades per a les funcions noves i si activeu o desactiveu les funcions s'activen i es desactiven.
- Les proves de rendiment són importants per garantir que la migració a un nou sistema o programari no hagi degradat el rendiment del sistema.
- També cal dur a terme proves de càrrega i esforç per garantir l’estabilitat del sistema.
- Verifiqueu que l’actualització de programari no hagi obert cap vulnerabilitat de seguretat i, per tant, realitzeu proves de seguretat, especialment a la zona on s’han fet canvis al sistema durant la migració.
- La usabilitat és un altre aspecte que s’ha de verificar, en què si el disseny de la interfície gràfica d’usuari / sistema frontal ha canviat o alguna funcionalitat ha canviat, quina és la facilitat d’ús que sent l’usuari final en comparació amb el sistema heretat.
Atès que l’abast de les proves post-migració esdevé molt gran, és ideal separar les proves importants que cal fer primer per qualificar que la migració té èxit i després dur a terme la resta.
També és recomanable automatitzar casos de prova funcionals de punta a punta i altres casos de prova possibles, de manera que es pugui reduir el temps de prova i que els resultats estiguin disponibles ràpidament.
Pocs consells per als verificadors per escriure els casos de prova per a l'execució post-migració:
- Quan es migra l'aplicació, no vol dir que s'hagin d'escriure els casos de prova per a tota la nova aplicació. Els casos de prova ja dissenyats per al llegat haurien de ser útils per a la nova aplicació. Per tant, utilitzeu els casos de proves antics i, en la mesura del possible, converteix els casos de prova antics a casos d’una nova aplicació sempre que sigui necessari.
- Si hi ha algun canvi de funció a la nova aplicació, caldria modificar els casos de prova relacionats amb la funció.
- Si hi ha alguna característica nova afegida a la nova aplicació, s'haurien de dissenyar nous casos de prova per a aquesta característica en particular.
- Quan hi ha alguna caiguda de funcions a la nova aplicació, els casos de prova de l'aplicació heretada relacionada no s'han de considerar per a l'execució posterior a la migració i s'han de marcar com a no vàlids i mantenir-los separats.
- Els casos de prova dissenyats sempre han de ser fiables i coherents en termes d’ús. La verificació de les dades crítiques s'hauria de cobrir en casos de prova perquè no es perdin durant l'execució.
- Quan el disseny de la nova aplicació és diferent del de la versió anterior (IU), els casos de prova relacionats amb la IU haurien de modificar-se per adaptar el nou disseny. La decisió d’actualitzar-ne o escriure’n de noves, en aquest cas, pot ser presa pel verificador en funció del volum de canvis ocorreguts.
Proves de compatibilitat cap enrere
La migració del sistema també requereix que els provadors verificin la 'compatibilitat cap enrere', en la qual el nou sistema introduït és compatible amb el sistema antic (almenys 2 versions anteriors) i garanteix que funcioni perfectament amb aquestes versions.
La compatibilitat amb versions anteriors és garantir:
- Si el nou sistema admet la funcionalitat admesa en les dues versions anteriors juntament amb la nova.
- El sistema es pot migrar amb èxit des de les 2 versions anteriors sense cap problema.
Per tant, és essencial garantir la compatibilitat amb el sistema mitjançant la realització específica de les proves relacionades amb la compatibilitat amb el sistema. Les proves relacionades amb la compatibilitat amb versions anteriors han de ser dissenyades i incloses al document d'especificacions de prova per a l'execució.
Proves de retrocés
En cas de tenir problemes durant la realització de la migració o si hi ha un error de migració en qualsevol moment durant la migració, el sistema hauria de ser possible tornar al sistema heretat i reprendre la seva funció ràpidament sense afectar els usuaris i la funcionalitat admesa anteriorment.
Per tant, per comprovar-ho, cal dissenyar escenaris de proves de fallades de migració com a part de proves negatives i s’ha de provar el mecanisme de retrocés. També cal registrar i informar el temps total necessari per tornar al sistema heretat als resultats de les proves.
Després de la recuperació, la funcionalitat principal i el fitxer proves de regressió (automatitzades) s'hauria d'executar per garantir que la migració no hagi afectat res i que la recuperació amb èxit hagi recuperat el sistema heretat.
Informe resum de proves de migració
L'informe resum de la prova s'hauria de produir després de completar la prova i hauria de cobrir l'informe sobre el resum de les diverses proves / escenaris realitzats com a part de diverses fases de la migració amb l'estat de resultat (aprovació / suspensió) i els registres de proves.
S'ha d'informar clarament del temps registrat per a les activitats següents:
millor lloc on veure l'anime
- Temps total per a la migració
- Temps d'inactivitat de les aplicacions
- Temps dedicat a migrar 10.000 registres.
- Temps dedicat a la recuperació.
A més de la informació anterior, també es pot informar de qualsevol observació / recomanació.
Reptes en les proves de migració de dades
Els desafiaments que s’enfronten en aquesta prova són principalment les dades. A continuació, es mostren uns quants a la llista:
# 1) Qualitat de les dades:
És possible que trobem que les dades que s’utilitzen a l’aplicació antiga són de mala qualitat a l’aplicació nova / actualitzada. En aquests casos, s’ha de millorar la qualitat de les dades per complir els estàndards empresarials.
Factors com els supòsits, les conversions de dades després de les migracions, les dades introduïdes a la pròpia aplicació heretada no són vàlides, la mala anàlisi de dades, etc., comporta una qualitat de les dades deficient. Això es tradueix en alts costos operatius, augment dels riscos d'integració de dades i desviació del propòsit del negoci.
# 2) Desajust de dades:
Les dades migrades des de l'herència a l'aplicació nova / actualitzada poden trobar-se que no coincideixen amb la nova. Això pot ser degut al canvi en el tipus de dades, el format d’emmagatzematge de dades, i es pot redefinir la finalitat per a la qual s’utilitzen les dades.
Això es tradueix en un gran esforç per modificar els canvis necessaris per corregir les dades no coincidents o acceptar-les i ajustar-les a aquest propòsit.
# 3) Pèrdua de dades:
És possible que es perdin dades mentre es migra des de l’herència a l’aplicació nova / actualitzada. Pot ser amb camps obligatoris o no obligatoris. Si les dades perdudes corresponen a camps no obligatoris, el registre continuarà sent vàlid i es podrà actualitzar de nou.
Però si es perden les dades del camp obligatori, el registre en si mateix queda nul i no es pot retirar. Això comportarà una pèrdua enorme de dades i hauria de ser recuperat de la base de dades de còpia de seguretat o dels registres d'auditoria si es capturen correctament.
# 4) Volum de dades:
Dades enormes que requereixen molt de temps per migrar a la finestra de temps d'inactivitat de l'activitat de migració. Per exemple: Targetes de ratllar a la indústria de les telecomunicacions, usuaris d'una plataforma de xarxa intel·ligent, etc., aquí el repte és que, en el moment, s'esborren les dades heretades, es crearan una enorme quantitat de dades noves, que s'han de tornar a migrar. L’automatització és la solució per a una enorme migració de dades.
# 5) Simulació d'un entorn en temps real (amb les dades reals):
La simulació d’un entorn en temps real al laboratori de proves és un altre desafiament real, en què els provadors entren en diferents tipus de problemes amb les dades reals i el sistema real, que no s’enfronten durant les proves.
Per tant, el mostreig de dades, la replicació de l’entorn real, la identificació del volum de dades implicades en la migració és bastant important durant la realització de proves de migració de dades.
# 6) Simulació del volum de dades:
Els equips han d’estudiar les dades del sistema en viu amb molta cura i haurien d’elaborar l’anàlisi i el mostreig típics de les dades.
Per exemple: usuaris amb un grup d’edat inferior a 10 anys, entre 10 i 30 anys, etc., en la mesura del possible, s’han d’obtenir dades de la transmissió en directe, si no la creació de dades a l’entorn de proves. Cal utilitzar eines automatitzades per crear un gran volum de dades. Es pot utilitzar l'extrapolació, sempre que sigui aplicable, si no es pot simular el volum.
Consells per suavitzar els riscos de migració de dades
A continuació es donen alguns consells que cal dur a terme per suavitzar els riscos de migració de dades:
- Estandarditzeu les dades utilitzades en el sistema heretat, de manera que quan es migri, les dades estàndard estaran disponibles en el sistema nou
- Millorar la qualitat de les dades, de manera que, quan es migra, hi ha dades qualitatives per provar que donen la sensació de provar-les com a usuari final
- Netejar les dades abans de migrar, de manera que, quan es migren, no hi haurà dades duplicades al nou sistema i, a més, mantindrà tot el sistema net.
- Torneu a comprovar les restriccions, els procediments emmagatzemats, les consultes complexes que donen resultats precisos, de manera que, quan es migren, també es retornin les dades correctes al nou sistema.
- Identifiqueu l'eina d'automatització correcta per realitzar comprovacions de dades / comprovacions de registres al nou sistema en comparació amb l'herència.
Conclusió
Per tant, tenint en compte que una petita falta en qualsevol aspecte de la verificació durant la prova comporta el risc de fracàs de la migració a la producció, tenint en compte que la complexitat que comporta la realització de proves de migració de dades, és molt important dur a terme un estudi acurat i exhaustiu i anàlisi del sistema abans i després de la migració. Planifiqueu i dissenyeu l’estratègia de migració eficaç amb eines robustes juntament amb provadors qualificats i formats.
Com sabem que la migració té un gran impacte en la qualitat de l’aplicació, tot l’equip ha de dedicar una gran quantitat d’esforços a verificar tot el sistema en tots els aspectes, com ara funcionalitat, rendiment, seguretat, usabilitat, disponibilitat, fiabilitat, compatibilitat. etc., que al seu torn assegurarà una 'prova de migració' amb èxit.
'Diferents tipus de migracions' que solen passar sovint a la realitat i les maneres de gestionar les seves proves s'explicaran breument a la nostra pàgina següent tutorial d'aquesta sèrie .
Quant als autors: Aquesta guia està escrita per l'autor Nandini de STH. Té més de 7 anys d’experiència en proves de programari. A més, gràcies a l’autor STH Gayathri S. per revisar i proporcionar els seus suggeriments valubale per millorar aquesta sèrie. Gayathri té més de 18 anys d’experiència en serveis de desenvolupament i proves de programari.
Feu-nos saber els vostres comentaris / suggeriments sobre aquest tutorial.
Lectura recomanada
- Tutorial de proves de magatzem de dades de proves ETL (una guia completa)
- Proves alfa i proves beta (guia completa)
- Proves funcionals contra proves no funcionals
- Tipus de proves de migració: amb escenaris de prova per a cada tipus
- Tutorial de proves d'usabilitat: una guia d'introducció completa
- 13 millors eines de migració de dades per a una integritat completa de les dades [LLISTA 2021]
- Guia completa de proves de verificació de compilació (proves BVT)
- Les millors eines de prova de programari 2021 [Eines d'automatització de proves de control de qualitat]