Prueba de base de datos - Guía rápida

La prueba de la base de datos incluye la realización de la validez de los datos, la prueba de la integridad de los datos, la verificación del rendimiento relacionado con la base de datos y la prueba de los procedimientos, desencadenantes y funciones de la base de datos.

Ejemplo

Considere una aplicación que captura los detalles de las transacciones diarias para los usuarios y almacena los detalles en la base de datos. Desde el punto de vista de las pruebas de la base de datos, se deben realizar las siguientes comprobaciones:

• La información transaccional de la aplicación debe almacenarse en la base de datos y debe proporcionar información correcta al usuario.

• La información no debe perderse cuando se carga en la base de datos.

• Solo se deben almacenar las transacciones completadas y la aplicación debe anular todas las operaciones incompletas.

• Debe mantenerse la autorización de acceso a la base de datos. No se debe proporcionar acceso no aprobado o no autorizado a la información del usuario.

¿Por qué necesita realizar pruebas de base de datos?

Hay varias razones por las que se realizan pruebas de bases de datos. Es necesario realizar una verificación de la integridad, la validación y la coherencia de los datos en la base de datos, ya que el sistema backend es responsable de almacenar los datos y se accede a él para múltiples propósitos.

A continuación se presentan algunas razones comunes para las pruebas de bases de datos:

• Para aliviar la complejidad de las llamadas al backend de la base de datos, los desarrolladores aumentan el uso de View y Stored Procedimientos.

• Estas Stored procedimientos y Viewscontienen tareas críticas como la inserción de detalles del cliente (nombre, información de contacto, etc.) y datos de ventas. Estas tareas deben probarse en varios niveles.

• Black-box testingrealizado en el front-end es importante, pero dificulta aislar el problema. Las pruebas en el sistema backend aumentan la solidez de los datos. Es por eso que las pruebas de la base de datos se realizan en el sistema back-end.

• En una base de datos, los datos provienen de múltiples aplicaciones y existe la posibilidad de que se almacenen datos dañinos o incorrectos en la base de datos. Por tanto, es necesario comprobar los componentes de la base de datos con regularidad. Además, la integridad y la coherencia de los datos deben comprobarse periódicamente.

Pruebas de base de datos frente a pruebas de front-end

Las pruebas de bases de datos son diferentes de las pruebas de interfaz de usuario de front-end. La siguiente tabla destaca las diferencias clave:

Según la función y la estructura de una base de datos, las pruebas de bases de datos se pueden clasificar en tres categorías:

• Structural Database Testing - Se ocupa de pruebas de tablas y columnas, pruebas de esquemas, pruebas de procedimientos almacenados y vistas, verificación de disparadores, etc.

• Functional Testing- Implica comprobar la funcionalidad de la base de datos desde el punto de vista del usuario. El tipo más común de pruebas funcionales son las pruebas de caja blanca y caja negra.

• Nonfunctional Testing - Implica pruebas de carga, pruebas de riesgo en la base de datos, pruebas de estrés, requisitos mínimos del sistema y se ocupa del rendimiento de la base de datos.

Pruebas de bases de datos estructurales

Las pruebas de bases de datos estructurales implican verificar aquellos componentes de la base de datos que no están expuestos a los usuarios finales. Involucra todos los componentes del repositorio, que se utilizan para almacenar los datos y no son modificados por los usuarios finales. Los administradores de bases de datos con buen dominio de los procedimientos almacenados de SQL y otros conceptos normalmente realizan estas pruebas.

Se discuten los componentes comunes probados con respecto a las pruebas estructurales:

Prueba de esquema / mapeo

Implica validar los objetos de la aplicación front-end con mapeo de objetos de base de datos.

En pruebas de esquema -

• A veces sucede que los objetos de la aplicación del usuario final no están correctamente mapeados o no son compatibles con los objetos de la base de datos. Por tanto, es necesario comprobar la validación de los distintos formatos de esquema asociados a las bases de datos.

• Se requiere encontrar los objetos no mapeados en la base de datos, como tablas, vistas, columnas, etc.

Existen varias herramientas en el mercado que se pueden utilizar para realizar el mapeo de objetos en esquemas.

Example - En Microsoft SQL Server, un evaluador puede escribir consultas simples para verificar y validar esquemas en la base de datos.

Si el evaluador desea realizar cambios en la estructura de una tabla, debe asegurarse de que todos los stored Los procedimientos que tienen esa tabla son compatibles con este cambio.

Pruebas de vistas y procedimientos almacenados

En esta prueba, un evaluador se asegura de que la ejecución manual de los procedimientos almacenados y las vistas generen el resultado requerido.

El probador asegura:

• Si permite que los disparadores necesarios se ejecuten como se esperaba.

• Si el equipo de desarrollo ha cubierto todos los bucles y condiciones pasando información a las aplicaciones en los procedimientos.

• Si hay procedimientos almacenados no utilizados en la base de datos.

• Las operaciones TRIM se aplican correctamente cuando los datos se obtienen de las tablas requeridas en la base de datos.

• Validación de la integración general de los módulos de procedimiento almacenado según los requisitos de la aplicación bajo prueba.

• Se siguen los mecanismos de manejo de excepciones y errores.

Las herramientas más comunes que se utilizan para realizar pruebas de procedimientos almacenados son LINQ, SP Test tooletc.

Prueba de activación

En las pruebas de activación, un probador debe asegurarse de lo siguiente:

