Pruebas de perfiles Android en escritorio y servidor

Si la QA de Android solo demuestra que una página cabe en una captura estrecha, conviene usar el recorrido de navegador basado en perfiles de BotBrowser para repetir controles de toque, viewport, permisos y navegación, y trasladar las afirmaciones dependientes del hardware a un dispositivo real.

Resumen

• Usa un perfil Android aprobado como línea base documentada.
• Prueba la tarea completa, incluidos toque, orientación, permisos, errores y cambios del área visible.
• Mantén separados los recorridos en navegador autónomo e integrado.
• Lleva sensores, transición nativa, diálogos del sistema y teclado o lector de pantalla reales al hardware.

Contenido

• Una prueba móvil debe representar un recorrido móvil
• Dónde aporta valor
• Cuándo usar un dispositivo Android real
• Decisión de despliegue
• Preguntas habituales
• Conclusión

Una prueba móvil debe representar un recorrido móvil

La cobertura Android se reduce a veces a una captura estrecha. Puede descubrir un problema inicial de diseño, pero no demuestra que el cliente termine la tarea. Los recorridos móviles incluyen toque, cambios de área visible alrededor de formularios, orientación, medios, permisos, navegación de plataforma y convenciones de la familia de navegador.

BotBrowser ofrece flujos Android respaldados por perfiles para hosts de escritorio y servidor. El perfil coordina pantalla, entrada, gráficos, medios, región e identidad de plataforma. Los equipos pueden repetir QA móvil autorizado sin mantener un teléfono físico para cada ejecución automatizada.

Trata el perfil como base documentada. El caso debe nombrar familia móvil, recorrido, clase de cuenta, idioma, orientación y resultado esperado. Así, desarrollo y revisión reciben evidencia reproducible en lugar de ajustes temporales. Para la estrategia más amplia de móvil, tablet y escritorio que respalda esta base, consulta Pruebas de perfiles de dispositivo: móvil, tablet y escritorio, donde se compara cómo planificar y revisar cada clase de dispositivo.

Dónde aporta valor

Resulta útil para diseño adaptable, consentimiento, privacidad, accesibilidad, soporte, regresión y compatibilidad de familias de navegador. Funciona bien en recorridos que permanecen dentro del navegador: acceso, búsqueda, compra, cuenta, carga de documentos, reproducción y aplicaciones web instalables.

Las comprobaciones pueden ejecutarse en estaciones, hosts compartidos y CI. El mismo perfil acompaña un cambio desde desarrollo hasta lanzamiento. Si aparece un fallo, se puede repetir la condición sin esperar al laboratorio.

No sustituye la aceptación ligada a hardware. Calidad de cámara, radio, biometría, batería, temperatura, transición nativa y diálogos del sistema pueden requerir un dispositivo. Un programa práctico reserva el hardware para esos requisitos.

Privacidad en recorridos móviles

Los sitios móviles suelen pedir datos personales cuando la pantalla está llena y el usuario tiene prisa. Ubicación, cámara, micrófono, notificaciones, cargas y pagos merecen atención. La página debe explicar la solicitud, ofrecer una elección real y recuperarse si se rechaza.

Un perfil coherente mantiene unidos pantalla, toque, presentación de navegador, medios y región. El revisor puede concentrarse en lo que pide la aplicación y cómo responde. Para ver cómo la identidad móvil se mantiene coherente entre hosts Android, iOS y de escritorio, consulta Coherencia del navegador móvil entre Android, iOS y escritorio, que explica qué debe esperar un revisor que coincida.

Utiliza cuentas aprobadas y datos sintéticos o controlados. Capturas, vídeos y trazas pueden contener nombres, direcciones o documentos. Recoge lo mínimo, oculta datos antes de compartir y aplica controles de acceso y retención.

Familias autónomas e integradas

Una aplicación Android puede abrir contenido en un navegador autónomo o mostrarlo dentro de una superficie web controlada por la aplicación. Los recorridos pueden diferir en navegación, espacio, cuenta, archivos y retorno a la aplicación.

Trátalos como casos separados. El autónomo suele empezar desde una entrada normal y usar navegación del navegador. El integrado puede comenzar desde una aplicación autenticada, usar un área limitada y devolver el control al terminar. El perfil debe corresponder al escenario del plan.

