Tutorial de pruebas de bases de datos

Los miembros del equipo de prueba y desarrollo generalmente le dan más énfasis a la GUI, ya que la interfaz gráfica de usuario es la parte más visible de la aplicación. Sin embargo, lo que también es importante es validar la información que es el corazón de la aplicación, también conocida como BASE DE DATOS.

Consideremos una aplicación bancaria en la que un usuario realiza transacciones. Ahora bien, desde el punto de vista de las pruebas de bases de datos, los siguientes puntos son importantes:

1. La aplicación almacena la información de la transacción en la base de datos de la aplicación y la muestra correctamente al usuario.
2. No se pierde información en el proceso.
3. La aplicación no guarda información de operaciones parcialmente realizadas o abortadas.
4. Ninguna persona no autorizada tiene permitido acceder a la información del usuario.

Para garantizar todos estos objetivos anteriores, debemos utilizar la validación o prueba de datos.

Diferencias entre pruebas de interfaz de usuario y pruebas de datos

Pruebas de interfaz de usuario	Pruebas de bases de datos o datos
Este tipo de prueba también se conoce como prueba de interfaz gráfica de usuario o prueba de interfaz de usuario.	Este tipo de prueba también se conoce como Backend Testing o prueba de datos.
Este tipo de prueba se ocupa principalmente de todos los elementos comprobables que están abiertos al usuario para su visualización e interacción, como formularios, presentaciones, gráficos, menús e informes, etc. (creados a través de VB, VB.net, VC++, Delphi – Herramientas de interfaz de usuario)	Este tipo de prueba se ocupa principalmente de todos los elementos comprobables que generalmente están ocultos al usuario para su visualización. Estos incluyen procesos internos y almacenamiento como Assembly, DBMS como Oracle, Servidor SQL, MYSQL, etc.
Este tipo de prueba incluye validar el cuadros de texto seleccionar menús desplegables calendarios y botones Navegación de página visualización de imágenes Aspecto y sensación de la aplicación general.	Este tipo de pruebas implica validar: el esquema tablas de base de datos columnas claves e índices desencadenantes de procedimientos almacenados validaciones del servidor de base de datos validar la duplicación de datos
El evaluador debe tener un conocimiento profundo de los requisitos comerciales, así como del uso de las herramientas de desarrollo y el uso de marcos y herramientas de automatización.	Para poder realizar pruebas de backend, el evaluador debe tener una sólida experiencia en el servidor de bases de datos y los conceptos del lenguaje de consulta estructurado.

Tipos de pruebas de bases de datos

Los 3 tipos de pruebas de bases de datos son

1. Pruebas estructurales
2. Prueba de funcion
3. Pruebas no funcionales

En este tutorial de prueba de bases de datos, analizaremos cada tipo y sus subtipos uno por uno.

¿Qué es la prueba de esquemas?

Prueba de esquema en las pruebas de bases de datos valida varios formatos de esquema asociados con la base de datos y verifica si los formatos de mapeo de tablas/vistas/columnas son compatibles con los formatos de mapeo de la interfaz de usuario. El objetivo principal de las pruebas de esquema es garantizar que la asignación de esquemas entre el front-end y el back-end sea similar. Por lo tanto, también se le conoce como prueba de mapeo.

Analicemos los puntos de control más importantes para las pruebas de esquemas.

1. Validación de los distintos formatos de esquemas asociados a las bases de datos. Muchas veces el formato de mapeo de la tabla puede no ser compatible con el formato de mapeo presente en el nivel de interfaz de usuario de la aplicación.
2. Es necesaria una verificación en el caso de tablas/vistas/columnas no asignadas.
3. También es necesario verificar si las bases de datos heterogéneas en un entorno son consistentes con el mapeo general de la aplicación.

Veamos también algunas de las interesantes herramientas de prueba de bases de datos para validar esquemas de bases de datos.

• DBUnit integrado con Ant es muy adecuado para pruebas de mapeo.
• SQL Server permite a los evaluadores poder verificar y consultar el esquema de la base de datos escribiendo consultas simples y no mediante código.

Por ejemplo, si los desarrolladores quieren cambiar la estructura de una tabla o eliminarla, el evaluador querrá asegurarse de que todos los procedimientos almacenados y las vistas que utilizan esa tabla sean compatibles con el cambio en particular. Otro ejemplo podría ser que si los evaluadores desean verificar cambios de esquema entre dos bases de datos, pueden hacerlo mediante consultas simples.

