Pruebas de bases de datos: tipos
Según la función y estructura de una base de datos, las pruebas de bases de datos se pueden clasificar en tres categorías:
Structural Database Testing - Se ocupa de pruebas de tablas y columnas, pruebas de esquemas, pruebas de procedimientos almacenados y vistas, verificación de activadores, etc.
Functional Testing- Implica comprobar la funcionalidad de la base de datos desde el punto de vista del usuario. El tipo más común de pruebas funcionales son las pruebas de caja blanca y caja negra.
Nonfunctional Testing - Implica pruebas de carga, pruebas de riesgo en la base de datos, pruebas de estrés, requisitos mínimos del sistema y se ocupa del rendimiento de la base de datos.
Pruebas de bases de datos estructurales
Las pruebas de bases de datos estructurales implican verificar aquellos componentes de la base de datos que no están expuestos a los usuarios finales. Involucra todos los componentes del repositorio, que se utilizan para almacenar los datos y no son modificados por los usuarios finales. Los administradores de bases de datos con buen dominio de los procedimientos almacenados de SQL y otros conceptos normalmente realizan estas pruebas.
Se discuten los componentes comunes probados con respecto a las pruebas estructurales:
Prueba de esquema / mapeo
Implica validar los objetos de la aplicación front-end con mapeo de objetos de base de datos.
En pruebas de esquema -
A veces sucede que los objetos de la aplicación del usuario final no están correctamente mapeados o no son compatibles con los objetos de la base de datos. Por tanto, es necesario comprobar la validación de los distintos formatos de esquema asociados a las bases de datos.
Se requiere encontrar los objetos no mapeados en la base de datos, como tablas, vistas, columnas, etc.
Existen varias herramientas en el mercado que se pueden utilizar para realizar el mapeo de objetos en esquemas.
Example - En Microsoft SQL Server, un evaluador puede escribir consultas simples para verificar y validar esquemas en la base de datos.
Si el probador desea realizar cambios en la estructura de una tabla, debe asegurarse de que todos los stored Los procedimientos que tienen esa tabla son compatibles con este cambio.
Pruebas de vistas y procedimientos almacenados
En esta prueba, un evaluador se asegura de que la ejecución manual de los procedimientos almacenados y las vistas generen el resultado requerido.
El probador asegura:
Si permite que los disparadores necesarios se ejecuten como se esperaba.
Si el equipo de desarrollo ha cubierto todos los bucles y condiciones pasando información a las aplicaciones en los procedimientos.
Si hay procedimientos almacenados no utilizados en la base de datos.
Las operaciones TRIM se aplican correctamente cuando los datos se obtienen de las tablas requeridas en la base de datos.
Validación de la integración general de los módulos de procedimiento almacenado según los requisitos de la aplicación bajo prueba.
Se siguen los mecanismos de manejo de excepciones y errores.
Las herramientas más comunes que se utilizan para realizar pruebas de procedimientos almacenados son LINQ, SP Test tooletc.
Prueba de activación
En las pruebas de activación, un probador debe asegurarse de lo siguiente:
Si se siguen las convenciones de codificación durante la fase de codificación de los activadores.
Ver que los disparadores ejecutados cumplen las condiciones requeridas.
Si el disparador actualiza los datos correctamente, una vez que se han ejecutado.
La validación de Actualizar / Insertar / Eliminar activa la funcionalidad de la aplicación bajo prueba.
Pruebas de tablas y columnas
Las áreas clave cubiertas en esta prueba son:
Validación de los tipos de datos en la base de datos a valores de campo en la aplicación de front-end.
Validación de la longitud del campo de datos en la base de datos a la longitud de los tipos de datos en la aplicación.
Comprobar si hay tablas o columnas sin asignar en la base de datos de los objetos de campo de la aplicación.
Se verifican las convenciones de nomenclatura de las tablas y columnas de la base de datos, si cumplen o no con los requisitos comerciales.
Validación de las claves e índices en la base de datos, es decir, las claves primarias y externas en las tablas se definen según el requisito.
Compruebe si las claves principales y sus claves externas correspondientes son las mismas en dos tablas.
Compruebe que se mantienen las características únicas y NO NULAS de las claves.
La longitud y el tipo de datos de las claves e índices se mantienen según los requisitos.
Verificación del servidor de base de datos
La verificación del servidor de base de datos implica verificar:
Si el servidor de la base de datos puede manejar el número esperado de transacciones según los requisitos comerciales.
Si los detalles de configuración de los servidores de bases de datos cumplen con los requisitos comerciales.
Si la autorización del usuario se mantiene según el requisito.
Pruebas funcionales
Las pruebas funcionales se realizan teniendo en cuenta el punto de vista del usuario final; si las transacciones y operaciones requeridas ejecutadas por los usuarios finales cumplen con las especificaciones comerciales.
Prueba de caja negra
Black Box Testing implica verificar la integración de la base de datos para verificar la funcionalidad. Los casos de prueba son simples y se utilizan para verificar los datos entrantes y salientes de la función.
Para probar la funcionalidad de la base de datos se utilizan diversas técnicas, como la técnica de creación de gráficos de causa-efecto, la partición de equivalencia y el análisis de valor límite.
Sus advantages son los siguientes:
- Es bastante simple y se realiza en las primeras etapas de desarrollo.
- El costo de desarrollar casos de prueba es menor en comparación con las pruebas de caja blanca.
Sus desventajas son las siguientes:
- No se pueden detectar algunos errores
- Se desconoce cuánto programa debe probarse.
Prueba de caja blanca
White Box Testing se ocupa de la estructura interna de la base de datos y los detalles de las especificaciones se ocultan a los usuarios. Implica la prueba de los disparadores de la base de datos y las vistas lógicas, que van a admitir la refactorización de la base de datos.
Realiza pruebas de módulo de funciones de base de datos, disparadores, vistas, consultas SQL, etc. Este tipo de prueba valida tablas de base de datos, modelos de datos, esquema de base de datos, etc. Verifica las reglas de integridad referencial. Selecciona los valores predeterminados de la tabla para verificar la coherencia de la base de datos.
Las técnicas más comunes que se utilizan para realizar pruebas de caja blanca son la cobertura de condiciones, la cobertura de decisiones, la cobertura de declaraciones, etc.
Los errores de codificación se pueden detectar en las pruebas de caja blanca, por lo que se pueden eliminar los errores internos en la base de datos. La limitación de las pruebas de caja blanca es que las declaraciones SQL no están cubiertas.
Pruebas no funcionales
Las pruebas no funcionales implican realizar pruebas de carga, pruebas de estrés, verificar los requisitos mínimos del sistema para cumplir con las especificaciones comerciales, encontrar riesgos y optimizar el rendimiento de la base de datos.
Prueba de carga
El objetivo principal de las pruebas de carga es comprobar si la mayoría de las transacciones en ejecución tienen un impacto en el rendimiento de la base de datos.
En la prueba de carga, el probador verifica:
- El tiempo de respuesta para ejecutar las transacciones para múltiples usuarios remotos.
- Tiempo que tarda la base de datos en recuperar registros específicos.
Examples of load testing in different testing types -
- Ejecutar la transacción más utilizada repetidamente para ver el rendimiento del sistema de base de datos.
- Descarga de una serie de archivos grandes de Internet.
- Ejecutar múltiples aplicaciones en una computadora o servidor simultáneamente.
Pruebas de estrés
Las pruebas de estrés se realizan para identificar el punto de interrupción del sistema. En esta prueba, la aplicación se carga de tal manera que el sistema falla en un punto. Este punto se llamabreakpoint del sistema de base de datos.
Determinar el estado de las transacciones de la base de datos implica un esfuerzo considerable. Se requiere una planificación adecuada para evitar problemas de tiempo y costos.
Las herramientas de prueba de esfuerzo más utilizadas son LoadRunner y WinRunner.
Tomemos un examplede las pruebas de estrés. Una aplicación CRM puede tener una carga máxima de usuarios de 50000 usuarios simultáneos. Suponga que aumenta la carga a 51000 y realiza algunas transacciones, como actualizar registros o agregar una entrada. Tan pronto como realice la transacción, la aplicación puede sincronizarse con el sistema de base de datos. Por lo tanto, la siguiente prueba debe realizarse con una carga de usuarios de 52000. A veces, la prueba de estrés también se llamaFatigue Testing.