¿Qué son las pruebas dinámicas? Tipos, técnicas y ejemplos

⚡ Resumen inteligente

Las pruebas dinámicas ejecutan la aplicación y observan cómo se comporta el código en ejecución con entradas reales, de modo que los evaluadores pueden validar la funcionalidad, el rendimiento y la estabilidad que ninguna revisión de la documentación puede revelar.

  • 🎯 Propósito: Valide el comportamiento real en tiempo de ejecución, no los documentos que lo describen.
  • 🔀 Dos ramas: La caja blanca examina el código, la caja negra examina el comportamiento.
  • 🧱 Cuatro niveles: Las pruebas unitarias, de integración, de sistema y de aceptación ejecutan código.
  • ⚙️ No funcional: Aquí se realizan comprobaciones de rendimiento, recuperación, compatibilidad, seguridad y usabilidad.
  • 🔄 Proceso: Estrategia, diseño de pruebas, configuración del entorno, ejecución e informe de defectos.
  • 💰 Compensación: Detección de defectos más exhaustiva a cambio de tiempo, entornos y costes.

Tipos, técnicas y ejemplos de pruebas dinámicas

¿Qué son las pruebas dinámicas?

Prueba dinámica Es un método de prueba de software que se utiliza para evaluar el comportamiento dinámico del código. El objetivo principal de las pruebas dinámicas es examinar el comportamiento del software con variables dinámicas (variables que no son constantes) y detectar puntos débiles en el entorno de ejecución. Para probar el comportamiento dinámico, es necesario ejecutar el código.

La prueba es verificación y validaciónSe necesitan ambas V para que las pruebas sean completas. La verificación se lleva a cabo mediante pruebas estáticas, que revisan los requisitos, los documentos de diseño y el código sin ejecutarlos. La validación se lleva a cabo mediante pruebas dinámicas, que ejecutan la compilación y comparan lo que la aplicación hace realmente con lo que se supone que debe hacer.

La tabla que aparece a continuación permite diferenciar ambos productos a simple vista.

Aspecto Pruebas estáticas (verificación) Pruebas dinámicas (validación)
Code ejecutado No Sí:
Actividades típicas Revvistas, recorridos, inspecciones, análisis estático Ejecución de casos de prueba en todos los niveles de prueba.
Pregunta respondida ¿Estamos construyendo el producto correctamente? ¿Estamos construyendo el producto correcto?
Defectos encontrados Requisitos ambiguos, violaciones de estándares de codificación, código muerto Salida errónea, fugas de memoria, fallos de sincronización, fallos de integración.
Empieza Tan pronto como exista un artefacto Una vez que exista una compilación ejecutable
Costo relativo de una solución Menor, porque los defectos se detectan antes. Más alto, porque los defectos aparecen más tarde.

Ejemplo de prueba dinámica

Un breve ejemplo práctico muestra cómo se comporta la prueba dinámica en la práctica.

Supongamos que se está probando una página de inicio de sesión. Tiene dos campos, Nombre de usuario y Contraseña, y el Nombre de usuario está restringido a caracteres alfanuméricos.

Cuando el usuario introduce el nombre de usuario como “Guru99”, el sistema lo acepta. Cuando el usuario ingresa “GuruAl introducir 99@123, la aplicación muestra un mensaje de error. Este resultado demuestra que el código actúa de forma dinámica en función de la entrada del usuario.

Por lo tanto, las pruebas dinámicas implican trabajar con el sistema real, proporcionar una entrada y comparar el comportamiento real de la aplicación con el comportamiento esperado; en otras palabras, trabajar con el sistema con la intención de encontrar errores.

Por lo tanto, las pruebas dinámicas son el proceso de validar una aplicación de software tal como lo haría un usuario final, en diferentes entornos, para desarrollar el software adecuado.

¿Qué hacen las pruebas dinámicas?

El objetivo principal de las pruebas dinámicas es garantizar que el software funcione correctamente durante y después de la instalación, ofreciendo una aplicación estable y sin fallos importantes. Ningún software está completamente libre de errores, y las pruebas pueden revelar la presencia de defectos, pero nunca su ausencia.

Las pruebas dinámicas también garantizan la coherencia en todo el software, como muestra este ejemplo.

En una aplicación bancaria hay varias pantallas, como Mis cuentas, Transferencia de fondos y Bill Pagar. Todos ellos contienen un campo de importe.

Supongamos que el campo Mis cuentas muestra el importe como 25,000, Transferencia de fondos muestra $25,000 y el Bill La pantalla de pago muestra 25000 dólares. La cantidad es la misma, pero la forma en que se muestra no lo es, lo que provoca inconsistencias en el software.

