stringtranslate.com

Prueba de base de datos

Las pruebas de bases de datos suelen constar 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 base de datos en sí. La capa de 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 empresariales .

Propósitos

Las bases de datos , que son un conjunto de archivos interconectados en un servidor que almacenan información, pueden no manejar el mismo tipo de datos, es decir, pueden ser heterogéneas . Como resultado, pueden ocurrir muchos tipos de errores de implementación e integración en sistemas de bases de datos grandes, lo que afecta negativamente el rendimiento, la confiabilidad, la consistencia 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 administración de bases de datos . [1]

Una de las capas más críticas es la capa de acceso a datos, que se ocupa de las bases de datos directamente durante el proceso de comunicación. Las pruebas de bases de datos se realizan principalmente en esta capa e implican estrategias de prueba como el control de calidad y la garantía de calidad de las bases de datos de productos. [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 con más frecuencia en los siguientes ejemplos:

Tipos de pruebas y procesos

Pruebas de caja negra y caja blanca en pruebas de bases de datos

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

Caja negra

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

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

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

Las ventajas y desventajas 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 se puede realizar en una etapa temprana del 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 de desarrollo de casos de prueba de caja negra es menor que el desarrollo de casos de prueba de caja blanca. La principal desventaja de las pruebas de caja negra es que se desconoce qué parte del programa se está probando. Además, no se pueden detectar ciertos errores. [3]

Caja blanca

Las pruebas de caja blanca se ocupan principalmente de la estructura interna de la base de datos. Los detalles de la especificación quedan ocultos al usuario.

  1. Implica la prueba de activadores de bases de datos y vistas lógicas que respaldarán la refactorización de la base de datos .
  2. Realiza pruebas de módulos de funciones de base de datos, disparadores, vistas, consultas SQL , etc.
  3. Valida tablas de bases de datos, modelos de datos, esquemas de bases de datos, etc.
  4. Comprueba las reglas de integridad referencial .
  5. Selecciona valores de tabla predeterminados para comprobar la consistencia de la base de datos.
  6. Las técnicas utilizadas en las pruebas de caja blanca son cobertura de condición, cobertura de decisión, cobertura de declaración 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 no se cubren las sentencias SQL.

El enfoque WHODATE

Enfoque WHODATE para la transformación de sentencias SQL

Al generar casos de prueba para la prueba 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 de caja blanca "(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

Un conjunto de parámetros describe el estado inicial de la base de datos antes de entrar en la fase de prueba. Después de establecer los parámetros, se prueba el comportamiento de la base de datos para los casos de prueba definidos. Según el resultado, los casos de prueba se modifican o se mantienen como están. La etapa de "desmantelamiento" da como resultado la finalización de la prueba o la continuación de otros casos de prueba. [5]

Para realizar pruebas de base de datos exitosas, generalmente se ejecuta el siguiente flujo de trabajo en cada prueba individual:

  1. Limpiar la base de datos: si los datos comprobables ya están presentes en la base de datos, es necesario vaciarla.
  2. Configurar el accesorio: una herramienta como PHPUnit luego iterará sobre los accesorios y realizará inserciones en la base de datos.
  3. Ejecutar la prueba, verificar el resultado y luego desmantelar: después de restablecer la base de datos y dejarla vacía, y enumerar los eventos, se ejecuta la prueba y se verifica el resultado. Si el resultado es el esperado, se continúa con el proceso de desmantelamiento; de lo contrario, se repite la prueba. [ cita requerida ]

Técnicas básicas

  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, se deben diseñar nuevos casos de prueba. [ cita requerida ]
  4. Se necesita un generador de SQL para transformar declaraciones SQL con el fin de incluir la semántica SQL en los casos de prueba de la base de datos.


Véase también

Referencias

  1. ^ Korth, Henry (2010). Conceptos de sistemas de bases 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 práctico . McGraw-Hill Education. 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 y 28 de marzo de 1999. Springer. ISBN 978-981-4021-64-7.
  5. ^ Kan, Stephen. Métricas y modelos en ingeniería de calidad de software . Pearson Education. ISBN 978-81-297-0175-6.
  6. ^ "InfoWorld". InfoWorld Media Group, Inc. 15 de enero de 1996.

Enlaces externos