Pruebas de bases de datos

Las pruebas de sistemas de software de bases de datos.

Las pruebas de bases de datos generalmente constan de un proceso en capas, que incluye la capa de interfaz de usuario (UI), la capa empresarial, la capa de acceso a datos y la propia base de datos. La capa UI se ocupa del diseño de la interfaz de la base de datos, mientras que la capa empresarial incluye bases de datos que respaldan las estrategias comerciales .

Propósitos

Las bases de datos , la colección de archivos interconectados en un servidor, que almacenan información, pueden no tratar el mismo tipo de datos, es decir, las bases de datos pueden ser heterogéneas . Como resultado, pueden ocurrir muchos tipos de errores de implementación e integración en grandes sistemas de bases de datos, que afectan negativamente el rendimiento, la confiabilidad, la coherencia y la seguridad del sistema. Por lo tanto, es importante realizar pruebas para obtener un sistema de base de datos que satisfaga las propiedades ACID (atomicidad, consistencia, aislamiento y durabilidad) de un sistema de gestión de bases de datos . ^[1]

Una de las capas más críticas es la capa de acceso a datos, que trata directamente con las bases de datos durante el proceso de comunicación. Las pruebas de bases de datos se llevan a cabo principalmente en esta capa e implican estrategias de prueba como el control de calidad y el aseguramiento de la calidad de las bases de datos del producto. ^[2] Las pruebas en estas diferentes capas se utilizan con frecuencia para mantener la coherencia de los sistemas de bases de datos, como se ve más comúnmente en los siguientes ejemplos:

• Los datos son críticos desde el punto de vista empresarial. Empresas como Google o Symantec , que se dedican al almacenamiento de datos , necesitan tener un sistema de base de datos duradero y consistente. Si las operaciones de la base de datos, como insertar, eliminar y actualizar, se realizan sin probar primero la coherencia de la base de datos, la empresa corre el riesgo de que todo el sistema colapse.
• Algunas empresas tienen diferentes tipos de bases de datos, y también diferentes objetivos y misiones. Para lograr un nivel de funcionalidad que permita alcanzar dichos objetivos, necesitan probar su sistema de base de datos.
• Es posible que sea necesario algo más que el enfoque actual de pruebas en el que los desarrolladores prueban formalmente las bases de datos. Sin embargo, este enfoque no es suficientemente eficaz ya que es probable que los desarrolladores de bases de datos ralenticen el proceso de prueba debido a lagunas de comunicación. Parece aconsejable contar con un equipo de prueba de bases de datos independiente.
• Las pruebas de bases de datos se ocupan principalmente de encontrar errores en las bases de datos para eliminarlos. Esto mejorará la calidad de la base de datos o del sistema basado en web.
• Las pruebas de bases de datos deben distinguirse de las estrategias para abordar otros problemas, como fallas de la base de datos, inserciones fallidas, eliminaciones o actualizaciones. Aquí, la refactorización de bases de datos es una técnica evolutiva que puede aplicarse.

Tipos de pruebas y procesos

Pruebas de caja negra y caja blanca en la prueba de base de datos

La figura indica las áreas de prueba involucradas durante los diferentes métodos de prueba de bases de datos, como las pruebas de caja negra y las pruebas de caja blanca .

Caja negra

Las pruebas de caja negra implican probar interfaces y la integración de la base de datos, que incluye:

1. Mapeo de datos (incluidos metadatos )
2. Verificar datos entrantes
3. Verificar datos salientes de funciones de consulta
4. Varias técnicas, como la técnica de gráficos de causa efecto, partición de equivalencia y análisis de valores límite .

Con la ayuda de estas técnicas, se puede probar exhaustivamente la funcionalidad de la base de datos.

Los pros y los contras de las pruebas de caja negra incluyen: La generación de casos de prueba en las pruebas de caja negra es bastante simple. Su generación es completamente independiente del desarrollo del software y puede realizarse en una etapa temprana de desarrollo. Como consecuencia, el programador tiene un mejor conocimiento de cómo diseñar la aplicación de base de datos y utiliza menos tiempo para la depuración. El costo del desarrollo de casos de prueba de caja negra es menor que el del desarrollo de casos de prueba de caja blanca. El principal inconveniente de las pruebas de caja negra es que se desconoce qué parte del programa se está probando. Además, ciertos errores no se pueden detectar. ^[3]

Caja blanca

Las pruebas de caja blanca se ocupan principalmente de la estructura interna de la base de datos. Los detalles de las especificaciones están ocultos para el usuario.

1. Implica la prueba de activadores de bases de datos y vistas lógicas que respaldarán la refactorización de bases de datos .
2. Realiza pruebas de módulos de funciones de bases de datos, activadores, vistas, consultas SQL , etc.
3. Valida tablas de bases de datos, modelos de datos, esquemas de bases de datos, etc.
4. Comprueba reglas de integridad referencial .
5. Selecciona valores de tabla predeterminados para verificar la coherencia de la base de datos.
6. Las técnicas utilizadas en las pruebas de caja blanca son cobertura de condiciones, cobertura de decisiones, cobertura de declaraciones y complejidad ciclomática .

La principal ventaja de las pruebas de caja blanca en las pruebas de bases de datos es que se detectan errores de codificación, por lo que se pueden eliminar 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.

El enfoque WHODATE