• Si se siguen las convenciones de codificación durante la fase de codificación de los activadores.

• Ver que los disparadores ejecutados cumplen las condiciones requeridas.

• Si el disparador actualiza los datos correctamente, una vez que se han ejecutado.

• La validación de Actualizar / Insertar / Eliminar activa la funcionalidad de la aplicación bajo prueba.

Pruebas de tablas y columnas

Las áreas clave cubiertas en esta prueba son:

• Validando los tipos de datos en la base de datos a valores de campo en la aplicación de front-end.

• Validación de la longitud del campo de datos en la base de datos a la longitud de los tipos de datos en la aplicación.

• Comprobar si hay tablas o columnas sin asignar en la base de datos de los objetos de campo de la aplicación.

• Se verifican las convenciones de nomenclatura de las tablas y columnas de la base de datos, si cumplen o no con los requisitos comerciales.

• Validar las claves y los índices en la base de datos, es decir, las claves primarias y externas en las tablas se definen según el requisito.

• Compruebe si las claves primarias y sus claves externas correspondientes son las mismas en dos tablas.

• Compruebe que se mantienen las características únicas y NO NULAS de las claves.

• La longitud y el tipo de datos de las claves e índices se mantienen según los requisitos.

Verificación del servidor de base de datos

La verificación del servidor de base de datos implica verificar:

• Si el servidor de la base de datos puede manejar el número esperado de transacciones según los requisitos comerciales.

• Si los detalles de configuración de los servidores de bases de datos cumplen con los requisitos comerciales.

• Si la autorización del usuario se mantiene según el requisito.

Pruebas funcionales

Las pruebas funcionales se realizan teniendo en cuenta el punto de vista del usuario final; si las transacciones y operaciones requeridas ejecutadas por los usuarios finales cumplen con las especificaciones comerciales.

Prueba de caja negra

Black Box Testing implica verificar la integración de la base de datos para verificar la funcionalidad. Los casos de prueba son simples y se utilizan para verificar los datos entrantes y salientes de la función.

Para probar la funcionalidad de la base de datos se utilizan diversas técnicas, como la técnica de creación de gráficos de causa-efecto, la división de equivalencia y el análisis de valor límite.

Sus advantages son los siguientes:

• Es bastante simple y se realiza en las primeras etapas de desarrollo.
• El costo de desarrollar casos de prueba es menor en comparación con las pruebas de caja blanca.

Sus desventajas son las siguientes:

• No se pueden detectar algunos errores
• Se desconoce cuánto programa debe probarse.

Prueba de caja blanca

White Box Testing se ocupa de la estructura interna de la base de datos y los detalles de las especificaciones se ocultan a los usuarios. Implica la prueba de los disparadores de la base de datos y las vistas lógicas, que van a soportar la refactorización de la base de datos.

Realiza pruebas de módulo de funciones de base de datos, disparadores, vistas, consultas SQL, etc. Este tipo de prueba valida tablas de base de datos, modelos de datos, esquema de base de datos, etc. Verifica las reglas de integridad referencial. Selecciona los valores predeterminados de la tabla para verificar la coherencia de la base de datos.

Las técnicas más comunes que se utilizan para realizar pruebas de caja blanca son la cobertura de condiciones, la cobertura de decisiones, la cobertura de declaraciones, etc.

Los errores de codificación se pueden detectar en las pruebas de caja blanca, por lo que se pueden eliminar los 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.

Pruebas no funcionales

Las pruebas no funcionales implican realizar pruebas de carga, pruebas de estrés, verificar los requisitos mínimos del sistema para cumplir con las especificaciones comerciales, encontrar riesgos y optimizar el rendimiento de la base de datos.

Prueba de carga

El objetivo principal de las pruebas de carga es comprobar si la mayoría de las transacciones en ejecución tienen un impacto en el rendimiento de la base de datos.

En la prueba de carga, el probador verifica:

• El tiempo de respuesta para ejecutar las transacciones para múltiples usuarios remotos.
• Tiempo que tarda la base de datos en recuperar registros específicos.

Examples of load testing in different testing types -

• Ejecutar la transacción más utilizada repetidamente para ver el rendimiento del sistema de base de datos.
• Descarga de una serie de archivos grandes de Internet.
• Ejecutar múltiples aplicaciones en una computadora o servidor simultáneamente.

Pruebas de estrés

Se realizan pruebas de estrés para identificar el punto de interrupción del sistema. En esta prueba, la aplicación se carga de tal manera que el sistema falla en un punto. Este punto se llamabreakpoint del sistema de base de datos.

Determinar el estado de las transacciones de la base de datos implica un esfuerzo considerable. Se requiere una planificación adecuada para evitar problemas relacionados con el tiempo y los costos.

Las herramientas de prueba de esfuerzo más utilizadas son LoadRunner y WinRunner.

Tomemos un examplede las pruebas de estrés. Una aplicación CRM puede tener una carga máxima de usuarios de 50000 usuarios simultáneos. Suponga que aumenta la carga a 51000 y realiza algunas transacciones, como actualizar registros o agregar una entrada. Tan pronto como realice la transacción, la aplicación puede sincronizarse con el sistema de base de datos. Por lo tanto, la siguiente prueba debe realizarse con una carga de usuarios de 52000. A veces, la prueba de esfuerzo también se llamaFatigue Testing.

El proceso para realizar pruebas de bases de datos es similar a las pruebas de otras aplicaciones. Las pruebas de bases de datos se pueden describir con los procesos clave que se indican a continuación.