Define cada caso por la familia visible, el punto de entrada aprobado, la navegación y el resultado esperado. Así, la prueba permanece estable cuando cambia una integración y la evidencia sigue siendo útil para el equipo de producto.

Construir la matriz desde tareas reales

Comienza con tareas móviles importantes: acceso, consentimiento, compra y un recorrido crítico de contenido. Añade compromisos de soporte, accesibilidad y diseños materialmente diferentes. La cobertura programada puede ampliar familias, idiomas y rutas menos frecuentes.

Cada caso debe indicar la familia y orientación, la tarea completa, el resultado de éxito y el propietario del fallo. Un catálogo largo sin requisitos consume recursos y ofrece poca garantía. Un conjunto pequeño con propiedad clara protege mejor a los usuarios.

Pantalla y diseño adaptable

Revisa el recorrido entero. Navegación, consentimiento, diálogos, formularios, medios y acciones principales deben seguir alcanzables. Observa cabeceras fijas, espacio en los bordes y contenido que aparece después de errores o actualizaciones.

Usa vertical como base cuando corresponda. Añade horizontal para vídeo, mapas, documentos, gráficos o tareas que admitan rotación. Conserva estado, datos introducidos, selección, reproducción y diálogos descartados.

El perfil controla la condición de pantalla. Evita superponer ajustes independientes del framework. Si se necesita un tamaño especial, defínelo como variante con resultado propio.

Toque e interacción

Sigue la forma en que una persona completa la tarea. Confirma que los objetivos sean alcanzables y separados, que el desplazamiento sea predecible y que los menús puedan cerrarse. Prueba arrastre o gestos solo cuando el producto los utilice.

La automatización ejecuta acciones aprobadas. La revisión manual detecta opciones de consentimiento difíciles, errores lejos del campo activo o controles demasiado densos. En rutas importantes conviene combinar ambas.

No conviertas el conjunto de QA en un recolector de señales. Observa el producto y conserva evidencia de la aplicación. La calidad de perfiles pertenece al proceso de validación compatible del producto. Para juzgar de forma estructurada si un perfil móvil es suficiente para estas comprobaciones, consulta Revisión de calidad de perfiles móviles, que trata estados de viewport, recorridos de teclado y toque, y cadencia de revisión.

Formularios y área visible

El teclado en pantalla reduce el espacio disponible. Es importante en acceso, búsqueda, dirección, pago, recuperación, chat y editores. El campo enfocado, la etiqueta, el error y la siguiente acción deben permanecer visibles o accesibles.

Completa el formulario. Cambia de campo, corrige un error, abre y cierra una ayuda y vuelve tras cancelar. Confirma desplazamiento y posición al terminar la entrada. Una captura inicial no prueba la secuencia.

BotBrowser ofrece un modo opcional --bot-mobile-keyboard en los flujos móviles compatibles. Al activarlo, visualViewport.height se reduce cuando un campo editable recibe el foco mediante una acción de usuario de confianza, para reflejar el espacio visible que ocupa el teclado. Usa la preparación documentada y deja que el framework se limite a acciones del usuario.

Consentimiento y permisos

Los permisos combinan presentación, explicación y elección guardada. Revisa aprobación inicial, rechazo, cancelación y visita posterior cuando proceda. La aplicación debe continuar de forma segura tras una negativa y explicar cómo cambiar la decisión.

Define el estado del navegador. Un estado limpio representa primera visita y uno conservado representa retorno. Etiqueta cada ejecución y evita que permisos o almacenamiento pasen accidentalmente entre casos.

En cámara y micrófono, revisa vista previa, silencio, cancelación y recuperación. En ubicación y notificaciones, comprueba que la solicitud aparezca en contexto y no presione repetidamente a quien rechazó.

Medios, cargas y descargas

Los controles multimedia necesitan espacio y estado claro. Prueba reproducción, pausa, silencio, subtítulos, pantalla completa cuando corresponda, interrupción y retorno. Los avisos de privacidad deben seguir disponibles cerca de captura o carga.

