Un flujo de trabajo seguro de Android no sigue pulsando hasta que algo suceda. Identifica la pantalla actual, limita los intentos de reintento, verifica el siguiente estado y se detiene con evidencia cuando el resultado es incierto.
La respuesta corta: detente cuando la siguiente acción ya no sea justificada.
Una condición de parada de automatización de Android es una regla que impide que el flujo de trabajo continúe cuando la pantalla actual, el resultado o el tiempo ya no admiten la siguiente acción. Puede terminar la ejecución, devolver un resultado controlado, recopilar pruebas o enviar el caso a una persona. El punto no es detenerse en cada sorpresa. El punto es evitar convertir la incertidumbre en otro toque.
Los flujos de trabajo fiables responden a cuatro preguntas antes de cada acción importante: ¿En qué estado debe estar el teléfono? ¿Qué observación prueba ese estado? ¿Cuántos intentos de recuperación son aceptables? ¿Qué evidencia debe conservarse si el estado nunca aparece? Android UI Automator incluye esperas condicionales y comprobaciones de estabilidad, mientras que WorkManager documenta la cancelación y el manejo del trabajo detenido. La lección de diseño común es simple: la espera, el intento de nuevo y la detención necesitan límites explícitos.
- Continuar solo cuando el estado esperado se identifique positivamente.
- Intente de nuevo solo cuando el fallo sea temporal y el intento de nuevo tenga un límite claro.
- Detenga o solicite una revisión cuando la pantalla sea desconocida, una acción sea sensible o el postcondicionamiento falle.
¿Continuar, esperar, volver a intentarlo, detenerse o revisar?
| decisión | Úsalo cuando | Límite requerido | Pruebas para conservar |
|---|---|---|---|
| continuar | Se espera tanto el estado actual como la próxima acción | Una transición revisada | Estado observado y postcondición |
| espera | La aplicación todavía está cargando o se está estableciendo | Tiempo de espera o condición de listo nombrada | Tiempo transcurrido y última pantalla |
| volver a intentar | Una condición temporal puede resolverse sin cambiar el significado comercial | Intentos máximos más intervalo | Contador de intentos y resultado de cada observación |
| parada | El estado es desconocido, inválido, inseguro o fuera del camino aprobado | Terminación inmediata | Detener razón, captura de pantalla, resultado estructurado |
| Revisión humana | El flujo de trabajo no puede decidir de forma segura o la siguiente acción tiene consecuencias materiales | Plazo claro para la transferencia de propiedad y propietario | Paquete completo de pruebas y próximo paso propuesto |
Estas opciones no son intercambiables. Una espera da al mismo estado tiempo para que se establezca. Un intento de nuevo repite una observación o acción de recuperación limitada. Un ramo selecciona entre resultados conocidos. Una parada termina el camino revisado. La revisión humana es apropiada cuando la automatización carece de suficientes pruebas para elegir de forma segura.
Paso 1: nombra los estados antes de elegir las acciones
Al final de este paso, cada pantalla importante tiene un nombre y un pequeño conjunto de hechos observables. Comience con un flujo de trabajo estrecho, como abrir una compilación de prueba, navegar a una página de configuración, cambiar una opción no sensible y confirmar el nuevo estado. No comience con una larga secuencia de coordenadas.
- Escribe el estado inicial, el estado siguiente esperado y los estados alternativos aceptables.
- Para cada estado, elija la señal útil más estrecha: propiedad de la interfaz de usuario, texto visible, imagen conocida, objeto detectado o captura de pantalla enfocada.
- Marque cualquier pantalla que nunca deba recibir una acción automática, como una cuenta inesperada, permiso, compra, eliminación o pantalla de datos de producción.
La verificación es sencilla: otro revisador debería poder mirar la definición del estado y explicar por qué la siguiente acción está permitida. elGuía de clic automático de reconocimiento de imágenesmuestra por qué encontrar un objetivo visual no es suficiente. El flujo de trabajo todavía necesita una condición previa antes del toque y una condición posterior después.
Paso 2: elija una observación que pruebe cada estado
Al final de este paso, cada estado tiene una observación primaria y una fuente de evidencia de respaldo. Use la estructura de la interfaz de usuario para hechos semánticos como una etiqueta, un estado seleccionado, un control habilitado o el número de elementos. Use OCR cuando el texto visible es importante, pero el árbol de la interfaz de usuario no lo expone de forma fiable. Use la coincidencia de plantillas para un objetivo visual conocido y la detección de objetos para una clase validada cuya posición o tamaño varía.
Evite apilar varios señales débiles y llamar a la certeza de la combinación. Una captura de pantalla amplia, una plantilla no validada y un resultado OCR parcial no toman automáticamente una decisión fiable. En cambio, defina una observación portante y registre las otras señales como evidencia de apoyo. elComparación de pruebas visuales de Androidexplica dónde encajan el estado de la interfaz de usuario, el OCR, las capturas de pantalla, los plantillas y la detección.
La verificación significa probar tanto muestras positivas como negativas. La condición debe pasar en la pantalla prevista y fallar en una pantalla visualmente similar pero incorrecta. Si no puede distinguir esos estados, reduzca la región, cambie la señal o detenga el flujo de trabajo antes de la acción.
Paso 3: establezca un presupuesto para cada espera y intento de nuevo.
Al final de este paso, ningún bucle puede ejecutarse para siempre. Cada espera necesita un tiempo de espera o una condición de listo nombrada. Cada intento de nuevo necesita un número máximo de intentos, un intervalo razonable y una razón por la que intentar de nuevo podría tener éxito sin empeorar la situación.
| Patrón de fallo | Por qué otro intento puede ayudar | Límite seguro | Detener razón |
|---|---|---|---|
| La pantalla sigue cargando | El mismo estado puede estar listo | Espere hasta que esté estable o expire el tiempo de espera | Condición lista no alcanzada |
| El elemento está temporalmente ausente | El contenido puede llegar con un breve retraso | Observe de nuevo durante un número fijo de intentos | El elemento esperado nunca apareció |
| El toque no produjo ninguna transición | La entrada puede haberse perdido una vez | Uno revisó la repetición después de comprobar la pantalla | La condición posterior sigue ausente |
| Aparece un diálogo o cuenta desconocido | Otro intento no reduce la incertidumbre | Sin volver a intentarlo | El estado inesperado requiere revisión |
| La acción podría eliminar, comprar, enviar o publicar | La repetición ciega puede duplicar las consecuencias | Sin intento automático de nuevo a menos que se demuestre la idempotencia | El resultado de la acción sensible es incierto |
Las preguntas de la comunidad sobre la automatización de Android a menudo describen bucleos que esperan para siempre o tareas que parecen estar atascadas. Una regla de intentos máximos es útil, pero el conteo debe seguir la operación. Una comprobación de lectura única puede tolerar más intentos que una acción que cambia el estado. El número correcto es el presupuesto revisado más pequeño que cubra la latencia normal.
Paso 4: verificar la postcondición antes de declarar el éxito
Al final de este paso, un toque entregado ya no se trata como una tarea completada. Después de cada acción que cambie el estado, espere a que la interfaz se estabilice y observe el resultado esperado. Si falta la postcondición, el flujo de trabajo no debe continuar silenciosamente hacia la siguiente acción.
- Registre el estado que autorizó la acción.
- Realice la única acción aprobada.
- Espere un postcondición nombrado o un tiempo de espera limitado.
- Éxito de la ruta al siguiente estado y fallo en la captura de evidencia, una recuperación revisada o parada.
Esto protege contra superposiciones, navegación retrasada, entradas perdidas, coordenadas obsoletas y pantallas similares. También produce un mejor informe de fallos: el revisador ve lo que se esperaba, qué acción ocurrió y qué estado siguiente no apareció.
Paso 5: preservar suficientes pruebas para que una persona pueda decidir
Al final de este paso, cada parada produce un paquete de pruebas compacto en lugar de una vaga etiqueta fallida. Captura pruebas antes de que las modificaciones de recuperación cambien la pantalla. Mantén solo lo que es necesario para el diagnóstico y maneja capturas de pantalla o registros de acuerdo con la política de datos para la aplicación que se está probando.
- Flujo de trabajo y nombre del paso, construcción de la aplicación, dispositivo, versión de Android, idioma y orientación.
- Estado esperado, estado observado, resultado de la condición, número de intentos y tiempo transcurrido.
- Una captura de pantalla o recorte enfocado, además de texto OCR, puntuación de coincidencia, propiedades de la interfaz de usuario o resultado de detección cuando sea relevante.
- El último estado exitoso, la acción intentada, la condición postcondicional faltante y la razón explícita de parada.
- Una opción sugerida para el revisor: volver a intentarlo después de una solución conocida, actualizar el estado aceptado o investigar el producto.
Una transferencia de trabajo útil permite a alguien tomar la siguiente decisión sin reproducir toda la ejecución primero. elGuía de pruebas de humo de la automatización de QA de AndroidDa un ejemplo más amplio de cómo mantener las comprobaciones de dispositivos reales estrechas y reproducibles.
CómoLaiCai FlowModelos de límites seguros
LaiCai FlowEs una función de automatización dentro deLaiCai Screen Mirroring. Un flujo puede observar la estructura de la interfaz de usuario o el estado visual, bifurcarse entre resultados conocidos, esperar visiblemente, repetir un número limitado de veces, llamar a un flujo hijo hasta el éxito o un límite, y terminar a través de un comportamiento de retorno explícito o de parada. Estos bloques de construcción hacen que la decisión de seguridad sea visible para un revisor.
En un patrón típico, una interfaz de usuario, OCR, plantilla o nodo de detección observa el teléfono una vez. Un ramal enruta un éxito o fracaso conocido. Una espera representa un retraso real en el negocio. Un bucle limitado maneja una condición temporal. Una observación fallida sin borde de recuperación puede terminar el flujo actual en lugar de alimentar la misma acción para siempre.
LaiCai Flow InsidePuede ejecutar un perfil compatible a través deLaiCai Android AgentPor teléfono después del despliegue. La compatibilidad todavía depende de cada nodo, activo, modelo y dependencia de red utilizada por ese perfil. Correr en el dispositivo no elimina la necesidad de límites, pruebas o revisión.
Una lista de verificación de revisión práctica antes del despliegue
- Cada acción tiene una condición previa nombrada y una condición posterior verificable.
- Cada espera tiene un tiempo de espera o condición de listo, y cada intento de nuevo tiene un número máximo de intentos.
- Los estados desconocidos detienen o van a un camino de recuperación revisado.
- Las acciones sensibles nunca se repiten ciegamente cuando su resultado es incierto.
- La evidencia de fallo se captura antes de que la pantalla cambie de nuevo.
- Se han probado casos de pantalla positivos, negativos, lentos, interrumpidos y inesperados en dispositivos autorizados.
Si una de estas afirmaciones es falsa, el flujo de trabajo no está listo para operar sin supervisión. Todavía puede ser útil en modo supervisado a través deAutomatización de IA para Android, donde una persona puede observar el dispositivo, refinar las condiciones del estado y revisar las pruebas de fallo.
Preguntas frecuentes sobre la condición de parada de la automatización de Android
¿Un retraso fijo es una condición de parada?
No. Un retraso fijo solo detiene el flujo de trabajo. No demuestra que la aplicación haya alcanzado el estado esperado. Asocie cualquier retraso con una observación de estado y un tiempo de espera.
¿Debería cada fallo detener todo el flujo de trabajo?
No. Un fallo conocido y temporal puede seguir un camino de recuperación revisado y limitado. Un estado desconocido, una condición postcondicional faltante o una acción sensible incierta normalmente debería detenerse o solicitar una revisión.
¿Cuántos intentos de nuevo son seguros?
No existe un número universal. Utilice el límite más pequeño que cubra la latencia normal medida y reduzca el límite para las acciones que cambian de estado. Si repetir la acción puede duplicar una consecuencia, verifique la idempotencia o no lo intente de nuevo automáticamente.
¿La IA elimina la necesidad de reglas de parada?
No. La IA puede ayudar a interpretar una pantalla o proponer un flujo de trabajo, pero la ejecución todavía necesita estados permitidos explícitos, presupuestos, postcondiciones y límites de revisión. La incertidumbre es una razón para recopilar pruebas, no permiso para continuar.
Haz visible la incertidumbre en lugar de automatizarla a través de ella
Un flujo de trabajo Android confiable no es el que se ejecuta más tiempo. Es el que puede explicar por qué se permitió cada acción, qué resultado esperaba y por qué se detuvo cuando las pruebas cambiaron.
Nombra los estados, elige una observación portante, ata cada espera y intento de nuevo, verifica cada postcondición y preserva una transferencia de trabajo útil. Ese diseño convierte las condiciones de parada del código defensivo en la política de funcionamiento del flujo de trabajo.
- Desarrolladores de Android: Automatizador de interfaz de usuario
- Desarrolladores de Android: Esperas del legado de UI Automator
- Desarrolladores de Android: Administrar el trabajo de WorkManager
- Desarrolladores de Android: Trabajo persistente y restricciones
- Appium: Capacidades de sesión
- Discusión de Tasker: intentos de espera restringidos