Calidad de datos en pruebas de regresión de bases de datos relacionales

He estado trabajando en una aplicación web de gestión de colecciones de museos de código abierto que se utilizará para realizar un seguimiento de los artefactos adheridos, donados, prestados o adquiridos de un museo.

Esto implicó diseñar y crear una base de datos bastante grande (en relación con mis experiencias anteriores), que almacena todo tipo de información variada (información de artefactos, información de ubicación cambiante, información de contacto personal, imágenes, etc.), que debe ser flexible y fácilmente ampliable .

Acabo de terminar mi título universitario y no soy un profesional en lo que respecta al diseño de bases de datos, por lo que realmente quiero crear un conjunto de pruebas exhaustivas para asegurar que lo que tengo en el lugar "funcione".

He leído sobre las pruebas de bases de datos y he encontrado algunos artículos que mencionan las pruebas de regresión en lo que respecta a las bases de datos, pero no entiendo completamente qué implica todo esto. Al leer este artículo en Dr.Dobbs , entiendo que un tipo de prueba que tendré que hacer es validar que la lógica en la base de datos es correcta. Por lo tanto, crearía pruebas que insertaran ciertos datos en la base de datos y luego siguiera con una consulta para asegurarme de que recupere los datos correctos de la base de datos (asegurándome de que todos los disparadores o vistas apropiados funcionen).

La confusión viene con la mención de las pruebas de "Calidad de datos". En el artículo anterior, el autor menciona que desea validar lo siguiente con las pruebas:

• Reglas de valor de dominio de columna
• Reglas de valor predeterminado de columna
• Reglas de existencia de valor
• Reglas de valor de fila
• Reglas de tamaño

¿Qué tipos de pruebas implicaría esto y cómo se implementarían? Además, esta es la primera vez que escribo un conjunto de pruebas para una base de datos, ¿hay alguna buena guía sobre cómo / dónde comenzar o algún proceso que pueda seguir para guiar el desarrollo de mi prueba?

Una respuesta completa a esta pregunta sería muy larga. Trataré de mencionar los puntos principales.

Para separar las preocupaciones, es posible que esté buscando pruebas para:

A - Validar el diseño de la base de datos.

B - Valide que los programas interactúen correctamente con la base de datos.

La validación del diseño de la base de datos debe ser realizada por las personas que diseñaron la base de datos. Los desarrolladores (durante las pruebas unitarias) deberían preocuparse más por la parte (B). La principal diferencia que veo entre los dos tipos de pruebas son las herramientas utilizadas. Para (A), usaría un entorno independiente del código del proyecto, mientras que en (B), por supuesto, usaría el código del proyecto. En el siguiente texto, mezclaré ambos.

Para responder a sus preguntas específicas:

Reglas de valor de dominio de columna

Cada columna tiene un tipo de datos asociado. Cada columna debe validarse según las reglas de negocio para demostrar que representa el tipo de datos correcto. Pueden surgir problemas si el tipo de datos de la columna no es compatible con los requisitos comerciales o si el código usa un tipo de datos diferente de cómo se define en la base de datos.

Por ejemplo:

• Si la columna se define como int pequeño, no debería poder almacenar texto en ella. Esta es una prueba importante, especialmente cuando las columnas son opcionales, ya que podrían pasar desapercibidas hasta que alguien ingrese algunos datos.

• ¿Podría almacenar un valor negativo en una columna donde la empresa requiere que eso suceda?

Reglas de valor predeterminado de columna

Algunas columnas están asociadas con una especificación de valor predeterminado en el DDL (Data Def. Language) donde si durante la inserción la inserción no proporciona un valor, la base de datos asumirá el valor predeterminado. Esto se puede probar al no pasar el valor y observar el valor del resultado que almacena la base de datos. Esta prueba también puede incluir la comprobación de columnas anulables. Esto rara vez requiere una prueba, ya que se puede verificar desde DDL a menos que se cree un índice único en la columna.

Reglas de existencia de valor

Según tengo entendido, verifica que los datos insertados o actualizados se muestran como se espera en la base de datos.

Reglas de valor de fila

No tengo claro qué significa exactamente esto.

Reglas de tamaño

