¿Qué es la prueba de subprocesos en las pruebas de software?

¿Qué es la prueba de subprocesos?

Prueba de subprocesos es un tipo de prueba de software que verifica la capacidad funcional clave de una tarea específica, llamada hilo. Generalmente se lleva a cabo en la etapa temprana del desarrollo. pruebas de integración fase. Las pruebas basadas en hilos son una de las estrategias incrementales adoptadas durante las pruebas de integración del sistema. Por esa razón, una prueba de hilos se describe más apropiadamente como una prueba de interacción de hilos.

Un hilo aquí no es solo un hilo del sistema operativo. En Ingeniería de software En términos de términos, un hilo es una transacción comercial completa; por ejemplo, "el cliente realiza un pedido". traca través de cada módulo con el que interactúa. Las pruebas de subprocesos determinan si esa única ruta sigue comportándose correctamente una vez que los módulos están conectados entre sí.

El siguiente diagrama muestra cómo se integran y se utilizan los hilos individuales como un subsistema antes de que se ensamble el sistema completo.

Tipos de pruebas de subprocesos

Las pruebas basadas en hilos se clasifican en dos categorías, y esta distinción determina tanto los datos de prueba como los defectos que es probable encontrar.

• Pruebas de un solo hilo: Una prueba de un solo hilo implica una transacción de la aplicación a la vez. Solo se atiende una solicitud, por lo que el comportamiento de la respuesta es predecible y la prueba es fácil de programar y repetir.
• Pruebas multihilo: Una prueba multihilo implica varias transacciones activas simultáneamente. Se preparan hilos separados para el mismo servicio, de modo que se pueda observar la capacidad de respuesta y la gestión del estado compartido bajo carga simultánea.

Una transacción que se ejecuta correctamente en una prueba de un solo hilo aún puede fallar en una ejecución de varios hilos, porque la segunda ejecución agrega contención por los mismos registros, conexiones y memoria.

Cómo hacer pruebas de subprocesos

El proceso de hilos se centra en las actividades de integración en lugar del ciclo de vida completo del desarrollo. En la práctica, el enfoque funciona de la siguiente manera.

• Las pruebas basadas en subprocesos son una forma generalizada de pruebas basadas en sesiones, en el sentido de que las sesiones son una forma de subproceso, pero un subproceso no es necesariamente una sesión.
• El hilo o programa (una pequeña funcionalidad) se integra y prueba de forma incremental como un subsistema, y ​​luego se ejecuta para todo el sistema.
• En su nivel más básico, proporciona a los integradores un mejor conocimiento del alcance de lo que deben probar.
• En lugar de probar directamente los componentes de software, exige que los integradores se concentren en probar las rutas de ejecución lógicas en el contexto de todo el sistema.

Debido a que la unidad de trabajo es una ruta de negocio en lugar de un componente, las pruebas de subprocesos se ubican naturalmente entre prueba de módulos y completo prueba del sistema.

Consejos para pruebas multiproceso

Los defectos en sistemas multihilo dependen de la sincronización, por lo que una sola ejecución sin errores demuestra muy poco. Los consejos que se presentan a continuación aumentan la probabilidad de detectarlos.

• Prueba tu programa multihilo ejecutándolo repetidamente con una combinación diferente de aplicaciones en ejecución.
• Prueba tu programa multihilo ejecutando varias instancias del programa simultáneamente.
• Ejecute su programa multihilo en diferentes modelos de hardware con distintos niveles de estrés y cargas de trabajo.
• Utilice la inspección de código, ya que algunos fallos de sincronización son más fáciles de leer que de reproducir.
• Recopile únicamente los errores y fallos que se hayan producido en hilos distintos del principal.

Defectos comunes detectados durante las pruebas de roscas

Los fallos de concurrencia rara vez se hacen notar con una pila limpia. trace. Las categorías que se detallan a continuación abarcan la mayor parte de lo que revela una ejecución multihilo, y cada una tiene un síntoma distinto que vale la pena reconocer.

• Condiciones de la carrera: Dos hilos leen y escriben el mismo valor sin orden específico, por lo que el resultado final depende de qué hilo terminó primero. Síntoma: totales correctos en algunas ejecuciones e incorrectos en otras.
• Punto muerto: Dos hilos mantienen un bloqueo que el otro necesita, y ninguno avanza. Síntoma: la transacción se queda bloqueada indefinidamente en lugar de fallar con un error.
• Contención de recursos: Los subprocesos se ponen en cola para la misma conexión, identificador de archivo o registro, y el rendimiento se desploma mucho antes de que se alcance el límite del hardware.
• Corrupción de datos: Las estructuras compartidas escritas parcialmente dejan los registros en un estado que ninguna transacción válida podría producir.
• Inanición: Un hilo de baja prioridad nunca obtiene el recurso que necesita, por lo que una ruta de usuario agota el tiempo de espera mientras que el resto del sistema parece funcionar correctamente.

Cada uno de estos necesita que la ejecución fallida quede registrada, porque un defecto que se reproduce una vez en cincuenta intentos es imposible de reportar de otra manera. proceso de gestión de defectos.

Pruebas de subprocesos vs. Pruebas de concurrencia vs. Pruebas de integración

Los tres términos se superponen y suelen confundirse en los planes de prueba. La tabla los separa según su finalidad.

En breve, pruebas de concurrencia Las pruebas de subprocesos analizan qué efecto tiene el acceso simultáneo en el sistema, mientras que las pruebas de subprocesos determinan si una ruta importante sobrevive a la integración. Los equipos que realizan ambas suelen programar primero las pruebas de subprocesos.

Ventajas de las pruebas de subprocesos

Esta técnica se justifica su inclusión en un plan de integración por varias razones prácticas.

• Las rutas comerciales clave se validan con antelación, de modo que se detecta cualquier fallo en la transferencia de información antes de que se ensamble el sistema completo.
• Los integradores obtienen una visión clara del alcance, porque la unidad de prueba es una transacción reconocible en lugar de un absolutotraclímite del componente t.
• Probar las rutas de ejecución lógicas en el contexto del sistema expone fallos que aislaban prueba de componentes no puedo ver.
• Las ejecuciones multihilo ponen de manifiesto defectos de concurrencia —interbloqueos, condiciones de carrera y conflictos de recursos— que, de otro modo, llegarían a producción.
• La integración incremental mantiene reducida la superficie de depuración, ya que solo se agrega un hilo a la vez.
• Los resultados se introducen directamente en pruebas de regresión, porque un hilo que pasa por alto es un candidato obvio para el conjunto de pruebas de regresión.

Desventajas de las pruebas de subprocesos

• En las pruebas multihilo, el mayor desafío reside en poder programar una prueba reproducible para una prueba unitaria.
• Escribir pruebas unitarias para código multihilo es una tarea compleja.
• Los criterios de prueba para las pruebas multihilo difieren de los de las pruebas de un solo hilo. En las pruebas multihilo, factores como el tamaño de la memoria, la capacidad de almacenamiento y los problemas de sincronización varían cuando el código se ejecuta en hardware diferente.
• Los hilos no se pueden probar antes de que estén disponibles los módulos que atraviesan, por lo que la planificación depende del orden de integración.
• Es fácil descartar las fallas intermitentes como ruido ambiental, lo que hace que el registro disciplinado sea esencial.

Preguntas Frecuentes