¿Puede GitHub Copilot ayudar a crear scripts para pruebas de mono?

GitHub Copilot crea rápidamente el arnés: generadores de eventos, manejo de semillas, analizadores de registros y scripts de clasificación de fallos. La estrategia de aleatoriedad y los criterios de aprobación aún necesitan ser definidos por un evaluador.

¿Qué son las pruebas de monos y gorilas? Ejemplos, diferencia

⚡ Resumen inteligente

Las pruebas de mono introducen datos aleatorios e imprevistos en una aplicación en ejecución y observan si sobrevive, de modo que los fallos, los bloqueos y los estados no controlados se exponen mucho antes de que se haya escrito cualquier caso de prueba predefinido.

???? Idea central: Los clics, las pulsaciones de teclas y los gestos aleatorios sondean el sistema en busca de puntos débiles, en lugar de buscar los resultados esperados.
🦍 Contraste de gorilas: Las pruebas de gorila someten a un módulo a una presión constante, mientras que las pruebas de mono recorren toda la aplicación.
🧠 Tres grados: Los monos tontos, inteligentes y brillantes difieren en la cantidad de conocimientos que poseen sobre el sistema que se está probando.
🇧🇷 Un intercambio honesto: Son baratos y rápidos de usar, pero los defectos son difíciles de reproducir y no se puede garantizar la cobertura.
🛠️ Estampación: Android Las herramientas UI/Application Exerciser Monkey, MonkeyRunner y similares generan flujos de eventos automáticamente.
🎯 Mejores ajuste: Las primeras versiones, las interfaces interactivas y las pruebas de estabilidad, siempre acompañadas de pruebas exploratorias y con scripts predefinidos.

Descubre más

¿Qué es la prueba del mono?

Pruebas con monos Es una técnica de prueba de software en la que el evaluador introduce datos aleatorios en una aplicación sin casos de prueba predefinidos y comprueba su comportamiento, en particular si falla. El objetivo de las pruebas experimentales (monkey testing) es encontrar errores mediante la interacción experimental y sin guion predefinido.

El nombre proviene de una imagen sencilla, que se muestra a continuación.

En las pruebas tipo "monkey testing", el probador (y a veces el desarrollador) es tratado como el "mono".
Si un mono utilizara un ordenador, realizaría tareas al azar, sin comprender el sistema.
Del mismo modo, el evaluador aplica entradas aleatorias al sistema que se está probando para encontrar errores sin predefinir ningún caso de prueba.
En algunos casos, las pruebas con monos tienen como objetivo examen de la unidad or Pruebas de GUI.

¿Qué son las pruebas de gorilas?

Pruebas con gorilas Es una técnica de prueba de software en la que se prueba repetidamente un módulo del programa para confirmar que funciona correctamente y no contiene defectos.

Un solo módulo puede ser probado cien veces o más exactamente de la misma manera, razón por la cual las pruebas de gorila también se conocen como "pruebas frustrantes". Las pruebas de mono se extienden aleatoriamente por toda la aplicación; las pruebas de gorila se centran en un punto hasta que falla o demuestra ser sólida.

Tipos de pruebas con monos

Las pruebas de simulación se dividen en categorías según el nivel de conocimiento que tenga el evaluador sobre el sistema. El siguiente diagrama resume los tres tipos.

Mono tonto: El evaluador no tiene ni idea del sistema ni de su funcionamiento, y no hay garantía de que ninguna entrada sea válida.
Mono inteligente: El evaluador tiene una idea precisa del sistema, su propósito y su funcionalidad, navega por él y proporciona datos de entrada válidos.
Mono brillante: El evaluador trabaja a partir del comportamiento real del usuario y puede indicar dónde es probable que aparezcan los defectos.

Pruebas con monos vs. Pruebas con gorilas vs. Pruebas ad hoc

Pruebas con monos, pruebas con gorilas y pruebas ad hoc Tienen un carácter espontáneo, por lo que a menudo se confunden. Las dos tablas siguientes los diferencian.

Pruebas con monos vs. pruebas con gorilas