Las cargas deben explicar el contenido permitido, mostrar progreso y admitir cancelación y reintento. Usa archivos sintéticos y limpia el runner según la política.

Una descarga puede pasar al navegador o al sistema. La prueba con perfil cubre la parte del navegador. Confirma el manejo final en hardware si depende de una aplicación del sistema o una política administrada.

Navegación y transición a aplicaciones

Los recorridos móviles cruzan límites: un enlace de correo abre el navegador, un pago vuelve a la aplicación o soporte abre un documento. Define qué parte pertenece a QA del navegador y cuál requiere hardware o un harness de aplicación.

Comprueba atrás, cancelar, actualizar y volver. El usuario no debe repetir un pago ni perder una recuperación por una transición deficiente. Las familias autónoma e integrada necesitan expectativas separadas cuando su navegación difiere.

Basa el caso en el punto de entrada aprobado y en el resultado observable. Vincula cualquier transición externa con un caso administrado por el equipo responsable de esa aplicación.

Región e idioma

Consentimiento, direcciones, pagos, fechas, soporte y avisos legales pueden cambiar según región. Selecciona idioma, zona y ruta desde el plan autorizado.

Cada condición regional debe ser un caso. Documenta cuenta, familia, idioma, zona y ruta. Durante una investigación, cambia una condición relevante cada vez.

Revisa expansión de texto, presentación de derecha a izquierda cuando se admita, entrada local, formatos e idioma de respaldo. Una página localizada no debe dejar una opción de privacidad sin traducir ni enviar a soporte de otra región.

Accesibilidad

El diseño táctil necesita nombres accesibles, orden de foco útil, contraste, errores claros y alternativas a gestos exclusivos. Si se admite teclado en tablet o teléfono, cúbrelo por separado. La certificación con lector de pantalla debe realizarse con la tecnología y el entorno definidos por el plan.

Los perfiles ofrecen bases visuales e interactivas repetibles antes de la revisión especializada. Detectan controles ocultos, texto recortado, pérdida de foco y problemas de rotación, pero no sustituyen a profesionales de accesibilidad.

Registra movimiento reducido y escalado de texto como variantes explícitas cuando formen parte del producto.

Evidencia con control de privacidad

Registra family, browser.version, recorrido, clase de cuenta, idioma, orientación, estado y resultado esperado. Describe la condición de prueba, no la composición del perfil.

Las capturas deben centrarse en la aplicación. Los vídeos deben empezar poco antes y terminar cuando el resultado sea claro. Oculta información personal, tokens, pagos y hosts. Guarda artefactos bajo controles existentes.

Si necesitas diagnósticos, recógelos durante el tiempo mínimo. Los registros pueden contener identificadores incluso en pruebas. Asigna retención y eliminación antes de ampliar a muchos runners.

Relaciona cada fallo con el paso visible que lo produjo. Un control tapado, un error oculto por el teclado y un retorno incompleto desde otra aplicación suelen pertenecer a responsables distintos. La referencia debe permitir que el equipo correcto reproduzca la condición sin conservar toda la sesión.

Separa evidencia de lanzamiento y material de investigación. La primera demuestra el resultado con el menor contenido posible. El segundo puede necesitar más contexto, pero recibe acceso limitado, fecha de caducidad y un propietario que confirme su eliminación.

Antes de aprobar una versión, revisa que cada referencia conserve la condición inicial, el resultado esperado y la decisión del responsable. Si una ejecución falla, vuelve a la última combinación aprobada, repite el recorrido con los mismos datos y conserva ambos resultados bajo la misma incidencia. Esta relación permite distinguir una regresión de una variación del entorno sin ampliar la recopilación.

Operación en CI

El runner recibe navegador, perfil, pruebas y secretos aprobados mediante controles normales. Fija browser.version, perfil y secretos para la puerta de lanzamiento. Una ejecución que cambia silenciosamente de perfil o versión no puede compararse bien.

Separa directorios de datos entre casos paralelos. Define el estado para primera visita y retorno. Limpia cargas sintéticas y conserva solo la evidencia necesaria.

Mide capacidad con la aplicación. Medios, documentos y paneles consumen más que un formulario. Empieza con concurrencia moderada, observa finalización y margen, y fija un límite específico. Revisa tras actualizaciones.