• Configurar el entorno
• Ejecutar una prueba
• Verifique el resultado de la prueba
• Validar según los resultados esperados
• Informar los hallazgos a las respectivas partes interesadas

Se utilizan varias sentencias SQL para desarrollar los casos de prueba. La declaración SQL más común, que se utiliza para realizar pruebas de bases de datos, es laSelectdeclaración. Aparte de esto, también se pueden utilizar varias declaraciones DDL, DML, DCL.

Example - Crear, Insertar, Seleccionar, Actualizar, etc.

Etapas de prueba de la base de datos

La prueba de base de datos no es un proceso tedioso e incluye varias etapas en el ciclo de vida de prueba de la base de datos de acuerdo con los procesos de prueba.

Las etapas clave en las pruebas de bases de datos son:

• Comprobando el estado inicial
• Prueba de funcionamiento
• Validación de resultados según el resultado esperado
• Generando los resultados

First stageen DB Testing es verificar el estado inicial de la base de datos antes de iniciar el proceso de prueba. Luego, se prueba el comportamiento de la base de datos para casos de prueba definidos. De acuerdo con los resultados obtenidos, los casos de prueba se personalizan.

Para una prueba de base de datos exitosa, el flujo de trabajo que se indica a continuación es ejecutado por cada prueba.

• Cleaning up the database - Si hay datos comprobables en la base de datos, debe vaciarse.

• Set up Fixture - Esto implica ingresar los datos en la base de datos y verificar el estado actual de la base de datos.

• Perform test, verify results and generate results- Se ejecuta la prueba y se verifica la salida. Si la salida es según los resultados esperados, el siguiente paso es generar los resultados según el requisito. De lo contrario, la prueba se repite para encontrar los errores en la base de datos.

Este capítulo explica las técnicas más comunes que se utilizan para realizar pruebas de base de datos.

Prueba de esquema de base de datos

Como se mencionó anteriormente, implica probar cada objeto en el esquema.

Verificación de bases de datos y dispositivos

• Verificando el nombre de la base de datos
• Verificación del dispositivo de datos, el dispositivo de registro y el dispositivo de volcado
• Verificar si hay suficiente espacio asignado para cada base de datos
• Verificación de la configuración de la opción de base de datos

Verificación de reglas de tablas, columnas y tipos de columnas

Verifique los elementos que se indican a continuación para averiguar las diferencias entre la configuración real y la aplicada.

• Nombre de todas las tablas en la base de datos

• Nombres de columna para cada tabla

• Tipos de columna para cada tabla

• NULL valor verificado o no

• Si un valor predeterminado está vinculado a las columnas de la tabla correcta

• Definiciones de reglas para corregir nombres de tablas y privilegios de acceso

Claves e índices

Verifique la clave y los índices en cada tabla -

• Clave principal para cada tabla

• Claves externas para cada tabla

• Tipos de datos entre una columna de clave externa y una columna en otros índices de tabla, agrupados o no agrupados, únicos o no únicos

Pruebas de procedimientos almacenados

Implica verificar si un procedimiento almacenado está definido y se comparan los resultados de salida. En una prueba de procedimiento almacenado, se comprueban los siguientes puntos:

• Nombre del procedimiento almacenado

• Nombres de parámetros, tipos de parámetros, etc.

• Output- Si la salida contiene muchos registros. Se efectúan cero filas o solo se extraen algunos registros.

• ¿Cuál es la función del procedimiento almacenado y qué se supone que no debe hacer un procedimiento almacenado?

• Pasar consultas de entrada de muestra para comprobar si un procedimiento almacenado extrae datos correctos.

• Stored Procedure Parameters- Llamar al procedimiento almacenado con datos de límite y con datos válidos. Anule cada parámetro una vez y ejecute un procedimiento.

• Return values- Compruebe los valores que devuelve el procedimiento almacenado. En caso de falla, se debe devolver un valor distinto de cero.

• Error messages check- Realice cambios de tal manera que el procedimiento almacenado falle y genere todos los mensajes de error al menos una vez. Compruebe cualquier escenario de excepción cuando no haya un mensaje de error predefinido.

Pruebas de activación

En una prueba de activación, el probador debe realizar las siguientes tareas:

• Asegúrese de que el nombre del disparador sea correcto.
• Valide el disparador si se genera para una columna de tabla específica.
• Validación de actualización del disparador.
• Actualice un registro con datos válidos.
• Actualice un registro con datos no válidos y cubra todos los errores de activación.
• Actualice un registro cuando todavía está referenciado por una fila en otra tabla.
• Asegúrese de revertir transacciones cuando ocurra una falla.
• Descubra los casos en los que se supone que un disparador no debe revertir transacciones.

Scripts de configuración del servidor

Deben realizarse dos tipos de pruebas:

• Configurar la base de datos desde cero y
• Para configurar una base de datos existente.

Pruebas de integración de SQL Server

Las pruebas de integración deben realizarse una vez que haya terminado con las pruebas de componentes.

• Los procedimientos almacenados deben llamarse intensamente para seleccionar, insertar, actualizar y eliminar registros en diferentes tablas para encontrar cualquier conflicto e incompatibilidad.

• Cualquier conflicto entre el esquema y los disparadores.

• Cualquier conflicto entre los procedimientos almacenados y el esquema.

• Cualquier conflicto entre procedimientos almacenados y desencadenadores.

Método de prueba funcional