La coherencia no se limita a la funcionalidad. También abarca estándares como el rendimiento, la usabilidad y la compatibilidad, razón por la cual las pruebas dinámicas son tan importantes.

Tipos de pruebas dinámicas

Las pruebas dinámicas se clasifican en dos categorías.

  • Blanco Box Pruebas
  • Negro Box Pruebas

El diagrama que aparece a continuación relaciona las dos categorías con los niveles de prueba que se encuentran debajo de ellas.

Las pruebas dinámicas se dividen en cajas blancas y cajas negras con niveles funcionales y no funcionales.

A continuación se describe cada tipo y su finalidad.

Blanco Box Pruebas — Método de prueba de software en el que el evaluador conoce la estructura y el diseño internos. Su objetivo principal es comprobar el rendimiento del sistema a partir del código. Lo realizan principalmente desarrolladores o evaluadores de caja blanca con conocimientos de programación.

Negro Box Pruebas — Un método de prueba en el que la estructura interna, el código y el diseño no son conocidos por el evaluador. Su objetivo principal es verificar la funcionalidad del sistema bajo prueba. Este tipo de prueba requiere la ejecución del conjunto completo de pruebas, la realizan principalmente evaluadores y no requiere conocimientos de programación.

Las pruebas de caja negra se clasifican a su vez en dos tipos.

  • Prueba de funcion
  • Pruebas no funcionales

Prueba de funcion

Prueba funcional Se realiza para verificar que todas las características desarrolladas coincidan con las especificaciones funcionales. Se lleva a cabo mediante la ejecución de la función. Casos de prueba Escrito por el equipo de control de calidad. En esta fase, el sistema se prueba introduciendo datos, verificando la salida y comparando los resultados reales con los esperados.

Existen diferentes niveles de pruebas funcionales, de los cuales los cuatro más importantes son los que se describen a continuación.

  • Examen de la unidad — Una unidad es un fragmento de código pequeño y comprobable. Las pruebas unitarias se realizan en una unidad de software individual y las llevan a cabo los desarrolladores.
  • Pruebas de integración — Se realiza después de las pruebas unitarias, combinando las unidades individuales que se pueden probar. La realizan tanto los desarrolladores como los evaluadores.
  • Pruebas del sistema — Se realiza para garantizar que el sistema se comporte según los requisitos. Generalmente, los evaluadores lo llevan a cabo cuando el sistema completo está listo, una vez que la versión se entrega al equipo de control de calidad.
  • Test de aceptación — Se realiza para verificar si el sistema cumple con los requisitos del negocio y está listo para su uso o implementación. Generalmente, lo realizan los usuarios finales.

Pruebas no funcionales

Pruebas no funcionales Es una técnica de prueba que no se centra en los aspectos funcionales, sino en los atributos no funcionales del sistema, como las fugas de memoria, el rendimiento o la robustez. Las pruebas no funcionales se realizan en todos los niveles de prueba.

Existen muchas técnicas de pruebas no funcionales, de las cuales las más importantes son las cinco que se describen a continuación.

  • Test de rendimiento — Comprueba si el tiempo de respuesta del sistema es normal, según los requisitos, bajo la carga de red deseada.
  • Pruebas de recuperación — verifica la capacidad de un sistema para recuperarse de fallos y averías de hardware.
  • Pruebas de compatibilidad — verifica cómo se comporta el sistema en diferentes entornos.
  • Pruebas de seguridad — Verifica la solidez de la aplicación, asegurando que solo los usuarios y roles autorizados puedan acceder al sistema.
  • Las pruebas de usabilidad — verifica la usabilidad del sistema por parte de los usuarios finales y el grado de comodidad que estos sienten al utilizarlo.

Técnicas de prueba dinámicas

Una vez definidos los tipos, la siguiente pregunta es cómo se ejecuta realmente un ciclo de pruebas dinámico.

Técnicas de prueba dinámicas en el STLC Consta de tareas como el análisis de requisitos para las pruebas, la planificación de pruebas, el diseño e implementación de casos de prueba, la configuración del entorno de prueba, la ejecución de casos de prueba, la notificación de errores y, finalmente, el cierre de las pruebas. Cada tarea en las pruebas dinámicas depende de la finalización de la tarea anterior en el proceso de pruebas.

Dentro del ciclo de vida de las pruebas de software (STLC), el proceso de pruebas dinámicas propiamente dicho comienza con el diseño de los casos de prueba. El siguiente diagrama muestra la secuencia de actividades, cada una de las cuales se describe a continuación.

Flujo del proceso de pruebas dinámicas desde el diseño de la prueba hasta la ejecución y la notificación de errores.

Antes de iniciar el proceso, es necesario acordar la estrategia que se seguirá para las pruebas dinámicas.