Incluye en la puerta los finales que liberan recursos: cierre normal, cancelación, espera agotada y fallo de la aplicación. Un recorrido puede mostrar el resultado correcto y dejar estado que afecte al siguiente caso. La capacidad solo vuelve al pool después de completar la limpieza prevista.

Cuando un runner se desvía de la referencia, retíralo de nuevas tareas y conserva su asignación para la revisión. Sustituir perfil, versión y ruta a la vez dificulta la atribución. Restaura primero una combinación aprobada y cambia una sola condición en el siguiente ensayo.

Desarrollo y soporte

Un desarrollador puede usar la misma familia que CI para reproducir un problema. Mantén versión, cuenta, idioma y recorrido. Usa un directorio dedicado y datos aprobados. Comparte una ruta breve y evidencia ocultada.

Para soporte, pide hechos relevantes: recorrido, familia aproximada, orientación, navegador, idioma, estado y resultado visible. Esta información suele bastar para seleccionar una base de reproducción aprobada.

Selecciona el perfil aprobado más cercano y repite con datos controlados. Si el comportamiento depende de un teléfono, una aplicación, un sensor o una política concreta, escala al entorno de hardware.

El informe de soporte debe distinguir una reproducción confirmada de una aproximación. Esa diferencia orienta al equipo hacia un cambio de producto, una revisión de perfil o una prueba en dispositivo.

Reproducción para soporte

El equipo de soporte debe usar la misma base móvil para reproducir un problema y registrar recorrido, familia, orientación, idioma, estado y resultado visible; las diferencias que dependan de un dispositivo real se escalan por separado.

Actualizaciones y lanzamiento

Ejecuta la puerta móvil tras cambios en navegador, perfiles, framework o aplicación. Cambia una capa cada vez cuando sea posible y compara con la misma familia y orientación.

Prioriza consentimiento, acceso, compra, retorno de pago, cargas y soporte. Revisa rechazo y cancelación, no solo éxito. Una versión puede parecer sana y dejar atrapado al usuario que corrige un error.

La cobertura programada puede seguir cuando la puerta sea estable. Toda cuarentena necesita motivo, caso diagnóstico y fecha de revisión.

Promueve la nueva combinación por grupos. Mantén disponible la referencia anterior hasta que el grupo candidato complete su periodo de observación. La reversión restaura navegador, perfil y preparación del host como una unidad, después de drenar las tareas activas.

Cuándo usar un dispositivo Android real

Usa hardware para cámara o micrófono reales, radio, biometría, entrega de notificaciones del sistema, batería, temperatura, comportamiento específico del fabricante, aplicaciones nativas o políticas administradas.

Usa perfiles para diseño, toque, formularios, consentimiento, navegación, región y regresión dentro del navegador. Reserva la emulación adaptable simple para diseño temprano cuando solo importe el ancho.

BotBrowser soporta perfiles Android que proporcionan entrada táctil, un viewport móvil definido por el perfil, la relación de píxeles del dispositivo y la orientación, además de un modo opcional --bot-mobile-keyboard que reduce visualViewport.height cuando un campo editable recibe el foco por una acción de usuario de confianza. Para tu equipo, esto ofrece una base móvil documentada que puedes repetir en las pruebas de formularios, consentimiento y navegación, con el cambio de espacio visible causado por el teclado como condición explícita y etiquetada. BotBrowser no sustituye el hardware Android físico para cámara, biometría, radio, batería, traspaso a aplicaciones nativas ni diálogos del sistema operativo. No garantiza el comportamiento de un teclado en pantalla real ni de un lector de pantalla, y no controla la lógica adaptable de la aplicación ni sus resultados.

Tres formas de ejecutar una prueba móvil

La mayoría de los equipos acaban con tres opciones sobre la mesa, y la elección no es cuestión de preferencia. Cada una prueba un conjunto distinto de hechos, y una decisión de versión necesita los hechos que importan al requisito que se está probando.

La cobertura Android con perfil ejecuta un perfil Android compatible en un host de escritorio o servidor gestionado. La entrada táctil, el viewport móvil, la relación de píxeles del dispositivo, la orientación, la identidad de plataforma y la condición del teclado móvil provienen de ese único perfil, así que la misma condición se repite en un puesto de trabajo, un host de pruebas compartido y un runner de CI. Prueba que el recorrido del navegador funciona bajo una condición móvil documentada y produce evidencia que otra persona puede reproducir con el mismo perfil y la misma compilación.

La fidelidad de entrada es donde más se separan. Una ejecución con perfil entrega eventos de puntero como toque, admite el número de puntos táctiles definido por el perfil y puede reducir el viewport visual cuando un campo editable recibe foco de confianza. Aun así envía esos eventos por una pila de entrada de escritorio, así que no reproduce la latencia, la presión ni el contacto accidental de palma de una pantalla real.

El comportamiento del viewport es cercano pero no idéntico. El perfil fija el viewport de diseño y la relación de píxeles, así que los saltos de línea, las cabeceras fijas y el espaciado de área segura se comportan como en la familia objetivo. Un dispositivo físico añade el chrome real del navegador, la barra de estado real y el teclado en pantalla real, todos los cuales reducen el área visible de formas que ninguna métrica simulada reproduce con exactitud.

La reproducción de medios es donde las afirmaciones suelen excederse. Una ejecución con perfil puede confirmar que un elemento de vídeo carga, que los controles son accesibles, que los subtítulos se renderizan y que la página sobrevive a una interrupción. No puede confirmar decodificación por hardware, limitación térmica tras reproducción prolongada ni soporte de códecs ligado a la pila multimedia del sistema del dispositivo. Esas propiedades pertenecen a un teléfono físico o a un laboratorio de dispositivos.

Un dispositivo Android físico prueba toda la pila. Pantalla táctil real, radio real, cámara y micrófono reales, aviso biométrico real, batería y temperatura reales, diálogos del sistema reales, traspaso real a aplicaciones nativas y la compilación propia del fabricante. También es la opción más lenta de agendar, la más difícil de reproducir con exactitud y la más propensa a quedarse inactiva o desfasada.

Un navegador de escritorio en emulación móvil es la opción más barata. Redimensiona el viewport de diseño y a menudo activa la emulación de eventos táctiles, lo que sirve para una revisión temprana de diseño. No puede dar a la página una identidad de plataforma Android coherente, así que los valores de JavaScript, el user agent y los client hints se contradicen entre sí y con el viewport. Prueba el diseño a un ancho, y poco más.

Dimensión	Cobertura Android con perfil	Dispositivo Android físico	Navegador de escritorio en emulación móvil
Fidelidad de entrada	Tipo de puntero táctil, puntos táctiles del perfil, cambio de espacio visible por teclado	Pantalla táctil real con latencia y presión reales	Eventos de puntero salvo que se active la emulación táctil a mano
Comportamiento del viewport	Viewport, DPR y orientación del perfil, viewport de diseño estable	Chrome real, barra de estado y teclado en pantalla reducen el área visible	Solo viewport de diseño redimensionado, sin chrome móvil
Reproducción de medios	Reproducción a nivel de página, controles, subtítulos y manejo de interrupciones	Incluye decodificación por hardware, códecs y comportamiento térmico	Reproducción en una pila multimedia de escritorio, no representativa
Identidad de plataforma	Plataforma, client hints y user agent coherentes en un perfil	El dispositivo real y la compilación del fabricante	A menudo contradictoria entre JavaScript y cabeceras
Qué puede probar	Un recorrido del navegador repetible bajo una condición documentada	Comportamiento de hardware, sensores, sistema y nativo	Diseño a un ancho dado
Qué no puede probar	Cámara, radio, biometría, batería, traspaso nativo, diálogos del sistema	Nada sobre escala, coste o repetibilidad en muchas ejecuciones en paralelo	Identidad móvil, entrada, medios o comportamiento de permisos
Reproducibilidad	Alta, el mismo perfil y compilación en cualquier host	Baja, ligada a un teléfono y su estado	Media, pero la condición no es móvil
Coste por ejecución en paralelo	Bajo, sin teléfono por ejecución	Alto, cada ejecución necesita un dispositivo agendado	Bajo

Cuándo un recorrido móvil debe pasar a hardware físico