Las pruebas funcionales se pueden realizar dividiendo la base de datos en módulos según la funcionalidad. Las funcionalidades son de los dos tipos siguientes:

• Type 1- En las pruebas de Tipo 1, averigüe las características del proyecto. Para cada característica principal, averigüe el esquema, los desencadenadores y los procedimientos almacenados responsables de implementar esa función y colóquelos en un grupo funcional. Luego pruebe a cada grupo juntos.

• Type 2- En las pruebas de Tipo 2, el límite de los grupos funcionales en un back-end no es obvio. Puede verificar el flujo de datos y ver dónde puede verificar los datos. Empiece desde el front-end.

Se lleva a cabo el siguiente proceso:

• Cuando un servicio tiene una solicitud o guarda datos, se llamarán algunos procedimientos almacenados.

• Los procedimientos actualizarán algunas tablas.

• Esos procedimientos almacenados serán el lugar para comenzar a probar y esas tablas serán el lugar para verificar los resultados de la prueba.

Pruebas de estrés

Stress Testing implica obtener una lista de las principales funciones de la base de datos y los correspondientes procedimientos almacenados. Siga los pasos que se indican a continuación para las pruebas de esfuerzo:

• Escriba scripts de prueba para probar esas funciones y cada función debe verificarse al menos una vez en un ciclo completo.

• Realice los scripts de prueba una y otra vez durante un período de tiempo específico.

• Verificación de los archivos de registro para comprobar cualquier punto muerto, falta de memoria, corrupción de datos, etc.

Pruebas comparativas

Si su base de datos no tiene problemas de datos o errores, se puede verificar el rendimiento del sistema. Se puede encontrar un rendimiento deficiente del sistema en las pruebas comparativas al verificar los parámetros que se indican a continuación:

• Rendimiento a nivel del sistema
• Identificar las funciones / características más utilizadas
• Sincronización: tiempo máximo, tiempo mínimo y tiempo medio para realizar funciones
• Volumen de acceso

Prueba de una base de datos a través de front-end

Los errores de back-end también se pueden encontrar a veces haciendo pruebas de front-end. Puede seguir los sencillos pasos que se indican a continuación para detectar errores mediante pruebas de front-end.

• Escriba consultas desde el front-end y emita las búsquedas.

• Elija un registro existente, cambie los valores en algunos campos y guarde el registro. (Implica la instrucción UPDATE o actualizar los procedimientos almacenados y los activadores de actualización).

• Inserte un nuevo elemento de menú en la ventana del front-end. Complete la información y guarde el registro. (Implica las instrucciones INSERT o los procedimientos almacenados de inserción y los desencadenadores de eliminación).

• Elija un registro existente, haga clic en el botón ELIMINAR o ELIMINAR y confirme la eliminación. (Implica la instrucción DELETE o los procedimientos almacenados de eliminación y los activadores de eliminación).

• Repita estos casos de prueba con datos no válidos y vea cómo responde la base de datos.

En este capítulo, veremos algunos escenarios de prueba de bases de datos comunes con respecto a varios métodos de prueba.

Prueba de base de datos estructurada

Los escenarios de bases de datos comunes con respecto a las pruebas de bases de datos estructuradas se dan a continuación:

• Verificar el nombre de la base de datos, verificar el dispositivo de datos, el dispositivo de registro y el dispositivo de volcado, verificar si hay suficiente espacio asignado para cada base de datos y verificar la configuración de la opción de la base de datos.

• Nombres de todas las tablas en la base de datos, nombres de columna para cada tabla, tipos de columna para cada tabla, verificación de valor nulo o no. Verifique la clave y los índices en cada tabla: clave principal para cada tabla, claves externas para cada tabla.

• Tipos de datos entre una columna de clave externa y una columna en otros índices de tabla, agrupados o no agrupados, únicos o no únicos.

Prueba de base de datos funcional

Escenarios comunes de prueba de bases de datos con respecto a Functional Database Testing son -

• Descubrir el esquema, los disparadores y los procedimientos almacenados responsables de implementar esa función y convertirlos en un grupo funcional y luego cada grupo se puede probar juntos.

• Verifique el flujo de datos y vea dónde puede verificar los datos. Empiece desde el front-end.

Prueba de base de datos no funcional

Escenarios comunes de prueba de bases de datos con respecto a Non-Functional Database Testing son -

• Escriba scripts de prueba para probar las funciones principales y cada función debe verificarse al menos una vez en un ciclo completo.

• Realice los scripts de prueba una y otra vez durante un período de tiempo específico.

• Verificación de los archivos de registro para comprobar cualquier punto muerto, falta de memoria, corrupción de datos, etc.

• Escriba consultas desde una interfaz y emita las búsquedas. Elija un registro existente, cambie los valores en algunos campos y guarde el registro. (Implica la instrucción UPDATE o actualizar los procedimientos almacenados, actualizar los activadores).

• Inserte un nuevo elemento de menú en una ventana de front-end. Complete la información y guarde el registro. (Implica instrucciones INSERT o procedimientos almacenados de inserción, desencadenadores de eliminación).

• Elija un registro existente, haga clic en el botón ELIMINAR o ELIMINAR y confirme la eliminación. (Implica la instrucción DELETE o procedimientos almacenados de eliminación, desencadenadores de eliminación).

• Repita estos casos de prueba con datos no válidos y vea cómo responde la base de datos.

