database testing complete guide why
Una guía completa para las pruebas de bases de datos con consejos prácticos y ejemplos:
Las aplicaciones informáticas son más complejas en estos días con tecnologías como Android y también con muchas aplicaciones para teléfonos inteligentes. Cuanto más complejos son los extremos frontales, más intrincados se vuelven los extremos posteriores.
Por lo tanto, es muy importante aprender sobre las pruebas de bases de datos y poder validar las bases de datos de manera efectiva para garantizar la seguridad y la calidad de las bases de datos.
En este tutorial, aprenderá todo sobre las pruebas de datos: ¿por qué, cómo y qué probar?
La base de datos es una de las partes inevitables de una aplicación de software.
No importa si se trata de una web, escritorio o móvil, cliente-servidor, peer-to-peer, empresa o negocio individual; la base de datos es necesaria en todas partes en el backend.
Del mismo modo, ya sea para atención médica, finanzas, arrendamiento, venta minorista, aplicación de correo o control de una nave espacial; una base de datos siempre está en acción detrás de escena.
A medida que aumenta la complejidad de la aplicación, surge la necesidad de una base de datos más sólida y segura. De la misma forma, para las aplicaciones con alta frecuencia de transacciones ( Por ejemplo, Aplicación bancaria o financiera), se combina la necesidad de una herramienta de base de datos con todas las funciones.
Hoy en día, tenemos macrodatos que son grandes y complejos y las bases de datos tradicionales no pueden manejarlos.
Hay varios Herramientas de base de datos están disponibles en el mercado Por ejemplo, MS-Access, MS SQL Server, SQL Server, Oracle, Oracle Financial, MySQL, PostgreSQL, DB2, Toad, Admirer, etc. Estas herramientas varían en costo, solidez, características y seguridad. Cada uno de estos tiene sus propios beneficios e inconvenientes.
Lo que vas a aprender:
- ¿Por qué probar la base de datos?
- Qué probar (lista de verificación de prueba de la base de datos)
- Cómo probar la base de datos (proceso paso a paso)
¿Por qué probar la base de datos?
A continuación, veremos por qué se deben validar los siguientes aspectos de una base de datos:
# 1) Mapeo de datos
En los sistemas de software, los datos a menudo viajan hacia adelante y hacia atrás desde la UI (interfaz de usuario) a la base de datos de back-end y viceversa. Estos son algunos aspectos a tener en cuenta:
- Compruebe si los campos de los formularios de interfaz de usuario / interfaz están asignados de forma coherente con los campos correspondientes de la tabla de base de datos. Normalmente, esta información de mapeo se define en los documentos de requisitos.
- Siempre que se realiza una determinada acción en el front-end de una aplicación, se invoca una acción CRUD (Crear, Recuperar, Actualizar y Eliminar) correspondiente en el back-end. Un evaluador tendrá que verificar si se invoca la acción correcta y si la acción invocada en sí misma es exitosa o no.
# 2) Validación de propiedades ACID
Atomicidad, consistencia, aislamiento y durabilidad. Cada transacción que realiza una base de datos debe cumplir estas cuatro propiedades.
- Atomicidad significa que una transacción falla o pasa. Esto significa que incluso si una sola parte de la transacción falla, significa que toda la transacción ha fallado. Por lo general, esto se llama la regla de 'todo o nada'.
- Consistencia : Una transacción siempre dará como resultado un estado válido de la base de datos
- Aislamiento : Si hay varias transacciones y se ejecutan todas a la vez, el resultado / estado de la base de datos debería ser el mismo que si se ejecutaran una tras otra.
- Durabilidad : Una vez que se realiza y se confirma una transacción, ningún factor externo como la pérdida de energía o el bloqueo deberían poder cambiarla
Lectura sugerida = >> Tutorial de transacciones MySQL
# 3) Integridad de los datos
Para cualquiera de los Operaciones CRUD , los valores / estado actualizados y más recientes de los datos compartidos deben aparecer en todos los formularios y pantallas. El valor no debe actualizarse en una pantalla y mostrar un valor anterior en otra.
Cuando la aplicación está en ejecución, el el usuario final utiliza principalmente las operaciones 'CRUD' facilitadas por la herramienta de base de datos .
C: Crear - Cuando el usuario 'Guarda' cualquier transacción nueva, se realiza la operación 'Crear'.
R: recuperar - Cuando el usuario 'Buscar' o 'Ver' cualquier transacción guardada, se realiza la operación 'Recuperar'.
U: actualización - Cuando el usuario 'Edita' o 'Modifica' un registro existente, se realiza la operación de 'Actualización' de la base de datos.
D: Eliminar - Cuando un usuario 'Elimina' cualquier registro del sistema, se realiza la operación 'Eliminar' de la base de datos.
Cualquier operación de base de datos realizada por el usuario final es siempre una de las cuatro anteriores.
Así que diseñe sus casos de prueba de base de datos de manera que incluyan la verificación de los datos en todos los lugares en los que parece para ver si son consistentemente los mismos.
# 4) Conformidad con las reglas comerciales
Una mayor complejidad en las bases de datos significa componentes más complicados como restricciones relacionales, disparadores, procedimientos almacenados, etc. Por lo tanto, los probadores tendrán que generar consultas SQL apropiadas para validar estos objetos complejos.
Qué probar (lista de verificación de prueba de la base de datos)
# 1) Transacciones
Al probar Transacciones, es importante asegurarse de que satisfagan las propiedades ACID.
Estas son las declaraciones de uso común:
- COMENZAR TRANSACCIÓN TRANSACCIÓN #
- FIN DE LA TRANSACCIÓN TRANSACCIÓN #
La declaración Rollback asegura que la base de datos permanece en un estado consistente.
- TRANSACCIÓN ROLLBACK #
Después de que se ejecuten estas declaraciones, use un Seleccionar para asegurarse de que los cambios se hayan reflejado.
- SELECCIONAR * DE TABLENAME
# 2) Esquemas de base de datos
Un esquema de base de datos no es más que una definición formal de cómo se organizarán los datos dentro de una base de datos. Para probarlo:
- Identificar los Requisitos en base a los cuales opera la Base de Datos. Requisitos de muestra:
- Las claves primarias se crearán antes de que se creen otros campos.
- Las claves externas deben estar completamente indexadas para una fácil recuperación y búsqueda.
- Nombres de campo que comienzan o terminan con ciertos caracteres.
- Campos con la restricción de que ciertos valores se pueden insertar o no.
- Utilice uno de los siguientes métodos según la relevancia:
- Consulta SQL DESC
para validar el esquema.
- Expresiones regulares para validar los nombres de los campos individuales y sus valores
- Herramientas como SchemaCrawler
# 3) Gatillos
Cuando un evento determinado tiene lugar en una mesa determinada, se puede auto-instruir un fragmento de código (un disparador) para que se ejecute.
Por ejemplo, un nuevo estudiante se unió a una escuela. El estudiante está tomando 2 clases: matemáticas y ciencias. El estudiante se agrega a la 'tabla de estudiantes'. Un activador podría agregar al estudiante a las tablas de materias correspondientes una vez que se agregue a la tabla de estudiantes.
El método común para probar es ejecutar la consulta SQL incrustada en el Trigger de forma independiente primero y registrar el resultado. Continúe con la ejecución del Trigger como un todo. Compare los resultados.
Estos se prueban en las fases de prueba de caja negra y caja blanca.
la mejor aplicación gratuita de descarga de música mp3
- Prueba de caja blanca : Los stubs y los controladores se utilizan para insertar, actualizar o eliminar datos que podrían provocar la invocación del activador. La idea básica es probar la base de datos sola incluso antes de que se realice la integración con la interfaz (UI).
- Prueba de caja negra :
a) Desde la interfaz de usuario y la base de datos, la integración ahora está disponible; podemos Insertar / Eliminar / Actualizar datos desde el front-end de manera que se invoque el Trigger. Después de eso, las sentencias Select se pueden usar para recuperar los datos de la base de datos para ver si el Trigger tuvo éxito en realizar la operación deseada.
b) La segunda forma de probar esto es cargar directamente los datos que invocarían al Trigger y ver si funciona según lo previsto.
# 4) Procedimientos almacenados
Los procedimientos almacenados son más o menos similares a las funciones definidas por el usuario. Estos pueden ser invocados por declaraciones de procedimiento de llamada / procedimiento de ejecución y la salida suele estar en forma de conjuntos de resultados.
Estos se almacenan en el RDBMS y están disponibles para aplicaciones.
Estos también se prueban durante:
- Prueba de caja blanca: Los stubs se utilizan para invocar los procedimientos almacenados y luego los resultados se validan con los valores esperados.
- Prueba de caja negra: Realice una operación desde el front-end (UI) de la aplicación y verifique la ejecución del procedimiento almacenado y sus resultados.
# 5) Restricciones de campo
El valor predeterminado, el valor único y la clave externa:
- Realizar una operación de front-end que ejercite la condición del objeto de la base de datos
- Valide los resultados con una consulta SQL.
Verificar el valor predeterminado para un determinado campo es bastante simple. Es parte de la validación de reglas comerciales. Puede hacerlo manualmente o puede utilizar herramientas como QTP. De forma manual, puede realizar una acción que agregará un valor que no sea el valor predeterminado del campo desde la interfaz y ver si da como resultado un error.
El siguiente es un ejemplo de código VBScript:
|_+_|El resultado del código anterior es Verdadero si existe el valor predeterminado o Falso si no existe.
La verificación del valor único se puede hacer exactamente de la misma manera que lo hicimos con los valores predeterminados. Intente ingresar valores de la interfaz de usuario que violarán esta regla y vea si se muestra un error.
El código de Automation VB Script puede ser:
|_+_|Para elClave externaLa validación de restricciones usa cargas de datos que ingresan directamente datos que violan la restricción y ver si la aplicación los restringe o no. Junto con la carga de datos de back-end, realice las operaciones de la interfaz de usuario de front-end también de una manera que viole las restricciones y vea si se muestra el error relevante.
Actividades de prueba de datos
El probador de bases de datos debe centrarse en las siguientes actividades de prueba:
# 1) Asegurar el mapeo de datos:
El mapeo de datos es uno de los aspectos clave de la base de datos y todos los probadores de software deben probarlo rigurosamente.
Asegúrese de que el mapeo entre las diferentes formas o pantallas de AUT y su base de datos no solo sea preciso sino también según los documentos de diseño (SRS / BRS) o el código. Básicamente, debe validar la asignación entre cada campo de front-end con su correspondiente campo de base de datos de back-end.
Para todas las operaciones CRUD, verifique que las tablas y registros respectivos se actualicen cuando el usuario haga clic en 'Guardar', 'Actualizar', 'Buscar' o 'Eliminar' de la GUI de la aplicación.
Lo que necesita verificar:
- Mapeo de tablas, mapeo de columnas y mapeo de tipos de datos.
- Asignación de datos de búsqueda.
- Se invoca la operación CRUD correcta para cada acción del usuario en la interfaz de usuario.
- La operación CRUD es exitosa.
# 2) Asegure las propiedades ACID de las transacciones:
Las propiedades ACID de las transacciones de base de datos se refieren al ' A tomicidad ',' C onsistency ',' I solation 'y' D urabilidad ». Se deben realizar pruebas adecuadas de estas cuatro propiedades durante la actividad de prueba de la base de datos. Debe verificar que cada transacción satisfaga las propiedades ACID de la base de datos.
Tomemos un ejemplo simple a través del siguiente código SQL:
|_+_|La tabla de prueba ACID tendrá dos columnas: A y B. Existe una restricción de integridad de que la suma de los valores en A y B siempre debe ser 100.
Prueba de atomicidad se asegurará de que cualquier transacción realizada en esta tabla sea toda o ninguna, es decir, no se actualicen registros si falla algún paso de la transacción.
Prueba de consistencia asegurará que siempre que se actualice el valor en la columna A o B, la suma siempre sea 100. No permitirá la inserción / eliminación / actualización en A o B si la suma total es diferente de 100.
Prueba de aislamiento se asegurará de que si dos transacciones ocurren al mismo tiempo y se intenta modificar los datos de la tabla de prueba ACID, estas tracciones se ejecutan de forma aislada.
Test de durabilidad se asegurará de que una vez que se haya comprometido una transacción sobre esta tabla, seguirá siéndolo, incluso en caso de pérdida de energía, fallas o errores.
Esta área exige pruebas más rigurosas, exhaustivas y minuciosas si su aplicación utiliza la base de datos distribuida.
# 3) Garantice la integridad de los datos
Tenga en cuenta que los diferentes módulos (es decir, pantallas o formularios) de la aplicación utilizan los mismos datos de diferentes maneras y realizan todas las operaciones CRUD en los datos.
En ese caso, asegúrese de que el último estado de los datos se refleje en todas partes. El sistema debe mostrar los valores actualizados y más recientes o el estado de dichos datos compartidos en todos los formularios y pantallas. Esto se llama Integridad de datos.
Casos de prueba para validar la integridad de los datos de la base de datos:
- Verifique si todos los disparadores están en su lugar para actualizar los registros de la tabla de referencia.
- Compruebe si existen datos incorrectos o no válidos en las columnas principales de cada tabla.
- Intente insertar datos incorrectos en las tablas y observe si ocurre alguna falla.
- Compruebe qué sucede si intenta insertar un hijo antes de insertar su padre (intente jugar con claves primarias y externas).
- Pruebe si se produce algún error si elimina un registro al que todavía se hace referencia por datos en cualquier otra tabla.
- Compruebe si los servidores y las bases de datos replicados están sincronizados.
# 4) Asegurar la exactitud de las reglas comerciales implementadas:
Hoy en día, las bases de datos no están diseñadas solo para almacenar registros. De hecho, las bases de datos se han convertido en herramientas extremadamente poderosas que brindan un amplio apoyo a los desarrolladores para implementar la lógica comercial a nivel de base de datos.
Algunos ejemplos simples de características poderosas son 'Integridad referencial', Restricciones relacionales, Disparadores y procedimientos almacenados.
Por lo tanto, utilizando estas y muchas otras características que ofrecen las bases de datos, los desarrolladores implementan la lógica empresarial a nivel de base de datos. El evaluador debe asegurarse de que la lógica empresarial implementada sea correcta y funcione con precisión.
Los puntos anteriores describen los cuatro 'Qué hacer' más importantes de probar la base de datos. Ahora, pasemos a la parte de 'Cómo'.
Cómo probar la base de datos (proceso paso a paso)
La base de datos de pruebas del proceso de prueba general no es muy diferente de cualquier otra aplicación.
Los siguientes son los pasos principales:
Paso 1) Prepara el medio ambiente
Paso 2) Ejecutar una prueba
Paso 3) Compruebe el resultado de la prueba
Paso 4) Validar según los resultados esperados
Paso # 5) Informar los hallazgos a las respectivas partes interesadas
Por lo general, se utilizan consultas SQL para desarrollar las pruebas. El comando más utilizado es 'Seleccionar'.
Seleccione * de donde
Aparte de Select, SQL tiene 3 tipos importantes de comandos:
- DDL: lenguaje de definición de datos
- DML: lenguaje de manipulación de datos
- DCL: lenguaje de control de datos
Veamos la sintaxis de las declaraciones más utilizadas.
Lenguaje de definición de datos Utiliza CREATE, ALTER, RENAME, DROP y TRUNCATE para manejar tablas (e índices).
Lenguaje de manipulación de datos Incluye declaraciones para agregar, actualizar y eliminar registros.
Lenguaje de control de datos: Se trata de dar autorización a los usuarios para la manipulación y acceso a los datos. Grant y Revoke son las dos declaraciones que se utilizan.
Grant sintaxis:
Otorgar selección / actualización
En
A ;Revocar la sintaxis:
Revocar seleccionar / actualizar
en
desde;Algunos consejos prácticos
# 1) Escriba consultas usted mismo:
Para probar la base de datos con precisión, el evaluador debe tener muy buen conocimiento de las declaraciones SQL y DML (lenguaje de manipulación de datos). El probador también debe conocer la estructura de base de datos interna de AUT.
Puede combinar la GUI y la verificación de datos en las tablas respectivas para una mejor cobertura. Si está utilizando el servidor SQL, puede utilizar SQL Query Analyzer para escribir consultas, ejecutarlas y recuperar resultados.
Esta es la mejor y más sólida forma de probar una base de datos cuando la aplicación tiene un nivel de complejidad pequeño o medio.
Si la aplicación es muy compleja, puede ser difícil o imposible para el evaluador escribir todas las consultas SQL necesarias. Para consultas complejas, necesita la ayuda del desarrollador. Siempre recomiendo este método, ya que le da confianza en las pruebas y también mejora sus habilidades de SQL.
# 2) Observe los datos en cada tabla:
Puede realizar la verificación de datos utilizando los resultados de las operaciones CRUD. Esto se puede hacer manualmente utilizando la interfaz de usuario de la aplicación cuando conozca la integración de la base de datos. Pero esto puede ser una tarea tediosa y engorrosa cuando hay una gran cantidad de datos en diferentes tablas de bases de datos.
Para la prueba manual de datos, el probador de la base de datos debe poseer un buen conocimiento de la estructura de la tabla de la base de datos.
# 3) Obtenga consultas de los desarrolladores:
Esta es la forma más sencilla de probar la base de datos. Realice cualquier operación CRUD desde GUI y verifique sus impactos ejecutando las respectivas consultas SQL obtenidas del desarrollador. No requiere un buen conocimiento de SQL ni un buen conocimiento de la estructura de la base de datos de la aplicación.
Pero este método debe usarse con precaución. ¿Qué sucede si la consulta proporcionada por el desarrollador es semánticamente incorrecta o no cumple correctamente los requisitos del usuario? El proceso simplemente fallará al validar los datos.
# 4) Utilice las herramientas de prueba de automatización de bases de datos:
Hay varias herramientas disponibles para el proceso de prueba de datos. Debe elegir la herramienta correcta según sus necesidades y aprovecharla al máximo.
=> Aquí está la lista de las MEJORES herramientas de prueba de bases de datos que debe verificar
Conclusión
Con todas estas características, factores y procesos para probar en una base de datos, existe una demanda creciente de que los probadores sean técnicamente competentes en los conceptos clave de la base de datos. A pesar de algunas de las creencias negativas de que probar una base de datos crea nuevos cuellos de botella y supone un gran gasto adicional, este es un ámbito de prueba que está atrayendo una atención y una demanda significativas.
Lectura sugerida = >> ¿Qué son las pruebas de seguridad de la base de datos?
Espero que este tutorial le haya ayudado a enfocarse en por qué es así y también le haya brindado los detalles básicos de lo que implica probar una base de datos.
Háganos saber sus comentarios y también comparta sus experiencias personales si está trabajando en pruebas de base de datos.
Lectura recomendada
- Prueba de base de datos con JMeter
- Más de 40 mejores herramientas de prueba de bases de datos: soluciones de prueba de datos populares
- Un enfoque simple para pruebas de XML para bases de datos
- Tutorial de pruebas de almacenamiento de datos de pruebas ETL (una guía completa)
- Tutorial de pruebas de migración de datos: una guía completa
- Las 10 mejores herramientas de diseño de bases de datos para crear modelos de datos complejos
- Tutorial de pruebas de almacenamiento de datos con ejemplos | Guía de prueba ETL
- Cómo probar la base de datos Oracle
^
- Consulta SQL DESC