Prueba de mono	Prueba de gorila
Realizado de forma aleatoria, sin casos de prueba predefinidos.	Ni predefinido ni aleatorio: simplemente se repiten las mismas comprobaciones.
Se realiza sobre todo el sistema y puede implicar muchos casos de prueba.	Realizado en algunos módulos seleccionados con pocos casos de prueba.
El objetivo es comprobar si se ha producido un fallo del sistema.	El objetivo es comprobar si el módulo funciona correctamente.

Pruebas con monos frente a pruebas ad hoc

Prueba de mono	Pruebas ad-hoc
Realizado de forma aleatoria, sin casos de prueba predefinidos.	Se realizó sin planificación ni documentación, por lo que no se prepararon casos de prueba ni especificaciones de requisitos de software (SRS).
Es posible que los evaluadores no sepan qué es el sistema ni para qué sirve.	El evaluador debe comprender bien el sistema antes de que comiencen las pruebas.
El objetivo es comprobar si se ha producido un fallo del sistema.	El objetivo es dividir el sistema en subpartes al azar y comprobar su funcionalidad.

Ventajas y desventajas de las pruebas con monos

Dado que esta técnica prioriza la velocidad sobre la planificación, tanto sus ventajas como sus desventajas provienen de la misma propiedad.

Ventajas de las pruebas con monos

Nuevos tipos de errores: El evaluador tiene libertad para trabajar fuera de los escenarios previamente establecidos, lo que saca a la luz errores que nadie pensó en incluir en el guion.
Fácil de ejecutar: Organizar acciones aleatorias con datos aleatorios es una forma rápida de poner a prueba el sistema.
Less personas cualificadas: Las pruebas con monos a menudo se pueden realizar sin la ayuda de evaluadores altamente experimentados.
Less costoso: Su configuración y funcionamiento requieren una inversión considerablemente menor que la de un paquete de software basado en scripts.

Desventajas de las pruebas con monos

Los errores pueden ser difíciles de reproducir: Debido a que las entradas son aleatorias, recrear un fallo puede resultar imposible sin una semilla registrada.
Less exactitud: El evaluador no puede definir un escenario exacto ni garantizar la precisión de lo que se cubrió.
Los conocimientos técnicos siguen siendo útiles: Para que los resultados sean relevantes, los evaluadores necesitan un buen conocimiento del dominio en cuestión.
Lento en relación con el rendimiento: Las ejecuciones pueden prolongarse durante mucho tiempo y aun así arrojar pocos defectos, dejando huecos en el sistema.

Cómo realizar pruebas de monos

Las pruebas de mono se vuelven mucho más eficientes cuando una herramienta las impulsa y se pueden ejecutar contra Android compilaciones, así como aplicaciones de escritorio y web. El proceso general es:

Registre la aplicación que se está probando con la herramienta o el servidor dedicado que la ejecutará.
Prepare las referencias y la configuración que la herramienta necesita para crear un conjunto de pruebas.
Ejecuta el conjunto de pruebas compilado.
Deja que la herramienta escriba su registro: el archivo de registro de la "prueba del mono" registra cada evento generado y los resultados.
Permita que la ejecución continúe hasta que el sistema alcance un punto de fallo, momento en el que la acción que causó el problema quedará registrada en el archivo de registro.
Comparta el informe con el equipo responsable y guarde los datos de la prueba para futuras consultas.

Conserva todos los registros. Una ejecución aleatoria solo es útil más adelante si se guardaron la secuencia de eventos y la semilla que la produjo, por lo que gestión de defectos se puede vincular el fallo a una entrada reproducible.

Herramientas de prueba de monos

Las pruebas de simulación de eventos suelen automatizarse, ya que una máquina puede generar miles de eventos en el tiempo que una persona tarda en producir unas pocas docenas. Las opciones más utilizadas son:

