¿Qué es el arnés de prueba? (Ejemplos)

Arnés de prueba en pruebas de software

Arnés de prueba en pruebas de software es una colección de códigos auxiliares, controladores y otras herramientas de soporte necesarias para automatizar la ejecución de pruebas. El arnés de prueba ejecuta pruebas utilizando una biblioteca de pruebas y genera informes de prueba. El arnés de prueba contiene toda la información necesaria para compilar y ejecutar una prueba, como casos de prueba, puerto de implementación de destino (TDP), archivo fuente bajo prueba, resguardos, etc.

En pocas palabras, un arnés protege el componente que se desea verificar dentro de un entorno controlado. Los módulos adyacentes que faltan se reemplazan con pequeños programas ficticios, las entradas provienen de un conjunto de datos fijo y cada resultado se registra en un archivo de registro en lugar de leerse de una pantalla. Las secciones siguientes explican por qué los equipos lo construyen, de qué está hecho, cómo funciona y dónde se ubica.

¿Por qué utilizar el arnés de prueba?

Existe un arnés para eliminar la espera del ciclo de prueba. Debido a que simula lo que aún no está listo, pruebas de software El equipo puede comenzar a verificar el comportamiento en el primer sprint en lugar de después de la integración final. El siguiente diagrama muestra dónde se ubica un arnés entre los scripts de prueba y la aplicación que se está probando.

• Automatice el proceso de prueba
• Ejecutar conjuntos de pruebas de casos de prueba.
• Generar informes de prueba asociados
• Soporte para depuración
• Registrar los resultados de las pruebas para cada una de las pruebas.
• Ayuda a los desarrolladores a medir la cobertura del código a nivel de código.
• Incrementar la productividad del sistema a través de la automatización.
• Mejorar la calidad de los componentes y aplicaciones del software.
• Para manejar la condición compleja que los evaluadores encuentran difícil de simular

Estas ganancias importan más en ciclos de lanzamiento cortos. Cuando el código se lanza varias veces por semana, un defecto que sobrevive hasta la etapa de integración cuesta mucho más. traces mejor que uno atrapado contra un tocón el día en que fue escrito. Sin embargo, esa recompensa solo llega cuando el arnés está ensamblado con las piezas correctas.

Componentes clave de un banco de pruebas

Un arnés no es un programa único, sino un conjunto de piezas, cada una de las cuales elimina un obstáculo que, de otro modo, impediría que una prueba se ejecutara sin supervisión.

• Scripts de prueba: Instrucciones automatizadas que indican los pasos a realizar y el resultado esperado, escritas según el script de prueba convenciones
• Motor de ejecución de pruebas: El proceso ejecutor que lee los scripts en orden, resuelve las dependencias y activa la ejecución secuencial o paralela.
• Repositorio de datos de prueba: Valores de entrada almacenados fuera del script en CSV, JSON, XML o una base de datos predefinida, a menudo rellenados por herramientas de generación de datos de prueba.
• Controladores: Módulos ficticios que invocan el componente bajo prueba cuando la capa superior real, como una interfaz de usuario, no está terminada.
• Talones: Módulos ficticios que devuelven respuestas predefinidas; por ejemplo, un servicio de pagos que responde "Pago exitoso" sin contactar con un banco.
• Validador de salida: Lógica de aserción que compara el resultado real con el valor esperado y marca cada caso como aprobado o reprobado.
• Capa de registro e informes: Marcas de tiempo, capturas de pantalla, salida de la consola y un resumen de la ejecución que hacen que cada fallo traccapaz después.

Si se elimina cualquiera de las piezas, el arnés deja de ser automático, ya que entonces hay que añadir algo manualmente en cada ciclo.

¿Cómo funciona un banco de pruebas?

Un arnés repite el mismo bucle en cada ejecución. Conocer ese bucle te dice exactamente dónde está tu propio pruebas de automatización Se conectan los recursos y se indica qué paso está fallando cuando una ejecución se pone en rojo.

1. Preparar el ambiente: El sistema resuelve la configuración del entorno, abre las conexiones y carga los dispositivos, de modo que cada ejecución comienza desde el mismo estado conocido.
2. Cargar los scripts de prueba: Los scripts, los parámetros y los resultados esperados se leen del repositorio. No se introduce nada durante la ejecución, lo que permite que una segunda ejecución sea comparable a la primera.
3. Sustituya los módulos que faltan: Los conductores representan a personas que aún no existen para realizar llamadas, y los eslabones representan servicios que están sin terminar, son inestables o resultan costosos de solicitar.
4. Invocar la aplicación que se está probando: El motor de ejecución activa el flujo de trabajo descrito por el script, ya sea una llamada a un método o una API solicitud o interacción con el navegador.
5. Capturar el resultado real: Los valores de retorno, las cargas útiles de respuesta, las filas de la base de datos, las líneas de registro y el estado de la pantalla se registran a medida que se producen.
6. Comparar con los resultados esperados: El validador de salida comprueba cada valor capturado. Cualquier discrepancia marca el caso como fallido y registra tanto el valor esperado como el observado.
7. Registro e informe: El arnés escribe una marca de tiempo trace de la ejecución y genera un informe de aprobado/reprobado que un desarrollador puede leer sin volver a ejecutar nada.
8. Demoler: Los datos temporales, las conexiones y el estado de los stubs se borran para que el siguiente caso no pueda heredar residuos de este.