Una estrategia de pruebas debe centrarse principalmente en los recursos disponibles y el plazo. En función de estos dos factores, se deben documentar el objetivo de las pruebas, su alcance, las fases o ciclos de las mismas, el tipo de entorno, las suposiciones o desafíos que puedan surgir y los riesgos.

Una vez definida y aceptada la estrategia por la dirección, comienza el proceso de diseño de los casos de prueba.

Diseño e implementación de pruebas

En esta fase el equipo identifica lo siguiente.

  • Características a probar
  • Condiciones de prueba derivadas de esas características
  • Elementos de cobertura derivados de las condiciones de la prueba
  • Casos de prueba derivados de los elementos de cobertura

Caja negra técnicas de diseño de pruebas tales como partición de equivalencia, análisis de valores límite, prueba de tablas de decisión y pruebas de transición de estado son lo que convierte una condición de prueba en un conjunto concreto de casos ejecutables.

Configuración del entorno de prueba

El entorno de prueba Siempre debe ser similar al entorno de producción. En esta fase se instala la compilación y se gestionan y configuran las máquinas de prueba.

Ejecución de prueba

Durante esta fase se ejecutan realmente los casos de prueba, ya sea manualmente o a través de la automatizacióny los resultados reales se registran comparándolos con los resultados esperados.

Informe de error capturado

Según la ejecución, si los resultados esperados y reales no son los mismos, el caso de prueba debe marcarse como Fallido y se debe registrar un error en el sistema. gestión de defectos .

Ventajas de las pruebas dinámicas

  • Las pruebas dinámicas revelan defectos que se consideran demasiado difíciles o complicados de detectar, y que el análisis estático no puede abarcar en absoluto.
  • El software se ejecuta de principio a fin, lo que eleva la calidad tanto del producto como del proyecto.
  • Las pruebas dinámicas son un medio esencial para detectar amenazas de seguridad en un sistema en funcionamiento.
  • Los fallos que solo se producen durante la ejecución, como las fugas de memoria, los problemas de sincronización y los fallos de integración, aparecen aquí y en ningún otro lugar.

Desventajas de las pruebas dinámicas

  • Las pruebas dinámicas consumen mucho tiempo, ya que la ejecución de la aplicación o el código requiere una gran cantidad de recursos.
  • Esto incrementa el coste del proyecto, ya que no se inicia en las primeras etapas del ciclo de vida del software y los problemas que se solucionan en fases posteriores resultan más caros de reparar.
  • Un entorno similar al de producción y datos de prueba realistas son requisitos previos, y ambos requieren esfuerzo para su creación y mantenimiento.

Preguntas Frecuentes

Los desarrolladores se encargan de las pruebas de caja blanca, realizando comprobaciones de unidades y componentes. Los evaluadores de control de calidad se encargan de las pruebas de caja negra, desde las pruebas del sistema en adelante. Los usuarios finales cierran el ciclo con las pruebas de aceptación.

Los modelos leen los requisitos y los casos existentes, y luego proponen los valores límite, las entradas no válidas y las secuencias de estados que un evaluador humano suele pasar por alto. Un evaluador confirma cada resultado esperado antes de la ejecución.

Sí. La estructura de las aserciones, los objetos de página y la configuración de los fixtures son código repetitivo que un asistente maneja bien. Decidir qué constituye un comportamiento correcto sigue siendo un juicio humano basado en los requisitos.

Marcos de unidades como JUnit, TestNG y pytest, además de los ejecutores de interfaz de usuario y API como Selenium, Cypress y Postman. Cargar herramientas como JMeter cubrir el lado no funcional de la automatización.

Los informes de trabajo de caja blanca muestran la cobertura de declaraciones, ramas y rutas de ejecución instrumentadas. Los informes de trabajo de caja negra muestran la cobertura de requisitos y condiciones de prueba. Ninguno de estos indicadores por sí solo demuestra que la compilación se haya probado adecuadamente.

No. Las pruebas dinámicas describen la ejecución del código, independientemente de quién o qué lo controle. Un script manual Tanto la ejecución en tiempo real como un conjunto de pruebas de regresión automatizadas son pruebas dinámicas.

Sí. Las pruebas dinámicas de seguridad de aplicaciones sondean una aplicación en ejecución desde el exterior, exactamente como una caja negra. pruebas de seguridad Sí lo hace, e informa sobre vulnerabilidades que solo aparecen en tiempo de ejecución.

Es la columna vertebral de uno. Las suites de unidades y API controlan cada confirmación, mientras que más tiempo regresión y las pruebas de rendimiento se ejecutan todas las noches sobre una compilación desplegada.

Resumir este post con: