Cómo realizar pruebas de software en vistas en la base de datos
Desde la perspectiva del proceso de prueba, también podemos dividir las pruebas de bases de datos en:
Pruebas del sistema
El enfoque de las pruebas de sistemas de software tradicionales es la cobertura de requisitos. Para las pruebas de nuestra base de datos, también debemos garantizar la cobertura de requisitos. Luego, la base de datos también necesita analizar y probar esto en el diseño inicial. Por ejemplo, procedimientos almacenados, vistas, activadores, restricciones, reglas, etc., todos debemos verificar los requisitos para garantizar que estos diseños funcionales cumplan con los requisitos. Por otro lado, debemos confirmar que el documento de diseño de la base de datos es el. Igual que la base de datos final. Cuando el documento de diseño cambia, también es necesario verificar si los cambios se implementan en la base de datos.
Nuestras pruebas en esta etapa se implementan principalmente a través de la revisión del diseño de la base de datos.
Pruebas de integración
Las pruebas de integración son pruebas principalmente para interfaces. Desde la perspectiva de la base de datos, son ligeramente diferentes de las pruebas ordinarias, lo que se debe considerar son los datos. Operaciones de modificación de elementos, operaciones de adición de elementos de datos, operaciones de eliminación de elementos de datos, agregar tablas de datos completas, eliminar tablas de datos vacías, eliminar registros en tablas vacías, operaciones concurrentes en tablas de datos, pruebas de interfaz para procedimientos almacenados y combinación de lógica empresarial. Realice pruebas de interfaz. de tablas de asociación.
De manera similar, debemos considerar probar estas interfaces utilizando métodos como clases de equivalencia, valores límite y adivinación de errores.
Pruebas unitarias
Las pruebas unitarias se centran en la cobertura lógica. En comparación con los códigos complejos, las pruebas unitarias para el desarrollo de bases de datos son relativamente simples y se pueden completar mediante la cobertura de declaraciones y el recorrido.
Las pruebas del sistema son relativamente difíciles y requieren altas capacidades de diseño de bases de datos y una rica experiencia en pruebas de bases de datos. Las pruebas de integración y las pruebas unitarias son relativamente simples.
Y también podemos clasificar las bases de datos desde la perspectiva de las pruebas:
Pruebas funcionales
Podemos confiar en herramientas para probar las funciones de las bases de datos:
DBunit: un marco de prueba funcional de base de datos de código abierto, que puede utilizar un método similar a Junit para realizar pruebas unitarias de caja blanca en las operaciones básicas de la base de datos y verificar la entrada y salida.
QTP: la famosa herramienta de prueba automática Al capturar e identificar objetos, podemos usar QTP para simular el proceso de operación del usuario y usar el método de verificación o combinarlo con el monitoreo del fondo de la base de datos para monitorear todo. datos de la base de datos para realizar pruebas. Personalmente prefiero el cuadro gris.
DataFactory: Una excelente herramienta automática de generación de datos de bases de datos, a través de la cual puedes generar fácilmente cualquier base de datos estructurada, llenar la base de datos y ayudarte a generar la gran cantidad de datos que necesitas para verificar las funciones de nuestra base de datos. ¿Es correcto? Esta es una prueba de caja negra.
Rendimiento de la base de datos Aunque nuestro hardware ha mejorado rápidamente en los últimos años, los datos que necesitamos procesar aumentan a un ritmo más rápido. Las tablas con cientos de millones de registros son comunes hoy en día, con una cantidad tan grande de datos, cuando se realizan una gran cantidad de operaciones de conexión simultáneas, no podemos usar consultas, consultas de conexión, consultas anidadas y vistas tan casualmente como antes. Las operaciones no se realizan correctamente, causarán daños al sistema, lo que genera una presión enorme y afecta gravemente el rendimiento del sistema.
La optimización del rendimiento se divide en 4 partes:
1. Almacenamiento físico
2. Diseño lógico
3. Ajuste de parámetros de la base de datos
4. Optimización de declaraciones SQL
Pruebas de rendimiento:
¿Cómo probamos el rendimiento? La industria también proporciona muchas herramientas para pasar declaraciones SQL en el sistema de base de datos. Con herramientas de análisis, podemos analizar y obtener los cuellos de botella en la ejecución de declaraciones de la base de datos, optimizando así las declaraciones SQL.
Loadrunner: No hace falta decir que podemos realizar pruebas de estrés de la base de datos programando el protocolo.
Swingbench: (Esta es una característica pesada, similar a LR y muy poderosa, pero específicamente para Oracle). Los fabricantes de bases de datos también lo saben. Por ejemplo, Oracle11g ha proporcionado pruebas de aplicaciones reales, que proporcionan rendimiento de la base de datos. Pruebas y análisis de cuellos de botella en las aplicaciones del sistema.
También hay muchas empresas de terceros que han desarrollado herramientas de optimización de declaraciones SQL para ayudarlo a optimizar automáticamente las declaraciones para mejorar la eficiencia de la ejecución.
Pruebas de seguridad:
El software es cada vez más complejo y los datos se han convertido en el núcleo del sistema. En el pasado, la destrucción del sistema ahora está más inclinada a la adquisición y. control de datos destruir. La seguridad de la base de datos ha pasado a primer plano desde que se descubrió el ataque de inyección SQL, la base de datos infalible cambió repentinamente del backend al frontend. Una vez que se viola la base de datos, todo el sistema quedará expuesto a los piratas informáticos. procedimientos almacenados de la base de datos, los piratas informáticos pueden obtener acceso fácilmente a todo el sistema. La inyección de SQL parece simple pero difícil de prevenir. Para las pruebas de seguridad, la forma de evitar la inyección en el sistema es la dificultad de la prueba.
La industria también cuenta con herramientas de detección de inyección de bases de datos relacionadas para ayudar a los usuarios a realizar pruebas de seguridad en sus propios sistemas.
La industria también cuenta con estándares para esto, como la ISO IEC 21827, también llamada SSE CMM 3.0, que es producto de la integración de CMM e ISO, apuntando específicamente a otro aspecto de la seguridad del sistema, la robustez de la base de datos, la tolerancia a fallos y las capacidades de recuperación también son los puntos clave de nuestras pruebas.
También podemos encontrar que las pruebas funcionales, las pruebas de rendimiento y las pruebas de seguridad son procesos que van desde simples hasta complejos, y también lo son. Habilidades que los probadores de bases de datos deben dominar gradualmente. Este es también el requisito de la empresa para los probadores de bases de datos en el futuro.