Schemas, tables, stored proceduresy Triggersson objetos clave de una base de datos. Ya hemos compartido los tipos de prueba de base de datos y los escenarios de prueba para estos objetos de base de datos.

Esquemas

Un esquema de base de datos define la estructura de un sistema de base de datos en un formato compatible con el sistema de gestión de base de datos. Un esquema se refiere a cómo está estructurada una base de datos (compuesta de tablas de base de datos en el caso de las bases de datos relacionales).

El esquema de la base de datos es un conjunto de fórmulas llamadas restricciones de integridad impuestas a una base de datos. Estas restricciones de integridad aseguran la compatibilidad entre partes del esquema.

En una base de datos relacional, el esquema consta de tablas, campos, vistas, índices, paquetes, procedimientos, funciones, disparadores, tipos, vistas materializadas, sinónimos, enlaces de bases de datos y otros elementos.

Los esquemas generalmente se almacenan en un diccionario de datos. Aunque un esquema se define en el lenguaje de la base de datos de texto, el término se usa a menudo para referirse a una descripción gráfica de la estructura de la base de datos. En otras palabras, el esquema es la estructura de la base de datos que define los objetos en la base de datos.

Los tipos comunes de esquemas utilizados en un almacén de datos son:

• Esquema de estrella
• Esquema de los copos de nieve
• Esquema de galaxia

Tablas en la base de datos

En una base de datos relacional, se utiliza una tabla para organizar la información en filas y columnas.

Example - Una tabla de clientes contiene información como identificación de cliente, direcciones, números de teléfono, etc., como una serie de columnas.

Cada dato es un campo en la tabla. Una columna consta de todas las entradas en un solo campo, como los números de teléfono de todos los clientes. Los campos se organizan como registros, que son conjuntos completos de información (como el conjunto de información sobre un cliente en particular), cada uno de los cuales comprende una fila.

Procedimientos almacenados

Un procedimiento almacenado es una serie de sentencias SQL almacenadas en la base de datos en una forma compilada y múltiples programas pueden compartirla. El uso de procedimientos almacenados puede ser útil para mantener la integridad de los datos, controlar el acceso a los datos y mejorar la productividad.

Disparadores

Un activador de base de datos es un código que se ejecuta en respuesta a ciertos eventos en una tabla o vista en particular en una base de datos. El disparador se usa principalmente para mantener la integridad de la información en la base de datos.

La integridad de los datos es importante en una base de datos. Incluye validación de datos antes de la inserción, actualización y eliminación. Deben existir activadores para validar los registros de la tabla de referencia.

Para verificar la integridad de los datos, debe realizar las siguientes operaciones:

• Debe verificar las columnas principales en cada tabla y verificar si existe algún dato incorrecto. (Caracteres en el campo de nombre, porcentaje negativo, etc.)

• Descubra datos inconsistentes e insértelos en tablas relevantes y vea si ocurre alguna falla.

• Inserte los datos de un hijo antes de insertar los datos de su padre. Intente eliminar un registro al que todavía hacen referencia los datos de otra tabla.

• Si se actualiza un dato de una tabla, compruebe si también se actualizan los demás datos relevantes. Debe asegurarse de que los servidores o bases de datos replicados estén sincronizados y contengan información coherente.

El mapeo de datos en una base de datos es uno de los conceptos clave que debe ser validado por cada evaluador. Por lo general, los probadores tienen que verificar el mapeo del campo del front-end de la interfaz de usuario con el campo correspondiente de la base de datos del back-end.

Esta información se proporciona en la especificación de requisitos de software o en el documento SRS / BRS de especificación de requisitos comerciales. Si no se proporciona el mapeo, debe verificar la parte de codificación.

Cuando realiza cualquier acción en la aplicación frontal, se invoca una acción CRUD correspondiente, y el evaluador debe verificar que cada acción invocada sea exitosa o no.

Aspectos clave del mapeo de datos

A continuación se presentan los aspectos clave del mapeo de datos:

• Para verificar los campos en los formularios de interfaz de usuario / front-end y mapeados de manera consistente con la tabla de base de datos correspondiente. Esta información cartográfica se define en los documentos de requisitos mencionados anteriormente.

• Para cualquier acción realizada en el front-end de una aplicación, se inicia una acción CRUD correspondiente 'Crear, recuperar, actualizar y eliminar' en el back-end.

• Un evaluador deberá verificar si se invoca la acción correcta y si la acción invocada en sí misma es exitosa o no.

Pasos en las pruebas de asignación de datos

A continuación se muestran los pasos seguidos para las pruebas de asignación de datos:

• Step 1 - Primero verifique si hay errores de sintaxis en cada script.

• Step 2 - Lo siguiente es verificar el mapeo de tablas, el mapeo de columnas y el mapeo de tipos de datos.

• Step 3 - Verificar el mapeo de datos de búsqueda.

• Step 4 - Ejecute cada script cuando no existan registros en las tablas de destino.

• Step 5 - Ejecute cada script cuando los registros ya existan en las tablas de destino.

Una aplicación con más tiempo de respuesta y un rendimiento deficiente puede generar grandes problemas. La prueba de carga de la base de datos se utiliza para encontrar problemas de rendimiento antes de implementar sus aplicaciones de base de datos para los usuarios finales.

La prueba de carga de la base de datos le ayuda a diseñar la aplicación de la base de datos para el rendimiento, la confiabilidad y la escalabilidad. La prueba de carga de aplicaciones de base de datos implica probar el rendimiento y la escalabilidad de su aplicación de base de datos con una carga de usuarios variable.