Enfoque WHODATE para la transformación de declaraciones SQL

Al generar casos de prueba para pruebas de bases de datos, la semántica de la declaración SQL debe reflejarse en los casos de prueba. Para ello se utiliza una técnica denominada Técnica de Aplicación de Base de Datos WHite bOx "(WHODATE)". Como se muestra en la figura, las declaraciones SQL se convierten de forma independiente en declaraciones GPL, seguidas de pruebas de caja blanca tradicionales para generar casos de prueba que incluyen semántica SQL. ^[4]

Cuatro etapas

• Establecer accesorio
• Prueba de funcionamiento
• Verificación de resultados
• Demoler

Un dispositivo establecido describe el estado inicial de la base de datos antes de ingresar a la prueba. Después de configurar los accesorios, se prueba el comportamiento de la base de datos para casos de prueba definidos. Dependiendo del resultado, los casos de prueba se modifican o se mantienen tal cual. La etapa de "derribar" da como resultado la finalización de las pruebas o la continuación de otros casos de prueba. ^[5]

Para una prueba exitosa de la base de datos, comúnmente se ejecuta el siguiente flujo de trabajo ejecutado por cada prueba:

1. Limpiar la base de datos: si los datos comprobables ya están presentes en la base de datos, es necesario vaciar la base de datos.
2. Configurar dispositivos: una herramienta como PHPUnit iterará sobre los dispositivos y realizará inserciones en la base de datos.
3. Ejecutar la prueba, verificar el resultado y luego derribar: después de restablecer la base de datos para vaciarla y enumerar los accesorios, se ejecuta la prueba y se verifica el resultado. Si el resultado es el esperado, se procede al proceso de desmontaje; de ​​lo contrario, se repiten las pruebas. ^{[ cita necesaria ]}

Técnicas básicas

• SQL Query Analyzer es una herramienta útil cuando se utiliza Microsoft SQL Server . ^{[ cita necesaria ]}
• Una función comúnmente utilizada, ^{[ vaga ]} create_input_dialog["label"] , se utiliza para validar la salida con entradas del usuario.
• El diseño de formularios para pruebas automatizadas de bases de datos, formularios front-end y back-end, es útil para los trabajadores de mantenimiento de bases de datos.
• Pruebas de carga de datos :
  • Para las pruebas de carga de datos, se requieren conocimientos sobre la base de datos de origen y la base de datos de destino.
  • Los trabajadores verifican la compatibilidad entre la base de datos de origen y la base de datos de destino utilizando el paquete DTS .
  • Al actualizar la base de datos de origen, los trabajadores se aseguran de compararla con la base de datos de destino.
  • Las pruebas de carga de la base de datos miden la capacidad del servidor de la base de datos para manejar consultas, así como el tiempo de respuesta del servidor y el cliente de la base de datos. ^[6]
• En las pruebas de bases de datos, a menudo se consideran cuestiones como la atomicidad, la coherencia, el aislamiento, la durabilidad, la integridad, la ejecución de desencadenadores y la recuperación.

1. La configuración para las pruebas de bases de datos es costosa y compleja de mantener porque los sistemas de bases de datos cambian constantemente con las operaciones esperadas de inserción, eliminación y actualización.
2. Se requiere una sobrecarga adicional para determinar el estado de las transacciones de la base de datos.
3. Después de limpiar la base de datos, es necesario diseñar nuevos casos de prueba. ^{[ cita necesaria ]}
4. Se necesita un generador de SQL para transformar declaraciones SQL con el fin de incluir la semántica de SQL en los casos de prueba de la base de datos.

Ver también

• Normalización de bases de datos
• Pruebas de software
• Examen de la unidad

Referencias

1. Korth, Henry (2010). Conceptos del sistema de base de datos . Macgraw-Hill. ISBN 978-0-07-352332-3.
2. Ambler, Scott (2003). Técnicas de bases de datos ágiles: estrategias efectivas para el desarrollador de software ágil . wiley. ISBN 978-0-471-20283-7.
3. Pressman, Roger (1994). Probador de software: un enfoque profesional . Educación McGraw-Hill. ISBN 978-0-07-707732-7.
4. Zhang, Yanchun (1999). Bases de datos y aplicaciones cooperativas '99: actas del Segundo Simposio internacional sobre sistemas de bases de datos cooperativas para aplicaciones avanzadas (CODAS '99), Wollongong, Australia, 27 al 28 de marzo de 1999 . Saltador. ISBN 978-981-4021-64-7.
5. Kan, Esteban. Métricas y modelos en ingeniería de calidad de software . Educación Pearson. ISBN 978-81-297-0175-6.
6. "InfoMundo". InfoWorld Media Group, Inc. 15 de enero de 1996.

• Ambler, Scott W. (2006). "Pruebas de bases de datos: cómo realizar pruebas de regresión en una base de datos relacional". Datos ágiles . Consultado el 4 de diciembre de 2011 .
• Zeichick, Alan; et al. (14 de agosto de 1989). Cómo probamos los paquetes de software integrados. InfoMundo . Consultado el 4 de diciembre de 2011 .

enlaces externos

• Capítulo 8. Pruebas de bases de datos, del manual PHPUnit
• Creación de conjuntos de datos para probar bases de datos relacionales
• Cobertura de prueba SQL
• Acolyte Framework simulará JDBC para pruebas de persistencia