La prueba de sistemas de software de bases 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:
Los datos son fundamentales desde el punto de vista empresarial. Empresas como Google o Symantec , que se dedican al almacenamiento de datos , necesitan contar con un sistema de base de datos duradero y consistente. Si se realizan operaciones de base de datos como insertar, eliminar y actualizar sin probar primero la consistencia de la base de datos, la empresa corre el riesgo de que se produzca un colapso de todo el sistema.
Algunas empresas tienen distintos tipos de bases de datos y también diferentes objetivos y misiones. Para lograr un nivel de funcionalidad que cumpla con dichos objetivos, necesitan probar su sistema de bases de datos.
Es posible que sea necesario un enfoque de prueba más amplio que el actual, en el que los desarrolladores prueban formalmente las bases de datos. Sin embargo, este enfoque no es lo suficientemente eficaz, ya que es probable que los desarrolladores de bases de datos ralenticen el proceso de prueba debido a las brechas 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 la web.
Las pruebas de bases de datos deben distinguirse de las estrategias para abordar otros problemas, como fallas de bases de datos, inserciones, eliminaciones o actualizaciones defectuosas. En este caso, la refactorización de bases de datos es una técnica evolutiva que puede aplicarse.
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.
Selecciona valores de tabla predeterminados para comprobar la consistencia de la base de datos.
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
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]
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:
Limpiar la base de datos: si los datos comprobables ya están presentes en la base de datos, es necesario vaciarla.
Configurar el accesorio: una herramienta como PHPUnit luego iterará sobre los accesorios y realizará inserciones en la base de datos.
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 ]
Una función comúnmente utilizada, [ vague ]create_input_dialog["label"] , se utiliza para validar la salida con las 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.
Para probar la carga de datos, se requiere conocimiento 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 base de datos para manejar consultas, así como el tiempo de respuesta del servidor de base de datos y del cliente. [6]
En las pruebas de bases de datos, a menudo se consideran cuestiones como la atomicidad, la consistencia, el aislamiento, la durabilidad, la integridad, la ejecución de activadores y la recuperación.
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.
Se requiere una sobrecarga adicional para determinar el estado de las transacciones de la base de datos.
Después de limpiar la base de datos, se deben diseñar nuevos casos de prueba. [ cita requerida ]
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.
^ Ambler, Scott (2003). Técnicas de bases de datos ágiles: estrategias efectivas para el desarrollador de software ágil . Wiley. ISBN978-0-471-20283-7.
^ Pressman, Roger (1994). Probador de software: un enfoque práctico . McGraw-Hill Education. ISBN978-0-07-707732-7.
^ 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. ISBN978-981-4021-64-7.
^ Kan, Stephen. Métricas y modelos en ingeniería de calidad de software . Pearson Education. ISBN978-81-297-0175-6.
^ "InfoWorld". 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". Agile Data . Consultado el 4 de diciembre de 2011 .
Zeichick, Alan; et al. (14 de agosto de 1989). How We Tested Integrated Software Packages [Cómo probamos paquetes de software integrados]. InfoWorld . Consultado el 4 de diciembre de 2011 .
Enlaces externos
Capítulo 8. Pruebas de bases de datos, del Manual de PHPUnit
Creación de conjuntos de datos para probar bases de datos relacionales
Cobertura de pruebas SQL
Acolyte Framework para simular JDBC para pruebas de persistencia