💡 Consejo: Actualiza tus stubs cada vez que cambie el módulo real. Un stub que siga respondiendo con el formato del trimestre pasado reportará una ejecución correcta, aunque la integración en vivo ya esté rota.

Un ejemplo práctico ilustra el funcionamiento del bucle. Supongamos que la página de pago está lista, pero la pasarela de pago no. Un controlador envía la solicitud que normalmente enviaría la interfaz; un módulo responde primero con "Pago exitoso" y luego con un tiempo de espera agotado; y el validador confirma el pedido en un caso y solicita un reintento en el otro. Ambos procesos se verifican antes de que el equipo de la pasarela escriba una sola línea de código.

Hay dos contextos donde se utiliza Test Harness

Ese mismo mecanismo cumple dos funciones distintas, y el vocabulario cambia ligeramente dependiendo de en cuál te encuentres.

1. Pruebas de automatización: Contiene el scripts de prueba, parámetros necesarios para ejecutar estos scripts y recopilar resultados para analizarlos
2. Pruebas de integración: Se utiliza para juntar dos unidades de código o módulo que interactúan entre sí para comprobar si el comportamiento combinado es el esperado o no.

Consideremos un módulo de inicio de sesión y un módulo de perfil que deben intercambiar un token de usuario. En el contexto de la integración, un controlador simula un inicio de sesión exitoso y entrega el token a la lógica del perfil, por lo que el mapa de datospingLa comprobación de permisos y la representación de la pantalla se pueden verificar antes de que finalice el servicio de autenticación real. En el contexto de la automatización, ese mismo par de casos se añade a un conjunto y se vuelve a ejecutar en cada compilación sin que nadie tenga que intervenir.

Tipos de arneses de prueba

Dado que el software se construye por capas, un arnés suele estar especializado para la capa que verifica. Existen cuatro tipos que cubren prácticamente todos los proyectos.

A arnés de prueba de la unidad Ejecuta las piezas de código más pequeñas, como una sola función o método, reemplazando cada dependencia por un stub. Es el más rápido de ejecutar y el más barato de mantener, por eso examen de la unidad Las suites suelen ser el primer entorno de pruebas que desarrolla un equipo. Un uso típico consiste en probar un cálculo de impuestos sin modificar el módulo de facturación.

An arnés de prueba de integración Comprueba que dos o más módulos cooperen correctamente y es la capa donde surgen las discrepancias de datos y las llamadas fallidas. Es el arnés descrito en el pruebas de integración En el contexto anterior, por ejemplo, verificar que un servicio de pedidos entregue la información correcta a un servicio de pago.

A Banco de pruebas del sistema impulsa un flujo completo de extremo a extremo a través de la interfaz, el servicio y la base de datos, por lo que prueba del sistema Se puede confirmar que las reglas de negocio se cumplen una vez que todas las capas están presentes. arnés de prueba de regresión Luego vuelve a ejecutar el conjunto acumulado después de cada cambio, que es lo que hace que pruebas de regresión Resulta práctico cuando hay que repetir varios cientos de escenarios en cada fusión.

Herramientas del arnés de prueba

Cada uno de esos tipos normalmente se construye sobre una herramienta existente en lugar de desde cero. Las dos opciones clásicas siguen siendo los marcos de trabajo a nivel de unidad:

• junit: Herramienta utilizada durante el uso Java
• unidad: Herramienta utilizada para usar .NET Framework

Además de estas dos opciones, la mayoría de los equipos añaden herramientas que extienden el sistema al navegador, la capa de API o el perfil de carga. La siguiente tabla relaciona las opciones comunes con la función de cada una.

Cualquiera que sea la combinación que elija, el arnés solo se amortiza una vez que funciona sin supervisión, así que conéctelo a un integración continua trabajo temprano. Un catálogo más amplio de opciones se enumera en el Guru99 herramientas de prueba Resumen. Una distinción aún genera confusión, y conviene aclararla antes de tomar cualquier decisión.

Arnés de prueba versus marco de prueba

A menudo, un arnés y un marco de automatización se confunden, pero responden a preguntas diferentes: el arnés ejecuta las pruebas, mientras que el marco es la estructura dentro de la cual se diseñan. La siguiente tabla los compara.

Preguntas Frecuentes