Las pruebas de carga de la base de datos implican la simulación de la carga del usuario real para la aplicación de la base de datos de destino. Le ayuda a determinar cómo se comporta su aplicación de base de datos cuando varios usuarios la acceden simultáneamente.

Prueba de carga

El objetivo principal de las pruebas de carga es verificar si la mayoría de las transacciones en ejecución tienen un impacto en el rendimiento de la base de datos. En las pruebas de carga, debe verificar los siguientes aspectos:

• Se debe verificar el tiempo de respuesta para ejecutar las transacciones para múltiples usuarios remotos.

• Con transacciones normales, debe incluir una transacción editable para verificar el rendimiento de la base de datos para este tipo de transacciones pf.

• Con transacciones normales, debe incluir una transacción que no sea de edición para verificar el rendimiento de la base de datos para este tipo de transacciones.

• Debe comprobarse el tiempo que tarda la base de datos en recuperar registros específicos.

Pruebas de estrés

Se realizan pruebas de estrés para identificar el sistema. breakpoint. Aquí la aplicación se carga de tal manera que el sistema falla en un punto. Este punto se denomina punto de interrupción del sistema de base de datos. Las pruebas de estrés también se conocen comoFatigue Testing.

Determinar el estado de las transacciones de la base de datos implica un esfuerzo considerable. Se requiere una planificación adecuada para evitar problemas relacionados con el tiempo y los costos.

Las herramientas de prueba de esfuerzo más comunes son LoadRunner y WinRunner.

Hay varias herramientas proporcionadas por los proveedores que se pueden utilizar para generar datos de prueba, administrar datos de prueba y realizar pruebas de base de datos como pruebas de carga y pruebas de regresión.

A continuación se proporcionan algunas herramientas comunes que se utilizan.

La parte más importante del crecimiento organizacional son sus datos. En caso de falla del sistema, es necesario restaurar los datos. La copia de seguridad es una copia exacta de la base de datos, que le ayuda a restaurar sus datos en caso de pérdida de datos.

Considere una compañía financiera que tiene datos relacionados con sus clientes, como número de A / C, nombres de clientes, crédito y débito, duración, etc. ¿Cómo lidiaría una organización con la presión de perder información tan importante en caso de una falla en los datos?

Esta es la razón por la que hace una copia de seguridad de los datos para que, en caso de falla de un disco, controlador de disco, etc., pueda confiar en la copia de seguridad para restaurarla en la base de datos.

Tipos de copias de seguridad de datos

Hay dos tipos de copias de seguridad que se pueden utilizar:

• Physical Backups - La copia de seguridad física incluye la realización de copias de seguridad mediante herramientas de copia de seguridad de terceros como Veritas Net Back, IBM Tivoli Manager o copias de seguridad del administrador de usuarios mediante utilidades del sistema operativo.

• Logical Backups - La copia de seguridad lógica de la base de datos incluye la realización de copias de seguridad de objetos lógicos como tablas, índices, procedimientos, etc.

Example - Una de las herramientas comunes para realizar copias de seguridad de datos es Oracle Recovery Manager (RMAN) que es una utilidad de Oracle para realizar copias de seguridad de la base de datos.

RMAN consta de dos componentes:

• Target database para lo cual se requiere una copia de seguridad.

• RMAN El cliente se utiliza para ejecutar comandos para realizar copias de seguridad de datos.

BACKUP VALIDATEse utiliza para probar si puede realizar una copia de seguridad válida de los archivos de la base de datos. Asegura -

• Si existe una copia de seguridad para los objetos físicos o lógicos de la base de datos.
• Si se configuran copias de seguridad periódicas para datos invaluables.
• Si la herramienta de respaldo cumple con los requisitos de respaldo de una organización.

Database recovery testingse utiliza para garantizar la recuperación de la base de datos. Las pruebas de recuperación le permiten averiguar si la aplicación se está ejecutando correctamente y verificar la recuperación de datos invaluables que se habrían perdido si su método de recuperación no está configurado correctamente.

También verifica si varios procesos críticos se están ejecutando sin problemas para garantizar que la recuperación de datos pase sin problemas por la fase de prueba.

Puede realizar las siguientes comprobaciones para la recuperación de la base de datos:

• Cualquier error o error en el software de respaldo y debe resolver estos problemas en una etapa anterior.

• Debe realizar las pruebas de recuperación para saber qué hacer en caso de una situación de emergencia.

• Debe verificar las necesidades de las pruebas de recuperación para poder planificar una estrategia de recuperación eficaz.

• También debe saber cómo recuperar los documentos.

Debe ejecutar las pruebas de recuperación en la fase inicial del proyecto. Esto le permite eliminar y eliminar todo tipo de errores del sistema. Aquí hay una lista de algunos puntos importantes, que deben considerarse en el momento de la prueba:

• Periodo de tiempo en el que ocurren cambios o modificaciones en el sistema de la base de datos.

• El período durante el cual desea que se lleve a cabo su plan de recuperación.

• La sensibilidad de los datos en el sistema de base de datos. Cuanto más críticos sean los datos, más regularmente necesitará probar el software.

Pasos habituales en las pruebas de recuperación y copia de seguridad de la base de datos

En las pruebas de recuperación de la base de datos, debe ejecutar la prueba en el entorno real para comprobar si el sistema o los datos se pueden recuperar en caso de desastres y cualquier otro evento imprevisto en el entorno empresarial.