Cada columna tiene un tamaño en la base de datos en función de cómo se define en DDL. desea asegurarse de que cualquier valor que se ajuste a los requisitos (ya sea ingresado en la GUI del formulario o resultante como resultado de un cálculo) se almacenará correctamente en la columna. Por ejemplo, un tipo de datos de entero pequeño no le permite almacenar un valor de 5 mil millones. Además, un nombre definido como VARCHAR2 (30) no tendrá capacidad para 40 caracteres, por lo que las reglas de negocio deben ser muy claras aquí, especialmente cuando la columna se utiliza para agregar datos. Desea probar lo que sucede en tales situaciones.

pautas sobre cómo / dónde comenzar

Una forma de hacerlo es idear un plan de prueba. Desea asegurarse de estar utilizando la versión correcta de las especificaciones (como documentos de requisitos y casos de uso) y del software. También necesita coordinar estas pruebas con las pruebas realizadas por Unit Testing (si corresponde). Puede encontrar pruebas duplicadas que no necesita realizar nuevamente. Desea tomar una copia de la base de datos antes de la prueba para poder repetir una prueba específica si alguna vez lo necesita. El DBA puede ayudarlo con esto. También debe verificar con su equipo cómo documentan estas pruebas y verificar el alcance de las pruebas con ellos. Puede dividir su base de datos en partes lógicas y comenzar a probar cada parte lógica por separado. El proceso de prueba podría comenzar estudiando el DDL de la base de datos y verificando que las columnas estén definidas correctamente según lo requiera la empresa. Debería utilizar el software de la aplicación y ninguna otra herramienta para realizar la mayoría de las pruebas. Por ejemplo, pregunta lo siguiente:

• Se supone que la columna es del tipo definido (no tiene sentido hacer un Nombre como Int).

• ¿El tamaño es compatible con los requisitos comerciales?

• ¿Se encuentran todas las columnas en los requisitos comerciales en la base de datos?

• ¿Las columnas nulas son realmente opcionales?

• etc.

A continuación, puede diseñar casos de prueba para probar lo anterior. Puede usar la GUI para hacer la mayoría de las pruebas.

Hay otras pruebas importantes de bases de datos que no ha mencionado. Los que tratan con:

1 - Prueba de que las claves principales son realmente únicas desde una perspectiva empresarial.

2 - Prueba de que los índices únicos (que no sean PK) son realmente únicos desde la perspectiva empresarial.

3 - Las restricciones de prueba de clave externa funcionan.

4 - Prueba de lo que sucede cuando se eliminan las filas y su efecto en las filas relacionadas.

5 - Otras pruebas con respecto a construcciones especiales de bases de datos como CHEKC, activadores si existen.

6 - Normalización correcta de la tabla y que las columnas normalizadas contienen valores correctos.

Lo anterior no es una lista completa, pero debería ayudarlo a comenzar.

Creo que te estás acercando a esto de la manera incorrecta.

Cualquier base de datos que conozca verifica los datos antes de insertarlos en las tablas; los valida con la definición de cada columna. No puede ingresar una cadena de 80 caracteres en una columna SMALLINT (3): la base de datos fallará ese intento y le informará que ha cometido un error. No necesita probarlo usted mismo insertando los datos y luego recuperándolos.

Lo que desea tener son reglas de validación / filtrado de datos antes de enviarlos a la base de datos.

• Asegurarse de que los datos se ajustan a los tipos y rangos aceptados para cada columna, y filtrar contenido no deseado
• Asegurándose de escapar correctamente para evitar errores (y posibles inyecciones de SQL si tiene una interfaz pública)

Esas reglas de validación / filtrado deben ejecutarse en los datos de su aplicación real. Luego, puede configurar las pruebas para asegurarse de que sean correctas, alimentándola con datos correctos e incorrectos para asegurarse de que aprueba o falla la validación en consecuencia.

En cuanto al diseño de la base de datos, realmente no se puede verificar con pruebas, ya que muchos diseños funcionarán incluso si no son ideales (y la definición de cambios ideales entre diferentes personas). El diseño adecuado de la base de datos viene con experiencia y conocimiento, no con pruebas automatizadas.