Mono de entrenamiento de interfaz de usuario/aplicación: una herramienta de línea de comandos integrada en Android que se ejecuta en el adb shell y envía secuencias pseudoaleatorias de eventos de usuario, como toques, gestos y pulsaciones de teclas, además de eventos a nivel del sistema, a un dispositivo o emulador.
Corredor de monos: una separacion Python API que controla dispositivos y emuladores desde una estación de trabajo, enviando comandos específicos y capturando pantallas. A pesar del nombre, no es la misma herramienta que el mono de ejercicio.
UI Automator y Appium: general prueba móvil marcos de trabajo que se pueden programar para activar secuencias de eventos semi-aleatorios durante una compilación.
Herramientas de fuzzing como AFL: La misma idea de entrada aleatoria aplicada a los datos en lugar de a los gestos, que se trata en prueba fuzz.

El soporte de herramientas para pruebas de mono es más escaso que para scripts. pruebas de automatizaciónPor lo tanto, la mayoría de los equipos combinan un generador de eventos genérico con su marco de trabajo existente en lugar de comprar un producto específico.

¿Cuándo utilizar las pruebas de mono?

Las pruebas con monos tienen su lugar en situaciones específicas, más que como un sustituto general de las pruebas planificadas.

Úselo cuando:

Antes de que existan casos de prueba formales, es necesario realizar una comprobación de estabilidad sencilla en una versión preliminar.
La interfaz es altamente interactiva (juegos, herramientas de dibujo, reproductores multimedia) y el comportamiento real del usuario es difícil de predecir.
¿Quieres un baño o remojo? estrés Ejecución que busca fallos, fugas de memoria y estados no controlados durante muchas horas.
Una versión ha superado las comprobaciones predefinidas y usted desea una revisión independiente para detectar cualquier aspecto que no haya sido afectado por el script.

Evítalo cuando:

Necesitas evidencia repetible de que se cumple un requisito; esa es la función de un documento escrito. caso de prueba.
La compilación es tan inestable que cada ejecución falla inmediatamente, lo que oculta todo tras el primer fallo.
El tiempo apremia, ya que una partida aleatoria no ofrece ninguna garantía de encontrar nada.

En la práctica, los mejores resultados provienen de la combinación de enfoques: las pruebas con scripts cubren los flujos conocidos, Prueba exploratoria Investiga deliberadamente lo desconocido, y las pruebas con monos ponen a prueba todo aquello que ambos suponían que nunca sucedería.

Preguntas Frecuentes

El nombre evoca la imagen del mono infinito: un mono que pulsa teclas al azar durante el tiempo suficiente acaba produciendo algo significativo. Aplicado al software, la entrada aleatoria acaba alcanzando estados que ningún diseñador anticipó.

Las pruebas exploratorias son deliberadas: el investigador formula una hipótesis, la investiga y se adapta. Las pruebas con monos, en cambio, no están dirigidas por diseño. Una depende del criterio, la otra del volumen y la aleatoriedad.

Comparten el principio de entrada aleatoria, pero difieren en su objetivo. Las pruebas de simulación (monkey testing) activan eventos de usuario en una interfaz. El fuzzing introduce datos mal formados en analizadores y API, generalmente en busca de fallos de seguridad.

Chaos Monkey pertenece a la ingeniería del caos: desactiva servicios o interrumpe la infraestructura de forma aleatoria para probar la resiliencia. La idea común es la aleatoriedad, pero el objetivo es la plataforma en funcionamiento, no la interfaz de usuario.

Los modelos pueden orientar el flujo de eventos hacia las rutas que siguen los usuarios reales, transformando a un usuario común en uno más inteligente. También agrupan los registros de fallos duplicados y clasifican qué fallos aleatorios merecen la atención prioritaria de un desarrollador.

Copiloto de GitHub El sistema se diseña rápidamente: generadores de eventos, manejo de semillas, analizadores de registros y scripts de análisis de fallos. La estrategia de aleatoriedad y los criterios de aprobación aún necesitan ser definidos por un evaluador.

Entre las métricas útiles se incluyen los fallos por cada mil acciones generadas, el número de defectos únicos detectados, la cobertura de código alcanzada durante la ejecución y el tiempo hasta el primer fallo. Analice estas tendencias en varias compilaciones en lugar de analizar una sola ejecución.

Registre la semilla aleatoria y el registro de eventos. Las herramientas que aceptan una semilla reproducirán la misma secuencia, de modo que el fallo pueda identificarse como un caso corto y reproducible y reportarse como un defecto normal.