A continuación se muestran las acciones comunes que se realizan en las pruebas de recuperación de bases de datos:

• Prueba del sistema de base de datos
• Prueba de los archivos SQL
• Prueba de archivos parciales
• Prueba de respaldo de datos
• Prueba de la herramienta de respaldo
• Prueba de copias de seguridad de registros

Las pruebas de seguridad de la base de datos se realizan para encontrar las lagunas en los mecanismos de seguridad y también para encontrar las vulnerabilidades o debilidades del sistema de la base de datos.

El objetivo principal de las pruebas de seguridad de las bases de datos es descubrir las vulnerabilidades de un sistema y determinar si sus datos y recursos están protegidos de posibles intrusos. Las pruebas de seguridad definen una forma de identificar las vulnerabilidades potenciales de manera efectiva, cuando se realizan con regularidad.

A continuación se presentan los objetivos principales de realizar pruebas de seguridad de bases de datos:

• Authentication
• Authorization
• Confidentiality
• Availability
• Integrity
• Resilience

Tipos de amenazas en un sistema de base de datos

Inyección SQL

Este es el tipo de ataque más común en un sistema de base de datos donde se insertan sentencias SQL maliciosas en el sistema de base de datos y se ejecutan para obtener información crítica del sistema de base de datos. Este ataque aprovecha las lagunas en la implementación de aplicaciones de usuario. Para evitar esto, los campos de entrada del usuario deben manejarse con cuidado.

Elevación de privilegios en la base de datos

En este ataque, un usuario ya tiene algún acceso en el sistema de la base de datos y solo intenta elevar este acceso a un nivel superior para que pueda realizar algunas actividades no autorizadas en el sistema de la base de datos.

Negación de servicio

En este tipo de ataque, un atacante hace que un sistema de base de datos o un recurso de aplicación no esté disponible para sus usuarios legítimos. Las aplicaciones también pueden ser atacadas de manera que la aplicación y, a veces, toda la máquina, quede inutilizable.

Acceso no autorizado a los datos

Otro tipo de ataque es obtener acceso no autorizado a datos dentro de una aplicación o sistema de base de datos. El acceso no autorizado incluye:

• Acceso no autorizado a los datos a través de aplicaciones basadas en el usuario
• Acceso no autorizado a monitoreando el acceso de otros
• Acceso no autorizado a información de autenticación de cliente reutilizable

Suplantación de identidad

En Identity Spoofing, un pirata informático utiliza las credenciales de un usuario o dispositivo para lanzar ataques contra hosts de red, robar datos o eludir los controles de acceso al sistema de base de datos. La prevención de este ataque requiere mitigaciones a nivel de red y de infraestructura de TI.

Manipulación de datos

En un ataque de manipulación de datos, un pirata informático cambia los datos para obtener alguna ventaja o dañar la imagen de los propietarios de la base de datos.

Técnicas de prueba de seguridad de bases de datos

Pruebas de penetración

Una prueba de penetración es un ataque a un sistema informático con la intención de encontrar lagunas de seguridad y, potencialmente, acceder a él, su funcionalidad y sus datos.

Hallazgo de riesgo

La búsqueda de riesgos es un proceso de evaluación y decisión sobre el riesgo involucrado con el tipo de pérdida y la posibilidad de que ocurra una vulnerabilidad. Esto se determina dentro de la organización mediante diversas entrevistas, discusiones y análisis.

Prueba de inyección SQL

Implica verificar las entradas del usuario en los campos de la aplicación. Por ejemplo, ingresando un carácter especial como ',' o ';' en cualquier cuadro de texto en una aplicación de usuario no debe permitirse. Cuando ocurre un error en la base de datos, significa que la entrada del usuario se inserta en alguna consulta, que luego es ejecutada por la aplicación. En tal caso, la aplicación es vulnerable a la inyección de SQL.

Estos ataques son una gran amenaza para los datos, ya que los atacantes pueden acceder a información importante de la base de datos del servidor. Para verificar los puntos de entrada de inyección de SQL en su aplicación web, busque el código de su base de código donde se ejecutan las consultas directas de MySQL en la base de datos al aceptar algunas entradas de usuario.

Las pruebas de inyección SQL se pueden realizar para corchetes, comas y comillas.

Craqueo de contraseña

Esta es la verificación más importante al realizar las pruebas del sistema de base de datos. Para acceder a información crítica, los piratas informáticos pueden usar una herramienta para descifrar contraseñas o pueden adivinar un nombre de usuario / contraseña común. Estas contraseñas comunes están fácilmente disponibles en Internet y también existen herramientas para descifrar contraseñas libremente.

Por lo tanto, es necesario verificar en el momento de la prueba si la política de contraseñas se mantiene en el sistema. En el caso de aplicaciones bancarias y financieras, es necesario establecer una política estricta de contraseñas en todos los sistemas de bases de datos de información crítica.

Auditoría de seguridad del sistema de base de datos

Una auditoría de seguridad es un proceso de evaluación de las políticas de seguridad de la empresa en un intervalo de tiempo regular para determinar si se siguen o no los estándares necesarios. Se pueden seguir varios estándares de seguridad según los requisitos comerciales para definir la política de seguridad y luego se puede realizar la evaluación de las políticas establecidas en relación con esos estándares.

Ejemplos de los estándares de seguridad más comunes son ISO 27001, BS15999, etc.

Herramientas de prueba de seguridad de bases de datos