Tabla de base de datos, prueba de columnas

Analicemos varias comprobaciones para pruebas de bases de datos y columnas.

1. ¿Si la asignación de los campos y columnas de la base de datos en el backend es compatible con esas asignaciones en el front-end?
2. Validación de la longitud y convención de nomenclatura de los campos y columnas de la base de datos según lo especificado por los requisitos.
3. Validación de la presencia de tablas/columnas de bases de datos no utilizadas o no asignadas.
4. Validación de la compatibilidad del

• tipo de datos
• longitudes de campo

de las columnas de la base de datos back-end con las presentes en el front-end de la aplicación.

5. Si los campos de la base de datos permiten al usuario proporcionar las entradas deseadas según lo requieren los documentos de especificación de requisitos comerciales.

Pruebas de claves e índices.

Comprobaciones importantes de claves e índices –

1. Compruebe si se requiere

• Clave primaria
• Clave externa

Se han creado restricciones en las tablas requeridas.

2. Compruebe si las referencias de claves foráneas son válidas.
3. Compruebe si el tipo de datos de la clave principal y las claves externas correspondientes son los mismos en las dos tablas.
4. Compruebe si se han seguido las convenciones de nomenclatura requeridas para todas las claves e índices.
5. Verifique el tamaño y la longitud de los campos e índices requeridos.
6. Si el requerido

• Clusteríndices ed
• no Clusteríndices ed

se han creado en las tablas requeridas según lo especificado por los requisitos comerciales.

Pruebas de procedimientos almacenados

Las pruebas importantes para comprobar los procedimientos almacenados son:

1. Si el equipo de desarrollo adoptó las convenciones estándar de codificación requeridas, A) y B) el manejo de excepciones y errores. Para todos los procedimientos almacenados para todos los módulos de la aplicación bajo prueba.
2. ¿Si el equipo de desarrollo cubrió todas las condiciones/bucles aplicando los datos de entrada requeridos a la aplicación bajo prueba?
3. ¿Si el equipo de desarrollo aplicó correctamente la operación TRIM cada vez que se obtienen datos de las tablas requeridas en la base de datos?
4. ¿La ejecución manual del procedimiento almacenado proporciona al usuario final el resultado requerido?
5. ¿La ejecución manual del procedimiento almacenado garantiza que los campos de la tabla se actualicen según lo requiere la aplicación bajo prueba?
6. ¿Si la ejecución de los procedimientos almacenados permite la invocación implícita de los desencadenantes requeridos?
7. Validación de la presencia de procedimientos almacenados no utilizados.
8. Validación para la condición Permitir nulo que se puede realizar a nivel de base de datos.
9. Validación de que todos los Procedimientos y Funciones Almacenados se han ejecutado exitosamente cuando la Base de Datos bajo prueba está en blanco.
10. Validación de la integración general de los módulos de procedimientos almacenados según los requisitos de la aplicación bajo prueba.

Algunas de las herramientas útiles de prueba de bases de datos para probar procedimientos almacenados son LINQ, la herramienta de prueba SP, etc.

Prueba de activación

1. ¿Se han seguido las convenciones de codificación requeridas durante la fase de codificación de los Activadores?
2. Verifique si los activadores ejecutados para las respectivas transacciones DML han cumplido las condiciones requeridas.
3. ¿Si el disparador actualiza los datos correctamente una vez que se han ejecutado?
4. Validación de la funcionalidad de activación requerida de Actualización/Inserción/Eliminación en el ámbito de la aplicación bajo prueba.

Validaciones del servidor de base de datos

1. Verifique las configuraciones del servidor de base de datos según lo especificado por los requisitos comerciales.
2. Verifique la autorización del usuario requerido para realizar solo aquellos niveles de acciones que requiere la aplicación.
3. Verifique que el servidor de la base de datos pueda satisfacer las necesidades del número máximo permitido de transacciones de usuario según lo especificado en las especificaciones de requisitos comerciales.

Pruebas funcionales de bases de datos

Pruebas funcionales de bases de datos es un tipo de prueba de base de datos que se utiliza para validar los requisitos funcionales de una base de datos desde la perspectiva del usuario final. El objetivo principal de las pruebas funcionales de bases de datos es probar si las transacciones y operaciones realizadas por los usuarios finales relacionadas con la base de datos funcionan como se esperaba o no.

A continuación se presentan las condiciones básicas que deben observarse para las validaciones de bases de datos.

• ¿El campo es obligatorio y se permiten valores NULL en ese campo?
• ¿Si la longitud de cada campo es de tamaño suficiente?
• ¿Todos los campos similares tienen los mismos nombres en todas las tablas?
• ¿Hay algún campo calculado presente en la base de datos?

Este proceso particular es la validación de las asignaciones de campos desde el punto de vista del usuario final. En este escenario particular, el evaluador realizaría una operación a nivel de base de datos y luego navegaría hasta el elemento relevante de la interfaz de usuario para observar y validar si se han realizado o no las validaciones de campo adecuadas.

También se debe cumplir la condición inversa, en la que el probador realiza la primera operación en la interfaz de usuario y luego la misma se valida desde el back-end.

Comprobación de la integridad y coherencia de los datos

Las siguientes comprobaciones son importantes

1. ¿Están los datos lógicamente bien organizados?
2. ¿Si los datos almacenados en las tablas son correctos y cumplen con los requisitos comerciales?
3. ¿Hay datos innecesarios presentes en la aplicación bajo prueba?
4. ¿Si los datos se han almacenado según el requisito con respecto a los datos que se han actualizado desde la interfaz de usuario?
5. ¿Se realizaron las operaciones TRIM en los datos antes de insertarlos en la base de datos bajo prueba?
6. ¿Si las transacciones se han realizado de acuerdo con las especificaciones de los requisitos comerciales y si los resultados son correctos o no?
7. ¿Si los datos se han confirmado correctamente si la transacción se ha ejecutado con éxito?
8. ¿Si los datos se han revertido correctamente si el usuario final no ha ejecutado correctamente la transacción?
9. ¿Se han revertido los datos si la transacción no se ha ejecutado correctamente y han estado involucradas múltiples bases de datos heterogéneas en la transacción en cuestión?
10. ¿Se han ejecutado todas las transacciones utilizando los procedimientos de diseño requeridos según lo especificado por los requisitos comerciales del sistema?

Inicio de sesión y seguridad del usuario

Las validaciones de las credenciales de inicio de sesión y seguridad del usuario deben tener en cuenta lo siguiente.

1. Si la aplicación impide que el usuario continúe con la aplicación en caso de un

• nombre de usuario no válido pero contraseña válida
• nombre de usuario válido pero contraseña no válida.
• nombre de usuario no válido y contraseña no válida.

2. ¿Se permite al usuario realizar solo aquellas operaciones específicas especificadas por los requisitos comerciales?
3. ¿Si los datos están protegidos contra el acceso no autorizado?
4. ¿Hay diferentes roles de usuario creados con diferentes permisos?
5. ¿Todos los usuarios tienen los niveles de acceso requeridos en la base de datos especificada según lo exigen las especificaciones comerciales?
6. Compruebe que los datos confidenciales, como contraseñas y números de tarjetas de crédito, estén cifrados y no almacenados como texto sin formato en la base de datos. Es una buena práctica asegurarse de que todas las cuentas tengan contraseñas complejas y difíciles de adivinar.

Pruebas no funcionales

Pruebas no funcionales en el contexto de las pruebas de bases de datos se pueden clasificar en varias categorías según lo requieran los requisitos comerciales. Estas pueden ser pruebas de carga, pruebas de estrés, Pruebas de seguridad, Las pruebas de usabilidad y Pruebas de compatibilidad, etcétera. Las pruebas de carga, así como las pruebas de estrés, que se pueden agrupar en la gama de pruebas de rendimiento, tienen dos propósitos específicos cuando se trata de la función de las pruebas no funcionales.

Cuantificación del riesgo– La cuantificación del riesgo ayuda a las partes interesadas a determinar los diversos requisitos de tiempo de respuesta del sistema bajo los niveles de carga requeridos. Esta es la intención original de cualquier garantía de calidad tarea. Debemos tener en cuenta que las pruebas de carga no mitigan el riesgo directamente, sino que, a través de los procesos de identificación y cuantificación del riesgo, presentan oportunidades correctivas y un impulso para la remediación que mitigará el riesgo.

Requisito mínimo de equipo del sistema– La configuración mínima del sistema que permitirá que el sistema cumpla con las expectativas de rendimiento formalmente establecidas por las partes interesadas, de modo que se puedan minimizar los costos de propiedad y hardware ajenos. Este requisito en particular se puede categorizar como el requisito general de optimización empresarial.

Prueba de carga

El propósito de cualquier prueba de carga debe entenderse y documentarse claramente. Los siguientes tipos de configuraciones son imprescindibles para Prueba de carga.

1. Las transacciones de usuario utilizadas con más frecuencia tienen el potencial de afectar el rendimiento de todas las demás transacciones si no son eficientes.
2. Se debe incluir al menos una transacción de usuario que no requiera edición en el conjunto de pruebas final, de modo que el rendimiento de dichas transacciones pueda diferenciarse de otras transacciones más complejas.
3. Deben incluirse las transacciones más importantes que facilitan los objetivos centrales del sistema, ya que la falla bajo una carga de estas transacciones tiene, por definición, el mayor impacto.
4. Se debe incluir al menos una transacción editable para que performance de dichas transacciones pueden diferenciarse de otras transacciones.
5. Tiempo de respuesta óptimo ante una gran cantidad de usuarios virtuales para todos los requisitos potenciales.
6. Tiempos efectivos para la recuperación de varios registros.

Herramientas importantes de prueba de carga son LoadRunner Profesional, gana corredor y JMeter.

Herramientas importantes para las pruebas de estrés son LoadRunner Profesional y JMeter.

Problemas más comunes que ocurren durante las pruebas de bases de datos

A significant amount of overhead could be involved to determine the state of the database transactions

La Solución: La planificación y el cronograma general del proceso deben organizarse de manera que no aparezcan problemas relacionados con el tiempo y los costos.

New test data have to be designed after cleaning up of the old test data.

La Solución: Se debe disponer de un plan y una metodología previos para la generación de datos de prueba.

An SQL generator is required to transform SQL validators in order to ensure the SQL queries are apt for handling the required database test cases.

La Solución: El mantenimiento de las consultas SQL y su actualización continua es una parte importante del proceso de prueba general que debería ser parte del proceso general. estrategia de prueba.

The above mentioned prerequisite ensure that the set-up of the database testing procedure could be costly as well as time consuming.

La Solución: Debe haber un delicado equilibrio entre la calidad y la duración general del cronograma del proyecto.

Mitos o conceptos erróneos relacionados con las pruebas de bases de datos

Database Testing requires plenty of expertise and it is a very tedious job

Realidad: Las pruebas de bases de datos eficaces y eficientes en las pruebas de software proporcionan estabilidad funcional a largo plazo a la aplicación general, por lo que es necesario trabajar duro para respaldarla.

Database testing adds extra work bottleneck

Realidad: Por el contrario, las pruebas de bases de datos agregan más valor al trabajo general al descubrir problemas ocultos y, por lo tanto, ayudar de manera proactiva a mejorar la aplicación general.

Database testing slows down the overall development process

Realidad: Una cantidad significativa de pruebas de bases de datos ayuda a la mejora general de la calidad de la aplicación de base de datos.

Database testing could be excessively costly

Realidad: Cualquier gasto en pruebas de bases de datos es una inversión a largo plazo que conduce a la estabilidad y solidez de la aplicación a largo plazo. Por lo tanto, el gasto en pruebas de bases de datos o SQL Es necesario realizar pruebas.

Mejores Prácticas

• Todos los datos, incluidos los metadatos y los datos funcionales, deben validarse de acuerdo con su asignación mediante los documentos de especificación de requisitos.
• Verificación de la datos de prueba que ha sido creado por/en consulta con el equipo de desarrollo debe ser validado.
• Validación de los datos de salida mediante el uso de procedimientos tanto manuales como automatizados.
• Implementación de diversas técnicas, como la técnica de gráficos de causa efecto, la técnica de partición de equivalencia y la técnica de análisis de valores límite para generar las condiciones de datos de prueba requeridas.
• También es necesario validar las reglas de validación de integridad referencial para las tablas de la base de datos requeridas.
• La selección de valores de tabla predeterminados para la validación de la coherencia de la base de datos es un concepto muy importante. Si los eventos de registro se han agregado correctamente en la base de datos para todos los eventos de inicio de sesión requeridos.
• ¿Se ejecutan los trabajos programados de manera oportuna?
• Realice una copia de seguridad oportuna de la base de datos.

También comprobar- Preguntas y respuestas de la entrevista sobre pruebas de bases de datos