Aplica una regla de decisión antes de escribir el caso: si la declaración de aceptación menciona un sensor, un servicio del sistema o un comportamiento de hardware, la comprobación pertenece a un dispositivo físico y ninguna ejecución con perfil puede satisfacerla. Todo lo demás puede empezar en una base con perfil.

Mueve el recorrido a hardware cuando se cumpla cualquiera de estas condiciones:

• El resultado depende de la calidad de captura de cámara o micrófono, no solo del aviso de permiso.
• El resultado depende del comportamiento de radio, del traspaso de red o del comportamiento sin conexión ligado al módem del dispositivo.
• El resultado depende de un aviso biométrico o de un elemento seguro.
• El resultado depende de la batería, la limitación térmica o la reproducción sostenida.
• El resultado depende de un diálogo del sistema operativo o de un traspaso a una aplicación nativa.
• El resultado depende de la compilación propia del fabricante o de un WebView embebido que envía el dispositivo.
• El equipo necesita certificación de lector de pantalla o teclado en pantalla con una tecnología de asistencia concreta.

Mantén el recorrido en la cobertura con perfil cuando la declaración de aceptación trate de la página misma: diseño, objetivos táctiles, finalización de formularios, rutas de consentimiento y rechazo, controles de medios, navegación, presentación regional y regresión contra una base aprobada. Registra el motivo de escalado en el caso para que un revisor posterior sepa por qué se exigió hardware en lugar de suponerlo.

Decisión de despliegue

Antes de incorporar perfiles Android, confirma uso autorizado, propietario, recorridos, política de cuentas, idiomas, capacidad, retención y escalado a hardware. Define quién revisa fallos y cuánto puede esperar un caso bloqueante.

Revisa la matriz tras cambios relevantes y elimina los casos que ya no respondan a un requisito. Cada caso restante debe conservar responsable, resultado esperado, referencia aprobada y una ruta clara hacia hardware cuando la decisión dependa del sistema.

Preguntas habituales

¿Puede ejecutarse un perfil Android en macOS, Linux o Windows?

Los perfiles compatibles funcionan con la versión adecuada de BotBrowser en hosts administrados. Aprueba perfil, navegador y configuración como una sola base.

¿Deben compartir caso los recorridos autónomo e integrado?

No. Cada uno necesita entrada, navegación, resultado y evidencia propios.

¿Cómo se prueba el toque?

Completa tareas con automatización aprobada y revisión manual. Comprueba alcance, desplazamiento, foco, diálogos, gestos usados y recuperación.

¿Puede certificar cámara o biometría?

No. Los requisitos ligados a sensores o servicios del sistema deben confirmarse en el hardware objetivo.

¿Cómo se separan primera visita y retorno?

Usa estado intencional para cada caso y etiqueta la evidencia. Evita transferir permisos o almacenamiento entre pruebas.

¿Es mejor un catálogo grande?

No necesariamente. Un conjunto compacto vinculado al uso, soporte y diferencias materiales resulta más fácil de mantener.

¿Qué debe incluir un informe de fallo móvil?

Incluye la familia del perfil, las versiones, el recorrido, la clase de cuenta, el idioma, la orientación, el estado, el resultado esperado, el comportamiento real del producto y la evidencia mínima redactada.

Conclusión

La cobertura Android aporta valor cuando la misma condición aprobada acompaña el recorrido desde desarrollo hasta CI, lanzamiento y soporte. La coherencia mantiene pantalla, entrada, medios, región y plataforma dentro de esa condición mientras el equipo evalúa el resultado del producto.

Descarga BotBrowser para preparar un entorno móvil autorizado o revisa las funciones de coherencia antes del despliegue. Perfiles multiplataforma trata las opciones de host.

Una observación reproducible del viewport visual

La especificación W3C Visual Viewport permite comprobar un límite: registra window.innerHeight y visualViewport.height antes y después de enfocar un campo. Un cambio del segundo muestra movimiento del espacio visible, no la reproducción de un teclado Android real o una ventana nativa.

Fuentes

• MDN: VisualViewport API
• MDN: Permissions API
• MDN: Media Capture and Streams API
• Android Developers: probar en dispositivos reales
• W3C: Visual Viewport