Hay varias herramientas de prueba del sistema disponibles en el mercado, que se pueden usar para probar el sistema operativo y la verificación de aplicaciones. Algunas de las herramientas más comunes se describen a continuación.

Proxy de ataque Zed

Es una herramienta de prueba de penetración para encontrar vulnerabilidades en aplicaciones web. Está diseñado para ser utilizado por personas con una amplia gama de experiencia en seguridad y, como tal, es ideal para desarrolladores y probadores funcionales que son nuevos en las pruebas de penetración. Se usa comúnmente para Windows, Linux, Mac OS.

Paros

Todos los datos HTTP y HTTPS entre el servidor y el cliente, incluidas las cookies y los campos de formulario, se pueden interceptar y modificar utilizando estos escáneres. Se utiliza para multiplataforma, Java JRE / JDK 1.4.2 o superior.

Kit de herramientas para ingenieros sociales

Es una herramienta de código abierto y los elementos humanos son atacados en lugar del elemento del sistema. Le permite enviar correos electrónicos, applets de Java, etc. que contienen el código de ataque. Se prefiere para Linux, Apple Mac OS X y Microsoft Windows.

Skipfish

Esta herramienta se utiliza para escanear sus sitios en busca de vulnerabilidades. Los informes generados por la herramienta están destinados a servir como base para evaluaciones profesionales de seguridad de aplicaciones web. Se prefiere para Linux, FreeBSD, MacOS X y Windows.

Vega

Es una herramienta de seguridad web multiplataforma de código abierto que se utiliza para encontrar instancias de inyección SQL, secuencias de comandos entre sitios (XSS) y otras vulnerabilidades en aplicaciones web. Se prefiere para Java, Linux y Windows.

Wapiti

Wapiti es una herramienta de código abierto y basada en la web que escanea las páginas web de la aplicación web y busca scripts y formularios donde pueda inyectar datos. Está construido con Python y puede detectar errores de manejo de archivos, bases de datos, XSS, inyecciones LDAP y CRLF, detección de ejecución de comandos.

Escarabajo Web

Está escrito en Java y se utiliza para analizar las aplicaciones que se comunican a través de los protocolos HTTP / HTTPS. Esta herramienta está diseñada principalmente para desarrolladores que pueden escribir código por sí mismos. Esta herramienta no depende del sistema operativo.

Para realizar las pruebas de la base de datos con éxito, un evaluador debe recopilar los requisitos de todas las fuentes, como los requisitos técnicos y funcionales. Existe la posibilidad de que algunos requisitos sean de alto nivel, por lo que es necesario desglosar esos requisitos en partes pequeñas. Probar la base de datos es una tarea compleja y los probadores enfrentan muchos desafíos al realizar esta prueba. Los desafíos más comunes de las pruebas de bases de datos son:

El alcance de la prueba es demasiado grande

Un evaluador necesita identificar los elementos de prueba en las pruebas de la base de datos, de lo contrario, es posible que no tenga una comprensión clara de lo que probaría y lo que no probaría. Por lo tanto, si tiene claro el requisito, puede perder mucho tiempo probando objetos no críticos en la base de datos.

Cuando tenga una lista de objetos para probar, lo siguiente es estimar el esfuerzo requerido para diseñar las pruebas y ejecutar las pruebas para cada elemento de prueba. Dependiendo de su diseño y tamaño de los datos, algunas pruebas de bases de datos pueden tardar mucho en ejecutarse.

Como el tamaño de la base de datos es demasiado grande, se convierte en un gran desafío encontrar los objetos que deben probarse y los que deben omitirse.

Base de datos de prueba reducida

Normalmente, los probadores reciben una copia de la base de datos de desarrollo para probar. Esa base de datos solo tiene pocos datos, que son suficientes para ejecutar la aplicación. Por lo tanto, es necesario probar el desarrollo, la puesta en escena y el sistema de base de datos de producción.

Cambios en la estructura de la base de datos

Este es uno de los desafíos comunes en las pruebas de bases de datos. A veces, sucede que diseña o ejecuta una prueba y la estructura de la base de datos se ha cambiado en ese momento. Es necesario que tenga en cuenta los cambios realizados en la base de datos durante la prueba.

Una vez que cambia la estructura de la base de datos, debe analizar el impacto de los cambios y modificar las pruebas. Además, si varios usuarios utilizan la base de datos de prueba, no estará seguro de los resultados de la prueba, por lo que debe asegurarse de que la base de datos de prueba se utilice únicamente con fines de prueba.

Otro desafío en las pruebas de bases de datos es que ejecuta varias pruebas al mismo tiempo. Debe ejecutar una prueba a la vez al menos para las pruebas de rendimiento. No desea que su base de datos realice varias tareas y no informe sobre el rendimiento.

Planes de prueba complejos

La estructura de la base de datos es normalmente compleja y tiene una gran cantidad de datos, por lo que existe la posibilidad de que esté ejecutando pruebas incompletas o las mismas repetidamente. Por lo tanto, es necesario crear un plan de prueba y proceder en consecuencia y verificar el progreso con regularidad.

Buen conocimiento de SQL

Para probar una base de datos, debe tener un buen conocimiento de las consultas SQL y las herramientas de administración de bases de datos necesarias.

db_connect(query1 DRIVER {drivername};SERVER server_name;UID uidname;
   PWD password;DBQ database_name );

db_excecute_query (write the required query that is to execute); Specify the appropriate condition

db_disconnect(query);