En este anexo el objetivo es tener una lista de las comprobaciones comunes que debe realizar el equipo de desarrollo de un proyecto cuando se aplican cambios sustanciales o se hace una migración (tecnológica, de servidor, de base de datos, etc.).
| Tabla de contenidos |
|---|
Comprobaciones a nivel de base de datos
Acceso a tablas
Se debe comprobar que el usuario de base de datos que use la aplicación sigue teniendo acceso a todas las tablas que se utilizan, tanto del propio usuario como las de otros esquemas que se usen.
...
- Si tenemos esta vista modelada como una entidad nuestra aplicación no arrancará diciendo que la tabla no existe
- Si accedemos a la vista por de manera nativa la aplicación sí arrancará pero fallará la consulta en cuestión diciendo que la tabla no existe.
Lectura de objetos BLOB y BFILE
Se debe comprobar que la lectura de objetos de tipo BLOB y BFile se sigue realizando de manera correcta por las aplicaciones.
Ejemplo: Tras una actualización del servidor Weblogic el driver jdbc se actualiza causando que algunos de los métodos utilizados para recuperar este tipo de objetos deje de funcionar correctamente. En ese caso la aplicación funcionará con normalidad pero lanzará una excepción cuando se intente recuperar este tipo de objetos.
Paquetes PL/SQL
Se debe comprobar que los paquetes PL/SQL siguen compilando correctamente y que la aplicación sigue pudiendo acceder a ellos con normalidad.
Ejemplo: Tras una actualización de la base de datos, se descompilan algunos paquetes PL/SQL, cuando la aplicación los invoque estos paquetes fallarán provocando una excepción en los servidores
Codificación
Se debe comprobar que no hay problemas de encoding a la hora de guardar o recuperar caracteres en base de datos.
Ejemplo: Tras un cambio en una parte de una aplicación se modifica el encoding por defecto en algunas pantallas. Esto provocará que los datos que se guarden en base de datos tendrán caracteres extraños debido a usar dos codificaciones diferentes. El usuario meterá la información de manera correcta, pero al gestionarla en el servidor se les hará un cambio de codificación que tendrá como consecuencia que esos datos se guarden con el encoding modificado y cuando se recuperen no se verán correctamente.
Sesiones bbdd
Se debe comprobar que la aplicación no deja sesiones abiertas en base de datos.
Ejemplo: Una aplicación creaba sus propias conexiones a base de datos sin usar un pool de conexiones. Tras una migración una parte de la lógica de negocio falla y no se cierran las conexiones a base de datos que se abrían. Esto causará problemas tanto en la aplicación como en la base de datos en general.
Comprobaciones en infraestructura o librerías
Carga de librerías
Se debe comprobar que todas las librerías del proyecto se cargan correctamente.
...
- La aplicación no arranca porque las librerías afectadas son necesarias desde el inicio.
- La aplicación arranca pero tiene una versión antigua de la librería que no es funcional y falla cuando se vaya a usar.
Acceso a servicios ajenos
Se debe comprobar que la aplicación sigue pudiendo acceder a servicios de terceros de manera que no haya un firewall que corte el acceso o se hayan cambiado las credenciales para usar el servicio.
...
- Nos indicará que no estoy autorizado a usar el recurso.
- Dará un timeout por no poder acceder al recurso (si el bloqueo está por firewall).
Logs
Se debe comprobar que los logs se siguen imprimiendo correctamente.
Ejemplo: Tras una migración de una aplicación, no se han configurado correctamente las colas Lagar lo que hace que no se vean nuevas trazas de log.
Acceso a ficheros de recursos
Se debe comprobar que todos los recursos (css, archivos, imágenes, etc) externos, locales o temporales a la aplicación se siguen recuperando correctamente.
...
- En recursos.um.es se activa la política CORS, es posible que las aplicaciones que carguen recursos desde ahí obtengan denegaciones de acceso por CORS.
- Mi aplicación tiene recursos en su sistema de ficheros local y se migra de versión de weblogic. Es posible que dichos recursos deban adaptar la ruta para recuperarlos correctamente.
Comprobaciones sobre el código fuente
Pruebas funcionales
Se deben realizar todas las pruebas funcionales y test de la aplicación para asegurar que el código sigue funcionando de manera satisfactoria.
...
- Si existe algún paquete de base de datos descompilado que no se ha detectado cuando las prueban pasen por esa parte de código el error se producirá.
- Si hay un cambio de versión de alguna librería, que hace que un método actual varíe, puede provocar problemas en su ejecución que sólo se detectarían haciendo uso del mismo.
- Si un cambio de versión de una librería hace que métodos que funcionaban correctamente dejen de hacerlo.
- Un cambio en la versión de Java puede introducir algún bug o modificar la manera en la que se debe llamar o procesar la respuesta de un determinado método. Una actualización de Java provocó un fallo en el parser XML que se incluye y se tuvo que volver a la versión anterior.
Pruebas de servicios
Se deben probar todos los servicios que exponemos a otras aplicaciones. Cuando se prueba una aplicación en ocasiones los servicios externos no se prueban porque no forman parte de la lógica de negocio principal por lo que cuando una aplicación los vaya a usar será cuando nos encontremos el error.
Ejemplo: Tras migrar nuestra aplicación, las credenciales de acceso a un servicio privado han cambiado. Si no realizamos las pruebas pertinentes no nos percataremos de este cambio.
Comprobaciones de dependencias externas
Interacción con servicios externos
Se debe comprobar que las interacciones de nuestra aplicación con servicios externos para verificar que el funcionamiento es correcto
...